19 Numbering, addressing and identification for the Evolved Packet Core (EPC)

23.0033GPPNumbering, addressing and identificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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

19.2 Home Network Realm/Domain

The home Network Realm/Domain shall be in the form of an Internet domain name, e.g. operator.com, as specified in IETF RFC 1035 [19] and IETF RFC 1123 [20]. The home Network Realm/Domain consists of one or more labels. Each label shall consist of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-) in accordance with IETF RFC 1035 [19]. Each label shall begin and end with either an alphabetic character or a digit in accordance with IETF RFC 1123 [20]. The case of alphabetic characters is not significant.

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 operator’s 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).

19.3 3GPP access to non-3GPP access interworking

19.3.1 Introduction

This clause describes the format of the UE identification needed to access the 3GPP EPC from both 3GPP and non‑3GPP accesses.

The NAI is generated respectively by the S-GW at the S5/S8 reference point and by the UE for the S2a, S2b and S2c reference points.

The NAI shall be generated as follows:

– based on the IMSI when the UE is performing a non-emergency Attach;

– based on the IMEI when the UE is performing an emergency attach and IMSI is not available (see clause 19.3.6); or

– based on the IMSI or the IMEI (depending on the interface and information element) when the UE is performing an emergency attach and IMSI is available in the UE, as follows:

– a UE that has an IMSI shall construct an Emergency NAI based on IMSI (see clause 4.6.1 of 3GPP TS 23.402 [68] and clause 19.3.9 of this specification);

– if the IMSI is not authenticated by the network, the network requests the IMEI from the UE and the network shall then construct a NAI based on the IMEI for identifying the user in the EPC (see 3GPP TS 29.273 [78]).

For further information on the use of the parameters see the clauses below and 3GPP TS 33.402 [69] and 3GPP TS 29.273 [78].

19.3.2 Root NAI

The Root NAI shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282 [53].

When the username part is the IMSI, the realm part of Root NAI shall be built according to the following steps:

1. Convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in clause 19.2.

2. Prefix domain name with the label of "nai".

The resulting realm part of the Root NAI will be in the form:

"@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

When including the IMSI, the Root NAI is prepended with a specific leading digit when used for EAP authentication (see 3GPP TS 29.273 [78]) in order to differentiate between EAP authentication method. The leading digit is:

– "0" when used in EAP-AKA, as specified in IETF RFC 4187 [50]

– "6" when used in EAP-AKA’, as specified in IETF RFC 5448 [82].

The resulting Root NAI will be in the form:

"0<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" when used for EAP AKA authentication

"6<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" when used for EAP AKA’ authentication

For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Root NAI takes the form 0234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA authentication and the Root NAI takes the form 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 based username that is described above.

19.3.3 Decorated NAI

The Decorated NAI shall take the form of a NAI and shall have the form ‘homerealm!username@otherrealm’ or ‘Visitedrealm!homerealm!username@otherrealm’ as specified in clause 2.7 of the IETF RFC 4282 [53].

The realm part of Decorated NAI consists of ‘otherrealm’, see the IETF RFC 4282 [53]. ‘Homerealm’ is the realm as specified in clause 19.2, using the HPLMN ID (‘homeMCC’ + ‘homeMNC)’. ‘Visitedrealm’ is the realm built using the VPLMN ID (‘VisitedMCC’ + ‘VisitedMNC)’, ‘Otherrealm’ is:

– the realm built using the PLMN ID (visitedMCC + visited MNC) if the service provider selected as a result of the service provider selection (see 3GPP TS 24.302 [77]) has a PLMN ID; or

– a domain name of a service provider if the selected service provider does not have a PLMN ID (3GPP TS 24.302 [77]).

When the username part of Decorated NAI includes the IMSI and the service provider has a PLMN ID, the Decorated NAI shall be built following the same steps as specified for Root NAI in clause 19.3.2.

The result will be a decorated NAI of the form:

– nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org !0<IMSI>@nai.epc.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org for EAP AKA authentication.

– nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org !6<IMSI>@nai.epc.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org for EAP AKA’ authentication.

For example, if the service provider has a PLMN ID and 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 either as:

– nai.epc.mnc015.mcc234.3gppnetwork.org!0234150999999999@nai.epc.mnc071.mcc610.3gppnetwork.org for EAP AKA authentication

– nai.epc.mnc015.mcc234.3gppnetwork.org!6234150999999999@nai.epc.mnc071.mcc610.3gppnetwork.org for EAP AKA’ authentication.

For example, if the domain name of a service provider is ‘realm.org’ and IMSI-based permanent username is used, then the Decorated NAI takes the form either as:

– nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org !0<IMSI>@realm.org for EAP AKA authentication

– nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org !6<IMSI>@realm.org for EAP AKA’ authentication.

