28 Numbering, addressing and identification for 5G System (5GS)

23.0033GPPNumbering, addressing and identificationRelease 18TS

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

28.1 Introduction

This clause describes the format of the parameters, identifiers and information used for the 5G system. For further information on these, see 3GPP TS 23.501 [119], 3GPP TS 23.502 [120] and 3GPP TS 23.503 [121].

28.2 Home Network Domain

The Home Network Domain for 5GC shall be in the format specified in IETF RFC 1035 [19] and IETF RFC 1123 [20] and shall be structured as:

"5gc.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 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 NF service endpoint format for inter PLMN routing.

As an example, the Home Network Domain for MCC 345 and MNC 12 is coded as:

"5gc.mnc012.mcc345.3gppnetwork.org".

The Home Network Domain for a Stand-alone Non-Public Network (SNPN) shall be in the format specified in IETF RFC 1035 [19] and IETF RFC 1123 [20] and, if not pre-configured in the NF, shall be structured as:

"5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org",

where <MNC> and <MCC> shall be encoded as specified above, and the NID shall be encoded as hexadecimal digits as specified in clause 12.7.

As an example, the Home Network Domain for MCC 345, MNC 12 and NID 000007ed9d5 (hexadecimal: assignment mode = 0, PEN = 00007ed9, NID code = d5) is coded as:

"5gc.nid000007ed9d5.mnc012.mcc345.3gppnetwork.org".

NOTE: For interworking with an SNPN (e.g. discovery of AMFs from an SNPN by a shared NG RAN), the above sub-domain can be used when the MCC, MNC and NID uniquely identifies the SNPN. For signalling within an SNPN, the above sub-domain can be used regardless of whether the MCC, MNC and NID uniquely identifies the SNPN or not.

28.3 Identifiers for Domain Name System procedures

28.3.1 Introduction

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

28.3.2 Fully Qualified Domain Names (FQDNs)

28.3.2.1 General

See clause 19.4.2.1.

28.3.2.2 N3IWF FQDN

28.3.2.2.1 General

The N3IWF Fully Qualified Domain Name (N3IWF FQDN) shall be constructed using one of the following formats, as specified in clause 6.3.6 of 3GPP TS 23.501 [119]:

– Operator Identifier based N3IWF FQDN;

– Tracking Area Identity based N3IWF FQDN;

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

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

The Visited Country FQDN for N3IWF is used by a roaming UE to determine whether the visited country mandates the selection of an N3IWF in this country. The Visited Country FQDN for N3IWF shall be constructed as specified in clause 28.3.2.2.4. The Replacement field used in DNS-based Discovery of regulatory requirements shall be constructed as specified in clause 28.3.2.2.5.

The Visited Country FQDN for SNPN N3IWF is used by a UE in the visited country to determine whether the visited country mandates the selection of an N3IWF in this country for the SNPN identified by the SNPN Identifier provided by the UE. The Visited Country FQDN for SNPN N3IWF shall be constructed as specified in clause 28.3.2.2.6. The Replacement field used in DNS-based Discovery of SNPN N3IWF for regulatory requirements shall be constructed as specified in clause 28.3.2.2.7.

NOTE 2: The DNS can be configured to return no records for the visited country regardless of the SNPN ID provided by the UE. This addresses the scenario that the visited country in general does not mandate selection of a local N3IWF.

28.3.2.2.2 Operator Identifier based N3IWF FQDN

The N3IWF Fully Qualified Domain Name (N3IWF FQDN) contains an Operator Identifier that shall uniquely identify the PLMN where the N3IWF is located. The N3IWF 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 "n3iwf.5gc". The result of the N3IWF FQDN will be:

"n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

In the roaming case, the UE can utilise the services of the VPLMN or the HPLMN. In this case, the Operator Identifier based N3IWF 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 "n3iwf.5gc. mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" format of the Operator Identifier based N3IWF 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 N3IWF FQDN.

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

"n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org".

28.3.2.2.3 Tracking Area Identity based N3IWF FQDN

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

There are two N3IWF 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 N3IWF FQDN using a 2 octet TAC shall be constructed respectively as:

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

where

– the <MNC> and <MCC> shall identify the PLMN where the N3IWF 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 N3IWF FQDN.

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

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;

As examples,

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

"tac-lb21.tac-hb0b.tac.n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org"

2) The 5GS Tracking Area Identity based N3IWF 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.n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

where

– the <MNC> and <MCC> shall identify the PLMN where the N3IWF 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 N3IWF FQDN.

– the <TAC>, together with the <MCC> and <MNC> shall identify the 5GSTracking 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 digit coding;

As examples,

– the 5GS Tracking Area Identity based N3IWF 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.n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org"

28.3.2.2.4 Visited Country FQDN for N3IWF

The Visited Country FQDN for N3IWF, used by a roaming UE to determine whether the visited country mandates the selection of an N3IWF 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 "n3iwf.5gc". The resulting Visited Country FQDN of N3IWF will be:

"n3iwf.5gc.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:

"n3iwf.5gc.mcc345.visited-country.pub.3gppnetwork.org".

28.3.2.2.4a Visited Country Emergency N3IWF FQDN

The Visited Country Emergency N3IWF FQDN, used by a roaming UE shall be constructed as specified for the Visited Country FQDN for N3IWF in clause 28.3.2.2.4, with the addition of the label "sos" before the labels "n3iwf.5gc".

The resulting Visited Country Emergency N3IWF FQDN will be:

"sos.n3iwf.5gc.mcc<MCC>.visited-country.pub.3gppnetwork.org"

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

"sos.n3iwf.5gc.mcc345.visited-country.pub.3gppnetwork.org".

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

If the visited country mandates the selection of an N3IWF in this country, 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 N3IWF selection.

The replacement field shall take the form of an Operator Identifier based N3IWF FQDN as specified in clause 28.3.2.2.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:

n3iwf.5gc.mcc345.visited-country.pub.3gppnetwork.org

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "" "" n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" n3iwf.5gc.mnc013.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" n3iwf.5gc.mnc014.mcc345.pub.3gppnetwork.org

28.3.2.2.5b Replacement field used in DNS-based Discovery of regulatory requirements for emergency services via N3IWF

The NAPTR record(s) associated to the Visited Country Emergency N3IWF FQDN shall be provisioned with the replacement field containing the identity of the PLMN(s) in the visited country supporting emergency services in non-3GPP access via N3IWF.

