2 Identification of mobile subscribers

23.0033GPPNumbering, addressing and identificationRelease 18TS

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

2.1 General

A unique International Mobile Subscription Identity (IMSI) shall be allocated to each mobile subscriber in the GSM/UMTS/EPS system.

NOTE: This IMSI is the concept referred to by ITU-T as "International Mobile Subscription Identity".

In order to support the subscriber identity confidentiality service the VLRs, SGSNs and MME may allocate Temporary Mobile Subscriber Identities (TMSI) to visiting mobile subscribers. The VLR,SGSN and MME must be capable of correlating an allocated TMSI with the IMSI of the MS to which it is allocated.

An MS may be allocated three TMSIs, one for services provided through the MSC, one for services provided through the SGSN (P-TMSI for short) and one for the services provided via the MME (M-TMSI part GUTI for short).

For addressing on resources used for GPRS, a Temporary Logical Link Identity (TLLI) is used. The TLLI to use is built by the MS either on the basis of the P-TMSI (local or foreign TLLI), or directly (random TLLI).

In order to speed up the search for subscriber data in the VLR a supplementary Local Mobile Station Identity (LMSI) is defined.

The LMSI may be allocated by the VLR at location updating and is sent to the HLR together with the IMSI. The HLR makes no use of it but includes it together with the IMSI in all messages sent to the VLR concerning that MS.

2.2 Composition of IMSI

IMSI is composed as shown in figure 1.

Figure 1: Structure of IMSI

IMSI is composed of three parts:

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

2) Mobile Network Code (MNC) consisting of two or three digits for 3GPP network applications. The MNC identifies the home PLMN of the mobile subscription within its country of domicile, or it identifies together with MCC and NID the mobile subscription’s SNPN. The length of the MNC (two or three digits) depends on the value of the MCC. A mixture of two and three digit MNC codes within a single MCC area is not recommended and is outside the scope of this specification.

3) Mobile Subscriber Identification Number (MSIN) identifying the mobile subscription within a PLMN or SNPN.

2.2A Subscription Permanent Identifier (SUPI)

The SUPI is a globally unique 5G Subscription Permanent Identifier allocated to each subscriber in the 5G System. It is defined in clause 5.9.2 of 3GPP TS 23.501 [119].

The SUPI is defined as:

– a SUPI type: in this release of the specification, it may indicate an IMSI, a Network Specific Identifier (NSI), a Global Line Identifier (GLI) or a Global Cable Identifier (GCI); and

– dependent on the value of the SUPI type:

– an IMSI as defined in clause 2.1;

– a Network Specific Identifier (NSI), taking the form of a Network Access Identifier (NAI) as defined in clause 28.7.2;

– a Global Cable Identifier (GCI) taking the form of a NAI as defined in clause 28.15.2;

– a Global Line Identifier (GLI) taking the form of an NAI as defined in clause 28.16.2.

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

See clauses 4.7.2, 4.7.3 and 4.7.4 of 3GPP TS 23.316 [131] for details on which types of SUPI are supported by 5G-BRG, FN-BRG, 5G-CRG and FN-CRG.

2.2B Subscription Concealed Identifier (SUCI)

The SUCI is a privacy preserving identifier containing the concealed SUPI. It is defined in clause 6.12.2 of 3GPP TS 33.501 [124].

Figure 2.2B-1: Structure of SUCI

The SUCI is composed of the following parts:

1) SUPI Type, consisting in a value in the range 0 to 7. It identifies the type of the SUPI concealed in the SUCI. The following values are defined:

– 0: IMSI

– 1: Network Specific Identifier (NSI)

– 2: Global Line Identifier (GLI)

– 3: Global Cable Identifier (GCI)

– 4 to 7: spare values for future use.

2) Home Network Identifier, identifying the home network of the subscriber.

When the SUPI Type is an IMSI, the Home Network Identifier is composed of two parts:

– Mobile Country Code (MCC), consisting of three decimal digits. The MCC identifies uniquely the country of domicile of the mobile subscription;

– Mobile Network Code (MNC), consisting of two or three decimal digits. The MNC identifies the home PLMN or SNPN of the mobile subscription.

