gUAMI stands for  Globally Unique Access and Mobility Management Function Identifier (gUAMI or GUAMI). It is a type of ID used in 5G Core that ensures the unique global addressing of an AMF(Access and Mobility Management Function ).

What it does ?

The main functionality of GUAMI can be listed as below

• Uniquely identifies an AMF instance globally to avoid conflicts in distributed deployments. Since multiple AMF instances can be deployed in a large or complex 5G network, each AMF instance needs a globally unique identity.
• Facilitates routing of signaling messages (e.g., during registration, handovers) to the correct AMF. It isTracking and managing UE mobility within the 5G Core.
• Supports scalability, redundancy, and load balancing across the 5G Core network.

Structure of GUAMI

GUAMI is composed of three main components:

• PLMN (Public Land Mobile Network) Identifier:
• MCC (Mobile Country Code): Identifies the country.
• MNC (Mobile Network Code): Identifies the mobile operator.
• Ensures uniqueness across operators and countries.
• AMF Region ID:
• Represents a large geographic or logical area (e.g., a group of states or cities).
• Enables hierarchical scaling of AMF deployments.
• AMF Set ID and AMF Pointer:
• AMF Set ID: Groups AMFs for redundancy and load balancing.
• AMF Pointer: Identifies a specific AMF within a Set.
• Example structure: PLMN (MCC+MNC) + AMF Region ID (8 bits) + AMF Set ID (10 bits) + AMF Pointer (6 bits).

GUAMI in NGAP signaling

The gUAMI/GUAMI plays a critical role in NGAP (Next-Generation Application Protocol) signaling, which governs communication between the gNB  and the AMF. Below is a detailed breakdown of how GUAMI is used in key NGAP procedures:

NG Setup

When gNB establishs NG Setup

• The gNB sends an NG Setup Request to initiate communication with an AMF (or set of AMFs).
• The AMF responds with an NG Setup Response, which includes the Global AMF ID (i.e., gUAMI). The gNB stores this identifier so it knows exactly which AMF(s) it is connected to.

Example : (from Amarisoft MME Log)

Message: 127.0.1.1:32823 NG setup response

 

Data:

successfulOutcome: {

  procedureCode id-NGSetup,

  criticality reject,

  value {

    protocolIEs {

      {

        id id-AMFName,

        criticality reject,

        value "amarisoft.amf.5gc.mnc001.mcc001.3gppnetwork.org"

      },

      {

        id id-ServedGUAMIList,

        criticality reject,

        value {

          {

            gUAMI {

              pLMNIdentity '00F110'H,

              aMFRegionID '80'H,

              aMFSetID '0000000100'B,

              aMFPointer '000001'B

            }

          }

        }

      },

      {

        id id-RelativeAMFCapacity,

        criticality ignore,

        value 50

      },

      {

        id id-PLMNSupportList,

        criticality reject,

        value {

          {

            pLMNIdentity '00F110'H,

            sliceSupportList {

              {

                s-NSSAI {

                  sST '01'H

                }

              }

            }

          }

        }

      }

    }

  }

}

Initial UE Registration

When a UE initiates registration, the gNB sends the Initial UE Message (NGAP) to the AMF.

GUAMI’s Role in this context is

• The UE includes its 5G-GUTI (Globally Unique Temporary UE Identity) in the RRC message. The 5G-GUTI contains the GUAMI of the AMF that previously served the UE.
• The gNB extracts the GUAMI from the 5G-GUTI and uses it to:
• Route the NGAP message to the correct AMF instance.
• Ensure continuity (if the UE is reconnecting to the same AMF).
• When a UE initially connects or re-registers, the gNB sends an Initial UE Message to the AMF. Internally, the network may use the gUAMI to ensure the message goes to the right AMF instance.
• Subsequent signaling (like Registration Accept/Reject, Service Requests, etc.) flows between the gNB and AMF identified by that same gUAMI.

Example :

• Initial UE Message (NGAP) → [RRC Container (5G-GUTI) → GUAMI]  

Example :

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)

Handover Procedures

During UE context release or mobility-related signaling (e.g., Xn handover to another gNB or AMF relocation), the network uses the gUAMI to reference the old or new AMF.

• N2 Handover:
• During handover, the source AMF may forward the UE context to a target AMF.
• The Target AMF’s GUAMI is included in the Handover Required (NGAP) message to ensure the target gNB routes signaling to the correct AMF.
• AMF Relocation:
• If AMF relocation is needed (e.g., load balancing), the source AMF provides the GUAMI of the target AMF to the gNB in the Handover Command (NGAP)

AMF Configuration Update

AMFs periodically update their configuration (e.g., capacity, load).

GUAMI’s Role in this context is :

