20060815181446!SMS Roaming White Paper

8/6/2019 20060815181446!SMS Roaming White Paper

1/38

SMS Roaming White Paper

Revision 0.4

January 27, 2006

1

2


2/38

SMS Roaming White Paper Figures

W

HIT

EPAPER

Engineering Services Group

Daniel [email protected]

Rev 0.4 January 27, 2006 ii

1

2


3/38

Revision History

Version Date Reason

0.1 2005-12-25 Initial version0.2 2006-01-11 Updated following internal review0.3 2006-01-13 Added transport layer ID for serving network, other minor updates0.4 2006-01-27 Restructure and update

QUALCOMM Incorporated5775 Morehouse DriveSan Diego, CA 92121-1714U.S.A.

SMS Roaming White Paper

Revision 0.4

January 27, 2006

Copyright 2006 QUALCOMM Incorporated.All rights reserved

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

2


4/38


Contents

SMS Roaming White Paper................................................................................................. i

..............................................................................................................................................i

Revision 0.4.......................................................................................................................... i

January 27, 2006.................................................................................................................................................i

............................................................................................................................................iii

Contents..............................................................................................................................iv

Figures.......................................................................................................................... .....vii

1. Introduction .....................................................................................................................8

1.1 Definitions ..................................................................................................................8

1.2 Audience ....................................................................................................................8

1.3 SMS Standards ........................................................................................................ .9

2. Operator Billing Requirements .................................................................................. ..10

2.1 Bill-and-Keep ...........................................................................................................10

2.1.1 Serving Operator .......................................................................................10

2.1.2 Home Operator ................................................................................. ........11

2.2 Intercarrier Settlement.............................................................................................11

2.2.1 Serving Operator .......................................................................................11

2.2.2 Home Operator ................................................................................. ........123. Operator Recommendations ........................................................................................13

3.1 Message Delivery .................................................................................................. ..13

3.2 Serving Operator Billing ......................................................................................... ..13

3.3 Home Operator Billing ........................................................................................ .....13

4. Existing Operator Networks .........................................................................................14

4.1 No MSC Records for SMS .................................................................................. .....14

4.2 MC CDRs Used for Billing .......................................................................................14

4.3 Transport Layer Address in MC CDR ......................................................................14

5. Network Interconnection Options ................................................................................15

5.1 Direct Connection .................................................................................................. ..15

5.2 Transport-Layer Roaming Service Provider .............................................................15

5.3 MAP Layer Roaming Serving Provider ................................................................. ...16

5.4 Billing Clearinghouse ...............................................................................................16

5.5 Multiple Option Scenarios ........................................................................................16

Rev 0.4 January 27, 2006 iv

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

2


5/38


5.6 Intercarrier Messaging Hubs ....................................................................................16

6. Solution Elements .........................................................................................................17

6.1 Serving Network CDR Generation ...........................................................................17

6.1.1 Message Center CDR Generation ....................................................... .....17

6.1.2 Network Probes ................................................................................... .....17

6.2 External Billing Information Sources ........................................................................18

6.2.1 Home Network ................................................................................... .......18

6.2.2 Roaming Service Provider ........................................................................18

6.3 Record Transfer .......................................................................................................19

6.4 Home Operator Billing ........................................................................................ .....20

6.4.1 Billing Using the MC CDR .........................................................................20

6.4.2 Billing Using a Transferred Record ...................................................... .....21

6.4.3 Billing Using Both MC CDR and Transferred Record ................................217. Signaling Issues ............................................................................................................22

7.1 Direct Versus Indirect Routing ............................................................................... ..22

7.2 Population of Serving Network Identifier ..................................................................22

7.2.1 MAP Layer Identifier ..................................................................................23

7.2.2 Transport Layer Identifier ..........................................................................23

7.2.3 Mobile Terminated SMS .......................................................................... ..24

7.3 Address Parameter Population ................................................................................24

7.4 Message Length .....................................................................................................26

7.5 Subscriber Provisioning ...........................................................................................26

7.5.1 Service Option List Population ............................................................... ...27

7.6 Numbering Formats .................................................................................................27

7.7 SMSNotification Support..........................................................................................27

7.8 Agreement Management.........................................................................................28

7.9 Roaming to SMS-Incapable Markets .......................................................................28

7.10 MDN-Based Message Centers ..............................................................................28

7.11 Subsystem Numbers ........................................................................................ .....29

7.12 Service Options .....................................................................................................29

8. Glossary .........................................................................................................................30

Appendix I - SMS Message Flows .....................................................................................31

Appendix I - SMS Message Flows .....................................................................................31

I.1 Successful MT SMS .............................................................................................. ..31

I.2 Postponed MT-SMS .............................................................................................. ..32

I.3 Successful MO-SMS Indirect Routing ...................................................................33

Rev 0.4 January 27, 2006 v

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


6/38


I.4 Successful MO-SMS Direct Routing .....................................................................34

I.5 Mobile-to-Mobile SMS ........................................................................................ .....34

Appendix II - Additional Message Routing Options ..................................... .............. .....35

Appendix II - Additional Message Routing Options ..................................... .............. .....35

II.1 Super-Indirect.........................................................................................................35

II.1.1 Billing Output............................................................................................36

II.1.2 Discussion and Issues........................................................................ .....36

II.2 Local Service ..........................................................................................................37

II.2.1 Discussion................................................................................................38

Rev 0.4 January 27, 2006 vi

1

1

2

3

4

5

6

7

8

9

2


7/38


Figures

Figure 1 - Successful MT-SMS...........................................................................................31

Figure 2 - Postponed MT-SMS............................................................................................32

Figure 3 - Indirect MO-SMS...................................................................................... ..........33

Figure 4 - Direct MO-SMS...................................................................................................34

Figure 5 - Super-Indirect Routing for MO-SMS.................................................................35

Figure 6 - Local Service Routing for MO-SMS..................................................................37

Rev 0.4 January 27, 2006 vii

1

1

2

3

4

5

6

7

8

2


8/38


9/38

SMS Roaming White Paper Glossary

1.3 SMS Standards

SMS is standardized for CDMA2000 in several published standards:

IS-2000: SMS messages between Mobiles and Base Stations are carried over theair inside IS-2000 DataBurst Messages.

ANSI-41: SMS messages between network elements are carried inside ANSI-41messages. The majority of roaming issues occur in the ANSI-41 domain, as thehome, serving (and Roaming Service Provider) networks communicate at this level.Revision D is in most common use, although Revision E is in the process ofpublication, and modifies several areas related to SMS.

TIA-637: This standard defines the content of the SMS message itself, including forexample additional fields such as Time Stamp or Call-Back Number. Many, but notall, of the TIA-637 parameters are carried transparently between IS-2000 and ANSI-41.

IS-841 : This standard modifies ANSI-41-D to accommodate the requirements of

Wireless Number Portability.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

2
http://www.3gpp2.org/Public_html/specs/C.S0005-0_v3.0.pdfhttp://www.3gpp2.org/Public_html/specs/N.S0005-0_v1.0.pdfhttp://www.3gpp2.org/Public_html/specs/CS0015-0.pdfhttp://www.3gpp2.org/Public_html/specs/N.S0024-0_v1.0.pdfhttp://www.3gpp2.org/Public_html/specs/C.S0005-0_v3.0.pdfhttp://www.3gpp2.org/Public_html/specs/N.S0005-0_v1.0.pdfhttp://www.3gpp2.org/Public_html/specs/CS0015-0.pdfhttp://www.3gpp2.org/Public_html/specs/N.S0024-0_v1.0.pdf


