plus code dialing requirements

7/30/2019 Plus Code Dialing Requirements

http://slidepdf.com/reader/full/plus-code-dialing-requirements 1/44

Plus Code Dialing Requirements

CDG Document 145

Version 1.1

2007-09-17

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, eachCDG member should consider all disclosures and contributions as beingmade solely on an as-is basis. If any CDG member makes any use of any disclosure or contribution, then such use is at such CDG member'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 of

http://www.cdg.org/

mailto:[email protected]

http://www.cdg.org/

mailto:[email protected]




any disclosure or contribution, including any liability arising out of infringement of intellectual property rights.

Ref Doc. 145, Ver. 1.1 2007-09-17




<page left blank intentionally>

Ref Doc. 145, Ver. 1.1 2007-09-17




Contents

Plus Code Dialing Requirements.................................................................................................i

CDG Document 145...................................................................................................................... i

Version 1.1..................................................................................................................................... i

2007-09-17...................................................................................................................................... i

1. Introduction.............................................................................................................................. 1

1.1Definition............................................................................................................................ 1

1.1Definition............................................................................................................................ 1

1.2Standards Support............................................................................................................. 1

1.2Standards Support............................................................................................................. 1

1.3Minimum Requirements.............................................................................................. ....... 2

1.3Minimum Requirements.............................................................................................. ....... 2

1.4Acronyms and Abbreviations..............................................................................................2

1.4Acronyms and Abbreviations..............................................................................................2

Mobile Station Requirements......................................................................................................4

2.1Origination..........................................................................................................................4

2.1Origination..........................................................................................................................4

2.1.1Voice....................................................................................................................42.1.2SMS..................................................................................................................... 7

2.2Termination........................................................................................................................ 9

2.2Termination........................................................................................................................ 9

2.2.1Voice....................................................................................................................9

2.2.2SMS................................................................................................................... 11

2.3Interface to the R-UIM/CSIM............................................................................................ 15

2.3Interface to the R-UIM/CSIM............................................................................................ 15

2. MSC Requirements................................................................................................................16

2.4Origination........................................................................................................................16

2.4Origination........................................................................................................................16

2.4.1Voice..................................................................................................................16

2.4.2SMS................................................................................................................... 21

2.5Termination...................................................................................................................... 25

2.5Termination...................................................................................................................... 25

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements Contents

2.5.1Voice..................................................................................................................25

2.5.2SMS................................................................................................................... 26

3. HLR/SCP Requirements........................................................................................................ 27

2.6Origination........................................................................................................................27

2.6Origination........................................................................................................................272.7Termination...................................................................................................................... 28

2.7Termination...................................................................................................................... 28

2.7.1Voice..................................................................................................................28

2.7.2SMS................................................................................................................... 28

4. MC Requirements...................................................................................................................30

2.8Origination........................................................................................................................30

2.8Origination........................................................................................................................30

2.9Termination...................................................................................................................... 32

2.9Termination...................................................................................................................... 32

5. Appendix – Call Flow Diagrams............................................................................................37

2.10SMS Scenarios...............................................................................................................37

2.10SMS Scenarios...............................................................................................................37

2.11Voice Scenarios............................................................................................................. 38

2.11Voice Scenarios............................................................................................................. 38

Revision History

Date Version Description

10 October 2006 0.1 Initial release

2 January 2007 0.2Updated following Nov 06 IRT, minimumrequirements identified

2 March 2007 0.3Updated following conference call and teamfeedback

9 April 2007 0.4Update to CDG Format and incorporate

changes from conference call

13 June 2007 0.5 Update following VSWG review period

27 August 2007 0.6Clarifications to SMS, remove MMS, added

Appendix

12 September 2007 1.0 Approval version, no text change from v0.6

17 September 2007 1.1 Additional minor clarifications

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements Contents

Ref Doc. 145, Ver. 1.1 2007-09-17




1. Introduction

Plus Code Dialing (PCD) is a capability of high interest to operator members of the

International Roaming Team (IRT) of the CDMA Development Group (CDG).

This document aims to state the technical requirements on both the MS and various

network elements to allow a consistent, interoperable implementation.

Requirements are listed below as they apply to each element. They are further divided

where appropriate as relating to Voice or SMS, and origination or termination. In some

cases a requirement in a particular section may have applicability to other scenarios.

1.1 Definition(from 3GPP2 C.S0005-C v1.0)

Plus code dialing relieves the user of the need to dial an international access

prefix, which may vary between countries and carriers. This capability allows

telephony addresses to be entered, received, displayed, stored and transmitted

in an international format (full ITU-T E.164 number, including country code).

When addresses are entered by a user, the MS user interface can provide an

input aid, such as a key marked with a “+” sign, to indicate that the address is

international. When displayed by the MS, they can be identified by a visual

device, such as a “+” prefix. When received, transmitted or stored, an

international indicator can be included with the address digits. It will be theresponsibility of the network to ignore the international indicator when attached to

a national number. This allows users to store and dial all phone numbers in a

consistent format, which is particularly useful for international travelers.

Within the IRT, the features described above are referred to as “network-based PCD” to

distinguish them from other approaches to achieve a similar end-user experience. This

document only addresses network-based PCD.

1.2 Standards Support

The requirements in this document are based primarily on the capabilities offered by IS-

2000 Rel 0. Other standards referenced are IS-875 and IS-637.

IS-2000 Revision C version 2, and Revision D make some modifications to PCD

procedures (most notably allowing the inclusion of NUMBER_TYPE when DIGIT_MODE

is set to 0). However, given the lack of commercialization of Rev Cv2/D-compliant

devices or network equipment, these changes are not discussed further, and are not

incorporated in the requirements below.

Ref Doc. 145, Ver. 1.1 2007-09-17

http://www.3gpp2.org/Public_html/specs/C.S0005-0_v3.0.pdf



http://www.3gpp2.org/Public_html/specs/NS0027.pdf


http://www.3gpp2.org/Public_html/SC/C.S0015-B_v2.0_051006.pdf




http://www.3gpp2.org/Public_html/SC/C.S0015-B_v2.0_051006.pdf



Plus Code Dialing Requirements Introduction

From the MS standpoint, these requirements are intended to expand upon, and be

consistent with CDG reference document #90: Global Handset Requirements for CDMA

(GHRC) CDMA2000 Voice, SMS and Data, Ver 2.0.

1.3 Minimum Requirements