When the SUPI type is a Network Specific Identifier (NSI), a GLI or a GCI, the Home Network Identifier consists of a string of characters with a variable length representing a domain name as specified in clause 2.2 of IETF RFC 7542 [126]. For a GLI or a GCI, the domain name shall correspond to the realm part specified in the NAI format for SUPI in clauses 28.15.2 and 28.16.2.

3) Routing Indicator, consisting of 1 to 4 decimal digits assigned by the home network operator and provisioned in the USIM, that allow together with the Home Network Identifier to route network signalling with SUCI to AUSF and UDM instances capable to serve the subscriber.

Each decimal digit present in the Routing Indicator shall be regarded as meaningful (e.g. value "012" is not the same as value "12"). If no Routing Indicator is configured on the USIM or the ME, this data field shall be set to the value 0 (i.e. only consist of one decimal digit of "0").

4) Protection Scheme Identifier, consisting in a value in the range of 0 to 15 (see Annex C.1 of 3GPP TS 33.501 [124]). It represents the null scheme or a non-null scheme specified in Annex C of 3GPP TS 33.501 [124] or a protection scheme specified by the HPLMN; the null scheme shall be used if the SUPI type is a GLI or GCI.

5) Home Network Public Key Identifier, consisting in a value in the range 0 to 255. It represents a public key provisioned by the HPLMN or SNPN and it is used to identify the key used for SUPI protection. This data field shall be set to the value 0 if and only if null protection scheme is used;

6) Scheme Output, consisting of a string of characters with a variable length or hexadecimal digits, dependent on the used protection scheme, as defined below. It represents the output of a public key protection scheme specified in Annex C of 3GPP TS 33.501 [124] or the output of a protection scheme specified by the HPLMN.

Figure 2.2B-2 defines the scheme output for the null protection scheme.

Figure 2.2B-2: Scheme Output for the null protection scheme

The Mobile Subscriber Identification Number ("MSIN") is defined in clause 2.2; the "username" corresponds to the username part of a NAI, and it is applicable to SUPI types Network-Specific Identifier (clause 28.7.2), GLI (clause 28.16.2) or GCI (clause 28.15.2).

NOTE 1: For a SUCI with SUPI Type 2 or 3 (i.e. GLI or GCI), the SUCI can, based on subscription information, act as a pseudonym of the actual SUPI containing an IMSI (see 3GPP TS 23.316 [131], clauses 4.7.3 and 4.7.4). If so, the UDM derives the actual SUPI (IMSI) from the de-concealed SUCI (GLI/GCI).

An anonymous SUCI is composed by setting the SUPI Type field to 1 (Network-Specific Identifier), using the null protection scheme, and where the scheme output corresponds to a username set to either the "anonymous" string or to an empty string (see IETF RFC 7542 [126], clause 2.4).

The scheme output is formatted as a variable length of characters as specified for the username in clause 2.2 of IETF RFC 7542 [126].

NOTE 2: If the null protection scheme is used, the NFs can derive SUPI from SUCI when needed. The AMF derives SUPI used for AUSF discovery from SUCI when the Routing-Indicator is zero and the protection scheme is null. For an anonymous SUCI, an NF can derive an anonymous SUPI from an anonymous SUCI when needed; this is, the NF can derive a SUPI in NAI format for which the "username" part of the SUPI is "anonymous" or omitted.

Figure 2.2B-3 defines the scheme output for the Elliptic Curve Integrated Encryption Scheme Profile A.

Figure 2.2B-3: Scheme Output for Elliptic Curve Integrated Encryption Scheme Profile A

The ECC ephemeral public key is formatted as 64 hexadecimal digits, which allows to encode 256 bits.

The ciphertext value is formatted as a variable length of hexadecimal digits.

The MAC tag value is formatted as 16 hexadecimal digits, which allows to encode 64 bits.

Editor’s Note: clause C.3.2 of TS 33.501 specifies that the scheme output may contain other parameters (not further defined in the specification). It is FFS how to format these parameters.

Figure 2.2B-4 defines the scheme output for the Elliptic Curve Integrated Encryption Scheme Profile B.

Figure 2.2B-4: Scheme Output for Elliptic Curve Integrated Encryption Scheme Profile B

The ECC ephemeral public key is formatted as 66 hexadecimal digits, which allows to encode 264 bits.

