WO2018205100A1

WO2018205100A1 - Method and apparatus for conducting a handover

Info

Publication number: WO2018205100A1
Application number: PCT/CN2017/083478
Authority: WO
Inventors: Jinguo Zhu; Fei Lu
Original assignee: Zte Corporation
Priority date: 2017-05-08
Filing date: 2017-05-08
Publication date: 2018-11-15

Abstract

A method for conducting a handover involves, according to various implementations, an access management function (e.g., executing on a computmg device that is part of a core network) receiving a handover required message from a source radio network, selecting a new session management function to manage the forwarding of protocol data units from a source radio access network to a target radio access network, receiving a path switch request message from the target radio access network, and triggering the session management function to switch the data path of the one or more protocol data unit sessions from the source radio access network to the target radio access network.

Description

METHOD AND APPARATUS FOR CONDUCTING A HANDOVER

TECHNICAL FIELD

The present disclosure is related generally to handovers in wireless networks and, more particularly, to a method and an apparatus for carrying out a handover from one radio access network to another.

BACKGROUND

Various international telecommunications organizations, such as the 3rd Generation Partnership Project ( “3GPP” ) , have been mapping out families of technologies that are envisioned to supplement and replace currently-deployed Fourth Generation ( “4G” ) Long-Term Evolution ( “LTE” ) . The new technologies, generally referred to as Fifth Generation ( “5G” ) , promise to provide increased network flexibility and virtualization and are intended to be particularly good at providing a communication platform for the so-called “Internet of Things” ( “IoT” ) . It is taking time, however, for various network procedures carried over from 4G to be updated to take advantage of the speed and flexibility of 5G. For example, in the area of handovers of multiple protocol data unit sessions between nodes of a radio access network ( “RAN” ) , currently-proposed 5G schemes typically require the access management function ( “AMF” ) to wait for responses from all of the session management functions ( “SMFs” ) involved before completing the handover. This can result in unnecessary delay and increased latency for the handover procedure.

DRAWINGS

While the appended claims set forth the features of the present techniques with particularity, these techniques, together with their objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:

FIG. 1 depicts a networking environment in which various embodiments of the disclosure may be employed.

FIG. 2 depicts a more specific networking environment in which various embodiments of the disclosure may be employed.

FIG. 3 depicts a basic hardware architecture that is included in various devices described herein.

FIG. 4 is a message flow diagram depicting an Xn based inter next generation ( “NG” ) RAN handover without user plane function ( “UPF” ) relocation.

FIG. 5 is a message flow diagram depicting an Intra AMF, inter NG-RAN node handover without an Xn interface.

FIG. 6 is a message flow diagram depicting an inter NG RAN, intra AMF handover without UPF relocation, according to an embodiment.

FIG. 7 is a message flow diagram depicting an inter NG RAN, inter AMF handover without UPF relocation, according to an embodiment.

FIG. 8 is a message flow diagram depicting an inter NG RAN intra AMF handover with UPF relocation, according to an embodiment.

DESCRIPTION

The present disclosure is generally directed to a method and apparatus for conducting a handover. According to various embodiments, an access management function (e.g., executing on a computing device that is part of a core network) receives a handover required message from a source radio network, selects a new session management function to manage the forwarding of protocol data units from a source radio access network to a target radio access network, receives a path switch request message from the target radio access network, and triggers the session management function to switch the data path of the one or more protocol data unit sessions from the source radio access network to the target radio access network.

Turning to FIG. 1, an example of a wireless networking environment in which the various techniques described herein may be practiced is shown. The wireless networking environment includes radio access networks ( “RANs” ) , represented in FIG. 1 by a first RAN 102 and a second RAN 104. The first and second RANs may be different types of networks. For example, the first RAN 102 may be a 5G network, while the second RAN 104 may be a 4G network (e.g., which has been upgraded to support an N2/N3 interface) . The wireless networking environment further includes a core network 105 (an example of which is a next generation core ( “NGC” ) ) . The first RAN 102 includes multiple network nodes, represented by

nodes

106, 108, 110, and 112, each of which is depicted as a next generation Node B ( “gNB” ) . The second RAN 104 includes multiple network nodes, represented by nodes 116 and 118, each of which is depicted as an evolved Node B ( “eNB” ) . An example of a physical implementation of a network node is a cellular base station (e.g., configured as an evolved Node B ( “eNB” ) or a next generation Node B ( “gNB” ) ) . Some of the nodes, such as nodes 108, 110, and 112, are communicatively linked with one another via interfaces or “reference points” labeled Xn, which often have fiber optic land lines as their physical media. Node 106 is not directly connected to the other nodes of FIG. 1. Each of the nodes is also communicatively linked to the core network 105 by a respective N2/N3 reference point. A user equipment ( “UE” ) 122 is capable of communicating over the first RAN 102 and the second RAN 104. The area of coverage of each of the nodes is indicated by a dashed circle and, in some embodiments, this area is known as a “cell. ” The UE 122 shown in FIG. 1 is meant to be representative, and many UEs may in fact communicate over the RANs 102 and 104 at the same time or at different times.