If the UE has selected a WLAN that directly interworks with a service provider in the Equivalent Visited Service Providers (EVSP) list provided by the RPLMN, see 3GPP TS 23.402 [77], clause 4.8.2b, then the decorated NAI is constructed to include the realm of this service provider and the realm of RPLMN. If the domain name of a service provider is ‘realm.org’ and IMSI-based permanent username is used, then the Decorated NAI with double decoration takes the form either as:

– nai.epc.mnc<rplmnMNC>.mcc<rplmnMCC>.3gppnetwork.org !nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org!0<IMSI>@realm.org for EAP AKA authentication

– nai.epc.mnc<rplmnMNC>.mcc<rplmnMCC>.3gppnetwork.org !nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org!6<IMSI>@realm.org for EAP AKA’ authentication.

When the username part of Decorated NAI includes a Fast Re-authentication NAI, the Decorated NAI shall be built following the same steps as specified for the Fast Re-authentication NAI in clause 19.3.4.

When the username part of Decorated NAI includes a Pseudonym, the Decorated NAI shall be built following the same steps as specified for the Pseudonym identity in clause 19.3.5.

19.3.4 Fast Re‑authentication NAI

The Fast Re-authentication NAI shall take the form of a NAI as specified in clause 2.1 of IETF RFC 4282 [53]. If the 3GPP AAA server does not return a complete NAI, the Fast Re-authentication NAI shall consist of the username part of the fast re-authentication identity as returned from the 3GPP AAA server and the same realm as used in the permanent user identity. If the 3GPP AAA server returns a complete NAI as the re-authentication identity, then this NAI shall be used. The username part of the fast re-authentication identity shall be decorated as described in 19.3.3 if the Selected PLMN is different from the HPLMN.

For EAP-AKA authentication, the username portion of the fast re-authentication identity shall be prepended with the single digit "4" as specified in clause 4.1.1.7 of IETF RFC 4187 [50].

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.

EXAMPLE 1: If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015, the IMSI is 234150999999999 (MCC = 234, MNC = 15) and EAP-AKA is used, the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 4358405627015@nai.epc.mnc015.mcc234.3gppnetwork.org

EXAMPLE 2: If the fast re-authentication identity returned by the 3GPP AAA Server is "358405627015@aaa1.nai.epc.mnc015.mcc234.3gppnetwork.org" , the IMSI is 234150999999999 (MCC = 234, MNC = 15) and EAP-AKA’ is used, the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 8358405627015@aaa1.nai.epc.mnc015.mcc234.3gppnetwork.org

EXAMPLE 3: If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015, the IMSI is 234150999999999 (MCC = 234, MNC = 15), the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71 and EAP-AKA is used, the Fast Re-authentication NAI takes the form: nai.epc.mnc015.mcc234.3gppnetwork.org !4358405627015@nai.epc.mnc071.mcc610.3gppnetwork.org.

19.3.5 Pseudonym Identities

The pseudonym shall take the form of an NAI, as specified in clause 2.1 of IETF RFC 4282 [53].

The pseudonym shall be generated as specified in clause 6.4.1 of 3GPP TS 33.234 [55]. This part of the pseudonym shall follow the UTF-8 transformation format specified in IETF RFC 2279 [54] except for the following reserved hexadecimal octet value:

When the pseudonym username is coded with FF, this reserved value is used to indicate the special case when no valid temporary identity exists in the UE (see 3GPP TS 24.234 [48] for more information). The network shall not allocate a temporary identity with the whole username coded with the reserved hexadecimal value FF.

The username portion of the pseudonym identity shall be prepended with the single digit "2" as specified in clause 4.1.1.7 of IETF RFC 4187 [50] for EAP-AKA. For EAP AKA’, see IETF RFC 5448 [82], the pseudonym NAI shall comply with IETF RFC 4187 [50] except that the username part of the NAI shall be prepended with single digit "7".

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.

EXAMPLE 1: For EAP AKA, if the pseudonym returned by the 3GPP AAA Server is 258405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the pseudonym NAI for the case when NAI decoration is not used takes the form: 258405627015@nai.epc.mnc015.mcc234.3gppnetwork.org

EXAMPLE 2: For EAP AKA’, if the pseudonym returned by the 3GPP AAA Server is 758405627015 and the IMSI is 234150999999999 (MCC = 234, MNC = 15), the pseudonym NAI for the case when NAI decoration is not used takes the form: 758405627015@nai.epc.mnc015.mcc234.3gppnetwork.org

EXAMPLE 3: For EAP AKA, if the pseudonym returned by the 3GPP AAA Server is 258405627015 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! 258405627015@nai.epc.mnc071.mcc610.3gppnetwork.org

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

19.3.6 Emergency NAI for Limited Service State