The ciphertext value is formatted as a variable length of hexadecimal digits.

The MAC tag value is formatted as 16 hexadecimal digits, which allows to encode 64 bits.

Editor’s Note: clause C.3.2 of TS 33.501 specifies that the scheme output may contain other parameters (not further defined in the specification). It is FFS how to format these parameters.

Figure 2.2B-5 defines the scheme output for Home Network proprietary protection schemes.

Figure 2.2B-5: Scheme Output for Home Network proprietary protection schemes

The Home Network defined scheme output is formatted as a variable length of hexadecimal digits. Its format is not further defined in 3GPP specifications.

As 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 SUCI for the null protection scheme is composed of: 0, 234, 15, 678, 0, 0 and 0999999999

– the SUCI for the Profile <A> protection scheme is composed of: 0, 234, 15, 678, 1, 27, <EEC ephemeral public key value>, <encryption of 0999999999> and <MAC tag value>

2.3 Allocation and assignment principles

IMSI shall consist of decimal digits (0 through 9) only.

The number of digits in IMSI shall not exceed 15.

The allocation and assignment of Mobile Country Codes (MCCs) is administered by the ITU. The current assignment is available on ITU web site (https://www.itu.int/en/ITU-T/inr/Pages/default.aspx).

The assignment of Mobile network Codes (MNC) is the responsibility of each national numbering plan administrator. MNCs under MCC ranges 90x are administered by the ITU. The MSIN is the third field of the IMSI, and is administered by the relevant MNC assignee to identify individual subscriptions.

If more than one PLMN exists in a country, the same Mobile Network Code should not be assigned to more than one PLMN.

The allocation of IMSIs should be such that not more than the digits MCC + MNC of the IMSI have to be analysed in a foreign PLMN for information transfer.

2.4 Structure of TMSI

Since the TMSI has only local significance (i.e. within a VLR and the area controlled by a VLR, or within an SGSN and the area controlled by an SGSN, or within an MME and the area controlled by an MME), the structure and coding of it can be chosen by agreement between operator and manufacturer in order to meet local needs.

The TMSI consists of 4 octets. It can be coded using a full hexadecimal representation.

In order to avoid double allocation of TMSIs after a restart of an allocating node, some part of the TMSI may be related to the time when it was allocated or contain a bit field which is changed when the allocating node has recovered from the restart.

In areas where both MSC-based services and SGSN-based services are provided, some discrimination is needed between the allocation of TMSIs for MSC-based services and the allocation of TMSIs for SGSN-based services. The discrimination shall be done on the 2 most significant bits, with values 00, 01, and 10 being used by the VLR, and 11 being used by the SGSN.

If intra domain connection of RAN nodes to multiple CN nodes as described in 3GPP TS 23.236 [23] is applied in the MSC/VLR or SGSN, then the NRI shall be part of the TMSI. The NRI has a configurable length of 0 to 10 bits. A configurable length of 0 bits indicates that the NRI is not used and this feature is not applied in the MSC/VLR or SGSN. The NRI shall be coded in bits 23 to 14. An NRI shorter than 10 bits shall be encoded with the most significant bit of the NRI field in bit 23.

The TMSI shall be allocated only in ciphered form. See also 3GPP TS 43.020 [7] and 3GPP TS 33.102 [42].

The network shall not allocate a TMSI with all 32 bits equal to 1 (this is because the TMSI must be stored in the SIM, and the SIM uses 4 octets with all bits equal to 1 to indicate that no valid TMSI is available).

To allow for eventual modifications of the management of the TMSI code space management, MSs shall not check if an allocated TMSI belongs to the range allocated to the allocating node. MSs shall use an allocated TMSI according to the specifications, whatever its value.

2.5 Structure of LMSI

The LMSI consists of 4 octets and may be allocated by the VLR. The VLR shall not allocate the value zero. The value zero is reserved to indicate that an LMSI parameter sent from the HLR to the VLR shall not be interpreted.

2.6 Structure of TLLI

A TLLI is built by the MS or by the SGSN either on the basis of the P-TMSI (local or foreign TLLI), or directly (random or auxiliary TLLI), according to the following rules.

The TLLI consists of 32 bits, numbered from 0 to 31 by order of significance, with bit 0 being the LSB.

A local TLLI is built by an MS which has a valid P-TMSI as follows:

bits 31 down to 30 are set to 1; and

bits 29 down to 0 are set equal to bits 29 to 0 of the P-TMSI.

A foreign TLLI is built by an MS which has a valid P-TMSI as follows:

bit 31 is set to 1 and bit 30 is set to 0; and

bits 29 down to 0 are set equal to bits 29 to 0 of the P-TMSI.

A random TLLI is built by an MS as follows:

bit 31 is set to 0;

bits 30 down to 27 are set to 1; and

bits 0 to 26 are chosen randomly.

An auxiliary TLLI is built by the SGSN as follows:

bit 31 is set to 0;

bits 30 down to 28 are set to 1;

bit 27 is set to 0; and

bits 0 to 26 can be assigned independently.

Other types of TLLI may be introduced in the future.

Part of the TLLI codespace is re-used in GERAN to allow for the inclusion of the GERAN Radio Network Temporary Identifier in RLC/MAC messages. The G-RNTI is defined in 3GPP TS 44.118 [29].

The structure of the TLLI is summarised in table 1.

Table 1: TLLI structure

31	30	29	28	27	26 to 0	Type of TLLI
1	1	T	T	T	T	Local TLLI
1	0	T	T	T	T	Foreign TLLI
0	1	1	1	1	R	Random TLLI
0	1	1	1	0	A	Auxiliary TLLI
0	1	1	0	X	X	Reserved
0	1	0	X	X	X	Reserved
0	0	0	0	G	G	Part of the assigned G-RNTI
0	0	0	1	R	R	Random G-RNTI

‘T’, ‘R’, ‘A’ and ‘X’ indicate bits which can take any value for the type of TLLI. More precisely, ‘T’ indicates bits derived from a P-TMSI, ‘R’ indicates bits chosen randomly, ‘A’ indicates bits chosen by the SGSN, ‘G’ indicates bits derived from the assigned G-RNTI and ‘X’ indicates bits in reserved ranges.

2.7 Structure of P-TMSI Signature

The P-TMSI Signature consists of 3 octets and may be allocated by the SGSN.

The network shall not allocate a P-TMSI Signature with all 24 bits equal to 1 (this is because the P-TMSI Signature must be stored in the SIM, and the SIM uses 3 octets with all bits equal to 1 to indicate that no valid P-TMSI signature is available.

2.8 Globally Unique Temporary UE Identity (GUTI)

2.8.1 Introduction

The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user’s permanent identity in the Evolved Packet System (EPS). It also allows the identification of the MME and network. It can be used by the network and the UE to establish the UE’s identity during signalling between them in the EPS. See 3GPP TS 23.401 [72].

The GUTI has two main components:

– one that uniquely identifies the MME which allocated the GUTI; and

– one that uniquely identifies the UE within the MME that allocated the GUTI.

Within the MME, the mobile shall be identified by the M-TMSI.

The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI).

The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).

