Seamless handover of protocol data unit sessions

Abstract

Embodiments of the present disclosure relate to seamless handover of protocol data unit sessions. A device may receive a handover request to handover a protocol data unit (PDU) session of a network device from a radio access network (RAN) to the device, and may provide a handover request acknowledgement message to the RAN that acknowledges receipt of the handover request. The device may receive, from the RAN, a sequence number status transmission indicating that a handover command is provided by the RAN to the network device, and may receive, from the RAN, an uplink data packet and a downlink data packet associated with the PDU session. The device may receive a request from a network device to establish a PDU session, and may establish the PDU session for the network device based on the request to establish the PDU session.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application Ser. No. 63 / 616,387, filed Dec. 29, 2023, entitled "SEAMLESS HANDOVER OF A PROTOCOL DATA UNIT SESSION", and assigned to its assignee. The disclosure of the prior application is considered part of this patent application and is hereby incorporated by reference in its entirety. BACKGROUND OF THE INVENTION

[0003] A network device, such as a dual access fifth generation (5G) residential gateway, may support wireless access to a data network via a radio access network (RAN) and may support wired access to the data network via an access gateway function (AGF). SUMMARY OF THE INVENTION

[0004] Some implementations described herein relate to a method. The method may include receiving a handover request to handover a protocol data unit (PDU) session of a network device from a radio access network (RAN) to the device and providing a handover request confirmation message to the RAN confirming receipt of the handover request. The method may include receiving from the RAN a sequence number status transfer indicating that the RAN provides a handover command to the network device, and receiving from the RAN uplink data packets and downlink data packets associated with the PDU session. The method may include receiving from the network device a request to establish a PDU session and establishing the PDU session of the network device based on the request to establish the PDU session.

[0005] In some implementations according to the present disclosure that relate to a method, further comprising: receiving a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the RAN to the device is complete.

[0006] In some implementations according to the present disclosure that relate to a method, further comprising: providing the downlink data packets associated with the PDU session to the network device.

[0007] In some implementations according to the present disclosure that relate to a method, further comprising: providing the uplink data packets associated with the PDU session to a user plane function.

[0008] In some implementations according to the present disclosure that relate to a method, further comprising: enabling exchange of additional uplink data packets and additional downlink data packets associated with the PDU session between the network device and a data network via the device based on establishing the PDU session.

[0009] In some implementations according to the present disclosure that relate to a method, the network device is a dual access residential gateway, and the device is an access gateway function.

[0010] In some implementations according to the present disclosure that relate to a method, the RAN generates the handover request based on a measurement report received from the network device and a handover decision generated based on the measurement report.

[0011] Some implementations described herein relate to a first device. The first device may include one or more memories and one or more processors. The one or more processors may be configured to receive a handover request for switching a PDU session of a network device from a second device to the first device, and provide a handover request confirmation message indicating receipt of the handover request to the second device. The one or more processors may be configured to receive from the second device a sequence number status transmission indicating that the second device provides a handover command to the network device, and receive uplink data packets and downlink data packets associated with the PDU session from the second device. The one or more processors may be configured to receive a request for establishing a PDU session from the network device, and establish the PDU session of the network device based on the request for establishing the PDU session.

[0012] In some implementations according to the present disclosure that relate to the first device, the one or more processors are further configured to: receive a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the second device to the first device is complete; based on receiving the handover completion message, provide the downlink data packets associated with the PDU session to the network device; and based on receiving the handover completion message, provide the uplink data packets associated with the PDU session to a user plane function.

[0013] In some implementations according to the present disclosure that relate to the first device, the one or more processors are further configured to: based on establishing the PDU session, enable additional uplink data packets and additional downlink data packets associated with the PDU session to be exchanged between the network device and a data network via the first device.

[0014] In some implementations according to the present disclosure that relate to the first device, the handover request is triggered by the network device.

[0015] In some implementations according to the present disclosure that relate to the first device, the handover request is triggered by the second device.

[0016] In some implementations according to the present disclosure that relate to a first device, the network device is a dual access residential gateway, the first device is a backup access gateway function, and the second device is an active access gateway function.

[0017] In some implementations according to the present disclosure that relate to a first device, the second device generates the handover request based on a handover decision.

[0018] Some implementations described herein relate to a non-transitory computer-readable medium storing an instruction set. When the instruction set is executed by one or more processors of the first device, the first device can be caused to receive a handover request for switching a PDU session of the network device from the second device to the first device, and provide a handover request confirmation message acknowledging the receipt of the handover request to the second device. When the instruction set is executed by one or more processors of the first device, the first device can be caused to receive from the second device a sequence number status transfer indicating that the second device provides a handover command to the network device, and receive an uplink data packet and a downlink data packet associated with the PDU session from the second device. When the instruction set is executed by one or more processors of the first device, the first device can be caused to receive from the network device a request for establishing a PDU session, and establish the PDU session of the network device based on the request for establishing the PDU session. When the instruction set is executed by one or more processors of the first device, the first device can be caused to receive a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the second device to the first device is completed, and provide a downlink data packet associated with the PDU session to the network device based on receiving the handover completion message. When the instruction set is executed by one or more processors of the first device, the first device can be caused to provide an uplink data packet associated with the PDU session to a user plane function based on receiving the handover completion message.

[0019] In some implementations according to the present disclosure that relate to a non-transitory computer-readable medium storing an instruction set, one or more instructions further cause the first device to: based on establishing the PDU session, via the first device, enable an additional uplink data packet and an additional downlink data packet associated with the PDU session to be exchanged between the network device and a data network.

[0020] In some implementations according to the present disclosure that relate to a non-transitory computer-readable medium storing an instruction set, the handover request is triggered by one of the network device or the second device.

[0021] In some implementations according to the present disclosure that relate to a non-transitory computer-readable medium storing an instruction set, the first device utilizes one of an Xn application protocol or a next generation application protocol.

[0022] In some implementations of non - transient computer - readable media storing instruction sets according to the present disclosure, the network device is a dual - access residential gateway, the first device is a backup access gateway function, and the second device is an active access gateway function.

[0023] In some implementations of non - transient computer - readable media storing instruction sets according to the present disclosure, the second device generates the handover request based on a handover decision. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figures 1A - 1M is a diagram of an example associated with providing seamless handover of a protocol data unit (PDU) session between a wireless network and a wired network.

[0025] Figure 2 is a diagram of an example environment in which the systems and / or methods described herein can be implemented.

[0026] Figure 3 and 4 is Figure 2 a diagram of example components of one or more devices.

[0027] Figure 5 is a flowchart of an example process for providing seamless handover of a PDU session between a wireless network and a wired network. DETAILED DESCRIPTION

[0028] The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

