GUTI

GUTI stands for Globally Unique Temporary Identifier. The GUTI is a critical temporary identifier used in 5G (and 4G/LTE) networks to protect the privacy and security of a UE. It serves as a substitute for the UE’s permanent identity (SUPI – Subscription Permanent Identifier) during interactions with the network, ensuring sensitive subscriber information is not transmitted over the air.

• Privacy Protection: Prevents exposure of the UE’s permanent identifier (SUPI) over radio interfaces.
• Efficiency: Allows the network to uniquely and temporarily identify the UE during mobility, session management, and authentication procedures.
• Security: Reduces the risk of tracking or eavesdropping on the UE by using a temporary, reallocatable identity.

• Executive Summary
• GUTI Structure (5G)
• How many bits does each field of the 5G-GUTI take?
• Key Aspects of 5G-GUTI
• How is it used in NAS Signaling?
• What is 5G-S-TMSI, and why does RRC use it instead of the full 5G-GUTI?
• How does the 5G-GUTI decide when the UE wakes up for paging?
• How is a new 5G-GUTI delivered and acknowledged?
• How does NG-RAN use the GUTI to select the AMF?
• What is a mapped 5G-GUTI, and when is it used?
• How well does the 5G-GUTI actually protect privacy?
• How does the 5G-GUTI compare with the other UE identities?
• Reference

Executive Summary

GUTI Structure (5G):

The 5G GUTI is structured as follows:

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

• GUAMI (Globally Unique AMF ID):
• Identifies the specific AMF (Access and Mobility Management Function) serving the UE.
• Composed of:
• MCC (Mobile Country Code)
• MNC (Mobile Network Code)
• AMF Region ID (Identifies the AMF region)
• AMF Set ID (Identifies an AMF set within the region)
• AMF Pointer (Identifies a specific AMF within the set).
• 5G-TMSI (5G Temporary Mobile Subscriber Identity):
• A unique identifier assigned by the AMF to the UE within the scope of the GUAMI.
• Typically 32 bits long.

Example :GUTI in Registraion Request

5GS mobile identity:

  5G-GUTI

    MCC = 001

    MNC = 01

    AMF Region ID = 128

    AMF Set ID = 4

    AMF Pointer = 1

    5G-TMSI = 0x32efe46b

How many bits does each field of the 5G-GUTI take?

I read the GUTI as five labels in a decoder trace for a long time. It is better read as a bit string. Each field has a fixed width, and those widths decide what the rest of the system can do with the identity.

TS 23.003 defines the 5G-GUTI as a concatenation of fixed-width fields. The MCC is three digits. The MNC is two or three digits. The AMF Region ID is 8 bits. The AMF Set ID is 10 bits. The AMF Pointer is 6 bits. The 5G-TMSI is 32 bits. The three AMF fields together form the AMF Identifier, and that is 24 bits.

Two groupings matter more than the individual fields. The first is the GUAMI. It is the PLMN ID followed by the 24-bit AMF Identifier. The GUAMI answers one question: which AMF holds the context for this UE. The second is the 5G-S-TMSI. It is the AMF Set ID, the AMF Pointer and the 5G-TMSI, so 48 bits in total. The 5G-S-TMSI answers a different question: which UE is being addressed inside one AMF set.

The AMF Region ID is not part of the 5G-S-TMSI, and that is deliberate. A UE only sends the 5G-S-TMSI to a cell it is camped on. The region of that cell is already known to the network. Therefore repeating the 8 region bits over the air would cost airtime and add nothing.

The figure below lays the example from the section above out as bits. The example values are MCC 001, MNC 01, AMF Region ID 128, AMF Set ID 4, AMF Pointer 1 and 5G-TMSI 0x32efe46b. The two brackets show the groupings. The GUAMI runs from the PLMN ID to the AMF Pointer. The 5G-S-TMSI runs from the AMF Set ID to the end of the string.

