Patent Description:
Modern terrestrial telecommunication systems include heterogeneous mixtures of second, third, and fourth generation (<NUM>, <NUM>, and <NUM>) cellular-wireless access technologies, which can be cross-compatible and can operate collectively to provide data communication services. Global Systems for Mobile (GSM) is an example of <NUM> telecommunications technologies; Universal Mobile Telecommunications System (UMTS) is an example of <NUM> telecommunications technologies; and Long Term Evolution (LTE), including LTE Advanced, and Evolved High-Speed Packet Access (HSPA+) are examples of <NUM> telecommunications technologies. Moving forward, future telecommunications systems may include fifth generation (<NUM>) cellular-wireless access technologies, among other forthcoming technologies, to provide improved bandwidth and decreased response times to a multitude of devices that may be connected to a network. "<NPL> discloses an architecture comprising a SMF, and several UPFs. <CIT> discloses a method in which a SMF performs selecting a UPF suitable to a UE new location and setting up an anchor UPF and a new tunnel.

The systems, devices, and techniques described herein relate to user plane system migration in mobile networks. In particular, the systems, devices, and techniques can be implemented in fifth generation (<NUM>) mobile networks to provide intelligent migration of a session from a first user plane function (UPF) to a second UPF.

A user device may receive services from a domain or data network (DN) in a communication session via a particular UPF. However, if the particular UPF is in distress (e.g., the UPF is failing, has failed, is overloaded, is in danger of being overloaded, is experiencing relatively high latency, or the like), the UPF may cause at least a portion of the services to be delayed from reaching the user device. In the case of a complete failure of the particular UPF, the user device may have to establish an entirely new communication session in order to continue receiving the services.

Establishing a new communication session can be problematic. Establishing a new communication session can take a significant amount of time, which can delay services delivered to the user device. In addition, establishing a new communication session can occupy network resources that could otherwise be applied to other tasks. For example, establishing a new communication session may require the user device to establish a new connection with a new signaling system (which can include, e.g., an access and mobility management function (AMF) and/or a session management function (SMF)). The signaling system may have to assign a new internet protocol (IP) address to the user device, select a new UPF to provide services to the user device, establish the new communication session with the user device, and the like. The various processes required to establish a new communication session can introduce further delays to the services and can occupy an unnecessary amount of resources within the network.

To address these and other problems, various implementations relate to migrating an existing communication session from a first path, which includes a stressed UPF, to a second path, which excludes the stressed UPF. The communication session can be migrated in a manner that is transparent to the user device, such that the migration does not interrupt services at the user device.

The UPF can be determined to be stressed using a variety of techniques. In some implementations, the stressed UPF is identified when a periodic heartbeat message from the stressed UPF is interrupted. In certain implementations, the stressed UPF identifies itself by transmitting an offloading request upon determining that it should offload data traffic.

The communication session can be migrated by causing a replacement UPF to export at least one revised route for the communication session to at least one node in the first path. The revised route may specify the replacement UPF and exclude the stressed UPF. For example, the revised route may instruct a node to transmit data destined for the user device to the replacement UPF, rather than to the stressed UPF. In some examples, the revised route may instruct a node to transmit data from the user device to the replacement UPF, rather than to the stressed UPF. Accordingly, the second path can include some of the nodes of the first path and the replacement UPF but can exclude the stressed UPF.

In particular implementations, a signaling system can initiate the migration of the session from the initial UPF to the replacement UPF. In certain instances, a session management function (SMF) determines whether the migration should occur and initiates the migration by signaling the replacement UPF.

In various implementations, the communication session can be migrated to an existing UPF, rather than generating a new node or regenerating the stressed UPF as a virtual machine. In some examples, the signaling system instructs the replacement UPF to export the migrated route to at least one node that is connected stressed UPF, rather than to the user device itself. Accordingly, the session can be migrated in a manner that is transparent to the user device.

Various implementations represent improvements to the field of networks. In particular, various implementations efficiently handle UPF failure and UPF overload scenarios, without significantly affecting user experience by migrating existing communication sessions from stressed UPFs to non-stressed UPFs in a manner that is transparent to user devices engaged in the communication sessions.

The various functions, gateways, nodes, and components discussed herein can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure.

The system, devices, and techniques described herein can be applied to selecting any function in a mobile network based at least in part on latency. For example, various components of a fifth generation (<NUM>) mobile network can include, but are not limited to, a network exposure function (NEF), a network resource function (NRF), an authentication server function (AUSF), an access and mobility management function (AMF), a policy control function (PCF), a session management function (SMF), a unified data management (UDM) function, a user plane function (UPF), and/or an application function (AF). For example, some or all of the functions discussed herein can indicate a stressed UPF, transmit or receive a migration request, transmit or receive an indication of a revised route, etc., associated with the various functions to an SMF and/or UPF (or other component), such that the SMF or other component can select a particular function of a plurality of possible functions or components providing the same function. Thus, the system, devices, and techniques broadly apply to migrating communication sessions, and are not limited to a particular context or function, as discussed herein.

As used herein, the term "signaling system" can refer to a system in a network configured to handle control plane data. In some cases, a signaling system can select and/or manage user plane systems that carry data traffic through the network. For example, a signaling system can be or include a session management function (SMF). In another example, a signaling system can be or include a packet data network (PDN) gateway-C (PGW-C).

