Internode Registration Support

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

5G-AMF

Applicable Platform(s)

SMI

Feature Default Setting

Enabled - Always-on

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

2021.04.0

Feature Description

This feature supports the following:

  • Internode Initial Registration

  • Internode Mobility Registration

Internode Initial Registration

Feature Description

AMF now supports registering a UE when it gets a registration request with type set to initial registration with identifier GUTI allocated by a peer node.

The case of this AMF being the “old” node during initial registration or attach procedure is described in Registration with AMF Change section.

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

Identification with Peer Node Call Flow

This section describes Identification with Peer Node call flow.

Figure 1. Identification with Peer Node Call Flow
Table 3. Identification with Peer Node Call Flow Description

Step

Description

1

If the peer node is an AMF, then new AMF sends a transfer request to the old AMF, with type set to “INITIAL REGISTRATION”, including the whole registration request received by it.

2

The old AMF checks the integrity protection of the request, and if integrity checks pass, responds with the UE context, but without any SMF information.

3

The old AMF checks the integrity of the message that is received from the new AMF. If the integrity check passes, the old AMF packages the attributes of the UE that is available in the response to the transfer request. If the request was for mobility updating, PDU session information present in the old AMF is sent to the new AMF.

4

AMF releases any resources that the UE held at any SMF.

5

SMF responds to the AMF request.

6

The new AMF sends a transfer update message to the old AMF.

7

The old AMF responds with a “204 OK” indicating that the transfer is successful.

8

If the old node is an MME, then AMF sends an identity request message to MME along with the registration request received.

9

MME checks the integrity of the message it receives. If integrity checks pass, the MME returns the MM context.

At the end of a successful transfer from a peer node, AMF issues a security mode command with a mapped security context (from LTE) or a non-current security context (5G) towards the UE.

Limitations

Additional GUTI in the registration request is not supported.

Internode Mobility Registration

Feature Description

This feature supports the following:

  • Idle Mode Registration from Peer MME to AMF

  • AMF to MME Idle Mode Handoff

  • Registration with AMF Change

Idle Mode Registration from Peer MME to AMF

Feature Description

AMF now supports using the N26 interface to retrieve a context from an MME for handling registration request with type set to Mobility Updating and a foreign GUTI. AMF then uses a mapped security context from the MME to use with the UE.

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

Idle Mode Registration to AMF from MME Call Flow

This section describes the Idle Mode Registration to AMF from MME call flow.

Figure 2. Idle Mode Registration to AMF from MME Call Flow
Table 4. Identification with Peer Node Call Flow Description

Step

Description

1

The UE sends a Registration Request with a GUTI assigned by an MME.

2

The AMF analyzes the GUTI, identifies an MME and sends a context request.

3

The MME responds with a ContextResponse.

4

The AMF sends a ContextAcknowledge to the MME.

Step 5 to Step 18 are same as mentioned in the call flow for Registration with AMF Change.

AMF to MME Idle Mode Handoff

Feature Description

AMF supports idle mode handoff to MME for 5GS to EPS Idle mode mobility using N26 interface.

  • Context Request: MME sends the Context Request message to the AMF to get the MM and EPS bearer Contexts for the UE.

  • Retrieve SM Context service operation: Retrieves an individual SM context, for a given PDU session associated with 3GPP access from the SMF.

Currently, the following are not supported:

  • Handling of timeouts from SMF during Retrieve Request

  • Handling of negative response from SMF during Retrieve Request

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

AMF to MME Idle Mode Handoff Call Flow

This section describes the AMF to MME Idle Mode Handoff call flow.

The following call flow shows the messaging that happens in the network.

Figure 3. AMF to MME Idle Mode Handoff Call Flow
Table 5. AMF to MME Idle Mode Handoff Call Flow Description

Step

Description

1

A UE that was previously registered on an AMF in 5GC moves to EPC, and sends a TAU request to an MME. From the GUTI sent by the UE, the MME finds the identity of the AMF, and sends a ContextRequest over N26.

2

The ContextRequest reaches the AMF. MME sends the full TAU Request message as a part of the ContextRequest. The AMF does integrity checks on the request to ascertain the validity of the request.

If the request from the MME indicates that the MME has authorized the UE, AMF doesn’t do security checks on the received message.