The GUTI shall be constructed from the GUMMEI and the M-TMSI.

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI.

The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

NOTE: In some network sharing cases it is required that the MMEC and NRI values are coordinated between the sharing operators, as described in 3GPP TS 23.251 [101]. In order to achieve CS/PS coordination in shared GERAN/UTRAN networks, the MMEC included in the GUTI can be set to identify the CS operator serving the UE.

The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).

The format and size of the GUTI is therefore the following:

<GUTI> = <GUMMEI><M-TMSI>,

where <GUMMEI> = <MCC><MNC><MME Identifier>

and <MME Identifier> = <MME Group ID><MME Code>

MCC and MNC shall have the same field size as in earlier 3GPP systems.

M-TMSI shall be of 32 bits length.

MME Group ID shall be of 16 bits length.

MME Code shall be of 8 bits length.

2.8.2 Mapping between Temporary and Area Identities for the EUTRAN and the UTRAN/GERAN based systems

2.8.2.0 Introduction

This clause provides information on the mapping of the temporary and location area identities, e.g. for the construction of the Routeing Area Update Request message in GERAN/UTRAN or Tracking Area Update Request message in E‑UTRAN.

In GERAN and UTRAN:

<P-TMSI/TLLI> includes the mapped NRI

P‑TMSI shall be of 32 bits length where the two topmost bits are reserved and always set to ’11’. Hence, for a UE which may handover to GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI are set to ’11’ (see clause 2.8.2.1.3).

