sms signaling for roaming billing

7/27/2019 SMS Signaling for Roaming Billing

1/19

Signaling for International Roaming SMS Billing

Ver 0.3

10 August 2006

Revision History0.1 2006-05-15 Initial version0.2 2006-08-03 Expand and update0.3 2006-08-10 Change MT Return Result OPC/CgPA


2/19

Page 2 of 19

Contents

1. Introduction......................................................................................................................3

2. Existing Signaling............................................................................................................4

3. Proposed Solution............................................................................................................9

4. Glossary.........................................................................................................................17

5. Appendix MAP Layer Identifier.................................................................................18


3/19

Page 3 of 19

1. Introduction

The Voice and SMS Working Group (VSWG) of the CDG IRT is working to address the

issues involved with International Short Message Service (SMS) Roaming Billing.

Of particular interest has been the need to ensure that the home operator is able to charge

its subscribers at a rate which accurately reflects the different intercarrier wholesale rates

that may be charged by the operators individual roaming partners.

There are several broad options possible and/or available for delivery of the necessaryinformation (identification of the serving operator) to the home operator. Based on

expressed operator preference (and the fact that some other options are already available),

the VSWG has focused on the use of the existing internetwork ANSI-41 signaling to

carry the necessary information to the home operators Message Center (MC, akaSMSC). The billing record generated by the MC is used for subscriber billing.

Given this general approach, there are a number of parameters within the relevantsignaling messages that could be used to carry the necessary information. At the June

2006 IRT, operators expressed their preference for the use of a transport-layer identifier(e.g. point code, Calling Party Address) to specify the serving network. This document

describes this approach in further detail, including modifications to accommodate

different signaling methods (point code routing and Global Title Translation). When

point code routing is used, there are two locations for the serving network identifier, andoperator feedback on the preferred approach is invited. An appendix describes an

alternative approach using ANSI-41 parameters to identify the serving network.
http://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billinghttp://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billinghttp://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billinghttp://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billing


4/19

Page 4 of 19

2. Existing Signaling

Most CDMA operators today connect to their international roaming partners via a

Roaming Service Provider (RSP). The RSP can represent all remote network elements as

a single identity. This arrangement greatly simplifies the configuration requirements inthe operators network, however in the process the identity of the serving network can be

masked from the home operator for SMS.

2.1. Point Code Routing

Many operators today use Point Code (PC) routing for signaling to and from the RSP.

The PCs are meaningful only within a given network/country. The Roaming Service

Provider (RSP) is assigned a point code inside each of its customer networks, and usesleased lines to connect back to its own premises. All roaming signaling to and from an

operators roaming partners is via the single RSP point code. This arrangement is shown

in Figure 1 below.

Figure 1 - Existing RSP Signaling

The following subsections show specific scenarios relevant for SMS. In each case there

may be one or more Signaling Transfer Points (STPs) present between the RSP and the

indicated operator network element these STPs do not modify the traversing message inany way. The Signaling Connection Control Part (SCCP) layer of the messages is

assumed to have Called and Calling Party Addresses either containing PCs that match theDestination and Originating Point Codes (respectively) together with a SubsystemNumber (SSN), or SSN only. The SCCP routing indicator indicates that routing is based

on the MTP PC and the SSN.


5/19

Page 5 of 19

2.1.1. Subscriber Registration

Figure 2 below shows subscriber registration. No indication is available of the actual

serving network. The SMS_Address parameter points only to the RSP.

Figure 2 - Subscriber Registration

2.1.2. Mobile-Originated SMS

Figure 3 below shows a mobile-originated (MO) SMS. The transport layer identifiers

received at the MC only refer to the RSP, and not to the serving operator. The MAP layercontents likewise provide no information about the serving operator.

Figure 3 - Mobile-Originated SMS

2.1.3. Mobile-Terminated SMS

Figure 4 below shows a mobile terminated (MT) SMS. The MC sends the SMS to the