The core network 105 includes several computing devices that execute software to carry out various functions in support of the first RAN 102 and the second RAN 104. Although these functions are sometimes depicted as functional blocks, it is to be understood that these functions are, in fact, carried out by actual computing devices (e.g., under the control of software) . For example, the core network 105 includes one or more computing devices that are represented by

devices

114, 116, 118, and 120, which execute one or more access and mobility management functions ( “AMFs” ) , one or more user plane functions ( “UPFs” ) , and one or more session management functions ( “SMF” ) . For ease of explanation,

devices

118 and 120 are each shown as executing a different SMF. Also, device 114 is shown as executing an AMF and device 116 is shown as executing a UPF. Put another way, the AMF and SMF are part of the control plane ( “CP” ) of the environment depicted in FIG. 1.

Continuing with FIG. 1, an AMF (i.e., a computing device executing software that carries out the AMF) carries out one or more of the following procedures in support of the RANs: registration management, connection management, reachability management and mobility management. The AMF also carries out access authentication and access authorization, acts as the non-access stratus ( “NAS” ) security termination, and relays the session management ( “SM” ) NAS between UE and SMF, etc. NAS is a layer over which communication between the UE and the core network 105 takes place. A UPF (i.e., a computing device executing software that carries out the UPF) carries out procedures in support of the RANs such as: acting as an anchor point for mobility between and within radio access technologies ( “RATs” ) , packet routing and forwarding, traffic usage reporting, quality-of-service ( “QoS” ) handling for the user plane, downlink ( “DL” ) packet buffering, DL data notification triggering, etc.

Turning to FIG. 2, a 5G-specific network environment in which the various techniques described herein may be implemented includes a first 5G RAN 202, a second 5G RAN 204, an AMF 206, an SMF 208, a UPF 210, a data network 212, and a UE 214. The first and second 5G RANs 202 and 204 are communicatively linked to one another via an Xn interface. The UE 214 communicates with the AMF 206 via an N1 interface. The 5G nodes 202 and 204 communicate with the AMF 206 via respective N2 interfaces and with the UPF via respective N3 interfaces. The SMF 208 and UPF 210 communicate with one another via an N4 interface.

The networking environments depicted in FIG. 1 and FIG. 2 have many components that are not shown, including other network nodes, other UEs, wireless infrastructure, wired infrastructure, and other devices commonly found in wireless networks. Example implementations of the UEs include any device capable of wireless (e.g., long-term evolution ( “LTE” ) or its follow-on technologies) communication, such as a smartphone, tablet, laptop computer, and non-traditional devices (e.g., household appliances or other parts of the IoT) .

FIG. 3 illustrates a basic (computing device) hardware architecture found in the devices depicted in FIG. 1, FIG. 2 (include the UEs, the devices of the core network 105, and any other device that executes one or more of the functions described herein, include the functional blocks) as well as in the devices depicted in the remaining figures. The devices may have other components as well, some of which are common to all of the devices and others that are not. The hardware architecture depicted in FIG. 3 includes logic circuitry 302, memory 304, transceiver 306 (awired and/or wireless transceiver) , and one more antennas represented by antenna 308. Each of these elements is communicatively linked to one another via one or more data pathways 310. Examples of data pathways include wires, conductive pathways on a microchip, and wireless connections.

The term “logic circuitry” as used herein means a circuit (atype of electronic hardware) designed to perform complex functions defined in terms of mathematical logic. Examples of logic circuitry include a microprocessor, a controller, or an application-specific integrated circuit. When the present disclosure refers to a computing device carrying out an action, it is to be understood that this can also mean that logic circuitry integrated with the computing device is, in fact, carrying out the action.

Possible implementations of the memory 304 include: volatile data storage； nonvolatile data storage； electrical memory； magnetic memory； optical memory； random access memory ( “RAM” ) ； cache memory； and hard drives.

Current Xn based inter NG RAN handover without UPF relocation

In currently-proposed implementations of wireless networks, Xn-based based inter NG RAN handover without UPF relocation occurs as shown in FIG. 4, which depicts a UE 402, a source RAN 404, a target RAN 406, an AMF 408, one or more SMFs 410, and one or more UPFs 412. In particular, the procedure of FIG. 4 is used to hand over a UE from a source RAN to a target RAN using the Xn reference point, keeping the same AMF, and where the SMF decides to keep the existing UPF. In addition to relying on the Xn reference point between the source and the target RAN, the procedure relies on the presence of an N2 reference point between the AMF and the source RAN as well as between the AMF and the target RAN. The steps are as follows:

Step 1. The source RAN 404 decides to perform an Xn based handover, since there is an Xn reference point between the source RAN 404 and target RAN 406. The source RAN 404 sends an Xn handover Request to the target RAN 406. This message includes information regarding all QoS flows of PDU sessions to be handed over.

Step 2. The target RAN 406 carries out an authorization procedure and reserves resources for the accepted QoS flows. The target RAN 406 sends an Xn handover Response to the source RAN 404, including information regarding the resources reserved in the target RAN 406.

Step 3. The source RAN 404 sends a handover command to the UE 402 to trigger the UE handover, including information regarding the resources reserved in the target RAN 406.

Step 4. The UE 402 performs synchronization with the target RAN 406 based on the resource information received from the source RAN 404.

Step 5. The Target RAN sends an N2 Path Switch Request message to an AMF 408 to inform it that the UE 402 has moved to a new target cell. For each of the QoS flows of PDU sessions accepted to be switched to the Target RAN, the N2 Path Switch Request message includes N2 SM information.

Step 6. The AMF 408 sends N2 SM information by using an N11 Message to each SMF 410 associated with the list of protocol data unit ( “PDU” ) Sessions received in the N2 Path Switch Request. For the PDU Sessions to be switched to the Target RAN, upon receipt of the N11 Message, each of these SMFs determines whether the existing UPF 412 can continue to serve the UE 402. For the PDU session (s) that are not included in the N2 Path Switch Request message, the AMF 408 sends separate request (s) to the relevant SMF (s) to release the PDU session (s) .

Step 7. For PDU Sessions requested by the Target RAN, the SMF 410 sends an N4 Session Modification Request (RAN address, tunnel identifiers for downlink User Plane) message to the UPF 412.

Step 8. The UPF 412 returns an N4 Session Modification Response (Tunnel identifiers for uplink traffic) message to the SMF 410 after the requested PDU Sessions are switched.

From this point on, the downlink data is sent to target RAN 406 from the UPF 412.

Step 9. The SMF 410 sends an N11 Message Ack (CN Tunnel Information) to the AMF 408 for PDU Sessions that have been switched successfully.

Step 10. Once the N11 Message Response is received from all of the SMFs, the AMF 408 aggregates all received CN Tunnel Information from these responses, and sends this aggregated information as part of the N2 SM Information in the N2 Path Switch Request Ack to the Target RAN. If none of the requested PDU Sessions have been switched successfully, the AMF 408 sends an N2 Path Switch Request Failure message to the Target RAN.

Step 11. By sending a Release Resources message to the Source RAN, the Target RAN confirms the success of the handover. It then triggers the release of resources with the Source RAN.

Current Intra AMF, inter NG-RAN node handover without Xn interface

In currently-proposed implementations of wireless networks, intra AMF and inter NG RAN handovers without an Xn interface occur as shown in FIG. 5, which depicts a UE 502, a source RAN 504, a target RAN 506, an AMF 508, one or more SMFs 510, and one or more UPFs 512.

Step 1. The source RAN 504 decides to perform an N2 based handover since there is no Xn reference point between source RAN 504 and target RAN 506 present. The source RAN 504 sends an N2 Handover Required to the AMF 508. This message includes information regarding all of the QoS flows to be handed over.

Step 2. The AMF 508 sends a PDU Handover Request (PDU session ID, Target ID) to each SMF involved in relevant PDU sessions. In other words, this message is sent for each PDU-session indicated, by the source RAN 504, as an N2 Handover candidate. The PDU session ID indicates a PDU session candidate for N2 Handover.

Step 3. Each SMF from Step 2 sends a PDU Handover Response (PDU session ID, SM N2 info) to the AMF 508.

Each SMF selects a UPF that supports N3 connectivity towards the Target RAN node. Also, each SMF checks to see if the N2 Handover for the indicated PDU session can be accepted, and includes the result in SM N2 information sent to the target RAN (transparently with regard to the AMF) . If the N2 handover for the PDU session is accepted, the SM N2 information also includes the PDU session ID, N3 UP address and Tunnel ID of the UPF, and QoS parameters.

Step 5. The target RAN 506 sends a Handover Request Acknowledge (Target to Source transparent container, SM N2 response list, PDU sessions failed to be setup list) to the AMF 508. The Target to Source transparent container includes a UE container with an access stratum part. The UE container is sent transparently via the AMF and source RAN to the UE 502. The information provided to the source RAN 504 also contains a list of PDU session IDs indicating the PDU sessions that failed to be setup and the reason (s) for failure. The SM N2 response list includes, for each entry in the list and for each PDU session accepted by the target RAN 506, a PDU session ID an N3 User Plane ( “UP” ) address (e.g., an internet protocol ( “IP” ) address) and the Tunnel ID of target RAN 506.