The replacement field shall take the form of an operator identifier based N3IWF FQDN as specified clause 28.3.2.2.2, with the addition of the label "sos" before the labels "n3iwf.5gc".

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

sos.n3iwf.5gc.mcc345.visited-country.pub.3gppnetwork.org

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "" "" sos.n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.n3iwf.5gc.mnc013.mcc345.pub.3gppnetwork.org

IN NAPTR 100 999 "" "" sos.n3iwf.5gc.mnc014.mcc345.pub.3gppnetwork.org

28.3.2.2.6 Visited Country FQDN for SNPN N3IWF

SNPN N3IWF is the N3IWF selected by the UE to access this SNPN service via PLMN as specified in clause 6.3.6.2a of 3GPP TS 23.501 [119].

The Visited Country FQDN for SNPN N3IWF used by a UE in the visited country to determine whether the visited country mandates the selection of an N3IWF in this country for the SNPN identified by the SNPN Identifier provided by the UE, shall be constructed as described below.

The Visited Country FQDN for SNPN N3IWF shall contain a MCC that uniquely identifies the country in which the UE is located, and the SNPN Identifier.

The Visited Country FQDN for SNPN N3IWF is composed of eight labels. The last three labels shall be "pub.3gppnetwork.org". The fifth label shall be "visited-country". The fourth label shall uniquely identify the MCC of the visited country. The third label shall be the SNPN Identifier as specified in clause 12.7. The first and second labels shall be "n3iwf.5gc". The resulting Visited Country FQDN for SNPN N3IWF will be:

"n3iwf.5gc.snpnid<SNPNID>.mcc<MCC>.visited-country.pub.3gppnetwork.org"

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

– <MCC> = 3 digits

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

– <SNPNID> = MCC || MNC || NID

NOTE 1: The MCC used in the SNPNID is not necessarily the same (e.g. it can be 999 reserved for internal use) as the one used in coding the <MCC>.

NOTE 2: Locally assigned NIDs are not supported, since a DNS cannot be properly configured for multiple SNPNs using the same locally assigned NID.

As an example, the Visited Country FQDN for SNPN N3IWF, for MCC 345, SNPN MCC 999, MNC 123, and NID 456789ABCDE is coded in the DNS as:

"n3iwf.5gc.snpnid999123456789ABCDE.mcc345.visited-country.pub.3gppnetwork.org".

NOTE 3: The identity (i.e. the corresponding DNS record) of an SNPN’s N3IWF in the visited country can be any FQDN and is not required to include the SNPN identifier.

28.3.2.2.7 Replacement field used in DNS-based Discovery of SNPN N3IWF for regulatory requirements

If the visited country mandates the selection of an N3IWF in this country, the NAPTR record(s) associated to the Visited Country FQDN shall be provisioned with the replacement field containing FQDNs of SNPN N3IWFs located in the visited country.

NOTE: If the visited country mandates the selection of the N3IWF in this country and the SNPN does not have an N3IWF in this country, the NAPTR record(s) associated to the Visited Country FQDN are provisioned with the replacement field containing an FQDN that cannot be resolved to an IP address.

28.3.2.2.8 Prefixed Operator Identifier based N3IWF FQDN

The Prefixed Operator Identifier based N3IWF FQDN, used by a UE that is configured with Slice-specific N3IWF prefix configuration, shall be constructed as specified for the Operator Identifier based N3IWF FQDN in clause 28.3.2.2.2, with the addition of <Prefix> before the labels "n3iwf.5gc". The <Prefix> is provided in the Slice-specific N3IWF prefix configuration for the selected PLMN that contains S-NSSAIs that match all (or most, in case there is no full match) of the S-NSSAIs that the UE is going to include in the Requested NSSAI in the subsequent Registration procedure, and is specified in 3GPP TS 24.526 [144].

The resulting Prefixed Operator Identifier based N3IWF FQDN will be:

"<Prefix>.n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

As an example, the Prefixed Operator Identifier based N3IWF FQDN for MNC 123, MCC 345 with an example <Prefix> value "ssn3iwfprefix-Y" is coded in the DNS as:

"ssn3iwfprefix-Y.n3iwf.5gc.mnc123.mcc345.pub.3gppnetwork.org".

28.3.2.2.9 Prefixed Tracking Area Identity based N3IWF FQDN

The Prefixed Tracking Area Identity based N3IWF FQDN, used by a UE that is configured with Slice-specific N3IWF prefix configuration, shall be constructed as specified for the Tracking Area Identity based N3IWF FQDN in clause 28.3.2.2.3, with the addition of <Prefix> before the TAC. The <Prefix> is provided in the Slice-specific N3IWF prefix configuration for the selected PLMN that contains S-NSSAIs that match all (or most, in case there is no full match) of the S-NSSAIs that the UE is going to include in the Requested NSSAI in the subsequent Registration procedure, and is specified in 3GPP TS 24.526 [144].

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

1) The Prefixed Tracking Area Identity based N3IWF FQDN using a 2 octet TAC shall be constructed respectively as:

"<Prefix>.tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.tac.n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

The syntax and semantics of <TAC-high-byte>, <TAC-low-byte>, <MNC>, and <MCC> are specified in clause 28.3.2.2.3.

As an example, the Prefixed Tracking Area Identity based N3IWF FQDN for the TAC H’0B21, MCC 345, MNC 12, and an example <Prefix> value "ssn3iwfprefix-Y" is coded in the DNS as:

"ssn3iwfprefix-Y.tac-lb21.tac-hb0b.tac.n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org"

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

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

The syntax and semantics of <TAC-high-byte>, <TAC-middle-byte>, <TAC-low-byte>, <MNC>, and <MCC> are specified in clause 28.3.2.2.3.

As an example, the 5GS Prefixed Tracking Area Identity based N3IWF FQDN for the 5GS TAC H’0B1A21, MCC 345, MNC 12, and an example <Prefix> value "ssn3iwfprefix-Y" is coded in the DNS as:

"ssn3iwfprefix-Y.tac-lb21.tac-mb1a.tac-hb0b.5gstac.n3iwf.5gc.mnc012.mcc345.pub.3gppnetwork.org"

28.3.2.3 PLMN level and Home NF Repository Function (NRF) FQDN