Figure 1. The field widths are what the rest of the system reads. RRC takes the 48-bit slice on the right, and AMF selection takes the 24-bit slice in the middle.

• Every field has a fixed width : MCC is 3 digits and MNC is 2 or 3 digits. The AMF Region ID is 8 bits, the AMF Set ID is 10 bits and the AMF Pointer is 6 bits. The 5G-TMSI is 32 bits.
• GUAMI answers which AMF : It is the PLMN ID plus the 24-bit AMF Identifier. The core network routes on it.
• 5G-S-TMSI answers which UE : It is 48 bits, built from the AMF Set ID, the AMF Pointer and the 5G-TMSI. The radio network carries this one.
• The AMF Region ID is left out of the 5G-S-TMSI : The cell the UE is camped on already identifies the region. Therefore those 8 bits do not need to travel over the air.
• The two groupings overlap : The AMF Set ID and the AMF Pointer belong to the GUAMI and to the 5G-S-TMSI at the same time. That overlap is what lets the gNB route on an identity the UE sent to RRC.

Key Aspects of 5G-GUTI

• Temporary Identity
• 5G-GUTI is used instead of the permanent SUPI (e.g., IMSI).
• Helps protect the subscriber’s privacy by minimizing the exposure of permanent identifiers over the air interface.
• Structure
• The 5G-GUTI contains two main parts:
• GUAMI (Globally Unique AMF Identifier) – indicates which AMF is serving the UE.
• 5G-TMSI – a temporary number unique within that AMF’s scope.
• This combination ensures the 5G-GUTI is unique globally.
• Assignment & Update
• The AMF allocates a 5G-GUTI during initial registration (similar to the “attach” process in LTE).
• The network can reassign a 5G-GUTI at any time—particularly after location updates or mobility events—to provide additional privacy.
• Usage in NAS Signaling
• Once assigned, the 5G-GUTI is used in Non-Access Stratum (NAS) procedures (e.g., registration updates, paging) instead of the SUPI.
• NAS messages carry this GUTI so the AMF can uniquely identify the UE.
• Security & Privacy
• Because the 5G-GUTI is temporary and can change over time, it helps thwart tracking and eavesdropping attempts.
• It is a core part of 5G’s improved identity protection and aligns with 3GPP security requirements (see 3GPP TS 23.501 and TS 33.501).

How is it used in NAS Signaling ?

In 5G networks, the 5G-GUTI (often referred to simply as GUTI) is a temporary identifier that the AMF assigns to a UE. Once assigned, the UE uses this identifier to communicate with the network in subsequent NAS signaling procedures—rather than using its permanent identifier (SUPI, e.g., IMSI)

Initial Registration (Attach)

Registration Request

• When a UE powers on or moves into a new network area (and does not have a valid GUTI), it sends a Registration Request to the gNB.
• If the UE already holds a valid GUTI from a previous session, it can include that in the Registration Request (instead of the SUPI) to expedite identification. If no valid GUTI exists, the UE might have to include its SUCI (Subscription Concealed Identifier, which the network can use to derive the SUPI).

Example : When UE does not have a valid GUIT

Message: Registration request

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x41 (Registration request)

5GS registration type:

  Follow-on request bit = 1

  Value = 1 (initial registration)

ngKSI:

  TSC = 0

  NAS key set identifier = 7

5GS mobile identity:

  SUCI

    SUPI format = 0 (IMSI)

    MCC = 001

    MNC = 01

    Routing indicator = 0

    Protection scheme id = 0 (Null scheme)

    Home network public key identifier = 0

    MSIN = 0123456789

UE security capability:

  0xe0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=0, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)

  0xe0 (5G-IA0=1, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=0, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)

Example : When UE already holds a valid GUIT

Message: Registration request

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x1 (Integrity protected)

Auth code = 0x4295c610

Sequence number = 0x2e

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x41 (Registration request)

5GS registration type:

  Follow-on request bit = 1

  Value = 1 (initial registration)