As used herein, the terms "communication session" and "session" can refer to an exchange of data between two or more communicating nodes or devices. A communication session can be temporary, such that it is established at a first time and ceased at a second time. In various implementations, a communication session includes the transfer of user plane data between two or more nodes.

As used herein, the term "node" can refer to one or more devices that transmit and/or receive data in a network. In some instances, a first node can transmit and/or receive data from a second node.

As used herein, the terms "network path" and "path" can refer to a pathway over which data can be transferred between at least two terminal nodes or devices. In some cases, a path may include one or more intermediary nodes and/or one or more interfaces between the terminal nodes.

As used herein, the term "route" can refer to an instruction or indication to transfer data along a particular network path. For example, when an entity is connected to a first node via a first interface and to a second node via a second interface, a first route may be an instruction for the entity to transmit data over the first interface to the first node, and a second route may be an instruction for the entity to transmit data over the second interface to the second node.

As used herein, the term "migrating" can refer to moving at least a portion of something to a different location. For example, a communication session can be migrated to a particular path by ensuring that the data exchanged in the communication session traverses the particular path rather than a previous path.

As used herein, the term "heartbeat" can refer to a repeatedly transmitted and/or received message. The repeated message can be transmitted or received by a network node. In some instances, a heartbeat can be a repeated echo request message or a repeated echo response message in a repeated ping operation. In some cases, a heartbeat is expected to be transmitted and/or expected to be received periodically.

The systems, devices, and techniques described herein can be implemented in a number of ways. Example implementations are provided below with reference to the following figures.

<FIG> is a diagram illustrating example signaling <NUM> between a user equipment (UE) and various components of a mobile network, such as a fifth generation (<NUM>) mobile network, as described herein. As illustrated, the signaling <NUM> includes interactions between a user equipment (UE) <NUM>, a session management function (SMF) <NUM>, a first user plane function (UPF) <NUM>(<NUM>), a second UPF <NUM>(<NUM>), and a domain or data network (DN) <NUM>. As can be understood in the context of this disclosure, the example signaling <NUM> is not limited to the components described in <FIG> and can include other components and operations.

In accordance with various embodiments described herein, the terms "user equipment (UE)," "user device," "wireless communication device," "wireless device," "communication device," "mobile device," and "client device," can be used interchangeably herein to describe any UE (e.g., the UE <NUM>) that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), New Radio (NR), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over internet protocol (VoIP), VoLTE, Institute of Electrical and Electronics Engineers' (IEEE) <NUM>. 1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future internet protocol (IP)-based network technology or evolution of an existing IP-based network technology.

In general, the UE <NUM> can be implemented as any suitable type of computing device configured to communicate over a wired or wireless network, including, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a portable digital assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an internet-of-things (IoT) device, an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), set-top-box (STB), desktop computer, an IoT device, and the like.

The UE <NUM> is configured to utilize various RANs, such as RAN <NUM>, in order to access the DN <NUM>. In general, the DN <NUM> is agnostic to the access technology that is used to connect a UE to the DN <NUM>. In this manner, the UE <NUM> can connect to the DN <NUM> via the RAN <NUM>, which can include a <NUM>rd Generation Partnership Project (3GPP) RAN, such a GSM/EDGE RAN (GERAN), a Universal Terrestrial RAN (UTRAN), or an evolved UTRAN (E-UTRAN), or alternatively, via a "non-3GPP" RAN, such as a Wi-Fi RAN, or another type of wireless local area network (WLAN) that is based on the IEEE <NUM> standards. If the UE <NUM> accesses the DN <NUM> through a Wi-Fi access network, the RAN <NUM> may include a Wi-Fi access point (AP). Providing access to the DN <NUM> through non-3GPP RANs has opened the door to recent advancements in IMS-based services, such as the introduction of Wi-Fi calling, which allows users to initiate and receive calls over an available Wi-Fi AP. Environments can include any number and type of base stations representing any number and type of macrocells, microcells, picocells, or femtocells, for example, with any type or amount of overlapping coverage or mutually exclusive coverage.

In general, the SMF <NUM> can be implemented as a network function including functionality to manage communication sessions by and between UEs, and/or to provide internet protocol (IP) addresses to the UEs. In some instances, the SMF <NUM> can select a UPF (e.g., the first UPF <NUM>(<NUM>) and/or the second UPF <NUM>(<NUM>) to provide services to the UE <NUM> in response to receiving a request from the UE <NUM>, as discussed herein.

In general, each of the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>) can be implemented as a network function including functionality to control data transfer between the UE <NUM> and the various components of the network. In some instances, one or both of the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>) can include functionality to act as an anchor point for radio access technology (RAT) handover (e.g., inter and intra), external protocol data unit (PDU) session point of interconnect to a data network (e.g., the internet), packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, traffic usage reporting, traffic routing, Quality of Service (QoS) handling for user plane (e.g., packet filtering, gating, uplink/downlink rate enforcement), uplink traffic verification, transport level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and the like. As can be understood in the context of this disclosure, there may be one or more UPFs in addition to UPFs <NUM>(<NUM>) and <NUM>(<NUM>), which are associated with a network and/or with the UE <NUM>.

