11.1.2 Processes and procedures in HLR

03.933GPPStage 2Technical realization of Completion of Calls to Busy Subscriber (CCBS)TS

Figure 11.1.2.1: Block diagram of HLRA processes

Figure 11.1.2.2: Process HLRA_Request_Manager

This process is in charge of the user interface procedures and queue handling, i.e. whether the request to processed is present in the queue or not.

The process has three states, "Idle", "Operative" and "Operative Resuming". In the "Idle" state the queue is empty and the only actions to queue are creation of new request and interrogation of the queue. In other states activation, interrogation and deactivation procedures similarly, that is why they are grouped under "*" state.

Whenever the first request is created the process changes it’s state to "Operative", in this state there are request(s) in the queue and none of them are suspended.

When HLRA_Request reports of suspension the process changes it’s state to "Operative Resuming" and the HLRA_Resume is started with correct trigger signal i.e. idle indication from MSC or recall end is waited.

Only NET suspended request can be selected and resumed, USER type suspended requests remain as suspended until them are marked as NET suspended. This happens when idle indication is received from the MSC.

The resuming process is paused if there is new suspended request with cause code Not reach i.e. The resuming starts again when idle condition is met again or there is a new recall with successful outcome i.e. the recall ends without Not Reach indication.

The resuming process will be stopped, if there are no suspended requests in the queue any more. The process changes it’s state to normal "Operative" or "Idle" state.

Figure 11.1.2.3: Process HLRA_Request

This process is created during the activation of service and contains all related data. The process has five different states, "Wait_For_Answer", "Active", "Recall", "Suspended" and "Frozen". During its creation the process sends CCBS_Request via SSAP interface to destination network B containing all call related data as well originating networks retention capabilities.

In the "Wait_For_Answer" state process receives response from destination network which is further relayed to the HLRA_Request_Manager. In case of positive acknowledgement destination network returns info whether the retention is supported in both networks.

In "Active" state process waits recall from destination network, however process can vanish if operation timer T3 expires or explicit deletion is received from the user or destination network. In case of deletion the process informs the queue. When the recall arrives the process transits to the "Recall" state.

In the "Recall" state process waits the recall outcome, either positive or negative. Depending of the recall outcome the request can be deleted, retained or suspended. If the request is to be retained the process transits back to the "Active" state. If the request is suspended due to the T10 expiry, CCBS_Busy condition or the MS is not reachable the process transits to the suspended state.

If the request is deleted during "Recall" due SSAP_Cancel, T3 expiry or explicit deletion the queue is updated immediately and the request changes it’s state to "Recall Deleted" where it waits the recall to end.

In the "Suspended" state actions the request can be resumed if the MS is known to be CCBS_Idle or the request can be deleted due to the explicit deletion or timer T3 expiry.

The request is placed in “Frozen” state whenever it receives Remote User Free indication from the destination network and the request can’t be fulfilled due service interaction or lack of support in MSCVLR. The request shall indicate suspended back to the destination network and stay in the queue. If the service becomes later possible, the request will revert back “Active” state and indicate resumed to the destination network.

Figure 11.1.2.4: Process HLRA_Recall_Manager

This process has two different states, "Idle" and "CCBS_Busy".

The process let’s only one individual process to be in recall state in a time and have a dialogue open to the MSC and it changes it’s state to "CCBS_Busy". In this state other requests are suspended immediately and marked as NET suspended with cause code = Busy.

In "CCBS_Busy" state the process waits recall reporting from the MSC. Possible inputs from the MSC are CCBS_RUF_Ack, CCBS_RUF_Error and CCBS_Call_Report. CCBS_Call_Report can be received if the subscriber has accepted the recall, otherwise the process changes it’s state back to "Idle". If the process receives Query_State request from the HLRA_Resume during the recall the process informs the resume process whether a recall is being processed.

Figure 11.1.2.5: Process HLRA_Resume

The process has four different states, "Idle", "Resume pending", "Wait For Selection" and "Resuming". The process is started when a request is suspended. For the first suspended request it is also set the trigger point i.e. when it is correct to send out selection request for resuming. Two triggers are provided, A_Idle from the monitoring process and Recall_End from the recall handling. If the trigger is set to A_Idle the monitoring process is also started.

When the process is started and correct trigger is set the process waits in the "Resume pending" state to receive a permission to start resuming. When the permission is received the process asks for the first NET request to resumed. If A_Idle signal is received from the monitoring process the resuming process asks the queue manager to set all suspended requests as NET type in order to allow the selection.

When there are no active suspended request in the queue any more the resuming process is stopped i.e. when the "Deleted" signal in the HLRA_Request_Manager is handled.

Figure 11.1.2.6: Process HLRA_Monitoring

Monitoring process has two different states, "Idle" and "Monitoring". Receival of "A_Query" signal transits the process to "Monitoring" state. In this state the process reports "Idle" condition to the resuming process and starts the monitoring again in the MSC if location update or restore data happens.

Figure 11.1.2.7: Procedure HLRA_CCBS_Check_Interactions

