Patent Description:
There is provided a method, a non-transitory computer-readable media, a system and a computer program according to the claims.

Described herein are techniques and systems for mobility management for mobile device edge computing. Using techniques described herein, a base station and computing resources to be used by a user equipment (UE), such as a mobile computing device, can be selected based on information, such as an identification of base station(s) that may be used by the UE, and the location and performance of the base station(s) and the computing resources in the telecommunications network. In some examples, when a mobility controller determines to switch the UE from a current base station to a different base station, the computing resources used to perform application processing for an application associated with UE can also be switched. For instance, when the current base station is switched to the different base station, the computing resources used to perform application processing for the UE may be moved to computing resources that are closer to the different base station. In other examples, the mobility controller may determine to delay switching the UE to the different base station if the performance of the mobile application would be better using the current base station and current computing resources compared to using the different base station and different computing resources.

Processing associated with an application (which may be referred to herein as "application processing") can be performed at dynamically determined locations associated with a mobile network. The determination of the location within the network can be based on the location of the mobile device, the location of computing resources in relation to a base station being used by the mobile device, latency measurements within the network, latency specifications of the application (which may be referred to herein as a "target latency"), related latency (e.g., jitter, packet loss, packet delivery rate,. ), the availability of computing resources at a particular location, and the like. Generally, latency refers to the time it takes a packet of data to move from one point within the network to another point within the network.

In some configurations, techniques described herein utilize computing resources, such as server computing devices, deployed at different locations within the mobile network to perform application processing. For instance, server computing devices may be placed at or near a wireless base station (BS), between the base station and other locations within the network, at the core network, at the Internet, or at other locations to provide applications with the computing resources that meet the target latencies of the application.

While computing resources located near or at the base station may provide the lowest latency for application processing, not all applications utilized have the same low target latency specifications. As a result, computing resources can be positioned throughout the network "path" with the applications specifying the lowest target latency specifications to be executed nearer the base station, the applications having the largest target latency specifications farthest away from the edge (e.g., the core network, the Internet), and the applications with target latency specifications between the lowest and largest somewhere between the BS and the farthest location away from the edge. When latency associated with application processing for an application becomes too high at one location, the application processing for the application can be moved to computing resources located at a different location.

To assist in determining what computing resources to use to perform application processing and whether or not to switch base stations, performance measurements may be obtained at different points (i.e., locations) within the network (e.g., one or more locations near the base station, the core network, and the like). In some examples, network probes and/or monitoring systems are placed at various locations within the network to determine network latencies between different measurement points within the network. The latency measurements can be obtained from commercially available network tools and/or from other software/hardware. According to some configurations, the network probes and/or monitoring systems are configured to monitor the network latencies (e.g. continuously and/or at predetermined times).

In some configurations, this live latency information associated with different links in the network can be used to determine the traffic status of the network and/or predict future traffic within the network. This latency information can then be used (e.g., by a mobility controller) to determine the location of where to perform the application processing. In some examples, a mobility controller can perform a live traffic routing calculation to direct network traffic to computing resources located within the network. For example, the mobility controller can locate and/or change the location of application processing between different locations within the network. More details are provided below with regard to FIGS. <NUM>-<NUM>.

<FIG> is a block diagram showing an illustrative environment <NUM> for mobility management for mobile device edge computing. The environment <NUM> may include a telecommunications network <NUM> that is operated by a wireless service provider and one or more other networks coupled to network <NUM>, such as the Internet <NUM> illustrated in <FIG>. The environment <NUM> is illustrated in simplified form and may include many more components.

Generally, mobile edge computing (MEC) refers to performing application processing associated with an application <NUM> using computing resources that are located closer to the UE <NUM> (e.g., nearer the "edge" of the network) to increase the performance of the application. As briefly discussed above, using techniques described herein, a mobility controller <NUM> selects a base station <NUM> and computing resources, such as computing resources <NUM>, to be used to perform application processing <NUM> for a mobile application <NUM> based on the base station <NUM> being used by the UE <NUM> and the location and performance of the computing resources <NUM> in the telecommunications network <NUM>.

The network <NUM> may include one or more base stations <NUM>, such as base station 104A and base station 104B, one or more service nodes <NUM>, and one or more other computing resources <NUM> that may be positioned at various locations within the network <NUM> (e.g., near a base station <NUM>, or at some other location). A base station <NUM> may handle traffic and signals between electronic devices, such as the computing device <NUM> and other computing devices (not shown), and a core network of the network <NUM>. For example, the base station <NUM> may perform the transcoding of speech channels, allocation of radio channels to electronic devices, paging, transmission and reception of voice and data, as well as other functions.