At the November 2006 IRT meeting, a suggestion was made to identify a minimum set of interoperable requirements, in an attempt to minimize expected development costs. Of

the requirements shown below, those that are suggested to make up the minimum set

are distinguished by the use of “shall” rather than “may” or “should” in the requirement

wording. The requirement number is also shaded green.

The primary objective for the minimum requirements set is to allow subscribers to

originate voice calls and SMS messages using the “plus code dialing” format (equated in

this document to “internationally-formatted”).

In particular, all requirements relating to the presentation of an internationally-formatted

Calling Party Number (for voice) or Originating Address (for SMS) have been omitted

from the minimum set, due to the difficulty of determining, in advance, whether aparticular MS can successfully receive and process internationally-formatted numbers.

1.4 Acronyms and Abbreviations

Term Meaning

ANLYZD AnalyzedInformation

BCD Binary Coded Decimal

BSC Base Station Controller

BTS Base Transceiver/Transmitter Station

CDG CDMA Development Group

CNIR Calling Number Information Restriction

CONNRES ConnectResource

CPNS CallingPartyNumberString

CSIM cdma2000 Subscriber Identity Module

GHRC Global Handset Requirements for CDMA

HLR Home Location Register

IAC+CC International Access Code + Country Code

IAM Initial Address Message

IP International Prefix (aka International Access Code)

IRT International Roaming TeamISDN Integrated Services Digital Network

ISUP ISDN User Part

ITU-T International Telecommunications Union-Telecommunications sector

MC Message Center

MCC Mobile Country Code

MDN Mobile Directory Number

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements Introduction

Term Meaning

ME Mobile Equipment

MO Mobile-Originated

MMS Multimedia Messaging Service

MS Mobile Station

MSC Mobile Switching Center

MSID Mobile Station Identifier

MT Mobile-Terminated

NAM Number Assignment Module

NPI Numbering Plan Identification

ODA Original Destination Address

OMA Open Mobile Alliance

ORREQ OriginationRequest

PCD Plus Code Dialing

R-UIM Removable User Identity Module

SCP Service Control Point

SMDPP SMSDeliveryPointToPoint

SMPP Short Message Peer-to-Peer

SMS Short Message Service

SMSADDR SMS_Address

SMSREQ SMSRequest

TON Type of Number

tranumreq TransferToNumberRequest RETURN RESULT

VLR Visitor Location Register WAP Wireless Application Protocol

Ref Doc. 145, Ver. 1.1 2007-09-17




Mobile Station Requirements

2.1 Origination

2.1.1 Voice

Requirement Number 2.1.1-010Requirement The MS shall provide a plus key or equivalent user interface

convention to allow PCD.

Standards Reference N.S0027 (“TIA/EIA-664-701-A MODIFICATIONS” chapter) §1.1.

Comments Individual operators may wish to specify the entry method in moredetail, e.g. double-press of “*” key. The input method shall beapplicable to all instances of digit entry, e.g. call origination,phonebook entry, SMS destination, and SMS Call-Back Number.

Requirement Number 2.1.1-020Requirement The MS shall support phonebook storage and subsequent retrieval

of digits with an international indication, regardless of the source of the digits (e.g. user entry, caller display, and SMS Origination

Address).

Standards Reference N.S0027 (“TIA/EIA-664-701-A MODIFICATIONS” chapter) §1.18

Comments

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements Mobile Station Requirements

Requirement Number 2.1.1-030Requirement The MS shall support transmission of the dialed digits in ASCII mode

for internationally-dialed voice calls (Origination Message).

Standards Reference C.S0005-0 v3.0 §2.7.1.3.2.4

Comments The NUMBER_TYPE field (required for indicating the internationalnature of the call) may only be included when DIGIT_MODE = 1,which signifies that the dialed digits are 8-bit ASCII codes. Use of the

ASCII mode is only required (in this document) for calls dialed usingthe “plus key” or equivalent as described above – existing calls areunchanged.

Requirement Number 2.1.1-040Requirement The MS shall support setting the NUMBER_TYPE to “International

number” for internationally-dialed voice calls.


Comments This is the central requirement for PCD.

Requirement Number 2.1.1-050Requirement The MS shall support setting the NUMBER_PLAN to either

“ISDN/Telephony” or “Unknown” for internationally-dialed voice calls.


Comments The preferred value is “ISDN/Telephony”, however use of the “pluskey” implies that an E.164-formatted digit string follows, therefore theinterpretation is clear even if “Unknown” is used..

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.1.1-060Requirement The MS shall support use of the Origination Continuation Message if

all the dialed digits cannot be included in the Origination Message.

Standards Reference C.S0005-0 v3.0 §§2.6.3.5 & 2.6.4.4

Comments Use of 8-bit encoding for the dialed digits increases message size,potentially exceeding the maximum Access Channel messagecapsule size. In this case the MS shall set MORE_FIELDS in theOrigination Message to 1 and include the remaining digits in theOrigination Continuation Message.

Requirement Number 2.1.1-070Requirement The MS shall not transmit an ASCII “+” character in the dialed digits

for internationally-dialed voice calls.

Standards Reference

Comments The international nature of the digit string is conveyed by the

NUMBER_TYPE field set appropriately. An ASCII “+” is redundant.This may be further inferred by the possibility (in IS-2000 Rev D) of including NUMBER_TYPE when DIGIT_MODE is set to 0, and thestatement “Prefix or escape digits shall not be included” (in A.S0014-C and T1.607) when the called party number is set to International.

Requirement Number 2.1.1-080Requirement The MS should allow international dialing even when the dialed digit