28.3.2.3.1 General

When an NF is instantiated, it may register with a PLMN level NF Repository Function (NRF). It may then discover other NF instance(s) in the 5GC by querying the PLMN level NRF. The IP address of the PLMN level NRF can be provisioned into the NF, or the NF can be pre-configured with the FQDN of the PLMN level NRF. If the PLMN level NRF addresses and FDQN are not provisioned into the NF, the NF self-constructs the PLMN level NRF FQDN as per the format specified in clause 28.3.2.3.2.

For NF discovery across PLMNs, the NRF (e.g vNRF) shall self-construct the PLMN level NRF FQDN of the target PLMN (e.g hNRF) as per the format specified in clause 28.3.2.3.2, and the hNRF URI as per the format specified in subsclause 28.3.2.3.3, if the NRF has not obtained the NRF FQDN of the target PLMN.

28.3.2.3.2 Format of NRF FQDN

The NRF FQDN for an NRF in an operator’s PLMN shall be constructed by prefixing the Home Network Domain Name (see clause 28.2) of the PLMN in which the NRF is located with the label "nrf." as described below:

– nrf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

The NRF FQDN for an NRF in an operator’s SNPN, if not pre-configured in the NF, shall be constructed by prefixing the Home Network Domain Name (see clause 28.2) of the SNPN in which the NRF is located with the label "nrf." as described below:

– nrf.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org

28.3.2.3.3 NRF URI

In absence of any other local configuration available in the vNRF, the API URIs of the hNRF shall be constructed by deriving the API root (see 3GPP TS 29.501 [128]) as follows:

– the authority part shall be set to the NRF FQDN as specified in 28.3.2.3.2

– the scheme shall be "https"

– the port shall be the default port for the "https" scheme, i.e. 443.

– the API prefix optional component shall not be used

EXAMPLE: For an MCC = 012 and MNC = 345, the API root of the NRF services shall be:

"https://nrf.5gc.mnc345.mcc012.3gppnetwork.org/"

28.3.2.4 Network Slice Selection Function (NSSF) FQDN

28.3.2.4.1 General

For roaming service, the vNSSF may invoke the Nnssf_NSSelection_Get service operation from the hNSSF. For routing of the HTTP/2 messages across the PLMN, the vNSSF self-constructs the FQDN of the hNSSF as per the format specified in clause 28.3.2.4.2 and the URI of the hNSSF as per the format specified in clause 28.3.2.4.3. The Home Network is identified by the PLMN ID of the SUPI provided to the vNSSF by the NF Service Consumer (e.g. the AMF).

28.3.2.4.2 Format of NSSF FQDN

The NSSF FQDN for an NSSF in an operator’s PLMN shall be constructed by prefixing its Home Network Domain Name (see clause 28.2) with the label "nssf." as described below:

– nssf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

The NSSF FQDN for an NSSF in an operator’s SNPN, if not pre-configured in the NF, shall be constructed by prefixing the Home Network Domain Name (see clause 28.2) of the SNPN in which the NSSF is located with the label "nssf." as described below:

– nssf.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org

28.3.2.4.3 NSSF URI

In absence of any other local configuration available in the vNSSF, the API URIs of the hNSSF shall be constructed by deriving the API root (see 3GPP TS 29.501 [128]) as follows:

– the authority part shall be set to the NSSF FQDN as specified in 28.3.2.4.2

– the scheme shall be "https"

– the port shall be the default port for the "https" scheme, i.e. 443.

– the API prefix optional component shall not be used

EXAMPLE: For an MCC = 012 and MNC = 345, the API root of the NSSF services shall be:

"https://nssf.5gc.mnc345.mcc012.3gppnetwork.org/"

28.3.2.5 AMF Name

The AMF Name FQDN shall uniquely identify an AMF.

The AMF Name FQDN for an AMF within an operator’s PLMN shall be constructed as follows:

"<AMF-id>.amf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

where

– the <MNC> and <MCC> shall identify the PLMN where the AMF 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 AMF Name FQDN.

– the <AMF-id> shall contain at least one label.

As example,

– If <AMF-id> is amf1.cluster1.net2, the AMF Name FQDN for MCC 345 and MNC 12 is:

"amf1.cluster1.net2.amf.5gc.mnc012.mcc345.3gppnetwork.org"

The AMF Name FQDN for an AMF within an operator’s SNPN, if not pre-configured in the NF, shall be constructed as follows:

"<AMF-id>.amf.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

where

– <MNC> and <MCC> shall be encoded as specified above;

– NID shall be encoded as hexadecimal digits as specified in clause 12.7.

As example,

– If <AMF-id> is amf1.cluster1.net2, the AMF Name FQDN for MCC 345, MNC 12 and NID 000007ed9d5 (hexadecimal) is:

"amf1.cluster1.net2.amf.5gc.nid000007ed9d5.mnc012.mcc345.3gppnetwork.org"

28.3.2.6 5GS Tracking Area Identity (TAI) FQDN

The 5GS Tracking Area Identity (TAI) FQDN shall be constructed as follows:

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

where the <TAC>, together with the <MCC> and <MNC> shall identify the 5GS Tracking Area Identity, and shall be encoded as follows:

– <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 5GS TAI FQDN.

– 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 an example, the 5GS Tracking Area Identity for the 5GS TAC H’0B1A21, MCC 345 and MNC 12 is coded in the DNS as:

"tac-lb21.tac-mb1a.tac-hb0b.5gstac.5gc.mnc012.mcc345.3gppnetwork.org"

28.3.2.7 AMF Set FQDN

An AMF Set within an operator’s PLMN is identified by its AMF Set ID, AMF Region ID, MNC and MCC.

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

The AMF Set FQDN shall be constructed as follows:

set<AMF Set Id>.region<AMF Region Id>.amfset.5gc.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 AMF Set FQDN.

– <AMF Set Id> and <AMF Region Id> are the hexadecimal strings of the AMF Set ID and AMF Region ID. If there are less than 2 significant digits in <AMF Region Id>, "0" digit(s) shall be inserted at the left side to fill the 2 digits coding. If there are less than 3 significant digits in <AMF Set Id>, "0" digit(s) shall be inserted at the left side to fill the 3 digits coding.

