AMF plays the most crtical(central) roles in 5G core network. Simply put, AMF is a central control box or central hub of the whole 5G core network.

The Major role of AMF is to handle NAS message from UE. This NAS message would mostly comes from RAN (gNB) but theoretically it can come from other Non 3GPP components. As shown below, the communication between AMF and RAN is going through N1 interface. I wrote a separate notes for N1 interface / N1 mode itself. In this note, I would focus mostly on handling each NAS message with examples.  There are some functionalities done by AMF only and some other functions that AMF need to communicate with other network components. In this note, I would mostly focus on those functions that are done by AMF only.

Followings are the name of each network component.

AMF     Access and Mobility Management Function ==> Equivalent to MME in 4G

AUSF    Authentication Server Function

DN       Data Network

NEF      Network Exposure Function

NRF      Network Repository Function

NSSF    Network Slice Selection Function

PCF      Policy Control Function ==> Equivalent to PCRF in 5G

(R)AN   (Radio) Access Network

SMF     Session Management Function

UDM     Unified Data Management ==> Equivalent to HSS in 4G

UPF      User Plane Function ==> Equivalent to PGW in 4G

SMSF   SMS Function

SEAF    SEcurity Anchor Function==> part of AMF function

ARPF    Authentication credential Repository and Processing Function

SIDF    Subscription Identifier De-concealing Function

Followings are the topics to be covered in this note.

• AMF Functionality/Services
• Interfaces around AMF
• Before AMF start NAS handling
• Signaling (Message flow between gNB and AMF) - N2 Interface
• How to select an AMF ?

AMF Functionality/Services

The AMF handles critical control plane functions like registration management, connection management, reachability management, mobility management and access authentication. It interacts with other core network functions and external entities via service-based interfaces like Namf.

Since AMF has so many different functionailties and interactions, we can take a look at it with various different perspective. In this section, I will try to describe AMF functionalities in a few different ways/perspective, so that you can get the understanding on AMF with different angles.

First let's look into AMF with the perspective of registration management, connection management, reachability management, mobility management and access authentication.

• Registration Management:
• Allows UE to register and deregister with 5G network
• Handles initial registration to authorize UE and create UE context
• Manages periodic registration updates to verify UE status
• Connection Management:
• Establishes and releases control plane N1 signaling connections with UE
• Manages transitions between CM-Idle and CM-Connected states
• Reachability Management:
• Ensures UE is reachable for mobile-terminated connections
• Uses paging to trigger idle UEs to establish connections
• Mobility Management:
• Maintains knowledge of UE location within network
• Manages mobility tracking area updates
• Handles Xn handovers between gNB base stations
• Access Authentication:
• Authenticates UEs during initial registration and periodic updates
• Verifies UE identity and validity of SIM credentials
• Authorizes UE access to 5G services and network

As a view with different angle, the functionality of AMF function can be summarized well by the AMF source code itself if you have access to.  As an example, following is the list of major fucntionalities written in the source code from free5gc (I wrote a note on how to get and install free5gc if you are interested).  It is completely OK that you don't have the code, just taking a lot at the list of major functions would give you pretty good idea on AMF functionality. This is from file : free5gc\NFs\amf\gmm\handler.go. For the details of what AMF does, I would suggest you to refer to the note NGAP and I will just put high level description in this page.

• HandleInitialRegistration
• HandleRegistrationRequest
• HandleIdentityResponse
• HandleMobilityAndPeriodicRegistrationUpdating
• HandleNotificationResponse
• HandleConfigurationUpdateComplete
• HandleAuthenticationResponse
• HandleAuthenticationError
• HandleAuthenticationFailure
• HandleSecurityModeComplete
• HandleRegistrationComplete
• HandleULNASTransport
• HandleServiceRequest
• handleRequestedNssai
• HandleSecurityModeReject
• HandleDeregistrationRequest
• HandleDeregistrationAccept
• HandleStatus5GMM
• forward5GSMMessageToSMF
• communicateWithUDM
• AuthenticationProcedure

Now let's describe on AMF functionality in terms of service function(service API).  Formal specification of AMF is described in 29.518 and the list of services that AMF provides are summarized in a table shown below.

