11.2.2 Processes and procedures in HLR

23.0933GPPRelease 17Stage 2Technical realization of Completion of Calls to Busy Subscriber (CCBS)TS

Figure 11.2.2.1: Block diagram of HLRB_processes

Figure 11.2.2.2: Process HLRB_Request_Manager

This process has the task of controlling the queue and determining whether requests to be processed are present in the queue or not.

The process has two states "idle" and "active". In the "idle" state there are no "operative" requests in the queue i.e. there are only suspended requests or no requests at all. In the "active" state there is at least one "operative" request in the queue which needs processing. A transition from "idle" to "active" will trigger this process to start the process "HLRB_Recall_Manager". Only a transition from "active" to "idle" will result in this process stopping the process "HLRB_Recall_Manager".

Figure 11.2.2.3: Process HLRB_Request

This process represents an individual CCBS request on the destination side. Reception of signals on the external interface (SSAP signalling) are handled by this process.

Retention is handled by this process. The individual request is informed by the Recall manager process about the outcome of the CCBS Call. The individual request is in charge to decide on whether it will stay in the destination queue (retention) or not according to its data stored.

T7 expiry is controlled by the individual request in that way, that it remembers T7 expiry when it is the selected request (i.e. a CCBS Recall has been initiated for this request). The event is detected after the CCBS Recall when retention has kept the request in the queue.

Figure 11.2.2.4: Process HLRB_Recall Manager

This process is in charge of the recall handling. It is started and stopped by the process "HLRB_Request_Manager" depending on whether there are operative requests in the terminating queue or not.

As soon as this process is started, it will start the process "HLRB_Monitoring" and wait for a response from this process. The response indicates that user B is idle guarded i.e. a CCBS Recall can be initiated. Hence, the process asks the request manager for selection of an individual request from the terminating queue.

When an individual process is selected, the process initiates a CCBS Recall via the individual request (since the external interface is tied to the individual request), starts T9 and takes over control of the blocking function while waiting for the CCBS Call. Control of blocking is done by sending the signal "Recall_Block" to process "HLRB_Blocking".

While waiting for the outcome of the CCBS Call, the process will be informed either by the selected individual request in the case of negative outcome (suspension or cancellation, both hidden to the process), or by process "HLRB_Monitoring" in the case the CCBS Call has reached the terminating PLMN.

Figure 11.2.2.5: Process HLRB_Monitoring

This process takes care of monitoring events received from MSC/VLR and detects potential conditions for initiating a CCBS Recall.

The process is controlled by the "HLRB_Recall_Manager" process which was formerly in charge of detecting the recall condition.

When the process is started, it invokes the monitoring function in the MSC/VLR and awaits the first event report. The process keeps track of the subscriber state changes by running a state machine which reflects the subscriber states. When there is a transition from subscriber state "not idle" to "idle", then T8 is started. As soon as T8 expires, the process changes state again in order to remember that the subscriber is now idle guarded and a recall could be initiated

Whether a CCBS Recall is initiated or not depends on whether the process "HLRB_Recall_Manager" has asked for this information by sending a "B_Query" signal to the monitoring process. The process "HLRB_Monitoring" gives this information only if the "B_Query" signal has been received. This is done by sending the signal "B_Guarded" to the Recall Manager and it is only done once per request. The monitoring process keeps track on whether a query was received or not by appropriate state changes.

As the monitoring process is in charge for the idle guard function, it also controls the blocking of incoming calls during the idle guard time (T8). Hence, when the recall manager process has sent a "B_Query" (i.e. a CCBS request needs to be processed) then the monitoring process starts the corresponding blocking along with T8. The blocking is only stopped if T8 does not expire. If T8 expires, then blocking is still needed for the following CCBS Recall. The responsibility for controlling the blocking (i.e. switching it off) is given to the recall manager process.

Figure 11.2.2.6: Process HLRB_Blocking