In general, the DN <NUM> can include any public or private network(s), such as the Internet. In addition, the DN <NUM> may include one or more devices that can receive and transmit data. For example, the DN <NUM> may include any of media server(s), user device(s), and the like.

In general, a user can further utilize the UE <NUM> to communicate with other users and associated UEs via an IP multimedia subsystem (IMS) core (sometimes referred to as the "IMS core network," the "IMS network," the "Core Network (CN)," or the "IM CN Subsystem"), which can be at least a portion of the DN <NUM>. IMS is an architectural framework defined by the 3GPP for delivering IP multimedia to a UE, such as the UE <NUM>. The IMS core can be maintained and/or operated by one or more service providers, such as one or more wireless carriers ("carriers"), that provide IMS-based services to users who are associated with UEs, such as the UE <NUM>. For example, a service provider can offer multimedia telephony services that allow a user to call or message other users via the IMS core using his/her UE. A user can also utilize an associated UE to receive, provide, or otherwise interact with various different IMS-based services by accessing the IMS core. It is to be appreciated that any number of base stations and/or IMS nodes can be included in the IMS network.

Accordingly, an operator of the IMS core can offer any type of IMS-based service, such as, telephony services, emergency services (e.g., E911), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order to access these services (e.g., telephony services), a UE is configured to request establishment of a communication session. In the case of telephony services, the communication session can comprise a call (e.g., a voice-based communication session, such as a VoLTE call, or a Wi-Fi call).

Turning to the signaling <NUM>, the UE <NUM> may transmit a session request <NUM> to the RAN <NUM>. The RAN <NUM> may forward the session request <NUM> to the SMF <NUM>. In some instances, the RAN <NUM> can forward the session request <NUM> to an application management function (AMF), which can then transmit an indication of the session request <NUM> to the SMF <NUM>.

In particular implementations, the session request <NUM> may be a request by the UE <NUM> for services from the DN <NUM>. In various examples, the services can be any of voice services, Internet browsing services, data streaming services, and the like. The UE <NUM> may be requesting a communication session with a destination in the DN <NUM> or beyond the DN <NUM>. For example, the UE <NUM> may be requesting a voice call with another device connected to, or part of, the DN <NUM>. In some examples, the UE <NUM> may be requesting to stream a video from a media server in the DN <NUM>. Although <FIG> illustrates a call initiated by the UE <NUM>, in some cases, the call may be initiated by the other device connected to, or part of, the DN <NUM>.

In response to receiving the session request <NUM>, the SMF <NUM> may transmit a services request <NUM> to the first UPF <NUM>(<NUM>). In some cases, the SMF <NUM> can transmit the services request <NUM> over an N4 interface with the first UPF <NUM>(<NUM>). The first UPF <NUM>(<NUM>) may further forward the services request <NUM> to the DN <NUM>. In some cases, the first UPF <NUM>(<NUM>) can transmit the services request <NUM> over an N6 interface with the DN <NUM>.

In particular implementations, the services request <NUM> may be a request by the SMF <NUM> to establish the communication session with the UE <NUM>. The services request <NUM> may specify the UE <NUM>, the first UPF <NUM>(<NUM>), the destination of the communication session (e.g., a destination associated with DN <NUM>), or a combination thereof. For example, the services request <NUM> may specify an IP address assigned to the UE <NUM> and/or routing information indicating that data destined for the IP address assigned to the UE <NUM> should be transmitted along a particular path (or route) that includes the first UPF <NUM>(<NUM>).

In response to receiving the services request <NUM>, a communication session may be initiated between the UE <NUM> and the DN <NUM>. In the communication session, first data <NUM> may be transmitted between the UE <NUM> and the DN <NUM> by the RAN <NUM> and the first UPF <NUM>(<NUM>). In some cases, the first data <NUM> is transmitted over a wireless link between the UE <NUM> and the RAN <NUM>, over an N3 interface between the RAN <NUM> and the first UPF <NUM>(<NUM>), and an N6 interface between the first UPF <NUM>(<NUM>) and the DN <NUM>. The wireless link, the RAN <NUM>, the N3 interface, the first UPF <NUM>(<NUM>), and the N6 interface may be included in a first network path corresponding to the communication session. The first data <NUM> may include uplink data and/or downlink data associated with the communication session. For example, the first data <NUM> may include the services requested by the UE <NUM> in the session request <NUM>.

After the communication session has been established, the SMF <NUM> may receive a stress indication <NUM> from the first UPF <NUM>(<NUM>). The stress indication <NUM> may be received over the N4 interface between the SMF <NUM> and the first UPF <NUM>(<NUM>). In some cases, the stress indication <NUM> can include one or more irregular heartbeat messages. For instance, the stress indication <NUM> may include a heartbeat message that is received later than a receipt time expected by the SMF <NUM>.

In various implementations, the stress indication <NUM> may indicate that the first UPF <NUM>(<NUM>) is stressed. In some examples, the stress indication <NUM> may inform the SMF <NUM> that the first UPF <NUM>(<NUM>) is failing, has failed, is overloaded, or the like. In some cases, the stress indication <NUM> comprises one or more periodic heartbeat messages that have been delayed and/or interrupted. In particular cases, the stress indication <NUM> is an offloading request generated by the first UPF <NUM>(<NUM>).