As an example, the AMF Set FQDN for the AMF Set 1, AMF Region 48 (hexadecimal), MCC 345 and MNC 12 is coded as:

"set001.region48.amfset.5gc.mnc012.mcc345.3gppnetwork.org"

An AMF Set within an operator’s Stand-alone Non-Public Network (SNPN) shall be identified by its AMF Set ID, AMF Region ID and by either its Network Identifier (NID), MNC and MCC or an SNPN domain name pre-configured in the NF.

The AMF Set FQDN shall be constructed as follows:

set<AMF Set Id>.region<AMF Region Id>.amfset.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org

set<AMF Set Id>.region<AMF Region Id>.amfset.<SNPN domain name>

where

– <MNC> and <MCC> shall be encoded as specified above;

– NID shall be encoded as hexadecimal digits as specified in clause 12.7;

– <SNPN domain name> is a domain name chosen by the SNPN operator.

As an example, the AMF Set FQDN for the AMF Set 1, AMF Region 48 (hexadecimal), NID 000007ed9d5 (hexadecimal), MCC 345 and MNC 12 is coded as:

"set001.region48.amfset.5gc.nid000007ed9d5. mnc012.mcc345.3gppnetwork.org"

28.3.2.8 AMF Instance FQDN

The AMF Instance FQDN shall uniquely identify an AMF instance.

The AMF Instance FQDN shall be constructed as:

pt<AMF Pointer>.set<AMF Set Id>.region<AMF Region Id>.amfi.5gc.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 AMF Instance FQDN.

– <AMF Pointer>, <AMF Set Id> and <AMF Region Id> are the hexadecimal strings of the AMF Pointer, AMF Set ID and AMF Region ID. If there are less than 2 significant digits in <AMF Pointer> or <AMF Region Id>, "0" digit(s) shall be inserted at the left side to fill the 2 digits coding of the AMF Pointer or AMF Region Id respectively. If there are less than 3 significant digits in <AMF Set Id>, "0" digit(s) shall be inserted at the left side to fill the 3 digits coding.

As an example, the AMF Instance FQDN for the AMF Pointer 12 (hexadecimal), AMF Set 1, AMF Region 48 (hexadecimal), MCC 345 and MNC 12 is coded as:

"pt12.set001.region48.amfi.5gc.mnc012.mcc345.3gppnetwork.org"

28.3.2.9 SMF Set FQDN

An SMF Set within an operator’s network is identified by its NF Set ID as defined in clause 28.12, with NFType set to "smf".

For an SMF Set within an operator’s PLMN, a subdomain name shall be derived from the MNC and MCC by adding the label "smfset" to the beginning of the Home Network Realm/Domain (see clause 28.2).

The SMF Set FQDN shall be constructed as follows:

set<Set Id>.smfset.5gc.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 AMF Set FQDN.

– <Set Id> is the string representing the Set ID part within the NF Set ID defined in clause 28.12.

EXAMPLE: "set12. smfset.5gc.mnc012.mcc345.3gppnetwork.org" (for the SMF set from MCC 345, MNC 12 and SetID "12")

NOTE: The labels preceding the ".3gppnetwork.org" domain correspond to the NF Set ID definition in clause 28.12.

For an SMF Set within an operator’s Stand-alone Non-Public Network (SNPN), the SMF Set FQDN shall be constructed from its Network Identifier (NID), MNC and MCC or an SNPN domain name pre-configured in the NF, as follows:

set<Set Id>.smfset.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org

set<Set Id>.smfset.<SNPN domain name>

where

– <MNC> and <MCC> shall be encoded as specified above;

– NID shall be encoded as hexadecimal digits as specified in clause 12.7;

– <SNPN domain name> is a domain name chosen by the SNPN operator.

EXAMPLE: "set12.smfset.5gc.nid000007ed9d5.mnc012.mcc345.3gppnetwork.org" (for an SMF set from MCC 345, MNC 12, NID 000007ed9d5 (hexadecimal) and SetID "12")

28.3.2.10 Short Message Service Function (SMSF) FQDN

The Short Message Service Function (SMSF) FQDN shall be constructed by prefixing its Home Network Domain Name (see clause 28.2) with the label "smsf" and with label(s) assigned by a PLMN as described below:

– <label(s) assigned by a PLMN>.smsf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

This format shall be used as a Diameter identity of an SMSF. A Diameter realm of an SMSF shall be a Home Network Domain Name (see clause 28.2), i.e.:

– 5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

28.3.2.11 5G DDNMF FQDN

The UE may construct the 5G DDNMF FQDN to discover the 5G DDNMF as specified in 3GPP TS 23.304 [143]. The 5G DDNMF FQDN shall be constructed as follows:

"ddnmf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"

where the <MCC> and <MNC> shall identify the PLMN where the 5G DDNMF is located. Both the "<MNC>" and "<MCC>" fields are 3 digits long. 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 5G DDNMF FQDN.

28.4 Information for Network Slicing

28.4.1 General

In order to identify a Network Slice end to end, the 5GS uses information called S-NSSAI (Single Network Slice Selection Assistance Information). See clause 5.15.2 of 3GPP TS 23.501 [119].

An S-NSSAI is comprised of:

– A Slice/Service type (SST),

– A Slice Differentiator (SD), which is optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices.

28.4.2 Format of the S-NSSAI

The structure of the S-NSSAI is depicted in Figure 28.4.2-1

Figure 28.4.2-1: Structure of S-NSSAI

The S-NSSAI may include both the SST and SD fields (in which case the S-NSSAI length is 32 bits in total), or the S-NSSAI may just include the SST field (in which case the S-NSSAI length is 8 bits only).

The SST field may have standardized and non-standardized values. Values 0 to 127 belong to the standardized SST range and they are defined in 3GPP TS 23.501 [119]. Values 128 to 255 belong to the Operator-specific range.

The SD field has a reserved value "no SD value associated with the SST" defined as hexadecimal FFFFFF. In certain protocols, the SD field is not included to indicate that no SD value is associated with the SST.

28.4.3 Ranges of S-NSSAIs

In the 5G Core Network, an NF Instance may indicate (e.g., while registering its NF profile in the NRF) support for several S-NSSAIs having a common SST value and different SDs, by including such SST value and adding, either a list of ranges of SDs, or a "wildcard" flag representing all SD values for the common SST (see 3GPP TS 29.571 [129], clause 5.4.5.1).