This process controls the CCBS Call delivery reporting when the processes are in the proper state. This means that the reporting functionality of the outcome of the CCBS Call is not blindly triggered whenever there is a terminating CCBS Call.

The process has three different states: "idle", "Blocking" and "Recall Blocking". The "Idle" state reflects the case when blocking is disabled. In the "Blocking" state all incoming calls are blocked (e.g. while T8 is running). The "Recall Blocking" state allows one CCBS Call to pass, which will trigger the CCBS Call delivery reporting in the MSC/VLR via the TS 23.018 process "SRI_HLR". When this happens, the process will automatically change back to state "Blocking" as no other CCBS Call is expected for now.

When the process has detected that destination B is idle, it will start the blocking. Hence, the blocking process will change state to "Blocking". As soon as the process "HLRB_Recall_Manager" has initiated a CCBS Recall, it will cause a state change in the blocking process to state "Recall Blocking". When the CCBS Call is received, "result = OK" indication in signal "SRI_Received_Ack" will trigger the reporting mechanism for CCBS Call delivery via a PRN request in the TS 23.018 process "SRI_HLR".

For Figure 11.2.2.6, sheet 2: The procedure Handle_CFB is specified in TS 23.018, clause 7.3.2.6.

Figure 11.2.2.7: Procedure HLRB_CCBS_Check_Interactions

This procedure checks whether the request is frozen due to the supplementary service interactions.

Figure 11.2.2.8: Procedure CCBS_Handling_HLR

This procedure is called during Send Routeing Info message handling in the HLR. If blocking is active only CCBS Calls can proceed, others will fail with busy or forward indication. For CCBS Call CCBS Call Indicator is set to the Provide Roaming Number message.

Figure 11.2.2.9: Procedure CCBS_Report_PRN_Failure

This procedure is called if Provide Roaming Number returns an error. For CCBS call is then generated an internal call report.

The handling of multiple requests in HLR B can be further clarified by the diagram shown in figure 11.2.2.1.

Figure 11.2.2.1: HLRB_Processes

Description of above signals

Relation Originating Network and HLRB_Request_Manager

CCBS_Request: When the originating network attempts to activate CCBS, it sends a CCBS_Request message to HLRB Request Manager.

CCBS_Request_Ack: When the HLRB_Request_Manager acknowledges the activation, it sends CCBS_Request Ack to originating network.

CCBS_Reject: If the HLRB_Request_Manager does not accept the activation attempt, it sends CCBS_Reject to the originating network indicating long term or short term denial.

Relation Originating Network and HLRB_Request

CCBS_Suspend: If the originating network suspends a CCBS Request, it sends CCBS_Suspend to HLRB Request.

CCBS_Resume: When a request that was suspended is now resumed, the originating network sends a CCBS_Resume message to HLRB Request.

CCBS Cancel: When a request is cancelled in the originating network, it sends a CCBS Cancel message to HLRB Request.

Remote_User_Free: HLRB_Request sends Remote_User_Free to the originating network to inform the originating network that destination B is now idle.

CCBS_Cancel: If a CCBS Request is cancelled in the destination network, HLRB_Request sends CCBS_Cancel to the originating network.

TC_END: If a CCBS Call is successfully delivered to destination B, then HLRB_Request ends the dialogue with the originating network by sending a TC_END message.

Relation HLRB_Request_Manager and HLRB_Request

Selection_Request: Once destination B is idle guarded, then the HLRB_Request_Manager will select the first non-suspended request in the queue for processing by sending "Select_Request" to HLRB_Request.

Inactive: When a CCBS Request is either suspended or unselectable due to the supplementary service interaction, HLRB_Request informs HLRB_Request_Manager so that the queue status can be updated.

Re-Activated: When either a suspended CCBS Request is resumed or the supplementary service interaction with the request ends, then HLRB_Request informs HLRB_Request_Manager so that the queue status can be updated.

Deleted: When a CCBS Request is cancelled, then HLRB_Request informs HLRB_Request_Manager so that the queue status can be updated.