< 29.518 - Table 5.1-1 List of AMF Services >

Highlights of this table can be summarized as below.

• Namf_Communication:
• Manages UE context transfer with peer AMFs during mobility
• Handles UE registration status updates with peer AMFs
• Creates UE contexts on demand
• N1N2MessageTransfer:
• Handles N1/N2 message transfer, failure notification and information subscription/notification
• AMFStatusChangeNotify:
• Enables subscriptions and notifications on AMF status changes
• EBIAssignment:
• Assigns PDU session IDs and tunnel endpoints
• Namf_MT:
• Enables UE reachability for delivering mobile terminated SMS
• Provides domain selection info to support SMS delivery
• Namf_Location:
• Provides positioning info to support location services
• Subscribes to location event notifications
• Namf_EventExposure:
• Allows other CNFs to subscribe and receive notifications on UE context events
• Namf_MBSBroadcast:
• Supports dedicated broadcast SMF contexts for MBMS
• Namf_MBSSCommunication:
• Provides N2 interface messaging with MBMS-SMF

Interfaces around AMF

AMF is the center of the whole 5G core network with the most diverse interface with other core network components. Followings are the network interfaces connected to AMF and corresponding 3GPP specification.

Before AMF start NAS handling

Even though this is not the main contents of this note, I think I need to put some short comments on this at least. Before AMF start handling NAS message, the interface and protocol between AMF and gNB should be established. Usually this process is printed just in a few lines in the trace log, but this establishement process itself is pretty complicated. I have three separate notes only for this process as listed below.  What AMF is doing is described mostly by NGAP page.

• Core - NGAP
• Core - SCTP
• Core - GTP

Signaling (Message flow between gNB and AMF) - N2 Interface

Following is the signaling procedure of NR SA attach. Roughly speaking that NGAP traces are the ones handled by AMF. Just take a look at the overal procedure and for the details refer to the note NGAP. At first, I was thinking of AMF details in this page but I thought it may be confusing or duplicating NGAP note. So I decided to put all the details in NGAP note and put overall / high level description in this note.

NOTE : The signaling message reaching to AMF through N2 interfaces will be conveyed to various other core network components via correponding interfaces. The signaling through other interfaces will be explained in other notes. Check out Interfaces around AMF to reach out to the corresponding interfaces.

This log is captured from Amari Callbox + Commercial UE. The wireshark log in NGAP note is captured from NIC on Core Network PC.

Check out this tutorial on Amarisoft TechAcademy to get the entire log.

How to select an AMF ?

In 5G network, one gNB can be connected to multiple AMF as illustrated below for an example, how the gNB select which AMF to communicate with for each transaction ?

In the example shown below, three gNBs are connected to two AMF and the two AMF are also connected to each and every gNBs. The green connecting lines indicates N2 interface and these interfaces are based on SCTP link. Let's assume that all the SCTPs are alive and hear beat keep going on.

In a 5G network, a gNB (gNodeB) can be connected to multiple Access and Mobility Management Functions (AMF). The selection of which AMF to communicate with for each traffic flow is based on several factors.

