Sunteți pe pagina 1din 49

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

CDG Document 133 Version 1.0 4 December 2006

CDMA Development Group 575 Anton Boulevard, Suite 560 Costa Mesa, California 92626 PHONE +1 888 800-CDMA +1 714 545-5211 FAX +1 714 545-4601 http://www.cdg.org cdg@cdg.org

Notice
Each CDG member acknowledges that CDG does not review the disclosures or contributions of any CDG member nor does CDG verify the status of the ownership of any of the intellectual property rights associated with any such disclosures or contributions. Accordingly, each

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations


CDG member should consider all disclosures and contributions as being made solely on an as-is basis. If any CDG member makes any use of any disclosure or contribution, then such use is at such CDG member's sole risk. Each CDG member agrees that CDG shall not be liable to any person or entity (including any CDG member) arising out of any use of any disclosure or contribution, including any liability arising out of infringement of intellectual property rights.

Contents

Ref Doc 133, Ver 1.0

4 December 2006

ii

Ref Doc 133, Ver 1.0

4 December 2006

iii

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Contents

Revision History Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 1.0 Date 2005-12-25 2006-01-11 2006-01-13 2006-01-27 2006-08-15 2006-09-25 2006-11-21 2006-12-04 Reason Initial version Updated following internal review Added transport layer ID for serving network, other minor updates Restructure and update Update for VSWG progress Minor updates post-IRT Minor updates following conference call Release version. No change from previous

Ref Doc 133, Ver 1.0

4 December 2006

iv

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Contents

Contents
SMS Roaming: Billing and Signaling Requirements, Options and Recommendations......i CDG Document 133...................................................................................................................i Version 1.0.................................................................................................................................i 4 December 2006.......................................................................................................................i Contents....................................................................................................................................v 1. Introduction...........................................................................................................................1 1.1 Definitions......................................................................................................................1 1.2 Audience........................................................................................................................2 1.3 SMS Standards..............................................................................................................2 2. Operator Billing Requirements............................................................................................3 2.1 Bill-and-Keep.................................................................................................................3 2.1.1 Serving Operator.............................................................................................4 2.1.2 Home Operator...............................................................................................4 2.2 Intercarrier Settlement...................................................................................................4 2.2.1 Serving Operator.............................................................................................5 2.2.2 Home Operator...............................................................................................5 3. Operator Recommendations...............................................................................................6 3.1 Message Delivery..........................................................................................................6 3.2 Serving Operator Billing.................................................................................................6 3.3 Home Operator Billing....................................................................................................7 4. Existing Operator Networks................................................................................................8 4.1 No MSC Records for SMS.............................................................................................8 4.2 MC CDRs Used for Billing..............................................................................................8 4.3 Transport Layer Address in MC CDR............................................................................8 5. Network Interconnection Options.......................................................................................9 5.1 Direct Connection..........................................................................................................9 5.2 Transport-Layer Roaming Service Provider...................................................................9 5.3 MAP Layer Roaming Serving Provider........................................................................10 5.4 Billing Clearinghouse...................................................................................................10 5.5 Multiple Option Scenarios............................................................................................10

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Contents

5.6 Intercarrier Messaging Hubs........................................................................................11 6. Solution Elements..............................................................................................................12 6.1 Serving Network CDR Generation...............................................................................12 6.1.1 Message Center CDR Generation.................................................................12 6.1.2 Network Probes.............................................................................................12 6.2 External Billing Information Sources............................................................................13 6.2.1 Home Network..............................................................................................13 6.2.2 Roaming Service Provider.............................................................................13 6.3 Record Transfer...........................................................................................................14 6.4 Home Operator Billing..................................................................................................15 6.4.1 Billing Using the MC CDR.............................................................................15 6.4.2 Billing Using a Received Record...................................................................17 6.4.3 Billing Using Both MC CDR and Received Record........................................17 7. Signaling Issues.................................................................................................................18 7.1 Direct Versus Indirect Routing.....................................................................................18 7.2 Population of Serving Network Identifier......................................................................19 7.2.1 MAP Layer Identifier......................................................................................19 7.2.2 Transport Layer Identifier..............................................................................21 7.2.3 Mobile Terminated SMS................................................................................22 7.3 Address Parameter Population....................................................................................23 7.4 Global Title Addressing for SMS..................................................................................25 7.5 Message Length .........................................................................................................25 7.5.1 Message Segmentation.................................................................................25 7.5.2 Failure Treatments........................................................................................27 7.5.3 Mobile-Originated SMS.................................................................................28 7.6 Subscriber Provisioning...............................................................................................29 7.6.1 Service Option List Population......................................................................29 7.7 Numbering Formats.....................................................................................................29 7.8 SMSNotification Support..............................................................................................30 7.9 Agreement Management.............................................................................................30 7.10 Roaming to SMS-Incapable Markets.........................................................................31 7.11 MDN-Based Message Centers..................................................................................31 7.12 Subsystem Numbers..................................................................................................32 7.13 Multiple Message Centers.........................................................................................32 7.14 Service Options.........................................................................................................32

Ref Doc 133, Ver 1.0

4 December 2006

vi

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Contents

8. Glossary..............................................................................................................................33 Appendix I - SMS Message Flows..........................................................................................35 Appendix I - SMS Message Flows..........................................................................................35 I.1 Successful MT SMS......................................................................................................35 I.2 Postponed MT-SMS......................................................................................................36 I.3 Successful MO-SMS Indirect Routing........................................................................37 I.4 Successful MO-SMS Direct Routing..........................................................................38 I.5 Mobile-to-Mobile SMS...................................................................................................38 Appendix II - Additional Message Routing Options.............................................................39 Appendix II - Additional Message Routing Options.............................................................39 II.1 Super-Indirect..............................................................................................................39 II.1.1 Billing Output.................................................................................................40 II.1.2 Discussion and Issues...................................................................................40 II.2 Local Service...............................................................................................................40 II.2.1 Discussion.....................................................................................................42

Figures
Figure 1. Successful MT-SMS..................................................................................................35 Figure 2. Postponed MT-SMS..................................................................................................36 Figure 3. Indirect MO-SMS.......................................................................................................37 Figure 4. Direct MO-SMS..........................................................................................................38 Figure 5. Super-Indirect Routing for MO-SMS.......................................................................39 Figure 6. Local Service Routing for MO-SMS.........................................................................41

Ref Doc 133, Ver 1.0

4 December 2006

vii

1. Introduction
This document describes international roaming Short Message Service (SMS). Operator requirements as well as characteristics of current implementations, challenges and possible future improvements are discussed. The document provides recommendations to address many of the issues raised, and summarizes the activities of the CDMA Development Group International Roaming Teams Voice & SMS Working Group (VSWG) to define industry-wide solutions where appropriate. For the majority of CDMA operators today, the primary issues related to international roaming of SMS relate to billing. The requirements, challenges and options related to billing represent a significant portion of the document.

1.1 Definitions
International SMS roaming is defined as the sending of short messages to or from a mobile which is receiving service from a network located outside its home country. International SMS roaming is the primary focus of this document. By contrast, domestic SMS roaming occurs when the mobile is receiving service from a network other than the home network, but still located inside the home country. Where a common numbering and addressing scheme is shared across multiple countries (e.g. within the North American Numbering Plan area), an international SMS roaming scenario may have many of the technical characteristics of domestic SMS roaming. In this document, this kind of roaming is termed quasi-international SMS roaming. Intercarrier SMS involves messaging between two mobiles homed in different networks. These networks may be based in different countries, i.e. international intercarrier SMS. Intercarrier SMS is different to, and independent of, SMS roaming

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

(whether domestic or international). A particular mobile-to-mobile messaging scenario may involve both SMS roaming and intercarrier SMS.

