Call Flow

Mobile Originated Prepaid Call to a Ported Out Subscriber

This scenario encompasses the following subscriber types:

Own Subscriber Ported Out - Refers to an Own Subscriber who has ported to a Foreign Network.
Foreign Subscriber Ported to Foreign Network - Refers to a Foreign Subscriber who has ported to a different Foreign Network.
Foreign Subscriber (optional, dependent on how the UDR is provisioned) - Refers to a subscriber whose number belongs to the number range of a Foreign Network, and who has not ported to another Foreign Network.
Foreign Subscriber Not Known to be Ported (optional, dependent on how the UDR is provisioned) - Refers to a Foreign Subscriber whose portability status is unknown by the querying network.

When a prepaid subscriber attempts to originate a call, the MSC/VLR must first query a prepaid SCP before attempting to complete the call, in order to determine if the subscriber has enough credit to complete the call.

Figure 6-4 MO Prepaid Call to Ported Out Subscriber

When a prepaid subscriber originates a call, the MSC/VLR serving that subscriber formulates an INAP or CAP IDP message and routes it to the Prepaid SCP. This message is routed by GTT (SCCP CdPA = PPSCP GTA), with the vSTP serving as either the Intermediate or Final GTT service provider. In either case, the vSTP is either an Intermediate or Final GTT service provider for the message in order for the IDP Relay service to be triggered (the message arriving at the vSTP must have MTP DPC = vSTP PC, SCCP CdPA RI = route-on-GT, and SCCP CdPA GTA = PPSCP).

Upon receipt of the IDP message, the SCCP CdPA TT, SSN, NP, NAI, and GTI Service Selectors are examined to determine which vSTP SCCP service is required. If the message parameters match the provisioned Service Selector combination for IDP Relay service in general, the IDP Relay service determines whether this specific IDP message requires processing, based on examination of the SCCP CdPA GTA digits (which should be the GTA of a PPSCP), the TCAP Operation Code, and the combination of Service Key and EventTypeBCSM in the INAP/CAP layer. If the SCCP CdPA GTA matches one of the provisioned PPSCP addresses, the Operation Code signifies IDP, and the Service Key and EventTypeBCSM matches one of the provisioned service values for the IDP Relay service, then the message is processed by IDP Relay. Otherwise, the message continues through normal SCCP processing.

If the intercepted IDP message is selected for IDP Relay service, IDP Relay processing extracts the B-party number (CDPN, the number which was dialed by the prepaid subscriber) from the INAP/CAP CalledPartyNumber parameter or from the CAP CalledPartyBCDNumber parameter, and performs a lookup in the UDR (after some number filtering and conditioning).

In this scenario, the vSTP finds a match on the B-party DN in the UDR with an association to a Routing Number (RN).

Note:

Typically, an DN entered in the database with an association to an RN indicates that the number is either (a) an Own Number ported to another network, or (b) a Foreign Number which has been ported to another foreign network. In some cases (depending upon how the customer chooses to provision the database), this may also indicate a Foreign Number which is not known to be ported.

After finding a match on DN with an associated RN in the UDR, the the INAP/CAP CDPN parameter is modified by prefixing the RN information to the DN. The CDPN NAI parameter will be copied from the incoming value, or changed to 'Unknown', based on the provisioned IDP Relay configuration options. The IDP Relay service may be configured to either send the same NAI as was received in the incoming CDPN, or to send the value 'Unknown' in all cases.

Note:

The term CDPNNAI is used in this document to represent the value in the INAP/CAPCDPN parameter. In INAP, this parameter is known as “NAI”, while in CAP, it is known as “Type of Number”. CDPNNAI is used here to represent both for simplicity.

After the required modifications are performed, the modified IDP message is routed through GTT to the PPSCP indicated by the original GTA in the SCCP CdPA, which was not altered as a result of the IDP Relay operation. The PPSCP receives the modified IDP message, which contains the portability information needed to correctly charge for the call. The SCP then returns the appropriate response to the MSC/VLR, either allowing or denying the call.

In order for the IDP Relay feature to provide accurate portability information for all ported numbers, all ported numbers must be entered into the UDR, including Own numbers ported out as well as Foreign numbers ported to foreign networks. If a foreign number ported to a foreign network is not entered in the database with a routing number (either in the individual or range entry tables), IDP Relay will not find a match, and will not be able to prefix the routing number information to the CDPN in the IDP message with the routing number of the current subscription network. Thus, the original IDP message unmodified is sent to the SCP with CDPN = dialed DN only. However, even in this case it is possible for the SCP to differentiate calls within the own network from calls to foreign networks very easily.