Step 6. The AMF 508 sends a Modify PDU Request (PDU session ID, SM N2 response) to the SMF 510. For each SM N2 response received from the target RAN 506 (included in SM N2 response list) , the AMF 508 sends the received SM N2 response to the SMF indicated by the respective PDU Session ID.

Step 7. Each SMF 510 sends a Modify PDU Response (PDU session ID) to the AMF 508. In effect, this message is sent for each received Modify PDU Request message.

The SMF 510 carries out preparations for the N2 Handover by indicating the N3 UP address and the Tunnel ID of target RAN 506 to the UPF if the N2 Handover is accepted by target RAN 506. If the N2 Handover is not accepted by target RAN 506, the SMF 510 de-allocates the N3 UP address and the Tunnel ID of the selected UPF. The SMF 510 acknowledges the Modify Request message by sending Modify PDU Response message to the AMF 508.

Step 8. The AMF 508 sends a Handover Command (Target to Source transparent container, PDU sessions failed to be setup list) to the source RAN 504. The Target to Source transparent container is forwarded as received by the AMF 508.

The source RAN 504 uses the list of PDU sessions failed to be setup and the indicated reason (s) for failure to decide whether to proceed with the N2 Handover procedure.

Step 9. The source RAN504 sends a Handover Command (UE container) to the UE. The UE container is sent transparently from target RAN 506 via the AMF 508 to the source RAN 504 and is provided to the UE 502 by the source RAN 504.

Step 10. The UE 502 sends a Handover Confirm to the target RAN 506. After the UE 502 has successfully synchronized to the target cell, it sends a Handover Confirm message to the target RAN 506. By sending this Handover Confirm message, the UE 502 is indicating that it considers the handover to be successful.

Step 11. The target RAN 506 sends a Handover Notify command to the AMF 508. By sending this Handover Notify message, the target RAN 506 is indicating that it considers the handover to be successful.

Step 12. The AMF 508 sends a Handover Complete (PDU session ID) to the SMF 510. A Handover Complete is sent for each PDU Session to the corresponding SMF to indicate the success of the N2 Handover.

Step 13. The SMF 510 sends a Handover Complete Ack (PDU session ID) to the AMF 508.

The SMF 510 indicates to the selected UPF 512 that the downlink User Plane for the indicated PDU session may be switched to target RAN 506. The SMF 510 confirms reception of Handover Complete.

Step 14. The AMF 508 sends a UE Context Release Command to the source RAN 504.

Step 15. The source RAN 504 sends a UE Context Release Complete to the AMF 508. The source RAN 504 releases the resources related to the UE 502 and responds with a UE Context Release Complete message.

As can be seen from FIG. 4 and FIG. 5, the AMF in both cases needs to wait for responses from all of the SMFs, which may result in delays in completing the handover and in high latency during the handover. According to an embodiment, an improved handover procedure involves the source RAN performing an Xn-like handover via the N2 interface. In this embodiment, the Xn can be regarded being implemented via the AMF. The AMF may establish an SMF for data forwarding, but it does not need to contact the existing SMF and does not need to wait for all responses from all of the SMFs. Thus, the UE can handover to the target RAN as soon as possible. The target RAN then performs a path switch procedure via the AMF, similar to an Xn handover.

According to an embodiment, an inter NG RAN intra AMF handover without UPF relocation occurs as shown in FIG. 6, which depicts a UE 602, a source RAN 604, a target RAN 606, a source AMF 608, one or more SMFs 610, a forwarding SMF 610a, one or more UPFs 612, and a forwarding UPF 612a. In this procedure, the AMF is unchanged and the SMF determines that the existing UPF will be kept.

Step 1. The source RAN 604 decides to perform an N2 based handover because no Xn reference point between the source RAN 604 and the target RAN 606 is present. The source RAN 604 sends an N2 Handover Required (Source to Target transparent container, Target ID, N2 SM information) to the AMF 608. The N2 SM information includes information regarding all QoS flows of PDU sessions to be handed over.

Step 2. The AMF 608 sends a Handover Request (Source to Target transparent container, N2 SM information, MM N2 info) to the target RAN 606. The AMF 608 determines the target RAN 606 based on the Target ID. The N2 SM information and Source to Target transparent container are forwarded to the target RAN 606 as received from source RAN 604. MM N2 information includes, e.g., security information and a Handover Restriction List.

Step 3. The target RAN 606 sends a Handover Request Acknowledge (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information) to the AMF 608. The Target to Source transparent container includes a UE container with an access stratum part. The UE container is sent transparently via the AMF 608 to the UE 602.