[0029] A PDU session established via wireless access (e.g., via a RAN) can move to wired access (e.g., via an AGF) only by releasing and then re - establishing the PDU session, and vice versa. Due to the re - connection, during the transition from one access type to another, the subscriber service associated with the PDU session will be dropped. The assigned subscriber network address (e.g., an Internet Protocol (IP) address) can also change due to the re - connection. The allocated user plane function (UPF) resources can be released and must be re - allocated (e.g., and there is an opportunity to select a new UPF). The current standard provides seamless handover of a PDU session from one RAN to another RAN, but does not provide seamless handover of a PDU session from an AGF to a RAN and from a RAN to an AGF. This causes the network device (e.g., a residential gateway) to re - connect (e.g., with loss of subscriber service), and results in multiple changes in the network.

[0030] Therefore, the current techniques for providing a handover of a PDU session between an AGF and a RAN consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), network resources, and / or other resources associated with the inability to provide seamless handover of the PDU session between the AGF and the RAN, handling lost subscriber traffic based on the inability to provide seamless handover of the PDU session, multiple changes in the network due to the release and re - establishment of the PDU session during handover, etc.

[0031] Some implementations described herein provide a device (e.g., an AGF) that provides seamless handover of a PDU session between a wireless network and a wired network. For example, the device can receive a handover request to switch a protocol data unit (PDU) session of a network device from a radio access network (RAN) to the device, and can provide a handover request confirmation message to the RAN confirming receipt of the handover request. The device can receive from the RAN a sequence number status transfer indicating that the RAN provides a handover command to the network device, and can receive uplink data packets and downlink data packets associated with the PDU session from the RAN. The device can receive a request to establish a PDU session from the network device, and can establish the PDU session of the network device based on the request to establish the PDU session.

[0032] In this way, the AGF provides seamless handover of the PDU session between the wireless network and the wired network. For example, seamless handover of the PDU session between wireless access (e.g., RAN) and wired access (e.g., AGF) can be provided. The AGF can support protocols (e.g., Xn Application Protocol (XnAP) or Next Generation Application Protocol (NGAP) specific to Session and Service Continuity (SSC) mode 3) that enable handover of the PDU session from the RAN to the AGF and from the AGF to the RAN. The AGF can utilize additional messages (e.g., handover request, handover command, handover complete, etc.) so that a network device (e.g., a residential gateway) can communicate with the AGF during the handover procedure. The AGF can include buffering and support for end - marker packets (e.g., the last packet to be transmitted during handover) to provide lossless handover. Therefore, the AGF can save computing resources, network resources, and / or other resources that may be consumed by the inability to provide seamless handover of the PDU session between the AGF and the RAN, handling lost subscriber traffic based on the inability to provide seamless handover of the PDU session, multiple changes in the network due to the release and re - establishment of the PDU session during handover, etc.

[0033] Figures 1A - 1M FIG. 100 is a diagram of Example 100 associated with providing seamless handover of a PDU session between a wireless network and a wired network. As shown in Figures 1A - 1MAs shown in, Example 100 includes a network device, a radio access network (RAN), a data network, and a core network including an access gateway function, an access and mobility management function (AMF), and a user plane function (UPF). Further details of the network device, RAN, core network, AGF, AMF, UPF, and data network are provided elsewhere in this document.

[0034] As in Figure 1A shown, the network device can communicate with the core network using the RAN and further communicate with the data network via the core network. Although a single network device, RAN, core network, AGF, AMF, UPF, and data network are described in Figure 1A , in some implementations, more than one network device, RAN, core network, AGF, AMF, UPF, and data network can be provided. Additionally, although the implementation is described in relation to a fifth generation (5G) core network, the implementation can be utilized with other types of core networks, such as a fourth generation (4G) core network.

[0035] Figure 1B and Figure 1C describe a message flow diagram associated with utilizing XnAP for lossless handover from a wireless network to a wired network. As shown at step 1 in Figure 1B , the RAN and AGF can execute an XnAP setup procedure to enable the utilization of XnAP for the message flow. As shown at step 2, the network device (ND) can interact with the RAN and AMF to perform wireless network device registration and wireless PDU session setup for the network device. For example, the network device can register a wireless PDU session via the RAN and AMF. The RAN and AMF can register the network device and can establish a wireless PDU session for the network device. As shown at step 3, the network device can interact with the AGF and AMF to perform wired network device registration.

[0036] As in Figure 1B step 4 shown, the network device can exchange uplink (UL) and downlink (DL) data packets with the data network. For example, once the wireless PDU session is established, the network device can exchange UL and DL data packets with the data network. As shown at step 5, the network device can provide a measurement report to the RAN. The measurement report can include information indicating the state of the wireless PDU session (e.g., degraded state, good state, excellent state, etc.). As shown at step 6, the RAN can make a handover decision for the network device based on the measurement report. For example, if the measurement report indicates that the wireless PDU session is degraded, the handover decision can be to hand over the wireless PDU session to the wired network. In another example, if the measurement report indicates that the wireless PDU session is not degraded, the handover decision can be to maintain the wireless PDU session.

[0037] As shown at step 7 in Figure 1B , the RAN may provide an XnAP handover request to the AGF. For example, the RAN may generate an XnAP handover request based on determining that a wireless PDU session is to be handed over to a wired network (e.g., a handover decision). The XnAP handover request may include a request to hand over the wireless PDU session to the wired network (e.g., to the AGF). As shown at step 8, the AGF may provide an XnAP handover request acknowledgement (Ack) to the RAN. For example, if the AGF agrees to accept the XnAP handover request from the RAN, the AGF may generate an XnAP handover request acknowledgement. The XnAP handover request acknowledgement may indicate that the AGF will accept the handover of the wireless PDU session to the AGF. As shown at step 9, the RAN may provide a handover command to the network device. For example, when the RAN receives the XnAP handover request acknowledgement, the RAN may generate a handover command. The handover command may include information indicating that the network device is to hand over the wireless PDU session to the AGF. As shown at step 10, the RAN may provide an XnAP sequence number (SN) status transfer message to the AGF. The XnAP SM status transfer message may include information indicating the status of the transmission of the wireless PDU session from the RAN. As shown at step 11, the RAN may provide UL and DL data packets associated with the wireless PDU session to the AGF. The UL and DL data packets may include UL data packets that have not been received by the data network and DL data packets that have not been received by the network device.

[0038] As shown at Figure 1C step 12 in

[0039] As shown at Figure 1CAs shown at step 16, the AMF can provide an NGAP path switch request confirmation to the AGF. The NGAP path switch request confirmation can indicate that the AMF has approved the request to switch the path of the PDU session from wireless to wired. As shown at step 17, the AGF can provide an UL data packet (e.g., received from the RAN but not yet received by the data network) to the UPF. As shown at step 18, the AGF can provide an XnAP context release message to the RAN. The XnAP context release message can indicate that the RAN can release the context associated with the wireless PDU session. As shown at step 19, the network device can exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device can exchange UL and DL data packets with the data network.