10/38


2. Operator Billing Requirements

The subsections below describe billing requirements for both the home and serving

networks. They are intended to be independent of any particular approach for networkinterconnection or billing record generation. Although each operator will have their ownpreferences, the information below should serve as a general guide.

Two main models for billing are discussed: Bill-and-Keep, where the home operator bills itsown subscribers without recompense to the serving operator; and Intercarrier Settlement,where the serving operator does receive a wholesale payment. Both arrangements cancoexist between the same home and serving operators, e.g. Intercarrier Settlement forMobile Originated (MO) SMS, Bill-and-keep for Mobile Terminated (MT). An operator couldalso use one method for one roaming partner and a different method with another partner.

Unless otherwise specified, the requirements below apply to both MO- and MT-SMS.

2.1 Bill-and-Keep

Bill-and-keep represents an extremely simple model for SMS roaming billing. Since theserving operator does not charge for the service, there is no direct need for billinginformation to be produced in the serving network (although it may be desirable for otherpurposes e.g. marketing, statistics). In addition, since there is no intercarrier component,there is less need for the home operator to be able to differentiate (as relating specifically toroaming) Call Detail Records (CDRs) produced in its network.

If the amount of roaming between two operators is largely symmetric, neither operator wouldlose net revenue as compared to the Intercarrier Settlement approach.

Also included in the Bill-and-keep definition are intercarrier payments not directly related toSMS activity (e.g. a flat monthly fee, or one based on the number of roamers regardless ofSMS usage). Such payments are a purely commercial arrangement with no directrelationship to actual delivery or billing mechanisms for SMS roaming.

The Bill-and-keep model has been successfully used by some serving operators forinternational MO-SMS roaming, particularly as an initial offering while alternative billingarrangements are being negotiated, and/or in conjunction with a flat fee. It is used by themajority of non-North American operators for international MT-SMS roaming. It is alsocommon among North American operators for domestic and quasi-international SMSroaming (both MO & MT).

2.1.1 Serving Operator

There are effectively no billing requirements on the serving network if bill-and keep is used.Billing information is not needed. If CDRs are produced (e.g. by the serving MSC) theyshould be identified as relating to roaming (assuming the MSC CDR is also in use for homenetwork SMS billing) and not processed further.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


11/38


2.1.2 Home Operator

The home operator is responsible for subscriber billing, and uses CDRs produced by thehome Message Center (MC) for this purpose. Since there is no additional intercarrier chargeto cover, rates could be exactly the same as for a subscriber at home, with no change to

existing billing systems. Alternatively, if the operator wished to charge a premium rate forroaming SMS, sufficient information (in the form of Originating/Destination Point Code orSCCP Calling/Called Party Address) should be available at the MC for inclusion into a CDRthat could be identified as relating to roaming.

If the home operator wishes to charge based on the subscribers serving network (or toinclude this information on the subscribers billing statement) then information that identifiesthe serving network is required at the MC. In some scenarios, this may not be available. See7.2 for a discussion on possible solutions when this is the case.

2.2 Intercarrier Settlement

In the Intercarrier Settlement model, the serving operator charges the home operator for theprovision of SMS services to inbound roamers. This approach is analogous to that currentlyused for voice roaming. The home operator continues to bill the subscriber, although maynow need to ensure that the retail charge includes a component to cover the wholesaleintercarrier portion that the home operator has been charged.

In this document, it is assumed that the intercarrier charges for this model relate directly tothe number of SMSs. Other charging regimes, e.g. flat monthly rate, are considered as partof the Bill-and-keep model, described above.

2.2.1 Serving Operator

The following bullet points are assumptions only. They may not hold for every operator, but

are intended to define as broad a set of requirements as possible: The operator may wish to charge for all SMS delivery messages transitingits network, or only for successful attempts. A successful attempt for MT is one thatis delivered to the mobile, while for MO the criterion is successful delivery to the MC(ultimate delivery to the message recipient is a separate task). In certain scenarios,the number of unsuccessful attempts may be large (e.g. for MT with an aggressiveretry schedule from the MC). Depending on the scenario, unsuccessful attemptsmay or may not consume radio resources.

The preferred source of information for billing that is used to requestpayment from the home operator will be from within the serving operators ownnetwork, rather than relying on outside information. (Comment)

The billing flow needs to be robust, automated and auditable. As a counterexample, a manual process to cut-and-paste weekly summaries from a web-based

report and build up a monthly invoice is likely to be error-prone, inefficient and notauditable at a later date.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

2


12/38


2.2.2 Home Operator

The following bullet points are assumptions only. They may not hold for every operator, butare intended to define as broad a set of requirements as possible:

The home operator may wish to charge its subscribers for SMS roaming. Asdifferent serving operators may charge different intercarrier rates, the home operatormay wish to be able to charge a subscriber based on where s/he was when themessage was sent/received.

Operators should retain the ability to provide an itemized list of SMSs on thesubscribers bill, rather than just a single total SMS charge.

It is preferable for all charges on a subscribers bill relating to a single SMSto come from a single source. This can prevent undesired end-of-billing-cycle eventswhere charges for the same message are split across two monthly statements, andcan also remove the need for record matching (except as an audit function).

1

1

2

3

4

5

6

7

8

9

10

11

12

13

2


13/38


3. Operator Recommendations

This section describes, from the operators perspective, high level recommendations for

SMS Roaming. The recommendations address three key aspects of SMS Roaming:successful message delivery; home operator (subscriber) billing; and serving operator(wholesale) billing, including the specific billing requirements described in the previoussection. In some cases more than one option is presented.

It is up to individual operators and their negotiations with roaming partners to decidebetween the bill-and-keep and intercarrier settlement approaches for billing. Therecommendations below relate to ways to implement intercarrier settlement, as therequirements for bill-and-keep present a far smaller challenge.

Later sections of this document discuss the recommendations in more detail, including howthey may differ from what is currently available, and what alternatives or modifications maybe pursued.

3.1 Message Delivery

For successful SMS delivery, indirect routing is recommended. For information on indirectrouting, and how it differs from direct routing, see the discussion in 7.1, and the call flows inI.

3.2 Serving Operator Billing

By analogy to voice, the recommended approach is for the serving MSC to produce CDRsfor MO- and MT-SMS. CIBER records generated from these CDRs can be used forintercarrier settlement.

Alternatively, settlement can be performed at a summary level, without the transfer to thehome operator of records detailing each individual SMS.

3.3 Home Operator Billing

The recommended approach for the home operator is to use the MC CDR for subscriberbilling. If required, this CDR must contain enough information to allow billing to bedifferentiated by subscriber location (see 2.2.2). The far end point code and/or SCCPCalled/Calling Party Address should be included in the CDR.

Alternatively, the home operator can use received CIBER records to perform subscriberbilling.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

2


14/38


4. Existing Operator Networks

This section briefly outlines some key aspects of existing operator networks with regards to

SMS. Taken together with the requirements and recommendations of the previous twosections, these characteristics can identify needs to be met by the solutions described inlater sections of this document.

4.1 No MSC Records for SMS

In the majority of CDMA networks today, the serving MSC does not produce a CDR for anSMS event, either MO or MT. This typically presents a problem when an operator wishes tointroduce an intercarrier settlement approach for SMS roaming.

At least one major network vendors MSCs do have the capability to produce SMS CDRs,but in most operator networks using these MSCs the option is either not purchased or notused.