The base station <NUM> may include several base transceiver stations (BTS). A BTS may include a transceiver, antenna, and additional network switch and control equipment that provide a network cell for facilitating wireless communication between computing devices and the core network of the network <NUM>. In some instances, the base station <NUM> may include an eNodeB and/or a gNodeB.

The computing device (UE) <NUM> may be an electronic device such as a smart phone, a personal digital assistant, a netbook, a laptop computer, and/or another electronic device that is capable of sending and/or receiving voice or data via the network <NUM> and/or a Wi-Fi network. For example, the computing device <NUM> can be integrated into a vehicle, a drone, a plane, a bicycle, a mobile device, and the like. In some instances, the computing device <NUM> can be configured to send and receive data using any wired or wireless protocols.

The mobility controller <NUM> is node that is configured to utilize data <NUM>, such as location data (e.g., of the UE <NUM>, base station <NUM>, computing resources <NUM>,. ), latency data associated with the network <NUM>, coverage area data indicating coverage area <NUM> for available base stations <NUM>, performance of computing resources data that can perform processing for the application <NUM>, predicted congestion data of the network, and the like. For example, the mobility controller <NUM> node can determine to switch the base station <NUM> and/or application processing for an application <NUM> to utilize computing resources 112B instead of computing resources 112A when UE <NUM> begins to use base station 104B.

Upon the determination to move the UE <NUM> to use computing resources 112B, that may be within the base station <NUM> or external from the base station <NUM>, the mobility controller <NUM> can move data used for the application processing from computing resource 112A to computing resource 112B. In some examples, the mobility controller <NUM> may determine to use computing resources <NUM> located at other areas within the network <NUM>, e.g., within the core network (e.g., utilizing one or more service nodes <NUM>), at computing resources <NUM> located within a gateway, such as gateway <NUM> illustrated in <FIG>, within the Internet <NUM>, and/or at other locations within the network <NUM>, such as at local services associated with a service node <NUM>.

According to some configurations, the mobility controller <NUM> is configured to perform live traffic routing calculations to assist in determining where to position the application processing for application <NUM>. The mobility controller <NUM> can locate and/or change the location of application processing between different locations within the network <NUM>. While the service nodes <NUM> are illustrated within the network <NUM>, one or more other computing devices may be located outside of the network <NUM>. For example, an application server, or some other server or device, may be connected to the network <NUM> via one or more external packet switched networks, such as the Internet <NUM>.

Application <NUM> may be any type of application. Some example applications include, but are not limited to autonomous vehicle applications, automotive applications, Internet of Things (IoT) applications, monitoring applications, browser applications, messaging applications, voice applications (e.g., Voice over Internet Protocol "VoIP" applications), video applications, and the like.

In the example illustrated by <FIG>, the UE <NUM> at time <NUM> is using base station 104A, that includes coverage area 114A, and computing resources 112A for application processing. Mobility controller <NUM> communicates with base station 104A using link 116A and communicates with computing resources 112A using link 118A. Mobility controller <NUM> communicates with base station 104B using link 116B and communicates with computing resources 112B using link 118B. According to some examples, mobility controller <NUM> determines when to switch the UE <NUM> from base station 104A to 104B and/or the computing resources 112A to other computing resources based on different information.

For instance, the mobility controller <NUM> may base a determination of whether to switch base stations <NUM> and/or computing resources <NUM> based on the location of the UE <NUM>, a projected movement of the UE <NUM>, the location of computing resources in relation to a base station 104A currently being used and/or a base station 104B that may be used by the UE <NUM>, latency measurements within the network <NUM>, latency specifications of the application <NUM>, related latency, the availability of computing resources <NUM> at a particular location, and the like.