destination PC received from the HLR in the SMS_Address parameter (the same received

by the HLR at registration time). No identification of the serving operator is available atthe MC.


6/19

Page 6 of 19

Figure 4 - Mobile-Terminated SMS

2.1.4. SMS Notification

Figure 5 below shows a notification from the RSP to the MC (e.g. when a subscriber with

a pending message becomes available). The SMS_Address points to the RSP, and theresulting MT-SMS will be as above in Figure 4.

Figure 5 - SMS Notification from RSP

2.1.5. Other Roaming Signaling

Figure 6 below shows a general representation of other signaling between the RSP and

the operator. All traffic is received from/directed to the single RSP PC.

Figure 6 - Other Signaling


7/19

Page 7 of 19

2.2. Global Title Routing

Some operators use Global Title Translation (GTT) to route calls through their network,

and to and from the RSP. Although the use of GTT can allow the transfer of messages

between networks without knowledge of each others MTP PC allocations, as used today

for CDMA international roaming the RSP is still present as a PC that appears inside theoperators network: GTT is used as a tool to simplify routing tables in nodes of large

networks.

STPs/SCCP Relay points in the operators network route the message, changing the MTP

addresses accordingly.

The following subsections highlight differences between Point Code and Global Titlerouting.

2.2.1. General Roaming Signaling

Figure 7 below shows a generic ANSI-41 message pair (which could be SMS or otherroaming signaling). The MTP layer addresses are modified en route by intervening STPs

which also perform Global Title Translation. At the SCCP layer, the routing indicator

indicates routing is based on the global title address, and the called and calling partyaddresses contain Global Titles for the message endpoints. As perIS-807, the Global

Titles are in E.212 format. In some cases the Global Title will be the relevant mobiles

IMSI, in other cases an identifier assigned directly to a network element. The RSP maybe physically located in a different country to the operator, however as with the point

code routing arrangement it is assigned a local point code. For this reason the Global

Title for the RSP uses the same Mobile Country Code as the operator.

Figure 7- GTT signaling
http://www.3gpp2.org/Public_html/specs/N.S0016-0_v1.0.pdfhttp://www.3gpp2.org/Public_html/specs/N.S0016-0_v1.0.pdf


8/19

Page 8 of 19

2.2.2. Subscriber Registration and SMS Notification

Subscriber registration and SMS Notification use the same signaling techniques as

described in above. The MAP layer SMS_Address parameter contains the RSP GT

address instead of a point code, so that mobile-terminated SMS can be addressed using

GTT.


9/19

Page 9 of 19

3. Proposed Solution

As stated above, the approach preferred by operators is for the RSP to modify an address

parameter in a transport layer (MTP and/or SCCP) to identify the serving network. The

message will appear to the home operator to be coming from (or going to) a differentlocation for each serving operator, rather than just to the single RSP location as today.

Many MCs today include the far end transport layer information in their billing record. Ifthis information is set to a value that is specific to the serving operator, a home operator

can potentially implement a per-serve charging scheme with no modifications to their

MCs. This was the primary reason for the operator preference for this approach (see themeeting minutes for more detail).

The differences between the existing point code and GT routing schemes necessitatedifferent approaches to incorporate serving network information for operators who use

these schemes.

3.1. Point Code Routing

For operators using point code routing, the proposed approach is to replace the single

RSP point code with a PC that is specific to the serving operator. The set of roamingpartner PCs would be unique to each home operator (for example, SMS traffic for

Operator 1s subscribers roaming in Operator 2s network may appear to Operator 1 to

use point code A (a point code assigned to the RSP for this purpose by Operator 1), while

SMS traffic for Operator 3s subscribers roaming in Operator 2s network appears toOperator 3 to use point code B). This arrangement is illustrated in Figure 8 below.

Figure 8 - Serve-specific Point Codes for SMS

The following subsections show the changes to specific scenarios. Note that Point Codes

can be carried in both the MTP and SCCP layers, leading to some options regarding
http://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billinghttp://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billing