This procedure checks whether the Remote User Free indication can be delivered to the MSCVLR or not.

Figure 11.1.2.1: HLRA Processes

NOTE: Figure 11.1.2.1 is one possible method of implementing queue processing in HLR A. Manufacturers are not constrained to follow the implementation given in figure 11.1.2.1. However, the external behaviour of HLR A shall appear to be the same.

Description of above signals:

Relation HLRA_Request_Manager and HLRA_Request

CCBS_Request_Ack signal is acknowledgement of a successful activation from the individual request to the queue manager.

CCBS_Request_Error signal is sent if the destination networks queue is full or the destination networks queue size is set to zero. The individual request is deleted from the originating side.

Suspend is used within HLRA_Request and HLRA_Request_Manager. The queue shall update it’s internal information.

Delete is used within HLRA_Request_Manager and HLRA_Request. The queue manager instructs the individual request the request to die.

Deleted is used within HLRA_Request_Manager and HLRA_Request. The individual request informs the queue of its expiry.

Resume is used within HLRA_Request_Manager and HLRA_Request. The individual request is resumed and it shall inform the destination network of the resumption.

Relation HLRA_Request_Manager and HLRA_Resume

Set_Trigger_Recall_End is used within the HLRA_Request_Manager and HLRA_Resume. If resuming is not ongoing this signal set the resuming process to the "ResumePending" state and query is sent to the recall process.

Set_Trigger_A_Idle is used within the HLRA_request_manager and HLRA_resume. If resuming is not ongoing this signal set the resuming process to the "ResumePending" state. In all cases this causes "A_Query" signal to be sent.

Reset_Trigger_A_Idle is used within the HLRA_request_manager and HLRA_resume. This signal sets the resuming process to the "ResumePending" state and causes "A_Query" signal to be sent.

Select_Resp is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process to start T11.

Not_Selected is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process that the selection was not done and the process will transit to "ResumePending" state.

Stop_Resume is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process to stop it’s actions and stop the monitoring also.

Set_All_Active is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to set all suspended requests as NET suspended and later on they can be resumed.

Select_Active_Req is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to select first NET suspended request to be resumed. If successful the request process will return "Select_Resp", otherwise "Not_Selected".

Select_First_Req is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to select first suspended request to be resumed. If successful the request process will return "Select_Resp", otherwise "Not_Selected".

Relation HLRA_Recall_Manager and HLRA_Request

Recall is used within HLRA_Request and HLRA_Recall_Manager. It contains all call related data in order to form the CCBS_Call.

Completed is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of successful CCBS_Call and causes the request to vanish.

Failure is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of unsuccessful CCBS_Call and causes the request to vanish.

Busy is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of unsuccessful CCBS_Call and causes the request to vanish if retention is not supported.

Suspend is used within HLRA_ Recall_Manager and HLRA_ Request. The request shall change it’s state and report the suspension to the queue manager.

Relation HLRA_Monitoring and HLRA_Resume

A_Query is used within HLRA_Resume and HLRA_Monitoring. It instruct the HLRA_Monitoring to start it’s actions and return the idle condition when possible.

A_Idle is used within HLRA_Monitoring and HLRA_Resume. It informs the resuming process that the subscriber is now CCBS_Idle and not CCBS_Busy.

Stop_Monitoring is used with HLRA_Resume and HLRA_Monitoring. It instructs the monitoring process to stop it’s actions and stop the monitoring from VLR also.

Location_Update/Restore_Data events are tracked and external reporting is started again.

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 1 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 2 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 3 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 4 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 5 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 6 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 7 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 8 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 9 of 10)

Figure 11.1.2.2: Process HLRA_Request_Manager (sheet 10 of 10)

Figure 11.1.2.3: Process HLRA_Request (sheet 1 of 5)

Figure 11.1.2.3: Process HLRA_Request (sheet 2 of 5)

Figure 11.1.2.3: Process HLRA_Request (sheet 3 of 5)

Figure 11.1.2.3: Process HLRA_Request (sheet 4 of 5)

Figure 11.1.2.3: Process HLRA_Request (sheet 5 of 5)

Figure 11.1.2.4: Process HLRA_Recall_Manager (sheet 1 of 4)

Figure 11.1.2.4: Process HLRA_Recall_Manager (sheet 2 of 4)

Figure 11.1.2.4: Process HLRA_Recall_Manager (sheet 3 of 4)

Figure 11.1.2.4: Process HLRA_Recall_Manager (sheet 4 of 4)

Figure 11.1.2.5: Process HLRA_Resume (sheet 1 of 3)

Figure 11.1.2.5: Process HLRA_Resume (sheet 2 of 3)

Figure 11.1.2.5: Process HLRA_Resume (sheet 3 of 3)

Figure 11.1.2.6: Process HLRA_Monitoring (sheet 1 of 2)

Figure 11.1.2.6: Process HLRA_Monitoring (sheet 2 of 2)

Figure 11.1.2.7: Procedure HLRA_CCBS_Check_Interactions