As an example, the mobility controller <NUM> may determine to switch from base station 104A to base station 104B, and from computing resources 112A to computing resources 112B, when the performance of the application <NUM> is predicted to be better using computing resources 112B and base station 104B as compared to continuing to use base station 104A and computing resources 112A. In some cases (e.g., within the overlapping first coverage area 114A and second coverage area 114B, the UE <NUM> may either use base station 104A or base station 104B. If the mobility controller <NUM> determines that the performance of the application <NUM> will not be better by switching to base station 104B and/or computing resources 112B, then the mobility controller <NUM> may delay the switch. According to some configurations, UE <NUM> may use computing resources 112A and 112B that are active at the same time to allow for a faster and smoother computing resource hand-off.

<FIG> is a block diagram showing an illustrative environment <NUM> that includes a mobility controller that monitors latencies at different locations within the network. The environment <NUM> is similar to the environment <NUM> of <FIG> but includes additional details. As illustrated, environment <NUM> may include a network <NUM> that is coupled to one or more other networks, such as the Internet <NUM>.

According to some configurations, the base station <NUM> and/or other devices/components within network <NUM> can include probe(s) 222A that are configured to measure latencies associated with the base station <NUM> and/or other components. For example, the probe(s) 222A may determine processing times associated with modules in the base station <NUM>, the upload and download times to the computing device <NUM>, the latency between the base station <NUM> and the service nodes <NUM> located within the core network, and the like. The latencies can be associated with different types of connections, including wired and/or wireless connections.

The core gateway (GW) <NUM> may be responsible for routing voice communication to other networks, as well as routing data communication to external packet switched networks, such as the Internet <NUM>. For example, the one or more service nodes <NUM> may be a Policy and Charging Rules Function (PCRF) node (not shown) that is utilized to enforce policy rules of the network. The PCRF node can be configured to automatically make policy decisions for each subscriber (e.g., each user equipment (UE)) active on the network. For example, the PCRF may be utilized to allocate bandwidth of the network as well as provide different levels of service to different computing devices on the network. In some configurations, the PCRF node can be used to assist in determining the location of where to perform application processing for one or more applications, such as application <NUM>. Additionally, some data can be prioritized within the network.

According to some configurations, the network includes a monitoring node 106B, a local services node 106C, and a node to perform functionality of the mobility controller <NUM>. The monitoring node 106B is configured to measure and/or obtain network measurements (e.g., latency) associated with different locations within the network (e.g., from one or more locations within the base station <NUM>, latency measurements associated with the core network, and the like). In some examples, the monitoring node 106B obtains latency data from network probe(s) <NUM>, and/or other monitoring systems located at different locations within the network <NUM>. The latency measurements can be obtained from commercially available network tools and/or from other software/hardware. According to some configurations, the network probes and/or monitoring systems are configured to continuously monitor the network latencies throughout different locations within the network.

In some examples, the mobility controller <NUM> node is configured to utilize latency data to locate application processing for an application, such as application <NUM>, within the network <NUM>. For example, the mobility controller <NUM> node can position application processing <NUM> for application <NUM> to utilize computing resources 112C within the base station <NUM>, computing resources 112D within the core network (e.g., utilizing one or more service nodes <NUM> such as service node 106A), at computing resources 120E located within the gateway <NUM>, within the Internet <NUM>, and/or at other locations within the network <NUM>, such as at local services associated with node 106C. In some examples, a mobility controller <NUM> is configured to perform live traffic routing calculations to assist in determining where to position the application processing for application <NUM>. The mobility controller <NUM> can locate and/or change the location of application processing between different locations within the network and coordinate the transition from a current base station <NUM> to a different base station <NUM>.

According to some configurations, a client application, such as application <NUM>, on the UE <NUM> may establish data communication with the network <NUM> through a data connection to the base station <NUM>. When a communication request arrives at the network <NUM>, one or more of the service nodes <NUM> may determine the identity of the originating computing device for the communication (e.g., using a telephone number, IMEI, ImsI, IP address) as well as the identity of the computing devices to send the communication. According to some configurations, the application <NUM> on the computing device <NUM> may connect to the service nodes <NUM>, or some other component such as an application server, via the Internet <NUM>. In such instances, the application <NUM> may connect to the Internet <NUM> via Wi-Fi access point <NUM>. Accordingly, data traffic from the application <NUM> may be routed to the service nodes <NUM> by the gateway <NUM> of the network <NUM>.

As briefly discussed above, application processing associated with an application, such as application <NUM>, can be performed at different locations within the network where computing resources, such as computing resources <NUM>. In some configurations, an application <NUM> is associated with a target latency that is used to identify an upper limit for latency associated with processing for the application. An application <NUM> may specify the target latency and/or a target latency can be associated with the application <NUM> based on a type of the application, or some other information indicating the target latency. For example, application <NUM> can specify the target latency (e.g., <NUM>, <NUM>, <NUM>, <NUM>,. ) or the mobility controller <NUM> can determine a type of the application and associate the target latency based on the type of application. Generally, applications <NUM> that utilize real-time data are associated with lower target latencies, whereas applications <NUM> that do not utilize real-time data are associated with higher target latencies.

In some examples, the mobility controller <NUM> can access target latencies associated with application <NUM>. For example, a PCRF node in the service nodes <NUM> may identify that an application <NUM> utilized by computing device <NUM> is a type of application that has a target latency of under <NUM>, and as such, cause the application processing for the application <NUM> to be performed at a location within the network that satisfies the target latency based on the current latency data <NUM> obtained from different locations within the network <NUM>.

According to some configurations, the location of the computing resources <NUM> used for application processing <NUM> for an application <NUM> can be determined by a software component and/or a hardware component that operates within network <NUM>, such as within the core network (e.g., mobility controller <NUM>), or a mobility controller <NUM> that is located at some other location within the network <NUM>.

<FIG> is a block diagram showing an illustrative environment <NUM> that includes a mobility controller <NUM> that uses data obtained from a network to assist in determining the location of computing resources <NUM> to use for application processing <NUM> within the network. The environment <NUM> is illustrated in simplified form and may include many more components.

Environment <NUM> shows computing resources <NUM> available for application processing <NUM> at different locations within a network and the Internet <NUM>. As illustrated, environment <NUM> includes computing resources 112A for application processing 224A at location <NUM> (<NUM>), computing resources 112B for application processing 224B at location <NUM> (<NUM>), computing resources 112C for application processing 224C at location <NUM> (<NUM>), and computing resources 112D for application processing 224D at Internet <NUM>. For purposes of explanation, location <NUM> is closest to the computing device <NUM> (i.e. closest to the "edge" of the network), location <NUM> is second closest to the computing device <NUM>, location <NUM> is third closest to the computing device <NUM>, and location <NUM> is furthest from the computing device <NUM>. Generally, the latency increases as the location is farther from the edge of the network. While four locations are shown, more or fewer locations may be utilized to perform application processing for an application.

As discussed above, mobility controller <NUM> is configured to dynamically determine the location of the computing resources <NUM> to utilize for application processing <NUM>. The determination can be based on different data, such as latency measurements obtained from probe(s) <NUM>, predicted performance data, current availability/predicted availability of computing resources <NUM>, location and/or movement of the UE <NUM>, and the like.

As briefly discussed above, some applications <NUM> have different performance specifications. Some applications <NUM> may have low target latency specifications and some applications have a more flexible target latency specification. Even though application processing <NUM> for an application <NUM> may initially be performed utilizing computing resources <NUM> deployed at one location within the network <NUM>, the application processing <NUM> can be moved to another location based on the current network conditions and/or predicted network conditions. The network conditions may include information such as, but not limited to latencies within the network, availability of computing resources within the network <NUM>, location of the UE <NUM>, location of the base station(s) <NUM> and computing resources <NUM> that may be used by the UE <NUM>.

The mobility controller <NUM> obtains data <NUM>, such as latency data from different locations within the network <NUM>. The latency data can be determined using network probes, such as probe(s) 222A - 222D (which may be referred to herein as "network probes <NUM>"), monitoring systems, and or other hardware/software components. For example, probe(s) 222A can determine latencies associated with the first location. The probe(s) <NUM> can be commercially available probes/monitoring system, internal equipment (BS, PGW/SGW, etc.) Key Performance Indicator (KPI) values, and/or custom hardware/software components. The probe(s) 322A can also be configured to determine the latency between the UE <NUM> to different nodes within the network <NUM> (e.g., an eNodeB that may be located at location <NUM><NUM>, as well as determine other latencies (not shown).

Mobility controller <NUM> receives the data <NUM> and determines one or more locations within the network <NUM> that are capable of performing the application processing <NUM> for the application <NUM> based on the performance specifications associated with the application <NUM>. As an example, assume that application <NUM> has a target latency of <NUM> or less and that the data <NUM> indicates that computing resources 112A and computing resources 112B satisfy the target latency of <NUM>. In this case, the mobility controller <NUM> can select computing resources 112A and/or computing resources 112B to provide the application processing for application <NUM>. For an application that has a higher target latency, such as <NUM>, the mobility controller <NUM> can select any one or more of computing resources 112A - 1312D.

The latency measurements for the network <NUM> can change throughout the day. For example, as the use of the network <NUM> increases/decreases, the latency measurements will fluctuate. As such, some applications having application processing performed at one location (e.g., at location <NUM> (<NUM>) utilizing computing resources 112C) may no longer be reliable to meet the desired target latency of the application. In some configurations, the mobility controller <NUM> monitors (e.g., in real-time) the data <NUM> within the network, the location of the UE <NUM>, and the base station <NUM> being used by the UE <NUM>, and determines the location of where to perform application processing for the applications within the network.

In response to determining a location that meets the application specifications. the mobility controller <NUM> provides instructions to at least one of the locations to instruct the location to perform application processing <NUM> for the application <NUM>.

As briefly discussed above, application processing associated with an application, such as application <NUM>, can be performed at different locations within the network where computing resources <NUM>, such as computing resources 112A - 120E are located. In some configurations, the mobility controller <NUM> and/or some other component determines a target latency associated with the application <NUM>. The target latency identifies an upper limit for latency associated with application processing for the application <NUM>. In some configurations, the application <NUM> specifies the target latency. In other examples, the mobility controller <NUM> determines the type of application. For example, application <NUM> can specify the target latency (e.g., <NUM>, <NUM>, <NUM>, <NUM>,. ) or the mobility controller <NUM> can determine a type of the application and associate the target latency based on the type of application. Generally, applications <NUM> that utilize real-time data are associated with lower target latencies, whereas applications <NUM> that do not utilize real-time data are associated with higher target latencies.

After selecting one or more locations to perform application processing <NUM>, the mobility controller <NUM> can change the selected location for application processing <NUM> for an application. For example, the mobility controller <NUM> can change the location of application processing for an application, such as application <NUM>, based on current latency data <NUM> and/or projected latencies associated with the network.

<FIG> is a block diagram illustrating a system <NUM> that includes a network mobility component <NUM> for selecting and causing application processing to be performed at a location within a network according to some implementations. The system <NUM> includes a terminal <NUM>, which can represent computing device <NUM> of <FIG>, coupled to a server <NUM>, via a network <NUM>. The server <NUM> can represent one or more of the service nodes <NUM>. The network <NUM> can represent, e.g., networks <NUM> or <NUM>, or other networks.

The network <NUM> can include one or more networks, such as a cellular network <NUM>, a data network <NUM>, and a peer to peer (PTP) network <NUM>. The network <NUM> can include one or more core network(s) connected to terminal(s) via one or more access network(s). Example access networks include LTE, WIFI, GSM Enhanced Data Rates for GSM Evolution (EDGE) Radio Access Network (GERAN), UTRAN, and other cellular access networks. Message transmission, reception, fallback, and deduplication as described herein can be performed, e.g., via <NUM>, <NUM>, <NUM>, WIFI, or other networks.

The cellular network <NUM> can provide wide-area wireless coverage using a technology such as GSM, Code Division Multiple Access (CDMA), UMTS, LTE, or the like. Example networks include Time Division Multiple Access (TDMA), Evolution-Data Optimized (EVDO), Advanced LTE (LTE+), <NUM> New Radio (NR), Device-To-Device (D2D), Vehicle-To-Everything (V2X) direct communication, Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Orthogonal Frequency Division Multiple Access (OFDM), GPRS, EDGE, Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), VoIP, VoLTE, IEEE <NUM>. 1x protocols, wireless microwave access (WIMAX), WIFI, and/or any future IP-based network technology or evolution of an existing IP-based network technology. Communications between the server <NUM> and terminals such as the terminal <NUM> can additionally or alternatively be performed using other technologies, such as wired (Plain Old Telephone Service, POTS, or PSTN lines), optical (e.g., Synchronous Optical NETwork, SONET) technologies, and the like.

The data network <NUM> can include various types of networks for transmitting and receiving data (e.g., data packets), including networks using technologies such as WIFI, IEEE <NUM>. <NUM> ("BLUETOOTH"), Asynchronous Transfer Mode (ATM), WIMAX, and other network technologies, e.g., configured to transport IP packets. In some examples, the server <NUM> includes or is communicatively connected with an IWF or other device bridging networks, e.g., LTE, <NUM>, and POTS networks. In some examples, the server <NUM> can bridge SS7 traffic from the PSTN into the network <NUM>, e.g., permitting PSTN customers to place calls to cellular customers and vice versa.

In some examples, the cellular network <NUM>, the data network <NUM>, and the P2P network <NUM> can carry voice or data. For example, the data network <NUM> can carry voice traffic using VoIP or other technologies as well as data traffic, or the cellular network <NUM> can carry data packets using HSPA, LTE, or other technologies as well as voice traffic. The P2P network <NUM> can carry signaling/data traffic from neighboring devices/network in a mesh-like communication such as Skype, or a direct communication such as D2D, vehicle-to-everything (V2X) messages, and the like. Some cellular networks <NUM> carry both data and voice in a packet-switch (PS) format. For example, many LTE networks carry voice traffic in data packets according to the VoLTE standard. Various examples herein provide origination and termination of, e.g., carrier-grade voice calls on, e.g., networks <NUM> using circuit-switching (CS) transports or mixed VoLTE/<NUM> transports, or on terminals <NUM> including OEM handsets and non-OEM handsets.

The terminal <NUM> can be or include a wireless phone, a wired phone, a tablet computer, a laptop computer, a wristwatch, or other type of terminal. The terminal <NUM> can include one or more processors <NUM>, e.g., one or more processor devices such as microprocessors, microcontrollers, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), programmable logic arrays (PLAs), programmable array logic devices (PALs), or digital signal processors (DSPs), and one or more computer readable media (CRM) <NUM>, such as memory (e.g., random access memory (RAM), solid state drives (SSDs), or the like), disk drives (e.g., platter-based hard drives), another type of computer-readable media, or any combination thereof. The CRM or other memory of terminal <NUM> can hold a datastore, e.g., an SQL or NoSQL database, a graph database, a BLOB, or another collection of data. The terminal <NUM> can further include a user interface (UI) <NUM>, e.g., including an electronic display device, a speaker, a vibration unit, a touchscreen, or other devices for presenting information to a user and receiving commands from the user. The terminal <NUM> can further include one or more network interface(s) <NUM> configured to selectively communicate (wired or wirelessly) via the network <NUM>, e.g., via an access network <NUM> or <NUM>, <NUM>.

