N2 Handover Procedure

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

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:

  • N2 handover without AMF change

  • N2 handover with AMF change

N2 Handover without AMF Change

Feature Description

For N2 handover without AMF change, the UE uses the source gNB to trigger the handover. The message from the source gNB has the ID of the target gNB.

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

N2 Handover without AMF Change Call Flow

This section describes the N2 Hanover without AMF Change call flow.

Figure 1. N2 Handover without AMF Change Call Flow
Table 3. N2 Handover without AMF Change Call Flow Description

Step

Description

1

With signaling from the UE, the source gNB starts the handover procedure by sending a HANDOVER REQUIRED message to the AMF.

2

The AMF finds a gNB that can support the signaled TargetId from the gNB. AMF rejects the message when it can’t find gNB. The AMF creates a ModificationRequest and sends it to the SMF.

3

The SMF analyzes the TargetID and takes appropriate actions. The SMF then responds.

4

The AMF finds the gNB corresponding to the Target ID, and the NGAP EP that serves that gNB. The AMF then sends a handover required message to the target gNB.

5

Target gNB sets up the resources required for the handover and responds with an ACK message. This ACK message contains the PDU resources that failed to setup as well.

6

The AMF constructs a Sm Context Modify message to update the target gNB tunnel endpoint IDs to the SMF. The AMF starts a guard timer and forwards the message to the SMF.

7

The SMF updates the information in associated UPFs and responds to the AMF.

8

The AMF builds a HandoverCommand message and sends it to the source gNB.

9

The UE now completes the handover at the target gNB. The target gNB sends a HANDOVER NOTIFY message to the AMF.

10

The AMF constructs a Sm Context Modify request to inform the SMF that the handover is complete.

11

SMF responds to the update.

12

The Handover procedure ends. The source gNB receives a UE context release command.

13

If there are PDU sessions that fail to setup at the target gNB are now released at the SMF.

N2 Handover with AMF Change

Feature Description

AMF supports N2 handover whenever there’s a change in AMF.

Unsupported Scenarios

The following scenarios aren’t supported:

  • Handover cancelation

  • Secondary RAT usage data signaling

  • Timeouts from SMF

  • Suspend/resume of running procedures

  • Handover restrictions

  • Service area restrictions

  • S-NSSAI checks

  • Tracing requirements

  • PCF reselection

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

N2 Handover with AMF Change Call Flow

This section describes the N2 Handover with AMF change call flow.

This call flow is similar to the N2 Handover without AMF change except the creation of the context on the new AMF and splitting up of the steps between the two nodes.

Figure 2. N2 Handover with AMF Change Call Flow
Table 4. N2 Handover with AMF Change Call Flow Description

Step

Description

1

The source gNB sends a HANDOVER REQUIRED message to the AMF.

2

The AMF analyses the target identifier and recognizes that it’s not a target it serves.

The AMF selects a new AMF to serve the UE and sends it a CreateUE Context message.

Note

 

In the CreateUE Context message, ncc remains absent, in the instance, when the value is 0.

3

The target AMF receives the message and verifies that it can serve the UE.

For each PDU session that must be handed over, the AMF sends a Modify SM Context message to the SMF.

4

The SMF does all the necessary procedures that are required to handle the UE in the new target and responds to the AMF.

5

The target AMF identifies the gNB that is going to handle the UE and sends a HANDOVER REQUEST to the gNB.

6

Once the necessary resources are allocated by the target gNB, the target gNB responds with a HANDOVER REQUEST ACK.

7

The AMF updates the SMF with the message transfer IE in the gNB.

8

The SMF responds to the requests in the AMF.

9

The target AMF responds to the source AMF and includes any Target to Source container in the response.

This response also includes any PDU sessions that have failed to set up in the target AMF due to any condition.

10

The source AMF sends a HANDOVER COMMAND to the source gNB.

11

The handover completes in the UE and the target gNB sends a HANDOVER NOTIFY to the target AMF.

12

The target AMF indicates receipt of the HANDOVER NOTIFY to the source AMF.

This causes the source AMF to start a timer the expiry of which leads to the release of resources in the source gNB.

13

The source AMF responds to the target.

14

The source AMF clears any PDU sessions that have failed to set up at the target.

15

The SMF responds to the release request in the source AMF.

16

The target AMF update the SMF on the completion of the handover.

17

The SMF acknowledges the message in the AMF.

18

When the timer expires for clearing of resources (or eventually when the UDM notifies the source that the registration for UECM isn’t valid), the source AMF releases resources both locally and at the gNB.

The AMF releases the resources at the gNB by sending a UE CONTEXT RELEASE COMMAND.

19

The source gNB responds with a UE CONTEXT RELEASE COMPLETE message.