ngKSI:

  TSC = 0

  NAS key set identifier = 6

5GS mobile identity:

  5G-GUTI

    MCC = 001

    MNC = 01

    AMF Region ID = 128

    AMF Set ID = 4

    AMF Pointer = 1

    5G-TMSI = 0x32efe46b

UE security capability:

  0xf0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=1, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)

  0x70 (5G-IA0=0, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=1, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)

  0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)

  0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)

NAS message container:

  Protocol discriminator = 0x7e (5GS Mobility Management)

  Security header = 0x0 (Plain 5GS NAS message, not security protected)

  Message type = 0x41 (Registration request)

  5GS registration type:

    Follow-on request bit = 1

    Value = 1 (initial registration)

  ngKSI:

    TSC = 0

    NAS key set identifier = 6

  5GS mobile identity:

    5G-GUTI

      MCC = 001

      MNC = 01

      AMF Region ID = 128

      AMF Set ID = 4

      AMF Pointer = 1

      5G-TMSI = 0x32efe46b

  5GMM capability:

    0x03 (SGC=0, 5G-IPHC-CP CIoT=0, N3 data=0, 5G-CP CIoT=0, RestrictEC=0, LPP=0, HO attach=1, S1 mode=1)

  UE security capability:

    0xf0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=1, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)

    0x70 (5G-IA0=0, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=1, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)

    0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)

    0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)

  Requested NSSAI:

    S-NSSAI

      Length of S-NSSAI contents = 1 (SST)

      SST = 0x01

  Last visited registered TAI:

    MCC = 001

    MNC = 01

    TAC = 0x000064

  S1 UE network capability:

    0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)

    0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)

    0xc0 (UEA0=1, UEA1=1, UEA2=0, UEA3=0, UEA4=0, UEA5=0, UEA6=0, UEA7=0)

    0x40 (UCS2=0, UIA1=1, UIA2=0, UIA3=0, UIA4=0, UIA5=0, UIA6=0, UIA7=0)

    0x19 (ProSe-dd=0, ProSe=0, H.245-ASH=0, ACC-CSFB=1, LPP=1, LCS=0, 1xSRVCC=0, NF=1)

    0x80 (ePCO=1, HC-CP CIoT=0, ERw/oPDN=0, S1-U data=0, UP CIoT=0, CP CIoT=0, ProSe-relay=0, ProSe-dc=0)

    0xb0 (15 bearers=1, SGC=0, N1mode=1, DCNR=1, CP backoff=0, RestrictEC=0, V2X PC5=0, multipleDRB=0)

  UE's usage setting = 0x01 (Data centric)

  LADN indication:

    Length = 0

    Data =

  Network slicing indication = 0x00 (DCNI=0, NSSCI=0)

  5GS update type = 0x01 (EPS-PNB-CIoT=no additional information, 5GS-PNB-CIoT=no additional information, NG-RAN-RCU=0, SMS requested=1)

Registration Accept

• The AMF processes the request, establishes a security context, and then assigns (or reassigns) a 5G-GUTI.
• The new 5G-GUTI is included in the Registration Accept message and delivered to the UE via the gNB.

Example

Message: Registration accept

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0xeab2c7d4

Sequence number = 0x01

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x42 (Registration accept)

5GS registration result = 0x09 (Disaster roaming registration result=0, Emergency registered=0, NSSAA to be performed=0, SMS allowed=1, 3GPP access)

5G-GUTI:

  5G-GUTI

    MCC = 001

    MNC = 01

    AMF Region ID = 128

    AMF Set ID = 4

    AMF Pointer = 1

    5G-TMSI = 0xe216d4e9

TAI list:

  Length = 7

  Data = 00 00 f1 10 00 00 64

Allowed NSSAI:

  S-NSSAI

    Length of S-NSSAI contents = 1 (SST)

    SST = 0x01

Configured NSSAI:

  S-NSSAI

    Length of S-NSSAI contents = 1 (SST)

    SST = 0x01