3GPP TS 23.236 [23] specifies that the NRI field is of variable length and shall be mapped into the P‑TMSI starting at bit 23 and down to bit 14. The most significant bit of the NRI is located at bit 23 of the P‑TMSI regardless of the configured length of the NRI. To support mobility between GERAN/UTRAN and E-UTRAN, the NRI length is limited to a maximum of 8 bits to be compatible for the mapping to MME Code within GUTI (see clause 2.8.2.2).

The P‑TMSI and NRI are defined elsewhere in this specification.

In the case of a combined MME‑SGSN node, the NRI of the SGSN part and the MME code of the MME part, refer to the same combined node. RAN configuration allows NAS messages on GERAN/UTRAN and E‑UTRAN to be routed to the same combined node. The same or different values of NRI and MME code may be used for a combined node.

2.8.2.1 Mapping from GUTI to RAI, P-TMSI and P-TMSI signature

2.8.2.1.1 Introduction

This clause addresses the case when a UE moves from an MME to an SGSN. The SGSN may be either an S4 SGSN or a Gn/Gp SGSN.

2.8.2.1.2 Mapping in the UE

When a UE moves from an E-UTRAN to a GERAN/UTRAN, the UE needs to map the GUTI to an RAI, a P-TMSI and a P-TMSI Signature, for them to be sent to the SGSN. For GERAN, the TLLI is derived from the P-TMSI by the UE and is a foreign TLLI (see clause 2.6).

The mapping of the GUTI shall be done to the combination of RAI of GERAN / UTRAN and the P‑TMSI:

E‑UTRAN <MCC> maps to GERAN/UTRAN <MCC>

E‑UTRAN <MNC> maps to GERAN/UTRAN <MNC>

E‑UTRAN <MME Group ID> maps to GERAN/UTRAN <LAC>

E‑UTRAN <MME Code> maps to GERAN/UTRAN <RAC> and is also copied into the 8 Most Significant Bits of the NRI field within the P‑TMSI;

E‑UTRAN <M-TMSI> maps as follows:

– 6 bits of the E‑UTRAN <M-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the GERAN/UTRAN <P‑TMSI>;

– 16 bits of the E‑UTRAN <M-TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the GERAN/UTRAN <P‑TMSI>;

– and the remaining 8 bits of the E‑UTRAN <M-TMSI> are mapped into the 8 Most Significant Bits of the <P-TMSI signature> field.

The UE shall fill the remaining 2 octets of the <P-TMSI signature> according to clauses 9.1.1, 9.4.1, 10.2.1, or 10.5.1 of 3GPP TS.33.401 [89] , as appropriate, for RAU/Attach procedures.

For UTRAN, the 10-bit long NRI bits are masked out from the P-TMSI and are also supplied by the UE to the RAN node as IDNNS (Intra Domain NAS Node Selector) (see 3GPP TS 23.236 [23]). However, the RAN configured NRI length should not exceed 8 bits.

2.8.2.1.3 Mapping in the old MME

A new SGSN attempts to retrieve information regarding the UE, e.g. the IMSI, from the old MME. In order to find the UE context, the MME needs to map the RAI, P-TMSI (or TLLI) and the P-TMSI Signature (sent by the SGSN) to create the GUTI and compare it with the stored GUTI.

The MME shall perform a reverse mapping to the mapping procedure specified in clause 2.8.2.1.2 "Mapping in the UE" (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of the messaging). For the reverse mapping, the E-UTRAN <MME Code> within the GUTI shall be set either to bits 23 to 16 of the GERAN/UTRAN <P-TMSI> (i.e., the NRI field) or to the GERAN/UTRAN <RAC>. For GERAN TLLI, the old MME replaces the two topmost bits of TLLI, received from new SGSN via GTPv1, with ’11’ before mapping the TLLI to the GUTI used for looking up the "UE Context".

2.8.2.2 Mapping from RAI and P-TMSI to GUTI

2.8.2.2.1 Introduction

