AMF supports the authentication activities and the GUTI (Globally Unique Temporary Identity) reallocation configuration control for call flows.

GUTI

GUTI is used to keep the subscriber's IMSI confidential. AMF allocates a GUTI to the UE. It's composed of PLMN ID, AMF ID, and TMSI. As it's a temporary identifier, its associations aren’t fixed to any specific subscriber or mobile. A single 5G-GUTI is used to access the Security Context of 3GPP and non-3GPP technologies within the AMF.

Supported Functions

AMF supports the following functions:

• Authentication and GUTI reallocation counter maintained as per the UE. For each supported type, separate counters are maintained.

• Time reference per UE for network-initiated GUTI reallocation

• GUTI reallocation attempted as per the configuration for a specific time interval.

• Includes the new GUTI in either Registration Accept or Configuration Update Command NAS message

• AMF shows the allocated GUTI and the allocated time in the show subscriber command output.

Note	Collision of GUTI reallocation in Registration Accept or Configuration Update Command with other procedures isn’t supported.

Supported Scenarios

This feature supports the following scenarios based on the UE on time and frequency of access attempts. These scenarios are part of the Registration and Service Request procedure:

• Selective authentication

• GUTI reallocation

The frequency supports access attempts per UE and not across UEs.

Unsupported Scenarios

The following scenario isn’t supported:

• Authentication requirements dependent or based on EAP-AKA or EAPAKA' or EAPAKA Prime

• When the latest GUTI isn’t acknowledged, the UE is paged simultaneously with the old and the new GUTI.

Note	GUTI reallocation process takes place only for the successful procedure.

For more information, see the UCC 5G AMF Configuration and Administration Guide > AMF Authentication and GUTI Reallocation Configuration Control chapter.

The rolling software upgrade is one of the following processes:

• Upgrading or migrating the build from an older version to a newer version.

• Upgrading the patch for the required deployment set of application pods.

Note

The applications must be available all the time, where: New versions are expected to be deployed with new build versions or patches. Any unstable deployment upgrade is reverted to a previous stable version. Rolling upgrade takes place with zero downtime by incrementally updating pod instances with new ones.

For more information, see the UCC 5G AMF Configuration and Administration Guide > AMF Rolling Software Upgrade chapter.

The bulk statistics and Key Performance Indicators (KPIs) are used for analyzing the AMF performance.

The following is a list of applicable bulk statistics:

• Gauge:

  • A snapshot value that shows the statistic at the time of reporting.

  • These statistics values can increment or decrement continuously.

  • Example: The number of current PDP contexts, simultaneous Active EPS Bearers, and so on

• Counter:

  • A historic value that shows the statistic accumulated for a specific time range.

  • These statistics values can only increment except in the following two scenarios:

    • Rollover: Where a counter exceeds its maximum value and rolls over to zero.

    • Reset: Where a counter is manually reset to zero.

  • Example: The total number of CSR requests received.

For more information, see the UCC 5G Metrics Reference > Bulk Statistics and MME Equivalent KPI Support chapter.

Network Repository Function (NRF) functions as a centralized repository for all the 5G network functions (NFs). It performs the following:

• Provides NF service registration and discovery, in the operator network

• Enables NFs to identify appropriate services in each or one another

• Supports the service discovery function

• Receives NF Discovery Request from an NF instance

• Provides information about discovered NF instances

The AMF functions and benefits the user in multiple activities such as the following:

• Supports and sends the following:

  • registration

  • heartbeat

  • update

  • deregistration

  • NF Discovery-Request

• Includes the following:

  • nf-type

  • plmn-info

  • slice-data

  • ddn

• Sends the NFDiscovery request towards the NRF during the discovery of network elements

• Enables or disables the parameters through the NFDiscovery request

The AMF checks and queries NF discovery APIs of the NRF. It helps when they aren’t configured locally. It further discovers or locates the following network functions:

• AUSF

• UDM

• PCF

• SMF

• SMSF

• NSSF

• Peer AMF

The AMF supports the following NRF functionalities for GR-based instances:

• Creating, updating, and deleting a subscription

• Receiving a notification when the NF instance profile is either modified or deregistered from the NRF.

• Subscribing to notifications and receiving notifications, which were previously subscribed for registration or deregistration or profile changes of NF instances.

For more information, see the UCC 5G AMF Configuration and Administration Guide > Enhancing NRF Functionalities chapter.

AMF supports the error handling for the following interfaces:

• SBI—AMF interaction across various 5G NF's

• REST-EP—AMF interaction to NGAP, and NAS (towards UE)

AMF validates the syntax and semantic errors for each attribute during SBI message validation. It evaluates the mandatory, conditional, and optional attributes in the following:

• NGAP content

• NAS content

• Each SBI interface message

Note	You can define the local cause code-mapping values for Mobility-Management, while rejecting the NAS messages under failure scenarios. Validation of the NGAP and NAS optional IEs aren’t supported.

For more information, see the UCC 5G AMF Configuration and Administration Guide > Failure and Error Handling Support chapter.

The low mobility handover feature supports the following functions:

• Handover cancel for N2 without AMF change

• Handover cancel for N2 with source and target AMF change

• Handover failure procedure with and without AMF change

AMF doesn't support the following:

• Collision

• Non-3GPP access

• Trace

• Event subscription

• PCF interactions

For more information, see the UCC 5G AMF Configuration and Administration Guide > Low Mobility Handover (Xn/N2) chapter.

The N26 interface supports the following handover procedures:

• 5G to 4G (EPC) Handover

• 4G to 5G Handover

For more information, see the UCC 5G AMF Configuration and Administration Guide > N26-based Handover Procedures - EPC Interworking chapter.

AMF supports the following roaming types:

• Roaming on N9 and S8 interface

• Inter-operator roaming

For more information, see the UCC 5G AMF Configuration and Administration Guide > Roaming Support chapter.

SCTP uses virtual IP (VIP) to support HA. This feature supports two SCTP endpoints.

The SCTP pod starts and listens on VIP. If one SCTP pod goes down, traffic moves to the other SCTP pod using VIP.

For more information, see the UCC 5G AMF Configuration and Administration Guide > High Availability Services chapter.

Before implementing this feature, AMF needs separate deployment of the following five namespaces for scalability. Each AMF namespace supports the following:

• A pair of SCTP pods (active-standby)

• A pair of Protocol pods (active-standby)

• Extra pods getting deployed on Ops Center and ETCD

A single AMF namespace supports and deploys multiple SCTP pods and protocol pods. SCTP pods support multihoming and some SCTP stack-related parameters are configurable.

SCTP Configurable Stack Parameters

SCTP uses the multihomed host to provide fast failover and associated endurance during hardware failures. Using the associated parameters, the following activities are supported:

• Creating and customizing the required stack

• Configuring the resources by modifying the parameter values, which are later used in the stack template.

• No need to enter hardcoded values in multiple templates to specify different settings.

Multiple SCTP and Protocol Pod Pairs

Pods are tagged with one or more labels. The labels are later used to select and manage groups of pods in a single operation. The labels are stored in a key-value format in the metadata hash.

For more information, see the UCC 5G AMF Configuration and Administration Guide > SCTP Multihoming and Stack Parameters Support chapter.

In 5G, the AMF sends and receives the SMS payloads from the UE over the NAS messages. The AMF and SMSF entities within the 5G core provide and utilize services provided by each other to enable the delivery of SMS over Non-Access Stratum (NAS).

For more information, refer to the UCC 5G AMF Configuration and Administration Guide > SMS over the Non-Access Stratum Procedures chapter.

AMF supports the following non-3GPP timers:

• UE Context Transfer (context-transfer-guard): AMF uses this timer to keep the individual UE Context resources until the timer expires. AMF starts this timer when UeRegStatusUpdateReqData message contains transferStatus as TRANSFERRED. Upon expiry, it clears the PDUs locally.

• Procedural Timeout (proc-timeout): It starts when AMF receives Registration Request. After expiry, AMF sends the Registration Reject message to the UE.