The information provided to the source RAN 604 also contains a list of PDU session IDs indicating PDU sessions failed to be setup and reason for failure. The AMF 608 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s) . The N2 SM information contains the RAN address and tunnel identifiers for downlink User Plane for all accepted PDU sessions.

Step 4. The AMF 608 may select a new SMF for data forwarding (SMF_F 610a) . The AMF sends an N11 message (N2 SM information) to the selected SMF.

Step 5. The SMF_F 610a selects a UPF_F 612a and sends an N4 Session Create Request (RAN address, tunnel identifiers for downlink User Plane) message to the UPF_F 612a.

Step 6. The UPF_F 612a allocates tunnel information for each accepted PDU session and returns an N4 Session Create Response (UPF address, Tunnel identifiers for forwarding data) message to the SMF_F 610a.

Step 7. The SMF_F 610a sends an N11 message (N2 SM information for forwarding data) to the AMF 608. The N2 SM information contains the UPF address and Tunnel identifiers of the UPF_F 612a for forwarding data.

Step 8. The AMF 608 sends a Handover Command (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information for forwarding data) to the source RAN 604. The Target to Source transparent container is forwarded as received from the target RAN 606. The N2 SM information contains the UPF address and Tunnel identifiers of the UPF_F 612a for forwarding data.

Step 9. The source RAN 604 sends a Handover Command (UE container) to the UE 602. The UE container is sent transparently from the target RAN 606 via the AMF 608 to the source RAN 604 and is provided to the UE 602 by the source RAN 604.

Step 10. The UE 602 sends a Handover Confirm to the target RAN 606. After the UE 602 has successfully synchronized to the target cell, it sends a Handover Confirm message to the target RAN 606. Handover is, by this message, indicated to be successful by the UE 602.

Step 11. The Target RAN 606 sends an N2 Path Switch Request message to the AMF 608 to inform it that the UE 602 has moved to a new target cell. This message includes the N2 SM information containing the RAN address and RAN N3 tunnel identifiers for downlink User Plane for all accepted PDU sessions. This message also includes a list of PDU sessions that failed to be setup. The AMF 608 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s)

Step 12. The AMF 608 sends N2 SM information (by using an N11 Message) to each SMF associated with the list of PDU Sessions received in the N2 Path Switch Request. For the PDU Sessions to be switched to the Target RAN 606, upon receipt of the N11 Message, each of these SMFs determines whether the existing UPF can continue to serve the UE 602.

Step 13. For PDU Sessions requested by the Target RAN 606, the SMF 610 sends an N4 Session Modification Request (RAN address, RAN N3 tunnel identifiers for downlink User Plane) message to the UPF 612.

Step 14. The UPF 612 returns an N4 Session Modification Response (Tunnel identifiers for uplink traffic) message to the SMF 610 after the requested PDU Sessions are switched.

From now on, the downlink data is sent to the target RAN 606 from the UPF 612.

Step 15. The SMF 610 sends an N11 Message Ack (CN Tunnel Information) to the AMF for PDU Sessions that have been switched successfully.

Step 16. Once the N11 Message Response is received from all of the SMFs, the AMF 608 aggregates received CN Tunnel Information from these responses and sends this aggregated information as a part of N2 SM Information in N2 Path Switch Request Ack to the Target RAN 606. If none of the requested PDP Sessions have been switched successfully, the AMF 608 sends an N2 Path Switch Request Failure message to the Target RAN 606.

Step 17. By sending a Release Resources message to the Source RAN 604, the AMF 608 confirms success of the handover. It then triggers the release of resources with the Source RAN 604.

According to an embodiment, an inter NG RAN inter AMF handover without UPF relocation occurs as shown in FIG. 7, which depicts a UE 702, a source RAN 704, a target RAN 706, a source AMF 708, a target AMF 709, one or more SMFs 710, a forwarding SMF 710a, one or more UPFs 712, and a forwarding UPF 712a. In this procedure, the AMF is changed and the SMF determines that the existing UPF will be kept.

Step 1. The source RAN 704 decides to perform an N2 based handover because there is no Xn reference point present between the source RAN 704 and the target RAN 706. The source RAN 704 sends an N2 Handover Required (Source to Target transparent container, target ID, N2 SM information) to the source AMF 708. The N2 SM information includes information regarding all QoS flows that are to be handed over.

Step 2. The source AMF 708 selects another AMF (the target AMF 709) and sends a Forward Relocation Request (Source to Target transparent container, Target ID, and N2 SM information) to the target AMF 709. The Source to Target transparent container and N2 SM information are forwarded to target AMF 709 as received from the source RAN 704.

Step 3. The target AMF 709 sends a Handover Request (Source to Target transparent container, N2 MM information, N2 SM information) to the target RAN 706. The target AMF 709 determines the target RAN 706 based on the Target ID. The N2 SM information and Source to Target transparent container are forwarded as received from the source AMF 708. The N2 MM information includes, e.g., security information and a Handover Restriction List.