• AMF Selection by the gNB:
• The gNB itself may select the appropriate AMF based on certain parameters when a UE (User Equipment) initiates a connection. The process follows this general flow:
• AMF Identifier: The gNB receives a list of AMF addresses from the Network Repository Function (NRF). This list includes AMFs that can serve the UE based on the UE’s location (Tracking Area) and network slice requirements.
• UE-Specific Information: The gNB may consider UE-specific information, such as the Network Slice Selection Assistance Information (NSSAI), priority level, and capability of the AMF to handle specific types of services (e.g., IoT, URLLC, eMBB).
• Load Balancing: If multiple AMFs are capable of serving the UE, the gNB may implement load balancing techniques, choosing an AMF based on current network load or predefined policies. ==> gNB may not able to do sophisticated load balancing for AMF since it does not have detailed information about how much load is being applied for each of AMF it is connected, but there is a signaling mechanism by which AMF can notify via NGAP message when it is overloaded (refer to this)
• AMF Selection by the UE:
• In some scenarios, the UE may have a role in determining the AMF, especially during initial registration or handover, by providing specific information to the gNB, such as its supported NSSAI and PLMN (Public Land Mobile Network) preferences.
• AMF Selection Assisted by the NRF:
• The gNB queries the Network Repository Function (NRF) to discover available AMFs, considering:
• Network Slicing: The NRF helps find AMFs that match the required network slices (based on NSSAI). For example, a UE requiring a slice for URLLC will be directed to an AMF that supports that service.
• AMF Pooling: If there are multiple AMFs available in a pool, the gNB and NRF may use load distribution policies to ensure efficient use of network resources.
• Dynamic AMF Selection for Mobility:
• For ongoing sessions, if the UE moves between different tracking areas, the gNB may decide to communicate with a new AMF, triggering a mobility registration update. The gNB can perform AMF reselection based on the new location or network conditions of the UE.
• Redundancy and Failover:
• In case of an AMF failure or overload, the gNB can switch to another AMF to maintain service continuity. This ensures high availability and robustness in the 5G core network.

In this situation how each of gNB can figure out(select) which AMF for a specific transaction ?

NOTE : Following samples logs are from the two tutorial([1] and [2]) at Amarisoft tech-academy

NOTE : In the test setup for collecting this log is not based on the inter connection of multi gNB/multi AMF, it is just the case of single gNB connected to single AMF.  So it would not show on how a gNB select a specific AMF, but I think this is enough for illustrating the detailed signaling between UE,gNB and AMF.

NOTE : In this note, I would not talk anything about (1) which is basically SCTP connection process and (2)/(3) is NGAP establishment process.

When a UE (User Equipment) specifies an AMF (Access and Mobility Management Function) in the RRC Connection Complete message, it typically indicates that the UE has a prior association with this AMF. This scenario usually occurs when the UE is re-registering or reconnecting to the network after a disconnection or mobility event.

The gNB usually attempts to connect to the AMF specified by the UE if it is a valid option based on availability, policies, and location. However, if the AMF is not suitable or unavailable, the gNB will select a different AMF based on its internal selection logic, load balancing, and NRF recommendations. This approach ensures optimal network performance and continuity of service for the UE.

Here’s what the gNB (gNodeB) typically does in this situation:

• Reception of AMF Information in RRC Connection Complete
• The AMF information is included by the UE in the RRC Connection Complete message as part of the NAS PDU. This AMF information is encapsulated in the GUAMI (Globally Unique AMF Identifier) field, which includes:
• PLMN ID (Public Land Mobile Network ID): Identifies the home network.
• AMF Region ID: Identifies a specific region.
• AMF Set ID: Identifies a set of AMFs within a region.
• AMF Pointer: Identifies a specific AMF within the set.
• Verification of the Provided AMF Information
• The gNB checks the provided AMF information to determine if:
• The specified AMF is reachable.
• The specified AMF is appropriate for the UE's current location (based on Tracking Area or TAI).
• The specified AMF matches the network slice requirements indicated by the UE in the NSSAI (Network Slice Selection Assistance Information).
• AMF Selection Decision Process by the gNB
• The gNB follows a decision-making process to either accept or override the AMF suggested by the UE:
• If the specified AMF is valid and available:
• The gNB will forward the NAS signaling to the specified AMF and establish a connection with it.
• If the specified AMF is not valid, unavailable, or does not match policies:
• The gNB will query the Network Repository Function (NRF) to discover an appropriate AMF.
• The gNB may select a different AMF that better suits the UE’s location, slice requirements, or load conditions.
• Interaction with the AMF
• Once the gNB has decided on an AMF (either the one specified by the UE or a different one), it initiates the N2 interface signaling procedures with that AMF:
• N2 Initial UE Message: The gNB sends the Initial UE Message over the N2 interface to the selected AMF. This message includes the NAS PDU (which contains the UE’s registration request) and other context information.
• AMF Context Handling:
• If the specified AMF is selected, and it recognizes the UE’s context (i.e., the UE was registered with this AMF previously), the AMF can quickly reestablish the UE’s session.
• If a new AMF is selected, it may need to retrieve the UE’s context from the previous AMF or start a fresh registration process.
• Handling Context Information and Registration Updates
• If the gNB has selected a different AMF than the one specified by the UE:
• The new AMF may need to perform context retrieval from the previously specified AMF to ensure a seamless UE experience, depending on whether this is a re-registration or fresh registration.
• If the context is successfully transferred, the new AMF updates its UE context accordingly.
• Outcomes and Next Steps
• After completing the AMF selection and registration process:
• The gNB continues to forward RRC and NAS messages between the UE and the selected AMF.
• The UE treats the selected AMF as its serving AMF, regardless of whether it was the same AMF initially specified in the RRC Connection Complete message.