[0040] Figure 1D and 1E Describes the message flow diagram associated with the use of XnAP for wired lossless handover when triggered by a network device. As shown at step 1 of FIG. 1, the active AGF and the backup AGF can perform an XnAP setup procedure to enable the use of XnAP for the message flow. As shown at step 2, the network device can interact with the active AGF and the AMF to perform wired network device registration and wired PDU session setup for the network device. For example, the network device can register a wired PDU session via the active AGF and the AMF. The active AGF and the AMF can register the network device and can establish a wired PDU session for the network device. As shown at step 3, the network device can exchange uplink (UL) and downlink (DL) data packets with the data network. For example, once the wired PDU session is established, the network device can exchange UL and DL data packets with the data network. As shown at step 4, the network device can provide a handover request to the active AGF. The handover request can include a request to switch the wired PDU session from the active AGF to the backup AGF. As shown at step 5, the active AGF can make a handover decision for the network device based on the handover request. For example, the handover decision may be to switch the wired PDU session from the active AGF to the backup AGF.

[0041] As shown in Figure 1DAs shown at step 6, the active AGF can provide an XnAP handover request to the backup AGF. For example, the active AGF can generate an XnAP handover request based on determining that a wired PDU session is to be handed over to the backup AGF (e.g., handover decision). The XnAP handover request can include a request to switch the wired PDU session from the active AGF to the backup AGF. As shown at step 7, the backup AGF can provide an XnAP handover request acknowledgement (Ack) to the active AGF. For example, if the backup AGF agrees to accept the XnAP handover request from the active AGF, the backup AGF can generate an XnAP handover request acknowledgement. The XnAP handover request acknowledgement can indicate that the backup AGF will accept the handover of the wired PDU session to the backup AGF. As shown at step 8, the active AGF can provide a handover command to the network device. For example, when the active AGF receives the XnAP handover request acknowledgement, the active AGF can generate a handover command. The handover command can include information indicating the network device to switch the wired PDU session to the backup AGF. As shown at step 9, the active AGF can provide an XnAP sequence number (SN) status transfer message to the backup AGF. The XnAP SM status transfer message can include information indicating the transfer status of the wired PDU session from the active AGF. As shown at step 10, the active AGF can provide UL and DL data packets associated with the wired PDU session to the backup AGF. The UL and DL data packets can include UL data packets not yet received by the data network and DL data packets not yet received by the network device.

[0042] As shown at Figure 1E As shown at step 11, the network device can interact with the backup AGF to perform wired PDU session setup for the network device. For example, the network device can request the establishment of a wired PDU session from the backup AGF, and the backup AGF can establish the wired PDU session based on the request. As shown at step 12, the network device can provide a handover completion message to the backup AGF. The handover completion message can indicate that the handover of the wired PDU session is complete. As shown at step 13, the backup AGF can provide DL data packets (e.g., received from the active AGF but not yet received by the network device) to the network device. As shown at step 14, the backup AGF can provide an NGAP path exchange request to the AMF. The NGAP path exchange request can include a request to exchange the path of the PDU session from the active AGF to the backup AGF.

[0043] As shown at Figure 1EAs shown at step 15, the AMF may provide an NGAP path exchange request confirmation to the backup AGF. The NGAP path exchange request confirmation may indicate that the AMF has approved the request to switch the path of the PDU session from the active AGF to the backup AGF. As shown at step 16, the backup AGF may provide an UL data packet (e.g., received from the active AGF but not yet received by the data network) to the UPF. As shown at step 17, the backup AGF may provide an XnAP context release message to the active AGF. The XnAP context release message may indicate that the active AGF may release the context associated with the wired PDU session. As shown at step 18, the network device may exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device may exchange UL and DL data packets with the data network.

[0044] Figure 1F and Figure 1G describes a message flow diagram associated with XnAP for wired lossless handover when triggered by the AGF. As shown in Figure 1F step 1, the active AGF and the backup AGF may execute an XnAP setup procedure to enable the utilization of XnAP for the message flow. As shown at step 2, the network device may interact with the active AGF and the AMF to perform wired network device registration and wired PDU session setup for the network device. For example, the network device may register a wired PDU session via the active AGF and the AMF. The active AGF and the AMF may register the network device and may establish a wired PDU session for the network device. As shown at step 3, the network device may exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device may exchange UL and DL data packets with the data network. As shown at step 4, the active AGF may make a handover decision for the network device. For example, the handover decision may be to switch the wired PDU session from the active AGF to the backup AGF.

[0045] As shown in Figure 1FAs shown at step 5, the active AGF can provide an XnAP handover request to the backup AGF. For example, the active AGF can generate an XnAP handover request based on determining that a wired PDU session is to be handed over to the backup AGF (e.g., handover decision). The XnAP handover request can include a request to switch the wired PDU session from the active AGF to the backup AGF. As shown at step 6, the backup AGF can provide an XnAP handover request acknowledgement (Ack) to the active AGF. For example, if the backup AGF agrees to accept the XnAP handover request from the active AGF, the backup AGF can generate an XnAP handover request acknowledgement. The XnAP handover request acknowledgement can indicate that the backup AGF will accept the handover of the wired PDU session to the backup AGF. As shown at step 7, the active AGF can provide a handover command to the network device. For example, when the active AGF receives the XnAP handover request acknowledgement, the active AGF can generate a handover command. The handover command can include information indicating the network device to switch the wired PDU session to the backup AGF. As shown at step 8, the active AGF can provide an XnAP SN status transfer message to the backup AGF. The XnAP SM status transfer message can include information indicating the transfer status of the wired PDU session from the active AGF. As shown at step 9, the active AGF can provide UL and DL data packets associated with the wired PDU session to the backup AGF. The UL and DL data packets can include UL data packets not yet received by the data network and DL data packets not yet received by the network device.

[0046] As shown at Figure 1G step 10, the network device can interact with the backup AGF to perform wired PDU session setup for the network device. For example, the network device can request the establishment of a wired PDU session from the backup AGF, and the backup AGF can establish the wired PDU session based on the request. As shown at step 11, the network device can provide a handover completion message to the backup AGF. The handover completion message can indicate that the handover of the wired PDU session is complete. As shown at step 12, the backup AGF can provide DL data packets (e.g., received from the active AGF but not yet received by the network device) to the network device. As shown at step 13, the backup AGF can provide an NGAP path exchange request to the AMF. The NGAP path exchange request can include a request to exchange the path of the PDU session from the active AGF to the backup AGF.

[0047] As shown at Figure 1GAs shown in step 14, the AMF may provide a NGAP path exchange request confirmation to the backup AGF. The NGAP path exchange request confirmation may indicate that the AMF has approved the request to switch the path of the PDU session from the active AGF to the backup AGF. As shown in step 15, the backup AGF may provide UL data packets (e.g., received from the active AGF but not yet received by the data network) to the UPF. As shown in step 16, the backup AGF may provide an XnAP context release message to the active AGF. The XnAP context release message may indicate that the active AGF may release the context associated with the wired PDU session. As shown in step 17, the network device may exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device may exchange UL and DL data packets with the data network.