Step 4. The target RAN 706 sends a Handover Request Acknowledge (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information) to the target AMF 709. The Target to Source transparent container includes a UE container with an access stratum part. The UE container is sent transparently via the the target AMF 709, the source AMF 708, and the source RAN 704 to the UE 702. The information provided to the source RAN 704 also contains a list of PDU session IDs indicating the PDU sessions failed to be setup and the reason (s) for failure. The N2 SM information contains the RAN address and RAN N3 tunnel identifiers for the downlink User Plane for all accepted PDU sessions.

Step 5. The target AMF 709 may select a new SMF for data forwarding (SMF_F 710a) . The target AMF 709 sends N11 message (N2 SM information) to the selected SMF (SMF_F 710a) .

Step 6. The SMF_F 710a sends an N4 Session Create Request (RAN address, tunnel identifiers for downlink User Plane) message to the forwarding UPF (UPF_F 712a) .

Step 7. The UPF_F 712a allocates tunnel information for each accepted PDU session and returns an N4 Session Create Response (UPF address, Tunnel identifiers for forwarding data) message to the SMF_F 712a.

Step 8. The SMF_F 712a sends an N11 message Ack (N2 SM information for forwarding data) to the target AMF 709. The N2 SM information contains the UPF address of the forwarding UPF (UPF_F 712a) and Tunnel identifiers for forwarding data.

Step 9. The target AMF 709 sends a Forward Relocation Response (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information for forwarding data) to the source AMF 708.

Step 10. The source AMF 708 sends a Handover Command (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information for forwarding data) to the source RAN. The Target to Source transparent container is forwarded as received from the target AMF 709. The N2 SM information contains the UPF address of the forwarding UPF_F 712a and Tunnel identifiers for forwarding data. The source AMF 708 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s) .

Step 11. The source RAN 704 sends Handover Command (UE container) to the UE 702. The UE container is sent transparently from the target RAN 706 via the AMFs (target AMF and source AMF) to the source RAN 704 and is provided to the UE 702 by the source RAN 704.

Step 12. The UE 702 sends a Handover Confirm to the target RAN 706. After the UE 702 has successfully synchronized to the target cell, it sends a Handover Confirm message to the target RAN. The UE 702 indicates success by the Handover Confirm message.

Step 13. The Target RAN 706 sends an N2 Path Switch Request message to the target AMF 709 to inform the target AMF 709 that the UE 702 has moved to a new target cell. This message includes the N2 SM information containing the RAN address and RAN N3 tunnel identifiers for the downlink User Plane for all accepted PDU sessions. This message also includes PDU sessions failed to be setup list. The target AMF 709 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s) .

Step 14. The target AMF 709 sends N2 SM information by using an N11 Message to each SMF associated with the list of PDU Sessions received in the N2 Path Switch Request. For the PDU Sessions to be switched to the Target RAN 706, each of these SMFs, upon receipt of the N11 Message, determines whether the existing UPF (i.e., the UPF that each SMF works with) can continue to serve the UE 702.

Step 15. For PDU Sessions requested by the Target RAN 706, the SMF 710 sends an N4 Session Modification Request (RAN address, tunnel identifiers for downlink User Plane) message to the UPF 712.

Step 16. The UPF 712 returns an N4 Session Modification Response (Tunnel identifiers for uplink traffic) message to the SMF 710 after requested PDU Sessions are switched.

From now on, the downlink data is sent to the target RAN 706 from the UPF 712.

Step 17. The SMF 710 sends an N11 Message Ack (CN Tunnel Information) to the target AMF 709 for PDU Sessions that have been switched successfully.

Step 18. Once the N11 Message Response is received from all the SMFs, the target AMF 709 aggregates received CN Tunnel Information from these responses and sends this aggregated information as a part of N2 SM Information in the N2 Path Switch Request Ack to the Target RAN 706. If none of the requested PDP Sessions have been switched successfully, the target AMF 709 sends an N2 Path Switch Request Failure message to the Target RAN 706.

Step 19. The target AMF 709 sends a Handover Complete to the source AMF 708.

Step 20. The source AMF 708 sends a Release Resources message to the Source RAN 704. The source AMF 708 then triggers the release of resources with the Source RAN 704.

According to an embodiment, an inter NG RAN intra AMF handover with UPF relocation occurs as shown in FIG. 8, which depicts a UE 802, a source RAN 804, a target RAN 806, an AMF 808, an SMF 810, a forwarding SMF 810a, a source UPF 812, a forwarding UPF 812a, a target UPF 814, and a PDU session anchor UPF 816. This procedure may be used to hand over a UE from a Source RAN to a Target RAN when the AMF is unchanged and the SMF determines that the Source UPF is to be relocated.