[4] RRC Setup Complete

{

  message c1: rrcSetupComplete: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcSetupComplete: {

      selectedPLMN-Identity 1,

      registeredAMF {

        amf-Identifier '800101'H

      },

      guami-Type native,

      dedicatedNAS-Message '7E014295C6102E7E004169000BF200F...'H

    }

  }

}

[5] Registration Request (piggybacked in RRC setup complete)

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)

[6] Initial UE message

initiatingMessage: {

  procedureCode id-InitialUEMessage,

  criticality ignore,

  value {

    protocolIEs {

      {

        id id-RAN-UE-NGAP-ID,

        criticality reject,

        value 1

      },

      {

        id id-NAS-PDU,

        criticality reject,

        value '7E014295C6102E7E004169000BF200F1....'H

      },

      {

        id id-UserLocationInformation,

        criticality reject,

        value userLocationInformationNR: {

          nR-CGI {

            pLMNIdentity '00F110'H,

            nRCellIdentity '001234501'H

          },

          tAI {

            pLMNIdentity '00F110'H,

            tAC '000064'H

          }

        }

      },

      {

        id id-RRCEstablishmentCause,

        criticality ignore,

        value mo-Signalling

      },

      {

        id id-UEContextRequest,

        criticality ignore,

        value requested

      }

    }

  }

}

[7] DownlinkNASTransport,

initiatingMessage: {

  procedureCode id-DownlinkNASTransport,

  criticality ignore,

  value {

    protocolIEs {

      {

        id id-AMF-UE-NGAP-ID,

        criticality reject,

        value 100

      },

      {

        id id-RAN-UE-NGAP-ID,

        criticality reject,

        value 1

      },

      {

        id id-NAS-PDU,

        criticality reject,

        value '7E005B01'H

      }

    }

  }

}

When the UE does not specify an AMF in the RRC Connection Complete message, the gNB takes responsibility for selecting an appropriate AMF using NRF queries, considering location, network slice requirements, AMF capabilities, and network policies. This ensures that the UE is served by the most suitable AMF based on the network’s current conditions and configurations.

When a UE (User Equipment) does not specify an AMF (Access and Mobility Management Function) in the RRC Connection Complete message, it indicates that the UE does not have a preference or prior association with a specific AMF.

This typically happens when the UE is:

• Connecting to the 5G network for the first time.
• Re-registering after a long absence where previous AMF contexts have expired.
• Changing from a different RAT (Radio Access Technology), such as transitioning from LTE to 5G.
• Reinitializing due to network-initiated procedures, such as handover or inter-AMF relocation.

In this scenario, the gNB (gNodeB) performs the following steps to select an appropriate AMF for the UE:

• Determining AMF Availability Using NRF Query
• The gNB queries the Network Repository Function (NRF) to retrieve a list of AMFs that are available to serve the UE. The NRF returns a list of AMFs based on the following parameters:
• UE Location: The AMFs must serve the Tracking Area (TA) where the UE is located.
• Network Slice Requirements: The NRF considers the Network Slice Selection Assistance Information (NSSAI) provided by the UE, which indicates the types of network slices required for the UE’s services (e.g., eMBB, URLLC, or IoT).
• AMF Capabilities: The NRF ensures that only AMFs capable of handling the specified services and functionalities are included in the response.
• Selecting an AMF from the Available List
• The gNB selects an appropriate AMF from the list provided by the NRF based on various criteria:
• AMF Load and Capacity: The gNB may consider the load status of each AMF to distribute the traffic evenly and avoid overloading a particular AMF.
• AMF Availability: The gNB will ensure that the AMF is available and operational to serve the UE’s requests.
• AMF Preferences and Network Policies: Network operators can define policies for AMF selection, such as prioritizing certain AMFs for specific services or geographic regions.
• The selection can also be influenced by predefined policies in the network, such as:
• Preferred AMF List: The gNB may have a pre-configured list of preferred AMFs.
• Fallback Mechanisms: If no suitable AMF is available, fallback mechanisms can be used to select a default AMF.
• Initiating Registration Request to the Selected AMF
• Once the gNB has selected an AMF, it sends the N2 Initial UE Message to the chosen AMF. This message contains:
• The NAS PDU received from the UE in the RRC Connection Complete message, which includes the initial registration request.
• The UE Context Information, such as the UE’s capability, location, and NSSAI.
• The AMF processes this registration request and establishes a context for the UE, initiating the NAS procedures like authentication and registration.
• Handling of NAS Registration and Authentication
• After sending the registration request to the selected AMF:
• The AMF will respond with the necessary NAS procedures to register the UE, authenticate it, and establish a signaling connection.
• The gNB acts as a relay between the UE and the AMF, forwarding NAS signaling messages back and forth.
• Completing the Registration and Context Establishment
• Once the AMF has authenticated and registered the UE:
• The gNB and AMF establish a stable signaling connection over the N2 interface.
• The gNB now knows which AMF is serving this UE and will continue to communicate with it for subsequent NAS signaling and mobility management procedures.
• Additional Considerations
• If the UE does not specify an AMF and the gNB cannot find a suitable AMF:
• The gNB may reject the registration attempt, and the UE might need to retry with different parameters.
• The gNB may send a redirection message to the UE, instructing it to connect to a different cell or tracking area if no AMF is available for the current location.

[4] RRC Setup Complete

{

  message c1: rrcSetupComplete: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcSetupComplete: {

      selectedPLMN-Identity 1,

      dedicatedNAS-Message '7E004179000D0100F110F0FF000010325476982E02E0E0'H,

      nonCriticalExtension {

        nonCriticalExtension {

          ul-RRC-Segmentation-r16 true

        }

      }

    }

  }

}

[5] Registration Request (piggybacked in RRC setup complete)

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 sheme 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)

[6] Initial UE message

initiatingMessage: {

  procedureCode id-InitialUEMessage,

  criticality ignore,

  value {

    protocolIEs {

      {

        id id-RAN-UE-NGAP-ID,

        criticality reject,

        value 1

      },

      {

        id id-NAS-PDU,

        criticality reject,

        value '7E004179000D0100F110F0FF000010325476982E02E0E0'H

      },

      {

        id id-UserLocationInformation,

        criticality reject,

        value userLocationInformationNR: {

          nR-CGI {

            pLMNIdentity '00F110'H,

            nRCellIdentity '001234501'H

          },

          tAI {

            pLMNIdentity '00F110'H,

            tAC '000064'H

          }

        }

      },

      {

        id id-RRCEstablishmentCause,

        criticality ignore,

        value mo-Signalling

      },

      {

        id id-UEContextRequest,

        criticality ignore,

        value requested

      }

    }

  }

}

[7] DownlinkNASTransport,

initiatingMessage: {

  procedureCode id-DownlinkNASTransport,

  criticality ignore,

  value {

    protocolIEs {

      {

        id id-AMF-UE-NGAP-ID,

        criticality reject,

        value 100

      },

      {

        id id-RAN-UE-NGAP-ID,

        criticality reject,

        value 1

      },

      {

        id id-NAS-PDU,

        criticality reject,

        value '7E005600020000213C985803AD3165...'H

      }

    }

  }

}

Reference

• AMF Overview - Cisco
• Exploring the 3GPP AMF Access & Mobility Management Function
• 5G StandAlone Access - Registration Procedure - Part2(AMF selection procedures, slices).
• Overload Control for N2 and NAS - Cisco
• Relative Capacity Configuration Update - Cisco

YouTube

• Access Mobility Function (AMF) in 5G - Telco Bytes (2021)