If integrity checks fail, AMF rejects the request. Or else, the AMF retrieves the PDU sessions information from each of the SMFs that host PDUs for this UE and has allocated EBI for their sessions from the AMF.

3

The SMF responds to the SmContext Retrieve Request from the AMF.

4

AMF responds to MME by sending a ContextResponse message when AMF receives all the expected responses from SMFs.

5

The MME sends a ContextAcknowledgement message to the AMF. The AMF starts a guard timer to clear allocated resources in case the notification from the UDM to clear the registration doesn’t come through.

6

Since the MME is now the owner of the registration, the UDM notifies the AMF that the registration for 3GPP access is cancelled.

7

The AMF releases any local resources, and responds to the UDM.

8

The AMF clears the subscription to changes in subscription data at the UDM.

9

The UDM responds to the request from the AMF.

Registration with AMF Change

Feature Description

AMF now supports registration with Mobility Updating and AMF Change. Currently, AMF only supports GUTI based relocations.

REST Endpoint

To support changes at the old AMF, endpoints are needed for the following:

  • Transfer requests from the new AMF

  • Transfer-Update requests from the new AMF

  • Notifications from the UDM

Client code for Transfer Requests and Transfer Update Requests are required in the new AMF.

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

Registration with AMF Change Call Flow

This section describes the Registration with AMF Change call flow.

Figure 4. Registration with AMF Change Call Flow
Table 6. Registration with AMF Change Call Flow Description

Step

Description

1

UE builds a registration message with type set to Mobility Updating or Initial Registration and sends it to the gNB. At gNB, the message becomes the payload of an INITIAL UE message (if the UE is in ECM_IDLE) or an UPLINK NAS TRANSPORT message when the UE is in ECM_CONNECTED (Only for Mobility Updating). When the UE is in ECM_CONNECTED, there's a N2 handover procedure that precedes this part, and the context transfer steps of the call flow are omitted.

2

The new AMF analyses the GUTI that is send by the UE and determines whether it’s allocated by a different AMF. The new AMF determines the old AMF using parameters from the GUTI and constructs a transfer request. The whole message body that is received by the new AMF is part of the request to the old AMF. The new AMF sets the type of transfer request based on whether the UE is registering for initial registration or mobility updating.

3

The old AMF checks the integrity of the message that is received from the new AMF. If the integrity check passes, the old AMF packages the attributes of the UE that is available in the response to the transfer request. If the request was for mobility updating, PDU session information present in the old AMF is sent to the new AMF.

4

The new AMF sends a transfer update message to the old AMF.

5

If the new AMF decides not to use the current PCF, the old AMF clears the PCF associations created by it. In the case of initial updating, the AMF clears all the PDU sessions.

The new AMF interacts with UDM to register as the node responsible for the UE. The AMF also interacts with the UDM to register for changes to subscription data for the UE, and these steps are the same as the one executed by the AMF during initial registration.

6

Once the new AMF registers with the UDM, the UDM notifies the old AMF that its registration has been cancelled.

7

The old AMF acknowledges the notification from the UDM.

8

Since the old AMF is no longer interested in changes to the subscription information, it sends a cancel for subscription for changes to SDM subscription.

9

The UDM clears the subscription and responds to the old AMF. The old AMF clears any state it has on the UE. The new AMF sets up policies in the PCF, and these steps are the same as those done during initial registration.

10

If AMF policies are to be set up with the PCF, the AMF sends a request to create the policies in the PCF.

11

PCF responds to the AMF request.

12

For each PDU session that the new AMF has taken over, it sends a message to the SMF to change the AMF for the session.

13

SMF responds to the AMF.

14

AMF sends a Registration Accept to the UE with new GUTI and a Tracking Area List. These steps are same as done during the AMF initial registration.

15

If the registration type is Mobility Updating, AMF ignores FollowOn IE and does not initiate UE CONTEXT RELEASE COMMAND.
Limitations

The following scenarios are currently not supported:

  • Activation of bearers during Registration

  • Steering of Roaming information

  • UE Policy Information

  • Integrity check failure

  • Optional authentication of the UE

  • Change of PCF during mobility

  • Rejection/Clearing of PDU sessions

OAM Support

This section describes operations, administration, and maintenance information for this feature.

Bulk Statistics Support

  • Message level statistics for new SBA messages, on a per peer AMF basis.

  • Procedure level statistics for new and old AMF procedures, with Attempted, Success and Failure.