1.2 Audience
This document is intended to be read by personnel responsible for implementing SMS roaming, whether from a technical, commercial or billing perspective. The document assumes basic familiarity with: the ANSI-41 standard as used for own-network SMS; the network elements involved in providing SMS service and their basic functions; as well as a high-level understanding of international voice roaming as typically implemented by CDMA operators today. By way of background, some basic SMS message flows are provided in I.

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 the air inside IS-2000 DataBurst Messages. ANSI-41: SMS messages between network elements are carried inside ANSI-41 messages. The majority of roaming issues occur in the ANSI-41 domain, as the home, serving (and Roaming Service Provider) networks communicate at this level. Revision D is in most common use, although Revision E is in the process of publication, and modifies several areas related to SMS. TIA-637: This standard defines the content of the SMS message itself, including for example additional fields such as Time Stamp or Call-Back Number. Many, but not all, of the TIA-637 parameters are carried transparently between IS-2000 and ANSI41. IS-841: This standard modifies ANSI-41-D to accommodate the requirements of Wireless Number Portability.

Ref Doc 133, Ver 1.0

4 December 2006

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 network interconnection or billing record generation. Although each operator will have their own preferences, the information below should serve as a general guide. Two main models for billing are discussed: Bill-and-Keep, where the home operator bills its own subscribers without recompense to the serving operator; and Intercarrier Settlement, where the serving operator does receive a wholesale payment. Both arrangements can coexist between the same home and serving operators, e.g. Intercarrier Settlement for Mobile Originated (MO) SMS, Bill-andkeep for Mobile Terminated (MT). An operator could also 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 MTSMS.

2.1 Bill-and-Keep
Bill-and-keep represents an extremely simple model for SMS roaming billing. Since the serving operator does not charge for the service, there is no direct need for billing information to be produced in the serving network (although it may be desirable for other purposes 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 to roaming) Call Detail Records (CDRs) produced in its network. If the amount of roaming between two operators is largely symmetric, neither operator would lose net revenue as compared to the Intercarrier Settlement approach. Also included in the Bill-and-keep definition are intercarrier payments not directly related to SMS activity (e.g. a flat monthly fee, or one based on the number of

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

roamers regardless of SMS usage). Such payments are a purely commercial arrangement with no direct relationship to actual delivery or billing mechanisms for SMS roaming. The Bill-and-keep model has been successfully used by some serving operators for international MO-SMS roaming, particularly as an initial offering while alternative billing arrangements are being negotiated, and/or in conjunction with a flat fee. It is used by the majority of non-North American operators for international MT-SMS roaming. It is also common among North American operators for domestic and quasi-international SMS roaming (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) they should be identified as relating to roaming (assuming the MSC CDR is also in use for home network SMS billing) and not processed further.

2.1.2 Home Operator


The home operator is responsible for subscriber billing, and uses CDRs produced by the home Message Center (MC) for this purpose. Since there is no additional intercarrier charge to 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 for roaming SMS, sufficient information (in the form of Originating/Destination Point Code or SCCP Calling/Called Party Address) should be available at the MC for inclusion into a CDR that could be identified as relating to roaming. If the home operator wishes to charge based on the subscribers serving network (or to include this information on the subscribers billing statement) then information that identifies the serving network is required at the MC. In some scenarios, this may not be available. See 7.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 the provision of SMS services to inbound roamers. This approach is analogous to that currently used for voice roaming. The home operator continues to bill the subscriber, although may now need to ensure that the retail charge includes a component to cover the wholesale intercarrier portion that the home operator has been charged. In this document, it is assumed that the intercarrier charges for this model relate directly to the number of SMSs. Other charging regimes, e.g. flat monthly rate, are considered as part of the Bill-and-keep model, described above.

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

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 transiting its network, or only for successful attempts. A successful attempt for MT is one that is 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 aggressive retry schedule from the MC). Depending on the scenario, unsuccessful attempts may or may not consume radio resources. The preferred source of information for billing that is used to request payment from the home operator will be from within the serving operators own network, rather than relying on outside information. (This is not to say that external reports are unacceptable, merely that given the choice, it is assumed that operators would prefer to be masters of their own destiny, and be able to determine for themselves how much they are owed, rather than rely on someone else to calculate it.) The billing flow needs to be robust, automated and auditable. As a counter example, a manual process to cut-and-paste weekly summaries from a webbased report and build up a monthly invoice is likely to be error-prone, inefficient and not auditable at a later date.

2.2.2 Home 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 home operator may wish to charge its subscribers for SMS roaming. As different serving operators may charge different intercarrier rates, the home operator may wish to be able to charge a subscriber based on where s/he was when the message was sent/received. Operators should retain the ability to provide an itemized list of SMSs on the subscribers bill, rather than just a single total SMS charge. It is preferable for all charges on a subscribers bill relating to a single SMS to come from a single source. This can prevent undesired end-of-billing-cycle events where charges for the same message are split across two monthly statements, and can also remove the need for record matching (except as an audit function).

Ref Doc 133, Ver 1.0

4 December 2006

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 previous section. In some cases more than one option is presented. It is up to individual operators and their negotiations with roaming partners to decide between the bill-and-keep and intercarrier settlement approaches for billing. The recommendations below relate to ways to implement intercarrier settlement, as the requirements for bill-and-keep present a far smaller challenge. A simplified status is provided for each of the recommendations. Later sections of this document discuss the recommendations in more detail, including how they may differ from what is currently available, and what alternatives or modifications may be pursued.

3.1 Message Delivery


For successful MO-SMS delivery, indirect routing is recommended. For information on indirect routing, and how it differs from direct routing, see the discussion in 7.1, and the call flows in I. Status: Most if not all operators today use indirect routing for international roaming SMS.

3.2 Serving Operator Billing


By analogy to voice, the best approach would be for the serving MSC to produce CDRs for MO- and MT-SMS. CIBER records generated from these CDRs can be used for intercarrier settlement. Practical considerations (see 4.1) mean that this method is not actually feasible in the short or medium term.

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Alternatively, settlement can be performed at a summary level, without the transfer to the home operator of records detailing each individual SMS. Status: Most operators MSCs cannot produce SMS CDRs. Many operators use or plan to use Roaming Service Provider (RSP)-generated summary reports.

3.3 Home Operator Billing


The recommended approach for the home operator is to use the MC CDR for subscriber billing. If required, this CDR must contain enough information to allow billing to be differentiated by subscriber location (see 2.2.2). The far end point code and/or SCCP Called/Calling Party Address should be included in the CDR. Alternatively, the home operator can use received CIBER records to perform subscriber billing. Status: RSPs have available solutions for SMS CIBER generation. Signaling modifications to enable MC CDR billing are undergoing specification by the VSWG.

Ref Doc 133, Ver 1.0

4 December 2006

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 two sections, these characteristics can identify needs to be met by the solutions described in later 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 an SMS event, either MO or MT. This typically presents a problem when an operator wishes to introduce 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 not used.

4.2 MC CDRs Used for Billing


Almost all operators surveyed use their MC to generate CDRs for SMS, and use these records 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 necessarily include this information in the CDR. This can present a challenge when a home operator wishes to distinguish roaming CDRs from those produced by its subscribers while at home.

Ref Doc 133, Ver 1.0

4 December 2006

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 possible depending on the choice of interconnection method. These methods are therefore described briefly below. Note that a detailed explanation of SS7 signaling is beyond the scope of this document.

5.1 Direct Connection


Networks in the same country (or numbering space) can connect directly to each other. This option does not allow for any special services relating to SMS. True transport layer identifiers will 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 hub operated by a Roaming Service Provider (RSP). If the RSP functions as an STP or SCCP Relay, 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 a transport layer RSP. Networks in different countries (that do not share a common numbering and addressing scheme) may also connect to a transport-layer RSP. This can be achieved by assigning point codes from one country (often the US) to network entities in another, or by using bidirectional Global Title Translation (GTT). Care may be required when dealing with parameters like SMS_Address, which is typically a transport layer address embedded in the application layer. A transport layer RSP may be able to report on SMS traffic that transits its hub. Without access to the application layer, identification of SMS signaling messages