4.2 MC CDRs Used for Billing

Almost all operators surveyed use their MC to generate CDRs for SMS, and use theserecords to determine subscriber billing.

4.3 Transport Layer Address in MC CDR

The originating (for MO-SMS) or destination (for MT-SMS) signaling transport layer address

is information available to the MC (although it may not always be a true value see 5.3).However, not all MCs include this information in the CDR. This can present a challengewhen a home operator wishes to distinguish roaming CDRs from those produced by itssubscribers while at home.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

2


15/38


5. Network Interconnection Options

A prerequisite for SMS roaming is that the home and serving networks can communicate.

Basic network connectivity, and the options for achieving it, is not unique to SMS roaming.However, various SMS-specific solutions (particularly relating to billing) are possibledepending on the choice of interconnection method. These methods are therefore describedbriefly below. Note that a detailed explanation of SS7 signaling is beyond the scope of thisdocument.

5.1 Direct Connection

Networks in the same country (or numbering space) can connect directly to each other. Thisoption does not allow for any special services relating to SMS. True transport layer identifierswill be passed between networks.

5.2 Transport-Layer Roaming Service Provider

Networks in the same country (or numbering space) may choose to connect via a huboperated by a Roaming Service Provider (RSP). If the RSP functional as an STP or SCCPRelay, i.e. only examines and routes messages based on the transport signaling layers(rather than the application (i.e. ANSI-41) layer), it is referred to in this document as atransport layer RSP.

Networks in different countries (that do not share a common numbering and addressingscheme) may also connect to a transport-layer RSP. This can be achieved by assigningpoint codes from one country (often the US) to network entities in another, or by usingbidirectional Global Title Translation (GTT). Care may be required when dealing withparameters like SMS_Address, which is typically a transport layer address embedded in theapplication layer.

A transport layer RSP may be able to report on SMS traffic that transits its hub. Withoutaccess to the application layer, identification of SMS signaling messages would be based onSubsystem Number (with some possible accuracy impacts see 6.2.2.1).

The true transport layer identifier (point code or Global Title Address) will typically be passedbetween networks.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

2


16/38


5.3 MAP Layer Roaming Serving Provider

A RSP that can analyze and potentially modify messages at the Mobile Application Part

(MAP) layer is referred to in this document as a MAP layer RSP. Since the message isprocessed by the RSP at the MAP layer, there is no end-to-end transport layer connection.Transport layer connectivity can be achieved by assigning the RSP a point code out of eachof the customer networks own allocation schemes. Thus the RSP appears to belong insideeach customer operators network.

Additional SMS-related services may be offered by a MAP layer RSP: The RSP may be ableto modify various ANSI-41 parameters to ensure interoperability, and also providebilling/reporting information.

The true transport layer identifier is not typically passed from one network to another.Instead, all messages sent between the RSP and the customer network appear to thenetwork to be coming from/going to a single entity (the RSP). While this characteristic is

often seen as a benefit (one network does not need to be aware of all the point codes usedin another), it can create challenges for the home operator if there is a need to identify thesubscribers true location in the MC CDR.

5.4 Billing Clearinghouse

Either a transport of a MAP layer RSP can also act as a billing clearinghouse. While thisdoes not directly relate to network interconnectivity at a signaling level, the link between thesignaling and billing services provided by the RSP can add value for SMS. For example, ifserving operator billing information is derived from the RSPs signaling function, the resultantcharge can be directly applied to the home and serving operators settlement position by theRSP in its capacity as a clearinghouse.

5.5 Multiple Option Scenarios

It is possible for two operators to connect using more than one of the above options inseries. For example, an operator customer of a transport layer RSP may wish to connectwith a customer of a MAP layer RSP, using an existing connection between the two RSPs.While this should present few problems from a pure connectivity perspective, it may impacton the value-added services available from the RSPs: accurate MAP layer parametermanipulations may not be possible without a customer-level relationship between bothoperators and the MAP layer RSP (e.g. to maintain network profile information about therequired mapping). Similarly the integration with the clearinghouse function is less likelywhen both networks are not customers of the same RSP.

5.6 Intercarrier Messaging Hubs

Various solutions are available which provide for intercarrier SMS using a hub arrangement.Connection to the hub is often from operators MCs using the Short Message Peer to Peer(SMPP) protocol. An SMPP service does notprovide a valid solution for SMS Roaming (witha possible exception in a theoretical, non-standard solution described inII.)

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

2


17/38


6. Solution Elements

The following subsections describe various ways in which the recommended approaches

described in 3 can be implemented, in light of the network characteristics andinterconnection options outlined in the preceding sections. Some of the methods describedhere are available and currently in use others are potential solutions that may or may notbe within the capabilities of currently deployed equipment.

6.1 Serving Network CDR Generation

In order to implement intercarrier settlement, some form of billing information should beavailable to the serving network (or its designate). To work around the fact that in mostcases the MSC does not produce CDRs, other sources may be available within the servingnetwork:

6.1.1 Message Center CDR Generation

The serving network MC does not normally handle SMS traffic for roamers. However, twonon-standard, theoretical options are described in II, where the MC is in the message flow.Production of a CDR should be a normal function for most MCs, however depending on theMSC behavior the CDR may lack some essential information (e.g. MSID), and the routingdecisions may be difficult for the MC.

6.1.2 Network Probes

Rather than introduce another logical node into the message flow (i.e. the MC), analternative is to use Indirect Routing for MO-SMS, and to passively sniff the links to theRSP or home carrier for traffic relating to MO and MT SMS. Information obtained in this

manner could be used to generate CDRs without further development on the MC or MSC.

Some carriers already send all roaming traffic through an ANSI-41 gateway, and this toocould be adapted to provide the necessary billing output.

In either case, the work is non-trivial to bill accurately for SMS, (especially if charging isonly based on successful messages) such a probe would need to keep track of the TCAPTransaction ID to correlate message invokes and responses, as well as analyze the MAPlayer to determine the type of message. In order to avoid the potential problem of MSIDavailability in the SMDPP (see II.1) the probe may need to retain subscriber profileinformation (e.g. MDN to MSID mapping) observed at registration time.

No known implementations of the network probe option exist at the time of writing.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

2


18/38


6.2 External Billing Information Sources

Rather than generate the necessary billing information within the serving network, it may be

possible to obtain it from other sources:

6.2.1 Home Network

In theory, the home network may be able to provide information to the serving network thatallows it to charge the home network. In practice, having the home operator nominate howmuch it must pay is unlikely to be considered an acceptable option from a commercialperspective.

6.2.2 Roaming Service Provider

Both a MAP and a transport layer RSP are in a position to observe the SMS traffic transitingtheir system and report on it. Such a report is generally assumed in this document to be

provided by the RSP to the serving operator, to allow the serving operator to charge thehome operator in any agreed fashion (see 6.3). However other arrangements are possibletoo, e.g. if the RSP is also a clearinghouse then (provided the RSP has access to theserving operators rates for SMS services) the SMS charge can be directly applied to theoperators net financial position.

6.2.2.1 Transport Layer RSP

A transport layer RSP will typically not be able to identify the individual subscriber for anSMS transaction, as this information is contained in the MAP layer. (A possible exception isMO-SMS, if the subscribers IMSI is used as the Global Title Address.) A report wouldtherefore be of a form such as on 9 January 2006, Operator As subscribersoriginated/received 1234 SMSs while roaming on Operator B

SMS transactions would be identifiable by Subsystem Number (SSN). Use of the SSN hasthe following characteristics:

SMSNotification counted as SMS. The SMSNotification (SMSNOT) message isindistinguishable at the transport layer from a SMSDeliveryPointToPoint (SMDPP)message which actually contains a subscribers SMS. SMSNOTs would be includedin the message count reported to the serving operator.

Unsuccessful messages counted. Without examining the MAP layer, it is notpossible to distinguish a successful SMS message from an unsuccessful one. Bothwill be included in the message count.

MO and MT both counted. At the transport layer, the response to an MT SMS isindistinguishable from an MO SMS., and vice versa. Thus both directions will beincluded in the message count.

There are no known implementations of transport layer RSP billing reporting at the time ofwriting.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


19/38


6.2.2.2 MAP Layer RSP

A MAP layer RSP has the opportunity to examine and report on SMS transactions in moredetail than a transport layer RSP. Access to the subscriber information in the MAP layer (e.gMSID, originating/destination address parameters) could allow the RSP to provide a report

which contains information on each individual SMS, e.g. on 9 January 2006 at 09:15:00,MSID xxxxxxxxxx originated an SMS to destination aaaaa; on 9 January 2006 at 09:16:00,MSID yyyyyyyyyy received an SMS from originator bbbbb; .

The summary-level report described in 6.2.2.1 could also be provided.

Regardless of the level of detail in the report (i.e. summary or individual), the RSP has thenecessary information available to it to distinguish SMSNOTs from SMDPPs, successfulSMDPPs from unsuccessful ones, and MO- from MT-SMS.

Summary-level reporting (integrated into the financial clearinghouse function) is availabletoday from at least one MAP layer RSP. No individual level reporting was available at thetime of writing.

6.3 Record Transfer

In order to perform intercarrier settlement, an agreed format for record transfer betweenoperators (or an equivalent approach, e.g. clearinghouse integration) is required. A singleindustry-wide solution is preferable to a proliferation of different bilateral approaches. Thesolution should be scalable, applicable to both summary and individual (i.e. per-SMS)records, and sufficiently robust to use for retail billing at the home operator (if used to passindividual records).

Serving operators may prefer to use a summary report for simplicity. For home operators,the situation is slightly more complicated: an individual report can be used for subscriber

billing, but may require changes to the usual (i.e. MC CDR-based) SMS billing flow.

A full specification of an intercarrier SMS billing format is beyond the scope of this document.

In the voice roaming arena, the CIBER billing record is in common use as the means bywhich roaming CDRs are exchanged among carriers. Appendix K of the CIBER specificationdescribes ways in which data services (including SMS) may be captured in CIBER format.Further discussion among the carrier community would be required to determine an agreedusage, particularly in the case of summary records. Existing fields in the CIBER formatshould provide sufficient scope to include enough information to use individual records forretail billing, as is done today for voice. At the time of writing, one serving operator isbelieved to be using CIBER records for SMS.

An alternative approach is to design a new record format specifically for SMS. The primarydriver for this may be cost SMS transactions are likely to be low value when compared torecords for voice calls, and any step in the billing chain which today involved a per-recordcharge would need to be carefully examined.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

2


20/38


6.4 Home Operator Billing

The home operator is responsible for subscriber billing. The information to perform thisbilling can come from a record produced in the operators own network (i.e. at the MC),outside the network (e.g. a transferred record from the serving network or RSP), or acombination of both.

In this document, to allow for the maximum flexibility in billing, it is assumed that the homeoperator wishes to be able to identify the roaming subscribers serving network. Severaloperators have indicated that this is the case, however individual roaming agreements andoperator preference may relax this requirement in some instances. A weaker requirementthat may hold for some operators is that roaming SMS be distinguishable from non-roamingSMS from a billing perspective.

6.4.1 Billing Using the MC CDR

Non-roaming SMS usually uses the MC CDR for billing. Using this record for roaming SMSmay represent a minimum impact on existing billing systems and processes.

For both roaming and non-roaming cases, the MC CDR is assumed to contain informationsuch as subscriber MSID/MDN and originating (for MT-SMS) or destination (for MO-SMS)address which is necessary for correct rating and billing.

The remainder of this section describes the requirements for identifying the serving network.

6.4.1.1 No Transport Layer Address in CDR

If the MC CDR does not contain a point code (or Global Title Address) for the far endnetwork element, identification of the serving network may not be possible. Inclusion of thisinformation is recommended as a minimum requirement for home operators interested indifferentiating roaming SMS MC CDRs.

An alternative approach using MAP layer parameters is described in 7.2. If not alreadyincluded, the work required to add these one of these parameters to the CDR may exceedthat required to add the point code.

6.4.1.2 True Transport Layer Address Available

For operators using direct connections or a transport layer RSP, the true transport layeraddress will be available to the MC. For MO-SMS, it will be received by the MC as theOriginating Point Code or Calling Party Address in the incoming SMDPP. For MT-SMS, it isused by the MC as the Destination Point Code or Called Party Address in the outgoingSMDPP. The MC obtains these values from the HLR in the SMS_Address parametercontained in the SMSRequest Return Result.

Assuming the transport layer address is included in the CDR, the home operator can use itto determine the subscribers serving network. However, this may require the population of alarge number of identifiers in the home operators billing system, and represent a largemaintenance effort. To identify only that the CDR relates to roaming SMS, the point code orglobal title address needs to be recognized as not belonging to the home operator this maybe an easier task to provision and maintain the data for.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

2


21/38


Further investigation is required regarding the validity of hierarchical address allocation, andwhether this could reduce the billing system provisioning load.

6.4.1.3 True Transport Layer Address not Available

When connecting via a MAP layer RSP, the true transport layer address is not used. Instead,the MC in the home operators network sees only the RSPs address. If the MC CDRcontains the observed transport layer address, then the CDR can be identified as relating toroaming, but the identity of the true serving operator cannot be ascertained.

Section 7.2 discusses some potential modifications to the ANSI-41 and transport layers ofvarious messages to ensure that the serving operator can be identified at the MC.

6.4.2 Billing Using a Transferred Record

If the home operator receives individual SMS records from the serving operator (or from theRSP), these records can be used for subscriber billing. Note that it is theoretically possiblefor intercarrier settlement to be performed at a summary level, but for a detailed per-SMS

record to be generated and provided by a MAP layer RSP directly to the home operator forsubscriber billing.

The transferred record must contain information about the message origin (for MT-SMS) ordestination (for MO-SMS) to enable correct billing. In the case of CIBER, a possiblemechanism is to use the Caller ID and Called Number Digits fields, respectively from theCIBER22 record.

For subscriber billing, the record may need to be re-rated rather than simply applying a fixedmarkup (e.g. in the case of a SMS to/from a premium service such as Idol voting or a stockprice alert)

Also, the MC CDRs must be identifiable as relating to roaming so they can be discarded.The destination point code (either RSP or RP) should be sufficient for this. If the transferredrecord only approach is being used by the home operator with only some of its roamingpartners, the MC CDR will need to identify the serving operator so that MC CDRs forroaming in the operators networks that dont transfer records to the home can be used forbilling.

A number of serving operators have indicated that they do not intend to provide detailedrecords. Coupled with the fact that this service is not currently available from a MAP layerRSP, this approach may present some challenges (at least in the short term) for a homeoperator.

6.4.3 Billing Using Both MC CDR and Transferred Record

