This subclause describes the functional architecture required to support control and interrogation of subscription data. Figure 10.1 shows the functional entities involved in CAMEL support of control and interrogation of subscription data.

gsmSCF: HLR:

This subclause describes the interface applicable to CAMEL control of subscription data. It specifies on a high level the functions specific to CAMEL.

Handling of Any Time Interrogation for Subscription Information Retrieval involves the following process:

• CAMEL_ATSI_HLR.

If an OSS needs the Subscription Information, the gsmSCF initiates a transaction to the HLR by sending an Any Time Subscription Interrogation Request.

Handling of Any Time Modification involves the following process:

• CAMEL_ATM_HLR.

The following procedures are involved:

• ATM_Modify_Data
  This procedure checks which data shall be modified and calls the appropriate data modification procedure.
• ATM_Modify_CSI_Data
  If the CSI indicated in the ATM request is not available in the HLR, then an error is returned.
  Otherwise, the CSI state and/or Notification-to-CSE flag are set as instructed with the ATM request.
• ATM_Modify_CF_Data
  When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Forwarding data belonging to this SS code and basic service code is erased, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in TS 23.082.
  Otherwise, the behaviour is as follows:
  • If a valid SS-status (i.e., the content of the SS-status parameter takes one of the values defined in the State Transition Model for the corresponding Call Forwarding supplementary service, as specified in TS 23.082) is present in the ATM request, then an SS state transition is performed.
  • If a valid FTN, FTN sub address or No Reply Condition Time is present in the ATM request, then the indicated variable is modified.
  • Before modification of CF data (SS state changed to 'registered', insert or change of FTN), the interaction checks between CF and ODB and between CF and CB shall be performed as described in TS 23.015 and TS 23.082 respectively. The CF data shall only be modified if the changed new CF data does not conflict with the existing ODB or CB entries.
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
  • If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement.
• ATM_Modify_CB_Data
  When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Barring belonging to this SS code and basic service code is deactivated, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in TS 23.088.
  Otherwise, the behaviour is as follows:
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for the corresponding Call Barring supplementary service, as specified in TS 23.088) is present in the ATM request, then an SS state transition is performed.
  • Before modification of CB data (SS state), the interaction checks between CF and CB shall be performed as described in TS 23.088. The CB data shall only be modified if the changed new CB data does not conflict with the existing CF entries.
  • If a valid Password or 'Wrong password attempt counter' is present in the ATM request, then the indicated variable is modified.
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
• ATM_Modify_ODB_Data
  • If ODB data is not present in the ATM request, then it is assumed that the ODB data is not modified. When present, the modification is done by overwriting the existing ODB data.
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
  • If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement.
• ATM_Modify_IP-SM-GW_Data
  • If Modification Instruction is "activate", the IP-SM-GW address is stored if not already pre-configured in the HLR and the process Subscriber_Present_HLR is invoked (see TS 23.012).
  • If Modification Instruction is "deactivate" and there is no IP-SM-GW address pre-configured in the HLR, the stored IP-SM-GW address is deleted.
• ATM_Modify_CW_Data
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Waiting, as specified in TS 23.083) is present in the ATM request, then the Call Waiting state is changed accordingly,
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
• ATM_Modify_CH_Data
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Hold, as specified in TS 23.083) is present in the ATM request, then the Call Hold state is changed accordingly,
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
• ATM_Modify_ECT_Data
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Explicit Call Transfer, as specified in TS 23.091) is present in the ATM request, then the Explicit Call Transfer state is changed accordingly,
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
• ATM_Modify_CLIP_Data
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIP, as specified in TS 23.081) is present in the ATM request, then the Calling Line Identification Presentation state is changed accordingly,
  • If the Override Category is present, the Override Category is changed accordingly.
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.
• ATM_Modify_CLIR_Data
  • If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIR, as specified in TS 23.081) is present in the ATM request, then the Calling Line Identification Restriction state is changed accordingly,
  • If the Override Category is present, the CLI Restriction Option is changed accordingly.
  • If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified.

After having executed the Any Time Modification instruction from the gsmSCF, the HLR calls the procedure CAMEL_NSDC_HLR, which sends notifications to gsmSCF(s), if required.

Changes of CSI, Call Forwarding data, Call Barring data, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data or ODB data shall be notified only if the corresponding data is marked with the Notification-to-CSE flag. The HLR maintains a list of gsmSCF address(es) for Call Forwarding Data, Call Barring Data, ODB, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data and CSI. When any of these items has been modified, a notification shall be sent to each gsmSCF in the corresponding list. The sending of a notification to the gsmSCF may be triggered by the following processes:

• subscriber data change by administrative procedure;
• subscriber data changed by subscriber;
• subscriber data changed by Any Time Modification request from gsmSCF;
• subscriber data changed due to a change of other subscriber data;
• subscriber data change due to Location Update.

When a change of subscriber data is requested by Any Time Modification, Any Time Modification acknowlegement is returned to the requesting gsmSCF confirming the status of the altered data. Separate Notifications of subscriber data change shall also be returned to the requesting gsmSCF for each other piece of altered data, but these shall not contain the requested change. Each gsmSCF shall be notified only once. Multiple occurrence of gsmSCF Address in these lists shall not lead to multiple notification. Handling of Notify Subscriber Data Change involves the following procedure:

• CAMEL_NSDC_HLR.

If a change of subscriber data needs to be notified to the gsmSCF, then the HLR initiates a transaction to the gsmSCF by sending Notify Subscriber Data Change information flow.