For an NF registering a list of supported S-NSSAIs in terms of ranges of SDs, or wildcard, the NF may associate a common network slicing policy (such as, e.g., for an AMF to assign a specific DNN to be used with a certain slice) to all S-NSSAIs derived from that SD range.

NOTE: The usage of SD ranges to define sets of S-NSSAIs is restricted to be used only by certain protocols/APIs in the 5G Core Network (e.g., NRF, NSSF, AMF…).

28.5 NF FQDN Format for Inter PLMN Routing

28.5.1 General

For routing HTTP/2 request messages to NF in a different PLMN, the FQDN of the target NF shall have the Home Network Domain (see clause 28.2) as the trailing part.

28.5.2 Telescopic FQDN

The FQDN of the NF services or the authority part of URIs in another PLMN, may be appended with the PLMN Network Domain of the request initiating PLMN, as the trailing part to form a Telescopic FQDN as specified in 3GPP TS 33.501 [124]. The structure of the Telescopic FQDN is as specified below:

<Label representing FQDN from other PLMN>.<FQDN of the SEPP in the request initiating PLMN>,

where:

– FQDN from other PLMN is the FQDN of the other PLMN NF (for e.g. returned in the NF Discovery Response) or the authority part of URIs from other PLMN, which may be rewritten by the other PLMN SEPP for topology hiding. The request initiating PLMN SEPP shall replace the other PLMN FQDN with a label;

NOTE 1: How a SEPP constructs the label to replace the other PLMN FQDN is implementation specific. The label replacement is required in order to avoid multiple subdomains in the FQDN since the SEPP presents wildcard certificates on behalf of the other PLMN and only single level subdomain is allowed in a wildcard certificate as per IETF RFC 2818 [127].

NOTE 2: FQDN from other PLMN includes the network domain of the other PLMN.

– FQDN of the SEPP in the request initiating PLMN is the identifier of the SEPP in the request initaiting PLMN (e.g. VPLMN).

28.6 5GS Tracking Area Identity (TAI)

The 5GS 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 28.6-1.

Figure 28.6-1: Structure of the 5GS 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 3-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 2-digit or 3-digit MNC contained in the IMSI;

– 5GS Tracking Area Code (TAC) is a fixed length code (of 3 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:

– 000000, and

– FFFFFE.

NOTE 1: The above reserved values are used in some special cases when no valid TAI exists in the UE (see 3GPP TS 24.501 [125] for more information).

NOTE 2: In the 5G Core Network protocols, when the TAI 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 TAI 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 TAI.

28.7 Network Access Identifier (NAI)

28.7.1 Introduction

This clause describes the NAI formats used in the 5G System.

28.7.2 NAI format for SUPI

The NAI for SUPI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126].

A SUPI containing a network specific identifier shall take the form of a Network Access Identifier (NAI). See clause 5.9.2 of 3GPP TS 23.501 [119] for the definition and use of the network specific identifier. In SNPN scenarios, the realm part of the NAI may include MCC, MNC and the NID of the SNPN (see 3GPP TS 23.501 clauses 5.30.2.3, 5.30.2.9, 6.3.4, and 6.3.8; for the realm part format see Home Network Domain for an SNPN in clause 28.2).

See clauses 28.15.2 and 28.16.2 for the NAI format for a SUPI containing a GCI or a GLI.

28.7.3 NAI format for SUCI

When the SUPI is defined as a Network Specific Identifier, the SUCI shall take the form of a Network Access Identifier (NAI). In this case, the NAI format of the SUCI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where the realm part shall be identical to the realm part of the Network Specific Identifier. In SNPN scenarios, the realm part of the NAI may include MCC, MNC and the NID of the SNPN (see 3GPP TS 23.501 clauses 5.30.2.3, 5.30.2.9, 6.3.4, and 6.3.8; for the realm part format see Home Network Domain for an SNPN in clause 28.2).

When the SUPI is defined as an IMSI, the SUCI in NAI format shall have the form username@realm, where the realm part shall be constructed by converting the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in clause 28.2. In SNPN scenarios, the realm part shall additionally include the NID of the SNPN. The resulting realm part of the NAI shall be in the form:

"5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org", or

"5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org" (for SNPN scenarios).

The username part of the NAI shall take one of the following forms:

a) for the null-scheme:

type<supi type>.rid<routing indicator>.schid<protection scheme id>.userid<MSIN or Network Specific Identifier SUPI username>

b) for the Scheme Output for Elliptic Curve Integrated Encryption Scheme Profile A and Profile B:

type<supi type>.rid<routing indicator>.schid<protection scheme id>.hnkey<home network public key id>.ecckey<ECC ephemeral public key value>.cip<ciphertext value>.mac<MAC tag value>

c) for HPLMN proprietary protection schemes:

type<supi type>.rid<routing indicator>.schid<protection scheme id>.hnkey<home network public key id>. out<HPLMN defined scheme output>

See clause 2.2B for the definition and format of the different fields of the SUCI.

EXAMPLES:

Assuming the IMSI 234150999999999, where MCC=234, MNC=15 and MSISN=0999999999, the Routing Indicator 678, and a Home Network Public Key Identifier of 27, the NAI format for the SUCI takes the form:

– for the null-scheme:

type0.rid678.schid0.userid0999999999@5gc.mnc015.mcc234.3gppnetwork.org

– for the Profile <A> protection scheme:

type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>.cip< encryption of 0999999999>.mac<MAC tag value>@5gc.mnc015.mcc234.3gppnetwork.org

Assuming the Network Specific Identifier user17@example.com, the Routing Indicator 678, and a Home Network Public Key Identifier of 27, the NAI format for the SUCI takes the form:

– for the null-scheme:

type1.rid678.schid0.useriduser17@example.com

– for an anonymous SUCI:

type1.rid678.schid0.useridanonymous@example.com (with username corresponding to "anonymous"), or

type1.rid678.schid0.userid@example.com (with username corresponding to an empty string)

– for the Profile <A> protection scheme:

type1.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>.cip< encryption of user17>.mac<MAC tag value>@example.com

See clauses 28.15.5 and 28.16.5 for the NAI format for a SUCI containing a GCI or a GLI.

28.7.4 Emergency NAI for Limited Service State