Ref Doc 133, Ver 1.0

4 December 2006

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

would be based on Subsystem 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 passed between networks.

5.3 MAP Layer Roaming Serving Provider


An 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 is processed by the RSP at the MAP layer, there is no direct end-to-end transport layer connection. Transport layer connectivity can be achieved by assigning the RSP a point code out of each of the customer networks own allocation schemes. Thus the RSP appears to belong inside each customer operators network. Additional SMS-related services may be offered by a MAP layer RSP: The RSP may be able to modify various ANSI-41 parameters to ensure interoperability, and also provide billing/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 the network 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 used in another), it can create challenges for the home operator if there is a need to identify the subscribers true location in the MC CDR.

5.4 Billing Clearinghouse


Either a transport or a MAP layer RSP can also act as a billing clearinghouse. While this does not directly relate to network interconnectivity at a signaling level, the link between the signaling and billing services provided by the RSP can add value for SMS. For example, if serving operator billing information is derived from the RSPs signaling function, the resultant charge can be directly applied to the home and serving operators settlement position by the RSP 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 in series. For example, an operator customer of a transport layer RSP may wish to connect with 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 impact on the value-added services available from the RSPs: accurate MAP layer parameter manipulations may not be possible without a customer-level relationship between both operators and the MAP layer RSP (e.g. to maintain network profile information about the required mapping). Similarly the

Ref Doc 133, Ver 1.0

4 December 2006

10

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

integration with the clearinghouse function is less likely when both networks are not customers of the same RSP. An operator may also choose to connect to one Roaming Partner using one method, and a different method for another Roaming Partner.

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 not provide a valid solution for SMS Roaming (with a possible exception in a theoretical, non-standard solution described in II.)

Ref Doc 133, Ver 1.0

4 December 2006

11

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 and interconnection options outlined in the preceding sections. Some of the methods described here are available and currently in use others are potential solutions that may or may not be 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 be available to the serving network (or its designate). To work around the fact that in most cases the MSC does not produce CDRs, other sources may be available within the serving network:

6.1.1 Message Center CDR Generation


The serving network MC does not normally handle SMS traffic for roamers. However, two non-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 the MSC behavior the CDR may lack some essential information (e.g. MSID), and the routing decisions 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), an alternative is to use Indirect Routing for MO-SMS, and to passively sniff the links to the RSP 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.

Ref Doc 133, Ver 1.0

4 December 2006

12

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Some carriers already send all roaming traffic through an ANSI-41 gateway, and this too could be adapted to provide the necessary billing output. In either case, the work is non-trivial to bill accurately for SMS, (especially if charging is only based on successful messages) such a probe would need to keep track of the TCAP Transaction ID to correlate message invokes and responses, as well as analyze the MAP layer to determine the type of message. In order to avoid the potential problem of MSID availability in the SMDPP (see II.1) the probe may need to retain subscriber profile information (e.g. MDN to MSID mapping) observed at registration time. One implementation of the network probe option is known to be in use at the time of writing.

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 that allows it to charge the home network. In practice, having the home operator nominate how much it must pay is unlikely to be considered an acceptable option from a commercial perspective.

6.2.2 Roaming Service Provider


Both a MAP and a transport layer RSP are in a position to observe the SMS traffic transiting their 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 the home operator in any agreed fashion (see 6.3). However other arrangements are possible too, e.g. if the RSP is also a clearinghouse then (provided the RSP has access to the serving operators rates for SMS services) the SMS charge can be directly applied to the operators 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 an SMS transaction, as this information is contained in the MAP layer. (A possible exception is MO-SMS, if the subscribers IMSI is used as the Global Title Address.) A report would therefore be of a form such as on 9 January 2006, Operator As subscribers originated/received 1234 SMSs while roaming on Operator B SMS transactions would be identifiable by Subsystem Number (SSN). Use of the SSN has the following characteristics:

Ref Doc 133, Ver 1.0

4 December 2006

13

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

SMSNotification counted as SMS. The SMSNotification (SMSNOT) message is indistinguishable at the transport layer from a SMSDeliveryPointToPoint (SMDPP) message which actually contains a subscribers SMS. SMSNOTs would be included in the message count reported to the serving operator. Unsuccessful messages counted. Without examining the MAP layer, it is not possible to distinguish a successful SMS message from an unsuccessful one. Both will be included in the message count. MO and MT both counted. At the transport layer, the response to an MT SMS is indistinguishable from an MO SMS., and vice versa. Thus both directions will be included in the message count.

There are no known implementations of transport layer RSP billing reporting at the time of writing. 6.2.2.2 MAP Layer RSP A MAP layer RSP has the opportunity to examine and report on SMS transactions in more detail than a transport layer RSP. Access to the subscriber information in the MAP layer (e.g. MSID, 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 the necessary information available to it to distinguish SMSNOTs from SMDPPs, successful SMDPPs from unsuccessful ones, and MO- from MT-SMS. Summary-level reporting is available today from both the two major RSPs. Individual level reporting is available but not in commercial use at the time of writing.

6.3 Record Transfer


In order to perform intercarrier settlement, an agreed format for record transfer between operators (or an equivalent approach, e.g. clearinghouse integration) is required. A single industry-wide solution is preferable to a proliferation of different bilateral approaches. The solution 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 pass individual 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 CDRbased) SMS billing flow.

Ref Doc 133, Ver 1.0

4 December 2006

14

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

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 by which roaming CDRs are exchanged among carriers. Appendix K of the CIBER specification describes ways in which data services (including SMS) may be captured in CIBER format. To avoid multiple different implementations, further discussion among the carrier community would be required to determine an agreed usage, particularly in the case of summary records. Existing fields in the CIBER format should provide sufficient scope to include enough information to use individual records for retail billing, as is done today for voice. At the time of writing, two serving operators are believed to be using CIBER records for SMS. No operators have expressed interest in the development of standardized usage guidelines for CIBER SMS records. An alternative approach is to design a new record format specifically for SMS. The primary driver for this may be cost SMS transactions are likely to be low value when compared to records for voice calls, and any step in the billing chain which today involved a per-record charge would need to be carefully examined.

6.4 Home Operator Billing


The home operator is responsible for subscriber billing. The information to perform this billing 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 a combination of both. In this document, to allow for the maximum flexibility in billing, it is assumed that the home operator wishes to be able to identify the roaming subscribers serving network. Several operators have indicated that this is the case, however individual roaming agreements and operator preference may relax this requirement in some instances. A weaker requirement that may hold for some operators is that roaming SMS be distinguishable from non-roaming SMS from a billing perspective this would allow a flat rate roaming charging scheme, with the roaming charge calculated to cover the range of inter-carrier charges to the extend decided on by the home operator.

6.4.1 Billing Using the MC CDR


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

1 An exception is a network which produces MSC CDRs. In this case the MC CDR may be disabled

and domestic (as well as inbound roaming) SMS charged from the MSC CDR.

Ref Doc 133, Ver 1.0

4 December 2006

15

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