string includes overdecadic digits (i.e. * and/or #).

Standards Reference

Comments A legitimate scenario is when a user attempts to set up callforwarding to a destination number in international format (even

though in most CDMA networks today the use of theRedirectionRequest operation means forwarding can be performedwithout the use of the international format) .

Requirement Number 2.1.1-090Requirement The MS should allow international dialing when the user enters the +

symbol anywhere in the digit string (and not just at the start).

Standards Reference

Comments For the “forwarding to international number” scenario described above, or a CNIR temporary activation call to an internationalnumber, the user may enter a digit string such as“*90+12125551212”. Since the + symbol is not transmitted explicitly

(see 2.1.1-070), the content of the resulting Origination Message isindependent of the placement of the + in the user-entered digits.

Requirement Number 2.1.1-100Requirement The MS is not required to support PCD for the second leg of a 3-way

call.

Standards Reference C.S0005-0 v3.0 §2.6.4.4 & 2.7.4.2

Comments Dialed digits for the second leg are carried in the Keypad Facility

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.1.1-100information record. This record does not define a means to indicatethat the digits it contains are in international format. (Use of an ASCII“+” symbol for this scenario is rejected for complexity.)

2.1.2 SMS

Requirement Number 2.1.2-010Requirement The MS shall support transmission of the Destination Address

parameter in ASCII mode for internationally-addressed textmessages.

Standards Reference C.S0015-B v2.0 §3.4.3.3 & C.S0005-0 v3.0 §2.7.1.3.2.4

Comments The address formatting for SMS is similar to that for the dialed digitsin the Origination Message.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.1.2-020Requirement The MS shall support setting the Destination Address

NUMBER_TYPE to “International number” for internationally-addressed text messages.


Comments With DIGIT_MODE set to 1, NUMBER_MODE set to 0,NUMBER_TYPE is set to 001 (binary).

Requirement Number 2.1.2-030Requirement The MS shall support setting the Destination Address

NUMBER_PLAN to either “ISDN/Telephony” or “Unknown” for internationally-addressed text messages.


Comments As with voice.

Requirement Number 2.1.2-040Requirement The MS should support transmission of the Call-Back Number sub-

parameter digits in ASCII mode when internationally formatted.

Standards Reference C.S0015-B v2.0 §4.5.15 & C.S0005-0 v3.0 §2.7.1.3.2.4

Comments When non-international digits are sent in this sub-parameter, ASCIIencoding is not required. If a default Call-Back Number is stored inthe MS independently of the MDN, it shall be possible for thisnumber to be in international format. (C.S0005-0 v3.0 §2.3.1.4 doesnot imply that the MDN NAM indicator itself can be stored ininternational format, although this may be possible when an R-UIM isused – see 2.3-020.)

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.1.2-050Requirement The MS should support setting the Call-Back Number sub-parameter

NUMBER_TYPE to “International number” when the Call-BackNumber is internationally formatted.

Standards Reference C.S0015-B v2.0 §4.5.15 & C.S0005-0 v3.0 §2.7.1.3.2.4.

Comments

Requirement Number 2.1.2-060Requirement The MS should support setting the Call-Back Number sub-parameter

NUMBER_PLAN to “ISDN/Telephony” when the Call-Back Number is internationally formatted.

Standards Reference C.S0015-B v2.0 §4.5.15 & C.S0005-0 v3.0 §2.7.1.3.2.4.

Comments

2.2 Termination

2.2.1 Voice

Requirement Number 2.2.1-010Requirement The MS should accept an internationally-formatted Calling Party

Number information record for an incoming voice call.

Standards Reference C.S0005-0 v3.0 §§ 3.7.5.3 & 2.7.1.3.2.4

Comments NUMBER_TYPE is “International number”. This requirement appliesboth to voice calls received when idle and incoming call waiting calls.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.2.1-020Requirement The MS should accept as internationally-formatted a Calling Party

Number with NUMBER_TYPE = “International number” andNUMBER_PLAN set to either “Unknown” or “ISDN/Telephony.”

Standards Reference C.S0005-0 v3.0 §§ 3.7.5.3 & 2.7.1.3.2.4.

Comments The preferred value is “ISDN/Telephony,” however theNUMBER_TYPE value is sufficient to allow equivalent treatment for an “Unknown” NUMBER_PLAN.

Requirement Number 2.2.1-030Requirement The MS should present a received internationally-formatted Calling

Party Number to the subscriber with a leading “+” symbol.

Standards Reference N.S0027, “TIA/EIA-664-508-A MODIFICATIONS” chapter §1 &“TIA/EIA-664-701-A MODIFICATIONS” chapter §1.8.3.

Comments

Requirement Number 2.2.1-040Requirement The MS should match a received internationally-formatted Calling

Party Number to a corresponding phonebook entry.

Standards Reference

Comments For example, to display the stored name of the caller. If the MSallows a partial match, this may optionally be extended to includematching between international and non-international numbers.Partial matching may be especially desirable with plus code, e.g.matching a presented non-international calling party number with theequivalent international format phonebook entry.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.2.1-050Requirement The MS should ignore an ASCII “+” symbol received in an

international Calling Party Number.

Standards Reference

Comments The MS should not display “++” for a number received in this format.This requirement should not impede the MS from handling non-numeric ASCII characters in the Calling Party Number whenNUMBER_TYPE is not set to “International number.”

2.2.2 SMS

Requirement Number 2.2.2-010Requirement The MS should accept an Originating Address parameter coded in

ASCII mode when receiving an SMS.


Comments

Requirement Number 2.2.2-020Requirement The MS should accept an Originating Address parameter with

NUMBER_TYPE = “International number” when receiving an SMS.


Comments

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.2.2-030Requirement The MS should present a received internationally-formatted

Originating Address parameter to the subscriber with a leading “+”symbol.

Standards Reference

Comments

Requirement Number 2.2.2-040Requirement The MS should match a received internationally-formatted

Originating Address parameter to a corresponding phonebook entry.

Standards Reference

Comments Includes partial match as above.

Requirement Number 2.2.2-050

Requirement The MS should ignore an ASCII “+” symbol received in aninternational Originating Address parameter.

Standards Reference

Comments The MS should not display “++” for a number received in this format.This requirement should not impede the MS from handling non-numeric ASCII characters in the Originating Address parameter when NUMBER_TYPE is not set to “International number.”

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.2.2-060Requirement The MS should recognize a “+” character as an international

identifier when prefixed to digits in the body of the message for number extraction.

Standards Reference

Comments If the MS supports “one-touch” dialing to a number contained in thebody of the text message (e.g. “please call John 2125551234 toarrange meeting”), then a “+” prefix should be recognized asdesignating an international number, e.g. “please call John+12125551234 …”. This requirement applies to all character encoding methods that the MS supports.

Requirement Number 2.2.2-070Requirement The MS should accept a Call-Back Number sub-parameter coded in

ASCII mode when receiving an SMS.

Standards Reference C.S0015-B v2.0 §4.5.15 & C.S0005-0 v3.0 §2.7.1.3.2.4Comments

Requirement Number 2.2.2-080Requirement The MS should accept a Call-Back Number sub-parameter with

NUMBER_TYPE = “International number” when receiving an SMS.

Standards Reference C.S0015-B v2.0 §4.5.15 & C.S0005-0 v3.0 §2.7.1.3.2.4

Comments

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.2.2-090Requirement The MS should present a received internationally-formatted Call-

Back Number sub-parameter to the subscriber with a leading “+”symbol.

Standards Reference

Comments

Requirement Number 2.2.2-100Requirement The MS should match a received internationally-formatted Call-Back

Number sub-parameter to a corresponding phonebook entry.

Standards Reference

Comments Includes partial match as above.


Requirement The MS should ignore an ASCII “+” symbol received in aninternational Call-Back Number sub-parameter.

Standards Reference

Comments The MS shall not display “++” for a number received in this format.This requirement should not impede the MS from handling non-numeric ASCII characters in the Call-Back Number sub-parameter when NUMBER_TYPE is not set to “International number.”

Ref Doc. 145, Ver. 1.1 2007-09-17




2.3 Interface to the R-UIM/CSIM

The following requirements apply only if the handset is implemented as Mobile

Equipment with an R-UIM or CSIM.

Requirement Number 2.3-010Requirement The ME shall have the capability to store and retrieve internationally-

formatted numbers to/from the R-UIM/CSIM.

Standards Reference C.S0065-0 v1.0 (various sections), and 3GPP 24.008 v6.13.0§10.5.4.7

Comments The READ and UPDATE commands to various Elementary Files(e.g. EF ADN, EFFDN, EFSDN, EF ANR, EFICI, EFOCI shall allow for Type of number (TON) = “international number” and Numbering PlanIdentification (NPI) = “ISDN/telephony”.

Requirement Number 2.3-020

Requirement The ME should have the capability to store and retrieve the MDNto/from the R-UIM/CSIM in international format.

Standards Reference C.S0065-0 v1.0 §5.2.35 & C.S0005-0 v3.0 §2.7.1.3.2.4

Comments NUMBER_TYPE and NUMBER_PLAN set as per 2.1.1-040 & 2.1.1-040 respectively.

Requirement Number 2.3-030Requirement The ME should have the capability to store and retrieve the default

SMS Destination Address to/from the R-UIM/CSIM in internationalformat.

Standards Reference C.S0065-0 v1.0 §5.2.29 & C.S0015-B v2.0 §3.4.3.3

Comments Default Destination Address is stored in EFSMSP.

Ref Doc. 145, Ver. 1.1 2007-09-17




2. MSC Requirements

This section also includes BSC/BTS requirements. Except where specified (e.g. for A-

interface requirements) the MSC is assumed to incorporate the BSC/BTS.

2.4 Origination

2.4.1 Voice

Requirement Number 2.4.1-010Requirement The MSC shall support receipt of the Origination Message with

dialed digits (Origination Message CHARi) in ASCII mode for internationally-dialed voice calls.


Comments The NUMBER_TYPE field (required for indicating the internationalnature of the call) may only be included when DIGIT_MODE = 1,which signifies that the dialed digits are 8-bit ASCII codes. Use of the

ASCII mode is only required (in this document) for calls dialed usingthe MS “plus key” or equivalent – existing calls are unchanged.

Requirement Number 2.4.1-020Requirement The MSC shall support receipt of the NUMBER_TYPE, set to

“International number” for internationally-dialed voice calls.

Standards Reference C.S0005-0 v3.0 §2.7.1.3.2.4Comments This is the central requirement for PCD.

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements MSC Requirements

Requirement Number 2.4.1-030Requirement The MSC shall support receipt of the NUMBER_PLAN set to

“ISDN/Telephony” or “Unknown” for internationally-dialed voice calls.


Comments The preferred value is “ISDN/Telephony,” however theNUMBER_TYPE value is sufficient to allow equivalent treatment for an “Unknown” NUMBER_PLAN.

Requirement Number 2.4.1-040Requirement The MSC shall support an international-format origination to a

destination in the same E.164 country as the MSC.

Standards Reference N.S0027 (“TIA/EIA-41.6-D MODIFICATIONS” chapter) §3.2.3

Comments This is particularly useful for the home network, as the subscriber can store all their phonebook entries in the international format evenwhen not roaming.

Requirement Number 2.4.1-050Requirement The MSC should support use of the Origination Continuation

Message to carry dialed digits that could not be included in theOrigination Message.

Standards Reference C.S0005-0 v3.0 §§2.6.3.5 & 2.6.4.4

Comments Use of 8-bit encoding for the dialed digits increases message size,potentially exceeding the maximum Access Channel messagecapsule size. In this case the MS sets MORE_FIELDS in theOrigination Message to 1 and includes the remaining digits in theOrigination Continuation Message.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.1-060Requirement The MSC should accept and ignore a leading ASCII “+” in the dialed

digits when the NUMBER_TYPE is set to “International number.”

Standards Reference

Comments The international nature of the digit string is conveyed by theNUMBER_TYPE field set appropriately: an ASCII “+” is redundant.However, some MSs may include this character. The MSC maydelete this character before any further processing of the digit string.This requirement should not impede the MSC from handling non-numeric ASCII characters in the dialed digits when NUMBER_TYPEis not set to “International number.”

Requirement Number 2.4.1-070Requirement The BSC shall transmit the called party number to the MSC in

international format for a received internationally-dialed voice call.

Standards Reference A.S0014-C v2.0 §§3.1.2 & 4.2.59Comments The Called Party ASCII Number field is used with Type of Number and Numbering Plan Identification fields set appropriately.

Requirement Number 2.4.1-080Requirement The MSC is not required to support PCD for the second leg of a 3-

way call.

Standards Reference C.S0005-0 v3.0 §2.6.4.4 & 2.7.4.2

Comments Dialed digits for the second leg are carried in the Keypad Facilityinformation record. This record does not define a means to indicatethat the digits it contains are in international format. (Use of an ASCII“+” symbol is rejected for complexity.)

Requirement Number 2.4.1-090Requirement [Note: An alternative to this requirement is shown below.] The MSC

should offer two options for onward signaling of the dialeddigits/destination number: retaining the international indication, andremoving the indication but prefixing the correct International Prefix(aka International Access Code) for the MSC service area.

Standards Reference

Comments This requirement applies both to trunk interfaces (e.g. the CalledParty Number Nature of Address in an ISUP IAM) and to ANSI-41(e.g. Digits (Dialed) Nature of Number in OriginationRequest Invoke).Replacing the international indicator with the International Prefix

digits removes the need for any downstream network elements to beaware of PCD. This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefixif a number in the serving country is dialed in plus code format. Caremay be required with some ANSI-41 operations (see 2.4.1-110 & 2.4.1-120). The option to replace the international indicator with theInternational Prefix does not apply to theSMS_OriginalDestinationAddress for MO-SMS (see 2.4.2-040). In allcases there is no requirement for a change to the outward signaling

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.1-090protocol – e.g. the dialed digits may be required to be converted toBCD format to comply.

Requirement Number 2.4.1-090a Requirement [Note: This requirement is an alternative to 3.1.1.-090 shown above.

090a represents more basic functionality than the full flexibility of 090.] The MSC shall populate the dialed digits/destination number information in onward signaling as if the subscriber explicitly dialedthe International Prefix.

Standards Reference

Comments This requirement applies both to trunk interfaces (e.g. the CalledParty Number Nature of Address in an ISUP IAM) and to ANSI-41(e.g. Digits (Dialed) Nature of Number in OriginationRequest Invoke).Replacing the international indicator with the International Prefixdigits removes the need for any downstream network elements to beaware of PCD. This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefixif a number in the serving country is dialed in plus code format. This

requirement does not apply to the SMS_OriginalDestinationAddressfor MO-SMS (see 2.4.2-040). In all cases there is no requirement for a change to the outward signaling protocol – e.g. the dialed digitsmay be required to be converted to BCD format to comply.

Requirement Number 2.4.1-100Requirement The MSC shall use any available preferred international carrier

information for the subscriber (e.g. CarrierDigits received in the ANSI-41 subscriber profile) when processing internationally-formatted calls, in accordance with existing preferred carrier handling.

Standards Reference

Comments If the subscriber has a specified international carrier preference, thena call dialed using the plus code must be routed to this carrier (provided the MSC otherwise honors Preferred Carrier informationwhen no carrier prefix is explicitly dialed). If the MSC retains theinternational indication in the out-dialed call, it shall also includeinformation (e.g. Transit Network Selection, Carrier Identificationparameters) to allow the receiving network to pass the call to theappropriate carrier. If the MSC replaces the international indicationwith the International Prefix, it may use a carrier-specific prefix, or include carrier information in separate parameters as describedabove, depending on implementation requirements. In either casethe choice of outgoing route may also be affected. Note that use of CarrierDigits is only specified in ANSI-41 for national use – i.e. while

the subscriber is within their home country.

Requirement Number 2.4.1-110Requirement The MSC should accept and process an international-format

origination which results in a FeatureRequest.

Standards Reference

Comments A legitimate scenario is when a user attempts to set up callforwarding to a destination number in international format (eventhough in most CDMA networks today the use of the

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.1-110RedirectionRequest operation means forwarding can be performedwithout the use of the international format). If the internationalindicator is retained in the FEATREQ no special handling is required.If however the MSC prefers to replace the international indicationwith the International Prefix digits (see 2.4.1-090), it must do so after

the feature code: e.g. the received international format string*90 52 xxxxxxxxxxshould be translated (in a country where the

International Prefix is 011) to *90 011 52 xxxxxxxxxx, not

011 *90 52 xxxxxxxxxx. Depending on existing MSC

capabilities, individual operators may have defined feature codes of a different length to the typical “*XX” format.

Requirement Number 2.4.1-120Requirement The MSC should accept and process an international-format

origination that includes a locally-handled service prefix.

Standards Reference

Comments An example is CNIR temporary (i.e. per-call) deactivation. If the MSC

retains the international indicator in the outgoing ISUP message, nospecial handling is required. If however the MSC prefers to replacethe international indication with the International Prefix digits, it mustdo so in such a way that both the service code and the user-intendedinternational nature of the resulting call are unaffected. For example,if the digit string [CNIR prefix] 52 xxxxxxxxxxis received with

an international indication in a country where the International Prefixis 011, a possible approach is to remove the international indicationand modify the digit string to [CNIR prefix] 011

52 xxxxxxxxxx. Alternatively, the CNIR prefix could be processed

and removed, then the international indication could be removed andreplaced with an 011 prefix to the remaining digits. Immediatelyreplacing the international indication with 011 to give a digit string of

011 [CNIR prefix] 52 xxxxxxxxxxhowever is unlikely toachieve the subscriber’s intended result.

Requirement Number 2.4.1-130Requirement [Note: An alternative to this requirement is shown below.] The MSC

should offer two options for population of a Call Detail Record:including an indication that PCD was used; and prefixing the dialeddigits with the correct International Prefix for the MSC service area(i.e. no changes to existing CDR). This approach may also beextended to removal of the serving network Country Code, andprefixing of a national prefix if a number in the serving country isdialed in plus code format.

Standards Reference

Comments This allows operators the choice to either track the incidence of PCDin their network, or to avoid any downstream billing system impacts.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.1-130a Requirement [Note: This requirement is an alternative to 31.1.-130 shown above.

130a represents more basic functionality than the full flexibility of 130.] The MSC shall populate the Call Detail Record exactly as itdoes today for non-PCD calls, i.e. as if the subscriber explicitly dialedthe International Prefix. This approach may also be extended toremoval of the serving network Country Code, and prefixing of anational prefix if a number in the serving country is dialed in pluscode format.

Standards Reference

Comments This allows operators to avoid any downstream billing systemimpacts.

Requirement Number 2.4.1-140Requirement The MSC should support the receipt of an internationally-formatted

Mobile Directory Number (MDN) in the subscriber profile.Standards Reference N.S0016-0 v1.0 Ch4 §6.4.2.37

Comments Nature of Number is set to International. BCD digits contain the fullE.164 string. This requirement is to allow presentation of the callingparty in “plus format” for a mobile-originated call.

Requirement Number 2.4.1-150Requirement The MSC should retain the international indicator for an MDN when

used for onward signaling.

Standards Reference

Comments This requirement applies both to trunk interfaces (e.g. Calling PartyNumber Nature of Address in ISUP IAM) and to ANSI-41 (e.g.

LocationRequest/OriginationRequest CallingPartyNumberDigits1,MobileDirectoryNumber).

Requirement Number 2.4.1-160Requirement If the MSC receives a call attempt containing both an international

indication, and digits which normally result in an international call, theentered digits should take precedence.

Standards Reference

Comments Possible examples include the standard International Prefix, aninternational-carrier identification string, or an international operator prefix.

2.4.2 SMS

In the following requirements, the use of Indirect Routing for SMS (i.e. via the

Originator’s MC) is assumed.

Requirement Number 2.4.2-010Requirement The MSC shall support the receipt of the air interface Destination

Address parameter in ASCII mode for internationally-addressed text

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.2-010messages.


Comments The address formatting for SMS is similar to that for the dialed digitsin the Origination Message.

Requirement Number 2.4.2-020Requirement The MSC shall support receipt of the Destination Address with

NUMBER_TYPE set to “International number” for internationally-addressed text messages.


Comments With DIGIT_MODE set to 1 and NUMBER_MODE set to 0,NUMBER_TYPE is set to 001 (binary).

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.2-030Requirement The MSC shall support receipt of the Destination Address

NUMBER_PLAN set to “ISDN/Telephony” or “Unknown” for internationally-addressed text messages.


Comments The preferred value is “ISDN/Telephony”, however theNUMBER_TYPE value is sufficient to allow equivalent treatment for an “Unknown” NUMBER_PLAN.

Requirement Number 2.4.2-040Requirement The MSC shall transfer a received internationally-formatted SMS

Destination Address into the ANSI-41SMS_OriginalDestinationAddress (SMS_ODA) parameter and retainthe international indicator.

Standards Reference N.S0005-0 v1.0 Ch5 §6.5.2.131

Comments Bit A of the Nature of Number octet is set to 1. The MSC maytransfer the received NUMBER_PLAN value to the correspondingNumbering Plan value (noting that NUMBER_PLAN = ‘00012’ shouldmap to Numbering Plan = ‘00102’), or it may (but is not required to)map a value of “Unknown” to “Telephony Numbering” (using thepresence of the NUMBER_TYPE set to “International number” todetermine this). Per ANSI-41, the encoding is changed to BCD. If theMSC also populates the SMS_DestinationAddress (SMS_DA)parameter with the same value as the SMS_ODA, then thisrequirement shall also apply to the SMS_DA.Note that the option to reconstitute the International Prefix (as per 3.1.1-090a) does not apply here, as the destination address isparsed by the MC in the home network. The MC may not be awareof the particular International Prefix in use in the servingnetwork/country.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.4.2-050Requirement The MSC should use the internationally-formatted MDN (if received

in the subscriber profile) to populate theSMS_OriginalOriginatingAddress (SMS_OOA) parameter.


Comments See above for formatting details. If the MSC also populates theSMS_OriginatingAddress (SMS_OA) parameter with the same valueas the SMS_OOA, then this requirement shall also apply to theSMS_OA.

Requirement Number 2.4.2-060Requirement The MSC should use the internationally-formatted MDN (if received

in the subscriber profile) to populate the SMS_DestinationAddress(SMS_DA) parameter.

Standards Reference X.S0004-641-E v1.0 §3.5 step 1-4-1, N.S0005-0 v1.0 Ch5

§6.5.2.127Comments See above for formatting details. Not all MSCs today populate

SMS_DA with the originating subscriber MDN.

Ref Doc. 145, Ver. 1.1 2007-09-17




2.5 Termination

2.5.1 Voice

Requirement Number 2.5.1-010Requirement The MSC should transfer the received calling party number

information to the air interface while preserving the internationalindication, if received.

Standards Reference N.S0005-0 v1.0 Ch3 §6.8.1 & Ch5 §6.5.2.23, C.S0005 v3.0 §3.7.5.3

Comments Either the Calling Party Number parameter from the ISUP incall/calldelivery leg or the ROUTREQ CallingPartyNumberString1 parameter can be used to provide the CNI information. The Nature of Addressor Nature of Number field as appropriate shall be inspected todetermine if the calling party is an international number. On the air interface, the NUMBER_TYPE field of the Calling Party Number

information record is set to “International number”, and theNUMBER_PLAN is mapped appropriately from the receivedinformation. If the MSC prefixes received international numbers withthe MSC’s own International Prefix for display (e.g. for non-PCD-capable mobiles), then the MSC should allow an option to retain thismodification, instead of sending the digits in international format onthe air interface. There is no standardized mechanism for theMSC/VLR to know whether a particular MS supports PCD.

Requirement Number 2.5.1-020Requirement The MSC shall not include an ASCII “+” symbol in an international

Calling Party Number.

Standards Reference

Comments This requirement should not impede the MSC from transferring non-numeric ASCII characters in the Calling Party Number whenNUMBER_TYPE is not set to “International number.”

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.5.1-030Requirement The MSC (acting as in-call/originating MSC) should transfer the

received ISUP Calling Party Number information to the ANSI-41LOCREQ preserving the international indicator.


Comments The calling party number is carried in the CallingPartyNumberDigits1parameter.

2.5.2 SMS

Requirement Number 2.5.2-030Requirement If the MSC uses the SMS_ODA parameter (as opposed to the MSID)

to determine the destination mobile for SMS, the MSC shouldreceive and match an internationally-formatted SMS_ODA.

Standards Reference C.S0015-B v2.0 §2.4.3Comments See Requirement 2.4.1-140. It is assumed that the HLR and MC in

the home network will provide the MDN/SMS_ODA in the sameformat (i.e. natl/intl). In most cases, the MSC/VLR is expected tomatch the subscriber based on the MSID from the received SMDPP

– in this case this requirement does not apply.

Requirement Number 2.5.2-040Requirement The MSC should receive and transfer an internationally-formatted

SMS_OOA or SMS_OA parameter to the IS-637 Originating Addressparameter.

Standards Reference N.S0005-0 v1.0 Ch5 §§6.5.2.133 & 6.5.2.135

Comments Encoding of the Originating Address (e.g. DIGIT_MODE,NUMBER_TYPE, NUMBER_PLAN) is similar to that used in voiceorigination. Per IS-637, SMS_OA is used if SMS_OOA is absent.

Requirement Number 2.5.2-050Requirement If the MSC includes the MDN parameter in an SMSNOT, the MDN

should be included in the same format (i.e. international or not) aswas received by the VLR at registration time.

Standards Reference N.S0024 v1.0 Ch3 §6.4.2.44

Comments IS-841 implies elsewhere that this parameter is not included. This

requirement applies only in the case of an MSC that already includesthe MDN in this scenario – it is not intended to suggest that the MDNought to be included.

Ref Doc. 145, Ver. 1.1 2007-09-17




3. HLR/SCP Requirements

2.6 Origination

Requirement Number 2.6-010Requirement The HLR should have the capability to return the subscriber profile

with a Mobile Directory Number (MDN) in international format.

Standards Reference N.S0016-0 v1.0 Ch4 §6.4.2.37 (RETURN RESULT note l)

Comments

Requirement Number 2.6-020Requirement The HLR should accept, store and return a termination address in

international format received in a FeatureRequest.Standards Reference N.S0005-0 v1.0 Ch5 §6.5.2.58

Comments The Nature of Number of the Digits (Dialed) parameter can be set tointernational. The HLR returns the stored address includinginternational indication in the Digits (Destination) or DestinationDigitsparameters in the tranumreq.


Requirement The HLR/SCP should be capable of being provisioned with numbersin international format for the purposes of translation of “short codedialing.”

Standards Reference N.S0016-0 v 1.0 “Assumptions”-e

Comments When the subscriber dials a “short code” (e.g. an office extension)and the dialed digits are sent to the HLR/SCP in an ORREQ, thetranslated digits are returned in international format. A provisioningmechanism is required to allow the home operator to specify that thetranslated number is in international format. Other scenarios (e.g.CONNRES) may also require internationally-formatted digits to besent.

Requirement Number 2.6-040Requirement The HLR/SCP should accept and process dialed digit strings with an

international Nature of Number.

Standards Reference N.S0016-0 v 1.0 “Assumptions”-eComments The digits may be received e.g. in ORREQ, ANLYZD. The Nature of

Number must be used to distinguish otherwise identical number strings (e.g. when dialing from the NANP, the string 6462741234could be a call to New York or New Zealand, depending on theNature of Number). Depending on application requirements, digitsmay also need to be returned to the serving MSC in internationalformat.

Ref Doc. 145, Ver. 1.1 2007-09-17

https://www.numberingplans.com/?page=plans&sub=phonenr_range&range=1646274&type=XGG&alpha_2=US

http://www.numberingplans.com/?page=plans&sub=phonenr_range&range=646274&type=XGG&alpha_2=NZ



https://www.numberingplans.com/?page=plans&sub=phonenr_range&range=1646274&type=XGG&alpha_2=US




Plus Code Dialing Requirements HLR/SCP Requirements

2.7 Termination

2.7.1 Voice

Requirement Number 2.7.1-010Requirement The HLR may “internationalize” the CallingPartyNumberString digits

for inclusion in the ROUTREQ when the called subscriber is knownto be roaming outside his/her home E.164 country.

Standards Reference N.S0027-0 v1.0 “TIA/EIA-41.6-D MODIFICATIONS” §5.8.1

Comments See 2.7.1-030 below.

Requirement Number 2.7.1-020Requirement The HLR shall not add an ASCII “+” symbol to the CPNS1/2 digit

string in the ROUTREQ when the number is in international format.

Standards Reference

Comments Although the CPNS digits are in ASCII format, the internationalindication can be carried by the Nature of Number field.

Requirement Number 2.7.1-030Requirement The HLR may maintain a local flag which defines whether the MS

can accept international-formatted digits for presentation.

Standards Reference

Comments This flag can be used to modify the logic in 2.7.1-010 above. Notethat this flag may not be practical in the case of an R-UIM-basedsubscription, where the MS capabilities may change depending onwhich ME currently hosts the R-UIM.

Requirement Number 2.7.1-040Requirement The HLR should transfer an internationally-formatted calling partynumber received in the LOCREQ to the outgoing ROUTREQ

Standards Reference N.S0005-0 v1.0 Ch5 §6.5.2.21 and §6.5.2.23

Comments The calling party number is carried in the CallingPartyNumberDigits1parameter in the LOCREQ, and in the CallingPartyNumberString1parameter in the ROUTREQ.

2.7.2 SMS


Requirement An HLR supporting IS-841 should accept an internationally-formattedMDN in the SMSREQ.

Standards Reference

Comments If a subscriber originates a mobile-to-mobile SMS using aninternationally-formatted destination address, this address may becopied into the SMSREQ by the subscriber’s MC.

Ref Doc. 145, Ver. 1.1 2007-09-17

http://www.3gpp2.org/Public_html/specs/N.S0024-0_v1.0.pdf




Plus Code Dialing Requirements HLR/SCP Requirements

Requirement Number 2.7.2-020Requirement An HLR supporting IS-841 should include an internationally-

formatted MDN in the SMSNOT if received as such in the SMSREQ.

Standards Reference N.S0024-0 v1.0 Ch4 §4.47.1

Comments

Requirement Number 2.7.2-030Requirement If an IS-841-compliant HLR includes the MDN parameter in an

SMSREQ sent to the VLR, it should include the MDN in the sameformat as was provided to the VLR at registration time.

Standards Reference N.S0024 v1.0 Ch4 §4.48.2 step 1-4-1

Comments IS-841 implies elsewhere that this parameter is not included. MSID isclearly identified as the primary identifier for the MS in this scenario.This requirement applies only in the case of an HLR that alreadyincludes the MDN in this scenario – it is not intended to suggest that

the MDN ought to be included.

Ref Doc. 145, Ver. 1.1 2007-09-17






4. MC Requirements

2.8 Origination

Requirement Number 2.8-010Requirement The MC shall accept and process a destination address in

international format received in an incoming SMDPP from a mobile-originated SMS.


Comments The international format is carried in the Nature of Number field for ANSI-41 parameters. The Numbering Plan value may be “Unknown”or “Telephony Numbering”. “Accept and process” implies that the MCwill match an internationally formatted address to its internal tables(e.g. MDN-to-HLR for SMSRequest addressing), and transfer theformat to outgoing messages as described elsewhere in thisdocument.

Requirement Number 2.8-015Requirement The MC should accept and process an originating address in

international format received in an incoming SMDPP from a mobile-originated SMS.


Comments The international format is carried in the Nature of Number field for ANSI-41 parameters. Receipt of an internationally-formattedSMS_OOA parameter would typically require the support of

requirements 2.6-010 and 2.4.2-050 in the home and servingnetworks respectively. “Accept and process” implies that the MC willmatch an internationally formatted address to its internal tables (e.g.any per-subscriber provisioned information), and transfer the formatto outgoing messages as described elsewhere in this document.

Ref Doc. 145, Ver. 1.1 2007-09-17



Plus Code Dialing Requirements MC Requirements

Requirement Number 2.8-020Requirement [Note: An alternative to this requirement is shown below.] The MC

should offer two options for population of a Call Detail Record:including an indication that an internationally-formatted destination

was entered; and prefixing the entered destination with the correctInternational Prefix for the MC service area (i.e. no changes toexisting CDR).

Standards Reference

Comments Depending on implementation options, the International Prefix maynot be required for existing international SMS destinations – theintent of this requirement is to allow the operator the choice to either track the use of PCD-based messaging through billing records, or toavoid any downstream billing system changes due to the introductionof PCD. This requirement applies to billing records produced for bothMO- and MT-SMS. This approach may also be extended to removalof the home network Country Code, and prefixing of a national prefixif a number in the home country is addressed in plus-code format,

and IAC+CC is not already in use as a valid format for this scenario.

Requirement Number 2.8-020a Requirement [Note: This requirement is an alternative to 5.1-020 shown above.

020a represents more basic functionality than the full flexibility of 020.] The MC shall produce Call Detail Records without indicatingthat an internationally-formatted destination was entered; i.e. as if themobile was non PCD-capable and the International Prefix had beenexplicitly entered by the user..

Standards Reference

Comments This allows the operator to avoid any downstream billing systemchanges due to the introduction of PCD. This requirement applies to

billing records produced for both MO- and MT-SMS. This approachmay also be extended to removal of the home network CountryCode, and prefixing of a national prefix if a number in the homecountry is addressed in plus code format, and IAC+CC is not alreadyin use as a valid format for this scenario.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.8-030Requirement The MC should transfer a received ANSI-41 destination address in

international format to an outgoing inter-MC link (e.g. using SMPP)

Standards Reference SMPP v3.4 §5.2.5

Comments For a mobile-mobile, inter-operator SMS, the originating subscriber’sMC should transfer the message to the terminating subscriber’s MC,typically via a protocol such as SMPP. An SMS “hub” provider maybe used to simplify routing and connections. See 5.1-050 below.

Requirement Number 2.8-040Requirement The MC should transfer a received ANSI-41 originating address in

international format to an outgoing inter-MC link (e.g. using SMPP)

Standards Reference SMPP v3.4 §5.2.5

Comments For a mobile-mobile, inter-operator SMS, the originating subscriber’sMC should transfer the message to the terminating subscriber’s MC,

typically via a protocol such as SMPP. An SMS “hub” provider maybe used to simplify routing and connections. See 5.1-050 below.

Requirement Number 2.8-050Requirement The MC should provide the option to “de-internationalize” originating

and destination addresses before transfer to an outgoing inter-MClink (e.g. using SMPP) for the case where the receiving entity isknown not to be capable of handling the international format.

Standards Reference

Comments The exact format of the addresses used in this case (e.g.: E.164without international number type; IP of sending country; IP of

receiving country) is subject to bilateral agreement and is outside thescope of this document.

2.9 Termination

Requirement Number 2.9-005Requirement The MC shall have the capability to “de-internationalize” originating

address information before sending a mobile-terminated SMDPP.

Standards Reference

Comments This capability is aimed to protect non-PCD-capable mobiles fromreceiving an ASCII/International Originating Address in an SMS,

which may have unknown handling.

Requirement Number 2.9-010Requirement Subject to 5.2-030 below, the MC should transfer an internationally-

formatted destination address received on incoming messages to theMT SMDPP).

Standards Reference

Comments This requirement applies both to messages received via ANSI-41,

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.9-010and via other interfaces (e.g. SMPP).


Requirement Subject to 5.2-005 & -040, the MC should transfer an internationally-formatted originating address received on incoming messages to theMT SMDPP).