This clause describes the format of the UE identification when UE is performing an emergency registration and IMSI is not available or not authenticated.

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.2 of IETF RFC 7542 [126]. 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.

or if IMEI is not available,

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.

28.7.5 Alternative NAI

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

The Alternative NAI shall contain a username part that is not 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".

28.7.6 NAI used for 5G registration via trusted non-3GPP access

While performing the EAP-authentication procedure when a UE attempts to register to 5GCN via a trusted non-3GPP access network in a selected PLMN (see clause 4.12a in 3GPP TS 23.502 [120]), the UE shall derive a NAI from the identity of the selected PLMN in the following format:

"<any_non_null_string>@nai.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

where:

a) the username part <any_non_null_string> is any non null string; and

b) the <MNC> and <MCC> identify the PLMN (either HPLMN or VPLMN) to which the UE attempts to connect via the trusted non-3GPP access network as described in clause 6.3.12 in 3GPP TS 23.501 [119].

While performing the EAP-authentication procedure when a UE attempts to register to 5GCN via a trusted non-3GPP access network in a selected SNPN (see clause 5.30.2.13 in 3GPP TS 23.501 [119]), the UE shall derive a NAI from the identity of the selected SNPN in the following format:

"<any_non_null_string>@nai.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org";

where:

a) the username part <any_non_null_string> is any non null string; and

b) the <MNC>, <MCC> and <NID> identify the SNPN to which the UE attempts to connect via the trusted non-3GPP access network.

NOTE 1: The username part of the NAI is not used to identify the UE since the UE is identified by its NAS registration to the 5GCN independent of using the NAI. The realm part of the NAI is however used by the trusted non-3GPP access for TNGF selection.

NOTE 2: In case of 5GCN, there is no need for a decorated NAI as in EPC (see clause 19.3.3), since the UE sends a NAS registration request to the PLMN including a SUCI or 5G-GUTI.

28.7.7 NAI used by N5CW devices via trusted non-3GPP access

While performing the EAP authentication procedure when a non 5G capable over WLAN (N5CW) device attempts to register to 5GCN via a trusted non-3GPP access network (see clause 4.12 b in 3GPP TS 23.502 [120]), the N5CW device shall use a NAI in the following format:

"<5G_device_unique_identity>@nai.5gc-nn.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

Where:

a) the username part <5G_device_unique_identity> is to identify the N5CW device and contains either:

– SUCI as defined as the username part of the NAI format in clause 28.7.3, if the UE is not registered to 5GCN via NG-RAN; or

– 5G-GUTI as defined as the username part of the NAI format in clause 28.7.8, if the N5CW device is registered to 5GCN via NG-RAN; and

b) the label ‘5gc-nn’ in the realm part indicates the NAI is used by N5CW devices via trusted non-3GPP access. <MNC> and <MCC> identify the PLMN (either HPLMN or VPLMN) to which the N5CW device attempts to connect via the trusted non-3GPP access as described in clause 6.3.12 of 3GPP TS 23.501 [119].

NOTE: As defined in 3GPP TS 33.501 [124], an N5CW device is authenticated using EAP-AKA’, thus, it has a USIM that stores the HPLMN identity.

28.7.8 NAI format for 5G-GUTI

The NAI format of the 5G-GUTI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126].

The username part of the NAI shall take the following form:

tmsi<5G-TMSI>.pt<AMF Pointer>.set<AMF Set Id>.region<AMF Region Id>

<5G-TMSI>, <AMF Pointer>, <AMF Set Id> and <AMF Region Id> are the hexadecimal strings of the 5G-TMSI, AMF Pointer, AMF Set ID and AMF Region ID. If there are less than 8 significant digits in <5G-TMSI>, "0" digit(s) shall be inserted at the left side to fill the 8 digits coding. If there are less than 2 significant digits in <AMF Pointer> or <AMF Region Id>, "0" digit(s) shall be inserted at the left side to fill the 2 digits coding of the AMF Pointer or AMF Region Id respectively. If there are less than 3 significant digits in <AMF Set Id>, "0" digit(s) shall be inserted at the left side to fill the 3 digits coding.

Example:

Assuming 5G-TMSI = 06666666 (hexadecimal), AMF Pointer=12 (hexadecimal), AMF Set = 001 (hexadecimal), AMF Region = 48 (hexadecimal), the username part of the NAI is encoded as:

"tmsi06666666.pt12.set001.region48"

The NAI for an N5CW device in a PLMN (either HPLMN or VPLMN) with MNC=012 and MCC=345, to which the N5CW device attempts to connect via the trusted non-3GPP access, according to clause 28.7.7 is:

"tmsi06666666.pt12.set001.region48@nai.5gc-nn.mnc012.mcc345.3gppnetwork.org"

28.7.9 Decorated NAI format for SUCI

The Decorated NAI format for SUCI shall take the form of a NAI and shall have the form

‘Homerealm!username@otherrealm’

as specified in clause 2.7 of the IETF RFC 4282 [53].

The username part of Decorated NAI shall contain the username of the NAI format for SUCI as specified in clause 28.7.3.

‘Homerealm’ shall be the realm of the NAI format for SUCI as specified in clause 28.7.3.

The realm part of Decorated NAI consists of ‘otherrealm’, see the IETF RFC 4282 [53]. Otherrealm’ is the realm built using the PLMN ID (visitedMCC + visited MNC) of the visited PLMN.

The result is a decorated NAI of the form:

5gc-nswo.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org!<username of SUCI in NAI format>@5gc-nswo.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org

EXAMPLE:

Assuming the IMSI 234150999999999, where MCC=234, MNC=15 and MSISN=0999999999, the Routing Indicator 678, a Home Network Public Key Identifier of 27, the null-scheme, and the service provider has a PLMN ID (MCC = 610, MNC = 71):

– the NAI format for the SUCI takes the form:

type0.rid678.schid0.userid0999999999@5gc.mnc015.mcc234.3gppnetwork.org

– the Decorated NAI format for the SUCI takes the form:

5gc-nswo.mnc015.mcc234.3gppnetwork.org!type0.rid678.schid0.userid0999999999@5gc-nswo.mnc071.mcc610.3gppnetwork.org

Editor’s note: it is FFS if this clause is needed, pending SA2 reply to CT4 LS on NAI format for 5G NSWO.

28.7.10 NAI format for UP-PRUK ID

