Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
3GPP TS 23.003
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 11
Keywords
GSM, UMTS, addressing
Internet
http://www.3gpp.org
3GPP
Release 11
Contents
Contents....................................................................................................................................................3 Foreword...................................................................................................................................................8 1 Scope......................................................................................................................................................9
1.1 References..............................................................................................................................................................9 1.1.1 Normative references..........................................................................................................................................9 1.1.2 Informative references......................................................................................................................................13 1.2 Abbreviations.......................................................................................................................................................13 1.3 General comments to references..........................................................................................................................13 1.4 Conventions on bit ordering.................................................................................................................................13
Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
2012, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC). All rights reserved UMTS is a Trade Mark of ETSI registered for the benefit of its members 3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners GSM and the GSM logo are registered and owned by the GSM Association
3GPP
Release 11
3GPP
Release 11
11 Identification of Localised Service Area............................................................................................37 12 Identification of PLMN, RNC, Service Area, CN domain and Shared Network Area.......................37
12.1 PLMN Identifier.................................................................................................................................................37 12.2 CN Domain Identifier........................................................................................................................................37 12.3 CN Identifier......................................................................................................................................................38 12.4 RNC Identifier....................................................................................................................................................38 12.5 Service Area Identifier.......................................................................................................................................38 12.6 Shared Network Area Identifier.........................................................................................................................38
13 Numbering, addressing and identification within the IP multimedia core network subsystem..........39
13.1 Introduction........................................................................................................................................................39 13.2 Home network domain name.............................................................................................................................39 13.3 Private User Identity..........................................................................................................................................39 13.4 Public User Identity............................................................................................................................................40 13.4A Wildcarded Public User Identity.....................................................................................................................40 13.4B Temporary Public User Identity......................................................................................................................41 13.5 Public Service Identity (PSI)..............................................................................................................................41 13.5A Private Service Identity...................................................................................................................................42 13.6 Anonymous User Identity..................................................................................................................................42 13.7 Unavailable User Identity..................................................................................................................................42 13.8 Instance-ID ........................................................................................................................................................42 13.9 XCAP Root URI................................................................................................................................................42 13.9.1 XCAP Root URI on Ut interface....................................................................................................................42 13.9.1.1 General 42 13.9.1.2 Format of XCAP Root URI..........................................................................................................................43
3GPP
Release 11
18 Addressing and Identification for IMS Service Continuity and Single-Radio Voice Call Continuity 54
18.1 Introduction........................................................................................................................................................54 18.2 CS Domain Routeing Number (CSRN).............................................................................................................54 18.3 IP Multimedia Routeing Number (IMRN).........................................................................................................54 18.4 Session Transfer Number (STN)........................................................................................................................54 18.5 Session Transfer Identifier (STI).......................................................................................................................54 18.6 Session Transfer Number for Single Radio Voice Call Continuity (STN-SR)..................................................55 18.7 Correlation MSISDN.........................................................................................................................................55 18.8 Transfer Identifier for CS to PS Single Radio Voice Call Continuity (STI-rSR)..............................................55 18.9 Additional MSISDN...........................................................................................................................................55
19 Numbering, addressing and identification for the Evolved Packet Core (EPC)..................................55
19.1 Introduction........................................................................................................................................................55 19.2 Home Network Realm/Domain..........................................................................................................................55 19.3 3GPP access to non-3GPP access interworking.................................................................................................56 19.3.1 Introduction.....................................................................................................................................................56 19.3.2 Root NAI.........................................................................................................................................................56 19.3.3 Decorated NAI................................................................................................................................................57 19.3.4 Fast Re-authentication NAI.............................................................................................................................57 19.3.5 Pseudonym Identities......................................................................................................................................58 19.3.6 Emergency NAI for Limited Service State.....................................................................................................59 19.4 Identifiers for Domain Name System procedures..............................................................................................59 19.4.1 Introduction.....................................................................................................................................................59 19.4.2 Fully Qualified Domain Names (FQDNs)......................................................................................................60 19.4.2.1 General 60 19.4.2.2 Access Point Name FQDN (APN-FQDN)...................................................................................................60 19.4.2.2.1 Structure 60 19.4.2.2.2 Void 60 19.4.2.2.3 Void 60 19.4.2.2.4 Void 60 19.4.2.3 Tracking Area Identity (TAI).......................................................................................................................60 19.4.2.4 Mobility Management Entity (MME)..........................................................................................................61 19.4.2.5 Routing Area Identity (RAI) - EPC.............................................................................................................61 19.4.2.6 Serving GPRS Support Node (SGSN) within SGSN pool...........................................................................62 19.4.2.7 Target RNC-ID for U-TRAN.......................................................................................................................62 19.4.2.8 DNS subdomain for operator usage in EPC.................................................................................................63 19.4.2.9 ePDG Fully Qualified Domain Name..........................................................................................................63 19.4.2.10 Global eNodeB-ID for eNodeB.................................................................................................................63 19.4.3 Service and Protocol service names for 3GPP................................................................................................63 19.5 Access Network Identity...................................................................................................................................64 19.6 E-UTRAN Cell Identity (ECI) and E-UTRAN Cell Global Identification (ECGI)...........................................64 19.7 Identifiers for communications with packet data networks and applications....................................................65 19.7.1 Introduction.....................................................................................................................................................65 19.7.2 External Identifier ..........................................................................................................................................65
3GPP
Release 11
23 Numbering, addressing and identification for the Relay Node OAM System....................................69
23.1 Introduction........................................................................................................................................................69 23.2 OAM System Realm/Domain............................................................................................................................70 23.3 Identifiers for Domain Name System procedures..............................................................................................70 23.3.1 Introduction.....................................................................................................................................................70 23.3.2 Fully Qualified Domain Names (FQDNs)......................................................................................................70 23.3.2.1 General 70 23.3.2.2 Relay Node Vendor-Specific OAM System................................................................................................70
Annex A (informative): Colour Codes.........................................................................................72 A.1 Utilization of the BSIC.....................................................................................................................72 A.2 Guidance for planning......................................................................................................................72 A.3 Example of PLMN Colour Codes (NCCs) for the European region.................................................73 Annex B (normative): IMEI Check Digit computation............................................................74 B.1 Representation of IMEI....................................................................................................................74 B.2 Computation of CD for an IMEI.......................................................................................................74 B.3 Example of computation...................................................................................................................74 Annex C (normative): Naming convention...............................................................................76 C.1 Routing Area Identities.....................................................................................................................76 C.2 GPRS Support Nodes.......................................................................................................................77 C.3 Target ID..........................................................................................................................................77 Annex D (informative): Applicability and use of the ".3gppnetwork.org" domain name.......78 Annex E (normative): Procedure for sub-domain allocation..................................................79 Annex F (informative): Change history......................................................................................80
3GPP
Release 11
Foreword
This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP). The present document defines the principal purpose and use of International Mobile station Equipment Identities (IMEI) within the digital cellular telecommunications system and the 3GPP system. The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 11
Scope
The present document defines the principal purpose and use of International Mobile station Equipment Identities (IMEI) within the digital cellular telecommunications system and the 3GPP system. The present document defines: a) an identification plan for mobile subscribers in the GSM system; b) principles of assigning telephone and ISDN numbers to MSs in the country of registration of the MS; c) principles of assigning Mobile Station (MS) roaming numbers to visiting MSs; d) an identification plan for location areas, routing areas, and base stations in the GSM system; e) an identification plan for MSCs, SGSNs, GGSNs, and location registers in the GSM system; f) principles of assigning international mobile equipment identities; g) principles of assigning zones for regional subscription; h) an identification plan for groups of subscribers to the Voice Group Call Service (VGCS) and to the Voice Broadcast Service (VBS); and identification plan for voice group calls and voice broadcast calls; an identification plan for group call areas; i) principles for assigning Packet Data Protocol (PDP) addresses to mobile stations; j) an identification plan for point-to-multipoint data transmission groups; k) an identification plan for CN domain, RNC and service area in the UTRAN system. l) an identification plan for mobile subscribers in the WLAN system. m) addressing and identification for IMS Service Continuity n) an identification plan together with principles of assignment and mapping of identities for the Evolved Packet System
1.1 References
1.1.1 Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] [2] [3] [4] 3GPP TS 21.905: "Vocabulary for 3GPP Specifications ". 3GPP TS 23.008: "Organization of subscriber data". 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2" 3GPP TS 23.070: "Routeing of calls to/from Public Data Networks (PDN)".
3GPP
Release 11
10
[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36]
3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 3". 3GPP TS 29.060: "GPRS Tunnelling protocol (GTP) across the Gn and Gp interface". 3GPP TS 43.020: "Digital cellular telecommunications system (Phase 2+); Security related network functions". void 3GPP TS 51.011: " Specification of the Subscriber Identity Module - Mobile Equipment (SIM ME) interface". ITU-T Recommendation E.164: "The international public telecommunication numbering plan". ITU-T Recommendation E.212: "The international identification plan for mobile terminals and mobile users". ITU-T Recommendation E.213: "Telephone and ISDN numbering plan for land Mobile Stations in public land mobile networks (PLMN)". ITU-T Recommendation X.121: "International numbering plan for public data networks". IETF RFC 791: "Internet Protocol". IETF RFC 2373: "IP Version 6 Addressing Architecture". 3GPP TS 25.401: "UTRAN Overall Description". 3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling". IETF RFC 2181: "Clarifications to the DNS Specification". IETF RFC 1035: "Domain Names - Implementation and Specification". IETF RFC 1123: "Requirements for Internet Hosts -- Application and Support". IETF RFC 2462: "IPv6 Stateless Address Autoconfiguration". IETF RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". 3GPP TS 23.236: "Intra Domain Connection of RAN Nodes to Multiple CN Nodes". 3GPP TS 23.228: "IP Multimedia (IM) Subsystem Stage 2" Void IETF RFC 3261: "SIP: Session Initiation Protocol" 3GPP TS 31.102: "Characteristics of the USIM Application." Void 3GPP TS 44.118: "Radio Resource Control (RRC) Protocol, Iu Mode". 3GPP TS 23.073: "Support of Localised Service Area (SoLSA); Stage 2" 3GPP TS 29.002: "Mobile Application Part (MAP) specification" 3GPP TS 22.016: "International Mobile Equipment Identities (IMEI)" Void Void 3GPP TS 45.056: "CTS-FP Radio Sub-system" 3GPP TS 42.009: "Security aspects" [currently not being raised to rel-5 Pete H. looking into it]
3GPP
Release 11
11
[37] [38] [39] [40] [41] [42] [43] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [58] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70]
3GPP TS 25.423: "UTRAN Iur interface RNSAP signalling" 3GPP TS 25.419: "UTRAN Iu-BC interface: Service Area Broadcast Protocol (SABP)" 3GPP TS 25.410: "UTRAN Iu Interface: General Aspects and Principles" ISO/IEC 7812: "Identification cards - Numbering system and registration procedure for issuer identifiers" Void 3GPP TS 33.102 "3G security; Security architecture" 3GPP TS 43.130: "Iur-g interface; Stage 2" IETF RFC 3966: "The tel URI for Telephone Numbers" 3GPP TS 44.068: "Group Call Control (GCC) protocol". 3GPP TS 44.069: "Broadcast Call Control (BCC) Protocol ". 3GPP TS 24.234: "3GPP System to WLAN Interworking; UE to Network protocols; Stage 3". Void IETF RFC 4187: "EAP AKA Authentication". IETF RFC 4186: "EAP SIM Authentication". 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description" IETF RFC 4282: "The Network Access Identifier". IETF RFC 2279: "UTF-8, a transformation format of ISO 10646". 3GPP TS 33.234: "Wireless Local Area Network (WLAN) interworking security". Void 3GPP TS 33.221 "Generic Authentication Architecture (GAA); Support for Subscriber Certificates". IEEE 1003.1-2004, Part 1: Base Definitions 3GPP TS 43.318: "Generic Access to the A/Gb interface; Stage 2" 3GPP TS 44.318: "Generic Access (GA) to the A/Gb interface; Mobile GA interface layer 3 specification" 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks" IETF RFC 2606: "Reserved Top Level DNS Names" Void 3GPP TS 51.011 Release 4: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface" 3GPP2 X.S0013-004: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3" 3GPP TS 23.402: "Architecture Enhancements for non-3GPP accesses" 3GPP TS 33.402: "3GPP System Architecture Evolution: Security Aspects of non-3GPP accesses" 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2"
3GPP
Release 11
12
3GPP TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity" 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" 3GPP TS 29.303: "Domain Name System Procedures; Stage 3" IETF RFC 3958: "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)" Void 3GPP TS 23.237: "Mobility between 3GPP-Wireless Local Area Network (WLAN) interworking and 3GPP systems" 3GPP TS 24.302: "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3" 3GPP TS 23.273: "Evolved Packet System; 3GPP EPS AAA Interfaces" IETF Internet-Draft, draft-montemurro-gsma-imei-urn-09 (January 2012): "A Uniform Resource Name Namespace For The GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)". IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace". 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". IETF RFC5448: "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') " 3GPP TS 22.011: "Service accessibility". 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ; S1 Application Protocol (S1AP)". Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48), http://standards.ieee.org/regauth/oui/tutorials/EUI48.html GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html The Broadband Forum TR-069: "CPE WAN Management Protocol v1.1", Issue 1 Amendment 2, December 2007 3GPP TS 29.274: "Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3". 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture". 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3". 3GPP TS 36.300: " Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC)". 3GPP TS 31.103: "IP Multimedia Services Identity Module (ISIM) application". IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)". 3GPP TS 29.229: " Cx and Dx interfaces based on the Diameter protocol; Protocol details". 3GPP TS 29.329: " Sh Interface based on the Diameter protocol; Protocol details".
[80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96]
3GPP
Release 11
13
[97] [98]
3GPP TS 29.165: "Inter-IMS Network to Network Interface (NNI); Stage 3". 3GPP TS 23.682: "Architecture Enhancements to facilitate communications with Packet Data Networks and Applications".
[57] [59]
1.2 Abbreviations
For the purposes of the present document, the abbreviations defined in 3GPP TS 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 [1]. EPS GUTI ICS MTC UUID Evolved Packet System Globally Unique Temporary UE Identity IMS Centralized Services Machine Type Communication Universally Unique IDentifier
When an identity appears in other Technical Specifications, the following conventions hold if not indicated otherwise: digits are numbered by order of significance, with digit 1 being the most significant; bits are numbered by order of significance, with the lowest bit number corresponding to the least significant bit.
3GPP
Release 11
14
2.1 General
A unique International Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber in the GSM/UMTS/EPS system. NOTE: This IMSI is the concept referred to by ITU-T as "International Mobile Station Identity".
In order to support the subscriber identity confidentiality service the VLRs, SGSNs and MME may allocate Temporary Mobile Subscriber Identities (TMSI) to visiting mobile subscribers. The VLR,SGSN and MME must be capable of correlating an allocated TMSI with the IMSI of the MS to which it is allocated. An MS may be allocated three TMSIs, one for services provided through the MSC, one for services provided through the SGSN (P-TMSI for short) and one for the services provided via the MME (M-TMSI part GUTI for short). For addressing on resources used for GPRS, a Temporary Logical Link Identity (TLLI) is used. The TLLI to use is built by the MS either on the basis of the P-TMSI (local or foreign TLLI), or directly (random TLLI). In order to speed up the search for subscriber data in the VLR a supplementary Local Mobile Station Identity (LMSI) is defined. The LMSI may be allocated by the VLR at location updating and is sent to the HLR together with the IMSI. The HLR makes no use of it but includes it together with the IMSI in all messages sent to the VLR concerning that MS.
N o t m o r e t h a n 1 5 d ig its 3 d ig it s M C C 2 or 3 d ig its M N C N M S I IM S I
Figure 1: Structure of IMSI IMSI is composed of three parts: 1) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of the mobile subscriber; 2) Mobile Network Code (MNC) consisting of two or three digits for GSM/UMTS applications. The MNC identifies the home PLMN of the mobile subscriber. The length of the MNC (two or three digits) depends on the value of the MCC. A mixture of two and three digit MNC codes within a single MCC area is not recommended and is outside the scope of this specification. 3) Mobile Subscriber Identification Number (MSIN) identifying the mobile subscriber within a PLMN. The National Mobile Subscriber Identity (NMSI) consists of the Mobile Network Code and the Mobile Subscriber Identification Number.
M S IN
3GPP
Release 11
15
3GPP
Release 11
16
A local TLLI is built by an MS which has a valid P-TMSI as follows: bits 31 down to 30 are set to 1; and bits 29 down to 0 are set equal to bits 29 to 0 of the P-TMSI. A foreign TLLI is built by an MS which has a valid P-TMSI as follows: bit 31 is set to 1 and bit 30 is set to 0; and bits 29 down to 0 are set equal to bits 29 to 0 of the P-TMSI. A random TLLI is built by an MS as follows: bit 31 is set to 0; bits 30 down to 27 are set to 1; and bits 0 to 26 are chosen randomly. An auxiliary TLLI is built by the SGSN as follows: bit 31 is set to 0; bits 30 down to 28 are set to 1; bit 27 is set to 0; and bits 0 to 26 can be assigned independently. Other types of TLLI may be introduced in the future. Part of the TLLI codespace is re-used in GERAN to allow for the inclusion of the GERAN Radio Network Temporary Identifier in RLC/MAC messages. The G-RNTI is defined in 3GPP TS 44.118 [29]. The structure of the TLLI is summarised in table 1. Table 1: TLLI structure
31 1 1 0 0 0 0 0 0 30 1 0 1 1 1 1 0 0 29 T T 1 1 1 0 0 0 28 T T 1 1 0 X 0 1 27 T T 1 0 X X G R 26 to 0 T T R A X X G R Type of TLLI Local TLLI Foreign TLLI Random TLLI Auxiliary TLLI Reserved Reserved Part of the assigned G-RNTI Random G-RNTI
'T', 'R', 'A' and 'X' indicate bits which can take any value for the type of TLLI. More precisely, 'T' indicates bits derived from a P-TMSI, 'R' indicates bits chosen randomly, 'A' indicates bits chosen by the SGSN, 'G' indicates bits derived from the assigned G-RNTI and 'X' indicates bits in reserved ranges.
3GPP
Release 11
17
Within the MME, the mobile shall be identified by the M-TMSI. The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI). The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC). The GUTI shall be constructed from the GUMMEI and the M-TMSI. For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI. The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools. The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request). The format and size of the GUTI is therefore the following: <GUTI> = <GUMMEI><M-TMSI>, where <GUMMEI> = <MCC><MNC><MME Identifier> and <MME Identifier> = <MME Group ID><MME Code> MCC and MNC shall have the same field size as in earlier 3GPP systems. M-TMSI shall be of 32 bits length. MME Group ID shall be of 16 bits length. MME Code shall be of 8 bits length.
2.8.2 Mapping between Temporary and Area Identities for the EUTRAN and the UTRAN/GERAN based systems
2.8.2.0 Introduction
This section provides information on the mapping of the temporary and location area identities, e.g. for the construction of the Routeing Area Update Request message in GERAN/UTRAN or Tracking Area Update Request message in E-UTRAN. In GERAN and UTRAN: <RAI> = <MCC><MNC><LAC><RAC>
3GPP
Release 11
18
<P-TMSI/TLLI> includes the mapped NRI P-TMSI shall be of 32 bits length where the two topmost bits are reserved and always set to '11'. Hence, for a UE which may handover to GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI are set to '11' (see subclause 2.8.2.1.3). 3GPP TS 23.236 [23] specifies that the NRI field is of variable length and shall be mapped into the P-TMSI starting at bit 23 and down to bit 14. The most significant bit of the NRI is located at bit 23 of the P-TMSI regardless of the configured length of the NRI. To support mobility between GERAN/UTRAN and E-UTRAN, the NRI length is limited to a maximum of 8 bits to be compatible for the mapping to MME Code within GUTI (see subclause 2.8.2.2). The P-TMSI and NRI are defined elsewhere in this specification. In the case of a combined MME-SGSN node, the NRI of the SGSN part and the MME code of the MME part, refer to the same combined node. RAN configuration allows NAS messages on GERAN/UTRAN and E-UTRAN to be routed to the same combined node. The same or different values of NRI and MME code may be used for a combined node.
2.8.2.1
2.8.2.1.1
This subclause addresses the case when a UE moves from an MME to an SGSN. The SGSN may be either an S4 SGSN or a Gn/Gp SGSN.
2.8.2.1.2
Mapping in the UE
When a UE moves from an E-UTRAN to a GERAN/UTRAN, the UE needs to map the GUTI to an RAI, a P-TMSI and a P-TMSI Signature, for them to be sent to the SGSN. For GERAN, the TLLI is derived from the P-TMSI by the UE and is a foreign TLLI (see subclause 2.6). The mapping of the GUTI shall be done to the combination of RAI of GERAN / UTRAN and the P-TMSI: E-UTRAN <MCC> maps to GERAN/UTRAN <MCC> E-UTRAN <MNC> maps to GERAN/UTRAN <MNC> E-UTRAN <MME Group ID> maps to GERAN/UTRAN <LAC> E-UTRAN <MME Code> maps to GERAN/UTRAN <RAC> and is also copied into the 8 most significant bits of the NRI field within the P-TMSI; E-UTRAN <M-TMSI> maps as follows: 6 bits of the E-UTRAN <M-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the GERAN/UTRAN <P-TMSI>; 16 bits of the E-UTRAN <M-TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the GERAN/UTRAN <P-TMSI>; and the remaining 8 bits of the E-UTRAN <M-TMSI> are mapped into the 8 MBS bits of the <P-TMSI signature> field.
The UE shall fill the remaining 2 octets of the <P-TMSI signature> according to subclauses 9.1.1, 9.4.1, 10.2.1, or 10.5.1 of 3GPP TS.33.401 [89] , as appropriate, for RAU/Attach procedures. For UTRAN, the 10-bit long NRI bits are masked out from the P-TMSI and are also supplied by the UE to the RAN node as IDNNS (Intra Domain NAS Node Selector) (see 3GPP TS 23.236 [23]). However, the RAN configured NRI length should not exceed 8 bits.
2.8.2.1.3
A new SGSN attempts to retrieve information regarding the UE, e.g. the IMSI, from the old MME. In order to find the UE context, the MME needs to map the RAI, P-TMSI (or TLLI) and the P-TMSI Signature (sent by the SGSN) to create the GUTI and compare it with the stored GUTI.
3GPP
Release 11
19
The MME shall perform a reverse mapping to the mapping procedure specified in subclause 2.8.2.1.2 "Mapping in the UE" (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of the messaging). For the reverse mapping, the E-UTRAN <MME Code> within the GUTI shall be set either to bits 23 to 16 of the GERAN/UTRAN <P-TMSI> (i.e., the NRI field) or to the GERAN/UTRAN <RAC>. For GERAN TLLI, the old MME replaces the two topmost bits of TLLI, received from new SGSN via GTPv1, with '11' before mapping the TLLI to the GUTI used for looking up the "UE Context".
2.8.2.2
2.8.2.2.1
This subclause addresses the case when a UE moves from an SGSN to an MME (i.e. during a TAU or an Attach to MME). The SGSN may be either an S4 SGSN or a Gn/Gp SGSN.
2.8.2.2.2
Mapping in the UE
When the UE moves from the GERAN/UTRAN to the E-UTRAN, the UE needs to map the RAI and P-TMSI to a GUTI to be sent to the MME. The P-TMSI signature is sent intact to the MME. The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN shall be performed as follows: GERAN/UTRAN <MCC> maps to E-UTRAN <MCC> GERAN/UTRAN <MNC> maps to E-UTRAN <MNC> GERAN/UTRAN <LAC> maps to E-UTRAN <MME Group ID> GERAN/UTRAN <RAC> maps into bit 23 and down to bit 16 of the M-TMSI The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code. GERAN/UTRAN <P-TMSI> maps as follows: 6 bits of the GERAN/UTRAN <P-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the E-UTRAN <M-TMSI>; 16 bits of the GERAN/UTRAN <P-TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the E-UTRAN <M-TMSI>.
The values of <LAC> and <MME group id> shall be disjoint, so that they can be differentiated. The most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set to one. Based on this definition, the most significant bit of the <MME group id> can be used to distinguish the node type, i.e. whether it is an MME or SGSN. The UE copies the received old SGSNs <LAC> into the <MME Group ID> when sending a message to an MME, regardless of the value of the most significant bit of the <LAC>. In networks where this definition is not applied (e.g. in networks already configured with LAC with the most significant bit set to 1 before LTE deployment), the information in the TAU/RAU request indicating whether the provided GUTI/P-TMSI is "native" (i.e. no system change) or "mapped" (i.e. system change) can be used to distinguish the node type for UEs implemented according to this release of the specification (see 3GPP TS 24.301 [90] and 3GPP TS 24.008 [5]). Specific network implementations still satisfying 3GPP standard interfaces can be used for pre-Rel-10 UEs to distinguish the node type. NOTE 1: As an example, at NAS level, the MME/SGSN can retrieve the old SGSN/MME by using additional GUTI/additional RAI/P-TMSI with double DNS query to solve the first time the UE moves between EUTRAN and GERAN/UTRAN. As another example, the MME/SGSN can retrieve the old SGSN/MME by using double DNS query.
2.8.2.2.3
In order to retrieve the UE's information, e.g. the IMSI, from the old SGSN, the new MME extracts only the RAI and PTMSI from the GUTI via the reverse mapping procedure to that specified in subclause 2.8.2.2.2. This is done in order to be able to include the mapped RAI and P-TMSI, along with the P-TMSI Signature received by the MME from the UE, in the corresponding message sent to the old SGSN (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of
3GPP
Release 11
20
the messaging). The old SGSN compares the received RAI, P-TMSI and P-TMSI Signature with the stored values for identifying the UE.
3.1 General
The structure of the following numbers is defined below: the number used by a subscriber of a fixed (or mobile) network to call a mobile station of a PLMN; the network addresses used for packet data communication between a mobile station and a fixed (or mobile) station; mobile station roaming numbers.
One or more numbers of the ISDN numbering plan shall be assigned to a mobile station to be used for all calls to that station, i.e. the assignment of at least one MSISDN to a mobile station is mandatory. NOTE: For card operated stations the ISDN number should be assigned to the holder of the card (personal number).
3GPP
Release 11
21
CC
NDC
SN
Figure 2: Number Structure of MSISDN The number consists of: Country Code (CC) of the country in which the MS is registered, followed by: National (significant) mobile number, which consists of: National Destination Code (NDC) and Subscriber Number (SN).
For GSM/UMTS applications, a National Destination Code is allocated to each PLMN. In some countries more than one NDC may be required for each PLMN. The composition of the MS international ISDN number should be such that it can be used as a global title address in the Signalling Connection Control Part (SCCP) for routeing messages to the home location register of the MS. The country code (CC) and the national destination code (NDC) will provide such routeing information. If further routeing information is required, it should be contained in the first few digits of the subscriber number (SN). A sub-address may be appended to an ISDN number for use in call setup and in supplementary service operations where an ISDN number is required (see ITU-T Recommendations E.164, clause 11.2 and X.213 annex A). The sub-address is transferred to the terminal equipment denoted by the ISDN number. The maximum length of a sub-address is 20 octets, including one octet to identify the coding scheme for the sub-address (see ITU-T Recommendation X.213, annex A). All coding schemes described in ITU-T Recommendation X.213, annex A are supported in GSM and UMTS.
The MSRN shall not be used for subscriber dialling. It should be noted that the MSRN can be identical to the MSISDN (clause 3.3) in certain circumstances. In order to discriminate between subscriber generated access to these numbers and re-routeing performed by the network, re-routeing or redirection indicators or other signalling means should be used, if available.
3GPP
Release 11
22
M C C
M N C
LAC
L o c a t io n A r e a Id e n tif ic a tio n
Figure 3: Structure of Location Area Identification The LAI is composed of the following elements: Mobile Country Code (MCC) identifies the country in which the GSM PLMN is located. The value of the MCC is the same as the three digit MCC contained in international mobile subscriber identity (IMSI); Mobile Network Code (MNC) is a code identifying the GSM PLMN in that country. The MNC takes the same value as the two or three digit MNC contained in IMSI; Location Area Code (LAC) is a fixed length code (of 2 octets) identifying a location area within a PLMN. This part of the location area identification can be coded using a full hexadecimal representation except for the following reserved hexadecimal values:
3GPP
Release 11
23
0000, and FFFE. These reserved values are used in some special cases when no valid LAI exists in the MS (see 3GPP TS 24.008 [5], 3GPP TS 31.102 [27] and 3GPP TS 51.011 [9]). A specific GSM PLMN code (MCC + MNC) may be broadcast for mobile stations which are not compatible with SoLSA and which do not understand the exclusive access indicator (see 3GPP TS 23.073 [30]). The reserved value of the escape PLMN code is MCC = 901 and MNC = 08.
Figure 4: Structure of Routing Area Identification The RAI is composed of the following elements: A valid Location Area Identity (LAI) as defined in clause 4.1. Invalid LAI values are used in some special cases when no valid RAI exists in the mobile station (see 3GPP TS 24.008 [5], 3GPP TS 31.102 [27] and 3GPP TS 51.011 [9]). Routeing Area Code (RAC) which is a fixed length code (of 1 octet) identifying a routeing area within a location area.
M CC
M N C
LAC
CI
3GPP
Release 11
24
NC C 3 b its P L M N c o lo u r c o d e
BCC 3 b its B S c o lo u r c o d e
Figure 6: Structure of BSIC In the definition of the NCC, care should be taken to ensure that the same NCC is not used in adjacent PLMNs which may use the same BCCH carrier frequencies in neighbouring areas. Therefore, to prevent potential deadlocks, a definition of the NCC appears in annex A. This annex will be reviewed in a co-ordinated manner when a PLMN is created.
RSZI
C C
NDC
ZC Z o n e C o d e , T w o o c te ts
Figure 7: Structure of Regional Subscription Zone Identity (RSZI) The elements of the regional subscription zone identity are: 1) the Country Code (CC) which identifies the country in which the PLMN is located; 2) the National Destination Code (NDC) which identifies the PLMN in that country; 3) the Zone Code (ZC) which identifies a regional subscription zone as a pattern of allowed and not allowed location areas uniquely within that PLMN. CC and NDC are those of an ITU-T E.164 VLR or SGSN number (see clause 5.1) of the PLMN; they are coded with a trailing filler, if required. ZC has fixed length of two octets and is coded in full hexadecimal representation. RSZIs, including the zone codes, are assigned by the VPLMN operator. The zone code is evaluated in the VLR or SGSN by information stored in the VLR or SGSN as a result of administrative action. If a zone code is received by a VLR or SGSN during updating by the HLR and this zone code is related to that VLR or SGSN, the VLR or SGSN shall be able to decide for all its MSC or SGSN areas and all its location areas whether they are allowed or not allowed. For details of assignment of RSZI and of ZC as subscriber data see 3GPP TS 23.008 [2]. For selection of RSZI at location updating by comparison with the leading digits of the VLR or SGSN number and for transfer of ZC from the HLR to VLR and SGSN see 3GPP TS 29.002 [31].
3GPP
Release 11
25
CC
ND C
LSP
Figure 8: Location Number Structure The structure of the locally significant part (LSP) of the location number is a matter for agreement between the PLMN operator and the national numbering authority in the PLMN's country. It is desirable that the location number can be interpreted without the need for detailed knowledge of the internal structure of the PLMN; the LSP should therefore include the national destination code in the national numbering plan for the fixed network which defines the geographic area in which the location lies. The set of location numbers for a PLMN shall be chosen so that a location number can be distinguished from the MSISDN of a subscriber of the PLMN. This will allow the PLMN to trap attempts by users to dial a location number.
3GPP
Release 11
26
<EUI48/64> is the first label which shall be the EUI-48 or EUI-64, represented as a string of 12 or 16 hexadecimal digits including any leading zeros. <REALM> denotes the realm which may consist of 3 labels , e.g. hnb. femtocellvendor.com.
GSN Address Address Type 2 bits Address Length 6 bits Address 4 to 16 octets
Figure 9: Structure of GSN Address The GSN Address is composed of the following elements: 1) The Address Type, which is a fixed length code (of 2 bits) identifying the type of address that is used in the Address field. 2) The Address Length, which is a fixed length code (of 6 bits) identifying the length of the Address field. 3) The Address, which is a variable length field which contains either an IPv4 address or an IPv6 address. Address Type 0 and Address Length 4 are used when Address is an IPv4 address. Address Type 1 and Address Length 16 are used when Address is an IPv6 address. The IP v4 address structure is defined in RFC 791 [14]. The IP v6 address structure is defined in RFC 2373 [15].
3GPP
Release 11
27
6.1 General
The structure and allocation principles of the International Mobile station Equipment Identity and Software Version number (IMEISV) and the International Mobile station Equipment Identity (IMEI) are defined below. The Mobile Station Equipment is uniquely defined by the IMEI or the IMEISV.
Figure 10: Structure of IMEI The IMEI is composed of the following elements (each element shall consist of decimal digits only): Type Allocation Code (TAC). Its length is 8 digits; Serial Number (SNR) is an individual serial number uniquely identifying each equipment within the TAC. Its length is 6 digits; Check Digit (CD) / Spare Digit (SD): If this is the Check Digit see paragraph below; if this digit is Spare Digit it shall be set to zero, when transmitted by the MS.
The IMEI (14 digits) is complemented by a Check Digit (CD). The Check Digit is not part of the digits transmitted when the IMEI is checked, as described below. The Check Digit is intended to avoid manual transmission errors, e.g. when customers register stolen MEs at the operator's customer care desk. The Check Digit is defined according to the Luhn formula, as defined in annex B. NOTE: The Check Digit is not applied to the Software Version Number.
The security requirements of the IMEI are defined in 3GPP TS 22.016 [32].
3GPP
Release 11
28
Figure 11: Structure of IMEISV The IMEISV is composed of the following elements (each element shall consist of decimal digits only): Type Allocation Code (TAC). Its length is 8 digits; Serial Number (SNR) is an individual serial number uniquely identifying each equipment within each TAC. Its length is 6 digits; Software Version Number (SVN) identifies the software version number of the mobile equipment. Its length is 2 digits.
Regarding updates of the IMEISV: The security requirements of 3GPP TS 22.016 [32] apply only to the TAC and SNR, but not to the SVN part of the IMEISV.
3GPP
Release 11
29
Group Call Area ID Voice Group Call Reference / Voice Broadcast Call Reference
Group ID
Figure 12: Voice Group Call Reference / Voice Broadcast Call Reference
Subsystem numbers are used to identify applications within network entities which use SCCP signalling. In GSM and UMTS, subsystem numbers may be used between PLMNs, in which case they are taken from the globally standardized range (1 - 31) or the part of the national network range (129 - 150) reserved for GSM/UMTS use between PLMNs. For use within a PLMN, they are taken from the part of the national network range (32 - 128 & 151 - 254) not reserved for GSM/UMTS use between PLMNs.
3GPP
Release 11
30
0000 1001EIR (MAP); 0000 1010is allocated for evolution (possible Authentication Centre).
In the GPRS backbone, an Access Point Name (APN) is a reference to a GGSN. To support inter-PLMN roaming, the internal GPRS DNS functionality is used to translate the APN into the IP address of the GGSN.
9.0 General
Access Point Name as used in the Domain Name System (DNS) Procedures defined in 3GPP TS 29.303 [73] is specified in subclause 19.4.2.2.
3GPP
Release 11
31
The APN Operator Identifier is placed after the APN Network Identifier. An APN consisting of both the Network Identifier and Operator Identifier corresponds to a DNS name of a GGSN/PGW; the APN has, after encoding as defined in the paragraph below, a maximum length of 100 octets. The encoding of the APN shall follow the Name Syntax defined in RFC 2181 [18], RFC 1035 [19] and RFC 1123 [20]. The APN consists of one or more labels. Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. Following RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1123 [20], the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The APN is not terminated by a length byte of zero. NOTE: A length byte of zero is added by the SGSN/MME at the end of the APN before interrogating a DNS server.
For the purpose of presentation, an APN is usually displayed as a string in which the labels are separated by dots (e.g. "Label1.Label2.Label3").
3GPP
Release 11
32
Alternatively, in the roaming case if the GGSN/PGW from the VPLMN is to be selected, the APN Operator Identifier for the UE is constructed from the serving network PLMN ID. In this case, the APN-OI replacement field, if received, shall be ignored. In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the "mnc<MNC>.mcc<MCC>.gprs" format of the APN OI shall be: <MNC> = 3 digits <MCC> = 3 digits If there are only 2 significant digits in the MNC, one "0" digit is inserted at the left side to fill the 3 digits coding of MNC in the APN OI.
As an example, the APN OI for MCC 345 and MNC 12 will be coded in the DNS as "mnc012.mcc345.gprs". The APN-OI replacement is only used for selecting the GGSN/PGW from the HPLMN. The format of the domain name used in the APN-OI replacement field (as defined in 3GPP TS 23.060 [3] and 3GPP TS 23.401 [72]) is the same as the default APN-OI as defined above except that it may be preceded by one or more labels each separated by a dot. EXAMPLE 1: EXAMPLE 2: province1.mnc012.mcc345.gprs ggsn-cluster-A.provinceB.mnc012.mcc345.gprs
The APN constructed using the APN-OI replacement field is only used for DNS translation. The APN when being sent to other network entities over GTP interfaces shall follow the rules as specified in 3GPP TS 23.060 [3] and 3GPP TS 23.401 [72].
10
3GPP
Release 11
33
The following CTSMSI Type values have been allocated for use by CTS: 00 Default Individual CTSMSI; 01 Reserved; 10 Assigned Individual CTSMSI; 11 Assigned Connectionless Group CTSMSI.
The value FFFFF from the set of Assigned Connectionless Group CTSMSI shall be considered in all CTS-MS as the value of the Connectionless Broadcast Identifier.
3GPP
Release 11
34
NOTE:
The following FPBI Type values have been allocated for use by CTS: 00 FPBI class A: residential and single-cell systems; 01 FPBI class B: multi-cell PABXs. All other values are reserved and CTS-MSs shall treat these values as FPBI class A.
10.3.2.2
FPBI class A
bit No 19 1 +-------------------------------------+ |0 0| | +-------------------+ Type| FPN | FPBI 19 bits <-------------------------------------> Figure 15: Structure of FPBI class A
This class is intended to be used for small residential and private (PBX) single cell CTS-FP.
The FPBI class A is composed of the following elements: FPBI Class A Type. Its length is 2 bits and its value is 00; Fixed Part Number (FPN). Its length is 17 bits. The FPN contains the least significant bits of the Serial Number part of the IFPEI.
3GPP
Release 11
35
10.3.2.3
FPBI class B
bit No 19 1 +-------------------------------------+ |0 1| | +-------------------+ Type| CNN + FPN + RPN | FPBI 19 bits <-------------------------------------> Figure 16: Structure of FPBI class B
This class is reserved for more complex private installation such as multi-cell PABXs.
The FPBI class B is composed of the following elements: FPBI Class B Type. Its length is 2 bits and its value is 01; CTS Network Number (CNN). Its length is defined by the manufacturer or the system installer; Fixed Part Number (FPN). Its length is defined by the manufacturer or the system installer; Radio Part Number (RPN) assigned by the CTS manufacturer or system installer. Its length is defined by the manufacturer or the system installer. RPN is used to separate a maximum of 2RPN length different cells from each other. This defines a cluster of cells supporting intercell handover. RPN length is submitted to a CTS-MS as a result of a successful attachment.
NOTE:
The FPBI Length Indicator shall be set to (2 + CNN Length) for a class B FPBI.
3GPP
Release 11
36
Serial NumbeR (SNR). Its length is 6 decimal digits; Software Version Number (SVN) identifies the software version number of the fixed part equipment. Its length is 2 digits.
Regarding updates of the IFPEI: the TAC, FAC and SNR shall be physically protected against unauthorised change (see 3GPP TS 42.009 [36]); i.e. only the SVN part of the IFPEI can be modified.
The National Fixed Part Subscriber Identity (NFPSI) consists of the CTS Operator Number and the Fixed Part Identification Number.
3GPP
Release 11
37
11
Cells may be grouped into specific localised service areas. Each localised service area is identified by a localised service area identity (LSA ID). No restrictions are placed on what cells may be grouped into a given localised service area. The LSA ID can either be a PLMN significant number or a universal identity. This shall be known both in the networks and in the SIM. The LSA ID consists of 24 bits, numbered from 0 to 23, with bit 0 being the LSB. Bit 0 indicates whether the LSA is a PLMN significant number or a universal LSA. If the bit is set to 0 the LSA is a PLMN significant number; if it is set to 1 it is a universal LSA. The LSA ID shall be composed as shown in figure 19:
LSB 1 bit
12 Identification of PLMN, RNC, Service Area, CN domain and Shared Network Area
The following clauses describe identifiers which are used by both the CN and the UTRAN across the Iu interface. For identifiers which are solely used within the UTRAN, see 3GPP TS 25.401 [16]. NOTE: in the following subclauses, the double vertical bar notation || indicates the concatenation operator.
The MCC and MNC are predefined within a UTRAN, and set in the RNC via O&M.
3GPP
Release 11
38
The LAC and RAC are defined by the operator, and set in the RNC via O&M. For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17].
12.3 CN Identifier
A CN node is uniquely identified within a PLMN by its CN Identifier (CN-Id). The CN-Id together with the PLMN identifier globally identifies the CN node. The CN-Id together with the PLMN-Id is used as the CN node identifier in RANAP signalling over the Iu interface. Global CN-Id = PLMN-Id || CN-Id The CN-Id is defined by the operator, and set in the nodes via O&M. For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17].
The RNC-Id is defined by the operator, and set in the RNC via O&M For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. For the usage of this identifier on Iur-g, see 3GPP TS 43.130 [43].
The SAC is defined by the operator, and set in the RNC via O&M. For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 3GPP TS 25.423 [37] and 3GPP TS 25.419 [38] define the use of this identifier in RNSAP and SABP signalling. A cell may belong to one or two Service Areas. If it belongs to two Service Areas, one is applicable in the Broadcast (BC) domain and the other is applicable in both the CS and PS domains. The Broadcast (BC) domain requires that its Service Areas each consist of only one cell. This does not limit the use of Service Areas for other domains. Refer to 3GPP TS 25.410 [39] for a definition of the BC domain.
3GPP
Release 11
39
The SNAC is defined by the operator. For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17].
13
Numbering, addressing and identification within the IP multimedia core network subsystem
13.1 Introduction
This clause describes the format of the parameters needed to access the IP multimedia core network subsystem. For further information on the use of the parameters see 3GPP TS 23.228 [24] and 3GPP TS 29.163 [63]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document. For more information on the ".invalid" top level domain see IETF RFC 2606 [64].
which gives the home network domain name: ims.mnc015.mcc234.3gppnetwork.org. For 3GPP2 systems, if there is no IMC present, the UE shall derive the home network domain name as described in Annex C of 3GPP2 X.S0013-004 [67].
For 3GPP systems, if there is no ISIM application, the private user identity is not known. If the private user identity is not known, the private user identity shall be derived from the IMSI. The following steps show how to build the private user identity out of the IMSI:
3GPP
Release 11
40
1. Use the whole string of digits as the username part of the private user identity; and 2. convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in subclause 13.2. The result will be a private user identity of the form "<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org". For example: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identity then takes the form "234150999999999@ims.mnc015.mcc234.3gppnetwork.org". For 3GPP2 systems, if there is no IMC present, the UE shall derive the private user identity as described in Annex C of 3GPP2 X.S0013-004 [67].
3GPP
Release 11
41
For 3GPP2 systems, if there is no IMC present, the UE shall derive the public user identity as described in Annex C of 3GPP2 X.S0013-004 [67].
3GPP
Release 11
42
13.8 Instance-ID
An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration. When an IMEI is available, the instance-id shall take the form of a IMEI URN (see draft-montemurro-gsma-imei-urn [79]). The format of the instance-id shall take the form "urn:gsma:imei:<gsma-specifier-defined-substring>" where by the the gsma-specifier-defined-substring shall be the IMEI encoded as defined in draft-montemurro-gsma-imei-urn [79]. The optional <gsma-specifier-defined-param> parameters shall not be included in the instance-id. An example of such an instance-id is as follows: EXAMPLE: urn:gsma:imei:90420156-025763-0
If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in IETF RFC 4122 [80]. An example of such an instance-id is as follows: EXAMPLE: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81].
XCAP Root URI is an HTTP URI that represents the XCAP Root. Although a valid URI, the XCAP Root URI does not correspond to an actual resource.
3GPP
Release 11
43
13.9.1.2
The XCAP Root URI, as defined in IETF RFC 4825 [94], is an HTTP URI that should have the following format: "http://xcap.<domain>" in which "<domain>" identifies the domain hosting the XCAP server. NOTE 1: The XCAP Root URI does not contain a port portion or an abs path portion of a standard HTTP URI. If a preconfigured or provisioned XCAP Root URI is available then the UE shall use it. When a preconfigured or provisioned XCAP Root URI does not exist then the UE shall create the XCAP Root URI as follows: The first label shall be "xcap". The next label(s) shall identify the home network as follows: 1. When the UE has an ISIM, the domain name from the IMPI shall be used (see 3GPP TS 31.103 [93]) as follows: a. if the last two labels of the domain name from the IMPI are "3gppnetwork.org": i. the next labels shall be all labels of the domain name from the IMPI apart from the last two labels; and ii. the last three labels shall be "pub.3gppnetwork.org"; b. if the last two labels of the domain name from the IMPI are other than the "3gppnetwork.org": i. the next labels shall be all labels of the domain name from the IMPI; 2. When the UE has a USIM and does not have ISIM, the home network shall be "ims.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" where <MNC> and <MCC> shall be derived from the components of the IMSI defined in subclause 2.2. If there are only two significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the FQDN of XCAP Root URI. As an example for the case when the UE has ISIM, where the IMPI is "user@operator.com", the overall XCAP Root URI used by the UE would be: "http://xcap.operator.com". As an example for the case when the UE has ISIM, where the IMPI is "234150999999999@ims.mnc015.mcc234.3gppnetwork.org", the overall XCAP Root URI used by the UE would be: "xcap.ims.mnc015.mcc234.pub.3gppnetwork.org". As an example for the case when the UE has USIM and does not have ISIM, where the MCC is 345 and the MNC is 12, the overall XCAP Root URI created and used by the UE would be: "xcap.ims.mnc012.mcc345.pub.3gppnetwork.org"
14
14.1 Introduction
This clause describes the format of the parameters needed to access the 3GPP system supporting the WLAN interworking. For further information on the use of the parameters see 3GPP TS 24.234 [48]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document.
3GPP
Release 11
44
3GPP
Release 11
45
The realm part of Decorated NAI consists of 'otherrealm', see the IETF draft 2486-bisRFC 4282 [53]. 'Homerealm' is the realm as specified in clause 14.2, using the HPLMN ID ('homeMCC' + 'homeMNC)'. 'Otherrealm' is the realm built using the PLMN ID (visitedMCC + visited MNC) of the PLMN selected as a result of WLAN PLMN selection (see 3GPP TS 24.234 [48]). The username part format of the Root NAI shall comply with IETF RFC 4187 [50] when EAP AKA authentication is used and with IETF RFC 4186 [51], when EAP SIM authentication is used. When the username part of Decorated NAI includes the IMSI, it shall be built following the same steps specified for Root NAI in clause 14.3. The result will be a decorated NAI of the form: "wlan.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org ! 0<IMSI>@wlan.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org", for EAP AKA authentication and " wlan.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org ! 1<IMSI>@wlan.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org ", for EAP SIM authentication For example, for EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15) and the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71 then the Decorated NAI takes the form wlan.mnc015.mcc234.3gppnetwork.org!0234150999999999@wlan.mnc071.mcc610.3gppnetwork.org. NOTE: the 'otherrealm' specified in the present document is resolved by the WLAN AN. If the WLAN AN does not have access to the GRX, then the WLAN AN should resolve the realm by other means e.g. static look-up table, private local DNS server acting as an authoritative name server for that sub-domain.
EXAMPLE 1: If the fast re-authentication identity returned by the 3GPP AAA Server is 458405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 458405627015@wlan.mnc015.mcc234.3gppnetwork.org EXAMPLE 2: If the fast re-authentication identity returned by the 3GPP AAA Server is "458405627015@aaa1.wlan.mnc015.mcc234.3gppnetwork.org" and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 458405627015@aaa1.wlan.mnc015.mcc234.3gppnetwork.org EXAMPLE 3: If the fast re-authentication identity returned by the 3GPP AAA Server is 458405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71, the Fast Re-authentication NAI takes the form: wlan.mnc015.mcc234.3gppnetwork.org ! 458405627015@wlan.mnc071.mcc610.3gppnetwork.org
3GPP
Release 11
46
When the temporary identity username is coded with FF, this reserved value is used to indicate the special case when no valid temporary identity exists in the WLAN UE (see 3GPP TS 24.234 [48]). The network shall not allocate a temporary identity with the whole username coded with the reserved hexadecimal value FF. For EAP-AKA authentication, the username portion of the pseudonym identity shall be prepended with the single digit "2" and the username portion of the fast re-authentication identity shall be prepended with the single digit "4" as specified in sub-clause 4.1.1.7 of IETF RFC 4187 [50]. For EAP-SIM authentication, the username portion of the pseudonym identity shall be prepended with the single digit "3" and the username portion of the fast re-authentication identity shall be prepended with the single digit "5" as specified in sub-clause 4.2.1.7 of IETF RFC 4186 [51].
14.7 W-APN
The W-APN is composed of two parts as follows: The W-APN Network Identifier; this defines to which external network the PDG is connected. The W-APN Operator Identifier; this defines in which PLMN the PDG serving the W-APN is located.
The W-APN Operator Identifier is placed after the W-APN Network Identifier. The W-APN consisting of both the Network Identifier and Operator Identifier corresponds to a FQDN of a PDG; the W-APN has, after encoding as defined in the paragraph below, a maximum length of 100 octets. The encoding of the W-APN shall follow the Name Syntax defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and IETF RFC 1123 [20]. The W-APN consists of one or more labels. Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. Following IETF RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following IETF RFC 1123 [20], the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The W-APN is not terminated by a length byte of zero. For the purpose of presentation, a W-APN is usually displayed as a string in which the labels are separated by dots (e.g. "Label1.Label2.Label3"). The W-APN for the support of IMS Emergency calls shall take the form of a common, reserved Network Identifier described in subclause 14.7.1 together with the usual W-APN Operator Identifier as described in subclause 14.7.2.
3GPP
Release 11
47
a W-APN which corresponds to a FQDN of a PDG, and which is locally interpreted by the PDG as a request for a specific service, or a W-APN Network Identifier consisting of 3 or more labels and starting with a Reserved Service Label, or a WAPN Network Identifier consisting of a Reserved Service Label alone, which indicates a PDG by the nature of the requested service. Reserved Service Labels and the corresponding services they stand for shall be agreed between operators who have WLAN roaming agreements.
The W-APN Network Identifier for the support of IMS Emergency calls shall take the form of a common, reserved Network Identifier of the form "sos". As an example, the W-APN for MCC 345 and MNC 12 is coded in the DNS as: "sos.w-apn.mnc012.mcc345.pub.3gppnetwork.org". where "sos" is the W-APN Network Identifier and " mnc012.mcc345.pub.3gppnetwork.org " is the W-APN Operator Identifier.
If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the W-APN OI.
As an example, the W-APN OI for MCC 345 and MNC 12 is coded in the DNS as: "w-apn.mnc012.mcc345.pub.3gppnetwork.org".
3GPP
Release 11
48
The Alternative W-APN Operator Identifiers shall be constructed as follows: "w-apn.<valid operators REALM>" where: <valid operators REALM> corresponds to REALM names owned by the operator hosting the PDG serving the desired W-APN. REALM names are required to be unique, and are piggybacked on the administration of the Public Internet DNS namespace. REALM names may also belong to the operator of the VPLMN.
As an example, the W-APN OI for the Operator REALM "notareal.com" is coded in the Public Internet DNS as: "w-apn.notareal.com".
3GPP
Release 11
49
15
15.1 Introduction
This clause describes the format of the parameters needed to access the Multimedia Broadcast/Multicast service. For further information on the use of the parameters see 3GPP TS 23.246 [52].
2 or 3 digits MNC
Figure 15.2.1: Structure of TMGI The TMGI is composed of three parts: 1) MBMS Service ID consisting of three octets. MBMS Service ID consists of a 6-digit fixed-length hexadecimal number between 000000 and FFFFFF. MBMS Service ID uniquely identifies an MBMS bearer service within a PLMN. 2) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of the BM-SC; 3) Mobile Network Code (MNC) consisting of two or three digits (depending on the assignment to the PLMN by its national numbering authority). The MNC identifies the PLMN which the BM-SC belongs to. For more information on the use of the TMGI, see 3GPP TS 23.246 [52].
3GPP
Release 11
50
16
16.1 Introduction
This clause describes the format of the parameters needed to access the GAA system. For further information on the use of the parameters see 3GPP TS 33.221 [58]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document.
3GPP
Release 11
51
Example 1: -
If IMSI in use is "234150999999999", where MCC=234, MNC=15, and MSIN=0999999999, the BSF address would be "bsf.mnc015.mcc234.pub.3gppnetwork.org".
In the case where ISIM is used in bootstrapping, the BSF address shall be derived as follows: 1. extract the domain name from the IMPI; 2. if the last two labels of the domain name extracted from the IMPI are "3gppnetwork.org": a. the first label is "bsf"; b. the next labels are all labels of the domain name extracted from the IMPI apart from the last two labels; and c. the last three labels are "pub.3gppnetwork.org"; Example 2: If the IMPI in use is "234150999999999@ims.mnc015.mcc234.3gppnetwork.org", the BSF address would be "bsf.ims.mnc015.mcc234.pub.3gppnetwork.org".
3. if the last two labels of the domain name extracted from the IMPI are other than the "3gppnetwork.org": a. add the label "bsf." to the beginning of the domain. Example 3: If the IMPI in use is "user@operator.com", the BSF address would be "bsf.operator.com ".
17
17.1 Introduction
This clause describes the format of the parameters needed to access the Generic Access Network (GAN). For further information on the use of the parameters and GAN in general, see 3GPP TS 43.318 [61] and 3GPP TS 44.318 [62]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document.
3GPP
Release 11
52
MNC = 15; MSIN = 0999999999, Which gives the home network realm: gan.mnc015.mcc234.3gppnetwork.org. NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation dependent how the UE determines the length of the MNC (2 or 3 digits).
EXAMPLE 2:
3GPP
Release 11
53
1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27], 3GPP TS 51.011 [66]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning; 2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" domain name; 3. add the label "gan." to the beginning of the domain name. An example of a home network domain name is: IMSI in use: 234150999999999; Where: MCC = 234; MNC = 15; MSIN = 0999999999, Which gives the home network domain name: gan.mnc015.mcc234.pub.3gppnetwork.org. NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation dependent how the UE determines the length of the MNC (2 or 3 digits).
3GPP
Release 11
54
An example of an FQDN for a Provisioning GANC is: IMSI in use: 234150999999999; Where: MCC = 234; MNC = 15; MSIN = 0999999999, Which gives the FQDN: pganc.gan.mnc015.mcc234.pub.3gppnetwork.org. NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation dependent how the UE determines the length of the MNC (2 or 3 digits).
18
Addressing and Identification for IMS Service Continuity and Single-Radio Voice Call Continuity
18.1 Introduction
This clause describes the format of the parameters needed for the support of IMS Service Continuity. For further information on the use of the parameters see 3GPP TS 23.237 [71] and also 3GPP TS 23.292 [70].
3GPP
Release 11
55
18.6 Session Transfer Number for Single Radio Voice Call Continuity (STN-SR)
The Session Transfer Number for Single Radio Voice Call Continuity (STN-SR) is a public telecommunication number, as defined by ITU-T Recommendation E.164 [10] and is used by the MSC Server to request session transfer of the media path from the PS domain to CS domain.
18.8 Transfer Identifier for CS to PS Single Radio Voice Call Continuity (STI-rSR)
A Session Transfer Identifier for CS to PS Single Radio Voice Call Continuity (STI-rSR) is a SIP URI (see IETF RFC 3261 [26] for more information) and is used by the UE to request access transfer of a media path.
19
Numbering, addressing and identification for the Evolved Packet Core (EPC)
19.1 Introduction
This clause describes the format of the parameters needed to access the Enhanced Packet Core (EPC). For further information on the use of the parameters see 3GPP TS 23.401 [72] and 3GPP TS 23.402 [68]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document
3GPP
Release 11
56
The Home Network Realm/Domain shall be in the form of "epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org", where "<MNC>" and "<MCC>" fields correspond to the MNC and MCC of the operators PLMN. Both the "<MNC>" and "<MCC>" fields are 3 digits long. If the MNC of the PLMN is 2 digits, then a zero shall be added at the beginning. For example, the Home Network Realm/Domain of an IMSI shall be derived as described in the following steps: 1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning; 2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.3gppnetwork.org" domain name; 3. add the label "epc" to the beginning of the domain name. An example of a Home Network Realm/Domain is: IMSI in use: 234150999999999; Where: MCC = 234; MNC = 15; MSIN = 0999999999; Which gives the Home Network Realm/Domain name: epc.mnc015.mcc234.3gppnetwork.org. NOTE: If it is not possible for a UE to identify whether a 2 or 3 digit MNC is used (e.g. USIM is inserted and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation dependent how the UE determines the length of the MNC (2 or 3 digits).
The NAI shall be generated based on the IMSI or, when UE is performing emergency attach and IMSI is not available or not authenticated, on the IMEI (see subclause 19.3.6). For further information on the use of the parameters see 3GPP TS 24.234 [48].
3GPP
Release 11
57
1. Generate an identity conforming to NAI format from IMSI as defined in EAP AKA [50] as appropriate; 2. Convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in subclause 19.2. 3. Prefix domain name with the label of "nai". The result will be a root NAI of the form: "0<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" for EAP AKA authentication "6<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" for EAP AKA' authentication For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the root NAI then takes the form as 0234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA authentication, and takes the form as 6234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA authentication. The NAI sent in the Mobile Node Identifier field in PMIPv6 shall not include the digit prepended in front of the IMSI that is described above. Consequently the Permanent User Identity assigned by the 3GPP AAA Server when Network Based Mobility is used shall not include this digit either.
3GPP
Release 11
58
For EAP AKA', see IETF RFC 5448 [82], the Fast Re-authentication NAI shall comply with IETF RFC 4187 [50] except that the username part of the NAI shall be prepended with single digit "8". NOTE: The permanent user identity is either the Root NAI or Decorated NAI as defined in clauses 19.3.2 and 19.3.3, respectively. If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 358405627015@nai.epc.mnc015.mcc234.3gppnetwork.org If the fast re-authentication identity returned by the 3GPP AAA Server is "358405627015@aaa1.nai.epc.mnc015.mcc234.3gppnetwork.org" and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 358405627015@aaa1.nai.epc.mnc015.mcc234.3gppnetwork.org If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71, the Fast Re-authentication NAI takes the form: nai.epc.mnc015.mcc234.3gppnetwork.org ! 358405627015@nai.epc.mnc071.mcc610.3gppnetwork.org.
EXAMPLE 1:
EXAMPLE 2:
EXAMPLE 3:
EXAMPLE 1:
EXAMPLE 2:
EXAMPLE 3:
3GPP
Release 11
59
EXAMPLE 4:
For EAP AKA', if the pseudonym returned by the 3GPP AAA Server is 758405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71, the pseudonym NAI takes the form: nai.epc.mnc015.mcc234.3gppnetwork.org! 758405627015@nai.epc.mnc071.mcc610.3gppnetwork.org
or mac<MAC>@sos.invalid For example, if the IMEI is 219551288888888, the Emergency NAI for Limited Service State then takes the form of imei219551288888888@sos.invalid. For example, if the MAC address is 44-45-53-54-00-AB, the Emergency NAI for Limited Service State then takes the form of mac4445535400AB@sos.invalid, where the MAC address is represented in hexadecimal format without separators.
3GPP
Release 11
60
The encoding of any identifier used as part of a Fully Qualifed Domain Name (FQDN) shall follow the Name Syntax defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and IETF RFC 1123 [20]. An FQDN consists of one or more labels. Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. Following IETF RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following IETF RFC 1123 [20], the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. Identifiers are not terminated by a length byte of zero. NOTE: A length byte of zero is added by the querying entity at the end of the FQDN before interrogating a DNS server.
For the purpose of presentation, identifiers are usually displayed as a string in which the labels are separated by dots (e.g. "Label1.Label2.Label3").
19.4.2.2
19.4.2.2.1
The Access Point Name FQDN (APN-FQDN) is derived from an APN as follows. The APN consists of an APN Network Identifier (APN-NI) and an APN Operator Identifier (APN-OI), which are as defined in subclause 9.1.1 and 9.1.2 of the present document. If an APN is constructed using the default APN-OI, the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between the APN-NI and the default APN - OI, and by replacing the label ".gprs" at the end of the default APN-OI with the labels ".3gppnetwork.org". EXAMPLE1: For an APN of internet.mnc015.mcc234.gprs, the derived APN-FQDN is internet.apn.epc.mnc015.mcc234.3gppnetwork.org
If an APN is constructed using the APN-OI Replacement field (as defined in 3GPP TS 23.060 [3] and 3GPP TS 23.401 [72]), the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between the label "mnc<MNC>" and its preceding label, and by replacing the label ".gprs" at the end of the APN-OI Replacement field with the labels ".3gppnetwork.org". EXAMPLE 2: If an APN-OI Replacement field is province1.mnc015.mcc234.gprs and an APN-NI is internet, the derived APN-FQDN is internet. province1.apn.epc.mnc015.mcc234.3gppnetwork.org
19.4.2.3
The Tracking Area Identity (TAI) consists of a Mobile Country Code (MCC), Mobile Network Code (MNC), and Tracking Area Code (TAC). It is composed as shown in figure 19.4.2.3.1.
3GPP
Release 11
61
Figure 19.4.2.3.1: Structure of the Tracking Area Identity (TAI) The TAI is composed of the following elements: Mobile Country Code (MCC) identifies the country in which the PLMN is located. The value of the MCC is the same as the three digit MCC contained in the IMSI; Mobile Network Code (MNC) is a code identifying the PLMN in that country. The value of the MNC is the same as the two or three digit MNC contained in the IMSI; Tracking Area Code (TAC) is a fixed length code (of 2 octets) identifying a Tracking Area within a PLMN. This part of the tracking area identification shall be coded using a full hexadecimal representation. The following are reserved hexadecimal values of the TAC: NOTE: 0000, and FFFE. The above reserved values are used in some special cases when no valid TAI exists in the MS (see 3GPP TS 24.301 [90] for more information).
A subdomain name can be derived from the TAI. This shall be done by adding the label "tac" to the beginning of the Home Network Realm/Domain (see subclause 19.2) and encoding the TAC as a sub-domain. This is called the TAI FQDN.. The TAI FQDN shall be constructed as follows: tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org The TAC is a 16-bit integer. The <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and the <TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in <TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding.
19.4.2.4
A Mobility Management Entity (MME) within an operator's network is identified using a MME Group ID (MMEGI), and an MME Code (MMEC). A subdomain name shall be derived from the MNC and MCC by adding the label "mme" to the beginning of the Home Network Realm/Domain (see subclause 19.2). The MME node FQDN shall be constructed as: mmec<MMEC>.mmegi<MMEGI>.mme.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org Where <MMEC> and <MMEGI> are the hexadecimal strings of the MMEC and MMEGI. An MME pool FQDN shall be constructed as: mmegi<MMEGI>.mme.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
19.4.2.5
The Routing Area Identity (RAI) consists of a RAC, LAC, MNC and MCC.
3GPP
Release 11
62
A subdomain name for use by core network nodes based on RAI shall be derived from the MNC and MCC by adding the label "rac" to the beginning of the Home Network Realm/Domain (see subclause 19.2). The RAI FQDN shall be constructed as: rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org <RAC> and <LAC> shall be Hex coded digits representing the LAC and RAC codes respectively. If there are less than 4 significant digits in <RAC> or <LAC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. Note: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. The subdomain name in Annex C.2 are still used for existing A/AAAA records for pre-Release 8 nodes and are also still used for backward compatibility.
19.4.2.6
A specific SGSN within an operator's network is identified using the RAI FQDN (subclause 19.4.2.5) and the Network Resource Identifier (NRI) (see 3GPP TS 23.236 [23]). Such an identifier can be used by a target MME or SGSN node to connect to the source SGSN node. The SGSN FQDN shall be constructed as: nri-sgsn<NRI>.rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org <NRI> shall be Hex coded digits representing the NRI code of the SGSN. If there are less than 4 significant digits in < NRI>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. Coding for other fields is the same as in Section 19.4.2.5. When a target MME constructs the FQDN of the source SGSN in the case of SGSN pooling, it should derive the NRI from the 8-bit MME Code received in the GUTI from the UE. However, if the length of the NRI, e.g., X, which is configured in the MME is less than 8 bits, then the MME should use only the most significant X bits of the MME Code as the NRI within the SGSN FQDN. Note: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. The subdomain name in Annex C.2 are still used for existing A/AAAA records for pre-Release 8 nodes and are also still used for backward compatibility. .
19.4.2.7
In the special case of a UTRAN target RNC a possible SGSN that can control that RNC can be identified by RNC-ID. This identifier can be used for SRNS relocation with a U-TRAN target RNC. A subdomain name for use by core network nodes based on RNC-ID shall be derived from the MNC and MCC by adding the label "rnc" to the beginning of the Home Network Realm/Domain (see subclause 19.2). The RNC FQDN shall be constructed as: rnc<RNC>.rnc.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org <RNC> shall be Hex coded digits representing the RNC-ID code of the RNC. If there are less than 4 significant digits in <RNC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. NOTE: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. The subdomain name in Annex C.3 are still used for existing A/AAAA records for pre-Release 8 nodes and are still used for backward compatibility. However, RNC-ID in Annex C.3 was originally intended for the case where only one SGSN controlled an RNC-ID and gave the SGSN IP address. The usage for the above RNC FQDN is potentially broader and can target an SGSN pool.
3GPP
Release 11
63
19.4.2.8
The EPC nodes DNS subdomain (DNS zone) shall be derived from the MNC and MCC by adding the label "node" to the beginning of the Home Network Realm/Domain (see subclause 19.2) and shall be constructed as: node.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org This DNS subdomain is formally placed into the operator's control. 3GPP shall never take this DNS subdomain back or any zone cut/subdomain within it for any purpose. As a result the operator can safely provision any DNS records it chooses under this subdomain without concern about future 3GPP standards encroaching on the DNS names within this zone.
19.4.2.9
The ePDG Fully Qualified Domain Name (ePDG FQDN) contains an Operator Identifier that shall uniquely identify the PLMN where the ePDG is located. The ePDG FQDN is composed of seven labels. The last three labels shall be "pub.3gppnetwork.org". The third and fourth labels together shall uniquely identify the PLMN. The first two labels shall be "epdg.epc". The result of the ePDG FQDN will be: "epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" In the roaming case, the UE may utilise the services of the VPLMN. In this case, the ePDG FQDN Operator Identifier shall be constructed as described above, but using the MNC and MCC of the VPLMN. In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the "epdg.epc. mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" format of the ePDG FQDN Operator Identifier shall be: <MNC> = 3 digits <MCC> = 3 digits
If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the ePDG FQDN. As an example, the ePDG FQDN Operator Identifier for MCC 345 and MNC 12 is coded in the DNS as: "epdg.epc.mnc012.mcc345.pub.3gppnetwork.org".
19.4.2.10
The Global eNodeB-ID is used to identify eNodeBs globally which is composed of the concatenation of MCC, MNC and the eNodeBID. The MCC and MNC are the same as included in the E-UTRAN Cell Global Identifier (ECGI) (see subclause 19.6). A subdomain name shall be derived from the MNC and MCC by adding the label "enb" to the beginning of the Home Network Realm/Domain (see subclause 19.2). The Global eNodeB-ID FQDN shall be constructed as: enb<eNodeB-ID>.enb.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org The <eNodeB-ID> shall be coded using a full hexadecimal representation. If there are less than 4 significant digits in < eNodeB-ID>, "0" digit(s) shall be inserted at the left side to fill the 4 digit coding.
3GPP
Release 11
64
IETF RFC 3958 section 6.5 'app-protocol' name x-s5-gtp , x-s5-pmip, x-s8-gtp , x-s8-pmip, x-s2a-pmip, x-s2a-mipv4, x-s2a-gtp, xs2b-pmip, x-s2b-gtp, x-s2c-dsmip, x-gn, x-gp x-s5-gtp , x-s5-pmip, x-s8-gtp , x-s8-pmip, x-s11, x-s12, x-s4, x-s1-u, x-s2a-pmip, x-s2b-pmip x-gn, x-gp x-gn, x-gp, x-s4,x-s3, x-s16, x-sv x-s10, x-s11, x-s3, x-s6a, x-s1-mme, x-gn, x-gp, x-sv x-sv
SGW and interface types supported by the SGW GGSN SGSN MME and interface types supported by the MME MSC Server
x-3gpp-sgw
NOTE 1: The formats follow the experimental format as specified in IETF RFC 3958 [74]. For example, to find the S8 PMIP interfaces on a PGW the Service Parameter of "3gpp-pgw:x-s8-pmip" would be used as input in the procedures defined in IETF RFC 3958 [74]. NOTE 2: Currently 'app-service' names identify 3GPP node type and 'app-protocol' identify 3GPP interfaces, which differs from more common usage of S-NAPTR where app-protocol is used for transport protocol. Type of nodes (i.e PGW, SGW, SGSN, MME, MSC Server etc) and interfaces (i.e. S11, S5, S8, Sv, etc.) follow the standard names from 3GPP TS 23.401 [72] ,3GPP TS 29.060 [6] and3GPP TS 23.216 [92] with prefix "x-" added. NOTE 3: x-gn denotes an intra-PLMN interface using GTPv1-C, x-gp denotes a inter-PLMN interface using GTPv1-C. NOTE 4: The app-service of x-3gpp-pgw with app-protocols x-gn or x-gp identifies the co-located GGSN function on a PGW. The app-service of x-3gpp-ggsn with app-protocols x-gn or x-gp identifies a GGSN function that is not co-located with a PGW. NOTE 5: The app-service of x-3gpp-msc with app-protocol x-sv identifies the MSC Sv interface service.
19.6 E-UTRAN Cell Identity (ECI) and E-UTRAN Cell Global Identification (ECGI)
The E-UTRAN Cell Global Identification (ECGI) shall be composed of the concatenation of the PLMN Identifier (PLMN-Id) and the E-UTRAN Cell Identity (ECI) as shown in figure 19.6.1 and shall be globally unique:
3GPP
Release 11
65
Figure 19.6.1: Structure of E-UTRAN Cell Global Identification The ECI shall be of fixed length of 28 bits and shall be coded using full hexadecimal representation. The exact coding of the ECI is the responsibility of each PLMN operator. For more details on ECI and ECGI, see 3GPP TS 36.413 [84].
19.7 Identifiers for communications with packet data networks and applications
19.7.1 Introduction
This subclause describes external identifiers used to facilitate communications with packet data networks and applications (e.g. Machine Type Communication (MTC) applications on the external network/MTC servers) as specified in 3GPP TS 23.682 [98].
The External Identifier shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282 [53]. The username part format of the External Identifier shall contain a Local Identifier as specified in 3GPP TS 23.682 [98]. The realm part format of the External Identifier shall contain a Domain Identifier as specified in 3GPP TS 23.682 [98]. As specified in subclause 4 of IETF RFC 4282 [53], the Domain Identifier shall be a duly registered Internet domain name. The combination of Local Identifier and Domain Identifier makes the External Identifier globally unique. The result of the External Identifier form is: "<Local Identifier>@<Domain Identifier>" An example of an External Identifier is: Local Identifier in use: "123456789"; Domain Identifier = "domain.com"; Which gives the External Identifier as: "123456789@domain.com"
3GPP
Release 11
66
20
20.1 Introduction
This clause describes the format of the parameters needed specifically for IMS Centralized Services (ICS). For further information on the use of ICS parameters, see 3GPP TS 23.292 [70].
3GPP
Release 11
67
The MSC Server enhanced for ICS shall derive the Private User Identity from the subscriber's IMSI as follows: 1. Use the whole string of digits as the username part of the private user identity; and 2. convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in sub-clause 20.3.2. The result will be a Private User Identity of the form "<IMSI>@ics.mnc<MNC>.mcc<MCC>.3gppnetwork.org". For example if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identity then takes the form 234150999999999@ics.mnc015.mcc234.3gppnetwork.org
The user portion of the SIP URI is optional and implementation specific.
21
21.1 Introduction
This clause describes the format of the parameters needed by the UE to use Dual Stack Mobile IPv6 (DSMIPv6 as specified in 3GPP TS 23.327 [76] and 3GPP TS 23.402 [68].
The HA-APN Operator Identifier is placed after the HA-APN Network Identifier. The HA-APN consisting of both the Network Identifier and Operator Identifier corresponds to a FQDN of a HA; the HA-APN has, after encoding as defined in the paragraph below, a maximum length of 100 octets. The encoding of the HA-APN shall follow the Name Syntax defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and IETF RFC 1123 [20]. The HA-APN consists of one or more labels. Each label is coded as a one octet length field
3GPP
Release 11
68
followed by that number of octets coded as 8 bit ASCII characters. Following IETF RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following IETF RFC 1123 [20], the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The HA-APN is not terminated by a length byte of zero. For the purpose of presentation, a HA-APN is usually displayed as a string in which the labels are separated by dots (e.g. "Label1.Label2.Label3").
As an example, the HA-APN for MCC 345 and MNC 12 is coded in the DNS as: "internet.ha-apn.mnc012.mcc345.pub.3gppnetwork.org". where "internet" is the HA-APN Network Identifier and "mnc012.mcc345.pub.3gppnetwork.org " is the HA-APN Operator Identifier.
If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the HA-APN OI. As an example, the HA-APN OI for MCC 345 and MNC 12 is coded in the DNS as:
3GPP
Release 11
69
"ha-apn.mnc012.mcc345.pub.3gppnetwork.org".
In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the "andsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" format of the ANDSF-SN shall be: <MNC> = 3 digits <MCC> = 3 digits
If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the ANDSF-SN. As an example, the ANDSF-SN OI for MCC 345 and MNC 12 is coded in the DNS as: "andsf.mnc012.mcc345.pub.3gppnetwork.org".
23
Numbering, addressing and identification for the Relay Node OAM System
23.1 Introduction
This clause describes some information needed to access the Relay Node OAM system as specified in TS 36.300 [91]. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document.
3GPP
Release 11
70
23.3.2.2
As part of the startup procedure, relay nodes (see 3GPP TS 36.300 [91], sub-clause 4.7) needs to discover its Operations and Maintainence (OAM) system. A relay node vendor-specific OAM system within an operators network is identified using the relay node type allocation code from IMEI or IMEISV (IMEI-TAC), MNC and MCC from IMSI and in some cases also tracking area code information associated to the eNB serving the relay node. A subdomain name for use by EUTRAN OAM system nodes shall be derived from the MNC and MCC by adding the label "eutran" to the beginning of the OAM System Realm/Domain (see sub-clause 23.2). The vendor-specific relay node OAM system FQDN shall be constructed as following:
3GPP
Release 11
71
tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.imei-tac<IMEI-TAC>.eutranrn.oam.mnc<MNC>.mcc<MCC>.3gppnetwork.org The IMEI-TAC is 8 decimal digits (see sub-clause 6.2). NOTE: IMEI-TAC is used for the type allocation code from IMEI or IMEISV instead of TAC in this sub-clause in order to separate it from the tracking area code (TAC).
The TAC is a 16 bit integer. <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and <TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in <TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding.
3GPP
Release 11
72
A BSIC is allocated to each cell. A BSIC can take one of 64 values. In each cell the BSIC is broadcast in each burst sent on the SCH, and is then known by all MSs which synchronise with this cell. The BSIC is used by the MS for several purposes, all aiming at avoiding ambiguity or interference which can arise when an MS in a given position can receive signals from two cells using the same BCCH frequency. Some of the uses of the BSIC relate to cases where the MS is attached to one of the cells. Other uses relate to cases where the MS is attached to a third cell, usually somewhere between the two cells in question. The first category of uses includes: The three least significant bits of the BSIC indicate which of the 8 training sequences is used in the bursts sent on the downlink common channels of the cell. Different training sequences allow for a better transmission if there is interference. The group of the three least significant bits of the BSIC is called the BCC (Base station Colour Code). The BSIC is used to modify the bursts sent by the MSs on the access bursts. This aims to avoid one cell correctly decoding access bursts sent to another cell.
The second category of uses includes: When in connected mode, the MSs measure and report the level they receive on a number of frequencies, corresponding to the BCCH frequencies of neighbouring cells in the same network as the used cell. Along with the measurement result, the MS sends to the network the BSIC which it has received on that frequency. This enables the network to discriminate between several cells which happen to use the same BCCH frequency. Poor discrimination might result in faulty handovers. The content of the measurement report messages is limited to information for 6 neighbour cells. It is therefore useful to limit the reported cells to those to which handovers are accepted. For this purpose, each cell provides a list of the values of the three most significant bits of the BSICs which are allocated to the cells which are useful to consider for handovers (usually excluding cells in other PLMNs). This information enables the MS to discard information for cells with non-conformant BSICs and not to report them. The group of the three most significant bits of the BSIC is called the NCC (Network Colour Code).
It should be noted that when in idle mode, the MS identifies a cell (for cell selection purposes) according to the cell identity broadcast on the BCCH and not by the BSIC.
A.2
Where the coverage areas of two PLMNs overlap, the rule above is respected if: 1) The PLMNs use different sets of BCCH frequencies (In particular, this is the case if no frequency is common to the two PLMNs. This usually holds for PLMNs in the same country), or 2) The PLMNS use different sets of NCCs, or 3) BSIC and BCCH frequency planning is co-ordinated.
3GPP
Release 11
73
Recognizing that method 3) is more cumbersome than method 2), and that method 1) is too constraining, it is suggested that overlapping PLMNs which use a common part of the spectrum agree on different NCCs to be used in any overlapping areas. As an example, a preliminary NCC allocation for countries in the European region can be found in clause A.3 of this annex. This example can be used as a basis for bilateral agreements. However, the use of the NCCs allocated in clause A.3 is not compulsory. PLMN operators can agree on different BSIC allocation rules in border areas. The use of BSICs is not constrained in non-overlapping areas, or if ambiguities are resolved by using different sets of BCCH frequencies.
A.3
Austria Belgium Cyprus Denmark Finland France Germany Greece Iceland Ireland Italy Liechtenstein Luxembourg Malta Monaco Netherlands Norway Portugal San Marino Spain Sweden Switzerland Turkey UK Vatican Yugoslavia
This allows a second operator for each country by allocating the colour codes n (in the table) and n + 4. More than 2 colour codes per country may be used provided that in border areas only the values n and/or n+4 are used.
3GPP
Release 11
74
Representation of IMEI
an 8 digit Type Allocation Code (TAC); a 6 digit Serial Number (SNR); and a 2 digit Software Version Number (SVN).
The International Mobile station Equipment Identity and Software Version number (IMEISV), as defined in clause 6, is a 16 digit decimal number composed of three distinct elements:
TAC SNR SVN Figure A.1: Composition of the IMEISV The IMEI is complemented by a check digit as defined in clause 3. The Luhn Check Digit (CD) is computed on the 14 most significant digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812 [3]). In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the IMEISV, excluding the SVN. This is done as follows: The (14 most significant) digits of the IMEISV are labelled D14, D13 ... D1, where: TAC = D14, D13 ... D7 SNR = D6, D5 ... D1 (with D7 the least significant digit of TAC); (with D1 the least significant digit of SNR).
B.2
Step 1: Step 2: Step 3:
B.3
Example of computation
IMEI (14 most significant digits): TAC D11 D10 5 3 SNR D3 3
D14 2
D13 6
D12 0
D9 1
D8 7
D7 9
D6 3
D5 1
D4 1
D2 8
D1 3
3GPP
Release 11
75
Step 1: 2 6 x2 12 0 5 x2 10 3 1 x2 2 7 9 x2 18 Step 2: 3 1 x2 2 1 3 x2 6 8 3 x2 6
2 + 1 + 2 + 0 + 1 + 0 + 3 + 2 + 7 + 1 + 8 + 3 + 2 + 1 + 6 + 8 + 6 = 53 Step 3: CD = 60 - 53 = 7
3GPP
Release 11
76
C.1
This subclause describes a possible way to support inter-PLMN roaming. When an MS roams between two SGSNs within the same PLMN, the new SGSN finds the address of the old SGSN from the identity of the old RA. Thus, each SGSN can determine the address of every other SGSN in the PLMN. When an MS roams from an SGSN in one PLMN to an SGSN in another PLMN, the new SGSN may be unable to determine the address of the old SGSN. Instead, the SGSN transforms the old RA information to a logical name of the form: racAAAA.lacBBBB.mncYYY.mccZZZ.gprs A and B shall be Hex coded digits; Y and Z shall be encoded as single digits (in the range 0-9). If there are less than 4 significant digits in AAAA or BBBB, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit coding. As an example, the logical name for RAC 123A, LAC 234B, MCC 167 and MNC 92 will be coded in the DNS server as: rac123A.lac234B.mnc092.mcc167.gprs. The SGSN may then acquire the IP address of the old SGSN from a DNS server, using the logical address. Introducing the DNS concept in GPRS enables operators to use logical names instead of IP addresses when referring to nodes (e.g. GSNs), thus providing flexibility and transparency in addressing. Each PLMN should include at least one DNS server (which may optionally be connected via the DNS service provided by the GSM Association). Note that these DNS servers are GPRS internal entities, unknown outside the GPRS system. The above implies that at least MCC || MNC || LAC || RAC (= RAI) is sent as the RA parameter over the radio interface when an MS roams to another RA. If for any reason the new SGSN fails to obtain the address of the old SGSN, the new SGSN takes the same actions as when the corresponding event occurs within one PLMN. Another way to support seamless inter-PLMN roaming is to store the SGSN IP addresses in the HLR and request them when necessary. If Intra Domain Connection of RAN Nodes to Multiple CN Nodes (see 3GPP TS 23.236 [23]) is applied then the Network Resource Identifier (NRI) identifies uniquely a given SGSN node out of all the SGSNs serving the same pool area. If the new SGSN is not able to extract the NRI from the old P-TMSI, it shall retrieve the address of the default SGSN (see 3GPP TS 23.236 [23]) serving the old RA, using the logical name described earlier in this section. The default SGSN in the old RA relays the GTP signalling to the old SGSN identified by the NRI in the old P-TMSI unless the default SGSN itself is the old SGSN. If the new SGSN is able to extract the NRI from the old P-TMSI, then it shall attempt to derive the address of the old SGSN from the NRI and the old RAI. NRI-to-SGSN assignments may be either configured (by O&M) in the new SGSN, or retrieved from a DNS server. If a DNS server is used, it shall be queried using the following logical name, derived from the old RAI and NRI information:
3GPP
Release 11
77
nriCCCC.racDDDD.lacEEEE.mncYYY.mccZZZ.gprs C, D and E shall be Hex coded digits, Y and Z shall be encoded as single digits (in the range 0-9). If there are less than 4 significant digits in CCCC, DDDD or EEEE, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digits coding. As an example, the logical name for NRI 3A, RAC 123A, LAC 234B, MCC 167 and MNC 92 will be coded in the DNS server as: nri003A.rac123A.lac234B.mnc092.mcc167.gprs. If for any reason the new SGSN fails to obtain the address of the old SGSN using this method, then as a fallback method it shall retrieve the address of the default SGSN serving the old RA.
C.2
This subclause defines a naming convention for GSNs. It shall be possible to refer to a GSN by a logical name which shall then be translated into a physical IP address. This clause proposes a GSN naming convention which would make it possible for an internal GPRS DNS server to make the translation. An example of how a logical name of an SGSN could appear is: sgsnXXXX.mncYYY.mccZZZ.gprs X, shall be Hex coded digits, Y andZz shall be encoded as single digits (in the range 0-9). If there are less than 4 significant digits in XXXX one or more "0" digit(s) is/are inserted at the left side to fill the 4 digits coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit coding. As an example, the logical name for SGSN 1B34, MCC 167 and MNC 92 will be coded in the DNS server as: sgsn1B34. mnc092.mcc167.gprs
C.3
Target ID
This subclause describes a possible way to support SRNS relocation. In UMTS, when SRNS relocation is executed, a target ID which consists of MCC, MNC and RNC ID is used as routeing information to route to the target RNC via the new SGSN. An old SGSN shall resolve a new SGSN IP address by a target ID to send the Forward Relocation Request message to the new SGSN. It shall be possible to refer to a target ID by a logical name which shall be translated into an SGSN IP address to take into account inter-PLMN handover. The old SGSN transforms the target ID information into a logical name of the form: rncXXXX.mncYYY.mccZZZ.gprs X shall be Hex coded digits; Y and Z shall be encoded as single digits (in the range 0-9). If there are less than 4 significant digits in XXXX, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digits coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit coding. Then, for example, a DNS server is used to translate the logical name to an SGSN IP address. As an example, the logical name for RNC 1B34, MCC 167 and MNC 92 will be coded in the DNS server as: rnc1B34.mnc092.mcc167.gprs
3GPP
Release 11
78
2.
To address the above, the IETF recommended using a domain name that is routable in the pubic domain but which requests to it are not actually serviced in the public domain. The domain name ".3gppnetwork.org" was chosen as the new top level domain name to be used (as far as possible) within the inter-PLMN IP backbone network. Originally, only the DNS servers connected to the inter-PLMN IP backbone network were populated with the correct information needed to service requests for all sub-domains of this domain. However, it was later identified that some new services needed their allocated sub-domain(s) to be resolvable by the UE and not just inter-PLMN IP network nodes. To address this, additional, higher-level sub-domains were created: "pub.3gppnetwork.org", which is to be used for domain names that need to be resolvable by UEs (and possibly network nodes too) that are connected to a local area network that is connected to the Internet; and "ipxuni.3gppnetwork.org", which is to be used for domain names for UNI interfaces that need to be resolvable by UEs that are connected to a local area network that is not connected to the Internet (e.g. local area networks connected to the inter-PLMN IP network of the IPX).
Therefore, DNS requests for the above domain names can be resolved, while requests for all other sub-domains of "3gppnetwork.org" can simply be configured to return the usual DNS error for unknown hosts (thereby avoiding potential extra, redundant load on the Internet's root DNS servers). The GSM Association is in charge of allocating new sub-domains of the ".3gppnetwork.org" domain name. The procedure for requesting new sub-domains can be found in Annex E.
3GPP
Release 11
79
Sub-domain Format
<service_id>.mnc<MNC>.mcc<MCC>.3gppnetwork.org
<service_id>.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org
<service_id>.mnc<MNC>.mcc<MCC>.ipxuni.3gppnetwork.org
Intended Usage Domain name that is to be resolvable by network nodes only. This format inherently adds protection to the identified node, in that attempted DNS resolutions instigated directly from end user equipment will fail indefinitely. Domain name that is to be resolvable by UEs and/or network nodes. This format inherently adds global resolution capability, but at the expense of confidentiality of network topology. Domain name for UNI interface that is to be resolvable by UEs that are connected to an interPLMN IP network that has no connectivity to the Internet. This format inherently adds resolution capability for UEs in closed IP networks e.g. IPX.
Table E.1: Sub-domain formats for the "3gppnetwork.org" domain and their respective intended usage NOTE 1: "<service_ID>" is a chosen label, conformant to DNS naming conventions (usually IETF RFC 1035 [19] and IETF RFC 1123 [20]) that clearly and succinctly describe the service and/or operation that is intended to use this sub-domain. NOTE 2: "<MNC>" and "<MCC>" are the MNC (padded to the left with a zero, if only a 2-digit MNC) and MCC of a PLMN.
Care should be taken when choosing which format a domain name should use. Once a format has been chosen, the responsible working group shall then check the CR and either endorse it or reject it. If the CR is endorsed, then the responsible working group shall send an LS to the GSMA IREG describing the following key points: the context the service intended use involved actors proposed new sub-domain name
GSMA IREG will then verify the consistence of the proposal and its usage within the domains structure and interworking rules (e.g. access to the GRX Root DNS servers). GSMA IREG will then endorse or reject the proposal and inform the responsible working group (in 3GPP). It is possible that GSMA IREG will also specify, changes to the newly proposed sub-domain name (e.g. due to requested sub-domain name already allocated). It should be noted that services already defined to use the ".gprs" domain name will continue to do so and shall not use the new domain name of ".3gppnetwork.org"; this is to avoid destabilising services that are already live.
3GPP
Release 11
80
3GPP
Release 11
81
Change history
TSG CN# Spec Version Apr 1999 GSM 03.03 7.0.0 CN#03 23.003 CN#04 23.003 3.0.0 CN#04 23.003 3.0.0 CN#04 CN#04 CN#04 CN#05 CN#05 CN#06 CN#07 CN#07 CN#07 CN#07 CN#07 CN#08 CN#08 CN#08 CN#09 CN#10 CN#11 CN#11 CN#11 CN#12 CN#12 CN#13 CN#13 CN#14 CN#14 CN#16 CN#16 CN#16 CN#16 CN#16 CN#17 CN#17 CN#17 CN#17 CN#18 CN#18 CN#18 CN#18 CN#18 CN#18 CN#18 CN#20 CN#21 CN#21 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 3.0.0 3.0.0 3.0.0 3.1.3 3.1.3 3.2.1 3.3.0 3.3.0 3.3.0 3.3.0 3.4.0 3.4.1 3.4.1 3.4.1 3.5.0 3.6.0 3.7.0 3.7.0 3.8.0 4.0.0 4.1.0 5.0.0 5.0.0 5.1.0 5.1.0 5.2.0 5.2.0 5.2.0 5.2.0 5.2.0 5.3.0 5.3.0 5.3.0 5.3.0 5.4.0 5.4.0 5.4.0 5.4.0 5.4.0 5.4.0 5.5.0 5.5.1 5.6.0 5.7.0 CR <Phase> New Version 3.0.0 3.1.0 3.1.0 3.1.0 3.1.0 3.1.0 3.2.0 3.2.0 3.3.0 3.4.0 3.4.0 3.4.0 3.4.0 3.4.1 3.5.0 3.5.0 3.5.0 3.6.0 3.7.0 3.8.0 3.8.0 4.0.0 4.1.0 5.0.0 5.1.0 5.1.0 5.2.0 5.2.0 5.3.0 5.3.0 5.3.0 5.3.0 5.3.0 5.4.0 5.4.0 5.4.0 5.4.0 5.5.0 5.5.0 5.5.0 5.5.0 5.5.0 5.5.0 5.5.1 5.6.0 5.7.0 6.0.0 Subject/Comment Transferred to 3GPP CN1 Approved at CN#03 Definition of escape PLMN code SSN reallocation for CAP, gsmSCF, SIWF, GGSN, SGSN, Correction of VGC/VBC reference Harmonisation of the MNC-length; correction of CR A019r1 Correction to the MNC length ASCII coding of <MNC> and <MCC> in APN OI New SSN allocation for RANAP and RNSAP Support of VLR and HLR Data Restoration procedures with LCS Necessity of the function of the calculation of an SGSN IP address from the target ID Definition of Service Area Identification Modification of clause 6.2 to enhance IMEI security Coding of a deleted P-TMSI signature Introduction of Reserved Service Labels in the APN Missing UTRAN identifiers Editorial Modification of clause 6.2.2. IMEI Formats and Encoding Alignment of 23.003 with text from 25.401 Moving informative Annex A from 3G TS 29.060 and making it normative. Clarification to Definition of Service Area Identifier Forbidden APN network identifier labels Updated from R99 to Rel-4 after CN#11 Remove reference to TS23.022 New Subsystem Number for the Position Calculation Application Part on the Iupc interface Clarification on APN labels that begin with a digit Editorial clean up Rules for TMSI partitioning Introduction of Global CN-ID definition IuFlex support for determining old SGSN during handover/relocation Allocation of unique prefixes to IPv6 terminals Use of a temporary public user identity Restructuring the IMEI to combine the TAC and FAC Use of the TLLI codespace in GERAN Iu mode Clarification on the definition of DNS Support for Shared Network in connected mode: definition of SNA Restructuring the IMEI to combine the TAC and FAC in Annex B SCCP sub-system Number for IM-SSF Iur-g Introduction Editorial clean-up Correction of the private user identity's form Addition of a reference to the ITU-T RECOMMENDATION E.212 for Mobile Country Codes Correction to the form of public user identity Fix miss-interworking for LMSI handling (LMSI definition) Corrupted figures 13 18 fixed Correction to Annex C.3 Target ID Correction to definition of Group-ID, Group call area ID and Group Call Reference PSI definition
001 002r1 003 004 005 007r1 008 011 014 016 017r2 018 013r2 019 021r1 022 023 024 025 026 028r1 029r1 032 033 035 037r1 038 041r2 044 045 048r3 050r1 053r1 054 055r1 056r2 057 058 059 062 065 072 073r2
R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 Rel-4 Rel-4 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-5 Rel-6
3GPP
Release 11
82
Change history
TSG CN# CN#22 CN#23 CN#23 CN#23 CN#23 CN#24 CN#24 CN#25 CN#25 CN#25 CN#26 CN#26 CN#26 CN#27 CN#27 CT#28 CT#28 CT#29 CT#29 CT#29 CT#31 CT#32 CT#32 CT#32 CT#33 CT#34 Spec 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 23.003 Version 6.0.0 6.1.0 6.1.0 6.1.0 6.1.0 6.2.0 6.2.0 6.3.0 6.3.0 6.3.0 6.4.0 6.4.0 6.4.0 6.5.0 6.5.0 6.6.0 6.6.0 6.7.0 6.7.1 6.7.1 6.7.1 6.8.0 6.9.0 6.9.0 6.10.0 7.0.0 7.1.0 CR 078 081 083r2 085r1 087 086r4 088r1 089 090r2 091r1 092r2 095r1 096r1 097 093r3 0099r4 0100r5 0102r2 0103 0104r1 0106r1 0107r1 0109r1 0111r1 0112r1 0117r1 0115r3 0118 0119r2 0120 0121 0122r2 0128r2 0126r2 0129r2 0131r2 0134r1 0135r2 0136 0138 0141r1 0140 0142r2 0144 0146r2 0143r2 CT#41 23.003 8.1.0 0150 0152r3 0153r1 Rel-8 <Phase> Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-6 Rel-7 Rel-7 Rel-7 New Version Subject/Comment 6.1.0 On the length of the APN NI 6.2.0 Changes and corrections to DNS names 6.2.0 Changes to enable the GSMA root DNS architecture using ".3gppnetwork.org" TLD 6.2.0 WLAN access parameters moved from TS 24.234 to TS 23.003 6.2.0 Assignment of SSN for Presence Network Agent 6.3.0 Clarification of the uses of SIP URIs for Public User ID 6.3.0 Addition of TMGI 6.4.0 Background of and procedures for the ".3gppnetwork.org" domain name 6.4.0 Decorated NAI format 6.4.0 Introduction of temporary identities 6.5.0 'otherrealm' format of Decorated NAI 6.5.0 Clarification of NRI position within (P)-TMSI 6.5.0 BSF address 6.6.0 Clarification of the TMGI 6.6.0 Definition of Alternative NAI 6.7.0 W-APN Definition 6.7.0 Correction to wildcards in PSI 6.7.1 2005-07: Correct line break before clause 14 header 6.8.0 Corrections to "3gppnetwork.org" addressing 6.8.0 Addition of addressing for the Generic Access Network 6.8.0 PSI routing 6.9.0 IETF references update 6.10.0 Fast re-authentication identity clarification 6.10.0 Case insensitive naming convention Correction to the W-APN definition 7.0.0 Definition of Anonymous URI in IMS 7.1.0 Re-authentication identity definition correction Definition of MBMS SAI 7.2.0 Voice Call Continuity Identification and Addressing Unavailable User Identity Emergency Realm for I-WLAN network advertisment Definition of emergency W-APN Format of emergency public identity 7.3.0 Definition of Private Service identity Definition of emergency APN for IMS em-calls Clarification to TMGI definition 7.4.0 Correction of derivation of identifiers, by the UE, using the IMSI 7.5.0 Home realm construction for MBMS roaming PSI clarification Remove emergency APN 7.6.0 Correction to text describing W-APN format 7.7.0 Structure of TMGI 8.0.0 Wildcarded Public User Identities format 8.1.0 IMS public and private identity derivation in 3GPP2 Minor corrections to the IMS section NAI for 3GPP access to Non-3GPP Access Interworking Addition of IMS Centralized Services related identities 8.2.0 Emergency Public User Identity Removal Introduction of IMC in support of common IMS Introduction of STN-SR
3GPP
Release 11
83
Change history
TSG CN# Spec Version CR 0154r1 0155r1 0156 0158r1 0159r1 0160r2 0161 0162 0165 0166 0163r4 0167r1 0168r1 0169 0170 0172 0174 0176r1 0177 0178r1 0179r2 0180r1 0181r2 0182 0187r2 0189r1 0190r1 0191 0193r2 0194r1 0197r1 0199r1 0200r1 0205r4 0210r1 0212r1 0215 0217 0213r4 0219r2 0221r2 0223 0225r1 0227 0229r1 0232r1 0235r1 0237r2 0242r1 0246r3 0247r2 0256 <Phase> New Version Subject/Comment Addition and correction of DNS related identifiers for EPC Definition of Globally Unique Temporary UE Identity Reference correction Addition of Conference Factory URI for IMS Centralized Services Naming for HA discovery HA-APN Definition and format of access network identifier SGSN related FQDNs New "nodes" subdomain for EPC Clarify the mapping between M-TMSI and P-TMSI Revising the GUTI Definition Closed Subscriber Group Adding the S-TMSI Definition Definition of instance Id STN-SR in SGSN Correction to NAI format Missing service identifiers for DNS procedures Correction of the GUTI format Correction of the GUTI P-TMSI mapping Corrections to Service Continuity addressing Support of EAP-AKA Naming for ANDSF discovery ePDG naming Clarification about canonical form of IMS Public User Identity when format is TEL URL Temporary Identity Tag Values for Fast Reauthentication Ids DNS-APN-OI HNB Name Definition Clarification on TAI FQDN Service Parameters for S2c Reference update for draft-montemurro-gsma-imeiurn Public User Identity definition in TS 23.003 Inclusion of CSG Type IMEI Based NAI definitions for emergency services IMEI based NAI IMEI Based NAI Reintroducing Emergency APN definition for IMS based Emergency Call Clarification for the format of ANDSF-SN in roaming scenario Tracking Area Code E-UTRAN Cell Global Identification definition Defining H(e)NB identity Exclude prepended digit from the NAI in PMIPv6 APN-FQDN construction Corrections to APN structure Correction on Home Network Realm/Domain Corrections to IMS Public Identity Removal of the redundancy reference to 23.401 IMEI and IMEISV Remove ambiguities and improved definition of HNB Unique Identity Essential corrections to GUTI mapping PSI use for services hosted in an AS Essential corrections to GUTI mapping Use of NRI Format of the Unavailable User Identity
CT#42
23.003
8.2.0
8.3.0
CT#43
23.003
8.3.0
Rel-8
8.4.0
CT#44
23.003
8.4.0
Rel-8
8.5.0
CT#47
23.003
9.1.0
Rel-9
9.2.0
CT#48
23.003
9.2.0
Rel-9
9.3.0
CT#49
23.003
9.3.0
Rel-9
9.4.0
3GPP
Release 11
84
Change history
TSG CN# CT#50 Spec 23.003 Version 9.4.0 CR 0257 0252r2 0265 0268r1 0258r3 0269r1 0259 CT#51 23.003 10.0.0 0274r3 0279r3 0277r1 0285 0280r2 0286 0289 0290 0293r2 0294r2 0296r1 0299 0307 0282r4 0303r3 0316r1 0309r1 0308r2 0312r2 0334 0322r2 0325 0317r2 0318 0320r6 0337r1 0319r5 0335r2 0311r7 Rel-10 10.1.0 <Phase> Rel-9 New Version 9.5.0 Subject/Comment Clarification of UE behaviour with regards to LAC format Correction of C-MSISDN definition Updating IMEI URN draft reference Determination of type of source node during TAU/RAU eNodeB-ID FQDN for DNS procedures Determination of type of source node during TAU/RAU Service Parameter on PGW selection for GTP based S2b Relay Node OAM system identification Correction of C-MSISDN definition Determination of type of source node during TAU/RAU Correction to a reference of an outdated IETF draft to an RFC Correction to the reserved values for Tracking Area Code (TAC) DNS Service Support For Sv Clarfication of decoding of NRI Closed Subscriber Group clarification UE moving from E-UTRAN to GERAN XCAP Addressing APN Network Identifier Updating IMEI URN draft reference Updating IMEI URN draft reference Format of Public User Identities and SIP/TEL URI Emergency NAI for UICC-less Terminal Definition of Distinct Public User Identity Emergency NAI for UICC-less Terminal APN Operator Identifier for local breakout Definition of STI-rSR BSF address correction Correction to domain name for XCAP Root URI Updating IMEI URN draft reference Clarification of GUTI mapping Service Parameter on PGW selection for GTP based S2a MTC External Identifier New Service Parameters for CS to PS SRVCC Definition of A-MSISDN MME Number for SMS in MME SSN Reallocation for CSS and its Number Definition
CT#50
23.003
9.5.0
Rel-10
10.0.0
CT#52
23.003
10.1.0
Rel-10
10.2.0
CT#53
23.003
10.2.0
Rel-10
10.3.0
CT#56
23.003
11.1.0
Rel-11
11.2.0
3GPP