9 Functional requirements of entities performing optimal routeing

03.793GPPStage 2Support of Optimal Routeing phase 1TS

9.1 Charging requirements for optimal routeing

MoU have imposed two constraints for the charging of optimally routed calls:

– No subscriber shall pay more for a call which has been optimally routed than he would do under the present routeing scheme described in GSM 03.04 [5] in the subclauses describing the call cases where the GMSC is in the same PLMN as the HLR;

– At least for the first phase of Support of Optimal Routeing, the charge for one leg of a call shall be paid for entirely by one subscriber.

These constraints mean that the direct route for a call cannot always be used. For example, if the calling mobile subscriber (the A subscriber) is in Germany, and the B subscriber’s HPLMN is in Switzerland but he has roamed to Finland, the charge payable by the A subscriber to route the call by the direct route to Finland would be greater than the charge payable to route the call to HPLMNB, so the HPLMN route must be used.

In the first phase of Support of Optimal Routeing, it cannot be assumed that a GMSC is able to calculate the charge payable for the direct route and the charge payable for the HPLMN leg. The MoU requirements can be met by applying more stringent (but simpler) criteria for deciding whether the direct route may be used:

– If the country code of the destination exchange and the country code of the GMSC are the same, then the direct route may be used;

– Otherwise, for a call leg which is chargeable to the A subscriber, if the country code of the destination exchange and the country code of HPLMNB are the same, then the direct route may be used;

– Otherwise, the HPLMN route shall be used.

In certain cases, the second criterion above (equality of country codes for the HPLMN and the destination exchange) may not be enough to determine equality of the charges payable for the direct route and the HPLMN route. In these cases, analysis of the national destination code as well as the country code is required; however the principle is still that if the two numbers are the same to the depth of analysis required then the direct route may be used.

For optimal routeing of late call forwarding, the constraints are satisfied if the following criteria are applied:

– If the country code of the forwarded-to exchange and the country code of the GMSC are the same, then the forwarded call may be routed directly from the GMSC to the forwarded-to exchange;

– Otherwise, if the country code of the forwarded-to exchange and the country code of HPLMNB are the same, then the forwarded call may be routed directly from the GMSC to the forwarded-to exchange;

– Otherwise, if the country code of the forwarded-to exchange and the country code of VPLMNB are the same, then the forwarded call may be routed directly from the GMSC to the forwarded-to exchange;

– Otherwise the forwarded call shall be routed through VPLMNB.

9.2 Functional behaviour of VMSCA

The functional behaviour of VMSCA is specified in GSM 03.18 [6]. The only function specific to optimal routeing is the transfer of the destination address, if it is received in the ISUP Answer message, to the call data record, to allow the correct charge for the call to be made. This function is required only if VMSCA supports optimal routeing of mobile-to-mobile calls.

9.3 Functional behaviour of VLRA

The functional behaviour of VLRA is specified in GSM 03.18 [6].

9.4 Functional behaviour of GMSC

It should be noted that if a call is being forwarded from VMSCB rather than from the MSC which acted as GMSC for the original call then VMSCB may use the services of an associated GMSC for the forwarding leg, i.e. the associated GMSC requests routeing information from HLRC. In this case, the forwarding leg is processed in the same way as a mobile-originated call from mobile subscriber B.

The functional behaviour of a GMSC is specified in GSM 03.18 [6]. The procedures specific to Support of Optimal Routeing are specified in this subclause.

9.4.1 Procedure OR_Set_ORA_Parameters

9.4.2 Procedure OR_Handle_RCH

Sheet 1: the procedure Activate_CF_Process is specified in GSM 03.18 [6].

Sheet 1: if the GMSC interrogates the HLR for a Forwarded-to number, the Routeing address is the Forwarded-to number received in the Send Routeing Info ack; otherwise the Routeing address is the Forwarded-to number received in the Resume Call Handling.

Sheet 1: the procedure CAMEL_MT_GMSC_Notify_CF is specific to CAMEL phase 2; it is specified in GSM 03.78 for CAMEL Phase 2 [8]. If the GMSC does not support CAMEL, processing continues from the "Continue" exit of the test "Result".