When the SMF <NUM> determines that the first UPF <NUM>(<NUM>) is stressed, the SMF <NUM> may migrate the communication session from the first path to a second path. The second path may exclude the first UPF <NUM>(<NUM>). Accordingly, interruptions in the communication session due to a failure and/or overloading condition of the UPF <NUM>(<NUM>) can be prevented.

In response to receiving the stress indication <NUM> from the first UPF <NUM>(<NUM>), the SMF <NUM> may transmit a migration request <NUM> to the second UPF <NUM>(<NUM>). The migration request <NUM> may be transmitted over an N4 interface between the SMF <NUM> and the second UPF <NUM>(<NUM>). In some implementations, the second UPF <NUM>(<NUM>) is an existing node that is connected to the SMF <NUM> prior to the SMF <NUM> receiving the stress indication <NUM>. In particular instances, the second UPF <NUM>(<NUM>) is not generated in response to the stress indication <NUM>. In some examples, the second UPF <NUM>(<NUM>) is not a virtual machine instance of the first UPF <NUM>(<NUM>). The migration request <NUM> may include, or otherwise indicate, one or more sessions to be migrated to the second UPF <NUM>(<NUM>), in particular implementations.

In various implementations, the migration request <NUM> instructs the second UPF <NUM>(<NUM>) to handle data traffic in the existing communication session between the UE <NUM> and the DN <NUM>. According to particular implementations, the migration request <NUM> may include, or otherwise indicate, one or more sessions that are to be migrated to the second UPF <NUM>(<NUM>). In some cases, these one or more sessions include all sessions that were previously served by the first UPF <NUM>(<NUM>). The migration request <NUM> may instruct the second UPF <NUM>(<NUM>) to export a revised route to one or more nodes in the existing first path, such as to the RAN <NUM> and/or the DN <NUM>. In some cases, the migration request <NUM> may instruct the second UPF <NUM>(<NUM>) to export a revised route to at least one node that is preconfigured to transmit data associated with the communication session to the first UPF <NUM>(<NUM>).

According to the invention, the migration request instructs the second UPF to transmit at least one indication of a revised route to at least one of a Radio Access Network, RAN, connected between the UE and the second UPF or the DN, the revised route replacing the first UPF with the second UPF.

In response to receiving the migration request <NUM>, the second UPF <NUM>(<NUM>) may transmit a first revised route indication <NUM> to a node in the first path that is connected to the first UPF <NUM>(<NUM>). In the example illustrated in <FIG>, this node is the DN <NUM> itself. When the node is the DN <NUM>, the first revised route indication <NUM> may be transmitted over an N6 interface. When the node is another UPF connected between the first UPF <NUM>(<NUM>) and the DN <NUM>, the first revised route indication <NUM> may be transmitted over an N9 interface.

In particular implementations, the first revised route indication <NUM> may instruct the node (e.g., the DN <NUM>) to transmit data packets destined for the UE <NUM> to the second UPF <NUM>(<NUM>) rather than the first UPF <NUM>(<NUM>). For example, upon receiving the first revised route indication <NUM>, a server within the DN <NUM> may amend an entry of a routing table associated with an IP address of the UE <NUM>. The amended entry of the routing table may cause the server to route downlink data packets for the UE <NUM> to the second UPF <NUM>(<NUM>), rather than to the first UPF <NUM>(<NUM>).

In addition, in response to receiving the migration request <NUM>, the second UPF <NUM>(<NUM>) may transmit a second revised route indication <NUM> to a node in the first path that is connected to the first UPF <NUM>(<NUM>). In the example illustrated in <FIG>, this node is the RAN <NUM> itself. When the node is the RAN <NUM>, the second revised route indication <NUM> may be transmitted over an N3 interface. When the node is another UPF connected between the first UPF <NUM>(<NUM>) and the RAN <NUM>, the second revised route indication <NUM> may be transmitted over an N9 interface.

In particular implementations, the second revised route indication <NUM> may instruct the node (e.g., the RAN <NUM>) to transmit data packets from the UE <NUM> to the second UPF <NUM>(<NUM>) rather than the first UPF <NUM>(<NUM>). For example, upon receiving the second revised route indication <NUM>, the RAN <NUM> may amend an entry of a routing table associated with an IP address of the UE <NUM>. The amended entry may cause the RAN <NUM> to route uplink data packets from the UE <NUM> to the second UPF <NUM>(<NUM>), rather than to the first UPF <NUM>(<NUM>).

In some implementations, the first revised route indication <NUM> and/or the second revised route indication <NUM> may indicate a route associated with a range of IP addresses associated with communication sessions that should be migrated, wherein the range includes the IP address of the UE <NUM>. In certain cases, an IP network associated with the DN <NUM> and/or the RAN <NUM> is informed of the migration via the first revised route indication <NUM>.

