62098681 SMS Roaming White Paper

8/4/2019 62098681 SMS Roaming White Paper

1/49

SMS Roaming: Billing and Signaling

Requirements, Options andRecommendations

CDG Document 133

Version 1.0

4 December 2006

CDMA Development Group575 Anton Boulevard, Suite 560Costa Mesa, California 92626PHONE +1 888 800-CDMA

+1 714 545-5211FAX +1 714 545-4601

http://[email protected]

Notice

Each CDG member acknowledges that CDG does not review thedisclosures or contributions of any CDG member nor does CDG verifythe status of the ownership of any of the intellectual property rightsassociated with any such disclosures or contributions. Accordingly, each
http://www.cdg.org/mailto:[email protected]://www.cdg.org/mailto:[email protected]


2/49

SMS Roaming: Billing and Signaling Requirements, Options and Recommendations Contents

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

Ref Doc 133, Ver 1.0 4 December 2006 ii


3/49

Ref Doc 133, Ver 1.0 4 December 2006 iii


4/49

SMS Roaming: Billing and SignalingRequirements, Options and Recommendations

Contents

Revision History

Version Date Reason0.1 2005-12-25 Initial version

0.2 2006-01-11 Updated following internal review0.3 2006-01-13 Added transport layer ID for serving network, other

minor updates0.4 2006-01-27 Restructure and update0.5 2006-08-15 Update for VSWG progress0.6 2006-09-25 Minor updates post-IRT0.7 2006-11-21 Minor updates following conference call1.0 2006-12-04 Release version. No change from previous

Ref Doc 133, Ver 1.0 4 December 2006 iv


5/49


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 ............................................................................... ..... ...95.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 v


6/49


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 ........................................177. 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


7/49


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...................................................................................40II.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..........................................................................................................38Figure 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


8/49

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 domesticSMS 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 1


9/49


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 ANSI-41.

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

Wireless Number Portability.

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


10/49

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-and-

keep 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 MT-

SMS.

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



11/49


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 alternativebilling 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.



12/49


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 itsnetwork, 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 forthemselves 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 web-

based 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 anaudit function).



13/49

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.



14/49


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. Signalingmodifications to enable MC CDR billing are undergoing specification by the

VSWG.



15/49

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 notpurchased 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.



16/49

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 networkentities 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



17/49


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 maybe 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 ClearinghouseEither 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 toconnect 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



18/49


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 notprovide a valid

solution for SMS Roaming (with a possible exception in a theoretical, non-standard

solution described in II.)



19/49

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 ProbesRather 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.



20/49


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, aswell 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, itmay 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. (Apossible 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:



21/49


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 notpossible 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 inmore 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 CDR-

based) SMS billing flow.



22/49


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 becaptured 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 valuewhen 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 servingnetwork. 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 billing 1. Using this record forroaming 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 disabledand domestic (as well as inbound roaming) SMS charged from the MSC CDR.



23/49


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 requirethe 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.



24/49


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 MT-

SMS) 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.



25/49

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 thelack 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 aunique 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.



26/49


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 per-

message 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 inthe 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 IdentifierIn 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.



27/49


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 theSMDPP 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 senderslocation 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



28/49


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 commoncapability 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 networkMCC/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



29/49


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 usedinstead 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 14-

bit 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 theMC 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 operator-

level 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.

http://210.54.118.1/mediawiki-1.5.3/images/7/7b/SMS_Signaling_for_Roaming_Billing.dochttp://210.54.118.1/mediawiki-1.5.3/images/7/7b/SMS_Signaling_for_Roaming_Billing.doc


30/49


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 homenetwork 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 ANSI-41-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:



31/49


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

5Set to MC PC/GTA in X.S0004-641-E v1.0 4.5 step 2. Later omitted based on X.S0004-641-E v1.03.2 step 9.

6Set 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

7X.S0004-641-E v1.0 4.6 step 9, & X.S0004-540-E v1.0 2.61 Note a

8X.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 usedinstead. C.S0015-B_v2.0_051006 2.4.2.1.1.1 says "The mobile station address shall be determinedfrom 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 tofind the MDN

9X.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, theMIN 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 64.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

11X.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.03.6 step 1-7-1. X.S0004-641-E v1.0 3.6 step 1-13-1



32/49


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-to-

MC 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 LengthProblems 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)14apply, 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.

A2003 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 MessageSignal Unit, but will fit in an air interface PDU, can be successfully transferred in this

manner. As anestimate15, 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

14C.S0004-0 v1.0 2.2.1.2.2 & 3.2.2.2.2

http://www.cdg.org/members_only/teams/IntRoaming/docs/030924/20030924-2D-SurveySummary-KDDI.xlshttp://www.cdg.org/members_only/teams/IntRoaming/docs/030924/20030924-2D-SurveySummary-KDDI.xlshttp://210.54.118.1/wiki/SMS_Maximum_Lengthshttp://210.54.118.1/wiki/SMS_Maximum_Lengthshttp://www.cdg.org/members_only/teams/IntRoaming/docs/030924/20030924-2D-SurveySummary-KDDI.xlshttp://210.54.118.1/wiki/SMS_Maximum_Lengths


33/49


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 thesubscriber 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 istransferred to the MC, then the operator can avoid sending segmented messages to

roaming partners. The specific action to be taken by the MC16if 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)



34/49


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 isless 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 theMESSAGE_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 non-

segmented message delivery is being attempted. The differing operator limits, and

http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-581.ziphttp://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-581.zip


35/49


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 amessage 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 MSCNote 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 thatthe 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 SMSThe 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).



36/49


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 message 17

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 wouldnot 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



37/49


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 analysistables 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 s

Documents

62098681 SMS Roaming White Paper