[0048] Figure 1H and Figure 1I describes a message flow diagram associated with using NGAP for lossless handover from a wireless network to a wired network. As shown in Figure 1H step 1, a network device (ND) may interact with the RAN and the AMF to perform wireless network device registration and wireless PDU session setup for the network device. For example, the network device may register a wireless PDU session via the RAN and the AMF. The RAN and the AMF may register the network device and may establish a wireless PDU session for the network device. As shown in step 2, the network device may interact with the AGF and the AMF to perform wired network device registration. As shown in step 3, the network device may exchange UL and DL data packets with the data network. For example, once the wireless PDU session is established, the network device may exchange UL and DL data packets with the data network.

[0049] As shown in Figure 1H step 4, the network device may provide a measurement report to the RAN. The measurement report may include information indicating the status of the wireless PDU session (e.g., degraded status, good status, excellent status, etc.). As shown in step 5, the RAN may make a handover decision for the network device based on the measurement report. For example, if the measurement report indicates that the wireless PDU session is degraded, the handover decision may be to hand over the wireless PDU session to the wired network. In another example, if the measurement report indicates that the wireless PDU session is not degraded, the handover decision may be to maintain the wireless PDU session.

[0050] As shown in Figure 1HAs shown at step 6, the RAN may provide a message requiring an NGAP handover to the AMF. For example, the RAN may generate a message requiring an NGAP handover based on determining that a wireless PDU session is to be handed over to a wired network (e.g., a handover decision). As shown at step 7, the AMF may provide an NGAP handover request to the AGF. For example, the AMF may generate an NGAP handover request based on receiving a message requiring an NGAP handover from the RAN. The NGAP handover request may include a request to hand over the wireless PDU session to a wired network (e.g., to the AGF). As shown at step 8, the AGF may perform a handover permission process to determine whether to hand over the wireless PDU session to a wired network. As shown at step 9, if the AGF determines to hand over the wireless PDU session to a wired network (e.g., during the handover permission process), the AGF may provide a handover command to the RAN. The handover command may include information instructing the RAN to hand over the wireless PDU session to the AGF.

[0051] As shown at Figure 1H step 10, the RAN may provide a handover command to a network device. For example, when the RAN receives a handover command from the AGF, the RAN may generate a handover command or may utilize the handover command generated by the AGF. The handover command may include information instructing the network device to hand over the wireless PDU session to the AGF. As shown at step 11, the RAN may provide an XnAP sequence number (SN) status transfer message to the AGF. The XnAP SN status transfer message may include information indicating the transfer status of the wireless PDU session from the RAN. As shown at step 11, the RAN may provide UL and DL data packets associated with the wireless PDU session to the AGF. The UL and DL data packets may include UL data packets not yet received by the data network and DL data packets not yet received by the network device.

[0052] As shown at Figure 1I step 14, the network device may interact with the AGF to perform a wired PDU session setup for the network device. For example, the network device may request the establishment of a wired PDU session from the AGF, and the AGF may establish a wired PDU session based on the request. As shown at step 15, the network device may provide a handover completion message to the AGF. The handover completion message may indicate that the handover of the wireless PDU session to the wired PDU session is complete. As shown at step 16, the AGF may provide an NGAP handover notification message to the AMF. The NGAP notification message may notify the AMF that the handover of the wireless PDU session to the wired PDU session is complete.

[0053] As shown at Figure 1IAs shown at step 17, the AGF may provide DL data packets (e.g., received from the RAN but not yet received by the network device) to the network device. As shown at step 18, the AGF may provide UL data packets (e.g., received from the RAN but not yet received by the data network) to the UPF. As shown at step 19, the network device may exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device may exchange UL and DL data packets with the data network. As shown at step 20, the AMF may provide an NGAP context release command to the RAN. The NGAP context release command may instruct the RAN to release the context associated with the wireless PDU session. As shown at step 21, the RAN may provide an NGAP context release complete message to the AMF. The NGAP context release complete message may indicate that the RAN has released the context associated with the wireless PDU session.

[0054] Figure 1J and Figure 1K describes the message flow diagram associated with NGAP for wired lossless handover when triggered by the network device. As shown at Figure 1J step 1, the network device may interact with the active AGF and AMF to perform wired network device registration and wired PDU session setup for the network device. For example, the network device may register a wired PDU session via the active AGF and AMF. The active AGF and AMF may register the network device and may establish a wired PDU session for the network device. As shown at step 2, the network device may exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device may exchange UL and DL data packets with the data network. As shown at step 3, the network device may provide a handover request to the active AGF. The handover request may include a request to switch the wired PDU session from the active AGF to the backup AGF. As shown at step 4, the active AGF may make a handover decision for the network device based on the handover request. For example, the handover decision may be to switch the wired PDU session from the active AGF to the backup AGF.

[0055] As shown at Figure 1JAs shown at step 5, the active AGF can provide a message that requires an NGAP handover to the backup AMF. For example, the active AGF can generate a message that requires an NGAP handover based on determining that a wired PDU session is to be handed over from the active AGF to the backup AGF (e.g., handover decision). As shown at step 6, the AMF can provide an NGAP handover request to the backup AGF. For example, the AMF can generate an NGAP handover request based on receiving a message that requires an NGAP handover from the active AGF. The NGAP handover request can include a request to hand over the wired PDU session from the active AGF to the backup AGF. As shown at step 7, the backup AGF can perform a handover permission process to determine whether to hand over the wired PDU session from the active AGF to the backup AGF. As shown at step 8, if the backup AGF determines to hand over the wired PDU session from the active AGF to the backup AGF (e.g., during the handover permission process), the backup AGF can provide a handover command to the active AGF. The handover command can include information indicating the active AGF to hand over the wired PDU session from the active AGF to the backup AGF.

[0056] As shown at Figure 1H step 9, the active AGF can provide a handover command to the network device. For example, when the active AGF receives a handover command from the backup AGF, the active AGF can generate a handover command or can utilize the handover command generated by the backup AGF. The handover command can include information indicating the network device to hand over the wired PDU session from the active AGF to the backup AGF. As shown at step 10, the active AGF can provide an UL RAN status transfer message to the AMF. The UL RAN status transfer message can include information indicating the status of the transfer of UL data of the wired PDU session from the active AGF to the backup AGF. As shown at step 11, the AMF can provide a DL RAN status transfer message to the backup AGF. The DL RAN status transfer message can include information indicating the status of the transfer of DL data of the wired PDU session from the active AGF to the backup AGF. As shown at step 12, the active AGF can provide UL and DL data packets associated with the wireless PDU session to the backup AGF. The UL and DL data packets can include UL data packets not yet received by the data network and DL data packets not yet received by the network device.

[0057] As shown at Figure 1KAs shown at step 13, the network device can interact with the backup AGF to perform a wired PDU session setup for the network device. For example, the network device can request the establishment of a wired PDU session from the backup AGF, and the backup AGF can establish a wired PDU session based on the request. As shown at step 14, the network device can provide a handover completion message to the backup AGF. The handover completion message can indicate that the handover of the wired PDU session from the active AGF to the backup AGF is complete. As shown at step 15, the backup AGF can provide DL data packets (not yet received by the network device) to the network device. As shown at step 16, the backup AGF can provide an NGAP handover notification message to the AMF. The NGAP notification message can notify the AMF that the handover of the wired PDU session from the active AGF to the backup AGF is complete.