After the first revised route indication <NUM> and the second revised route indication <NUM> have been transmitted to the nodes in the first path (e.g., the DN <NUM> and the RAN <NUM>, respectively), second data <NUM> may be transmitted between the UE <NUM> and the DN <NUM>. The second data <NUM> may be part of same communication session as the first data <NUM>, such that the communication session is substantially uninterrupted by the migration to the new path including the second UPF <NUM>(<NUM>). The second data <NUM> may be transmitted between the UE <NUM> and the DN <NUM> by the RAN <NUM> and the second UPF <NUM>(<NUM>). In some cases, the second data <NUM> is transmitted over a wireless link between the UE <NUM> and the RAN <NUM>, over an N3 interface between the RAN <NUM> and the second UPF <NUM>(<NUM>), and an N6 interface between the second UPF <NUM>(<NUM>) and the DN <NUM>. The wireless link, the RAN <NUM>, the N3 interface, the second UPF <NUM>(<NUM>), and the N6 interface may be included in a second network path corresponding to the communication session. The second data <NUM> may include uplink data and/or downlink data associated with the communication session. For example, the second data <NUM> may include the services requested by the UE <NUM>. In various implementations, the services delivered to the UE <NUM> may not be noticeably interrupted by the migration of the communication session from the first path to the second path.

Additional details of an example network are discussed below in connection with <FIG>.

<FIG> illustrates an example environment <NUM> including a user equipment (UE) and various components implementing session migration, as described herein. For example, the environment <NUM> includes the UE <NUM>, the (radio) access network (RAN) <NUM>, the session management function (SMF) <NUM>, the first and second user plane functions (UPFs) <NUM>(<NUM>) and <NUM>(<NUM>), and the domain or data network (DN), as discussed in connection with <FIG>, as well as a network exposure function (NEF) <NUM>, an authentication server function (AUSF) <NUM>, a network resource function (NRF) <NUM>, an access and mobility management function (AMF) <NUM>, a policy control function (PCF) <NUM>, a unified data management (UDM) <NUM>, and an application function (AF) <NUM>. A signaling system <NUM> can include the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the AMF <NUM>, the PCF <NUM>, the SMF <NUM>, and the UDM <NUM>. Further, the environment includes n first node(s) <NUM> connected between the RAN <NUM> and the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>), as well as m second node(s) <NUM> connected between the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>) and the DN <NUM>.

In general, the NEF <NUM> can be implemented as a network function including functionality to securely expose services and/or capabilities provided by and amongst the various network functions, as discussed herein. In some instances, the NEF <NUM> receives information from other network functions and can store the received information as structured data using an interface to a data storage network function.

In general, the AUSF <NUM> can be implemented as a network function including functionality to provide authentication to various devices in the network. For example, the AUSF <NUM> can request device credentials (e.g., security key(s)), verify that a device is authorized to connect to a network, and/or control access to the network based on the device credentials.

In general, the NRF <NUM> can be implemented as a network function including functionality to support service discovery (e.g., receive a network function discovery request and provide information associated with the discovered network function instances to a requesting entity). In some instances, the NRF <NUM> can receive utilization information, capability information, etc. from various network functions, such as the UPFs <NUM>(<NUM>) and <NUM>(<NUM>), to provide such utilization information to the other components discussed herein. Further, the NRF <NUM> can select, assign, implement, or otherwise determine network functions to be used in a network based at least in part on utilization information, as discussed herein.

In general, the AMF <NUM> can be implemented as a network function including functionality to provide UE-based authentication, authorization, mobility management, etc., to various UEs. In some instances, the AMF <NUM> can include functionality to terminate a RAN control plane interface between the UE <NUM> and other functions on the network. In some instances, the AMF <NUM> can include functionality to perform registration management of the UE <NUM> in a network, connection management, reachability management, mobility management, access authentication, access authorization, security anchor functionality (e.g., receiving and/or transmitting security keys during registration/authorization), and the like.

In general, the PCF <NUM> can be implemented as a network function including functionality to support unified policy framework to govern network behavior, provide policy rules to control plane functions and/or enforce such rules, and/or implement a front end to access subscription information relevant for policy decisions in a data repository.

In general, the UDM <NUM> can be implemented as a network function including functionality to process authentication credentials, handle user identification processing, manage registration and/or mobility, manage subscriptions between a UE and a carrier, and/or manage short message service (SMS) data.

In general, the AF <NUM> can be implemented as a network function including functionality to route traffic to/from applications operating on the network, facilitate accessing the NEF <NUM>, and interact with the policy framework for policy control in connection with the PCF <NUM>.

In general, the n first node(s) <NUM> may include one or more network nodes between the RAN <NUM> and the first UPF <NUM>(<NUM>), as well as between the RAN <NUM> and the second UPF <NUM>(<NUM>). In some cases, the n first node(s) <NUM> include multiple nodes that are connected to each other in series. As used herein, n can be a positive integer. In various examples, each one of the n first node(s) <NUM> is a UPF that is separate from the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>). The n first node(s) <NUM> may be connected to the RAN <NUM> by an N3 interface, connected to the first UPF <NUM>(<NUM>) by a first N9 interface, and connected to the second UPF <NUM>(<NUM>) by a second N9 interface. In some implementations, the n first node(s) <NUM> are omitted from the environment <NUM>, such that the RAN <NUM> is connected to the first UPF <NUM>(<NUM>) via a single (N3) interface and to the second UPF(<NUM>) via a single (N3) interface.