• If the AMF’s identifiers change—say the operator adds a new AMF pointer or modifies region/set IDs—the AMF sends an AMF Configuration Update to the gNB, again including the updated gUAMI. This keeps the gNB’s configuration and routing knowledge accurate.
• The AMF sends an AMF Configuration Update (NGAP) message to the gNB, including its GUAMI.
• The gNB updates its records to ensure future NGAP messages are routed to the updated AMF instance.

Downlink NAS Transport

The AMF sends downlink NAS messages (e.g., authentication requests) to the UE via the gNB.

GUAMI’s Role in this context is :

• The AMF includes its GUAMI in the Downlink NAS Transport (NGAP) message.
• The gNB uses the GUAMI to validate that the message is from the AMF currently serving the UE.

UE Context Management

During UE context release (e.g., idle mode transition), the AMF initiates UE Context Release (NGAP).

GUAMI’s Role in this context is:

• The GUAMI ensures the gNB releases resources associated with the correct AMF instance.

When UE registers to a Core for the first time

When UE registers to a core network, it conveys a specific AMF information as a part of GUTI if has registered a core before. Then what would happen if UE has never registered the network before ? There are a couple of different scenario we can think of

Scenario 1: UE uses SUCI instead of GUTI

• UE Sends Registration Request
• If the UE has a valid (old) GUTI from another AMF, it may include it in the Registration Request. Otherwise, it may use its SUCI (Subscription Concealed Identifier).
• At this point, the UE does not know the new AMF’s GUAMI.
• AMF Resolves Identity
• The new AMF either retrieves the UE context from the old AMF (if the old GUTI is recognized) or from the UDM using SUCI (if no valid old GUTI is present).
• New AMF Assigns a GUTI
• In the Registration Accept message, the new AMF includes the new GUTI.
• The GUTI contains the new AMF’s GUAMI (i.e., MCC, MNC, AMF Region ID, AMF Set ID, AMF Pointer) and a unique 5G-TMSI.
• UE Stores the New GUTI
• Once the UE receives the Registration Accept, it updates its stored GUTI.
• From then on, the UE will present this new GUTI whenever it initiates a connection with the same AMF (or possibly with other gNBs in the same PLMN).

Example :

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)

Scenario 2: UE Has a Valid GUTI (e.g., from a Previous AMF)

• UE Behavior:
• The UE includes its existing 5G-GUTI in the Registration Request message (sent via the RRC/NAS layer to the gNB and forwarded to the AMF via NGAP).
• The 5G-GUTI contains the GUAMI of the old AMF that previously served the UE.
• Network Behavior:
• The new AMF receives the Registration Request and extracts the GUAMI from the UE’s 5G-GUTI.
• The new AMF uses this GUAMI to contact the old AMF (via the N14 interface) to retrieve the UE’s context (e.g., subscription, security keys).
• After successful authentication and context transfer, the new AMF assigns a fresh 5G-GUTI containing its own GUAMI (to replace the old one).
• Key Point:
• The UE does not populate the new AMF’s GUAMI in the GUTI upfront. Instead, it uses the old GUAMI to help the network route the request and retrieve its context. The new AMF then provides its GUAMI in the new GUTI after successful registration.

Scenario 3: UE Has No Valid GUTI (Initial Registration)

• UE Behavior:
• If the UE has no valid GUTI (e.g., first-time registration, GUTI expired), it uses the SUCI (Subscription Concealed Identifier) instead of the GUTI in the Registration Request.
• The SUCI protects the UE’s permanent identifier (SUPI) using encryption.
• Network Behavior:
• The new AMF authenticates the UE using the SUCI and interacts with the UDM/AUSF to validate the UE’s subscription.
• After successful authentication, the new AMF assigns a new 5G-GUTI containing its own GUAMI and sends it to the UE in the Registration Accept message.

How the New AMF’s GUAMI Populates the GUTI

The UE does not pre-populate the new AMF’s GUAMI. Instead:

• Existing GUTI: If available, the UE provides the old GUAMI (from a prior AMF) to help the network retrieve its context.
• New GUTI Assignment: After successful registration, the new AMF generates a fresh GUTI with its own GUAMI and sends it to the UE. The UE stores this new GUTI for future sessions.

Key Steps in GUAMI/GUTI Handling

• Registration Request:
• UE sends either:
• Old 5G-GUTI (with old GUAMI) or SUCI (if no valid GUTI exists).
• AMF Resolution:
• New AMF uses the old GUAMI (if provided) to fetch UE context from the old AMF.
• New GUTI Assignment:
• New AMF generates a new GUTI with its GUAMI and sends it to the UE in Registration Accept.
• UE Storage:
• UE replaces the old GUTI with the new one, now containing the new AMF’s GUAMI.

Example Flow

• UE → gNB → New AMF:
• Registration Request (Old 5G-GUTI: GUAMI_Old + 5G-TMSI)
• New AMF → Old AMF:
• Retrieve UE Context (using GUAMI_Old)
• New AMF → UE:
• Registration Accept (New 5G-GUTI: GUAMI_New + 5G-TMSI)

Reference :

[1]