This clause describes the format of the UE identification needed to access the 3GPP EPC from both 3GPP and non‑3GPP accesses, when UE is performing an emergency attach and IMSI is not available or not authenticated (see clause 19.3.1). For more information, see clauses 4.6.1 and 5.2 of 3GPP TS 23.402 [68].

The Emergency NAI for Limited Service State shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282 [53]. The exact format shall be:

imei<IMEI>@sos.invalid

NOTE: The top level domain ".invalid" is a reserved top level domain, as specified in IETF RFC 2606 [64], and is used here due to the fact that this NAI never needs to be resolved for routing (as specified in 3GPP TS 23.402 [68]).

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.

19.3.7 Alternative NAI

The Alternative NAI shall take the form of a NAI, i.e. ‘any_username@REALM’ as specified of IETF RFC 4282 [53]. The Alternative NAI shall not be routable from any AAA server.

The Alternative NAI shall contain a username part which is not derived from the IMSI. The username part shall not be a null string.

The REALM part of the NAI shall be "unreachable.3gppnetwork.org".

The result shall be an NAI in the form of:

"<any_non_null_string>@unreachable.3gppnetwork.org".

19.3.8 Keyname NAI

The keyname NAI shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282 [53].

The username part is the EMSK name as defined in IETF RFC 6696 [113].

For ERP exchange with an ER server located in the 3GPP AAA Server, the realm part of the keyname NAI shall be the realm part of the Root NAI of the UE as described in clause 19.3.2, i.e. the realm part of the keyName-NAI will be in the form:

"@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

For ERP exchange with an ER server located in the TWAP or in the 3GPP AAA Proxy, the realm part of the keyname NAI shall be the realm discovered by the UE in the non-3GPP access network (received at the lower layer or through an ERP exchange as described in IETF RFC 6696 [113]).

19.3.9 IMSI-based Emergency NAI

This clause describes the format of the UE identification needed to access the 3GPP EPC from non‑3GPP accesses, when UE is performing an emergency attach and IMSI is available. For more information, see clause 4.4.1 of 3GPP TS 24.302 [77].

The IMSI-based Emergency NAI shall take the form of an NAI and shall be encoded as the Root NAI as specified in clause 19.3.2, but with the realm name prepended by the "sos" label. The resulting realm part of the IMSI-based Emergency NAI will be in the form:

"@sos.nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

The resulting IMSI-based Emergency NAI will be in the form:

"0<IMSI>@sos.nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" when used for EAP AKA authentication

"6<IMSI>@sos.nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" when used for EAP AKA’ authentication

For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the IMSI-based Emergency NAI takes the form 0234150999999999@sos.nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA authentication and it takes the form 6234150999999999@sos.nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA’ authentication.

19.4 Identifiers for Domain Name System procedures

19.4.1 Introduction

This clause describes Domain Name System (DNS) related identifiers used by the procedures specified in 3GPP TS 29.303 [73].