In general, the m second node(s) <NUM> may include one or more network nodes between the first UPF <NUM>(<NUM>) and the DN <NUM>, as well as between the second UPF <NUM>(<NUM>) and the DN <NUM>. In some cases, the m second node(s) <NUM> include multiple nodes that are connected to each other in series. As used herein, m can be a positive integer. In various examples, each one of the m second node(s) <NUM> is a UPF that is separate from the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>) and is separate from any UPFs included in the n first node(s) <NUM>. The m second node(s) <NUM> may be connected to the first UPF <NUM>(<NUM>) by a third N9 interface, connected to the second UPF <NUM>(<NUM>) by a fourth N9 interface, and connected to the DN <NUM> by an N6 interface. In some implementations, the m second node(s) are omitted from the environment <NUM>, such that the DN <NUM> is connected to the first UPF <NUM>(<NUM>) via a single (N6) interface and connected to the second UPF <NUM>(<NUM>) via a single (N6) interface.

In general, the signaling system <NUM> can be implemented as a technology configured to establish a communication session between the UE <NUM> and the DN <NUM>. In some implementations, the RAN <NUM> transmits a request for services from the UE <NUM> to the AMF <NUM>. In certain examples, the AMF <NUM> requests the SMF <NUM> to select a UPF to provide the services between the UE <NUM> and the DN <NUM>. For example, the SMF <NUM> may initially select the first UPF <NUM>(<NUM>) to provide services between the UE <NUM> and the DN <NUM>. As a result of establishing the communication session, services can be transmitted between the UE <NUM> and the DN <NUM> over a first path <NUM>, which can include a wireless link between the UE <NUM> and the RAN <NUM>, the RAN <NUM>, the N3 interface, the n first node(s) <NUM>, the first N9 interface between the n first node(s) <NUM> and the first UPF <NUM>(<NUM>), the first UPF <NUM>(<NUM>), the third N9 interface between the first UPF <NUM>(<NUM>) and the m second node(s) <NUM>, and the N6 interface.

In general, the signaling system <NUM> can be implemented as a technology configured to migrate a communication session from one UPF to another UPF. In some cases, the SMF <NUM> may determine that the first UPF <NUM>(<NUM>) is stressed while providing services between the UE <NUM> and the DN <NUM>. In response, the SMF <NUM> may migrate the communication session from the first UPF <NUM>(<NUM>) to the second UPF <NUM>(<NUM>).

In some cases, the SMF <NUM> may transmit a migration request (e.g., migration request <NUM>) to the second UPF <NUM>(<NUM>), which may cause the second UPF <NUM>(<NUM>) to export revised route(s) to nodes in the first path that are connected to the first UPF <NUM>(<NUM>). For example, the second UPF <NUM>(<NUM>) may transmit a revised route to the n first node(s) <NUM> (e.g., at least one of the n first node(s) <NUM> that is connected to the first UPF <NUM>(<NUM>) via a single interface), which may cause the one first node <NUM> to transmit data from the UE <NUM> to the second UPF <NUM>(<NUM>) over the second N9 interface, rather than to the first UPF <NUM>(<NUM>) over the first N9 interface. For example, the n first node(s) <NUM> may amend or rewrite an entry of a routing table associated with an identification (e.g., an Internet Protocol (IP) address) of the UE <NUM>. In some cases, the second UPF <NUM>(<NUM>) may transmit a revised route to the m second node(s) <NUM> (e.g., at least one of the m second node(s) <NUM> that is connected to the first UPF <NUM>(<NUM>) via a single interface), which may cause the m second node(s) <NUM> to transmit data destined for the UE <NUM> to the second UPF <NUM>(<NUM>) over the fourth N9 interface, rather than to the first UPF <NUM>(<NUM>) over the third N9 interface. For example, the m second node(s) <NUM> may amend or rewrite an entry of a routing table associated with an identification (e.g., the IP address) of the UE <NUM>.

As a result of migrating the communication session, data corresponding to the communication session may be provided via a second path <NUM>, which may include the wireless link between the UE <NUM> and the RAN <NUM>, the second N3 interface between the RAN <NUM> and the second UPF <NUM>(<NUM>), the second UPF <NUM>(<NUM>), and the second N6 interface between the second UPF <NUM>(<NUM>) and the DN <NUM>. In various implementations, the migration of the communication session from the first path including the first UPF <NUM>(<NUM>) to the second path including the second UPF <NUM>(<NUM>) can be performed without interrupting or delaying services provided to the UE <NUM> in the communication session.

In general, the devices and network functions illustrated in the environment <NUM> can be communicatively coupled via one or more control planes which can pass controls and signaling by and between the various components discussed herein. Further, the environment <NUM> can include a plurality of each of the various functions (e.g., the SMF <NUM> can represent a plurality of SMFs, for example). The environment <NUM> can further include additional functions and is not limited to those represented in <FIG>.

<FIG> illustrate example processes in accordance with embodiments of the disclosure. These processes are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

<FIG> illustrates a process <NUM> for migrating a communication session according to the claimed invention. Process <NUM> may be performed by at least one of a session management function (SMF) (e.g., SMF <NUM>) or a signaling system (e.g., signaling system <NUM>), for example.