Sheet 2: the task "Destination address:=FTN" is executed only if the GMSC supports optimal routeing of basic mobile-to-mobile calls.

Sheet 2: the process MT_CF_MSC is specified in GSM 03.18 [6].

Sheet 2: the called party address sent in the IAM to the process MT_CF_MSC is the Forwarded-to number received in the Perform Call Forwarding ack.

9.4.3 Procedure Route_Permitted

9.4.4 Procedure OR_Handle_SRI_Negative_Response

‘Non-fatal’ error situations, which cause the call to be routed through a GMSC in the same PLMN as the HLR, are:

– Send Routeing Info request rejected because the HLR does not support OR;

– Protocol error;

– System failure;

– Unexpected data value;

– Data missing;

– OR not allowed.

‘Fatal’ negative responses, which cause the GMSC to return a ‘fail’ result, are:

– Unknown subscriber;

– Number changed;

– Bearer service not provisioned;

– Teleservice not provisioned;

– Call barred;

– CUG reject;

– Forwarding violation;

– Facility not supported;

– Absent subscriber.

Figure 6: Procedure OR_Set_ORA_Parameters

Figure 7a: Procedure OR_Handle_RCH (sheet 1)

Figure 7b: Procedure OR_Handle_RCH (sheet 2)

Figure 8: Procedure Route_Permitted

Figure 9: Procedure OR_Handle_SRI_Negative_Response

9.5 Functional behaviour of HLR

The functional behaviour of an HLR is specified in GSM 03.18 [6]. The procedures specific to Support of Optimal Routeing are specified in this subclause.

9.5.1 Procedure OR_HLR_CF

Sheet 1: if the HLR does not support optimal routeing of basic mobile-to-mobile calls, the test "Optimal routeing allowed" takes the "No" exit.

Sheet 2: the procedures Handle_CFB, Handle_CFNRc and Handle_CFNRy are specified in GSM 03.18 [6].

9.5.2 Procedure OR_HLR_Interrogate_VLR

If the HLR does not support optimal routeing of basic mobile-to-mobile calls, this procedure will be executed only if the Send Routeing Info was from a GMSC in the same PLMN as the HLR, i.e. this was not an Optimal Routeing enquiry.

The procedure Handle_CFNRc is specified in GSM 03.18 [6].

Figure 10a: Procedure OR_HLR_CF (sheet 1)

Figure 10b: Procedure OR_HLR_CF (sheet 2)

Figure 11: Procedure OR_HLR_Interrogate_VLR

9.6 Functional behaviour of VLRB

9.6.1 Functional behaviour of VLRB for provision of subscriber information

The functional behaviour of VLRB for provision of subscriber information is specified in GSM 03.18 [6].

9.6.2 Functional behaviour of VLRB for roaming number allocation

The functional behaviour of VLRB for roaming number allocation is specified in GSM 03.18 [6]. The only function specific to Support of Optimal Routeing is the storage of the OR indicator, the GMSC address and the call reference number if VLRB receives them in the Provide Roaming Number request.

9.6.3 Functional behaviour of VLRB when handling an incoming call

The functional behaviour of VLRB when handling a request for information to handle an incoming call is specified in GSM 03.18 [6]. The only functions specific to Support of Optimal Routeing are:

– the inclusion in the Complete Call or Process Call Waiting, if the call is to be offered to the B subscriber, of the OR indicator and the GMSC address if VLRB received them in the Provide Roaming Number request;

– the inclusion in the Send Info For Incoming Call response, if the call is to be forwarded, of:

– the OR indicator, the GMSC address and the call reference number if VLRB received them in the Provide Roaming Number request;

– the basic service which applies for this call.

9.7 Functional behaviour of VMSCB

The functional behaviour of VMSCB when it handles an incoming call is described in GSM 03.18 [6]. The procedure specific to Support of Optimal Routeing is specified in this subclause.

9.7.1 Procedure Handle_ORLCF_VMSC

Figure 12: Procedure Handle_ORLCF_VMSC