The NAI format for UP-PRUK ID shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where:

– the realm part shall be in the form:

"prose-up.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

– the username part shall be a non-empty string which is unique in the realm, as specified in 3GPP TS 33.503 [142].

The maximum length of a UP-PRUK ID in NAI format is 254 octets.

28.7.11 NAI format for CP-PRUK ID

The NAI format for CP-PRUK ID shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126].

The realm part shall be in the form:

"prose-cp.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

The username part of the NAI shall take one of the following forms:

"rid<routing indicator>.pid<CP-PRUK ID*>"

– the <routing indicator> part is the "Routing Indicator" as specified in clause 2.2B.

– the <CP-PRUK ID*> part is the hexadecimal representation of the CP-PRUK ID* specified in clause A.3 of 3GPP TS 33.503 [142].

The maximum length of a CP-PRUK ID in NAI format is 254 octets.

28.7.12 NAI used for 5G NSWO

When the UE decides to use 5G NSWO to connect to the WLAN access network using its 5GS credentials but without registration to 5GS, the NAI format for 5G NSWO is used.

NOTE: In this case the NAI realm is different than the realm defined for usage during 5G registration via of Trusted non-3GPP access to the 5GCN (see clause 28.7.6) or when N5CW devices access 5GCN via Trusted non-3GPP access to the 5GCN (see clause 28.7.7). See clause 5.42 in 3GPPTS 23.501 [119].

In the 5G NSWO use case, the UE shall use a NAI in the following format:

"<username>@5gc-nswo.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

In the above use cases:

a) the username part is defined in clause 28.7.3; and

b) the label ‘5gc-nswo’ in the realm part indicates the NAI is used for 5G NSWO. <MNC> and <MCC> identify the PLMN to which the UE attempts to connect via the 5G NSWO as described in clause 4.2.15 of 3GPP TS 23.501 [119].

28.8 Generic Public Subscription Identifier (GPSI)

The Generic Public Subscription Identifier (GPSI) is defined in clause 5.9.8 of 3GPP TS 23.501 [119].

The GPSI is defined as:

– a GPSI type: in this release of the specification, it may indicate an MSISDN or an External Identifier; and

– dependent on the value of the GPSI type:

– an MSISDN as defined in clause 3.3; or

– an External Identifier as defined in clause 19.7.2.

NOTE: Depending on the protocol used to convey the GPSI, the GPSI type can take different formats.

28.9 Internal-Group Identifier

Internal-Group Identifier is a network internal globally unique ID which identifies a set of SUPIs (e.g. MTC devices) from a given network that are grouped together for one specific group related service (see 3GPP TS 23.501 [119] clause 5.9.7).

An Internal-Group Identifier shall be composed in the same way as IMSI-Group Identifier (see clause 19.9).

If a 5G subscriber’s IMSI belongs to an IMSI-Group identified by a given IMSI-Group Identifier X, the IMSI shall also belong to the Internal-Group identified by the Internal-Group Identifier X.

28.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.501 [119] and 3GPP TS 23.503 [121].

A PRA is composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers 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 AMF.

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 formatted as an integer within the following ranges:

0 .. 8 388 607 for UE-dedicated PRA

8 388 608 to 16 777 215 for Core Network predefined PRA.

NOTE: The PRA ID is encoded over the Service Based Interfaces as a string of digits representing an integer. See 3GPP TS 29.571 [129].

28.11 CAG-Identifier

A Closed Access Group (CAG) within a PLMN is uniquely identified by a CAG-Identifier (see 3GPP TS 23.501 [119]).

The CAG-Identifier shall be a fixed length 32 bit value.

28.12 NF Set Identifier (NF Set ID)

A NF Set Identifier is a globally unique identifier of a set of equivalent and interchangeable CP NFs from a given network that provide distribution, redundancy and scalability (see clause 5.21.3 of 3GPP TS 23.501 [119]).

An NF Set Identifier shall be constructed from the MCC, MNC, NID (for SNPN), NF type and a Set ID.

A NF Set Identifier shall be formatted as the following string:

set<Set ID>.<nftype>set.5gc.mnc<MNC>.mcc<MCC> for a NF Set in a PLMN, or

set<Set ID>.<nftype>set.5gc.nid<NID>.mnc<MNC>.mcc<MCC> for a NF Set in a SNPN.

where:

– the <MCC> and <MNC> shall identify the PLMN of the NF Set and shall be encoded as follows:

– <MCC> = 3 digits

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

– the Network Identifier (NID) shall be encoded as hexadecimal digits as specified in clause 12.7.

– the <NFType> shall identify the NF type of the NFs within the NF set and shall be encoded as a value of Table 6.1.6.3.3-1 of 3GPP TS 29.510 [130] but with lower case characters;

– the Set ID shall be a NF type specific Set ID 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;

– the case of alphabetic characters is not significant (i.e. two NF Set IDs with the same characters but using different lower and upper cases identify the same NF Set).

For an AMF set, the Set ID shall be set to "<AMF Set ID>.region<AMF Region ID>", with the AMF Region ID and AMF Set ID encoded as defined in 3GPP TS 29.571 [129].

EXAMPLE 1: setxyz.smfset.5gc.mnc012.mcc345

EXAMPLE 2: set12.pcfset.5gc.mnc012.mcc345

EXAMPLE 3: set001.region48.amfset.5gc.mnc012.mcc345 (for AMF Region 48 (hexadecimal) and AMF Set 1)

EXAMPLE 4: setxyz.smfset.5gc.nid000007ed9d5.mnc012.mcc345 for a SNPN with the NID 000007ed9d5 (hexadecimal).

NOTE: If needed, an FQDN can be derived from a given NF Set ID by appending the ".3gppnetwork.org" domain to the NF Set ID, see e.g. SMF Set FQDN in clause 28.3.2.9. For NFs whose NF type contains an underscore and for which an FQDN needs to be derived, the underscore is replaced by an hyphen in the corresponding label of the FQDN.

NF Instances of an NF Set are equivalent and share the same MCC, MNC, NID (for SNPN), NF type and NF Set ID.

28.13 NF Service Set Identifier (NF Service Set ID)

A NF Service Set Identifier is a globally unique identifier of a set of equivalent and interchangeable CP NF service instances within a NF instance from a given network that provide distribution, redundancy and scalability (see clause 5.21.3 of 3GPP TS 23.501 [119]).