The DNS identifiers for APNs for legacy systems (as defined in clause 9), RAIs (as defined in clause C.1, GSNs (as defined in clause C.2) and RNCs (as defined in clause C.3) in the present document use the top level domain ".gprs" and have a similar purpose and function as those described below. These clauses are still valid and DNS records based on these and the below types of identifiers are expected to coexist in an operator’s network for the purpose of backwards compatibility and interworking with legacy networks.

The APN as defined in clause 9 is used also in EPC to identify the access network to be used for a specific PDN connection or PDP Context. In addition, the APN Network Identifier (APN-NI) part of the APN as defined in clause 9.1.1 of the present document may be used to access a service associated with a PDN-GW or GGSN. This is achieved by defining an APN which in addition to being usable to select a PDN-GW or GGSN is locally interpreted by the PDN‑GW or GGSN as a request for a specific service.

For DNS procedures defined in 3GPP TS 29.303 [73], an APN-FQDN derived from a given APN is used instead of the APN itself as defined in clause 19.4.2.2. For all other purposes, including communication between EPC nodes and to the UE, the APN format defined in clause 9 is used. In order to support backwards compatibility with existing GPRS/PS roaming using the Gn/Gp interfaces, the APN as specified in clause 9 of the present document may also be used for the DNS procedures as defined in 3GPP TS 23.060 [3].

19.4.2 Fully Qualified Domain Names (FQDNs)

19.4.2.1 General

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 Access Point Name FQDN (APN-FQDN)

19.4.2.2.1 Structure

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 clause 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.2.2 Void

19.4.2.2.3 Void

19.4.2.2.4 Void

19.4.2.3 Tracking Area Identity (TAI)

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.

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:

– 0000, and

– FFFE.

NOTE: 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 clause 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 Mobility Management Entity (MME)

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

If there are less than 2 significant digits in <MMEC>, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding. If there are less than 4 significant digits in <MMEGI>, "0" digit(s) shall be inserted at the left side to fill the 4 digit coding.

19.4.2.5 Routing Area Identity (RAI) – EPC

The Routing Area Identity (RAI) consists of a RAC, LAC, MNC and MCC.

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 clause 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 Serving GPRS Support Node (SGSN) within SGSN pool

A specific SGSN within an operator’s network is identified using the RAI FQDN (clause 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 Clause 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.

19.4.2.7 Target RNC-ID for U-TRAN

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

19.4.2.8 DNS subdomain for operator usage in EPC

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 clause 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 ePDG FQDN and Visited Country FQDN for non-emergency bearer services

19.4.2.9.1 General

The ePDG Fully Qualified Domain Name (ePDG FQDN), for non-emergency bearers services, shall be constructed using one of the following formats, as specified in clause 4.5.4 of 3GPP TS 23.402 [68]:

– Operator Identifier based ePDG FQDN;

– Tracking/Location Area Identity based ePDG FQDN;

– the ePDG FQDN configured in the UE by the HPLMN.

NOTE: The ePDG FQDN configured in the UE can have a different format than those specified in the following clauses.

The Visited Country FQDN is used by a roaming UE to determine whether the visited country mandates the selection of an ePDG in this country (see clause 4.5.4.5 of 3GPP TS 23.402 [68]). The Visited Country FQDN shall be constructed as specified in clause 19.4.2.9.4. The Replacement field used in DNS-based Discovery of regulatory requirements shall be constructed as specified in clause 19.4.2.9.5.

19.4.2.9.2 Operator Identifier based ePDG FQDN

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 can utilise the services of the VPLMN or the HPLMN (see 3GPP TS 23.402 [68] and 3GPP TS 24.302 [77]). In this case, the Operator Identifier based ePDG FQDN shall be constructed as described above, but using the MNC and MCC of the VPLMN or the HPLMN.

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 Operator Identifier based ePDG FQDN 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 Operator Identifier based ePDG FQDN for MCC 345 and MNC 12 is coded in the DNS as:

"epdg.epc.mnc012.mcc345.pub.3gppnetwork.org".

19.4.2.9.3 Tracking/Location Area Identity based ePDG FQDN

The Tracking/Location Area Identity based ePDG FQDN is used to support location based ePDG selection within a PLMN.

There are two Tracking Area Identity based ePDG FQDNs defined: one based on a TAI with a 2 octet TAC and a 5GS one based on a 3 octet TAC.

1) The Tracking Area Identity based ePDG FQDN using a 2 octet TAC and the Location Area Identity based ePDG FQDN shall be constructed respectively as:

"tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.tac.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

and

"lac<LAC>.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

where

– the <MNC> and <MCC> shall identify the PLMN where the ePDG is located and shall be encoded as

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

– the <TAC>, together with the <MCC> and <MNC> shall identify the Tracking Area Identity the UE is located in.

– the <LAC>, together with the <MCC> and <MNC> shall identify the Location Area Identity the UE is located in.

The LAC> shall be hexadecimal coded digits representing the LAC; if there are less than 4 significant digits in <LAC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding;

As examples,

– the Tracking Area Identity based ePDG FQDN for the TAC H’0B21, MCC 345 and MNC 12 is coded in the DNS as:

" tac-lb21.tac-hb0b.tac.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

– the Location Area Identity based ePDG FQDN for the LAC H’0B21, MCC 345 and MNC 12 is coded in the DNS as:

" lac0b21.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

2) The 5GS Tracking Area Identity based ePDG FQDN using a 3 octet TAC shall be constructed respectively as:

"tac-lb<TAC-low-byte>.tac-mb<TAC-middle-byte>.tac-hb<TAC-high-byte>.5gstac. epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

where

– the <MNC> and <MCC> shall identify the PLMN where the ePDG is located and shall be encoded as

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

– the <TAC>, together with the <MCC> and <MNC> shall identify the 5GS Tracking Area Identity the UE is located in.

The 5GS TAC is a 24-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-low-byte>, <TAC-middle-byte> or <TAC-high-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digits coding;

As examples,

– the 5GS Tracking Area Identity based ePDG FQDN for the 5GS TAC H’0B1A21, MCC 345 and MNC 12 is coded in the DNS as:

"tac-lb21.tac-mb1a.tac-hb0b.5gstac.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

19.4.2.9.4 Visited Country FQDN

The Visited Country FQDN, used by a roaming UE to determine whether the visited country mandates the selection of an ePDG in this country, shall be constructed as described below.

The Visited Country FQDN shall contain a MCC that uniquely identifies the country in which the UE is located.

The Visited Country FQDN is composed of seven labels. The last three labels shall be "pub.3gppnetwork.org". The fourth label shall be "visited-country". The third label shall uniquely identify the MCC of the visited country. The first and second labels shall be "epdg.epc". The resulting Visited Country FQDN will be:

"epdg.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org"

The <MCC> coding used in this FQDN shall be:

– <MCC> = 3 digits

As an example, the Visited Country FQDN for MCC 345 is coded in the DNS as:

"epdg.epc. mcc345.visited-country.pub.3gppnetwork.org".

19.4.2.9.5 Replacement field used in DNS-based Discovery of regulatory requirements

If the visited country mandates the selection of an ePDG in this country (see clause 4.5.4.5 of 3GPP TS 23.402 [68]), the NAPTR record(s) associated to the Visited Country FQDN shall be provisioned with the replacement field containing the identity of the PLMN(s) in the visited country which may be used for ePDG selection.

The replacement field shall take the form of an Operator Identifier based ePDG FQDN as specified in clause 19.4.2.9.2.

For countries with multiple MCC, the NAPTR records returned by the DNS may contain a different MCC than the MCC indicated in the Visited Country FQDN.

As an example, the NAPTR records associated to the Visited Country FQDN for MCC 345, and for MNC 012, 013 and 014, are provisioned in the DNS as:

epdg.epc.mcc345.visited-country.pub.3gppnetwork.org

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "" "" epdg.epc.mnc012.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" epdg.epc.mnc013.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" epdg.epc.mnc014.mcc345.pub.3gppnetwork.org

19.4.2.9A ePDG FQDN for emergency bearer services

19.4.2.9A.1 General

The ePDG FQDN used for the selection of an ePDG supporting emergency bearer services shall be constructed using one of the following formats, as specified in clause 4.5.4a of 3GPP TS 23.402 [68] and 3GPP TS 24.302 [77]:

– an Operator Identifier based Emergency ePDG FQDN;

– a Tracking/Location Area Identity based Emergency ePDG FQDN;

– an Emergency ePDG FQDN configured in the UE by the HPLMN, which may have a different format than the one specified in the following clause.

The Visited Country Emergency FQDN is used by a roaming UE, in the context of an emergency session, to determine whether the visited country mandates the selection of an ePDG in this country. The Visited Country Emergency FQDN shall be constructed as specified in clause 19.4.2.9A.4. The Replacement field used in DNS-based Discovery of regulatory requirements shall be constructed as specified in clause 19.4.2.9A.5.

The Visited Country Emergency Numbers FQDN is used by a roaming UE to determine the list of emergency numbers and related emergency service types in the the visited country.

19.4.2.9A.2 Operator Identifier based Emergency ePDG FQDN

The Operator Identifier based Emergency ePDG FQDN shall be constructed as specified for the Operator Identifier based ePDG FQDN in clause 19.4.2.9.2, with the addition of the label "sos" before the labels "epdg.epc". The result of the Emergency ePDG FQDN will be:

"sos.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

As an example, the Operator Identifier based Emergency ePDG FQDN for MCC 345 and MNC 12 is coded in the DNS as:

"sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org".

19.4.2.9A.3 Tracking/Location Area Identity based Emergency ePDG FQDN

There are two Tracking Area Identity based Emergency ePDG FQDNs defined: one based on a TAI with a 2 octet TAC and a 5GS one based on a 3 octet TAC.

1) The Tracking Area Identity based Emergency ePDG FQDN using a 2 octet TAC and the Location Area Identity based Emergency ePDG FQDN shall be constructed as specified for the Tracking Area Identity based ePDG FQDN and the Location Area Identity based ePDG FQDN in clause 19.4.2.9.3, with the addition of the label "sos" before the labels "epdg.epc".

The result of the Tracking Area Identity based Emergency ePDG FQDN and the Location Area Identity based Emergency ePDG FQDN will be:

"tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.tac.sos.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

and

"lac<LAC>.sos.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

As examples,

– the Tracking Area Identity based Emergency ePDG FQDN for the TAC H’0B21, MCC 345 and MNC 12 is coded in the DNS as:

" tac-lb21.tac-hb0b.tac.sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

– the Location Area Identity based Emergency ePDG FQDN for the LAC H’0B21, MCC 345 and MNC 12 is coded in the DNS as:

" lac0b21.sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

2) The 5GS Tracking Area Identity based Emergency ePDG FQDN using a 3 octet TAC shall be constructed as specified for the 5GS Tracking Area Identity based ePDG FQDN in clause 19.4.2.9.3, with the addition of the label "sos" before the labels "epdg.epc".

The result of the 5GS Tracking Area Identity based Emergency ePDG FQDN will be:

"tac-lb<TAC-low-byte>.tac-mb<TAC-middle-byte>.tac-hb<TAC-high-byte>.5gstac.sos. epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org "

As examples,

– the 5GS Tracking Area Identity based Emergency ePDG FQDN for the 5GS TAC H’0B1A21, MCC 345 and MNC 12 is coded in the DNS as:

"tac-lb21.tac-mb1a.tac-hb0b.5gstac.sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"