For both roaming and non-roaming cases, the MC CDR is assumed to contain information such 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 end network element, identification of the serving network may not be possible. Inclusion of this information is recommended as a minimum requirement for home operators interested in differentiating roaming SMS MC CDRs. An alternative approach using MAP layer parameters is described in 7.2. If not already included, the work required to add these one of these parameters to the CDR may exceed that 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 layer address will be available to the MC. For MO-SMS, it will be received by the MC as the Originating Point Code or Calling Party Address in the incoming SMDPP. For MT-SMS, it is used by the MC as the Destination Point Code or Called Party Address in the outgoing SMDPP. The MC obtains these values from the HLR in the SMS_Address parameter contained in the SMSRequest Return Result, or from the MSC/RSP in the SMS_Address parameter of an SMSNotification Invoke. Assuming the transport layer address is included in the CDR, the home operator can use it to determine the subscribers serving network. However, this may require the population of a large number of identifiers in the home operators billing system, and represent a large maintenance effort. To identify only that the CDR relates to roaming SMS, the point code or global title address needs to be recognized as not belonging to the home operator this may be an easier task to provision and maintain the data for. Further investigation is required regarding the validity of hierarchical point code allocation, and whether 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 CDR contains the observed transport layer address, then the CDR can be identified as relating to roaming, but the identity of the true serving operator cannot be ascertained. Section 7.2 discusses some potential modifications to the ANSI-41 and/or transport layers of various messages to ensure that the serving operator can be identified at the MC. Detailed specification of these modifications is under action in the VSWG.
Ref Doc 133, Ver 1.0 4 December 2006 16

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

6.4.2 Billing Using a Received Record