To use both records, the home operator may wish to combine them into a single charge onthe subscribers statement. Matching against time and originator may be difficult if there aremultiple messages delivered within a short time. Another alternative is to use the IS-637Message Identifier, although for certain types of messages (e.g. WAP Push), this is notunique, and no standard method exists for its inclusion in a CIBER record.

If both records are used, the MC record can be used for any value-added charges relating tothe originator/destination, meaning that this address need not be included in the transferredrecord.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

1415

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

2


22/38


7. Signaling Issues

The following subsections list various interworking issues that may arise when roaming

partners attempt to implement SMS roaming.

7.1 Direct Versus Indirect Routing

Both direct and indirect routing for SMS are defined in ANSI-41. In 3.1 of this document,indirect routing is recommended. This section seeks to justify that recommendation. Forexamples of direct and indirect routing, see Appendix I.

Direct routing appears to be a more efficient routing arrangement, involving fewer signalinghops. However, there are a number of potential drawbacks:

An initial concern with a direct routing arrangement would be that, depending on themessage destination, the Home MC may be bypassed, thereby exacerbating the lack ofavailable billing information. This approach can be seen as similar to that for a roamer-originated voice call the home network is entirely reliant on the serving network to providebilling information. For the SMS case, if the serving network (or MAP layer RSP) couldproduce sufficient billing information and pass it to the home network (e.g. in the form ofCIBER records), direct routing could represent a valid approach from a billing perspective.As noted in 6.4.2, such an information stream may not be relied upon for most operators intodays environment.

Another issue with Direct Routing relates to the requirement on the MSC to analyze thedestination address received from the mobile. Different operators may have different SMSaddressing plans, and SMS interconnection agreements with a unique subset of othernetworks. Short Codes (e.g. for SMS information pull services or voting) are not assigned

on a global basis, and may conflict between carriers. Analysis of an inbound roamersdestination address appears to be an unreasonable requirement on a serving MSC,compared with the Indirect approach of sending all originations to the Home MC.

Note that it is possible for an operator to use Direct Routing for their own subscribers (wherethe addressing plan is clearly understood), and Indirect Routing for inbound roamers. Thisapproach is in use in at least one CDMA operator today. For the purposes of roaming, anarrangement affecting subscribers at home is transparent, and the network would be viewedas providing Indirect Routing.

7.2 Population of Serving Network Identifier

To enable per-serving operator subscriber charging for MO-SMS, the home network mustreceive information that identifies (at a minimum) the serving operator. If per-messageintercarrier settlement records are not used, the source for this information must be thehome MC CDR. The source of the MCs information is the received SMDPP. See 7.2.3 fordiscussion on per-serving operator charging for MT-SMS.

If a direct signaling connection or a transport layer RSP is used, information about theoriginating MSC will be present in the transport layer of the SMDPP Invoke, to enable routingof the Return Result. However, when a MAP layer RSP is present in the signaling path the

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

2


23/38


SMDPP today may contain no information about the true serving network. Somemodification is needed by the RSP to reinsert an identifier for the serving network.

Two general options are discussed below, based on the location in the message of theidentifier: MAP layer, and transport layer.

7.2.1 MAP Layer Identifier

In the MAP layer, the logical parameter to use would be the MSCID, or perhaps SenderIN.Unfortunately, these are not allowed parameters in the SMDPP operation. An alternativeapproach therefore involves use of one of two other parameters: SMS_OriginatingAddress(SMS_OA) or SMS_OriginalOriginatingSubaddress (SMS_OOSA). Note that the intention isto provide information to the MC for the sole purpose of including it in the CDR it does notneed to be acted on in any other way. Therefore, the exact format of the serving networkidentifier is largely irrelevant, provided the home operators billing system can recognize itand charge accordingly. A suggested value would be Mobile Country Code + MobileNetwork Code.

Advantages and disadvantages of the two parameters are discussed below:

SMS_OriginatingAddress:

If populated, this would typically (on the RSP-> MC leg) take the value of the RSPPoint Code/Global Title Address.

In ANSI-41-D, SMS_OA is copied to the original originating address by the MC ifSMS_OriginalOriginatingAddress (SMS_OOA) is not received (reference), althoughSMS_OOA should normally be present.

In ANSI-41-E, SMS_OA is clearly overwritten at the MC (reference), however thismay not always happen, especially under Rev D.

SMS_OriginalOriginatingSubaddress:

When the Type of Subaddress = User Specified, the formatting of the rest of thisparameter is open.

This parameter is unlikely to be used for any routing decision, however it is likely tobe transferred to the ultimate message recipient, with unpredictable results.

This may also lead to privacy concerns, with information about the senders locationbeing provided to the recipient without the senders consent.

The ability of currently deployed MCs to include either of these parameters in the CDR isunknown.

7.2.2 Transport Layer Identifier

If the RSP passes through the true Point Code (PC) of the serving MSC, the home MC will

have the opportunity to include this information in the CDR, thus identifying the servingnetwork. However, this negates some of the key advantages of having a MAP layer RSP inthe first place, namely screening different (and possibly conflicting) national point codeassignments from each other, and simplifying the network provisioning required by eachoperator.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

2


24/38


An alternative is for the RSP to populate a single (originating) PC per operator in MO-SMSSMDPPs. Inclusion of this operator-level PC in the MC CDR will allow for identification ofthe true serving network, and is believed to be a relatively common capability of the MCCDR. Each operator would assign a PC from their own national allocation plan to each of

their roaming partners, to be used by the RSP. Thus the PC used to identify a particularserving network would depend on the home network to which the message was addressed.

Home operators would provision their MCs and STPs to route all of these virtual point codesto the RSP, to ensure correct Return Result routing.

This approach could also be used with an operator-level Global Title Address (GTA) forthose (home) networks which use Global Title Translation. It is suggested for STPconfiguration simplicity that the virtual GTA used be one that naturally resolves to a PC inthe home operators network (e.g. home network MCC/MNC), rather than using an addressthat belongs directly to the serving operator.

7.2.3 Mobile Terminated SMS

For MT-SMS, the MC originates the SMDPP. A serving network identifier must therefore bederived from information available to the MC prior to the transmission of the SMDPP.

If the operator level PC/GTA described above is also used by the RSP to populate the (MAPlayer) SMS_Address parameter sent to the HLR at registration time, then this value will bereturned to the MC in the SMSRequest Return Result and used to address the subsequentSMDPP. This value could then be included in the MT CDR and used to identify the servingmarket. In some HLR implementations, an operator-level MSCID may also be required, asthe HLR may not handle multiple SMS_Addresses for a single MSCID

The MAP layer identifier approaches described in 7.2.1 are not applicable to MT-SMS.

7.3 Address Parameter Population

Interworking problems can arise due to the way different networks populate the variousaddress parameters available in the SMDPP operation. These parameters are:

SMS_OriginalOriginatingAddress (SMS_OOA)

SMS_OriginatingAddress (SMS_OA)

SMS_OriginalDestinationAddress (SMS_ODA)

SMS_DestinationAddress (SMS_DA)

(Two Subaddress parameters are also available, however these are not usually used, andare not discussed in this document, except to note the possibility of an RSP using the

SMS_OriginalOriginatingSubaddress to identify the true serving network - see above)

Different networks may or may not populate certain parameters, and may or may not makeuse of them on receipt. Also, the addresses may take the form of either MSID or MDN.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


25/38


As an example, a serving network may populate the SMS_OOA parameter with theoriginating subscribers MDN (for a MO SMS originated by a roamer). The home network MC(assuming Indirect Routing is used) may expect to receive the MIN in this field, and themessage may fail. Alternatively, a MC may populate the SMS_OA with the senders address