10/19

Page 10 of 19

where to place the serve-specific value. Except where noted, the SCCP point codes are

assumed to either be absent, or the same as their MTP counterparts.

3.1.1. Subscriber Registration

Figure 9 below shows the subscriber registering. The regular RSP PC is used at the MTP

layer, but inside the ANSI-41 message the SMS_Address parameter (which will be usedfor subsequent MT-SMS attempts) is set to the new point code used by the RSP for SMS

roaming between this serving operator and this home operator. Note that some HLRs may

store SMS_Address against the MSCID, rather than against the subscriber. In this caseanother RSP feature may be required to provide a per-serve MSCID in the message.

No modifications in the operators signaling network are required to support this solution.If differentiated billing for MT-SMS is not required, this modification is not necessary.

Figure 9 - Registration with serve-specific SMS_Address


For MO-SMS, the RSP may choose to either modify the MTP Originating Point Code(OPC), or the PC in the SCCP Calling Party Address (CgPA), leaving the OPC as the

(generic) RSP PC. SCCP modification may represent a simpler task for the RSPs. For thehome operator, there should be little difference between the two.

Figure 10 below shows a mobile-originated SMS with the modifications applied at theMTP layer. When sending the SMDPP to the home operators MC (indirect SMS routing

is assumed here), the RSP sets the MTP Originating Point Code (OPC) to the per-serve

value. The MC responds to the same point code. The SCCP Calling Party Address isassumed to contain the MC SSN, and the same serve-specific PC.

The home operator must configure its network elements to route the set of serve-specificpoint codes to the RSP. Modifications to STP Gateway Screening rules may also be

necessary to allow incoming traffic from the new OPCs. The RSP accepts the incoming

smdpp addressed to the new PC.


11/19

Page 11 of 19

Figure 10 - MO-SMS from serve-specific point code MTP modifications

As an alternative, the RSP could modify the SCCP CgPA PC, while leaving the OPC

untouched. This may represent a simpler development effort for the RSP than the MTPmodification discussed above. The resulting messaging is shown in Figure 11 below:

Figure 11 - MO-SMS from serve-specific point code - SCCP modification

The Return Result addressing is identical to the MTP modification case. Although it

would be convenient if the Return Result were to use the RSP (generic) PC at the MTPlayer (thereby avoiding the need for STP routing tables to include the serve-specific PCs),

this is unlikely to be the case for real-world MCs. The reason is that the internal primitiveused to pass the received message from the SCCP layer up to the application can only

carry a single point code. If, as here, both MTP and SCCP carry a (different) PC, only

that from SCCP will be preserved. When the application sends the return message, it willbe directed to the PC seen by the application. Both SCCP and MTP will use this PC for

their respective destination address parameters. This arrangement is shown in Figure 12

below:


12/19

Page 12 of 19

Figure 12 - Internal Primitives for MO-SMS

For the home operator, the SCCP modification approach may mean that no STP gatewayscreening changes are required (unless gateway screening / access mediation is used that

checks the SCCP CgPA). Although the use of different MTP and SCCP PCs may be

somewhat unusual, there should be no problem transporting these messages through theoperators network, as the SCCP layer is not examined by STPs.

The generation of a billing record is presumably a function of the application, rather thanthe signaling transport layers. The point code included in the billing record should

therefore be the one carried in SCCP, which will give the desired effect of identifying the

serving network.


Figure 13 below shows a MT-SMS. The serve-specific point code is received from theHLR in the SMSRequest Return Result message, and used as the Destination Point Code

(DPC) by the MC. Serve-specific billing for roaming MT-SMS, if desired, is achieved by

an assumed inclusion of the DPC in the MCs billing record. The RSP responds with the

serve-specific PC in the OPC/CgPA of the Return Result, in case the MC uses this valueto populate its billing record.

The alternative SCCP modification is shown in Figure 14.


13/19

Page 13 of 19