If the home operator receives individual SMS records from the serving operator (or from the RSP), these records can be used for subscriber billing. Note that it is also possible for 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 specifically for subscriber billing. Both major RSPs have advised that they can offer this service. The received record must contain information about the message origin (for MTSMS) or destination (for MO-SMS) to enable correct billing. In the case of CIBER, a possible mechanism is to use the Caller ID and Called Number Digits fields respectively from the CIBER22 record. For subscriber billing, the record may need to be re-rated rather than simply applying a fixed markup (e.g. in the case of a SMS to/from a premium service such as Idol voting or a stock price 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 received record only approach is being used by the home operator with only some of its roaming partners, the MC CDR will need to identify the serving operator so that MC CDRs for roaming in the operators networks that dont transfer records to the home can be used for billing. Most serving operators cannot currently provide detailed records, and a number have indicated that they have no intention of doing so. However both major RSPs have announced that an individual CIBER record generation service is available.

6.4.3 Billing Using Both MC CDR and Received Record


To use both records, the home operator may wish to combine them into a single charge on the subscribers statement. Matching against time and originator may be difficult if there are multiple messages delivered within a short time. Another alternative is to use the IS-637 Message Identifier, although for certain types of messages (e.g. WAP Push), this is not unique, 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 to the originator/destination, meaning that this address need not be included in the received record.

Ref Doc 133, Ver 1.0

4 December 2006

17

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. For examples of direct and indirect routing, see Appendix I. Direct routing appears to be a more efficient routing arrangement, involving fewer signaling hops. However, there are a number of potential drawbacks: An initial concern with a direct routing arrangement would be that, depending on the message destination, the Home MC may be bypassed, thereby exacerbating the lack of available 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 provide billing information. For the SMS case, if the serving network (or MAP layer RSP) could produce sufficient billing information and pass it to the home network (e.g. in the form of CIBER 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 in todays environment. Another issue with Direct Routing relates to the requirement on the MSC to analyze the destination address received from the mobile. Different operators may have different SMS addressing plans, and SMS interconnection agreements with a unique subset of other networks. 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 roamers destination address appears to be an unreasonable requirement on a serving MSC, compared with the Indirect approach of sending all originations to the Home MC.

Ref Doc 133, Ver 1.0

4 December 2006

18

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

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

7.2 Population of Serving Network Identifier


To enable per-serving operator subscriber charging for MO-SMS, the home network must receive information that identifies (at a minimum) the serving operator. If permessage intercarrier settlement records are not used, the source for this information must be the home MC CDR. The source of the MCs information is the received SMDPP. See 7.2.3 for discussion on per-serving operator charging for MT-SMS. If a direct signaling connection or a transport layer RSP is used, information about the originating MSC will be present in the transport layer of the SMDPP Invoke, to enable routing of the Return Result. However, when a MAP layer RSP is present in the signaling path the SMDPP today may contain no information about the true serving network. Some modification 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 the identifier: MAP layer, and transport layer. At the June 2006 VSWG meeting, operators expressed a preference for the transport layer option, and reconfirmed this preference at the September meeting. Advantages and disadvantages of the two options are discussed in their respective sections.

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 defined parameters for the SMDPP message. An alternative approach therefore involves using a different parameter two specific options are discussed below. Note that the intention is to provide information to the MC for the sole purpose of including it in the CDR it does not need to be acted on in any other way. Therefore, the exact format of the serving network identifier is largely irrelevant, provided the parameter layout can accommodate it, and the home operators billing system can recognize it and charge accordingly. A suggested value would be Mobile Country Code + Mobile Network Code. Characteristics of a MAP layer solution include:

Simple for the RSPs to implement. This is the layer at which the RSPs can already modify parameters. "Safe", in that no other network elements need to be aware of the change, only the MC.

Ref Doc 133, Ver 1.0

4 December 2006

19

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Complex for carriers/SMSCs. It is not clear which MAP parameters MC vendors currently include in their billing records, but this is expected to vary. Development may be required to support a common solution. Widespread support may be slow due to multiple MC vendors affected. Message length increase. If the chosen parameter is not present in the SMDPP from the serving carrier, this parameter will be inserted by the RSP, with an expected minimum length of 10 bytes. This may cause a long SMS which would have otherwise been successful to fail as overlength. Overwriting. Although the best information available currently indicates that no carriers look to the preferred parameter (see below) to carry some other important information, it is possible that some operators may require other information in this parameter. Asymmetrical. Would require a different parameter for MT SMS as compared to MO.

Two specific parameters are considered for carrying the serving network identity: SMS_OriginatingAddress (SMS_OA), and SMS_OriginalOriginatingSubaddress (SMS_OOSA). 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 RSP Point Code/Global Title Address. In ANSI-41-D, SMS_OA is copied to the original originating address by the MC if SMS_OriginalOriginatingAddress (SMS_OOA) is not received2, although SMS_OOA should normally be present. In ANSI-41-E, SMS_OA is clearly overwritten at the MC3, however this may not always happen, especially under Rev D.

SMS_OriginalOriginatingSubaddress:

When the Type of Subaddress = User Specified, the formatting of the rest of this parameter is open. This parameter is unlikely to be used for any routing decision, however it is likely to be transferred to the ultimate message recipient, with unpredictable results. This may also lead to privacy concerns, with information about the senders location being provided to the recipient without the senders consent.

2 N.S0005-0 v1.0 Ch 6 4.46.6 step 1-14-1 3 X.S0004-641-E v1.0 4.4 step 2-3

Ref Doc 133, Ver 1.0

4 December 2006

20

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Of these two parameters, use of SMS_OA is preferred due to the uncertainty of SMS_OOSA handling end-to-end. However, the potential impact on MCs in order to include the necessary information in the billing record was the primary reason why operators did not prefer the MAP layer option.

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 serving network. However, this negates some of the key advantages of having a MAP layer RSP in the first place, namely screening different (and possibly conflicting) national point code assignments from each other, and simplifying the network provisioning required by each operator. An alternative is for the RSP to populate a single (originating) PC per operator in MO-SMS SMDPPs. Inclusion of this operator-level PC in the MC CDR will allow for identification of the true serving network, and is believed to be a relatively common capability of the MC CDR. Each operator would assign a PC from their own national allocation plan to represent each of their roaming partners, to be used by the RSP. Thus the PC used to identify a particular serving 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 codes to the RSP, to ensure correct Return Result routing. This approach could also be used with an operator-level Global Title Address (GTA) for those (home) networks which use Global Title Translation4. It is suggested for STP configuration simplicity that the virtual GTA used be one that naturally resolves to a PC in the home operators network (e.g. home network MCC/MNC), rather than using an address that belongs directly to the serving operator. Characteristics of the transport-layer approach:

Simple carrier implementation. Many carriers' MCs already include the point code in their billing record. There may be no MC modification at all required if this point code is changed to be serving-carrier specific. Common for non-RSP implementations. With no RSP in the middle, expect that the native point code could be used to identify the serving network. This may require a large administration effort in the home billing system, but the principle is there to use the same approach whether or not an RSP is used. Symmetrical. Inclusion of the "dummy" point code in the SMS_Address MAP parameter at registration time could allow this approach to be used for MT billing as well.

4 Provided the MC includes the SCCP CgPA in the CDR when GT routing is used

Ref Doc 133, Ver 1.0

4 December 2006

21

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Implementation effort required in the network. Routing needs to be defined for the dummy point codes through all the STPs etc that may handle the message. This is configuration work as opposed to development. Different for GT. Where a carrier uses Global Title Translation (GTT) for routing in their network, a "dummy" SCCP Global Title should be used instead of a point code. This represents an impact to the RSP to support the various options. Complex implementation in the RSP. The RSPs need to manage many point codes, and determine the point code they will appear as towards the home carrier based on which serving carrier sent them the original message. Point code availability. Several parties have raised the issue that it may be difficult to secure point codes in each network/country to represent all other roaming partners. Apparently in some countries (especially those using a 14bit point code) there is already an issue with exhaustion of this resource, due to inefficient assignment procedures.

A separate document, Signaling for International Roaming SMS Billing, describes the transport layer approach in more detail. An alternative approach was presented at the September 2006 IRT meeting, in which the serving network identifier is carried in the global title, even when routing uses the point code. For global title routing, extra digits are added to the global title address to identify the serving network, but should not be used for routing. This solution would minimize operator routing impacts, and also greatly lessen the impact on the RSP (as a single identifier could be used to represent a particular serving operator to all home operators). The primary concern (and the main reason why it was not endorsed by operators at the meeting) was uncertainty about whether the MC CDR would include a GT that is redundant from an SCCP point of view.

7.2.3 Mobile Terminated SMS


For MT-SMS, the MC originates the SMDPP. A serving network identifier may therefore be derived either from information available to the MC prior to the transmission of the SMDPP, or from information contained in the smdpp (Return Result). If the operator level PC/GTA described above is also used by the RSP to populate the (MAP layer) SMS_Address parameter sent to the HLR at registration time, then this value will be returned to the MC in the SMSRequest Return Result and used to address the subsequent SMDPP. This value could then be included in the MT CDR and used to identify the serving market. In some HLR implementations, an operatorlevel MSCID may also be required, as the HLR may not handle multiple SMS_Addresses for a single MSCID. The operator-level PC/GTA could also be sent in the smdpp from the RSP.

Ref Doc 133, Ver 1.0

4 December 2006

22

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

An equivalent MAP-layer solution would be to include the MSCID parameter (set appropriately to identify the serving operator) in the smdpp. MSCID is defined as an optional parameter for smdpp in ANSI-41-E, for use in Over-The-Air Service Provisioning. MC support for the reception and CDR inclusion of this parameter is unknown.

7.3 Address Parameter Population


Interworking problems can arise due to the way different networks populate the various address 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, and are 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 make use of them on receipt. Also, the addresses may take the form of either MSID or MDN. As an example, a serving network may populate the SMS_OOA parameter with the originating 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 the message 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 previously provisioned information about the requirements of the receiving node. This can be performed by a MAP layer RSP if used; otherwise this manipulation functionality must be implemented in at least one of the operator networks. (MSIDMDN mapping if needed can be cached at registration.) Below are recommended values for address population, based primarily on ANSI41-E and IS-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 derived are informative only. MSID population is also recommended, although in current implementations is not always the case, especially for MO-SMS. MT SMS - SMDPP from MC to MSC:

Ref Doc 133, Ver 1.0

4 December 2006

23

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

SMS_OOA: Unchanged from incoming SMDPP or otherwise provided by originating Short Message Entity (SME) SMS_OA: Not populated5 SMS_ODA: Entered digits from message originator SMS_DA: Not populated6 MSID: Destination MSs MSID7

MO SMS SMDPP from MSC to MC (Indirect Routing): SMS_OOA: Originating MS MDN8 SMS_OA: Not populated9 SMS_ODA: User entered digits, provided by the MS over the air SMS_DA: Originating MS MDN10 MSID: Originating MSs MSID11

Note that population of SMS_OA for MO with a serving network identifier is discussed as an option in the previous section. The key parameters are the SMS_OOA and SMS_ODA, which should be carried unchanged end-to-end in ANSI-41. In ANSI-41 Rev E, messages are rejected if these parameters are not present.12
5 Set to MC PC/GTA in X.S0004-641-E v1.0 4.5 step 2. Later omitted based on X.S0004-641-E v1.0

3.2 step 9.
6 Set to MSC PC/GTA (assuming this is SMS_Address in smsreq) in X.S0004-641-E v1.0 4.6 step 8.

Later omitted based on X.S0004-641-E v1.0 3.2 step 4


7 X.S0004-641-E v1.0 4.6 step 9, & X.S0004-540-E v1.0 2.61 Note a 8 X.S0004-691-E v1.0 4.5 step 6-1. In N.S0005-0 v1.0 Annex D D.5 steps 7 & 9-1, the MIN is used

instead. C.S0015-B_v2.0_051006 2.4.2.1.1.1 says "The mobile station address shall be determined from the MSID field of the Data Burst Message.", but MSID here is used in its C.S0004 sense, i.e. potentially including the ESN as well, so "determined from" can include looking up the VLR record to find the MDN
9 X.S0004-691-E v1.0 4.5 step 4 uses MSC PC/GTA, in N.S0005-0 v1.0 Annex D D.5 step 7, the

MIN is used instead. However, at X.S0004-641-E v1.0 3.2 step 9, SMS_OA is omitted if carried by the underlying transport, as would be the case for PC/GTA. Equivalent text in N.S0005-0 v1.0 Ch 6 4.46.2 step 12 may indicate omitting it too?
10 X.S0004-641-E v1.0 3.5 step 1-4-1. Corresponds to " {A->As MC}" from N.S0005-0 v1.0 Ch 3 7 11 X.S004-540-E v1.0 2.61 Note a 12 X.S0004-641-E v1.0 3.4 step 1-5-1. X.S0004-641-E v1.0 3.4 step 1-10-1. X.S0004-641-E v1.0

3.6 step 1-7-1. X.S0004-641-E v1.0 3.6 step 1-13-1

Ref Doc 133, Ver 1.0

4 December 2006

24

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

A fully-qualified E.164 MDN is recommended for MO addressing, particularly in the case where 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.

7.4 Global Title Addressing for SMS


Support for bi-directional Global Title (GT) addressing was introduced in IS-807, and has since been incorporated into ANSI-41-E. Detailed information is provided for several translation scenarios under ANSI and ITU signaling. However, an IMSI-toMC translation is not defined for ITU, and is instead left to mutual agreements. Coordination between both home and serving operators, as well as any intervening STP/SCCP Relay providers will be necessary as part of agreeing on a GT format for SMS.

7.5 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 maximum allowed length can be difficult although hard limits of 272 octets for the MTP Signalling Information Field13, and 2016 bits for an air interface Protocol Data Unit (PDU)14 apply, the variable length and presence of other (non-SMS) parameters in the message, and possibly arbitrary equipment-imposed limits mean that there are many possible reasons why a message may be determined to be overlength. A 2003 Survey highlights the differences among various operators. Besides general operator coordination of maximum lengths, some specific options are discussed below.

7.5.1 Message Segmentation


One approach to dealing with long messages is to divide them into multiple smaller parts. This process is called Segmentation and Reassembly (SAR). There are several layers within the message protocol at which segmentation can take place. 7.5.1.1 SCCP Segmentation The SCCP standards define a mechanism for SAR. Instead of a single Unitdata (UDT) message, the SMDPP is broken up into multiple Extended Unitdata (XUDT) messages. A message that is too long to be carried as a single MTP Message Signal Unit, but will fit in an air interface PDU, can be successfully transferred in this manner. As an estimate15, the potential gain in usable message length could be up to 60 7-bit characters.
13 T1.111.3-2001 2.3.8 & Q.703 2.3.8 14 C.S0004-0 v1.0 2.2.1.2.2 & 3.2.2.2.2

Ref Doc 133, Ver 1.0

4 December 2006

25

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

Unfortunately, not all operators or RSPs currently support SCCP SAR/XUDT. In some cases, an XUDT message is silently discarded. This leads to a phenomenon loosely referred to as message jamming, where the MC continues to retry the overlength message before sending other messages for the subscriber. Until the offending message expires from the MC (which can be several days) or the subscriber returns to their home network, no messages, regardless of length, can be received by the subscriber. ANSI-41-D does not provide a means for the MC to determine if the serving MSC (or RSP) can accept SS7 SAR this is addressed by N.S0020 (and incorporated into ANSI-41-E): a bit in the TRANSCAP parameter is used to indicate SAR support, and this parameter may be included in the smsreq or SMSNOT sent to the MC by the HLR. Among operators using SCCP SAR in their own networks, support for this reporting mechanism is recommended: if the operators MSCs set the SAR bit in the TRANSCAP parameter, but the RSP/partner MSC does not, and the information is transferred to the MC, then the operator can avoid sending segmented messages to roaming partners. The specific action to be taken by the MC16 if it has a message to send that is too long for a single MTP message, but the serving network does not support segmentation, is not defined, but at least it should avoid the message jamming situation. An alternative is for static configuration data (against the received SMS_Address) to be used in the MC to prevent the sending of segmented messages to non-supporting networks. When all roaming partners appear to the home operator as a single MAP-layer RSP location (and the RSP itself supports SAR), the reporting mechanism may not be successful in allowing segmented messaged to be sent to those partners who support them, and not to those who dont. The HLR is assumed to store transaction capabilities not on a per-subscriber basis, but per-MSCID. If a single MSCID is seen by the HLR, then the RSP cannot report differing SAR capabilities for the various serving networks. A possible solution here is MSCID pass-through or assignment by the RSP of an operator-level MSCID. See 7.5.2for a suggested interim action. In any case, RSP support for SAR is recommended as a necessary first step to the successful use of SAR while roaming, and also the interim alternative in 7.5.2. 7.5.1.2 Teleservice Segmentation An alternative to segmenting at the SCCP layer is segmenting at the SMS Teleservice layer. Although TIA-637 does not directly define a segmentation method, it does so indirectly though the Wireless Enhanced Messaging Teleservice (WEMT). WEMT allows for the use of GSM Enhanced Messaging Service (EMS) in

15 Based on an arbitrary but real-world population of other parameters in the message 16 E.g. discard, truncate, segment at application (see next section) or inform originator (see 7.5.2)

Ref Doc 133, Ver 1.0

4 December 2006

26

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

CDMA SMS (although the reference in TIA-637 to 3GPP 23.040 would appear to allow regular GSM SMS as well as EMS to be carried). The referenced GSM specification (23.040) defines a mechanism for segmentation of short messages, up to a maximum length of over 39,000 7-bit characters. Segmentation at this layer has the advantage of not requiring special handling from any intervening network elements between the MC and MS (other than the transparent transfer of the WEMT teleservice). At the SS7 and ANSI-41 layers the segments appear as individual messages, and the RSP and serving network need not be concerned with reassembly. Length limits on the air interface can also be avoided by this method, as separate air interface Data Burst Messages are sent. Specific support for WEMT is however required in the handset. The level of availability of handsets that support WEMT is unknown at the time of writing (although its use has been observed in at least some commercially available handsets). Since a message segmented in this way is seen by the RSP and serving network as multiple individual messages, any charging mechanism would by default apply separately to each of the message segments. The WEMT Teleservice ID is however available at the ANSI-41 layer, so in theory a different charging regime for WEMT messages could be applied. 7.5.1.3 Application Segmentation Another option for segmentation is simply to divide the text of the message into multiple parts, and send as entirely separate messages. A brief header such as Part x of y: could be included at the start of each part. This approach requires no special capabilities from the RSP, serving network or MS. The user experience is less than perfect, however, as the user will receive multiple message alerts and must open and read each part individually. This approach has the same billing implications as the Teleservice Segmentation described above, but messages segmented in this way could not be identified by TeleserviceID. One possible use of this approach is for the RSP to perform the segmentation when a message is received that exceeds the (predetermined) maximum length for the destination network. This may represent a non-trivial task for the RSP it would need to modify the message deep into the SMS Teleservice layer, be careful with character boundaries for non-octet encoding, and it may need to manage the MESSAGE_ID for all SMSs it transits to avoid conflicts. Accordingly, this approach is not recommended as a short-term option.

7.5.2 Failure Treatments


In some cases, operators have reported overlength failures even when a nonsegmented message delivery is being attempted. The differing operator limits, and
Ref Doc 133, Ver 1.0 4 December 2006 27

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

the message jamming experienced when an overlength message (or segment) is silently discarded, show the need for explicit handling of messages that cannot be delivered due to excessive length. ANSI-41 defines the SMS_CauseCode value 106 as User Data size error. This cause code value is recommended for use by network entities when they receive a message that is too long. Examples include:

An MSC that supports SCCP SAR receiving a message that is too long to fit in an air interface PDU An RSP receiving a segmented message destined for a network that is known (either via TRANSCAP or static configuration) not to support SAR. (In order to process this message and respond to it, the RSP itself must support SAR such support is therefore recommended) An RSP receiving an unsegmented message that exceeds a preconfigured known maximum for the destination MSC

Note that an entity that does not support SCCP SAR is unlikely to be able to return an application level error message on receipt of an XUDT. The return of this cause code allows the sending entity to know that there is a problem with the message, and what the issue is. Actions at this point could include providing a notification to the message originator or application segmentation as described above. An alternative approach is message truncation either on receipt of, or instead of sending, an overlength notification. Truncation is less preferred than notification as important information may be lost from the message (e.g. if the message Please call me urgently on 555-1234 were truncated). The originator may be unaware that the intended recipient did not receive the entire message. Nevertheless, some operators may prefer a partial delivery to no delivery. If the message originator requested a delivery receipt, failure information (i.e. text such as your message to mobile xxxxxx was too long) can be included in an SMS Delivery Acknowledgment Message. In addition, C.S0015-B defines the Message Status subparameter which can be included in an SMS Delivery Acknowledgment Message the MSG_STATUS_CODE field in this subparameter can take a value indicating Text too long.

7.5.3 Mobile-Originated SMS


The discussion above generally assumes that the overlength message is mobile terminated. It is typically easier for the originator to become aware of a problem with a MO-SMS: If the message is too long for the air interface, this should be apparent to the user (the MS will not receive a Layer 2 confirmation for the Data Burst Message, and the MS will display message not sent or equivalent).
Ref Doc 133, Ver 1.0 4 December 2006 28

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

If the message is too long for the ANSI-41 interface, this can be conveyed to the MS via the SMS Acknowledge Message. Use of the Bearer Reply Option parameter (to request the Acknowledge message) is recommended. The MSC is recommended to wait for the ANSI-41 result before sending the Acknowledge message17

7.6 Subscriber Provisioning


ANSI-41 provides several options for provisioning subscribers ability to send and receive messages. The key parameters in the subscriber profile are SMS_TerminationRestrictions and SMS_OriginationRestrictions. SMS_TerminationRestrictions: In many cases, the only values supported by HLRs and MSCs are 0 (Block all), and 3 (Allow all). Home networks should be wary of relying on serving network support of the Allow specific and Reverse Charge values. Delivery attempts to subscribers with Block all should 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 by the serving operator, use of the Force Message Center (FMC) bit can allow a home operator to require Indirect Routing for its subscribers, even if the default policy in the serving MSC is to use Direct Routing. Support for the FMC bit is recommended in HLRs, and in MSCs that otherwise use Direct Routing. The use of the DIRECT bit (block/allow direct routing) can be somewhat misleading, and in fact this has been removed from ANSI-41E. The bit should be set to zero.

7.6.1 Service Option List Population


Some operators include the SMS Service Options (6 & 14) in the ANSI-41 CDMAServiceOptionList 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_TerminationRestrictions parameters to determine SMS service qualification, without regard to the Service Option List.

7.7 Numbering Formats


The Indirect routing method leads to the destination address being parsed in the home network. As has been discussed above, this is generally a good thing. However, it can lead to subscriber confusion as the required format will likely be different to that used for voice (where the dialed digits are parsed by the serving

17 See C.S0015-A 3.3.1

Ref Doc 133, Ver 1.0

4 December 2006

29

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

MSC). The long-term resolution for this issue is Plus-Code Dialing (allowing a uniform format in all countries) or perhaps Virtual Home Environment (allowing at home formats for all services while roaming). In the short term, operators are encouraged to educate their subscribers (e.g. via Welcome SMS) to use the home 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. Although the marketing position is that subscribers should use the NZ domestic format, the roaming voice format will work as well.

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

7.8 SMSNotification Support


Not all networks currently support returning SMSNOT, even when the SMS_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. by omitting SMS_NotificationIndicator), except in certain circumstances e.g. time-critical SMSs. Any network that does not support sending SMSNOT should not send SMS_CauseCode 36 (SMS delivery postponed) in the smdpp.

7.9 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 serving operator to allow/deny SMS on a per-roaming partner basis. In this case, the RSP may ensure that SMS traffic is only allowed for a particular {Home, Serving} operator pair when both parties have advised the RSP that an agreement is in place.

Ref Doc 133, Ver 1.0

4 December 2006

30

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

7.10 Roaming to SMS-Incapable Markets


ANSI-41 contains various provisions to handle scenarios where a MS moves between serving markets with differing ability to support (MT) SMS. When roaming is implemented via a MAP layer RSP which represents all roaming destinations 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 the REGNOT) as an indication that the serving MSC supports SMS. Operators should investigate the behavior of their HLR when receiving REGNOTs from the same MSCID where the SMS_Address is inconsistently present. In a worst-case scenario, a MS registering in a market that is not SMS-capable may inadvertently suspend SMS delivery to all roaming MSs in all markets served by the RSP! Two RSP scenarios in particular should be carefully examined by the home operator with respect to their particular network behavior:

An MT SMS is submitted to the MC for a MS roaming in a network that does not support SMS, which then roams to a network that does support SMS. From which network element will the MC receive the necessary SMSNOT?18 A MT SMS delivery is unsuccessfully attempted to a MS roaming in a SMScapable market. The MS subsequently moves to a market that is non SMScapable.19

7.11 MDN-Based Message Centers


SMS as standardized in ANSI-41-D does not fully address the requirements of Wireless Number Portability (WNP). When the MC queries the HLR for the location of the destination MS (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 to allow use of the MDN instead of the MIN. In a roaming situation, the home and serving networks may have differing levels of IS-841 support. In particular, a non-IS-841-compatible serving MSC may send a SMSNOT to the MC using MIN (only), but the IS-841 MC may in theory require the

18 If the HLR has a static definition that the RSP is SMS-capable, it will return a valid SMS_Address

(indicating the RSP, not the true serving market) to the MC, and the MC will attempt to deliver the message by sending SMDPP to RSP. The MS may at some point roam to a SMS-capable market, therefore the only reasonable response is for the RSP to return "postponed". The RSP must therefore maintain the SMSDPF, since the serving market can't. When the MS moves to a SMS-capable market, the MC must be notified. Possibilities are either that the RSP sends SMSNOT, or that it includes SMSMWI in a REGNOT to the HLR (the REGNOT is forwarded to the HLR due to the change in SMScapability), and the HLR sends the SMSNOT.
19 In this case, the regcanc from the old network contains the SMSMWI parameter. The RSP passes

the SMSMWI to the HLR in the REGNOT. The HLR is responsible for maintaining the SMSDPF, and sending the SMSNOT when the mobile returns to a SMS-capable network. See ANSI-41.3-D 7.16 with the RSP as VLR.

Ref Doc 133, Ver 1.0

4 December 2006

31

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

MDN as the primary key to identify the MS for whom a short message is pending. IS-841 procedures20 indicate that the MSC should only use the MSID to identify the mobile, and not the MDN. IS-841-compatible MCs should be designed with this approach in mind. The behavior of real-world MCs in this respect is unknown.

7.12 Subsystem Numbers


In IS-41-A, SSN 5 was used for all MAP traffic. In later revisions, distinct SSNs were defined for the various applications e.g. HLR, VLR etc. ANSI-41-D assigns SSN 11 for SMS in both ANSI and ITU SCCP, however the ITU value has been changed to TBD in IS-807 and ANSI-41-E. Roaming partners may need to confirm their SSN usage, and potentially ensure that their applications can accept traffic routed to the wrong SSN, or that the SSN can be modified en route (e.g. by the RSP).

7.13 Multiple Message Centers


ANSI-4121 states there is only one home MC for each MS-based SME ... Notification for postponed delivery is only sent to this MC. Despite this, some operators are believed to deliver MT-SMS from more than one MC for the same subscriber (e.g. application push from one MC, mobile-to-mobile from another). Routing of an SMSNOT to the correct MC or MCs can become a difficult task. When the subscriber is within the home network, custom handling of this scenario is possible at the MSC (e.g. maintenance of multiple SMS Delivery Pending Flags (SMSDPFs) per subscriber). When roaming however, similar capabilities from the serving MSC or RSP can not be relied upon, and home network handling should be used. A possible approach is for an MC receiving an SMSNOT to copy this message to all other MCs in case they too have a message pending for this mobile.

7.14 Service Options


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

20 N.S0024 v1.0 4.47.2 step A 21 X.S0004-600-E v1.0 1.5, also in Rev D

Ref Doc 133, Ver 1.0

4 December 2006

32

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

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 for intercarrier settlement of voice roaming. EMS GTA GTT HLR ITU MAP MC Enhanced Messaging Service Global Title Address Global Title Translation Home Location Register International Telecommunication Union Mobile Application Part Message Center. An entity that stores and forwards short messages. Also referred to as Short Message Service Center (SMSC) Mobile-Originated SMS

MO-SMS MS MSC

Mobile Station Mobile Switching Center

MSID Mobile Station Identifier. May be either MIN or IMSI. MT-SMS MTP PDU RP RSP Mobile-Terminated SMS

Message Transfer Part. Lowest layer of SS7 signaling stack. Together with SCCP, generically referred to as transport layer in this document Protocol Data Unit Roaming Partner Roaming Service Provider. An intermediate entity providing interconnection (and possibly other services) between the home and serving operators.

Ref Doc 133, Ver 1.0

4 December 2006

33

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Signaling Issues

SCCP Signaling Connection Control Part. Part of SS7 signaling stack. Together with MTP, generically referred to as transport layer in this document. SMDPP SME SMS SMSDeliveryPointToPoint. ANSI-41 message that actually carries the subscribers SMS text.

Short Message Entity Short Message Service.

SMSC See MC SMSMWI SMSNOT SSN SMS Message Waiting Indicator SMSNotification. ANSI-41 message that reports a change in a mobiles ability to receive SMS.

SubSystem Number

TRANSCAP Transaction Capabilities VSWG Voice & SMS Working Group WEMT Wireless Enhanced Messaging Teleservice

Ref Doc 133, Ver 1.0

4 December 2006

34

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 focus on the MAP layer messaging between operator network elements. For more comprehensive and detailed scenarios, see ANSI-41.3-D 7.

I.1 Successful MT SMS


The message flow for a successful MT-SMS is shown below in Figure 1:
Home MC Home HLR
SMSREQ smsreq SMDPP smdpp

Serving MSC
a b c d e f

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 from another network, is outside the scope of this document. The MC queries the HLR to determine the current location of the mobile The HLR responds with an SMS_Address parameter, indicating the location of the destination mobile. The MC sends the message to the Serving MSC, using the ANSI-41 SMSDeliveryPointToPoint (SMDPP) operation. The message is delivered over the air, and acknowledged. The MSC returns a successful result to the MC

b) c) d) e) f)

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

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 scenarios are possible where this message is sent from the HLR (see following text).
Home MC Home HLR
SMSREQ smsreq SMDPP smdpp[SMS_CauseCode ]

