Documente Academic
Documente Profesional
Documente Cultură
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
Contents
4 December 2006
ii
4 December 2006
iii
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
4 December 2006
iv
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
4 December 2006
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
4 December 2006
vi
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
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
4 December 2006
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.
4 December 2006
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
4 December 2006
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).
4 December 2006
Signaling Issues
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.
4 December 2006
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.
4 December 2006
4 December 2006
4 December 2006
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.
4 December 2006
10
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.
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.
4 December 2006
12
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.
4 December 2006
13
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.
4 December 2006
14
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.
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.
4 December 2006
15
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
Signaling Issues
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.
4 December 2006
18
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.
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.
4 December 2006
19
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
4 December 2006
20
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.
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
4 December 2006
21
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.
4 December 2006
22
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.
(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:
4 December 2006
23
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.
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
4 December 2006
24
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.
4 December 2006
25
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)
4 December 2006
26
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.
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.
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
4 December 2006
29
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.
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.
4 December 2006
30
Signaling Issues
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
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.
4 December 2006
31
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.
4 December 2006
32
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
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.
4 December 2006
33
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.
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
4 December 2006
34
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)
Appendices
Serving MSC
a b c d e f
smsnot SMDPP
SMSNOT
g h i j k l
smdpp
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
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.
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.
Appendices
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)
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)
Appendices
f)
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.
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.