for a MT, but the serving MSC may require SMS_OOA to be present.

The current approach for resolution entails modifying the SMDPP according to previouslyprovisioned information about the requirements of the receiving node. This can be performedby a MAP layer RSP if used; otherwise this manipulation functionality must be implementedin at least one of the operator networks. (MSIDMDN mapping if needed can be cached atregistration.)

Below are recommended values for address population, based primarily on ANSI-41-E andIS-637-C. Note that there have been several changes between ANSI-41 Revisions D and E,and that some of the sections of ANSI-41 from which these recommendations are derivedare informative only. MSID population is also recommended, although in currentimplementations is not always the case, especially for MO-SMS.

MT SMS - SMDPP from MC to MSC:

SMS_OOA: Unchanged from incoming SMDPP or otherwise provided by originatingSME

SMS_OA: Not populated (comments)

SMS_ODA: Entered digits from message originator

SMS_DA: Not populated (comments)

MSID: Destination MSs MSID (comments)

MO SMS SMDPP from MSC to MC (Indirect Routing):

SMS_OOA: Originating MS MDN (comments)

SMS_OA: Not populated (comments)

SMS_ODA: User entered digits, provided by the MS over the air SMS_DA: Originating MS MDN (comments)

MSID: Originating MSs MSID (comments)

Note that population of SMS_OA for MO with a serving network identifier is discussed as anoption in the previous section.

The key parameters are the SMS_OOA and SMS_ODA, which should be carried unchangedend-to-end in ANSI-41. In ANSI-41 Rev E, messages are rejected if these parameters arenot present. (reference)

A fully-qualified E.164 MDN is recommended for MO addressing, particularly in the casewhere the MSID is not included, and the message is routed via a RSP. This will avoid

MDN/routing clashes among all roamers served by the RSP.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


26/38


7.4 Message Length

Problems can arise when a MS or network node attempts to send a message that is longer

than the receiving entity or intervening medium can support. Determining the maximumallowed length can be difficult there are hard limits at the signaling layer (MTP/SCCP), aswell as in the air interface and SMS Transport and Teleservice layers. MSs, MSCs, RSPsand MCs may impose different (lower) limits. At the SMS Teleservice layer, the presence ofoptional subparameters (e.g. Call-Back Number, Reply Option) may mean the end user mayexperience a lower limit than is strictly necessary.

The behavior of entities when receiving (or instructed to send) overlength messages shouldbe known when entering long message testing. Possible behaviors include messagetruncation, or rejection. Cause Code 106 is used to indicate that the User Data portion of themessage is too large. There is no known mechanism to provide feedback to the messageoriginator informing them that the message has been truncated. Due to the possibility ofinforming the message originator, message rejection is recommended as the preferred

option for overlength messages.

MTP/SCCP length limitations can be overcome if all entities in the path support messageSegmentation and Reassembly (SAR). However, since SAR is not applicable to the airinterface, the gain in usable message length is likely to be small. A better approach is for themessage to be segmented at the application layer (e.g. for a ringtone download etc). ANSI-41-D does not provide a means for the MC to determine if the serving MSC can accept SS7SAR this is covered by N.S0020 (and incorporated into ANSI-41-E), in which the MSCsTRANSCAP parameter may be included in the smsreq or SMSNOT.

7.5 Subscriber Provisioning

ANSI-41 provides several options for provisioning subscribers ability to send and receivemessages. The key parameters in the subscriber profile are SMS_TerminationRestrictionsand SMS_OriginationRestrictions.

SMS_TerminationRestrictions:

In many cases, the only values supported by HLRs and MSCs are 0 (Block all), and 3 (Allowall). Home networks should be wary of relying on serving network support of the Allowspecific and Reverse Charge values. Delivery attempts to subscribers with Block allshould fail at the SMSREQ point, and an SMDPP would not be seen.

SMS_OriginationRestrictions:

Similarly, the most common values here are 0 (Block all), and 3 (Allow all). If supported bythe serving operator, use of the Force Message Center (FMC) bit can allow a home operatorto require Indirect Routing for its subscribers, even if the default policy in the serving MSC isto use Direct Routing. Support for the FMC bit is recommended in HLRs, and in MSCs thatotherwise use Direct Routing.

The use of the DIRECT bit (block/allow direct routing) can be somewhat misleading, and infact this has been removed from ANSI-41E. The bit should be set to zero.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

2


27/38


7.5.1 Service Option List Population

Some operators include the SMS Service Options (6 & 14) in the ANSI-41CDMAServiceOptionList parameter sent as part of the subscriber profile (e.g. in the regnot).While this practice is not known to cause any problems, in most cases it is redundant

MSCs will typically use the SMS_OriginationRestrictions and SMS_TerminationRestrictionsparameters to determine SMS service qualification, without regard to the Service Option List.

7.6 Numbering Formats

The Indirect routing method leads to the destination address being parsed in the homenetwork. As has been discussed above, this is generally a good thing. However, it can leadto subscriber confusion as the required format will likely be different to that used for voice(where the dialed digits are parsed by the serving MSC). The long-term resolution for thisissue is Plus-Code Dialing (allowing a uniform format in all countries). In the short term,operators are encouraged to educate their subscribers (e.g. via Welcome SMS) to use thehome format, as well as optionally including foreign dialing patterns in their MC analysis

tables as a backup.

The following example highlights the problem:

TNZ subscriber roaming in Australia communicates with TNZ mobile (+64) 27 1234567:

To make a voice call, dial 0011 64 27 1234567 (Australian IAC is 0011)

To send SMS, address to 027 1234567 (NZ domestic format)

Mitigation involves loading 0011 64 0 mapping in TNZ MC. Althoughthe official position is that subscribers should use the NZ domestic format, theroaming voice format will work as well.

The addition of foreign dialing patterns is purely a workaround, and may well clash with thedialing plan in the home country.

7.7 SMSNotification Support

Not all networks currently support returning SMSNOT, even when theSMS_NotificationIndicator parameter is omitted or set to Notify when Available.

For successful MT roaming to these networks, a polled approach, i.e.timer-based retry schedule from the MC, is recommended.

It is recommended that the home MC normally requests notification (e.g. byomitting SMS_NotificationIndicator), except in certain circumstances e.g. time-criticalSMSs.

Any network that does not support sending SMSNOT should not send

SMS_CauseCode 36 (SMS delivery postponed) in the smdpp.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

2


28/38


7.8 Agreement Management

Typically, little office data provisioning is required to enable SMS in the serving network.

Particularly when a MAP layer RSP is involved, there may be no means for a servingoperator to allow/deny SMS on a per-roaming partner basis. In this case, the RSP mayensure that SMS traffic is only allowed for a particular {Home, Serving} operator pair whenboth parties have advised the RSP that an agreement is in place.

7.9 Roaming to SMS-Incapable Markets

ANSI-41 contains various provisions to handle scenarios where a MS moves betweenserving markets with differing ability to support (MT) SMS.

When roaming is implemented via a MAP layer RSP which represents all roamingdestinations as a single location to the home network, these scenarios become more

complicated. ANSI-41 uses the presence of the SMS_Address parameter (e.g. in theREGNOT) as an indication that the serving MSC supports SMS. Operators shouldinvestigate the behavior of their HLR when receiving REGNOTs from the same MSCIDwhere the SMS_Address is inconsistently present. In a worst-case scenario, a MSregistering in a market that is not SMS-capable may inadvertently suspend SMS delivery toall roaming MSs in all markets served by the RSP!

