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 clause 5.9.7 of TS 23.501).
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.
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 TS 23.501 and TS 23.503.
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.
A Closed Access Group (CAG) within a PLMN is uniquely identified by a CAG-Identifier (see TS 23.501).
The CAG-Identifier shall be a fixed length 32 bit value.
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 TS 23.501).
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 TS 29.510 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 TS 29.571.
EXAMPLE 1:
setxyz.smfset.5gc.mnc012.mcc345
EXAMPLE 2:
set12.pcfset.5gc.mnc012.mcc345
EXAMPLE 3:
set0011-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).
FQDN.
NF Instances of an NF Set are equivalent and share the same MCC, MNC, NID (for SNPN), NF type and NF Set ID.
In earlier versions of this specification, the Set ID of an AMF Set was defined to be set to the string "<AMF Set ID>.region<AMF Region ID>". For backward compatibility with AMF implementations complying with these earlier versions of the specifications, AMF peers' implementations shall:
support receiving such a former encoding of an AMF Set ID in 3GPP custom HTTP headers (e.g. 3gpp-Sbi-Binding header or 3gpp-Sbi-Producer header) and shall interpret it the same as if they receive these headers with the AMF Set format defined in the current version of the specification; and
use the amf-region-id and the amf-set-id query parameters when they need to discover the AMF profiles of the AMF set registered at the NRF, when receiving a binding header with such a former encoding of the AMF 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 TS 23.501).
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 TS 23.501 and TS 29.510;
the ServiceName shall identify the NF service of the NF Service set, as defined by TS 29.510;
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).
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.
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 of TS 23.501). The same DN may also be referred to by multiple DNAIs.
DNAI is represented as an operator specific string (see clause A.2 of TS 29.571. The format of the DNAI is defined by the operator and is not standardized.
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 Section 2.2 of RFC 7542, 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:
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].
The User Location information shall include the GCI and HFC Node ID for a AUN3 device connected behind the 5G-CRG (see clause 7.2.8.1 of TS 23.316).
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 Section 2.2 of RFC 7542 for the username part of a NAI.
EXAMPLE:
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 Section 2.2 of RFC 7542, 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:
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 Section 2.2 of RFC 7542, 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:
The User Location information for a 5G-BRG/FN-BRG accessing the 5GC via a Wireline BBF Access Network (W-5GBAN), and for a AUN3 device connected behind the 5G-BRG (see clause 7.2.8.1 of TS 23.316), shall take the form of a GLI as defined in clause 28.16.4.
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].
The SUCI containing a GLI 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 Section 2.2 of RFC 7542, where the realm part shall be identical to the realm part of the SUPI (see clause 28.16.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:
type2.rid0.schid0.userid<username>
where the username shall be encoded as the username part of the SUPI (see clause 28.16.2).
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.
For routing HTTP/2 request messages to NF in a different SNPN, the FQDN of the target NF shall have the Home Network Domain of the SNPN (see clause 28.2) as the trailing part.
The User Location information for a UE behind the 5G-RG using trusted N3GPP access (see clause 7.2.8.1 of TS 23.316), shall include a TNAP ID with 5G-RG civic address information.
The following clauses describe Location Services (LCS) specific identifiers which are used by both the UE and the 5GC (LMF and AMF), see clause 6 of TS 23.273.
The LCS Session Identity may contain an LCS correlation identifier, or a routing identifier, or a deferred routing identifier. The LCS Session Identity is used by Location supplementary services messages and LPP messages. The LCS correlation identifier is encoded as a variable length string with a minimum length of 1 octet and the maximum length of 255 octets, see clause 11.2.3 of TS 24.572.
The LCS correlation identifier is assigned either by an LMF, or AMF. It is used to identify a control plane and also a user plane LCS session between the UE and the LMF. The LCS correlation identifier is encoded as an alpha-numerical string (see also CorrelationID type definition in clause 6.1.6.3.2 of TS 29.572).
The routing identifier is assigned by an AMF. The AMF associates the routing identifier with the LCS correlation identifier. The routing identifier is used to identify the LMF. The routing identifier is encoded as a Universally Unique Identifier (UUID) version 4, see clause 6.1.6.2.10 and clause 6.1.6.2.12 of TS 29.518 and also the NfInstanceId type definition in clause 5.3.2 of TS 29.571.
The deferred routing identifier is assigned by an LMF. It is used to identify the serving or the default LMF. It may be encoded e.g. as an IP address, UUID, URI, or as a generic alpha-numerical string (see TS 23.273 e.g. clause 6.3.1).
The LCS User Plane Connection ID (see e.g. clause 6.18 of TS 23.273), or the LCS User Plane Binding ID (LCS-UP Binding ID, see clause 11.3.4 of TS 24.572) is assigned by an LMF. It is used by an LMF to associate the UE identity (SUPI and/or GUTI) with the LCS user plane connection between the UE and the LMF. The LCS User Plane Connection/Binding ID is encoded as a variable length alpha-numerical string with minimum length of 1 octet and the maximum length of 255 octets (see the LCS-UP Binding ID IE definition in clause 11.3.4 of TS 24.572).
The following clauses describe MPQUIC specific identifiers which are used by both the UE and the 5GC (UPF) if MPQUIC functionality is utilized, see clause 5.32 in TS 23.501.
If MPQUIC functionality is used between the UE and the anchor UPF, the Context ID value determines the contents of the UDP Proxying Payload (see Section 4 of RFC 9298 and Section 5 of RFC 9298) and also whether 3GPP specified Datagram mode 1 or mode 2 is used (see TS 24.193).