Standards Reference

Comments This requirement applies both to messages received via ANSI-41,and via other interfaces (e.g. SMPP).

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.9-020Requirement The MC shall have a configurable option to provide the MDN to the

HLR in international or national format in the SMSREQ.

Standards Reference

Comments This requirement only applies to MCs that support IS-841. The MDN(received as a destination address in an incoming message) mayneed to be internationalized or de-internationalized as appropriate,based on the HLR capabilities.

Requirement Number 2.9-030Requirement The MC should have the capability to internationalize or de-

internationalize the MDN if used to populate the SMS_ODA (andpossibly SMS_DA) parameters, to match the value sent by the HLR.

Standards Reference

Comments A mobile-to-mobile SMS sent by a subscriber to an internationally-formatted destination may carry the (internationally-formatted) MDNas the SMS_ODA in the resulting MT SMDPP. If the HLR only sends

a nationally-formatted MDN in the subscriber profile, and the servingMSC matches on MDN/SMS_ODA for SMS delivery, use of theinternationally-formatted SMS_ODA could result in a mismatch anddelivery failure. The MC should be configured to match the valuesent by the HLR, and to convert from the originator-entered format,as appropriate.

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.9-040Requirement The MC may have the capability to internationalize the SMS_OOA

parameter if it is known that the destination subscriber is roamingoutside his/her home E.164 country.