Two RSP scenarios in particular should be carefully examined by the home operator withrespect to their particular network behavior:

A MT SMS is sent to a MS roaming in a network that does not support SMS, then roams to anetwork that does support SMS. From which network element will the MC receive thenecessary SMSNOT? (Comments)

A MT SMS delivery is unsuccessfully attempted to a MS roaming in a SMS-capable market.The MS subsequently moves to a market that is non SMS-capable. (Comments)

7.10 MDN-Based Message Centers

SMS as standardized in ANSI-41-D does not fully address the requirements of WirelessNumber Portability (WNP). When the MC queries the HLR for the location of the destinationMS (SMSREQ operation), the MIN is used as the identifier of the mobile. In a WNP scenario,the MC may only have knowledge of the MDN. IS-841 modifies certain SMS operations toallow use of the MDN instead of the MIN.

In a roaming situation, the home and serving networks may have differing levels of IS-841support. In particular, a non-IS-841-compatible serving MSC may send a SMSNOT to theMC using MIN (only), but the IS-841 MC may in theory require the MDN as the primary keyto identify the MS for whom a short message is pending. ANSI-41-E clarifies the requirementfor the MC to use the MSID (and ESN) to identify the MS, and not the MDN. The behavior ofreal-world MCs in this respect is unknown.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


29/38


7.11 Subsystem Numbers

In IS-41-A, SSN 5 was used for all MAP traffic. In later revisions, distinct SSNs were definedfor the various applications e.g. HLR, VLR etc. ANSI-41-D assigns SSN 11 for SMS in bothANSI and ITU SCCP, however the ITU value has been changed to TBD in IS-807 andANSI-41-E.

Roaming partners may need to confirm their SSN usage, and potentially ensure that theirapplications can accept traffic routed to the wrong SSN, or that the SSN can be modifieden route (e.g. by the RSP).

7.12 Service Options

As mentioned in 7.5.1, there are two Service Options allowed for SMS SO6, using RateSet 1, and SO14, using Rate Set 2. Most operators use SO6 for SMS, and to date no issueshave been reported arising from a service option mismatch.

1

1

2

3

4

5

6

7

8

9

10

11

12

2


30/38


8. Glossary

CDR Call Detail Record. Used somewhat loosely in this document to refer to billing

records produced for SMS, even when no actual call took place.

CIBER Cellular Intercarrier Billing Exchange Roamer. Billing format in common use forintercarrier settlement of voice roaming.

GTA Global Title Address

GTT Global Title Translation

HLR Home Location Register

MAP Mobile Application Part

MC Message Center. An entity that stores and forwards short messages. Also referredto as Short Message Service Center (SMSC)

MO-SMS Mobile-Originated SMS

MSC Mobile Switching Center

MSID Mobile Station Identifier. May be either MIN or IMSI.

MT-SMS Mobile-Terminated SMS

MTP Message Transfer Part. Lowest layer of SS7 signaling stack. Together with SCCP,generically referred to as transport layer in this document

RP Roaming Partner

RSP Roaming Service Provider. An intermediate entity providing interconnection (andpossibly other services) between the home and serving operators.

SCCP Signaling Connection Control Part. Part of SS7 signaling stack. Together with MTP,generically referred to as transport layer in this document.

SMDPPSMSDeliveryPointToPoint. ANSI-41 message that actually carries the subscribersSMS text.

SMS Short Message Service.

SMSC See MC

SMSNOT SMSNotification. ANSI-41 message that reports a change in a mobiles abilityto receive SMS.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

2


31/38

SMS Roaming White Paper Appendices

Appendix I - SMS Message Flows

The following message flows show some of the most common SMS scenarios. The

diagrams do not assume any particular network interconnection method rather, they focuspurely on the MAP layer messaging. For more comprehensive and detailed scenarios, seeANSI-41.3-D 7.

I.1 Successful MT SMS

The message flow for a successful MT-SMS is shown below in Figure 1:

Home

HLR

Home

MC

Serving

MSC

a

bSMSREQ

smsreq

SMDPP

smdpp

c

d

e

Figure 1 - Successful MT-SMS

a) A message is submitted to the Message Center (MC) for delivery to a mobile.The detailed mechanism for submission, e.g. from another mobile, or fromanother network, is outside the scope of this document.

b) The MC queries the HLR to determine the current location of the mobile

c) The HLR responds with an SMS_Address parameter, indicating the location ofthe destination mobile.d) The MC sends the message to the Serving MSC, using the ANSI-41

SMSDeliveryPointToPoint (SMDPP) operation.e) The message is delivered over the air, and acknowledged.f) The MSC returns a successful result to the MC

1

1

2

3

4

5

6

7

8

9

10

11

12

13

1415

16

17

18

19

2


32/38


I.2 Postponed MT-SMS

There are various notification scenarios supported in ANSI-41. The one shown below in

Figure 2 shows an SMSNotification message sent from the serving MSC. Other scenariosare possible where this message is sent from the HLR (see following text).

Home

HLR

Home

MCServing

MSC

a

bSMSREQ

smsreq

SMDPP

smd pp[SMS_Cau seC od e]

c

d

e

f

SMSNOT

SMDPPi

j

k

smsnot

g

h

Figure 2 - Postponed MT-SMS

a-d) As per previous examplee) The mobile is inaccessible (e.g. coverage hole), and the message is not

deliveredf) A return result with a postponed indication is returned to the MC, and the MSC

sets a Delivery Pending Flag (DPF) for the mobile.g) Some time later, the serving network becomes aware that the mobile is available

for SMS (e.g. mobile makes a timer-based registration)h) Due to the DPF, the MSC sends an SMSNotification to the RSP.i) The message is acknowledged

j-l) The MC can now successfully deliver the message as per the previousscenario steps d-f

ANSI-41 shows the SMSNOT message as originating from either the MSC or the HLR.Which node will send it depends on where the SMS Delivery Pending Flag (SMSDPF) isheld: if the mobile is known by the HLR to be unavailable for SMS delivery (e.g. inactive, orroaming in a non SMS-capable MSC) then the HLR will respond to the SMSREQ with apostponed indication and set the SMSDPF. When the HLR learns that the mobile is again

available (e.g. on registration in a SMS-capable MSC), it will send SMSNOT to the MC.

In the above example, the HLR believed that the mobile was available, thus the deliveryattempt proceeded as far as the SMDPP to the serving MSC before encountering problems

in this case the SMSDPF resides at the MSC, and the MSC is responsible for sending theSMSNOT.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

2


33/38


The two cases are (very) roughly analogous to Call Forward No Answer: Inactive vs CallForward No Answer: Ring No Reply in a voice scenario, although no actual SMS forwardingtakes place.

I.3 Successful MO-SMS Indirect Routing

Indirect routing is the most common way in which MO-SMS is implemented. See 7.1 for adiscussion about the advantages and disadvantages of Direct versus Indirect routing. Themessage flow is shown in Figure 3:

HomeHLR

HomeMC

ServingMSC

SMDPPa

b

csmdpp

d

Figure 3 - Indirect MO-SMS

a) The mobile originates an SMS.b) Using indirect routing, the MSC sends the message to the Home MC of the

originating mobile.c) The MC acknowledges a successful submissiond) The MSC sends an acknowledgement to the mobile.

Note that the MC delivery of the message to its ultimate destination is a separate task,independent of roaming SMS.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

2


34/38