5GS network feature support:

  0x03 (MPSI=0, IWK N26=0, EMF=not supported, EMC=not supported, IMS-VoPS-N3GPP=1, IMS-VoPS-3GPP=1)

  0x00 (5G-UP CIoT=0, 5G-IPHC-CP CIoT=0, N3 data=0, 5G-CP CIoT=0, RestrictEC=both CE mode A and CE mode B are not restricted, MCSI=0, EMCN3=0)

T3512 value:

  Value = 30

  Unit = 5 (1 minute)

Emergency number list:

  Length = 8

  Data = 03 1f 19 f1 03 1f 11 f2

UE Context Creation

• From that point on, the AMF uses the 5G-GUTI to track the UE’s NAS signaling context (mobility management, session management, etc.).

Subsequent NAS Procedures

Once the UE has a valid GUTI, it uses that GUTI in all subsequent NAS messages to avoid exposing its permanent identity. Examples include:

Service Request

• When the UE is in idle state and wants to send data or respond to paging, it issues a Service Request.
• The UE includes the 5G-GUTI to identify itself, so the AMF can quickly retrieve the correct UE context.

Registration Update (Periodic or Mobility-Based)

• If the UE needs to update its registration (e.g., moving to a new TA—Tracking Area—outside its current Registration Area), it sends a Registration Update Request.
• The UE includes its 5G-GUTI, allowing the AMF to identify the existing UE context.

Security Procedures

• With an established NAS security context (integrity protection and ciphering), the GUTI is included in encrypted and/or integrity-protected NAS messages, preventing third-parties from discovering the UE’s permanent identity.

GUTI Re-Allocation / Re-Assignment

To further protect the subscriber’s privacy and prevent long-term correlation:

• The AMF may reassign a new 5G-GUTI to the UE at any time (e.g., after a Registration Update, periodically, or due to certain mobility events).
• This mechanism works much like TMSI reallocation in LTE; it helps thwart efforts to track a UE over long periods based on a single temporary identifier.

Handling Unknown or Invalid GUTI

• If the UE’s stored 5G-GUTI has become invalid or unknown to the network (e.g., the AMF lost context, the UE changed serving AMFs without a proper handover procedure, etc.), the network may request the UE’s SUCI.
• The UE then provides a secured version of its SUPI (the SUCI), which the network uses to re-establish the user’s identity and assign a fresh GUTI.

What is 5G-S-TMSI, and why does RRC use it instead of the full 5G-GUTI?

The NAS layer and the RRC layer do not carry the same identity. That surprised me the first time I compared a NAS log against an RRC log for the same call. NAS carries the full 5G-GUTI. RRC carries the shorter 5G-S-TMSI, and the reason is message size.

RRCSetupRequest travels on UL-CCCH, and that message is 48 bits long in total. The message type, the establishment cause and the identity all have to fit inside those 48 bits. The 5G-S-TMSI is itself 48 bits. Therefore the whole identity cannot travel in Msg3.

TS 38.331 solves this by splitting the identity across two messages. The ue-Identity field in RRCSetupRequest is 39 bits wide. The UE puts ng-5G-S-TMSI-Part1 there, which is the leading 39 bits of the 5G-S-TMSI. The remaining 9 bits travel in RRCSetupComplete as ng-5G-S-TMSI-Part2. RRCSetupComplete may also carry the full 48-bit ng-5G-S-TMSI instead of the 9-bit part.

RRCSetupComplete carries one more field that matters here. It is registeredAMF, and it holds a PLMN identity plus the 24-bit AMF Identifier. That field restores the AMF Region ID, which the 5G-S-TMSI does not contain. The section on AMF selection below shows what the gNB does with it.

Paging uses the identity differently. PagingUE-Identity in TS 38.331 is a choice between two values. For CN-initiated paging it is the full 48-bit ng-5G-S-TMSI. For RAN-initiated paging of a UE in RRC INACTIVE it is the full I-RNTI instead. There is no split in either case, because PCCH has room for the whole value.