Serving MSC
a b c d e f

smsnot SMDPP

SMSNOT

g h i j k l

smdpp

Figure 2. Postponed MT-SMS

a-d) e) f) g) h) i) j-k)

As per previous example The mobile is inaccessible (e.g. coverage hole), and the message is not delivered A return result with a postponed indication is returned to the MC, and the MSC sets a Delivery Pending Flag (DPF) for the mobile. Some time later, the serving network becomes aware that the mobile is available for SMS (e.g. mobile makes a timer-based registration) Due to the DPF, the MSC sends an SMSNotification to the RSP. The message is acknowledged The MC can now successfully deliver the message as per the previous scenario 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) is held: if the mobile is known by the HLR to be unavailable for SMS delivery (e.g. inactive, or roaming in a non SMS-capable MSC) then the HLR will respond to the SMSREQ with a postponed indication and set the SMSDPF. When the HLR learns that the mobile is again available (e.g. on registration in a SMScapable MSC), it will send SMSNOT to the MC. In the above example, the HLR believed that the mobile was available, thus the delivery attempt proceeded as far as the SMDPP to the serving MSC before

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

encountering problems in this case the SMSDPF resides at the MSC, and the MSC is responsible for sending the SMSNOT. The two cases are (very) roughly analogous to Call Forward No Answer: Inactive vs Call Forward No Answer: Ring No Reply in a voice scenario, although no actual SMS forwarding takes 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 a discussion about the advantages and disadvantages of Direct versus Indirect routing. The message flow is shown in Figure 3: Home MC
SMDPP smdpp

