Plus Code Dialing Requirements

Plus Code Dialing Requirements
CDG Document 145 Version 1.1
2007-09-17
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 CDG member should consider all disclosures and contributions as being made solely on an as-is basis. If any CDG member makes any use of any disclosure or contribution, then such use is at such CDG member's sole risk. Each CDG member agrees that CDG shall not be liable to any person or entity (including any CDG member) arising out of any use of

any disclosure or contribution, including any liability arising out of infringement of intellectual property rights.
Ref Doc. 145, Ver. 1.1
2007-09-17
<page left blank intentionally>
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.................................................................................................................... 4 2.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
Contents
2.5.1Voice.................................................................................................................. 25 2.5.2SMS................................................................................................................... 26 3. HLR/SCP Requirements........................................................................................................ 27 2.6Origination........................................................................................................................ 27 2.6Origination........................................................................................................................ 27 2.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
10 October 2006 2 January 2007 2 March 2007 9 April 2007 13 June 2007 27 August 2007 12 September 2007 17 September 2007
Version
0.1 0.2 0.3 0.4 0.5 0.6 1.0 1.1
Description
Initial release Updated following Nov 06 IRT, minimum requirements identified Updated following conference call and team feedback Update to CDG Format and incorporate changes from conference call Update following VSWG review period Clarifications to SMS, remove MMS, added Appendix Approval version, no text change from v0.6 Additional minor clarifications
2007-09-17
Contents
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 the responsibility 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 IS2000 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.
2007-09-17
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 a particular MS can successfully receive and process internationally-formatted numbers.
1.4 Acronyms and Abbreviations

Term
ANLYZD BCD BSC BTS CDG CNIR CONNRES CPNS CSIM GHRC HLR IAC+CC IAM IP IRT ISDN ISUP ITU-T MC MCC MDN
Meaning
AnalyzedInformation Binary Coded Decimal Base Station Controller Base Transceiver/Transmitter Station CDMA Development Group Calling Number Information Restriction ConnectResource CallingPartyNumberString cdma2000 Subscriber Identity Module Global Handset Requirements for CDMA Home Location Register International Access Code + Country Code Initial Address Message International Prefix (aka International Access Code) International Roaming Team Integrated Services Digital Network ISDN User Part International Telecommunications Union-Telecommunications sector Message Center Mobile Country Code Mobile Directory Number
2007-09-17
Introduction
Term
ME MO MMS MS MSC MSID MT NAM NPI ODA OMA ORREQ PCD R-UIM SCP SMDPP SMPP SMS SMSADDR SMSREQ TON tranumreq VLR WAP
Meaning
Mobile Equipment Mobile-Originated Multimedia Messaging Service Mobile Station Mobile Switching Center Mobile Station Identifier Mobile-Terminated Number Assignment Module Numbering Plan Identification Original Destination Address Open Mobile Alliance OriginationRequest Plus Code Dialing Removable User Identity Module Service Control Point SMSDeliveryPointToPoint Short Message Peer-to-Peer Short Message Service SMS_Address SMSRequest Type of Number TransferToNumberRequest RETURN RESULT Visitor Location Register Wireless Application Protocol
2007-09-17
Mobile Station Requirements