[0058] As shown at Figure 1I As shown at step 17, the AGF can provide UL data packets (e.g., not yet received by the data network) to the UPF. As shown at step 18, the network device can exchange UL and DL data packets with the data network. For example, once a wired PDU session is established with the backup AGF, the network device can exchange UL and DL data packets with the data network. As shown at step 19, the AMF can provide an NGAP context release command to the active AGF. The NGAP context release command can indicate that the active AGF releases the context associated with the wireless PDU session. As shown at step 20, the active AGF can provide an NGAP context release completion message to the AMF. The NGAP context release completion message can indicate that the active AGF has released the context associated with the wired PDU session.

[0059] Figure 1L and 1M describes the message flow diagram associated with NGAP for wired lossless handover when triggered by the AGF. As shown at Figure 1LAs shown at step 1, the active AGF and the backup AGF can execute the NGAP setup procedure to enable the utilization of NGAP for the message flow. As shown at step 2, the network device can interact with the active AGF and the AMF to perform wired network device registration and wired PDU session setup for the network device. For example, the network device can register a wired PDU session via the active AGF and the AMF. The active AGF and the AMF can register the network device and can establish a wired PDU session for the network device. As shown at step 3, the network device can exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device can exchange UL and DL data packets with the data network. As shown at step 4, the active AGF can make a handover decision for the network device. For example, the handover decision may be to hand over the wired PDU session from the active AGF to the backup AGF.

[0060] As shown at Figure 1F As shown at step 5, the active AGF can provide a message that requires NGAP handover to the AMF. For example, the active RAN can generate a message that requires NGAP handover based on determining that the wired PDU session is to be handed over from the active AGF to the backup AGF (e.g., handover decision). As shown at step 6, the AMF can provide a NGAP handover request to the backup AGF. For example, the AMF can generate a NGAP handover request based on receiving a message that requires NGAP handover from the active AGF. The NGAP handover request can include a request to hand over the wired PDU session from the active AGF to the backup AGF. As shown at step 7, the backup AGF can perform a handover permission process to determine whether to hand over the wired PDU session from the active AGF to the backup AGF.

[0061] As shown at step 8, the backup AGF can provide a handover command to the active AGF. For example, the backup AGF can generate a handover command based on a handover permission process that determines to hand over a wired PDU session from the active AGF to the backup AGF. As shown at step 9, the active AGF can provide the handover command to the network device. For example, when the active AGF receives the handover command from the backup AGF, the active AGF can generate the handover command or can forward the handover command to the network device. The handover command can include information indicating the network device to hand over the wired PDU session from the active AGF to the backup AGF. As shown at step 10, the active AGF can provide a UL RAN status transfer message to the AMF. The UL RAN status transfer message can include information indicating the status of the transfer of UL data of the wired PDU session from the active AGF to the backup AGF. As shown at step 11, the AMF can provide a DL RAN status transfer message to the backup AGF. The DL RAN status transfer message can include information indicating the status of the transfer of DL data of the wired PDU session from the active AGF to the backup AGF. As shown at step 12, the active AGF can provide UL and DL data packets associated with the wired PDU session to the backup AGF. The UL and DL data packets can include UL data packets not yet received by the data network and DL data packets not yet received by the network device.

[0062] As shown at Figure 1M step 13 as shown above, the network device can interact with the backup AGF to perform network device registration and wired PDU session setup for the network device. For example, the network device can request the establishment of a wired PDU session from the backup AGF, and the backup AGF can establish the wired PDU session based on the request. As shown at step 14, the network device can provide a handover completion message to the backup AGF. The handover completion message can indicate that the handover of the wired PDU session is completed. As shown at step 15, the backup AGF can provide DL data packets (e.g., received from the active AGF but not yet received by the network device) to the network device. As shown at step 16, the backup AGF can provide an NGAP handover notification message to the AMF. The NGAP handover notification message can include a request for handing over the PDU session from the active AGF to the backup AGF.

[0063] As shown at Figure 1MAs shown at step 16, the backup AGF can provide the UPF with UL data packets (e.g., received from the active AGF but not yet received by the data network). As shown at step 17, the network device can exchange UL and DL data packets with the data network. For example, once the wired PDU session is established, the network device can exchange UL and DL data packets with the data network. As shown at step 18, the AMF can provide the active AGF with an NGAP context release command. The NGAP context release command can instruct the active AGF to release the context associated with the wired PDU session. As shown at step 19, the active AGF can provide the AMF with an NGAP context release complete message. The NGAP context release complete message can indicate that the active AGF has released the context associated with the wired PDU session.

[0064] In this way, the AGF provides seamless handover between the wireless network and the wired network of the PDU session. For example, seamless handover of the PDU session between wireless access (e.g., RAN) and wired access (e.g., AGF) can be provided. The AGF can support protocols (e.g., XnAP or NGAP specific to SSC mode 3) that enable handover of the PDU session from the RAN to the AGF and from the AGF to the RAN. The AGF can utilize additional messages (e.g., handover request, handover command, handover complete, etc.) so that the network device (e.g., residential gateway) can communicate with the AGF during the handover procedure. The AGF can include buffering and support for end marker packets (e.g., the last packet to be transmitted during handover) to provide lossless handover. Thus, the AGF can save computing resources, network resources, and / or other resources that may be consumed by not providing seamless handover of the PDU session between the AGF and the RAN, handling lost subscriber traffic based on the inability to provide seamless handover of the PDU session, multiple changes in the network due to release and re - establishment of the PDU session during handover, etc.

[0065] As shown above, Figures 1A - 1M is provided as an example. Other examples may be different from those regarding Figures 1A - 1M described. The number and arrangement of the devices shown in Figures 1A - 1M are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or devices arranged differently from those shown in Figures 1A - 1M . Additionally, two or more devices shown in Figures 1A - 1M can be implemented within a single device, or a single device shown in Figures 1A - 1M can be implemented as multiple distributed devices. Additionally or alternatively, the set of devices shown in Figures 1A - 1M (e.g., one or more devices) can perform as described by the devices in Figures 1A - 1MOne or more functions performed by another set of devices as shown.

[0066] Figure 2 FIG. is a diagram of an example environment 200 in which the systems and / or methods described herein can be implemented. As shown in Figure 2 FIG., the example environment 200 can include a network device 205, a RAN 210, a core network 215, and a data network 275. The devices and / or networks of the example environment 200 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0067] The network device 205 can include one or more devices capable of receiving, processing, storing, routing, and / or providing traffic (e.g., packets and / or other information or metadata) in the manner described herein. For example, the network device 205 can include routers such as label switching routers (LSRs), label edge routers (LERs), ingress routers, egress routers, provider routers (e.g., provider edge routers or provider core routers), virtual routers, or other types of routers. Additionally or alternatively, the network device 205 can include gateways (e.g., residential gateways), switches, firewalls, hubs, bridges, reverse proxies, servers (e.g., proxy servers, cloud servers, or data center servers), load balancers, and / or similar devices. In some implementations, the network device 205 can be a physical device implemented within an enclosure such as a chassis. In some implementations, the network device 205 can be a virtual device implemented by one or more computing devices of a cloud computing environment or a data center. In some implementations, a group of network devices 205 can be a group of data center nodes used to route traffic over a network.