The CRM <NUM> can be used to store data and to store instructions that are executable by the processors <NUM> to perform various functions as described herein. The CRM <NUM> can store various types of instructions and data, such as an operating system, device drivers, etc. The processor-executable instructions can be executed by the processors <NUM> to perform the various functions described herein.

The CRM <NUM> can be or include 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 (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, non-transitory medium which can be used to store the desired information and which can be accessed by the processors <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 components, or other data.

The CRM <NUM> can include processor-executable instructions of a client application <NUM>. The client application <NUM>, e.g., a native or other dialer, can permit a user to originate and terminate communication sessions associated with the terminal <NUM>, e.g., a wireless phone. The client application <NUM> can additionally or alternatively include an SMS, RCS, or presence client, or a client of another telephony service offered by the server <NUM>. The client application <NUM> can also be any other type of application, such as application <NUM> described herein.

The CRM <NUM> can store information <NUM> identifying the terminal <NUM>. The information <NUM> can include, e.g., an IMEI, an IMSI identifying the subscriber using terminal <NUM>, or other information discussed above. The CRM <NUM> can additionally or alternatively store credentials (omitted for brevity) used for access, e.g., to IMS or RCS services.

The server <NUM> can include one or more processors <NUM> and one or more CRM <NUM>. The CRM <NUM> can be used to store processor-executable instructions of a network mobility component <NUM>, as well as one or more other components <NUM>. In some configurations, the server <NUM> can be configured as a network mobility controller <NUM>, a monitoring node 106B, and the like. The processor-executable instructions can be executed by the one or more processors <NUM> to perform various functions described herein, e.g., with reference to <FIG>, and <FIG>.

In some examples, server <NUM> can communicate with (e.g., is communicatively connectable with) terminal <NUM> or other devices via one or more communications interface(s) <NUM>, e.g., network transceivers for wired or wireless networks, or memory interfaces. Example communications interface(s) <NUM> can include ETHERNET or FIBER CHANNEL transceivers, WIFI radios, or DDR memory-bus controllers (e.g., for DMA transfers to a network card installed in a physical server <NUM>).

In some examples, processor <NUM> and, if required, CRM <NUM>, are referred to for brevity herein as a "control unit. " For example, a control unit can include a CPU or DSP and instructions executable by that CPU or DSP to cause that CPU or DSP to perform functions described herein. Additionally, or alternatively, a control unit can include an ASIC, FPGA, or other logic device(s) wired (physically or via blown fuses or logic-cell configuration data) to perform functions described herein. Other examples of control units can include processor <NUM> and, if required, CRM <NUM>.

In the flow diagrams of <FIG> and <FIG>, each block represents one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, cause the processors to 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 blocks 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. For discussion purposes, the processes <NUM> and <NUM> are described with reference to the systems <NUM>, <NUM>, <NUM>, and <NUM> as described above, although other models, frameworks, systems and environments may implement these processes.

<FIG> is a flow diagram of an example process <NUM> that includes determining a base station <NUM> and computing resources <NUM> to be used by a UE <NUM>. The process <NUM> may be performed by one or more computing devices, such as the computing devices described with regard to <FIG>.

At <NUM>, the base station(s) <NUM> that may be used by the UE <NUM> may be determined. As discussed above, a UE <NUM> may move within network <NUM> and may be within a coverage area <NUM> of one or more base stations <NUM>. In some cases, a prediction may be determined by the mobility controller <NUM>, or some other device/component, that the UE <NUM> is moving from coverage area 114A of base station 104A to coverage area 114B of base station 104B.

At <NUM>, application specifications may be determined for an application <NUM>. As discussed above, the application <NUM> may be any type of application. For example, application <NUM> can be associated with autonomous driving, augmented reality, virtual reality, monitoring networks, video streaming, voice calls, or any other type of application. Some applications <NUM> specify a low target latency, whereas other applications specify a higher target latency. Generally, applications <NUM> that utilize real-time data are associated with lower target latencies, whereas applications <NUM> that do not utilize real-time data are associated with higher target latencies. According to some configurations, application <NUM> defines the target latency. In other configurations, the mobility controller <NUM> identifies the target latency based on a type of the application <NUM>. In some configurations, the mobility controller <NUM> accesses a table, or some other data, that indicates a target latency with the type of application <NUM>.

At <NUM>, computing resources <NUM> that can be used by the UE <NUM> to perform application processing <NUM> for an application <NUM> can be identified. As discussed above, the computing resources <NUM> may be located near a base station <NUM>, and/or at some other location within the network <NUM>.

At <NUM>, network performance at different computing resource <NUM> locations can be determined. As discussed above, network performance data, such as latency measurements can be obtained from different locations within the network <NUM>. In some examples, network probes <NUM> and/or monitoring systems are placed at various locations within the network (e.g., base station, core network, gateway,. ) to determine network latencies between different points within the network <NUM>. The latency measurements can be obtained from commercially available network tools and/or from other software/hardware. According to some configurations, the network probes <NUM> and/or monitoring systems are configured to monitor the network latencies (e.g. continuously and/or at predetermined times and provide latency data <NUM> to mobility controller <NUM>. As discussed above, the mobility controller <NUM>, or some other component, can calculate the latencies associated with different locations within the network using the latency data <NUM> obtained from the network probe(s) <NUM> and/or monitoring systems.

At <NUM>, a base station and computing resource location may be selected to perform application processing associated with the application <NUM>. As discussed above, the mobility controller <NUM> determines what base stations that may be used by the UE <NUM>, receives the data <NUM> and determines one or more locations within the network for performing the application processing <NUM> for the application <NUM>. Generally, the mobility controller <NUM> selects the location for application processing that meets the target latency of the application. Generally, the lower the target latency, the nearer the base station <NUM> and processing for the application <NUM> will be to the computing device <NUM>. (See <FIG> for more details).

At <NUM>, the base station <NUM> and selected computed resources <NUM> within the network <NUM> is utilized to perform processing for the application <NUM>. As discussed above, the mobility controller <NUM> provides instructions <NUM> to the selected location(s) to cause the computing resources <NUM> associated with the selected location(s) to perform the application processing <NUM>.

<FIG> is a flow diagram of an example process <NUM> that includes identifying a location in a network to perform application processing according to some implementations. The process <NUM> may be performed by one or more computing devices, such as the computing devices described with regard to <FIG>.

At <NUM>, possible base station(s) <NUM> and computing resources <NUM> to perform application processing are identified. As discussed above, a base station <NUM> used by the UE <NUM> may be selected with many different locations within the network <NUM>, and/or external from the network, can include computing resources <NUM> for performing application processing <NUM>. For example, a mobile network service provider may position computing resources throughout the network <NUM> and utilize available computing resources <NUM> outside of the network (e.g., Internet <NUM>) to perform application processing <NUM>. For instance, the locations can include but are not limited to computing resources <NUM> located at/near base stations, gateways, core network, and the like.

At <NUM>, a base station <NUM> and computing resource location <NUM> is selected from the identified computing resource locations. As discussed above, the mobility controller <NUM> selects one of the identified base station(s) <NUM> and locations such that a determination can be made as to whether the selected base station and location satisfies the application specifications such as a target latency. According to some configurations, the mobility controller <NUM> first selects a possible base station <NUM> for the UE <NUM> and the location nearest to the UE <NUM> which is near the edge of the network (e.g., the location having the smaller latency), and then the next location farther from the UE <NUM> is selected. The mobility controller <NUM> may repeat this for other possible base station(s) <NUM>. In other examples, the ordering of the selection can be changed (e.g., random, farthest location from the edge to nearest to the edge,.

At <NUM>, a determination is made as to whether the selected base station and computing resource location satisfies the application <NUM> specifications. When the selected base station <NUM> location <NUM> satisfies the application <NUM> specifications, the process moves to <NUM>. When the selected location does not satisfy the application <NUM> specifications, the process returns to <NUM> where another location is selected.

At <NUM>, the base station <NUM> and computing resource location <NUM> is identified as satisfying the application <NUM> specifications. As discussed above, one or more base station(s) <NUM> and locations <NUM> may satisfy the application <NUM> specifications. In some configurations, the process returns to <NUM> if there are additional base stations/locations that have not been checked to determine as to whether or not the base station/location satisfies the application <NUM> specifications. In other examples, the process moves to <NUM> when a base station and one or more of the locations satisfying the target latency are selected to perform the application processing for application <NUM>.

At <NUM>, a base station and one or more locations are selected to perform application processing <NUM> for the application <NUM>. As discussed above, one or more locations inside or outside of the network <NUM> can be selected to perform the application processing in combination with a base station <NUM> selected for the UE <NUM>. In some examples, the mobility controller <NUM> can select a location nearer the edge based on anticipated traffic within the network. For example, the mobility controller <NUM> identifies that the network is becoming more congested and selects a location nearer to the computing device <NUM>. In yet other configurations, the application processing <NUM> can be divided between different locations.

The various techniques described above are assumed in the given examples to be implemented in the general context of computer-executable instructions or software, such as program components, that are stored in computer-readable storage and executed by the processor(s) of one or more computers or other devices such as those illustrated in the figures. Generally, program components include routines, programs, objects, components, data structures, etc., and define operating logic for performing particular tasks or implement particular abstract data types.

Other architectures may be used to implement the described functionality and are intended to be within the scope of this disclosure. Furthermore, although specific distributions of responsibilities are defined above for purposes of discussion, the various functions and responsibilities might be distributed and divided in different ways, depending on particular circumstances.

Similarly, software may be stored and distributed in various ways and using different means, and the particular software storage and execution configurations described above may be varied in many different ways. Thus, software implementing the techniques described above may be distributed on various types of computer-readable media, not limited to the forms of memory that are specifically described.

Claim 1:
A computer-implemented method performed by one or more processors of a mobility controller (<NUM>) configured with specific instructions, the computer-implemented method comprising:
determining, by the mobility controller, that a user equipment (UE (<NUM>)), associated with a first base station (104A) within a network affiliated with a wireless service provider, is within a coverage area (114B) of a second base station (104B), wherein the UE is using first computing resources (112A) at a first location within the network to perform application processing (<NUM>) for an application (<NUM>) associated with the UE;
determining, by the mobility controller and from a plurality of locations associated with the network, second computing resources (112B) at a second location to perform the application processing (<NUM>) for the application;
obtaining, by the mobility controller and from probes (<NUM>, 222A-222D) at different locations within the network, latency data for the different locations; and
determining, by the mobility controller, based at least in part on a first performance level associated with the application processing using the first computing resources and a second performance level associated with a use of the second computing resources to perform the application processing for the application, and based on the latency data, to perform one or more operations, including:
switching from the first base station to the second base station; and
selecting the second computing resources to perform the application processing for the application,
wherein the mobility controller is separate and distinct from the UE, the first base station, and the second base station;
wherein the determining to perform one or more operations is further based on a projected movement of the UE (<NUM>), and the locations of computing resources in relation to the first base station (104A) currently being used and the second base station (104B).