• Tidle (tidle): When the UE moves to the CONNECTED state, tidle timer is started and it's reset when any signalling occurs for the subscriber.

  On expiry of tidle timer, AMF checks:

  • If the UE Configuration Update is enabled and if new configuration is available to send to the UE, AMF triggers the UE Config Update Command to UE and resets the tidle timer.

  • If the UE Configuration Update isn’t enabled or there’s no configuration update to send the to UE, the UE is moved to the IDLE state. AMF triggers the Context Release Command towards the gNB and the SM Context Update towards the SMF accordingly.

• Tn2 (tn2): It functions in AMF-initiated N2 messages, specifically for the AMF that waits for the response.

For more information, see the UCC 5G AMF Configuration and Administration Guide > Session Timers chapter.

AMF supports the UE Context Transfer message at source and target AMF. The following CLI configurations are added:

• allow-interplmn-supi-transfer

• horizontal-key-derivation

• use-source-key

• use-source-pcf

UE Context Transfer at Source AMF:

• Sends UE Context with SUPI value to target AMF as per the CLI configuration, when source AMF and target AMF are in different PLMN

• Uses either existing keys or generates new keys, and sends the keys to target AMF during context transfer as per the CLI configuration

• Starts context-transfer-guard timer (configured with greater than zero (0)), when UeRegStatusUpdateReqData contains transfer status as TRANSFERRED

  On expiry of the context-transfer-guard timer, source AMF performs the following:

  • Triggers the UDM Deregistration internally to clear the local ueContext

  • When the UE Context Transfer reason is INIT_REG, it updates the SMF to release the PDU context

• It releases PDU sessions in the toReleaseSessionList

• The UE-validation reason is handled as follows:

  • Without registration request

  • By omitting integrity check

  • Responding with appropriate data to target AMF

• Clears PCF association, when target AMF sends pcfReselectedInd in transfer update

• Handles reject indication received from target AMF

• Performs horizontal key derivation as per the CLI configuration

• Transfers URI with SUPI as ueContextId to target AMF

• Sends DRX, GMM capability IEs to target AMF

• Increments transfer failure counters including NOT_TRANSFERRED counters

• Doesn't send SeafData in transfer response in MOBI_REG_UE_VALIDATED when the Individual ueContext is identified with SUPI

UE Context Transfer handling at Target AMF:

• Sends Reject Indication to source AMF through StatusUpdate message when authentication or security fails

  The security algorithm mismatch is handled as follows:

  • Authenticates when integrity check fails

  • Recomputes the keys as per the algorithm received from AUSF

  • Regenerates all the keys and ignores the keys received from source AMF.

• Sends failure to source AMF when authentication or security check fails

• The SUPI as UeContextID is handled as follows:

  • Sends Identity request to UE when message integrity check fails

  • Performs UE authentication with obtained SUPI from UE

  • Sends SUPI as UeContextId, and UE-validated in UeContextTansferReq to source AMF

• Ignores the PCF information obtained from the source AMF and selects the new PCF based on the CLI configuration. Informs the selection of new PCF using pcfReselectedInd to source AMF in UeRegStatusUpdateReq.

For more information, see the UCC 5G AMF Configuration and Administration Guide > UE Context Transfer chapter.

The AMF supports the generic UE configuration procedure by sending the Configuration Update Command message to the UE when certain parameters are modified. The AMF supports the following parameters in the Configuration Update Command message:

• 5G-GUTI

• TAI list

• SMS indication

For more information, refer to the UCC 5G AMF Configuration and Administration Guide > UE Configuration Management Procedures chapter.

When the 5GC supports the emergency services, the UE is enabled to handle the emergency through the Registration Accept message on per-TA and per-RAT basis. This feature allows the UE to fall back to EUTRAN connected to 5GC (4G radio, 5G core) or EUTRAN connected to EPC (4G radio, 4G core). UE switches to the EUTRAN type based on the network capabilities and if the 5G Radio is not NR capable.

For more information, refer to the UCC 5G AMF Configuration and Administration Guide > VoNR Support chapter.