19.4.2.9A.4 Visited Country Emergency FQDN

The Visited Country Emergency FQDN shall be constructed as specified for the Visited Country FQDN in clause 19.4.2.9.4, with the addition of the label "sos" before the labels "epdg.epc".

The result of the Visited Country Emergency FQDN will be:

"sos.epdg.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org"

As an example, the Visited Country Emergency FQDN for MCC 345 is coded in the DNS as:

"sos.epdg.epc. mcc345.visited-country.pub.3gppnetwork.org".

19.4.2.9A.5 Replacement field used in DNS-based Discovery of regulatory requirements for emergency services

The requirements specified in clause 19.4.2.9.5 for the Replacement field used in DNS-based Discovery of regulatory requirements shall apply with the following modification.

The replacement field shall take the form of an Operator Identifier based Emergency ePDG FQDN as specified in clause 19.4.2.9A.2.

As an example, the NAPTR records associated to the Visited Country FQDN for MCC 345, and for MNC 012, 013 and 014, are provisioned in the DNS as:

sos.epdg.epc.mcc345.visited-country.pub.3gppnetwork.org

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "" "" sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.epdg.epc.mnc013.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.epdg.epc.mnc014.mcc345.pub.3gppnetwork.org

19.4.2.9A.6 Country based Emergency Numbers FQDN

The Country based Emergency Numbers FQDN shall be constructed as specified for the Visited Country Emergency FQDN in clause 19.4.2.9A.4, but with replacing the label "epdg" by the label "en".

The result of the Country based Emergency Numbers FQDN will be:

"sos.en.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org"

NOTE: Even though a label named "visited-country" is present, operators in the home country can use the same mechanism to provide emergency numbers and associated type(s).

As an example, the Country based Emergency Numbers FQDN for MCC 345 is coded in the DNS as:

"sos.en.epc. mcc345.visited-country.pub.3gppnetwork.org".

19.4.2.9A.7 Replacement field used in DNS-based Discovery of Emergency Numbers

The NAPTR record(s) associated to the Country based Emergency Numbers FQDN shall be provisioned with the replacement field containing the emergency numbers and related emergency service types.

The replacement field shall take the following form and include both an emergency number and at least one emergency service type:

<emergency-type>.<emergency-number>.sos.en.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org

The <emergency-number> and <emergency-type> shall follow the syntax defined in Table 19.4.2.9A.7-1. The <emergency-number> shall consist of a single label. The <emergency-type> shall consist of at least one label.

Table 19.4.2.9A.7-1: Syntax of emergency number and emergency type

emergency-number = DIGIT*DIGIT ; at least one DIGIT

emergency-type = "sos" *("." sub-label)

sub-label = let-dig [ *61let-dig-hyp let-dig ]

let-dig-hyp = let-dig / "-"

let-dig = ALPHA / DIGIT

ALPHA = %x41-5A / %x61-7A ; A-Z / a-z

As an example, the NAPTR records associated to the Country based Emergency Numbers FQDN for MCC 345 are provisioned in the DNS as:

sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "" "" sos.ambulance.15.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.police.17.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.fire.18.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.marine.196.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org

19.4.2.10 Global eNodeB-ID for eNodeB

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

19.4.2.11 Local Home Network identifier

The Local Home Network identifier uniquely identifies a local home network. For the definition of a local home network see 3GPP TS 23.060 [3] and 3GPP TS 23.401 [72].

A subdomain name shall be derived from the MNC and MCC from the visited network by adding the label "lhn" to the beginning of the Home Network Realm/Domain (see clause 19.2).

The Local Home Network-ID FQDN shall be constructed as:

lhn< LHN name >.lhn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

The <LHN-name> length and content is an operator choice. The labels shall follow the rules specified in clause 19.4.2.1.

19.4.2.12 UCMF

The UCMF FQDN shall be constructed as:

ucmf.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Where <mcc> and <mnc> are taken from the serving network identity.

19.4.2.13 PGW Set FQDN

A PGW Set Identifier is a globally unique identifier of a set of equivalent and interchangeable PGWs from a given network that provides distribution, redundancy and scalability.

A PGW Set Identifier shall be constructed from the MCC, MNC and a Set ID.

The PGW Set FQDN shall be constructed as follows:

set<Set Id>.pgwset.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

where

– <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 PGW Set FQDN.

– <Set Id> is the string representing a PGW Set within the PLMN, chosen by the operator, that shall consist of alphabetic characters (A-Z and a-z), digits (0-9) and/or the hyphen (-) and that shall end with either an alphabetic character or a digit, where the case of alphabetic characters is not significant (i.e. two PGW Set IDs with the same characters but using different lower and upper cases identify the same PGW Set).

EXAMPLE: "set12.pgwset.epc.mnc012.mcc345.3gppnetwork.org" (for the PGW set from MCC 345, MNC 12 and Set ID "12")