[0068] For example, the RAN 210 can support a cellular radio access technology (RAT). The RAN 210 can include one or more base stations (e.g., base transceiver stations, wireless base stations, 3G base stations (node B), eNodeBs (eNBs), gNodeBs (gNBs), base station subsystems, cell sites, cell towers, access points, transmit receive points (TRPs), radio access nodes, macro cell base stations, micro cell base stations, small micro cell base stations, pico cell base stations, or similar types of devices) and other network entities that can support wireless communication for user equipment (UE). The RAN 210 can transmit traffic between the UE (e.g., using a cellular RAT), one or more base stations (e.g., using a wireless interface or a backhaul interface, such as a wired backhaul interface), and / or the core network 215. The RAN 210 can provide one or more cells that cover a geographic area.

[0069] In some implementations, the RAN 210 may perform scheduling and / or resource management for UEs covered by the RAN 210 (e.g., UEs with cellular coverage provided by the RAN 210). In some implementations, the RAN 210 may be controlled or coordinated by a network controller, which may perform load balancing, network-level configuration, and / or other operations. The network controller may communicate with the RAN 210 via a wireless or wired backhaul. In some implementations, the RAN 210 may include a network controller, a self-organizing network (SON) module or component, or a similar module or component. In other words, the RAN 210 may perform network control, scheduling, and / or network management functions (e.g., for uplink, downlink, and / or sidelink communications of UEs covered by the RAN 210).

[0070] In some implementations, the core network 215 may include an exemplary functional architecture in which the systems and / or methods described herein may be implemented. For example, the core network 215 may include an exemplary architecture of a 5G next-generation (NG) core network included in a 5G radio telecommunications system. Although the exemplary architecture of the core network 215 shown in Figure 2 may be an example of a service-based architecture, in some implementations, the core network 215 may be implemented as a reference point architecture and / or a 4G core network, among other examples.

[0071] As shown in Figure 2 the core network 215 may include many functional elements. For example, the functional elements may include a network slice selection function (NSSF) 220, a network exposure function (NEF) 225, an authentication server function (AUSF) 230, a unified data management (UDM) device 235, a policy control function (PCF) 240, an application function (AF) 245, an access and mobility management function (AMF) 250, a session management function (SMF) 255, a user plane function (UPF) 260, and / or an access gateway function (AGF) 265. These functional elements may be communicatively connected via a message bus 270. Each of the functional elements shown in Figure 2 is implemented on one or more devices associated with the radio telecommunications system. In some implementations, one or more of the functional elements may be implemented on a physical device, such as an access point, a base station, and / or a gateway. In some implementations, one or more of the functional elements may be implemented on a computing device in a cloud computing environment.

[0072] The NSSF 220 includes one or more devices that select a network slice instance for a UE. By providing network slices, the NSSF 220 allows an operator to deploy multiple substantially independent end-to-end networks that may be deployed with the same infrastructure. In some implementations, each slice may be customized for a different service.

[0073] The NEF 225 includes one or more devices that support the exposure of capabilities and / or events in a radio telecommunications system to assist other entities in the radio telecommunications system in discovering network services.

[0074] The AUSF 230 includes one or more devices that act as an authentication server and support the UE authentication process in a wireless communication system.

[0075] The UDM 235 includes one or more devices that store subscriber data and profiles in a wireless communication system. The UDM 235 can be used for fixed access and / or mobile access in the core network 215.

[0076] The PCF 240 includes one or more devices that provide a policy framework that includes other examples such as network slicing, roaming, packet handling, and / or mobility management.

[0077] The AF 245 includes one or more devices that support other examples such as the impact of an application on service routing, access to the NEF 225, and / or policy control.

[0078] The AMF 250 includes one or more devices that act as an endpoint for non-access stratum (NAS) signaling and / or other examples such as mobility management.

[0079] The SMF 255 includes one or more devices that support the establishment, modification, and release of communication sessions in a wireless communication system. For example, the SMF 255 can configure service-oriented policies at the UPF 260 and / or implement other examples such as user equipment Internet Protocol (IP) address allocation and policies.

[0080] The UPF 260 includes one or more devices that act as an anchor point for internal RAT and / or internal RAT mobility. The UPF 260 can apply rules to packets, such as rules regarding packet routing, traffic reporting, and / or handling user plane QoS, and other examples.

[0081] The AGF 265 includes one or more devices that provide authentication, authorization, and accounting (AAA) services and hierarchical traffic shaping and policing for fixed networks and 5G residential gateways (e.g., network device 205), and these devices provide services from the UPF 260 within the core network 215. The AGF 265 supports shared support infrastructure, such as the Internet Protocol (IP) Multimedia Subsystem (IMS) for rich multimedia service delivery.

[0082] The message bus 270 represents a communication structure for communication among functional elements. In other words, the message bus 270 can enable communication between two or more functional elements.

[0083] The data network 275 includes one or more wired and / or wireless data networks. For example, the data network 275 can include an IP Multimedia Subsystem (IMS), a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a private network such as an intranet, an ad-hoc network, the Internet, a fiber-based network, a cloud computing network, a third-party service network, an operator service network, and / or a combination of these or other types of networks.

[0084] In Figure 2 the number and arrangement of the devices and networks shown are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently from those shown in Figure 2 In addition, two or more of the devices shown in Figure 2 can be implemented within a single device, or a single device shown in Figure 2 can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of the example environment 200 can perform one or more of the functions performed by another set of devices of the example environment 200.

[0085] Figure 3 is a diagram of example components of a device 300, which can correspond to the network device 205, RAN 210, NSSF 220, NEF 225, AUSF 230, UDM 235, PCF 240, AF 245, AMF 250, SMF 255, UPF 275, and / or AGF 265. In some implementations, the network device 205, RAN 210, NSSF 220, NEF 225, AUSF 230, UDM 235, PCF 240, AF 245, AMF 250, SMF 255, UPF 275, and / or AGF 265 can include one or more devices 300 and / or one or more components of the device 300. As shown in Figure 3 the device 300 can include a bus 310, a processor 320, a memory 330, an input component 340, an output component 350, and a communication component 360.

[0086] The bus 310 includes one or more components that implement wired and / or wireless communication among the components of the device 300. The bus 310 can couple Figure 3Two or more components are coupled together, such as via operational coupling, communication coupling, electrical coupling, and / or electro - coupling. Processor 320 includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field - programmable gate array, an application - specific integrated circuit, and / or another type of processing component. Processor 320 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 320 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0087] Memory 330 includes volatile and / or non - volatile memory. For example, memory 330 can include random access memory (RAM), read - only memory (ROM), a hard disk drive, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory). Memory 330 can include internal memory (e.g., RAM, ROM, or hard disk drive) and / or removable memory (e.g., removable via a universal serial bus connection). Memory 330 can be a non - transient computer - readable medium. Memory 330 stores information, instructions, and / or software (e.g., one or more software applications) related to the operation of device 300. In some implementations, memory 330 includes one or more memories coupled to one or more processors (e.g., processor 320) via bus 310.