A UE without a valid 5G-GUTI cannot send any of this. In that case ue-Identity carries a 39-bit random value. The network then identifies the UE from the NAS message, using the SUCI.

The figure below shows which part of the identity travels in which message. The bar on the right represents the 48 bits of the 5G-S-TMSI. The shaded part of each bar is the portion that the message on the left carries.

Figure 2. The 39-bit limit in Msg3 is a message-size constraint, not an identity design. Everything the split leaves out arrives in Msg5.

• RRC never carries the full 5G-GUTI : It carries the 48-bit 5G-S-TMSI, and even that arrives in two pieces.
• Msg3 is the constraint : The UL-CCCH message is 48 bits in total, so ue-Identity is limited to 39 bits.
• Part1 and Part2 split the 48 bits : Part1 is the leading 39 bits in RRCSetupRequest. Part2 is the trailing 9 bits in RRCSetupComplete.
• registeredAMF carries the missing region : The 24-bit AMF Identifier in RRCSetupComplete gives the gNB the AMF Region ID that the 5G-S-TMSI leaves out.
• Paging needs no split : PCCH carries the full 48-bit ng-5G-S-TMSI for CN-initiated paging, and the full I-RNTI for RAN-initiated paging.
• No valid GUTI means a random value : ue-Identity then carries 39 random bits, and identification moves to the SUCI in the NAS message.

How does the 5G-GUTI decide when the UE wakes up for paging?

The GUTI does more than name the UE. It also picks the radio frame in which the UE listens for paging. This is the part of the identity with a visible effect on the air interface.

TS 38.304 defines a UE identity value for the paging arithmetic. For CN-initiated paging, UE_ID = 5G-S-TMSI mod 1024. Only the lowest 10 bits of the 48-bit identity take part. For RAN-initiated paging the same formula is applied to the full I-RNTI instead.

The paging frame then follows from UE_ID and three broadcast parameters. T is the DRX cycle of the UE, counted in radio frames. N is the number of paging frames inside T. Ns is the number of paging occasions inside one paging frame. N, Ns and PF_offset come from pcch-Config in SIB1. T is the shorter of the UE-specific DRX cycle and the default cycle broadcast by the cell.

Two consequences follow, and the second one is easy to miss. The first is that the paging occasion is a function of the identity, not of the subscription. The second is that reallocating the GUTI moves the UE to a different paging occasion. Therefore the UE and the AMF have to agree on which identity is current. If they disagree, the paging message is sent in a frame the UE does not monitor.

The figure below runs the arithmetic on the two identities that appear in the examples earlier on this page. The first is the 5G-GUTI the UE sent in the Registration Request. The second is the new 5G-GUTI the AMF assigned in the Registration Accept. Both rows use the same broadcast parameters, so only UE_ID differs between them.

Figure 3. The same UE moves from one paging frame to another purely because its temporary identity changed.

• UE_ID is the identity reduced modulo 1024 : For CN-initiated paging it is 5G-S-TMSI mod 1024, so only 10 bits of the identity matter.
• The paging frame is computed, not signalled : Both the UE and the network run the same formula on the same identity, using pcch-Config from SIB1.
• Reallocation moves the paging occasion : In the worked example UE_ID changes from 107 to 233. The paging frame therefore changes from SFN mod 128 = 107 to SFN mod 128 = 105.
• Agreement on the current identity is a reachability requirement : If the UE and the AMF use different identities, the network pages in a frame the UE does not monitor.
• RRC INACTIVE uses a different input : RAN-initiated paging computes UE_ID from the full I-RNTI, so the 5G-S-TMSI is not involved.

How is a new 5G-GUTI delivered and acknowledged?

The AMF can reassign the GUTI at any time, and the sections above say so. What they do not show is the acknowledgement that goes with every new identity. That acknowledgement is the reason reallocation is safe to do while the UE is reachable.