19.4.3 Service and Protocol service names for 3GPP

A list of standardized "service-parms" names is required to identify a "service" as defined in clause 6.5 of IETF RFC 3958 [74].

The following table defines the names to be used in the procedures specified in 3GPP TS 29.303 [73]:

Table 19.4.3.1: List of ‘app-service’ and ‘app-protocol’ names

Description	IETF RFC 3958 clause 6.5 ‘app-service’ name	IETF RFC 3958 clause 6.5 ‘app-protocol’ name
PGW and interface types supported by the PGW	x-3gpp-pgw	x-s5-gtp, x-s5-pmip, x-s8-gtp , x-s8-pmip, x-s2a-pmip, x-s2a-mipv4, x-s2a-gtp, x-s2b-pmip, x-s2b-gtp, x-s2c-dsmip, x-gn, x-gp See NOTE.
SGW and interface types supported by the SGW	x-3gpp-sgw	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 See NOTE.
GGSN	x-3gpp-ggsn	x-gn, x-gp See NOTE.
SGSN	x-3gpp-sgsn	x-gn, x-gp, x-s4, x-s3, x-s16, x-sv, x-nqprime See NOTE.
MME and interface types supported by the MME	x-3gpp-mme	x-s10, x-s11, x-s3, x-s6a, x-s1-mme, x-gn, x-gp, x-sv, x-nq See NOTE.
MSC Server	x-3gpp-msc	x-sv
UP function	x-3gpp-upf	x-sxa, x-sxb, x-sxc, x-n4, x-n4mb See NOTE.
AMF	x-3gpp-amf	x-n2 x-n26 See NOTE.
UCMF	x-3gpp-ucmf	x-urcmp x-n55
NOTE: When using Dedicated Core Networks, the character string "+ue-<ue usage type>" shall be appended to the ‘app-protocol’ name, for the interfaces applicable to Dedicated Core Networks, where <ue-usage-type>" contains one or more UE usage type values. See 3GPP TS 29.303 [73], 3GPP TS 29.272 [108] and 3GPP TS 29.273 [78]. Example: x-s5-gtp+ue-<ue usage type> If multiple UE usage type values are embedded in the "+ue-<ue usage type>", they shall be separated by the symbol ".", e.g. "+ue-1.3.4.20" as specified in IETF RFC 3958 [74]. To select a network node with a particular network capability needed, the character string "+nc-<network capability>" shall be appended to the ‘app-protocol’ name, where < network capability > contains one or more network capability of the node. See 3GPP TS 29.303 [73]. Example: x-s5-gtp+nc-<network capability> If multiple network capability of the node are embedded in the "+nc-<network capability>", they shall be separated by the symbol ".", e.g. "+nc-nr.smf", as specified in IETF RFC 3958 [74]. To select a network node with a particular network capability needed within a certain Dedicated Core Networks, the character string "+nc-<network capability>" and "+ue-<ue usage type>" shall be appended to the ‘app-protocol’ name, where <ue usage type> contains one or more UE usage type values and the Example: x-s5-gtp+nc-<network capability>+ue-<ue usage type> or x-s5-gtp+ue-<ue usage type>+nc-<network capability>

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

NOTE 6: The app-service of x-3gpp-amf with app-protocol x-n2 identifies the AMF N2 interface service. The app-service of x-3gpp-amf with app-protocol x-n26 identifies the AMF N26 interface service.

19.5 Access Network Identity

A trusted non-3GPP access network used by the UE to access EPS can be identified using the Access Network Identity. The Access Network Identity is used as an input parameter in the EPS security procedures as specified in 3GPP TS 33.402 [69]. The format and signalling of the parameter between the network and the UE is specified in 3GPP TS 24.302 [77] and the format and signalling of this parameter between access network and core network is specified in 3GPP TS 29.273 [78].

The encoding of the Access Network Identity shall be specified within 3GPP, but the Access Network Identity definition for each non-3GPP access network is under the responsibility of the corresponding standardisation organisation respectively.

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:

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

NOTE: In the 5G Core Network protocols, when the ECGI needs to be identified in the context of Standalone Non-Public Networks (SNPN), the Network Identifier (NID) of the SNPN is included as part of the ECGI Information Element (see 3GPP TS 29.571 [129]); this is a protocol aspect that does not imply any change on the system-wide definition of the ECGI.

19.6A NR Cell Identity (NCI) and NR Cell Global Identity (NCGI)

The NR Cell Global Identity (NCGI) shall be composed of the concatenation of the PLMN Identifier (PLMN-Id) and the NR Cell Identity (NCI) as shown in figure 19.6A-1 and shall be globally unique:

Figure 19.6A-1: Structure of NR Cell Global Identity

The NCI shall be of fixed length of 36 bits and shall be coded using full hexadecimal representation. The exact coding of the NCI is the responsibility of each PLMN operator.