[0088] Input component 340 enables device 300 to receive input, such as user input and / or sensed input. For example, input component 340 can include a touch screen, a keyboard, a keypad, a mouse, buttons, a microphone, switches, sensors, a global positioning system sensor, an accelerometer, a gyroscope, and / or an actuator. Output component 350 enables device 300 to provide output, such as via a display, a speaker, and / or a light - emitting diode. Communication component 360 enables device 300 to communicate with other devices via a wired connection and / or a wireless connection. For example, communication component 360 can include a receiver, a transmitter, a transceiver, a modem, a network interface card, and / or an antenna.

[0089] Device 300 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) may store an instruction set (e.g., one or more instructions or code) for execution by processor 320. Processor 320 may execute the instruction set to perform one or more operations or processes described herein. In some implementations, the instruction set executed by one or more processors 320 causes one or more processors 320 and / or device 300 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry may be used in place of or in combination with the instructions to perform one or more operations or processes described herein. Additionally or alternatively, processor 320 may be configured to perform one or more operations or processes described herein. Thus, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0090] The Figure 3 number and arrangement of components shown in are provided as an example. Device 300 may include additional components, fewer components, different components, or components arranged differently than those shown in Figure 3 . Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform the one or more functions described as being performed by another set of components of device 300.

[0091] Figure 4 is Figure 2 a diagram of example components of one or more devices. The example components may be included in device 400. Device 400 may correspond to network device 205. In some implementations, network device 205 may include one or more devices 400 and / or one or more components of device 400. As shown in Figure 4 , device 400 may include one or more input components 410-1 to 410-B (B≥1) (collectively referred to herein as input components 410 and individually as input component 410), a switching component 420, one or more output components 430-1 to 430-C (C≥1) (collectively referred to herein as output components 430 and individually as output component 430), and a controller 440.

[0092] The input component 410 can be one or more points of attachment for a physical link and can be one or more points of ingress for incoming traffic such as packets. The input component 410 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 can transmit and / or receive packets. In some implementations, the input component 410 can include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and / or input queues. In some implementations, the device 400 can include one or more input components 410.

[0093] The switching component 420 can interconnect the input component 410 and the output component 430. In some implementations, the switching component 420 can be implemented via one or more crossbars, via a bus, and / or using a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 410 before the packets are finally scheduled for delivery to the output component 430. In some implementations, the switching component 420 can enable the input component 410, the output component 430, and / or the controller 440 to communicate with each other.

[0094] The output component 430 can store packets and can schedule packets for transmission on an output physical link. The output component 430 can support data link layer encapsulation or decapsulation, and / or various high-level protocols. In some implementations, the output component 430 can transmit packets and / or receive packets. In some implementations, the output component 430 can include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, the device 400 can include one or more output components 430. In some implementations, the input component 410 and the output component 430 can be implemented by the same set of components (e.g., and the input / output component can be a combination of the input component 410 and the output component 430).

[0095] The controller 440 includes a processor that is in the form of, for example, a CPU, GPU, accelerated processing unit (APU), microprocessor, microcontroller, DSP, FPGA, ASIC, and / or other types of processors. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 440 can include one or more processors that can be programmed to perform functions.

[0096] In some implementations, the controller 440 may include a RAM, a ROM, and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the controller 440.

[0097] In some implementations, the controller 440 may communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 440 may create a routing table based on the network topology information, may create a forwarding table based on the routing table, and may forward the forwarding table to the input component 410 and / or the output component 430. The input component 410 and / or the output component 430 may use the forwarding table to perform a route lookup for incoming and / or outgoing packets.

[0098] The controller 440 may execute one or more of the processes described herein. The controller 440 may execute these processes in response to executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0099] The software instructions may be read via a communication interface from another computer-readable medium or from another device into the memory and / or storage components associated with the controller 440. When executed, the software instructions stored in the memory and / or storage components associated with the controller 440 may cause the controller 440 to execute one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with the software instructions to execute one or more of the processes described herein. Thus, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0100] In Figure 4 The number and arrangement of the components shown in Figure 4 are provided as an example. In practice, the device 400 may include additional components, fewer components, different components, or components arranged differently from those shown in

[0101] Figure 5 is a flowchart of an example process 500 for providing seamless handover of a PDU session between a wireless network and a wired network. In some implementations, Figure 5 one or more of the process blocks of Figure 5One or more process blocks of can be executed by another device or a set of devices that are separated from or include the device, such as a network device (e.g., network device 205). Additionally or alternatively, Figure 5 One or more process blocks of can be executed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication component 360. Additionally or alternatively, Figure 5 One or more process blocks of can be executed by one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440.

[0102] As shown in Figure 5 Process 500 can include receiving a handover request for handing over a PDU session of a network device from the RAN to the device (block 510). For example, the device can receive a handover request for handing over a PDU session of a network device from the RAN to the device, as described above. In some implementations, the network device is a dual-access residential gateway, and the device is an access gateway function. In some implementations, the RAN generates a handover request based on a measurement report received from the network device and a handover decision generated based on the measurement report.

[0103] As shown in Figure 5 Process 500 can include providing a received handover request confirmation message that confirms the handover request to the RAN (block 520). For example, as described above, the device can provide a received handover request confirmation message that confirms the handover request to the RAN.

[0104] As shown in Figure 5 Process 500 can include receiving from the RAN a sequence number status transmission indicating a handover command provided by the RAN to the network device (block 530). For example, as described above, the device can receive from the RAN a sequence number status transmission that indicates to the network device a sequence number status transmission of a handover command provided by the RAN.

[0105] As shown in Figure 5 Process 500 can include receiving from the RAN uplink data packets and downlink data packets associated with the PDU session (block 540). For example, as described above, the device can receive from the RAN uplink data packets and downlink data packets associated with the PDU session.

[0106] As shown in Figure 5 Process 500 can include receiving from the network device a request for establishing a PDU session (block 550). For example, the device can receive from the network device a request for establishing a PDU session, as described above.

[0107] As shown in Figure 5As shown in, process 500 may include establishing a PDU session of a network device based on a request to establish a PDU session (block 560). For example, a device may establish a PDU session of a network device based on a request to establish a PDU session, as described above.

[0108] In some implementations, process 500 includes receiving a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the RAN to the device is complete. In some implementations, process 500 includes providing a downlink data packet associated with the PDU session to the network device. In some implementations, process 500 includes providing an uplink data packet associated with the PDU session to the user plane function. In some implementations, based on establishing the PDU session, via the device, process 500 includes enabling additional uplink data packets and additional downlink data packets associated with the PDU session to be exchanged between the network device and the data network.