At <NUM>, a communication session corresponding to a first path associated with a first user plane function (UPF) is established. In particular implementations, the communication session is between a user equipment (UE) and a domain or data network (DN). The communication session can include data traversing a first path between the UE and the DN. The data may correspond to services exchanged between the UE and the DN. For example, the data may include voice services traversing the first path from the DN to the UE.

According to various implementations, the first path includes one or more nodes and multiple interfaces between the UE and the DN. In some cases, the first path includes the first UPF. The first UPF may receive and transmit the data as one of the nodes between the UE and the DN. In some cases, the first UPF was initially selected by the SMF to provide services between the UE and the DN.

At <NUM>, the first UPF is determined to be stressed. In some implementations, an offload request is received from the first UPF. The offload request could be in response to the first UPF determining that it is handling more than a threshold of data traffic. In certain implementations, <NUM> includes determining that a periodic heartbeat message received from the first UPF has been delayed or interrupted. For example, a heartbeat message from the first UPF may be received later than an expected time, may never be received, and the like. When the first UPF is stressed, the first UPF may be in danger of disrupting and/or delaying the data exchanged between the UE and the DN in the communication session.

At <NUM>, the communication session is migrated to a second path including a second UPF. In various implementations, <NUM> is performed in response to determining that the first UPF is determined to be stressed at <NUM>. In various implementations, multiple communication sessions corresponding to the first path are migrated to the second path.

In particular instances, <NUM> includes transmitting a migration request to the second UPF. The migration request may instruct the second UPF to transmit at least one indication of a revised route to at least one node in the first path. In some cases, the second UPF is an existing UPF that is connected to a device performing process <NUM>, but unlike the first UPF, is determined to not be stressed.

In various implementations, the migration request instructs the second UPF to transmit an indication to a node in the first path that is connected to the first UPF. The node, for example, may be connected to the first UPF by a single interface. In some cases, the node may have forwarded data in the communication session to the first UPF. In particular implementations, the node is at least one of a third UPF, a radio access network (RAN) connected to the UE, or the DN itself.

In particular implementations, the revised route includes the second UPF. For example, an indication of a revised route may instruct a node to transmit data in a communication session to the second UPF. The indication may cause the node to transmit data to the second UPF rather than the first UPF, in certain examples.

As a result of process <NUM>, the communication session between the UE and the DN may be migrated from the first path (including the stressed first UPF) to a second path (including the non-stressed second UPF). In some examples, the UE may not experience any significant interruptions in the communication session that are due to the stress experienced by the first UPF or due to the migration itself.

<FIG> illustrates a process <NUM> for migrating a communication session according to implementations of the disclosure. Process <NUM> may be performed by a user plane function (UPF) (e.g., second UPF <NUM>(<NUM>)), for example.

At <NUM>, a replacement request is received from a session management function (SMF). The migration request may include an instruction to transmit at least one indication of a revised route to at least one network node. In various implementations, the migration request may identify an existing communication session including data traversing a first path through the network and/or identify the network node in the first path.

In some cases, the migration request includes an indication of a user equipment (UE) associated with the communication session. For example, the migration request may include an internet protocol (IP) address of the UE, an IP address of a server in a domain or data network (DN) communicating with the UE in the session, or a combination thereof.

In various implementations, the network node may be part of a first path over which data in the communication session has previously traversed. In some cases, the network node is a network node that is connected with a stressed, first UPF via a single interface. In particular implementations, the node is at least one of a third UPF connected to the first UPF via a single N9 interface, a radio access network (RAN) connected to the first UPF via a single N3 interface, or the DN itself connected to the first UPF via a single N6 interface.

At <NUM>, at least one indication of a revised route is transmitted to the at least one node carrying data in the communication session. In some cases, the node may have forwarded data in the communication session to the first UPF at least prior to <NUM> and/or <NUM>.

In some cases, the revised route includes a device performing the process <NUM>, e.g., the second UPF. For example, the at least one indication of the revised route may instruct the node to transmit data in the communication session to the second UPF. The indication may cause the node to transmit data to the second UPF rather than the first UPF, in certain examples.

According to particular implementations, the indication of the revised route instructs the node to update a routing table managed by the node. In some examples, the indication may instruct the node to update an entry in the routing table that is associated with the communication session. In some cases, the indication includes an identifier of the UE (e.g., an IP address of the UE), an identifier of the DN (e.g., an IP address of one or more servers in the DN), or a combination thereof. Using the identifier(s) in the indication, the node may identify an entry associated with the communication session and amend the entry to indicate that data in the communication session should be forwarded by the node to the second UPF, rather than to the first UPF.

At <NUM>, data in the communication session is received from the at least one node. In various implementations, the node routed the data along the revised route in response to receiving the indication of the revised route. The data may be destined for the UE or the DN.

At <NUM>, the data is transmitted between the UE and the DN in the communication session. The data may be transmitted to another node in the first path between the UE and the DN. In various implementations, the node is connected to the first UPF via a single interface. In some cases, the node can be at least one of a fourth UPF, the RAN, or the DN itself.

As a result of process <NUM>, the communication session between the UE and the DN may be migrated from the first path (including the stressed, first UPF) to a second path (including the second UPF, which may not be stressed). In some examples, the UE may not experience any significant interruptions in the communication session that are due to stress experienced by the first UPF or due to the migration itself.