For more details on NCI and NCGI, see 3GPP TS 38.413 [123].

NOTE: In the 5G Core Network protocols, when the NCGI needs to be identified in the context of Standalone Non-Public Networks (SNPN), the Network Identifier (NID) of the SNPN is included as part of the NCGI Information Element (see 3GPP TS 29.571 [129]); this is a protocol aspect that does not imply any change on the system-wide definition of the NCGI.

19.7 Identifiers for communications with packet data networks and applications

19.7.1 Introduction

This clause 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], 3GPP TS 23.501 [119] and 3GPP TS 23.502 [120].

19.7.2 External Identifier

An External Identifier identifies a subscription associated to an IMSI. A subscription associated to an IMSI may have one or several External Identifier(s).

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

19.7.3 External Group Identifier

An External Group Identifier identifies a group made up of one or more subscriptions associated to a group of IMSIs.

The External Group Identifier shall have the form groupname@realm as specified in clause 2.1 of IETF RFC 4282 [53].

The groupname part format of the External Group Identifier shall contain a Local Identifier as specified in 3GPP TS 23.682 [98]. The realm part format of the External Group Identifier shall contain a Domain Identifier as specified in 3GPP TS 23.682 [98]. As specified in clause 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 Group Identifier globally unique.

The result of the External Group Identifier form is:

"<Local Identifier>@<Domain Identifier>"

An example of an External Group Identifier is:

Local Identifier in use: "Group1";

Domain Identifier = "domain.com";

Which gives the External Group Identifier as:

Group1@domain.com

19.8 TWAN Operator Name

The TWAN Operator Name identifies the TWAN operator when the TWAN is not operated by a mobile operator.

The TWAN Operator Name shall be encoded as a realm in the form of an Internet domain name, e.g. operator.com, as specified in IETF RFC 1035 [19] and IETF RFC 1123 [20]. The TWAN Operator Name consists of one or more labels. Each label shall consist of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-) in accordance with IETF RFC 1035 [19]. Each label shall begin and end with either an alphabetic character or a digit in accordance with IETF RFC 1123 [20]. The case of alphabetic characters is not significant.

NOTE: The TWAN Operator Name is encoded as a dotted string.

19.9 IMSI-Group Identifier

IMSI-Group Identifier is a network internal globally unique ID which identifies a set of IMSIs (e.g. MTC devices) from a given network that are grouped together for one specific group related services. It is used e.g. for group specifc NAS level congestion control (see 3GPP TS 23.401 [72]).

An IMSI-Group Identifier shall be composed as shown in figure 19.9-1.

Figure 19.9-1: Structure of IMSI-Group Identifier

IMSI-Group Identifier is composed of four parts:

1) Group Service Identifier, identifies the service (4 Octets) for which the IMSI-Group Identifier is valid.

2) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of the mobile subscriber;

3) Mobile Network Code (MNC) consisting of two or three digits. 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.

4) the Local Group Id is assigned by the network operator and may have a length of up to 10 octets.

Two different IMSI-Group Identifier values, with the same Group Service Identifier and with MCC/MNC values that point to the same PLMN, shall have two different Local Group Ids.

19.10 Presence Reporting Area Identifier (PRA ID)

The Presence Reporting Area Identifier (PRA ID) is used to identify a Presence Reporting Area (PRA).

PRAs can be used for reporting changes of UE presence in a PRA, e.g. for policy control or charging decisions. See 3GPP TS 23.401 [72], 3GPP TS 23.060 [3] and 3GPP TS 23.203 [107].

A PRA is composed of a short list of TAs/RAs, or eNBs and/or cells/SAs in a PLMN. A PRA can be:

– either a "UE-dedicated PRA", defined in the subscriber profile;

– or a "Core Network predefined PRA", pre-configured in MME/S4-SGSN.

PRA IDs used to identify "Core Network predefined PRAs" shall not be used for identifying "UE-dedicated PRAs".

The same PRA ID may be used for different UEs to identify different "UE-dedicated PRAs", i.e. PRA IDs may overlap between different UEs, while identifying different "UE-dedicated PRAs".

The PRA ID shall be encoded as an integer on 3 octets. The most significant bit of the PRA ID shall be set to 0 for UE-dedicated PRA and shall be to 1 for Core Network predefined PRA.

19.11 Dedicated Core Networks Identifier

A Dedicated Core Network ID (DCN-ID) identifies a Dedicated Core Network (DCN) within a PLMN.

The allowed values of DCN-ID shall be in the range of 0 to 65535.

Values in the range of 0 to 127 are standardized and defined as follows:

0: Spare, for future use

…

127: Spare, for future use

Values in the range of 128 to 65535 are operator-specific.

The use of the standardized DCN-ID is specified in 3GPP TS 23.401 [72].