Step 1. The source RAN 804 decides to perform N2 based handover because no Xn reference point is present between the source RAN 804 and the target RAN 806. The source RAN 804 sends an N2 Handover Required (Source to Target transparent container, target ID, N2 SM information) to the AMF 808. The N2 SM info includes information regarding all QoS flows of PDU sessions to be handed over.

Step 2. The AMF 808 sends Handover Request (Source to Target transparent container, N2 MM information, N2 SM information) to the target RAN 806. The AMF 808 determines the target RAN 806 based on the Target ID. The Source to Target transparent container and N2 SM information are forwarded to the target RAN 806 as received from the source RAN 804. The MM N2 information includes, e.g., security information and a Handover Restriction List.

Step 3. The Target RAN 806 sends a Handover Request Acknowledge (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information) to the AMF 808. The Target to Source transparent container includes a UE container with an access stratum part. The UE container is sent transparently via the AMF 808 to the UE 802. The information provided to the source RAN 804 also contains a list of PDU session IDs indicating the PDU sessions failed to be setup and the reason (s) for failure. The AMF 808 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s) . The N2 SM information contains the RAN address and RAN N3 tunnel identifiers for the downlink User Plane for all accepted PDU sessions.

Step 4. The AMF 808 may select a new SMF for data forwarding. The AMF 808 sends an N11 message (N2 SM information) to the selected SMF (SMF_F 810a) .

Step 5. The SMF_F 810a selects UPF_F 812a and sends an N4 Session Create Request (RAN address, tunnel identifiers for downlink User Plane) message to the UPF_F 812a.

Step 6. The UPF_F 812a allocates tunnel information for each accepted PDU session and returns an N4 Session Create Response (UPF address, Tunnel identifiers for forwarding data) message to the SMF_F 810a.

Step 7. The SMF_F 810a sends an N11 message (N2 SM information for forwarding data) to the AMF. The N2 SM information contains the UPF address and Tunnel identifiers (of the UPF_F 812a) for forwarding data.

Step 8. The AMF 808 sends a Handover Command (Target to Source transparent container, PDU sessions failed to be setup list, N2 SM information for forwarding data) to the source RAN 804. The Target to Source transparent container is forwarded as received from the AMF. The source RAN 804 uses the PDU sessions failed to be setup list and the indicated reason for failure to decide whether to proceed with the N2 Handover procedure. The N2 SM information for forwarding data contains the UPF address and Tunnel identifiers of the UPF_F 812a for forwarding data.

Step 9. The source RAN 804 sends a Handover Command (UE container) to the UE 802. UE container is sent transparently from the target RAN 806 via the AMF 808 to the source RAN 804 and is provided to the UE 502 by the source RAN 804.

Step 10. The UE 802 sends a Handover Confirm to the target RAN 806. After the UE 802 has successfully synchronized to the target cell, it sends a Handover Confirm message to the target RAN 806. Handover is by this message considered as successful by the UE 802.

Step 11. The Target RAN 806 sends an N2 Path Switch Request message to AMF 808 to inform the AMF that the UE has moved to a new target cell. This message includes the N2 SM information containing the RAN address and RAN N3 tunnel identifiers for the downlink User Plane for all accepted PDU sessions. This message also includes PDU sessions failed to be setup list. The AMF 808 sends separate request (s) to the relevant SMF (s) to deactivate the failed PDU session (s) .

Step 12. The AMF 808 sends N2 SM information by using an N11 Message to each SMF associated with the list of PDU Sessions received in the N2 Path Switch Request.

Step 13. For the PDU Sessions to be switched to the Target RAN 806, upon receipt of the N11 Message, the SMF 810 (for at least one PDU session) determines that the existing UPF cannot continue to serve the UE 802. The SMF 810 then selects a new Target UPF 814 and sends an N4 Session Create Request (Target RAN address, uplink and downlink tunnel identifiers) message to the Target UPF 814.

Step 14. The Target UPF 814 sends an N4 Session Create Response message to the SMF 810. The SMF 810 starts a timer, which is used in Step 20.

Step 15. The SMF 810 sends an N4 Session Modification message to the PDU session anchor UPF 816.

Step 16. The PDU session anchor UPF 816 responds with an N4 Session Modification Response message. At this point, the PDU session anchor UPF 816 starts sending downlink packets to the Target RAN 806 using the address and tunnel identifiers of the Target RAN 806 via the Target UPF 814.

Step 17. The SMF 810 sends an N11 Message Ack (CN Tunnel Information) to the AMF 808 for PDU Sessions that have been switched successfully.

Step 18. Once the N11 Message Response is received from all the SMFs, the AMF 808 aggregates received CN Tunnel Information from these responses and sends this aggregated information as a part of N2 SM Information in N2 Path Switch Request Ack to the Target RAN 806. If none of the requested PDP Sessions have been switched successfully, the AMF 808 sends an N2 Path Switch Request Failure message to the Target RAN 806.