There are two ways to deliver a new 5G-GUTI. The first is inside the registration procedure. REGISTRATION ACCEPT carries the 5G-GUTI IE, and the UE answers with REGISTRATION COMPLETE. The second is outside any registration. CONFIGURATION UPDATE COMMAND carries the 5G-GUTI IE, and the UE answers with CONFIGURATION UPDATE COMPLETE.

Both paths are acknowledged, and that is the design point. The AMF cannot assume the new identity arrived. Therefore it starts a retransmission timer when it sends the message. T3550 covers REGISTRATION ACCEPT. T3555 covers CONFIGURATION UPDATE COMMAND. If the acknowledgement does not arrive before the timer expires, the AMF sends the message again.

Until the acknowledgement arrives, the AMF treats the old and the new 5G-GUTI as valid. The reason is the paging arithmetic described in the section above. A lost REGISTRATION ACCEPT would leave the UE computing its paging occasion from the old identity. If the AMF had already discarded that old identity, the UE would be unreachable until it registered again.

TS 33.501 does not leave the timing of reallocation entirely to the operator. The AMF shall send a new 5G-GUTI after an initial registration. It shall also send one after a mobility registration update. It shall send one after a Service Request that the UE sent in answer to paging. After a periodic registration update, the specification says the AMF should send a new one. The difference between shall and should is where operator policy enters, and the privacy section below returns to it.

One property of the CONFIGURATION UPDATE COMMAND path is worth stating separately. That message is sent inside an established NAS security context. Therefore it is integrity protected and ciphered. The new identity is not exposed on the air interface at the moment it is delivered.

• A new GUTI is always acknowledged : REGISTRATION ACCEPT is answered by REGISTRATION COMPLETE, and CONFIGURATION UPDATE COMMAND is answered by CONFIGURATION UPDATE COMPLETE.
• The AMF retransmits until it is answered : T3550 guards the registration path, and T3555 guards the configuration update path.
• Old and new are valid at the same time : The overlap lasts until the acknowledgement arrives. Without it, a lost message would leave the UE pageable only on an identity the AMF no longer holds.
• Some reallocation points are mandatory : TS 33.501 requires a new 5G-GUTI after initial registration, after mobility registration update, and after a Service Request answering paging.
• Delivery outside registration is protected : CONFIGURATION UPDATE COMMAND runs inside a NAS security context, so the new identity is ciphered when it is sent.

How does NG-RAN use the GUTI to select the AMF?

A gNB that receives the first NAS message has no UE context. It also cannot read the NAS payload, because that payload may be ciphered. The GUTI is what it routes on instead.

Two RRC fields give the gNB what it needs. The first is registeredAMF in RRCSetupComplete, which carries a PLMN identity and the 24-bit AMF Identifier. From that field the gNB reads the AMF Region ID, the AMF Set ID and the AMF Pointer. The second is the ng-5G-S-TMSI value, which identifies the UE inside the set.

The selection rule is a short ladder. The gNB first tries the AMF that the GUAMI names. That works when the gNB has an NG interface to that AMF and the AMF is available. If it is not available, the gNB selects another AMF in the same AMF Set. If the UE has no valid GUTI at all, the gNB selects on the Requested NSSAI and on local configuration instead.

The Set and Pointer split exists for exactly this fallback. An AMF Set is a group of AMFs that serve the same region and the same network slices. The members share access to the UE context store. Therefore any member can take a UE over when the AMF named by the pointer is unavailable. The AMF Pointer names one member, and the AMF Set ID names the group.

The gNB then sends an NGAP INITIAL UE MESSAGE to the chosen AMF. That message may include the Five-G-S-TMSI IE and the AMF Set ID IE. The receiving AMF uses them to find the UE context, or to fetch it from the AMF that holds it. If no context can be found anywhere, the AMF sends an IDENTITY REQUEST, and the UE answers with its SUCI.