2.1 Origination 2.1.1 Voice
Requirement Number
Requirement Standards Reference Comments
2.1.1-010
The MS shall provide a plus key or equivalent user interface convention to allow PCD. N.S0027 (TIA/EIA-664-701-A MODIFICATIONS chapter) 1.1. Individual operators may wish to specify the entry method in more detail, e.g. double-press of * key. The input method shall be applicable to all instances of digit entry, e.g. call origination, phonebook entry, SMS destination, and SMS Call-Back Number.
Requirement Number
Requirement
2.1.1-020
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). N.S0027 (TIA/EIA-664-701-A MODIFICATIONS chapter) 1.18
Standards Reference Comments
2007-09-17
Requirement Number
2.1.1-030
The MS shall support transmission of the dialed digits in ASCII mode for internationally-dialed voice calls (Origination Message). C.S0005-0 v3.0 2.7.1.3.2.4 The NUMBER_TYPE field (required for indicating the international nature 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 using the plus key or equivalent as described above existing calls are unchanged.
Requirement Number
2.1.1-040
The MS shall support setting the NUMBER_TYPE to International number for internationally-dialed voice calls. C.S0005-0 v3.0 2.7.1.3.2.4 This is the central requirement for PCD.
Requirement Number
2.1.1-050
The MS shall support setting the NUMBER_PLAN to either ISDN/Telephony or Unknown for internationally-dialed voice calls. C.S0005-0 v3.0 2.7.1.3.2.4 The preferred value is ISDN/Telephony, however use of the plus key implies that an E.164-formatted digit string follows, therefore the interpretation is clear even if Unknown is used..
2007-09-17
Requirement Number
2.1.1-060
The MS shall support use of the Origination Continuation Message if all the dialed digits cannot be included in the Origination Message. C.S0005-0 v3.0 2.6.3.5 & 2.6.4.4 Use of 8-bit encoding for the dialed digits increases message size, potentially exceeding the maximum Access Channel message capsule size. In this case the MS shall set MORE_FIELDS in the Origination Message to 1 and include the remaining digits in the Origination Continuation Message.
Requirement Number
2.1.1-070
The MS shall not transmit an ASCII + character in the dialed digits for internationally-dialed voice calls. 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 the statement Prefix or escape digits shall not be included (in A.S0014C and T1.607) when the called party number is set to International.
Requirement Number
2.1.1-080
The MS should allow international dialing even when the dialed digit string includes overdecadic digits (i.e. * and/or #). A legitimate scenario is when a user attempts to set up call forwarding to a destination number in international format (even though in most CDMA networks today the use of the RedirectionRequest operation means forwarding can be performed without the use of the international format) .
Requirement Number
2.1.1-090
The MS should allow international dialing when the user enters the + symbol anywhere in the digit string (and not just at the start). For the forwarding to international number scenario described above, or a CNIR temporary activation call to an international number, 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 is independent of the placement of the + in the user-entered digits.
Requirement Number
Requirement Standards Reference Comments Ref Doc. 145, Ver. 1.1
2.1.1-100
The MS is not required to support PCD for the second leg of a 3-way call. C.S0005-0 v3.0 2.6.4.4 & 2.7.4.2 Dialed digits for the second leg are carried in the Keypad Facility 2007-09-17
Requirement Number
2.1.1-100
information record. This record does not define a means to indicate that 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-010
The MS shall support transmission of the Destination Address parameter in ASCII mode for internationally-addressed text messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 The address formatting for SMS is similar to that for the dialed digits in the Origination Message.
2007-09-17
Requirement Number
2.1.2-020
The MS shall support setting the Destination Address NUMBER_TYPE to International number for internationallyaddressed text messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 With DIGIT_MODE set to 1, NUMBER_MODE set to 0, NUMBER_TYPE is set to 001 (binary).
Requirement Number
2.1.2-030
The MS shall support setting the Destination Address NUMBER_PLAN to either ISDN/Telephony or Unknown for internationally-addressed text messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 As with voice.
Requirement Number
2.1.2-040
The MS should support transmission of the Call-Back Number subparameter digits in ASCII mode when internationally formatted. C.S0015-B v2.0 4.5.15 & C.S0005-0 v3.0 2.7.1.3.2.4 When non-international digits are sent in this sub-parameter, ASCII encoding is not required. If a default Call-Back Number is stored in the MS independently of the MDN, it shall be possible for this number to be in international format. (C.S0005-0 v3.0 2.3.1.4 does not imply that the MDN NAM indicator itself can be stored in international format, although this may be possible when an R-UIM is used see 2.3-020.)
2007-09-17
Requirement Number
2.1.2-050
The MS should support setting the Call-Back Number sub-parameter NUMBER_TYPE to International number when the Call-Back Number is internationally formatted. C.S0015-B v2.0 4.5.15 & C.S0005-0 v3.0 2.7.1.3.2.4.
Requirement Number
2.1.2-060
The MS should support setting the Call-Back Number sub-parameter NUMBER_PLAN to ISDN/Telephony when the Call-Back Number is internationally formatted. C.S0015-B v2.0 4.5.15 & C.S0005-0 v3.0 2.7.1.3.2.4.
2.2 Termination 2.2.1 Voice

Requirement Number
2.2.1-010
The MS should accept an internationally-formatted Calling Party Number information record for an incoming voice call. C.S0005-0 v3.0 3.7.5.3 & 2.7.1.3.2.4 NUMBER_TYPE is International number. This requirement applies both to voice calls received when idle and incoming call waiting calls.
2007-09-17
Requirement Number
2.2.1-020
The MS should accept as internationally-formatted a Calling Party Number with NUMBER_TYPE = International number and NUMBER_PLAN set to either Unknown or ISDN/Telephony. C.S0005-0 v3.0 3.7.5.3 & 2.7.1.3.2.4. The preferred value is ISDN/Telephony, however the NUMBER_TYPE value is sufficient to allow equivalent treatment for an Unknown NUMBER_PLAN.
Requirement Number
2.2.1-030
The MS should present a received internationally-formatted Calling Party Number to the subscriber with a leading + symbol. N.S0027, TIA/EIA-664-508-A MODIFICATIONS chapter 1 & TIA/EIA-664-701-A MODIFICATIONS chapter 1.8.3.
Requirement Number
2.2.1-040
The MS should match a received internationally-formatted Calling Party Number to a corresponding phonebook entry. For example, to display the stored name of the caller. If the MS allows a partial match, this may optionally be extended to include matching 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 the equivalent international format phonebook entry.
2007-09-17
Requirement Number
2.2.1-050
The MS should ignore an ASCII + symbol received in an international Calling Party Number. The MS should not display ++ for a number received in this format. This requirement should not impede the MS from handling nonnumeric ASCII characters in the Calling Party Number when NUMBER_TYPE is not set to International number.
2.2.2 SMS
Requirement Number
2.2.2-010
The MS should accept an Originating Address parameter coded in ASCII mode when receiving an SMS. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4
Requirement Number
2.2.2-020
The MS should accept an Originating Address parameter with NUMBER_TYPE = International number when receiving an SMS. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4
2007-09-17
Requirement Number
2.2.2-030
The MS should present a received internationally-formatted Originating Address parameter to the subscriber with a leading + symbol.
Requirement Number
2.2.2-040
The MS should match a received internationally-formatted Originating Address parameter to a corresponding phonebook entry. Includes partial match as above.
Requirement Number
2.2.2-050
The MS should ignore an ASCII + symbol received in an international Originating Address parameter. The MS should not display ++ for a number received in this format. This requirement should not impede the MS from handling nonnumeric ASCII characters in the Originating Address parameter when NUMBER_TYPE is not set to International number.
2007-09-17
Requirement Number
2.2.2-060
The MS should recognize a + character as an international identifier when prefixed to digits in the body of the message for number extraction. If the MS supports one-touch dialing to a number contained in the body of the text message (e.g. please call John 2125551234 to arrange meeting), then a + prefix should be recognized as designating 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-070
The MS should accept a Call-Back Number sub-parameter coded in ASCII mode when receiving an SMS. C.S0015-B v2.0 4.5.15 & C.S0005-0 v3.0 2.7.1.3.2.4
Requirement Number
2.2.2-080
The MS should accept a Call-Back Number sub-parameter with NUMBER_TYPE = International number when receiving an SMS. C.S0015-B v2.0 4.5.15 & C.S0005-0 v3.0 2.7.1.3.2.4
2007-09-17
Requirement Number
2.2.2-090
The MS should present a received internationally-formatted CallBack Number sub-parameter to the subscriber with a leading + symbol.
Requirement Number
2.2.2-100
The MS should match a received internationally-formatted Call-Back Number sub-parameter to a corresponding phonebook entry. Includes partial match as above.
Requirement Number
2.2.2-110
The MS should ignore an ASCII + symbol received in an international Call-Back Number sub-parameter. The MS shall not display ++ for a number received in this format. This requirement should not impede the MS from handling nonnumeric ASCII characters in the Call-Back Number sub-parameter when NUMBER_TYPE is not set to International number.
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-010
The ME shall have the capability to store and retrieve internationallyformatted numbers to/from the R-UIM/CSIM. C.S0065-0 v1.0 (various sections), and 3GPP 24.008 v6.13.0 10.5.4.7 The READ and UPDATE commands to various Elementary Files (e.g. EFADN, EFFDN, EFSDN, EFANR, EFICI, EFOCI shall allow for Type of number (TON) = international number and Numbering Plan Identification (NPI) = ISDN/telephony.
Requirement Number
2.3-020
The ME should have the capability to store and retrieve the MDN to/from the R-UIM/CSIM in international format. C.S0065-0 v1.0 5.2.35 & C.S0005-0 v3.0 2.7.1.3.2.4 NUMBER_TYPE and NUMBER_PLAN set as per 2.1.1-040 & 2.1.1040 respectively.
Requirement Number
2.3-030
The ME should have the capability to store and retrieve the default SMS Destination Address to/from the R-UIM/CSIM in international format. C.S0065-0 v1.0 5.2.29 & C.S0015-B v2.0 3.4.3.3 Default Destination Address is stored in EFSMSP.
2007-09-17
2. MSC Requirements
This section also includes BSC/BTS requirements. Except where specified (e.g. for Ainterface requirements) the MSC is assumed to incorporate the BSC/BTS.
2.4 Origination 2.4.1 Voice

Requirement Number
2.4.1-010
The MSC shall support receipt of the Origination Message with dialed digits (Origination Message CHARi) in ASCII mode for internationally-dialed voice calls. C.S0005-0 v3.0 2.7.1.3.2.4 The NUMBER_TYPE field (required for indicating the international nature 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 using the MS plus key or equivalent existing calls are unchanged.
Requirement Number
2.4.1-020
The MSC shall support receipt of the NUMBER_TYPE, set to International number for internationally-dialed voice calls. C.S0005-0 v3.0 2.7.1.3.2.4 This is the central requirement for PCD.
2007-09-17
MSC Requirements
Requirement Number
2.4.1-030
The MSC shall support receipt of the NUMBER_PLAN set to ISDN/Telephony or Unknown for internationally-dialed voice calls. C.S0005-0 v3.0 2.7.1.3.2.4 The preferred value is ISDN/Telephony, however the NUMBER_TYPE value is sufficient to allow equivalent treatment for an Unknown NUMBER_PLAN.
Requirement Number
2.4.1-040
The MSC shall support an international-format origination to a destination in the same E.164 country as the MSC. N.S0027 (TIA/EIA-41.6-D MODIFICATIONS chapter) 3.2.3 This is particularly useful for the home network, as the subscriber can store all their phonebook entries in the international format even when not roaming.
Requirement Number
2.4.1-050
The MSC should support use of the Origination Continuation Message to carry dialed digits that could not be included in the Origination Message. C.S0005-0 v3.0 2.6.3.5 & 2.6.4.4 Use of 8-bit encoding for the dialed digits increases message size, potentially exceeding the maximum Access Channel message capsule size. In this case the MS sets MORE_FIELDS in the Origination Message to 1 and includes the remaining digits in the Origination Continuation Message.
2007-09-17
MSC Requirements
Requirement Number
2.4.1-060
The MSC should accept and ignore a leading ASCII + in the dialed digits when the NUMBER_TYPE is set to International number. The international nature of the digit string is conveyed by the NUMBER_TYPE field set appropriately: an ASCII + is redundant. However, some MSs may include this character. The MSC may delete this character before any further processing of the digit string. This requirement should not impede the MSC from handling nonnumeric ASCII characters in the dialed digits when NUMBER_TYPE is not set to International number.
Requirement Number
2.4.1-070
The BSC shall transmit the called party number to the MSC in international format for a received internationally-dialed voice call. A.S0014-C v2.0 3.1.2 & 4.2.59 The Called Party ASCII Number field is used with Type of Number and Numbering Plan Identification fields set appropriately.
Requirement Number
2.4.1-080
The MSC is not required to support PCD for the second leg of a 3way call. C.S0005-0 v3.0 2.6.4.4 & 2.7.4.2 Dialed digits for the second leg are carried in the Keypad Facility information record. This record does not define a means to indicate that the digits it contains are in international format. (Use of an ASCII + symbol is rejected for complexity.)
Requirement Number
Requirement
2.4.1-090
[Note: An alternative to this requirement is shown below.] The MSC should offer two options for onward signaling of the dialed digits/destination number: retaining the international indication, and removing the indication but prefixing the correct International Prefix (aka International Access Code) for the MSC service area. This requirement applies both to trunk interfaces (e.g. the Called Party 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 be aware of PCD. This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefix if a number in the serving country is dialed in plus code format. Care may be required with some ANSI-41 operations (see 2.4.1-110 & 2.4.1-120). The option to replace the international indicator with the International Prefix does not apply to the SMS_OriginalDestinationAddress for MO-SMS (see 2.4.2-040). In all cases there is no requirement for a change to the outward signaling
2007-09-17
MSC Requirements
Requirement Number
2.4.1-090
protocol e.g. the dialed digits may be required to be converted to BCD format to comply.
Requirement Number
Requirement
2.4.1-090a
[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 dialed the International Prefix. This requirement applies both to trunk interfaces (e.g. the Called Party 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 be aware of PCD. This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefix if a number in the serving country is dialed in plus code format. This requirement does not apply to the SMS_OriginalDestinationAddress for 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 digits may be required to be converted to BCD format to comply.
Requirement Number
Requirement
2.4.1-100
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 internationallyformatted calls, in accordance with existing preferred carrier handling. If the subscriber has a specified international carrier preference, then a call dialed using the plus code must be routed to this carrier (provided the MSC otherwise honors Preferred Carrier information when no carrier prefix is explicitly dialed). If the MSC retains the international indication in the out-dialed call, it shall also include information (e.g. Transit Network Selection, Carrier Identification parameters) to allow the receiving network to pass the call to the appropriate carrier. If the MSC replaces the international indication with the International Prefix, it may use a carrier-specific prefix, or include carrier information in separate parameters as described above, depending on implementation requirements. In either case the 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-110
The MSC should accept and process an international-format origination which results in a FeatureRequest. A legitimate scenario is when a user attempts to set up call forwarding to a destination number in international format (even though in most CDMA networks today the use of the 2007-09-17
MSC Requirements
Requirement Number
2.4.1-110
RedirectionRequest operation means forwarding can be performed without the use of the international format). If the international indicator is retained in the FEATREQ no special handling is required. If however the MSC prefers to replace the international indication with 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 xxxxxxxxxx should 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-120
The MSC should accept and process an international-format origination that includes a locally-handled service prefix. An example is CNIR temporary (i.e. per-call) deactivation. If the MSC retains the international indicator in the outgoing ISUP message, no special handling is required. If however the MSC prefers to replace the international indication with the International Prefix digits, it must do so in such a way that both the service code and the user-intended international nature of the resulting call are unaffected. For example, if the digit string [CNIR prefix] 52 xxxxxxxxxx is received with an international indication in a country where the International Prefix is 011, a possible approach is to remove the international indication and 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 and replaced with an 011 prefix to the remaining digits. Immediately replacing the international indication with 011 to give a digit string of 011 [CNIR prefix] 52 xxxxxxxxxx however is unlikely to achieve the subscribers intended result.
Requirement Number
Requirement
2.4.1-130
[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 dialed digits with the correct International Prefix for the MSC service area (i.e. no changes to existing CDR). This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefix if a number in the serving country is dialed in plus code format. This allows operators the choice to either track the incidence of PCD in their network, or to avoid any downstream billing system impacts.
2007-09-17
MSC Requirements
Requirement Number
Requirement
2.4.1-130a
[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 it does today for non-PCD calls, i.e. as if the subscriber explicitly dialed the International Prefix. This approach may also be extended to removal of the serving network Country Code, and prefixing of a national prefix if a number in the serving country is dialed in plus code format. This allows operators to avoid any downstream billing system impacts.
Requirement Number
2.4.1-140
The MSC should support the receipt of an internationally-formatted Mobile Directory Number (MDN) in the subscriber profile. N.S0016-0 v1.0 Ch4 6.4.2.37 Nature of Number is set to International. BCD digits contain the full E.164 string. This requirement is to allow presentation of the calling party in plus format for a mobile-originated call.
Requirement Number
2.4.1-150
The MSC should retain the international indicator for an MDN when used for onward signaling. This requirement applies both to trunk interfaces (e.g. Calling Party Number Nature of Address in ISUP IAM) and to ANSI-41 (e.g. LocationRequest/OriginationRequest CallingPartyNumberDigits1, MobileDirectoryNumber).
Requirement Number
2.4.1-160
If the MSC receives a call attempt containing both an international indication, and digits which normally result in an international call, the entered digits should take precedence. Possible examples include the standard International Prefix, an international-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 Originators MC) is assumed. Requirement Number
Requirement
2.4.2-010
The MSC shall support the receipt of the air interface Destination Address parameter in ASCII mode for internationally-addressed text
2007-09-17
MSC Requirements
Requirement Number
2.4.2-010
messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 The address formatting for SMS is similar to that for the dialed digits in the Origination Message.
Requirement Number
2.4.2-020
The MSC shall support receipt of the Destination Address with NUMBER_TYPE set to International number for internationallyaddressed text messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 With DIGIT_MODE set to 1 and NUMBER_MODE set to 0, NUMBER_TYPE is set to 001 (binary).
2007-09-17
MSC Requirements
Requirement Number
2.4.2-030
The MSC shall support receipt of the Destination Address NUMBER_PLAN set to ISDN/Telephony or Unknown for internationally-addressed text messages. C.S0015-B v2.0 3.4.3.3 & C.S0005-0 v3.0 2.7.1.3.2.4 The preferred value is ISDN/Telephony, however the NUMBER_TYPE value is sufficient to allow equivalent treatment for an Unknown NUMBER_PLAN.
Requirement Number
Requirement
2.4.2-040
The MSC shall transfer a received internationally-formatted SMS Destination Address into the ANSI-41 SMS_OriginalDestinationAddress (SMS_ODA) parameter and retain the international indicator. N.S0005-0 v1.0 Ch5 6.5.2.131 Bit A of the Nature of Number octet is set to 1. The MSC may transfer the received NUMBER_PLAN value to the corresponding Numbering Plan value (noting that NUMBER_PLAN = 0001 2 should map to Numbering Plan = 00102), or it may (but is not required to) map a value of Unknown to Telephony Numbering (using the presence of the NUMBER_TYPE set to International number to determine this). Per ANSI-41, the encoding is changed to BCD. If the MSC also populates the SMS_DestinationAddress (SMS_DA) parameter with the same value as the SMS_ODA, then this requirement 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 is parsed by the MC in the home network. The MC may not be aware of the particular International Prefix in use in the serving network/country.
2007-09-17
MSC Requirements
Requirement Number
2.4.2-050
The MSC should use the internationally-formatted MDN (if received in the subscriber profile) to populate the SMS_OriginalOriginatingAddress (SMS_OOA) parameter. N.S0005-0 v1.0 Ch5 6.5.2.133 See above for formatting details. If the MSC also populates the SMS_OriginatingAddress (SMS_OA) parameter with the same value as the SMS_OOA, then this requirement shall also apply to the SMS_OA.
Requirement Number
2.4.2-060
The MSC should use the internationally-formatted MDN (if received in the subscriber profile) to populate the SMS_DestinationAddress (SMS_DA) parameter. X.S0004-641-E v1.0 3.5 step 1-4-1, N.S0005-0 v1.0 Ch5 6.5.2.127 See above for formatting details. Not all MSCs today populate SMS_DA with the originating subscriber MDN.
2007-09-17
MSC Requirements

Requirement Number
2.5.1-010
The MSC should transfer the received calling party number information to the air interface while preserving the international indication, if received. N.S0005-0 v1.0 Ch3 6.8.1 & Ch5 6.5.2.23, C.S0005 v3.0 3.7.5.3 Either the Calling Party Number parameter from the ISUP incall/call delivery leg or the ROUTREQ CallingPartyNumberString1 parameter can be used to provide the CNI information. The Nature of Address or Nature of Number field as appropriate shall be inspected to determine 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 the NUMBER_PLAN is mapped appropriately from the received information. If the MSC prefixes received international numbers with the MSCs own International Prefix for display (e.g. for non-PCDcapable mobiles), then the MSC should allow an option to retain this modification, instead of sending the digits in international format on the air interface. There is no standardized mechanism for the MSC/VLR to know whether a particular MS supports PCD.
Requirement Number
2.5.1-020
The MSC shall not include an ASCII + symbol in an international Calling Party Number. This requirement should not impede the MSC from transferring nonnumeric ASCII characters in the Calling Party Number when NUMBER_TYPE is not set to International number.
2007-09-17
MSC Requirements
Requirement Number
2.5.1-030
The MSC (acting as in-call/originating MSC) should transfer the received ISUP Calling Party Number information to the ANSI-41 LOCREQ preserving the international indicator. N.S0005-0 v1.0 Ch5 6.5.2.21 The calling party number is carried in the CallingPartyNumberDigits1 parameter.
2.5.2 SMS
Requirement Number
2.5.2-030
If the MSC uses the SMS_ODA parameter (as opposed to the MSID) to determine the destination mobile for SMS, the MSC should receive and match an internationally-formatted SMS_ODA. C.S0015-B v2.0 2.4.3 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 same format (i.e. natl/intl). In most cases, the MSC/VLR is expected to match the subscriber based on the MSID from the received SMDPP in this case this requirement does not apply.
Requirement Number
2.5.2-040
The MSC should receive and transfer an internationally-formatted SMS_OOA or SMS_OA parameter to the IS-637 Originating Address parameter. N.S0005-0 v1.0 Ch5 6.5.2.133 & 6.5.2.135 Encoding of the Originating Address (e.g. DIGIT_MODE, NUMBER_TYPE, NUMBER_PLAN) is similar to that used in voice origination. Per IS-637, SMS_OA is used if SMS_OOA is absent.
Requirement Number
2.5.2-050
If the MSC includes the MDN parameter in an SMSNOT, the MDN should be included in the same format (i.e. international or not) as was received by the VLR at registration time. N.S0024 v1.0 Ch3 6.4.2.44 IS-841 implies elsewhere that this parameter is not included. This requirement applies only in the case of an MSC that already includes the MDN in this scenario it is not intended to suggest that the MDN ought to be included.
2007-09-17
3. HLR/SCP Requirements
2.6 Origination
Requirement Number
2.6-010
The HLR should have the capability to return the subscriber profile with a Mobile Directory Number (MDN) in international format. N.S0016-0 v1.0 Ch4 6.4.2.37 (RETURN RESULT note l)
Requirement Number
2.6-020
The HLR should accept, store and return a termination address in international format received in a FeatureRequest. N.S0005-0 v1.0 Ch5 6.5.2.58 The Nature of Number of the Digits (Dialed) parameter can be set to international. The HLR returns the stored address including international indication in the Digits (Destination) or DestinationDigits parameters in the tranumreq.
Requirement Number
Requirement
2.6-030
The HLR/SCP should be capable of being provisioned with numbers in international format for the purposes of translation of short code dialing. N.S0016-0 v 1.0 Assumptions-e 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, the translated digits are returned in international format. A provisioning mechanism is required to allow the home operator to specify that the translated number is in international format. Other scenarios (e.g. CONNRES) may also require internationally-formatted digits to be sent.
Requirement Number
2.6-040
The HLR/SCP should accept and process dialed digit strings with an international Nature of Number. N.S0016-0 v 1.0 Assumptions-e 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 6462741234 could be a call to New York or New Zealand, depending on the Nature of Number). Depending on application requirements, digits may also need to be returned to the serving MSC in international format.
2007-09-17
HLR/SCP Requirements

Requirement Number
2.7.1-010
The HLR may internationalize the CallingPartyNumberString digits for inclusion in the ROUTREQ when the called subscriber is known to be roaming outside his/her home E.164 country. N.S0027-0 v1.0 TIA/EIA-41.6-D MODIFICATIONS 5.8.1 See 2.7.1-030 below.
Requirement Number
2.7.1-020
The HLR shall not add an ASCII + symbol to the CPNS1/2 digit string in the ROUTREQ when the number is in international format. Although the CPNS digits are in ASCII format, the international indication can be carried by the Nature of Number field.
Requirement Number
2.7.1-030
The HLR may maintain a local flag which defines whether the MS can accept international-formatted digits for presentation. This flag can be used to modify the logic in 2.7.1-010 above. Note that this flag may not be practical in the case of an R-UIM-based subscription, where the MS capabilities may change depending on which ME currently hosts the R-UIM.
Requirement Number
2.7.1-040
The HLR should transfer an internationally-formatted calling party number received in the LOCREQ to the outgoing ROUTREQ N.S0005-0 v1.0 Ch5 6.5.2.21 and 6.5.2.23 The calling party number is carried in the CallingPartyNumberDigits1 parameter in the LOCREQ, and in the CallingPartyNumberString1 parameter in the ROUTREQ.
2.7.2 SMS
Requirement Number
2.7.2-010
An HLR supporting IS-841 should accept an internationally-formatted MDN in the SMSREQ. If a subscriber originates a mobile-to-mobile SMS using an internationally-formatted destination address, this address may be copied into the SMSREQ by the subscribers MC.
2007-09-17
HLR/SCP Requirements
Requirement Number
2.7.2-020
An HLR supporting IS-841 should include an internationallyformatted MDN in the SMSNOT if received as such in the SMSREQ. N.S0024-0 v1.0 Ch4 4.47.1
Requirement Number
2.7.2-030
If an IS-841-compliant HLR includes the MDN parameter in an SMSREQ sent to the VLR, it should include the MDN in the same format as was provided to the VLR at registration time. N.S0024 v1.0 Ch4 4.48.2 step 1-4-1 IS-841 implies elsewhere that this parameter is not included. MSID is clearly identified as the primary identifier for the MS in this scenario. This requirement applies only in the case of an HLR that already includes the MDN in this scenario it is not intended to suggest that the MDN ought to be included.
2007-09-17
4. MC Requirements
2.8 Origination
Requirement Number
2.8-010
The MC shall accept and process a destination address in international format received in an incoming SMDPP from a mobileoriginated SMS. N.S0005-0 v1.0 Ch5 6.5.2.131 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 MC will match an internationally formatted address to its internal tables (e.g. MDN-to-HLR for SMSRequest addressing), and transfer the format to outgoing messages as described elsewhere in this document.
Requirement Number
2.8-015
The MC should accept and process an originating address in international format received in an incoming SMDPP from a mobileoriginated SMS. N.S0005-0 v1.0 Ch5 6.5.2.133 The international format is carried in the Nature of Number field for ANSI-41 parameters. Receipt of an internationally-formatted SMS_OOA parameter would typically require the support of requirements 2.6-010 and 2.4.2-050 in the home and serving networks respectively. Accept and process implies that the MC will match an internationally formatted address to its internal tables (e.g. any per-subscriber provisioned information), and transfer the format to outgoing messages as described elsewhere in this document.
2007-09-17
MC Requirements
Requirement Number
Requirement
2.8-020
[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 correct International Prefix for the MC service area (i.e. no changes to existing CDR). Depending on implementation options, the International Prefix may not be required for existing international SMS destinations the intent of this requirement is to allow the operator the choice to either track the use of PCD-based messaging through billing records, or to avoid any downstream billing system changes due to the introduction of PCD. This requirement applies to billing records produced for both MO- and MT-SMS. This approach may also be extended to removal of the home network Country Code, and prefixing of a national prefix if 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
Requirement
2.8-020a
[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 indicating that an internationally-formatted destination was entered; i.e. as if the mobile was non PCD-capable and the International Prefix had been explicitly entered by the user.. This allows the operator to avoid any downstream billing system changes due to the introduction of PCD. This requirement applies to billing records produced for both MO- and MT-SMS. This approach may also be extended to removal of the home network Country Code, and prefixing of a national prefix if 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.
2007-09-17
MC Requirements
Requirement Number
2.8-030
The MC should transfer a received ANSI-41 destination address in international format to an outgoing inter-MC link (e.g. using SMPP) SMPP v3.4 5.2.5 For a mobile-mobile, inter-operator SMS, the originating subscribers MC should transfer the message to the terminating subscribers MC, typically via a protocol such as SMPP. An SMS hub provider may be used to simplify routing and connections. See 5.1-050 below.
Requirement Number
2.8-040
The MC should transfer a received ANSI-41 originating address in international format to an outgoing inter-MC link (e.g. using SMPP) SMPP v3.4 5.2.5 For a mobile-mobile, inter-operator SMS, the originating subscribers MC should transfer the message to the terminating subscribers MC, typically via a protocol such as SMPP. An SMS hub provider may be used to simplify routing and connections. See 5.1-050 below.
Requirement Number
Requirement
2.8-050
The MC should provide the option to de-internationalize originating and destination addresses before transfer to an outgoing inter-MC link (e.g. using SMPP) for the case where the receiving entity is known not to be capable of handling the international format. The exact format of the addresses used in this case (e.g.: E.164 without international number type; IP of sending country; IP of receiving country) is subject to bilateral agreement and is outside the scope of this document.
2.9 Termination
Requirement Number
2.9-005
The MC shall have the capability to de-internationalize originating address information before sending a mobile-terminated SMDPP. This capability is aimed to protect non-PCD-capable mobiles from receiving an ASCII/International Originating Address in an SMS, which may have unknown handling.
Requirement Number
Requirement Standards Reference Comments Ref Doc. 145, Ver. 1.1
2.9-010
Subject to 5.2-030 below, the MC should transfer an internationallyformatted destination address received on incoming messages to the MT SMDPP). This requirement applies both to messages received via ANSI-41, 2007-09-17
MC Requirements
Requirement Number
2.9-010
and via other interfaces (e.g. SMPP).
Requirement Number
2.9-015
Subject to 5.2-005 & -040, the MC should transfer an internationallyformatted originating address received on incoming messages to the MT SMDPP). This requirement applies both to messages received via ANSI-41, and via other interfaces (e.g. SMPP).
2007-09-17
MC Requirements
Requirement Number
2.9-020
The MC shall have a configurable option to provide the MDN to the HLR in international or national format in the SMSREQ. This requirement only applies to MCs that support IS-841. The MDN (received as a destination address in an incoming message) may need to be internationalized or de-internationalized as appropriate, based on the HLR capabilities.
Requirement Number
2.9-030
The MC should have the capability to internationalize or deinternationalize the MDN if used to populate the SMS_ODA (and possibly SMS_DA) parameters, to match the value sent by the HLR. A mobile-to-mobile SMS sent by a subscriber to an internationallyformatted destination may carry the (internationally-formatted) MDN as the SMS_ODA in the resulting MT SMDPP. If the HLR only sends a nationally-formatted MDN in the subscriber profile, and the serving MSC matches on MDN/SMS_ODA for SMS delivery, use of the internationally-formatted SMS_ODA could result in a mismatch and delivery failure. The MC should be configured to match the value sent by the HLR, and to convert from the originator-entered format, as appropriate.
2007-09-17
MC Requirements
Requirement Number
2.9-040
The MC may have the capability to internationalize the SMS_OOA parameter if it is known that the destination subscriber is roaming outside his/her home E.164 country. Per requirement 2.9-005, and 2.9-060, this would only be used if it were known that the MS could accept the address in this format. By extension from 2.7.1-010, it is debatable whether the MC is logically required to associate the received SMS_Address with a geographic region, even if that information may, in practice, be preconfigured or derived (e.g. from MCC if SMSADDR is E.212 GT).
2007-09-17
MC Requirements
Requirement Number
2.9-050
The MC may have the capability to internationalize the IS-637 Callback Number sub-parameter if it is known that the destination subscriber is roaming outside his/her home E.164 country. By extension from 2.7.1-010. It is debatable whether the MC is logically required to associate the received SMS_Address with a geographic region, even if that information may, in practice, be preconfigured or derived (e.g. from MCC if SMSADDR is E.212 GT).
Requirement Number
2.9-060
The MC may maintain a local flag which defines whether the MS can accept international-formatted digits for presentation. This flag can be used to modify the logic in 2.9-040 & 2.9-050. Note that this flag may not be practical in the case of an R-UIM-based subscription, where the MS capabilities may change depending on which ME currently hosts the R-UIM.
2007-09-17
MC Requirements
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
2007-09-17
MC Requirements
2.11 Voice Scenarios
2007-09-17

Plus Code Dialing Requirements

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Plus Code Dialing Requirements

Diunggah oleh

Hak Cipta:

Format Tersedia

Plus Code Dialing Requirements

CDG Document 145 Version 1.1