<FIG> illustrates a process <NUM> for migrating a communication session according to implementations of the disclosure. Process <NUM> may be performed by a network node, such as a user plane function (UPF) (e.g., first UPF <NUM>(<NUM>)), for example.

At <NUM>, data in a communication session is carried by a network node between a user equipment (UE) and a domain or data network (DN). The data may traverse a network through a first path, which includes one or more nodes and multiple interfaces connecting the nodes. In some cases, the first path includes the device performing the process <NUM>.

At <NUM>, data traffic traversing the network node is determined to exceed a threshold. The data traffic may include data outside of the communication session as well as the data in the communication session. For example, the data traffic may be associated with various other communication sessions between other UEs and/or other DNs. The threshold may be a static threshold or a dynamic threshold.

At <NUM>, an offload request is transmitted by the network node to the SMF. The offload request may instruct the SMF to migrate at least a portion of the data traffic to a path that excludes the network node. For example, the offload request may instruct the SMF to migrate the communication session to a different network node.

As a result of process <NUM>, the SMF may cause migration of the communication session from a first path (including the network node performing process <NUM>) to a second path (excluding the network node performing process <NUM>). Accordingly, interruptions to the communication session as a result of the network node being overloaded can be prevented.

<FIG> illustrates example device(s) <NUM> to implement session migration, as described herein. In some embodiments, some or all of the functionality discussed in connection with <FIG> can be implemented in the device(s) <NUM>. Further, the device(s) <NUM> can be implemented as one or more server computers <NUM>, a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure, and the like. It is to be understood in the context of this disclosure that the device(s) <NUM> can be implemented as a single device or as a plurality of devices with components and data distributed among them.

As illustrated, the device(s) <NUM> comprise a memory <NUM> storing the session management function (SMF) <NUM>, the first user plane function (UPF) <NUM>(<NUM>), the second UPF <NUM>(<NUM>), the network exposure function (NEF) <NUM>, the authentication server function (AUSF) <NUM>, the network resource function (NRF) <NUM>, the access and mobility management function (AMF) <NUM>, the unified data management (UDM) <NUM>, the policy control function (PCF) <NUM>, the domain or data network (DN) <NUM>, and the application function (AF) <NUM>, and to provide functionality to the device <NUM> to facilitate improved user plane system selection based on latency, as described herein. In various embodiments, the memory <NUM> may also comprise additional functions and structures that are not explicitly described herein. Also, the device <NUM> includes processor(s) <NUM>, at least one removable storage <NUM> and at least one non-removable storage <NUM>, input device(s) <NUM>, output device(s) <NUM>, and transceiver(s) <NUM>.

Aspects of the SMF <NUM>, the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>), the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the AMF <NUM>, the PCF <NUM>, the UDM <NUM>, the DN <NUM>, and the AF <NUM> are discussed above with connection with at least <FIG> and <FIG>. In general, these functions comprise aspects of a fifth generation (<NUM>) mobile network.

In various embodiments, the memory <NUM> is volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. One or more of the SMF <NUM>, the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>), the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the AMF <NUM>, the PCF <NUM>, the UDM <NUM>, the DN <NUM>, and the AF <NUM> stored in the memory <NUM> can comprise methods, threads, processes, applications or any other sort of executable instructions. One or more of the SMF <NUM>, the first and second UPFs <NUM>(<NUM>) and <NUM>(<NUM>), the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the AMF <NUM>, the PCF <NUM>, the UDM <NUM>, the DN <NUM>, and the AF <NUM> can also include files and databases.

In some embodiments, the processor(s) <NUM> is a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or other processing unit or component known in the art.

The device <NUM> also includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Tangible computer-readable media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Memory <NUM>, removable storage <NUM> and non-removable storage <NUM> are all examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs), contentaddressable memory (CAM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the device <NUM>. Any such tangible computer-readable media can be part of the device <NUM>.

The device <NUM> also can include input device(s) <NUM>, such as a keypad, a cursor control, a touch-sensitive display, voice input device, etc., and output device(s) <NUM> such as a display, speakers, printers, etc. These devices are well known in the art and need not be discussed at length here.

Claim 1:
A system comprising:
one or more processors;
a memory; and
one or more components stored in the memory and executable by the one or more processors to perform operations comprising:
establishing (<NUM>) a communication session between a User Equipment, UE, (<NUM>) and a Data Network, DN, (<NUM>), the communication session comprising data traversing a first path between the UE and the DN that includes a first User Plane Function, UPF (<NUM>(<NUM>));
determining (<NUM>, <NUM>) that the first UPF is stressed; and
in response to determining that the first UPF is stressed, migrating (<NUM>, <NUM>) the communication session to a second path between the UE and the DN, the second path including a second UPF (<NUM>(<NUM>)),
wherein migrating the communication session to the second path comprises transmitting a migration request (<NUM>) to the second UPF (<NUM>(<NUM>)), characterised by the migration request instructing the second UPF to transmit at least one indication (<NUM>) of a revised route to at least one of a Radio Access Network, RAN (<NUM>), connected between the UE and the second UPF or the DN, the revised route replacing the first UPF with the second UPF.