This clause addresses the case when a UE moves from an SGSN to an MME (i.e. during a TAU or an Attach to MME). The SGSN may be either an S4 SGSN or a Gn/Gp SGSN.

2.8.2.2.2 Mapping in the UE

When the UE moves from the GERAN/UTRAN to the E-UTRAN, the UE needs to map the RAI and P-TMSI to a GUTI to be sent to the MME. The P-TMSI signature is sent intact to the MME.

The mapping of P‑TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E‑UTRAN shall be performed as follows:

GERAN/UTRAN <MCC> maps to E‑UTRAN <MCC>

GERAN/UTRAN <MNC> maps to E‑UTRAN <MNC>

GERAN/UTRAN <LAC> maps to E‑UTRAN <MME Group ID>

GERAN/UTRAN <RAC> maps into bit 23 and down to bit 16 of the M‑TMSI

The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.

GERAN/UTRAN <P‑TMSI> maps as follows:

– 6 bits of the GERAN/UTRAN <P‑TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the E‑UTRAN <M-TMSI>;

– 16 bits of the GERAN/UTRAN <P‑TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the E‑UTRAN <M-TMSI>.

The values of <LAC> and <MME group id> shall be disjoint, so that they can be differentiated.

The most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set to one. Based on this definition, the most significant bit of the <MME group id> can be used to distinguish the node type, i.e. whether it is an MME or SGSN. The UE copies the received old SGSN’s <LAC> into the <MME Group ID> when sending a message to an MME, regardless of the value of the most significant bit of the <LAC>.
In networks where this definition is not applied (e.g. in networks already configured with LAC with the most significant bit set to 1 before LTE deployment), the information in the TAU/RAU request indicating whether the provided GUTI/P-TMSI is "native" (i.e. no system change) or "mapped" (i.e. system change) can be used to distinguish the node type for UEs implemented according to this release of the specification (see 3GPP TS 24.301 [90] and 3GPP TS 24.008 [5]). Specific network implementations still satisfying 3GPP standard interfaces can be used for pre-Rel-10 UEs to distinguish the node type.

NOTE 1: As an example, at NAS level, the MME/SGSN can retrieve the old SGSN/MME by using additional GUTI/additional RAI/P-TMSI with double DNS query to solve the first time the UE moves between E-UTRAN and GERAN/UTRAN. As another example, the MME/SGSN can retrieve the old SGSN/MME by using double DNS query.

2.8.2.2.3 Mapping in the new MME

In order to retrieve the UE’s information, e.g. the IMSI, from the old SGSN, the new MME extracts only the RAI and P-TMSI from the GUTI via the reverse mapping procedure to that specified in clause 2.8.2.2.2. This is done in order to be able to include the mapped RAI and P-TMSI, along with the P-TMSI Signature received by the MME from the UE, in the corresponding message sent to the old SGSN (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of the messaging). The old SGSN compares the received RAI, P-TMSI and P-TMSI Signature with the stored values for identifying the UE.

2.9 Structure of the S-Temporary Mobile Subscriber Identity (S-TMSI)

The S-TMSI is the shortened form of the GUTI to enable more efficient radio signalling procedures (e.g. paging and Service Request). For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI:

<S-TMSI> = <MMEC><M-TMSI>

See clause 2.8 for these definitions and the mapping.

2.10 5G Globally Unique Temporary UE Identity (5G-GUTI)

2.10.1 Introduction

The purpose of the 5G-GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user’s permanent identity in the 5G System (5GS). It also allows the identification of the Access and Mobility Management Function (AMF) and network. It can be used by the network and the UE to establish the UE’s identity during signalling between them in the 5GS. See 3GPP TS 23.501 [119].

The 5G-GUTI has two main components:

– one that identifies the AMF(s) which allocated the 5G-GUTI; and

– one that uniquely identifies the UE within the AMF(s) that allocated the 5G-GUTI.

Within the AMF(s), the mobile shall be identified by the 5G-TMSI.

The Globally Unique AMF Identifier (GUAMI) shall be constructed from the MCC, MNC and AMF Identifier (AMFI).

The AMFI shall be constructed from an AMF Region ID, an AMF Set ID and an AMF Pointer. The AMF Region ID identifies the region, the AMF Set ID uniquely identifies the AMF Set within the AMF Region, and the AMF Pointer identifies one or more AMFs within the AMF Set.