I.4 Successful MO-SMS Direct Routing

Direct routing is an alternative routing method that is also defined in ANSI-41. With direct

routing, the message is sent directly from the serving MSC of the originator to the MC ofthe destination party, bypassing the originators MC. The message flow is shown in Figure 4:

Serving

Nwk MC

Home

MC

Serving

MSC

SMDPPa

b

Roaming MSDomestic M

Serving N

smdppc

dSMDPP

e

f

Figure 4 - Direct MO-SMS

a) The roaming subscriber originates a SMS, intended for a domesticsubscriber in the visited network.

b) Since the routing method used is direct, the MSC analyzes the destinationaddress received from the air interface and uses it to determine the MCaddress. In this case, the destination is a subscriber of the serving network,so the MSC sends SMDPP to the serving network MC.

c) The MC returns smdpp.d) An air interface acknowledgement is provided to the originating MS.e) The MC (assumed here to already have a current SMS routing address for

the destination MS), sends SMDPP to the MSC serving the destinationmobile.

f) The MSC delivers the message to the mobile, and the message isacknowledged.

g) An smdpp is returned to the MC.

I.5 Mobile-to-Mobile SMS

Mobile-to-mobile SMS can be viewed simply as a combination of MO and MT messages. Ifthe two Mobile Stations (MSs) are not served by the same MC, there will also be a MC-to-MC relay leg. This leg is unaffected by whether the originating and/or terminating MSs areroaming.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

2


35/38


Appendix II - Additional Message RoutingOptions

II.1 Super-Indirect

The Super-Indirect message flow is a non-standard approach introduced in this documentspecifically to produce billing records in the serving network for MO-SMS. It routes allroamer-originated SMSs first to the MC in the serving network, and then to the Home MC.No real-world implementations of this method are currently known to exist it is shown as apossible solution to the billing requirements of the serving network, subject to the limitationsdiscussed below. The impacts of this approach (as compared to a standard Indirect routingmethod) should be almost entirely restricted to the serving network. As this approach existsonly on paper today, full systems engineering would be required before proceeding withimplementation.

The message flow is shown in Figure 5:

Serving

nwk MC

Home

MC

Serving

MSC

SMDPPa

b

SMDPP

smdpp

smdpp

c

d

e

Figure 5 - Super-Indirect Routing for MO-SMS

a) The mobile originates an SMSb) The serving MSC sends the SMS in an SMDPP to the serving network MC.

The MSC considers neither originating nor destination address, merelyroutes all MO SMSs to its own MC

d) The MC returns an smdpp acknowledging successful message submission,and an acknowledgement is made back to the mobile. By sending anacknowledgement at this point (and not after step f), the serving network MCis accepting the responsibility of ensuring reliable delivery to the homenetwork MC. This approach is chosen to more closely match the behavior ofcurrently deployed MCs, however it means that any information from thehome MC (e.g. message rejected due to insufficient prepaid balance) couldnot be relayed to the originating mobile.

e) The serving network MC determines that the originating mobile is not fromits own network, and therefore ignores the destination address, and routesbased on originating address to the Home MC.

f) The MC acknowledges receipt of the message with smdpp.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

2


36/38


II.1.1 Billing Output

A CDR produced by the Home MC should be the same as that produced inthe standard Indirect Routing scenario the true serving network may be impossibleto determine based on the information in the received SMDPP.

The serving network is in a better position to produce a good CDR than in

the Indirect case. While many MSCs may not produce CDRs for SMS events, MCsdo. Individual CDRs for SMS events could be easily produced by the servingnetwork MC. This difference is the main reason for describing this routing option,although see the final discussion point below for a specific potential problem.

II.1.2 Discussion and Issues

This routing arrangement is non-standard. ANSI-41-D procedures show a(serving network) MC rejecting a message such as this, which would appear to havebeen misrouted to the MC.

Care would be required with MSC configuration to ensure that SMS trafficcould be routed this way, especially with no impact to the MT-SMS service (e.g.SMSNOTs should not be sent to the serving network MC)

The requirement for a MC to route based on originating address in the caseof an inbound roamer, and on destination address for a home subscriber, mayexceed currently deployed MC capabilities.

Despite the non-standard message routing in the serving network, to thehome network the messaging should appear relatively normal. Some additional caremay need to be given to the population of the various address parameters to ensurethis is the case.

Production of a CIBER record from the serving network MC CDR may bedifficult, depending on the address parameters present in the SMDPP sent from theMSC to the MC. If (as has been observed for some networks) the MSC populatesonly the MDN in the originating address fields, the MSID would not be available atthe MC for population in the CDR and subsequent CIBER record, where it is amandatory field.

As noted above, the smdpp transmission timing by the serving network MCmay cause problems if the SMDPP is rejected by the home MC for some reason.Treating the SMDPP as an end-to-end message rather than link-by-link mayrequire additional modification to the serving network MC.

The MC-to-MC leg need not use ANSI-41. Other approaches such as SMPPmay also be used.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


37/38


II.2 Local Service

This non-standard option is also introduced in this document to produce a CDR in the

serving network for MO-SMS. In attempting to simplify the requirements on a servingnetwork MC (as compared with the Super-Indirect method), it treats the roaming subscriberin the same manner as a home subscriber of the serving network, which may represent adifferent set of services (and addressable destinations) than the roamer enjoys when athome. No real-world implementations of this method are currently known to exist it isshown as a possible solution to the billing requirements of the serving network, subject to thelimitations discussed below. The message flow is shown in Figure 6:

Serving

nwk MC

Home

HLR

Home

MC

Serving

MSC

SMDPPa

b

c

d

smdpp

Figure 6 - Local Service Routing for MO-SMS

a) The mobile originates an SMSb) The MSC sends all SMSs, regardless of origination or destination address,

to its own MC. The serving network MC processes the origination as if itwere for a (provisionless) home subscriber in this network.

c-d) smdpp and air interface acknowledgement are returned

Following this message submission, the serving network MC will analyze the destinationaddress and attempt delivery.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

2


38/38


II.2.1 Discussion

Although the message flow looks similar to the Direct Routing scenario, thedifference is that the MSC performs no analysis on the SMS address to determinethe correct destination. SMSs are passed blindly to the serving network MC.

The MC treats this as it would any origination from its one of its own networksubscribers. All numbering plans are unchanged, as are available intercarrier SMSdestinations and special short codes. The intercarrier destinations may be differentto those available to the subscriber when at home, leading to customer confusion. Insome cases, it may not be possible for the addressed party to respond.

A key requirement for this arrangement to be viable would be intercarrierSMS between the serving and home networks, so the roamer could message othersfrom his/her home network. While complementary to SMS roaming in this case, it isactually a separate piece of network connectivity to be achieved, and may make useof SMPP, SMTP or other transport options rather than ANSI-41. Care may berequired with originating address information to ensure that a reply from the homenetwork is routed via normal methods (i.e. MT-SMS roaming) rather than intercarrierto the serving network.

Home network SMS Short codes are unlikely to be available to the roamer,and clashes may lead to unexpected results.

The billing output from the serving network MC should be similar to that forthe Super-Indirect case, and potentially subject to the same issue of MSIDavailability.

In the direct routing scenario, a major concern was the analysis of the destination addressbeing performed in the serving network, and the complexities and limitations this may cause(see 7.1). This issue is present in the Local Service option as well, but it is hoped thatdestination analysis at a MC will prove more flexible than at a MSC.

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

Documents

20060815181446!SMS Roaming White Paper