Mobile Originated Prepaid Call to Imported or Own Non-Ported Subscriber

This scenario encompasses the following subscriber types:

Own Subscriber - Refers to a subscriber whose number belongs to the number range of the Own Network and who has not ported to another network.
Foreign Subscriber Ported In - Refers to a Foreign Subscriber who has ported into the Own Network.

When a prepaid subscriber attempts to originate a call, the MSC/VLR must first query a Prepaid SCP before attempting to complete the call, in order to determine if the subscriber has enough credit to complete the call.

When a prepaid subscriber originates a call, the MSC/MSC/VLR serving that subscriber formulates an INAP or CAP IDP message and routes it to the Prepaid SCP. This message is routed by GTT (SCCP CdPA = PPSCP GTA), with the vSTP serving as either the Intermediate or Final GTT service provider. In either case, the vSTP is either an Intermediate or Final GTT service provider for the message in order for the IDP Relay service to be triggered (message arriving at the vSTP must have MTP DPC = vSTP PC, SCCP CdPA RI = route-on-GT, and SCCP CdPA GTA = PPSCP).

Upon receipt of the IDP message, the the SCCP CdPA TT, SSN, NP, NAI, and GTI Service Selectors to are examined to determine which SCCP service is required. If the message parameters match the provisioned Service Selector combination for IDP Relay service in general, the SCCP CdPA GTA digits (which should be the GTA of a PPSCP), the TCAP Operation Code, and the combination of Service Key and EventTypeBCSM in the INAP/CAP layer are examined to determine whether this specific IDP message requires IDP Relay processing. If the SCCP CdPA GTA matches one of the provisioned PPSCP addresses, the Operation Code signifies IDP, and the Service Key and EventTypeBCSM matches one of the provisioned service values for the IDP Relay service, then the message enters IDP Relay processing. Otherwise, the message continues through normal SCCP processing.

Additionally, for Route on SSN INAP messages with GTI=0, if the OPC/DPC matches a provisioned OPC/DPC, the message is processed by IDP Relay. Otherwise, the message continues through normal SCCP processing.

If the intercepted IDP message is selected for IDP Relay service, IDP Relay processing extracts the B-party number (CDPN - the number which was dialed by the prepaid subscriber) from the INAP/CAP CalledPartyNumber parameter or from the CAP CalledPartyBCDNumber parameter, and performs a lookup in the UDR (after some number filtering and conditioning).

In this scenario, a match is found on the DN in the UDR with an association to an SP entity ID (HLR GTA).

Figure 6-5 MO Prepaid Call to an Imported or Own-Non-Ported Subscriber

In this case, the PPSCP always requires an SP ID to be prefixed to the DN in the CDPN - for both Foreign Numbers Ported In as well as Own Numbers never ported. Based on this, IDP Relay requires that all such numbers be entered in the UDR with an association to an SP ID, either as individual numbers (which is likely the case for imported numbers), or in a number range (which is likely the case of own numbers not ported). This distinction is made because in a standard MNP node, it is often standard practice not to enter Own Subscribers never ported. For SP queries, the standard GTT translation normally suffices for these subscribers, and it is not required to enter them into the UDR. If these numbers are not entered, IDP Relay will not find a match, and would simply transfer the IDP message without modification to the PPSCP (containing DN only in CDPN).

This may not be an issue if the PPSCP correctly interprets when the PPSCP receives an IDP without any RN or SP ID, it assumes the DN is an Own Subscriber, and acts accordingly. It is also beneficial to enter all own subscribers with the respective HLR-ID to streamline MNP processing in networks with a high prepaid subscriber base.

Mobile Originated Prepaid Call to Foreign (Non-Ported) Subscriber

In this scenario, an IDP message is received for a number which is a foreign (non-own-network) number and which has not been ported. Their are two options in this scenario, both configurable through provisioning. In one case, a number range for the foreign network is entered with a Generic Routing Number for the network. In this case, IDP Relay reacts in the same way as with a ported-out number, prefixing the CDPN with the RN taken from the number range entry. Although the number is technically not ported, the use of a range with an RN would still point to the correct network.

Alternatively, if the number is not provisioned in the UDR at all, or is entered without an associated routing number/HLR ID, the IDP message is not modified and the message is simply be relayed to the SCP. In this scenario, the SCP returns the IDP response to the MSC without any prefix.

This method could also be used for Own Subscribers never ported (no entry in the UDR), which would cause IDP Relay to send the unmodified IDP message to the PPSCP.