Standards Reference

Comments Per requirement 2.9-005, and 2.9-060, this would only be used if itwere known that the MS could accept the address in this format. Byextension from 2.7.1-010, it is debatable whether the MC is logicallyrequired to associate the received SMS_Address with a geographicregion, even if that information may, in practice, be preconfigured or derived (e.g. from MCC if SMSADDR is E.212 GT).

Ref Doc. 145, Ver. 1.1 2007-09-17




Requirement Number 2.9-050Requirement The MC may have the capability to internationalize the IS-637 Call-

back Number sub-parameter if it is known that the destinationsubscriber is roaming outside his/her home E.164 country.

Standards ReferenceComments By extension from 2.7.1-010. It is debatable whether the MC is

logically required to associate the received SMS_Address with ageographic region, even if that information may, in practice, bepreconfigured or derived (e.g. from MCC if SMSADDR is E.212 GT).

Requirement Number 2.9-060Requirement The MC may maintain a local flag which defines whether the MS can

accept international-formatted digits for presentation.

Standards Reference

Comments This flag can be used to modify the logic in 2.9-040 & 2.9-050. Notethat this flag may not be practical in the case of an R-UIM-basedsubscription, where the MS capabilities may change depending onwhich ME currently hosts the R-UIM.

Ref Doc. 145, Ver. 1.1 2007-09-17




5. Appendix – Call Flow Diagrams

The following figures aim to provide a graphical depiction of several representative call

scenarios, and show where in the call flow many (but not all) of the requirements apply.

In the event of any conflict of interpretation arising between these diagrams and the

main body text, the main body text shall prevail.

2.10 SMS Scenarios

Ref Doc. 145, Ver. 1.1 2007-09-17




2.11 Voice Scenarios

plus code dialing requirements

Documents