Step 19. The AMF 808 sends Release Resources message to the Source RAN 804. It then triggers the release of resources with the Source RAN 804.

Step 20. When the timer in step 14 expires, the SMF 810 sends an N4 Session Termination Request to the source UPF 812.

Step 21. The source UPF sends an N4 Session Termination Response to the SMF.

It should be understood that the embodiments described herein should be considered in a descriptive sense only and not for purposes of limitation. Descriptions of features or aspects within each embodiment should typically be considered as available for other similar features or aspects in other embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from their spirit and scope. For example, the steps of the methods described here could be reordered in ways that will be apparent to those of skill in the art.

Claims

A method for conducting a handover of a user equipment engaged in one or more protocol data unit sessions, the method comprising:

receiving a handover required message from a source radio access network；

selecting a session management function to manage the forwarding of protocol data units of the one or more protocol data unit sessions from the source radio access network to a target radio access network,

receiving a path switch message from the target radio access network； and

triggering the session management function to switch the data path of the one or more protocol data unit sessions from the source radio access network to the target radio access network.
The method of claim 1, wherein the handover required message comprises information regarding the radio resources and quality of service flows for the one or more protocol data unit sessions.
The method of claim 1, further comprising:

transmitting, to the target radio access network, a handover request message； and

receiving, from the target radio access network, a handover request acknowledge message.
The method of claim 3, wherein the handover request acknowledge message comprises session management information, the method further comprising:

sending session management information to the session management function for forwarding protocol data units.
The method of claim 4, wherein the session management information comprises the radio access network address and tunnel information of the radio access network.
The method of claim 4, wherein:

the session management information includes a list of protocol data unit sessions that the target radio access network failed to setup.
The method of claim 6, further comprising:

sending request to the session management function to deactivate the protocol data unit sessions that the target radio access network failed to setup.
The method of claim 1, further comprising transmitting a handover command to the source radio access network.
The method of claim 8, wherein the handover command comprises the session management information received from the target radio access network.
A computing device that conducts a handover of a user equipment engaged in one or more protocol data unit sessions, wherein the first computing device operates within a telecommunications core network and carries out steps comprising:

receiving a handover required message from a source radio access network；

selecting a session management function to manage the forwarding of protocol data units of the one or more protocol data unit sessions from the source radio access network to a target radio access network,

receiving a path switch message from a target radio access network； and

triggering the session management function to switch the data path of the one or more protocol data unit sessions from the source radio access network to the target radio access network.
The computing device of claim 10, wherein the handover required message comprises information regarding the radio resources and the quality of service flow for the one or more protocol data unit sessions.
The computing device of claim 10, wherein the computing device performs further steps comprising:

transmitting, to the target radio access network, a handover request message； and

receiving, from the target radio access network, a handover request acknowledge message.
The computing device of claim 10, wherein the computing device performs further steps comprising the first computing device transmitting a handover command to the source radio access network.
The computing device of claim 10, wherein the handover request acknowledge message comprises session management information, the method further comprising:

sending session management information to the session management function for forwarding protocol data units.
The computing device of claim 14, wherein the session management information comprises the radio access network address and tunnel information of the radio access network.
The computing device of claim 14, wherein:

the session management information includes a list of protocol data unit sessions that the target radio access network failed to setup.
The computing device of claim 16, wherein the computing device performs further steps comprising:

sending request to the session management function to deactivate the protocol data unit sessions that the target radio access network failed to setup.
The computing device of claim 16, wherein the computing device performs further steps comprising transmitting a handover command to the source radio access network.
The computing device of claim 18, wherein the handover command comprises the session management information received from the target radio access network.
A method for receiving a handover of a user equipment from a source radio access network to a target radio access network, wherein engaged in one or more protocol data unit sessions, the method comprising:

receiving a handover request message from an access management function；

transmitting a handover request acknowledgement to the access management function；

receiving handover confirm from user equipment； and

transmitting a path switch message to the access management function to trigger a path switch of the one or more protocol data unit sessions to the target radio access network.
The method of claim 20, wherein the handover request acknowledgement includes a container that is transparent to the access management function.
The method of claim 21, wherein the container includes a user equipment container with an access stratum part.
The method of claim 20, wherein the handover request acknowledgement includes a list of protocol data units that were failed to be setup.
The method of claim 20, wherein the handover request acknowledgement contains session management information, including the RAN address and tunnel identifiers for all accepted protocol data unit sessions.
A computing device configured to carry out the method of any one of claims 1 through 9 and 20 through 24.
A non-transitory computer-readable medium having stored thereon computer-executable instructions for carrying out the method of any one of claims 1 through 9 and 20 through 24.