An NF Service Set Identifier shall be constructed from the MCC, MNC, NID (for SNPN), NF instance Identifier, service name and a Set ID.

A NF Service Set Identifier shall be formatted as the following string:

set<Set ID>.sn<Service Name>.nfi<NF Instance ID>.5gc.mnc<MNC>.mcc<MCC> for a NF Service Set in a PLMN, or

set<Set ID>.sn<Service Name>.nfi<NF Instance ID>.5gc.nid<NID>.mnc<MNC>.mcc<MCC> for a NF Service Set in a SNPN.

where:

– the <MCC> and <MNC> shall identify the PLMN of the NF Service Set and shall be encoded as follows:

– <MCC> = 3 digits

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

– the Network Identifier (NID) shall be encoded as hexadecimal digits as specified in clause 12.7.

– the NFInstanceID shall identify the NF instance of the NF Service set, as defined by 3GPP TS 23.501 [119] and 3GPP TS 29.510 [130];

– the ServiceName shall identify the NF service of the NF Service set, as defined by 3GPP TS 29.510 [130];

– the Set ID shall be a service specific Set ID within the NF instance, 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;

– the case of alphabetic characters is not significant (i.e. two NF Service Set IDs with the same characters but using different lower and upper cases identify the same NF Service Set).

EXAMPLE 1: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345

EXAMPLE 2: set2.snnpcf-smpolicycontrol.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345

EXAMPLE 3: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.nid000007ed9d5.mnc012.mcc345 for a SNPN with the NID 000007ed9d5 (hexadecimal).

NF service instances from different NF instances are equivalent NF service instances if they share the same MCC, MNC, NID (for SNPN), ServiceName and Set ID.

NF Service Sets belonging to different NF Instances are said to be equivalent, if they share the same MCC, MNC, NID (for SNPN), ServiceName and Set ID.

28.14 Data Network Access Identifier (DNAI)

A Data Network Access Identifier (DNAI) is an operator defined identifier of a user plane access to one or more DN(s) where applications are deployed (see clauses 3.1 and 5.6.7 in 3GPP TS 23.501 [119]). The same DN may also be referred to by multiple DNAIs.

DNAI is represented as an operator specific string (see clause A.2 in 3GPP TS 29.571 [129]. The format of the DNAI is defined by the operator and is not standardized.

28.15 Global Cable Identifier (GCI)

28.15.1 Introduction

This clause describes the GCI formats used in the 5G System.

28.15.2 NAI format for SUPI containing a GCI

A SUPI containing a GCI shall take the form of a Network Access Identifier (NAI).

The NAI for SUPI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where:

– the username part shall be the GCI, as defined in clause 28.15.4;

– the realm part shall identify the operator owning the subscription; if the operator owns a PLMN ID, the realm part should be in the form:

"5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

EXAMPLE 1: 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org

EXAMPLE 2: 00-00-5E-00-53-00@operator.com

28.15.3 User Location Information for RG accessing the 5GC via W-5GCAN (HFC Node ID)

The User Location information for a 5G-CRG/FN-CRG accessing the 5GC via a Wireline 5G Cable Access network (W-5GCAN) shall take the form of an HFC Node ID. The HFC Node ID consists of a string of up to six characters as specified in CableLabs WR‑TR‑5WWC‑ARCH [134]. .

28.15.4 GCI

The GCI uniquely identifies the line connecting the 5G-CRG or FN-CRG to the 5GS.

The GCI is a variable length opaque identifier, encoded as specified in CableLabs WR‑TR‑5WWC‑ARCH [134] and CableLabs DOCSIS MULPI [135]. It shall comply with the syntax specified in clause 2.2 of IETF RFC 7542 [126] for the username part of a NAI.

NOTE: The GCI contains an HFC_Identifier, see WR‑TR‑5WWC‑ARCH [134] and CableLabs DOCSIS MULPI [135].

EXAMPLE: 00-00-5E-00-53-00

28.15.5 NAI format for SUCI containing a GCI

The SUCI containing a GCI shall take the form of a Network Access Identifier (NAI).

The NAI format of the SUCI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where the realm part shall be identical to the realm part of the SUPI (see clause 28.15.2).

The username part of the NAI shall be encoded as specified for the null-scheme in clause 28.7.3, i.e. it shall take the following form:

type3.rid0.schid0.userid<username>

where the username shall be encoded as the username part of the SUPI (see clause 28.15.2).

EXAMPLE 1: type3.rid0.schid0.userid00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org

EXAMPLE 2: type3.rid0.schid0.userid00-00-5E-00-53-00@operator.com

28.16 Global Line Identifier (GLI)

28.16.1 Introduction

This clause describes the GLI formats used in the 5G System.

28.16.2 NAI format for SUPI containing a GLI

A SUPI containing a GLI shall take the form of a Network Access Identifier (NAI).

The NAI for SUPI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where:

– the username part shall be the GLI, as defined in clause 28.16.4;

– the realm part shall identify the operator owning the subscription; if the operator owns a PLMN ID, the realm part should be in the form:

"5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org"

28.16.3 User Location Information for RG accessing the 5GC via W-5GBAN

The User Location information for a 5G-BRG/FN-BRG accessing the 5GC via a Wireline BBF Access Network (W-5GBAN) shall take the form of a GLI as defined in clause 28.16.4.

28.16.4 GLI

The GLI uniquely identifies the line connecting the 5G-BRG or FN-BRG to the 5GS.

The GLI is a variable length opaque identifier, consisting of a string of up to 200 base64-encoded characters, representing the GLI value (up to 150 bytes) encoded as specified in BBF WT-470 [133].

NOTE: The GLI contains an identifier of the Line ID source and the Line ID value, see BBF WT-470 [133].

28.16.5 NAI format for SUCI containing a GLI

The SUCI containing a GLI shall take the form of a Network Access Identifier (NAI).

The username part of the NAI shall be encoded as specified for the null-scheme in clause 28.7.3, i.e. it shall take the following form:

type2.rid0.schid0.userid<username>

where the username shall be encoded as the username part of the SUPI (see clause 28.16.2).

28.17 DNS subdomain for operator usage in 5GC

The 5GC 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 Domain for 5GC (see clause 28.2) and shall be constructed as:

node.5gc.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.