[0109] In some implementations, the device is a first device, the RAN is replaced by a second device, and process 500 includes receiving a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the second device to the first device is complete; based on receiving the handover completion message, providing a downlink data packet associated with the PDU session to the network device; and based on receiving the handover completion message, providing an uplink data packet associated with the PDU session to the UPF. In some implementations, based on establishing the PDU session, via the first device, process 500 includes enabling additional uplink data packets and additional downlink data packets associated with the PDU session to be exchanged between the network device and the data network.

[0110] In some implementations, the handover request is triggered by the network device. In some implementations, the handover request is triggered by the second device. In some implementations, the network device is a dual-access residential gateway, the first device is a backup AGF, and the second device is an active AGF. In some implementations, the second device generates a handover request based on a handover decision.

[0111] Although Figure 5 illustrates example blocks of process 500, in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those described in Figure 5 . Additionally or alternatively, two or more of the blocks of process 500 may be executed in parallel.

[0112] As used herein, the term "component" is intended to be broadly understood as hardware, firmware, or a combination of hardware and software. It is evident that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods is not limited to the implementation. Therefore, the operation and behavior of the systems and / or methods herein are described without reference to a specific software code - it is to be understood that based on the description herein, software and hardware can be used to implement the systems and / or methods.

[0113] As used herein, depending on the context, meeting a threshold can refer to a value greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc.

[0114] Regarding the scope of collecting, storing, or using personal information of individuals in connection with the foregoing implementations, it should be understood that such information can be used in accordance with the applicable laws regarding the protection of personal information. In addition, the collection, storage, and use of such information can be subject to the consent of the individual for such activities, for example, through well-known "opt-in" or "opt-out" processes, as may be determined according to the circumstances and type of information. The storage and use of personal information can be in an appropriate secure manner reflecting the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.

[0115] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in ways not explicitly recited in the claims and / or disclosed in the specification. Although each of the dependent claims listed below can directly depend on only one claim, the disclosure of various implementations includes each dependent claim in relation to every other claim in the claim set. As used herein, the phrase "at least one" in reference to a list of items refers to any combination of those items, including a single member. As an example, "at least one of a, b, or c" is intended to mean a, b, c, a - b, a - c, b - c, and a - b - c, as well as any combination of multiple items from the same list.

[0116] Unless so explicitly described, no element, act, or instruction used herein should be construed as critical or essential. Further, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced by the article “the” and may be used interchangeably with “one or more.” Further, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items) and may be used interchangeably with “one or more.” If only one item is intended, the phrase “only one” or similar language is used. Further, as used herein, the terms “has,” “have,” “having,” etc. are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “at least partially based on” unless otherwise explicitly stated. Further, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and / or” unless otherwise explicitly stated (e.g., if used in combination with “either” or “only one of”).

[0117] In the foregoing specification, various example embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the following claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising: receiving, by the device, a handover request to handover a protocol data unit (PDU) session of the network device from a radio access network RAN ​​to the device; providing, by the device and to the RAN, a handover request confirmation message confirming receipt of the handover request; receiving, by the device and from the RAN, a sequence number status transmission indicating a handover command provided by the RAN to the network device; receiving, by the device and from the RAN, uplink data packets and downlink data packets associated with the PDU session; receiving, by the device and from the network device, a request to establish the PDU session; as well as The PDU session of the network device is established, by the device, based on the request for establishing the PDU session.

2. The method according to claim 1, further comprising: A handover complete message is received from the network device, the handover complete message indicating that the handover of the PDU session of the network device from the RAN to the device is complete.

3. The method according to claim 1, further comprising: The downlink data packets associated with the PDU session are provided to the network device.

4. The method according to claim 1, further comprising: The uplink data packets associated with the PDU session are provided to a user plane function.

5. The method according to claim 1, further comprising: Based on establishing the PDU session, additional uplink data packets and additional downlink data packets associated with the PDU session are enabled to be exchanged between the network device and a data network via the device.

6. The method of claim 1, wherein the network device is a dual access residential gateway and the device is an access gateway function.

7. The method of claim 1, wherein the RAN generates the handover request based on a measurement report received from the network device and a handover decision generated based on the measurement report.

8. A first device, comprising: one or more memories; as well as One or more processors to: receiving a switching request for switching a protocol data unit (PDU) session of a network device from a second device to the first device; providing a handover request confirmation message confirming receipt of the handover request to the second device; receiving, from the second device, a sequence number status transmission indicating that the second device provides a handover command to the network device; receiving, from the second device, an uplink data packet and a downlink data packet associated with the PDU session; receiving a request from the network device to establish the PDU session; as well as The PDU session of the network device is established based on the request for establishing the PDU session.

9. The first device of claim 8, wherein the one or more processors are further configured to: receiving a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the second device to the first device is completed; Based on receiving the handover completion message, providing the downlink data packet associated with the PDU session to the network device; as well as Based on receiving the handover complete message, the uplink data packet associated with the PDU session is provided to a user plane function.

10. The first device of claim 8, wherein the one or more processors are further configured to: Based on establishing the PDU session, additional uplink data packets and additional downlink data packets associated with the PDU session are enabled to be exchanged between the network device and a data network via the first device.

11. The first device of claim 8, wherein the switching request is triggered by the network device.

12. The first device of claim 8, wherein the handover request is triggered by the second device.

13. The first device of claim 8, wherein the network device is a dual access residential gateway, the first device is a backup access gateway function, and the second device is an active access gateway function.

14. The first device of claim 8, wherein the second device generates the handover request based on a handover decision.

15. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: One or more instructions that, when executed by one or more processors of a first device, cause the first device to: receiving a switching request for switching a protocol data unit (PDU) session of a network device from a second device to the first device; providing a handover request confirmation message confirming receipt of the handover request to the second device; receiving, from the second device, a sequence number status transmission indicating that the second device provides a handover command to the network device; receiving, from the second device, an uplink data packet and a downlink data packet associated with the PDU session; receiving a request from the network device to establish the PDU session; establishing the PDU session of the network device based on the request for establishing the PDU session; receiving a handover completion message from the network device, the handover completion message indicating that the handover of the PDU session of the network device from the second device to the first device is completed; Based on receiving the handover completion message, providing the downlink data packet associated with the PDU session to the network device; as well as Based on receiving the handover complete message, the uplink data packet associated with the PDU session is provided to a user plane function.

16. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first device to: Based on establishing the PDU session, additional uplink data packets and additional downlink data packets associated with the PDU session are enabled to be exchanged between the network device and a data network via the first device.

17. The non-transitory computer-readable medium of claim 15, wherein the handover request is triggered by one of the network device or the second device.

18. The non-transitory computer readable medium of claim 15, wherein the first device utilizes one of an Xn application protocol or a next generation application protocol.

19. The non-transitory computer readable medium of claim 15, wherein the network device is a dual access residential gateway, the first device is a backup access gateway function, and the second device is an active access gateway function.

20. The non-transitory computer-readable medium of claim 15, wherein the second device generates the handover request based on a handover decision.

Images