NOTE: When the UE is assigned a 5G-GUTI with an AMF Pointer value used by more than one AMF, the AMFs need to ensure that the 5G-TMSI value used within the assigned 5G-GUTI is not already in use within the AMF’s sharing that pointer value.

The 5G-GUTI shall be constructed from the GUAMI and the 5G-TMSI.

For paging purposes, the mobile is paged with the 5G-S-TMSI. The 5G-S-TMSI shall be constructed from the AMF Set ID, the AMF Pointer and the 5G-TMSI.

The operator shall need to ensure that the combination of the AMF Set ID and AMF Pointer is unique within the AMF Region and, if overlapping AMF Regions are in use, unique within the area of overlapping AMF Regions.

The 5G-GUTI shall be used to support subscriber identity confidentiality, and, in the shortened 5G-S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).

The format and size of the 5G-GUTI is therefore the following:

<5G-GUTI> = <GUAMI><5G-TMSI>,

where <GUAMI> = <MCC><MNC><AMF Identifier>

and <AMF Identifier> = <AMF Region ID><AMF Set ID><AMF Pointer>

MCC and MNC shall have the same field size as in earlier 3GPP systems.

5G-TMSI shall be of 32 bits length.

AMF Region ID shall be of 8 bits length.

AMF Set ID shall be of 10 bits length.

AMF Pointer shall be of 6 bits length.

2.10.2 Mapping between Temporary Identities for the 5GS and the E-UTRAN

2.10.2.0 Introduction

This clause provides information on the mapping of the temporary identities, e.g. for the construction of the Tracking Area Update Request message in E‑UTRAN.

In E-UTRAN:

2.10.2.1 Mapping from 5G-GUTI to GUTI

2.10.2.1.1 Introduction

This clause addresses the case when a UE moves from an AMF to an MME.

2.10.2.1.2 Mapping in the UE

When a UE moves from 5GS to an E-UTRAN, the UE needs to map the 5G-GUTI to a GUTI.

The mapping of the 5G-GUTI to a GUTI shall be done as follows:

5GS <MCC> maps to E-UTRAN <MCC>

5GS <MNC> maps to E-UTRAN <MNC>

5GS <AMF Region ID> and 5GS <AMF Set ID> map to E-UTRAN <MME Group ID> and part of E-UTRAN <MME Code> as follows:

– 8 bits of the 5GS <AMF Region ID> starting at bit 7 and down to bit 0 are mapped into bit 15 and down to bit 8 of the E‑UTRAN <MME Group ID>;

– 8 bits of the 5GS <AMF Set ID> starting at bit 9 and down to bit 2 are mapped into bit 7 and down to bit 0 of the E‑UTRAN <MME Group ID>;

– 2 bits of the 5GS <AMF Set ID> starting at bit 1 and down to bit 0 are mapped into bit 7 and down to bit 6 of the E‑UTRAN <MME Code>;

5GS <AMF Pointer> maps to part of E-UTRAN <MME Code> as follows:

– 6 bits of the 5GS <AMF Pointer> starting at bit 5 and down to bit 0 are mapped into bit 5 and down to bit 0 of the E‑UTRAN <MME Code>.

5GS <5G-TMSI> maps to to E-UTRAN <M-TMSI>

2.10.2.1.3 Mapping in the old AMF

A new MME attempts to retrieve information regarding the UE, e.g. the IMSI, from the old AMF. In order to find the UE context, the AMF needs to map the GUTI (sent by the MME) to create the 5G-GUTI and compare it with the stored 5G-GUTI.

The AMF shall perform a reverse mapping to the mapping procedure specified in clause 2.10.2.1.2 "Mapping in the UE".

2.10.2.2 Mapping from GUTI to 5G-GUTI

2.10.2.2.1 Introduction

This clause addresses the case when a UE moves from an MME to an AMF (i.e. during a Registration Update or an Initial Registration to an AMF).

2.10.2.2.2 Mapping in the UE

When the UE moves from the E-UTRAN to 5GS, the UE needs to map the GUTI to a 5G-GUTI to be sent to the AMF.

The mapping of the GUTI to a 5G-GUTI shall be performed as follows:

E-UTRAN <MCC> maps to 5GS <MCC>

E-UTRAN <MNC> maps to 5GS <MNC>

E‑UTRAN <MME Group ID> maps to 5GS <AMF Region ID> and part of 5GS <AMF Set ID> as follows:

– 8 bits of the E‑UTRAN <MME Group ID> starting at bit 15 and down to bit 8 are mapped into bit 7 and down to bit 0 of the 5GS <AMF Region ID>;

– 8 bits of the E‑UTRAN <MME Group ID> starting at bit 7 and down to bit 0 are mapped into bit 9 and down to bit 2 of the 5GS <AMF Set ID>;E-UTRAN <MME Code> maps to 5GS <AMF Set ID> and 5GS <AMF Pointer> as follows:

– 2 bits of the E‑UTRAN <MME Code> starting at bit 7 and down to bit 6 are mapped into bit 1 and down to bit 0 of the 5GS <AMF Set ID>;

– 6 bits of the E‑UTRAN <MMEC Code> starting at bit 5 and down to bit 0 are mapped into bit 5 and down to bit 0 of the 5GS <AMF Pointer >;

E-UTRAN <M‑TMSI> maps to 5GS <5G-TMSI>

2.10.2.2.3 Mapping in the new AMF

In order to retrieve the UE’s information, e.g. the IMSI, from the old MME, the new AMF shall perform a reverse mapping to the mapping procedure specified in clause 2.10.2.2.2 "Mapping in the UE". This is done in order to be able to include the mapped GUTI in the corresponding message sent to the old MME. The old MME compares the received GUTI with the stored values for identifying the UE.

2.11 Structure of the 5G-S-Temporary Mobile Subscriber Identity (5G-S-TMSI)

The 5G-S-TMSI is the shortened form of the 5G-GUTI to enable more efficient radio signalling procedures (e.g. paging and Service Request). For paging purposes, the mobile is paged with the 5G-S-TMSI. The 5G-S-TMSI shall be constructed from the AMF Set ID, the AMF Pointer and the 5G-TMSI:

<5G-S-TMSI> = <AMF Set ID><AMF Pointer><5G-TMSI>

See clause 2.10.1 for these definitions and clause 2.10.2 for the mapping.

2.12 Structure of the Truncated 5G-S-Temporary Mobile Subscriber Identity (Truncated 5G-S-TMSI)

The Truncated 5G-S-TMSI is a 40 bit UE identifier constructed from the 5G-S-TMSI. It is used in RRC Connection Re-Establishment for the control plane for NB-IoT as described in 3GPP TS 36.300 [91]. The Truncated 5G-S-TMSI shall be constructed from the Truncated AMF set ID, the Truncated AMF Pointer and the Truncated 5G-TMSI:

Truncated AMF set ID is n least significant bits of AMF Set ID, where n is no greater than 10 bits.

Truncated AMF Pointer is m least significant bits of AMF Pointer, where m is no greater than 6 bits.

Truncated 5G-TMSI is (40-n-m) least significant bits of 5G-TMSI.

The values n and m are configurable based on network deployment. The value n+m shall be larger or equal to 8 bits.

NOTE: Depending on network deployment it is up to operator configuration to ensure that Truncated AMF Set ID and Truncated AMF Pointer identify the AMF uniquely, and that Truncated 5G-TMSI identifies the UE uniquely within the serving AMF.

The NG-RAN and AMF are configured with the values n and m respectively, and NG-RAN is configured with how to recreate AMF Set ID from Truncated AMF Set ID, AMF Pointer from Truncated AMF Pointer, and 5G-TMSI from Truncated 5G-TMSI. The configuration of these parameters are specific to each PLMN.

The AMF configures the UE with the Truncated 5G-S-TMSI Configuration that provides the sizes of the components of the Truncated 5G-S-TMSI as described in 3GPP TS 24.501 [125] during the Registration and UE Configuration Update procedures.

For Network Sharing, the sharing NG-RAN is configured with the respective values n and m that are specific to each PLMN, and AMF is configured with the same values n and m as ones configured on NG-RAN per PLMN. The AMF configures the UE with the corresponding values n and m according to the PLMN which the UE accesses to during the Registration procedure.