The figure below follows one connection setup from the UE to the selected AMF. The AMF Set on the right holds three AMFs. The AMF Pointer names the second one, and the shaded box marks it. The numbered list gives the order in which the gNB works through the decision.

Figure 4. The gNB routes on the GUAMI fields alone. The AMF Region ID reaches it through registeredAMF, because the 5G-S-TMSI does not carry that field.

• The gNB routes on the GUAMI, not on the NAS payload : It has no UE context, and the NAS message may be ciphered. Therefore the RRC fields are all it has.
• registeredAMF is the field that carries the routing information : It holds a PLMN identity and the 24-bit AMF Identifier, which is Region ID, Set ID and Pointer.
• The AMF Set is the failure domain : Members serve the same region and slices and share the UE context store, so any member can take the UE over.
• No valid GUTI changes the selection input : The gNB then selects on Requested NSSAI and local configuration rather than on an AMF identifier.
• NGAP repeats the identity : INITIAL UE MESSAGE may carry the Five-G-S-TMSI IE and the AMF Set ID IE, so the AMF can locate or fetch the context.

What is a mapped 5G-GUTI, and when is it used?

A UE that moves between 5GS and EPS carries an identity from each system. Losing the UE context on every move would be expensive in signalling and in time. That is why the two identities are made convertible.

TS 23.003 defines a bit-level mapping between the 5G-GUTI and the EPS GUTI. The field widths line up exactly, which is what makes the mapping possible at all. The MME Group ID is 16 bits, and it maps to the AMF Set ID plus the AMF Pointer. The MME Code is 8 bits, and it maps to the AMF Region ID. The M-TMSI is 32 bits, and it maps to the 5G-TMSI. MCC and MNC map to themselves.

Two terms follow from that mapping. A native GUTI is one that the serving core network node assigned itself. A mapped GUTI is one that the UE derived from the other system's identity. A UE that has both keeps both.

The mapping is what makes idle-mode interworking work. A UE moving from 5GS to EPS sends a Tracking Area Update Request. In that request it uses a mapped EPS GUTI as the old GUTI. The MME reads the MME Group ID and the MME Code from it. Those fields point back at the AMF, and the MME fetches the UE context over N26. Where the UE also holds a native EPS GUTI from an earlier stay in EPS, it includes that one in the Additional GUTI IE.

The same relation runs the other way. A UE moving from EPS to 5GS derives a mapped 5G-GUTI from its EPS GUTI, and sends it in the Registration Request. The AMF reads the AMF Set ID and the AMF Pointer, which are the old MME Group ID, and fetches the context from the MME.

• The mapping is a re-labelling of the same bits : MME Group ID becomes AMF Set ID plus AMF Pointer, MME Code becomes AMF Region ID, and M-TMSI becomes 5G-TMSI.
• Native and mapped are the two kinds of GUTI : Native means assigned by the serving system. Mapped means derived from the other system's identity.
• The mapped identity is what routes the context fetch : The receiving node reads the mapped fields to find the node that holds the context, and fetches it over N26.
• A UE can carry both : Where a native identity for the target system also exists, the UE offers it in the Additional GUTI IE.
• A GUTI seen in one system may belong to the other : An EPS GUTI in a TAU Request is not proof that the UE was last served by an MME.

How well does the 5G-GUTI actually protect privacy?

This is the section where I would be careful with claims. The GUTI removes the permanent identity from the air interface. It does not make the UE anonymous, and the difference between those two statements is the whole subject.

Start with what the design does fix. The SUPI is never sent in clear over the radio interface. When the network needs the permanent identity, it sends an IDENTITY REQUEST, and the UE answers with a SUCI. The SUCI is the SUPI encrypted with the home network public key. Only the home network can decrypt it. In 4G the same request returned the IMSI in clear, and that is what a passive IMSI catcher collected.