Figure 13 - MT-SMS to serve-specific point code, MTP modification

Figure 14 - MT-SMS to serve-specific point code, SCCP modification

3.1.4. SMS Notification

Figure 15 below shows an SMS Notification from the RSP. The key parameter is the

(MAP-layer) SMS_Address, which will be used as the DPC in the resulting MT-SMS.The normal RSP PC is used at the MTP layer of the SMSNOT message itself.

Figure 15 - SMS Notification with serve-specific SMS_Address


Other roaming traffic to/from the operator (including SMS traffic where the operator is

the serving operator) uses the standard RSP PC assigned for that operator (i.e. no change

to existing arrangement).


14/19

Page 14 of 19

3.1.6. Signaling Management

The RSP should manage the compete set of serve-specific PCs, and issue TFP/TFA

messages concerning these point codes as appropriate to the operators network elements.

3.2. Global Title TranslationFor operators using Global Title (GT) routing to signal to/from the RSP, a serve-specific

Global Title is used instead of a Point Code. The MC must include the SCCPCalled/Calling Party Address Global Title in its billing record to enable MT/MO serve-

specific billing, respectively.

The following subsections discuss changes for individual scenarios.

3.2.1. Subscriber Registration and SMS Notification

Both subscriber registration and SMS Notification require no changes to the transport

layer arrangements shown in Figure 7above. At the ANSI-41 layer, the SMS_Addressparameter is changed to contain a serve-specific Global Title.

While it may be possible to build this (E.212) GT using the serving operators true

Mobile Country Code (MCC) and Mobile Network Code (MNC), this may impacttranslation tables if current or future deployments use GT without the RSP. Instead, the

recommended approach is to assign a set of addresses from the home operators own

MCC-MNC range, which will be used to route the message to the RSPs local presence inthe operators network.


Figure 16 below shows a roamer-originated SMS sent from the RSP to the home

operators MC. At the MTP layer there is no change from the existing arrangements,

while at the SCCP layer the RSP has used a serve-specific E.212 address in the Calling

Party Address.

If the MC includes the received CgPA in its billing record, then the desired outcome ofserve-specific billing can be achieved.

For the return result, the MC uses the received CgPA to build the outgoing CdPA. GTtranslations must be in place for the new serve-specific values to route to the RSP.

Depending on the way the range of serve-specific addresses have been chosen, and the

internal data configuration in the STPs, this may entail little or no changes to the STPtranslation tables.

Any gateway screening or access mediation that checks the CgPA Global Title against a

whitelist must be updated to allow the new values.


15/19

Page 15 of 19

Figure 16 - MO-SMS with serve-specific Global Title


Figure 17 below shows roamer-terminated SMS signaling between the home operators

MC and the RSP. The MC uses the serve-specific Global Title previously received (inSMS_Address of smsreq or SMSNOT). As in 3.2.2, the operators GTT tables must

contain data to route the new address to the RSP. The RSP responds to the SMDPP using

the serve-specific GT, in case the MC uses this to populate its billing record.

Figure 17 - MT-SMS with serve-specific Global Title


There are no changes required to other roaming scenarios.


16/19

Page 16 of 19

3.2.5. One-way Global Title

Some operators may use Global Title routing only for the Invoke message, but not for the

Return Result. This can relive some routing configuration/point code discovery burden on

the invoking network element, and allows simple return routing when both source and

destination nodes are within the same point code universe.

Serve-specific information can be made available at the MC of an operator using one-

way GT routing via a combination of the methods discussed above. MO-SMS routing

will use the SCCP modification described in 3.1.2. Registration/Notification and MT-SMS will use the GT routing described in 3.2.1 and 3.2.3 respectively.

3.3. Discussion

The solution described above should meet operators needs for serve-specific billing forSMS roaming. Operators using PC routing and those using GT routing require different

solutions, both of which must be supported by the RSP.

Two options are shown for PC routing. The SCCP modification approach is preferred on