Home HLR

Serving MSC
a b c d

Figure 3. Indirect MO-SMS a) b) c) d) The mobile originates an SMS. Using indirect routing, the MSC sends the message to the Home MC of the originating mobile. The MC acknowledges a successful submission 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.

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

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 of the destination party, bypassing the originators MC. The message flow is shown in Figure 4: Roaming MS Home MC Serving Nwk MC
SMDPP smdpp SMDPP smdpp

Domestic MS in Serving Nwk

Serving MSC
a b c d e f g

Figure 4. Direct MO-SMS a) b) The roaming subscriber originates a SMS, intended for a domestic subscriber in the visited network. Since the routing method used is direct, the MSC analyzes the destination address received from the air interface and uses it to determine the MC address. In this case, the destination is a subscriber of the serving network, so the MSC sends SMDPP to the serving network MC. The MC returns smdpp. An air interface acknowledgement is provided to the originating MS. The MC (assumed here to already have a current SMS routing address for the destination MS), sends SMDPP to the MSC serving the destination mobile. The MSC delivers the message to the mobile, and the message is acknowledged. An smdpp is returned to the MC.

c) d) e) f) g)

I.5 Mobile-to-Mobile SMS


Mobile-to-mobile SMS can be viewed simply as a combination of MO and MT messages. If the 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 are roaming.

Appendix II - Additional Message Routing Options


II.1 Super-Indirect
The Super-Indirect message flow is a non-standard approach introduced in this document specifically to produce billing records in the serving network for MO-SMS. It routes all roamer-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 a possible solution to the billing requirements of the serving network, subject to the limitations discussed below. The impacts of this approach (as compared to a standard Indirect routing method) should be almost entirely restricted to the serving network. As this approach exists only on paper today, full systems engineering would be required before proceeding with implementation. The message flow is shown in Figure 5: Home MC Serving nwk MC
SMDPP smdpp SMDPP smdpp

Serving MSC
a b c d e f

Figure 5. Super-Indirect Routing for MO-SMS a) b) d) The mobile originates an SMS The serving MSC sends the SMS in an SMDPP to the serving network MC. The MSC considers neither originating nor destination address, merely routes all MO SMSs to its own MC The MC returns an smdpp acknowledging successful message submission, and an acknowledgement is made back to the mobile. By sending an acknowledgement at this point (and not after step f), the serving network MC is accepting the responsibility of ensuring reliable delivery to the home network MC. This approach is chosen to more closely match the behavior of currently deployed MCs, however it means that any information from the home MC (e.g. message rejected due to insufficient prepaid balance) could not be relayed to the originating mobile. The serving network MC determines that the originating mobile is not from its own network, and therefore ignores the destination address, and routes based on originating address to the Home MC.

e)

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

f)

The MC acknowledges receipt of the message with smdpp.

II.1.1 Billing Output


A CDR produced by the Home MC should be the same as that produced in the standard Indirect Routing scenario the true serving network may be impossible to 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, MCs do. Individual CDRs for SMS events could be easily produced by the serving network 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 have been misrouted to the MC. Care would be required with MSC configuration to ensure that SMS traffic could 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 case of an inbound roamer, and on destination address for a home subscriber, may exceed currently deployed MC capabilities. Despite the non-standard message routing in the serving network, to the home network the messaging should appear relatively normal. Some additional care may need to be given to the population of the various address parameters to ensure this is the case. Production of a CIBER record from the serving network MC CDR may be difficult, depending on the address parameters present in the SMDPP sent from the MSC to the MC. If (as has been observed for some networks) the MSC populates only the MDN in the originating address fields, the MSID would not be available at the MC for population in the CDR and subsequent CIBER record, where it is a mandatory field. As noted above, the smdpp transmission timing by the serving network MC may 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 may require additional modification to the serving network MC. The MC-to-MC leg need not use ANSI-41. Other approaches such as SMPP may also be used.

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

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

serving network MC (as compared with the Super-Indirect method), it treats the roaming subscriber in the same manner as a home subscriber of the serving network, which may represent a different set of services (and addressable destinations) than the roamer enjoys when at home. No real-world implementations of this method are currently known to exist it is shown as a possible solution to the billing requirements of the serving network, subject to the limitations discussed below. The message flow is shown in Figure 6: Home MC Home HLR Serving nwk MC
SMDPP smdpp

Serving MSC
a b c d

Figure 6. Local Service Routing for MO-SMS a) b) The mobile originates an SMS The MSC sends all SMSs, regardless of origination or destination address, to its own MC. The serving network MC processes the origination as if it were for a (provisionless) home subscriber in this network. smdpp and air interface acknowledgement are returned

c-d)

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

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations

Appendices

II.2.1 Discussion
Although the message flow looks similar to the Direct Routing scenario, the difference is that the MSC performs no analysis on the SMS address to determine the 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 network subscribers. All numbering plans are unchanged, as are available intercarrier SMS destinations and special short codes. The intercarrier destinations may be different to those available to the subscriber when at home, leading to customer confusion. In some cases, it may not be possible for the addressed party to respond. A key requirement for this arrangement to be viable would be intercarrier SMS between the serving and home networks, so the roamer could message others from his/her home network. While complementary to SMS roaming in this case, it is actually a separate piece of network connectivity to be achieved, and may make use of SMPP, SMTP or other transport options rather than ANSI-41. Care may be required with originating address information to ensure that a reply from the home network is routed via normal methods (i.e. MT-SMS roaming) rather than intercarrier to 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 for the Super-Indirect case, and potentially subject to the same issue of MSID availability. In the direct routing scenario, a major concern was the analysis of the destination address being 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 that destination analysis at a MC will prove more flexible than at a MSC.

S-ar putea să vă placă și