Now the part that is left open. A 5G-GUTI is stable until the AMF replaces it. Anyone who can observe it can link every session inside that interval to one device. The protection therefore lasts exactly as long as the interval between reallocations, and no longer.

There is a second channel, and it is quieter than the first. The paging occasion is derived from the lowest 10 bits of the 5G-S-TMSI. Those 10 bits stay constant until the identity changes. An observer who can trigger paging, for example by placing a call that is cancelled, can therefore test whether a subscriber is present in a tracking area. Decoding the GUTI itself is not required for that test.

Published measurement work on deployed 4G networks reported that many operators reallocated the temporary identity rarely. I have not repeated those measurements on 5G networks, so treat that as background rather than as a current figure. What the 5G specification changed is the list of points where reallocation is mandatory. What it did not change is that periodic reallocation remains a should, and therefore a policy choice.

My own reading is that the identity format is the settled part of this problem, and the reallocation policy is not. A GUTI that is replaced on every registration and after every paging response is doing the job it was designed for. A GUTI that survives for days is a permanent identifier with a temporary name.

• The SUPI is protected, and that part works : An IDENTITY REQUEST returns a SUCI, which only the home network can decrypt. The 4G attack of asking for the IMSI in clear does not carry over.
• The GUTI is linkable while it lasts : Every session under one 5G-GUTI belongs to the same device, and an observer needs no keys to see that.
• The paging occasion exposes 10 bits : Those bits are stable between reallocations, so presence in a tracking area can be tested without decoding the identity.
• Reallocation frequency is the real control : TS 33.501 makes some reallocation points mandatory, but leaves periodic reallocation as a recommendation.
• Judge a deployment by its reallocation policy : The identity format is the same everywhere. How often it changes is what differs between networks.

How does the 5G-GUTI compare with the other UE identities?

A single decoder trace shows several identities for one UE, and they are easy to confuse. I keep a table like this one open while reading traces, because the layer a name belongs to tells me which message should carry it.

One distinction runs through the whole table. The first three identities belong to the core network. The next three belong to the radio network. The last two belong to the NG interface between them, and they never reach the air interface at all.

The 5G-S-TMSI is the one entry that belongs to both sides. It is derived from a core network identity, and the radio network is allowed to carry it. That is why it appears in RRC messages and in the paging arithmetic, while the full 5G-GUTI does not.

• Only the SUPI is permanent : Everything else in the table is temporary, and each one has a different replacement trigger.
• The layer tells you where to look : A NAS identity will not appear in an RRC message, and an NGAP identity will not appear on the air interface.
• 5G-S-TMSI belongs to both sides : It comes from the 5G-GUTI, and RRC carries it. That dual role is what connects the core identity to the paging occasion.
• C-RNTI and I-RNTI are not privacy identities : They are scheduling and context identifiers, and they change on cell change and on state change respectively.

Reference :

• 3GPP TS 23.003 : Numbering, addressing and identification. Defines the 5G-GUTI, the GUAMI, the 5G-S-TMSI and the mapping to and from the EPS GUTI.
• 3GPP TS 23.501 : System architecture for the 5G System. Defines the AMF Set, the GUAMI and AMF selection.
• 3GPP TS 24.501 : Non-Access-Stratum protocol for 5GS. Defines the 5G-GUTI information element, the registration procedure and the generic UE configuration update procedure.
• 3GPP TS 33.501 : Security architecture and procedures for the 5G System. Defines when the AMF has to allocate a new 5G-GUTI.
• 3GPP TS 38.304 : UE procedures in Idle mode and RRC Inactive state. Defines UE_ID and the paging frame and paging occasion formulas.
• 3GPP TS 38.331 : Radio Resource Control protocol specification. Defines ng-5G-S-TMSI-Part1, ng-5G-S-TMSI-Part2, registeredAMF and PagingUE-Identity.
• 3GPP TS 38.413 : NG Application Protocol. Defines INITIAL UE MESSAGE, the Five-G-S-TMSI IE and the AMF Set ID IE.