Relation HLRB_Recall_Manager and HLRB_Blocking

Stop_Blocking: When the Recall manager process is stopped by the Request Manager process or the Recall manager receives and ‘End’ signal from the Request manager, the Recall manager sends "Stop_Blocking" to HLRB_Blocking.

Recall_Block: When a "Send RUF" signal is sent to HLRB_Request, the HLRB_Recall_Manager also sends "Recall Block" to HLRB_Blocking so that one CCBS Call can be delivered to destination B, but other normal incoming calls are blocked.

Relation HLRB Recall_Manager and HLRB_Request_Manager

Select_Request: On reception of a "B_Guarded" signal, the Recall manager sends "Select_Request" to the Request manager. The Request manager then selects the first non-suspended request in the queue for processing.

Start_Recall_Manager: When a CCBS Request is successfully activated, the Request manager sends "Start_Recall_Manager" to HLRB_Recall_Manager which subsequently causes the recall manager process to start the monitoring process.

Stop_Recall_Manager: The Request manager can stop the Recall manager process by sending a "Stop_Recall_Manager" signal

Select_Request_Response: When the Request manager has selected a request for processing it sends a response to the recall manager causing the recall manager to initiate a CCBS Recall.

Relation HLRB_Recall_Manager and HLRB_Request

Send_RUF: The Recall manager requests the individual process to send a Remote User Free indication to the originating network by sending a "Send_RUF" signal to the individual process.

Recall_Report: The Recall manager informs the individual process of the result of processing a CCBS Recall by sending a "Recall Report" signal.

END: When a CCBS Request is suspended or cancelled the HLRB_Request process sends an "End" signal to the Recall Manager process.

Relation HLRB_Recall_Manager and HLRB_Monitoring

Start_Monitoring: When the Recall manager process is started by the Request manager process, the Recall manager sends "Start_Monitoring" to the HLRB_Monitoring process to request the status of destination B

Stop_Monitoring: When the Recall manager process is stopped by the Request manager process, the Recall manager sends "Stop_Monitoring" to the HLRB_Monitoring process.

B_Query: HLRB_Recall_Manager requests the HLRB_monitoring process to get informed when destination B has become idle guarded.

Relation HLRB_Monitoring and HLRB_Recall_Manager

B_Guarded: HLRB_Monitoring informs the HLRB_Recall_Manager that destination B has become idle guarded.

Call_Delivery: HLRB_Monitoring informs the HLRB_Recall_Manager about the delivery of the CCBS call.

Figure 11.2.2.2: Process HLRB_REQUEST_MANAGER (sheet 1 of 3)

Figure 11.2.2.2: Process HLRB_REQUEST_MANAGER (sheet 2 of 3)

Figure 11.2.2.2: Process HLRB_REQUEST_MANAGER (sheet 3 of 3)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 1 of 6)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 2 of 6)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 3 of 6)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 4 of 6)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 5 of 6)

Figure 11.2.2.3: Process HLRB_REQUEST (sheet 6 of 6)

Figure 11.2.2.4: Process HLRB_RECALL_MANAGER (sheet 1 of 3)

Figure 11.2.2.4: Process HLRB_RECALL_MANAGER (sheet 2 of 3)

Figure 11.2.2.4: Process HLRB_RECALL_MANAGER (sheet 3 of 3)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 1 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 2 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 3 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 4 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 5 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 6 of 7)

Figure 11.2.2.5: Process HLRB_MONITORING (sheet 7 of 7)

Figure 11.2.2.6: Process HLRB_BLOCKING (sheet 1 of 3)

Figure 11.2.2.6: Process HLRB_BLOCKING (sheet 2 of 3)

Figure 11.2.2.6: Process HLRB_BLOCKING (sheet 3 of 3)

Figure 11.2.2.7: Procedure HLRB_Check_Interactions

Figure 11.2.2.8: Procedure CCBS_Handling_HLR

Figure 11.2.2.9: Procedure CCBS_Report_PRN_Failure