the assumption that this is easier for the RSPs to implement (and may also require fewer

Gateway Screening changes on the part of the home operator). The requirements on theMC billing record should be the same for either option.


17/19

Page 17 of 19

4. GlossaryCDG CDMA Development Group

CdPA Called Party Address

CgPA Calling Party Address

DPC Destination Point CodeGT Global Title

GTT Global Title Translation

HLR Home Location Register

IMSI International Mobile Station Identity

IRT International Roaming Team

MAP Mobile Application Part

MC Message Center (aka SMSC)

MCC Mobile Country Code

MNC Mobile Network Code

MO Mobile-OriginatedMSC Mobile Switching Center

MSCID Mobile Switching Center Identification

MT Mobile-Terminated

MTP Message Transfer Part

OPC Originating Point Code

PC Point Code

RSP Roaming Service Provider

SCCP Signaling Connection Control Part

SMDPP SMS Delivery Point to Point

SMS Short Message Service

SMS_OA SMS_OriginatingAddressSMSC Short Message Service Center (aka MC)

SMSNOT SMS Notification

SMSREQ SMS Request

SSN Sub-System Number

TFA Transfer Allowed

TFP Transfer Prohibited

VSWG Voice & SMS Working Group


18/19

Page 18 of 19

5. Appendix MAP Layer Identifier

At the June 2006 IRT meeting, VSWG participants decided on the transport layer

modification approach discussed in the main body of this document. However, for some

operators a MAP-layer modification may be better suited. See the meeting minutes fordiscussion of the relative merits of a MAP- and a transport-layer solution. An operator

desiring a MAP-based solution as described below would need to approach their RSP on

an individual basis.

In this approach, the RSP adds a parameter to the SMSDeliveryPointToPoint Invoke (for

MO-SMS) or Return Result (for MT-SMS) to indicate the serving system. Whilecleaner from a system impact point of view, this approach may require more

modification to the MC, depending on which ANSI-41 parameters are normally included

in the MC billing record.

There are a number of parameters that may conceivably be used to store the serving

system identifier. Ideally, the chosen parameter would have the following characteristics:

Defined in ANSI-41 for inclusion in the SMSDeliveryPointToPoint operation

(invoke and/or return Result as appropriate for MO/MT SMS billing)

Not populated/examined by existing implementations

Allow for sufficient values to cover all CDMA networks

Included in MC billing records

Intuitively relate somehow to the serving system

The parameters described below meet many but not all of these criteria.

For the Invoke, custom values of the SMS_OriginatingAddress (SMS_OA) are used toidentify the serving network. Information available at the time of writing indicates thatwhile some operators may populate this parameter, no-one is examining it when received

at the MC. Whether it is included on MC billing records is unknown. The exact format of

the identifier is largely unimportant, and is left for future specification if required. An

MSCID-like value or MCC-MNC would seem to be logical candidates.

For the Return Result, ANSI-41 Rev E (following IS-725) allows the presence of theMSCID parameter in the message. Although intended for OTASP usage, the MC could

be modified to include this value in the billing record (no further MC action on this

parameter is required). A single MSCID per serving operator would be defined and

advised by the RSP.

The serve-specific values chosen are assumed to be common for all home operators usingthis solution. This is in contrast to the transport-layer solution in the main body of the

document, in which a full set of per-serving roaming partner values is maintained by the

RSP for each participating home operator.
http://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billinghttp://210.54.118.1/wiki/20060621_VSWG_Miami_Face_to_Face_Minutes#SMS_Roaming_Billing


19/19

Page 19 of 19

Figure 18 and Figure 19below show the changes to the SMDPP/smdpp operation for

MO- and MT-SMS. PC routing is assumed in the diagram, but the MAP layer changes

apply equally to GT routing. All other operations are unchanged from the existingarrangement.

Figure 18 - MO-SMS with serve-specific MAP-layer identifier

Figure 19 - MT-SMS with serve-specific MAP-layer identifier

sms signaling for roaming billing

Documents