Orchestrate the migration of edge computing resources

Abstract

The present invention relates to a system configured as an orchestration function for a mobile network, wherein the mobile network includes edge nodes configurable to provide edge computing resources to mobile devices, wherein the system is configured to, at least in part, orchestrate the migration of edge computing resources for the mobile device from a first edge node to a second edge node. The orchestration function interacts with the mobile device to enable the orchestration function to initiate the migration of the edge computing resources in a timely manner.

Description

Technical Field

[0001] The present invention relates to a system configured for orchestration functionality of a mobile network, wherein the mobile network includes edge nodes configurable to provide edge computing resources to mobile devices, wherein the system is configured to orchestrate, at least in part, the migration of edge computing resources for the mobile device from a first edge node to a second edge node. The present invention further relates to a computer-implemented method for orchestrating, at least in part, the migration of edge computing resources for the mobile device from the first edge node to the second edge node. The present invention further relates to the mobile device and a computer-implemented method for use with the mobile device.

[0002] The invention further relates to a computer-readable medium comprising transitory or non-transitory data representing a computer program comprising instructions for causing a processor system to perform one of these methods. Background Art

[0003] Edge computing (or Multi-access Edge Computing (MEC) as proposed by the ETSI industry specification group) generally involves edge nodes at the 'edge' of a telecommunications network providing computing resources to clients of the network. For this purpose, edge nodes can be arranged into an 'edge cloud', where computing resources are provided to clients using the cloud computing paradigm, but edge nodes can also individually provide such computing resources to clients.

[0004] Since the edge is located relatively close to the client, the available edge computing resources (e.g., computing, content, or a combination of both) have high bandwidth, low latency, and high availability. These characteristics make edge computing an enabler for demanding applications on mobile networks.

[0005] A typical use case for edge computing involves offloading computing functions to the edge. For example, a mobile client can upload raw data to the edge, where it can be processed and forwarded to a central cloud. The advantage of such edge computing is that the mobile client (which can be battery-powered) does not require significant computing power, and processing at the edge avoids having to send the raw data to the central cloud, thereby reducing the load on the backhaul network.

[0006] An example use case for edge computing is a connected vehicle (CV). A CV may be equipped with numerous sensors that acquire sensor data. The CV can upload this sensor data, which can be characterized as a high-bandwidth, continuous, high-speed stream, to the edge cloud. In the edge cloud, this data can be analyzed and transmitted to other nearby vehicles. Interpreted information can be forwarded to a central cloud for storage in the form of metadata. Depending on the CV's environment (e.g., location, weather) or specific needs, the CV may transmit different sensor data, requiring different analyses at the edge.

[0007] To provide the necessary network performance for edge computing, the client and the edge node(s) need to be near each other in the network, which can be characterized in terms of latency, number of hops, and / or more indirectly in terms of bandwidth. This network proximity is often, but not necessarily, reflected in the geographic proximity between the client and the edge node(s).

[0008] For example, in mobile networks where mobile devices act as clients (also known as user equipment, UE), high bandwidth and (ultra) low latency access to computing resources is usually only available when the computing resources are located near radio access points. Deploying edge computing resources for fixed UEs can be considered simple. However, for mobile clients, the computing resources may have to travel with the UE to an edge node near the UE. For example, Figure 1 As shown in , a mobile UE can move between base stations located along its route, wherein the radio communication of the mobile UE can be handed off from one base station to another. A first group of base stations can be served by edge node 1 because these base stations can each have a high-bandwidth network connection to edge node 1. However, as the UE travels further along the route, the UE's radio communication may be handed off to a base station served by another edge node. In this way, edge computing resources may have to be migrated to the new edge node in order to still provide the necessary network performance for edge computing.

[0009] For example, migration of edge computing resources may involve obtaining a virtual machine (VM) image, instantiating the VM, transferring the VM state from a source edge to a destination edge, and updating network routing to the VM.

[0010] In high-mobility scenarios (e.g., when the UE moves at high speeds and / or edge nodes only serve a small area), computing resources for the UE may have to be frequently migrated between edge nodes. When the destination edge node is not prepared for the migration (e.g., it does not have the VM image and / or application state), the migration may have to be temporarily delayed. During this time, network traffic may continue to be routed to the previous edge node, burdening the backhaul network with high-bandwidth traffic and / or providing degraded performance to the UE, as the UE may experience increased latency and reduced bandwidth.

[0011] It is well known that edge computing resources are proactively deployed at new edge nodes in an attempt to minimize unnecessary backhaul load and degraded performance.

[0012] In [1], [2], and [3], proactive provisioning is done by preloading VMs on edges close to the current edge. To avoid starting too many VMs, mobility prediction can be used. Mobility prediction can be based on the serving base station, the serving edge node, or GPS information, which can be based on actual or historical mobility traces. [4] follows a similar principle, but uses mobility prediction to place portions of content on different edge nodes next to the expected path.

[0013] Unfortunately, the mobility predictions of [1] to [4] may be based on assumptions about the UE's mobility, which may be inaccurate. As a result, proactive provisioning may be suboptimal because it may be too early or too late to provision edge computing resources at edge nodes, given the actual mobility of the UE.

[0014] References:

[0015] [1] Sun, X., & Ansari, N. (2016). EdgeIoT: Mobile edge computing for the Internet of Things. IEEE Communications Magazine , 54 (12), 22-29 [Sun,X., & Ansari, N. (2016). EdgeIoT: Mobile edge computing for the Internet of Things. IEEE Communications Magazine, 54(12), 22-29].

[0016] [2] Farris, I., Taleb, T., Flinck, H., & Iera, A. (2018). Providingultra-short latency to user-centric 5G applications at the mobile network edge. Transactions on Emerging Telecommunications Technologies , 29 (4), e3169[Farris, I., Taleb, T., Flinck, H., & Iera, A. (2018). Providing ultra-low latency for user-centric 5G applications at the edge of mobile networks. Transactions on Emerging Telecommunications Technologies, 29(4), e3169].

[0017] [3] Plachy, J., Becvar, Z., & Strinati, EC (2016, September). Dynamic resource allocation exploiting mobility prediction in mobile edgecomputing. In 2016 IEEE 27th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC) (pp. 1-6). IEEE [Plachy, J.,Becvar, Z., & Strinati, EC (September 2016). Dynamic Resource Allocation Leveraging Mobility Prediction in Mobile Edge Computing. In 2016 IEEE 27th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC) (pp. 1-6). IEEE].

[0018] [4] Mathew, N. (2017). US Patent Application No. 15 / 191,190 [Mathew, N. (2017). U.S. Patent Application No. 15 / 191,190]. Summary of the Invention

[0019] The migration of edge computing resources may need to be orchestrated to better account for the mobility of mobile devices.

[0020] The following measures provide a system for providing orchestration functionality in a mobile network and a complementary mobile device. These two entities can collaborate to enable the orchestration function to at least partially orchestrate the migration of edge computing resources for the mobile device. To this end, the fact that the mobile device can follow a certain route can be exploited, which can be predicted, for example, using the aforementioned network-based mobility prediction or by obtaining a planned route of the mobile device. The orchestration function can obtain this route, for example, in a computer-readable form. Furthermore, the orchestration function can identify so-called migration points, for example based on its understanding of the network topology. These migration points can represent geographical locations where migration of edge computing resources from one edge node to another may be required. Rather than waiting for the mobile device to reach or even pass through the migration point before reactively initiating migration, the migration point can be provided to the mobile device so that the mobile device can provide an 'advance warning' notification to the orchestration function before the mobile device reaches the migration point. In response to such a notification, the orchestration function can then proactively initiate the migration of edge computing resources between edge nodes.

[0021] In a first aspect of the present invention, a system may be configured to orchestrate functionality for a mobile network, wherein the mobile network may include edge nodes configurable to provide edge computing resources to mobile devices. The system may include:

[0022] - a network interface with the mobile network;

[0023] - A processor subsystem that can orchestrate, at least in part, the migration of edge computing resources for a mobile device from a first edge node to a second edge node by being configured to:

[0024] - obtaining route data indicating a route along which the mobile device is predicted to travel;

[0025] - based on the route data, identifying one or more migration points along the route, the one or more migration points defining respective geographic locations at which the second edge node is expected to have better bandwidth and / or latency for the mobile device than the first edge node;

[0026] - sending migration data to the mobile device via the network interface, the migration data indicating the one or more migration points;

[0027] - receiving, via the network interface, an initiation message from the mobile device, the initiation message indicating a notification that the mobile device is expected to arrive at a corresponding migration point among the migration points; and

[0028] - Based on the initiation message, start migrating the edge computing resource from the first edge node to the second edge node.

[0029] In another aspect of the present invention, a mobile device for a mobile network may be provided, wherein the mobile network may include an edge node configurable to provide edge computing resources to the mobile device. The mobile device may include:

[0030] - a network interface for wirelessly connecting to the mobile network via a corresponding base station of the mobile network;

[0031] - A processor subsystem that can be configured to:

[0032] - receiving, via the network interface, migration data from an orchestration function of the mobile network, wherein the migration data may indicate one or more migration points along a route along which the mobile device is predicted to travel, the one or more migration points defining respective geographic locations at which the second edge node is predicted to have better bandwidth and / or latency for the mobile device than the first edge node;

[0033] - Based on the migration data and the current geographic location of the mobile device, sending an initiation message to the orchestration function before reaching a corresponding migration point among the migration points, wherein the initiation message can be configured to trigger the orchestration function to start the migration of the edge computing resource from the first edge node to the second edge node.

[0034] In yet another aspect of the present invention, a computer-implemented method for orchestrating, at least in part, migration of edge computing resources for a mobile device from a first edge node to a second edge node in a mobile network may be provided, the mobile network including an edge node configurable to provide edge computing resources to the mobile device, wherein the method may include:

[0035] - obtaining route data indicating a route along which the mobile device is predicted to travel;

[0036] - based on the route data, identifying one or more migration points along the route, the one or more migration points defining respective geographic locations at which the second edge node is expected to have better bandwidth and / or latency for the mobile device than the first edge node;

[0037] - sending migration data to the mobile device, the migration data indicating the one or more migration points;

[0038] - receiving an initiation message from the mobile device, the initiation message indicating a notification that the mobile device is expected to arrive at a corresponding one of the migration points; and

[0039] - Based on the initiation message, start migrating the edge computing resource from the first edge node to the second edge node.

[0040] In yet another aspect of the present invention, a computer-implemented method for use with a mobile device for a mobile network may be provided, wherein the mobile network may include an edge node configurable to provide edge computing resources to the mobile device. The method may include:

[0041] - receiving migration data from an orchestration function of the mobile network, wherein the migration data may indicate one or more migration points along a route along which the mobile device is predicted to travel, the one or more migration points defining respective geographic locations at which the second edge node is predicted to have better bandwidth and / or latency for the mobile device than the first edge node;

[0042] - Based on the migration data and the current geographic location of the mobile device, sending an initiation message to the orchestration function before reaching a corresponding migration point among the migration points, wherein the initiation message can be configured to trigger the orchestration function to start the migration of the edge computing resource from the first edge node to the second edge node.

[0043] In another aspect of the present invention, a computer-readable medium may be provided, which may include transient or non-transient data representing a computer program. The computer program may include instructions for causing a processor system to execute individual methods of the aforementioned methods.

[0044] As briefly explained above, the above measures take advantage of the fact that mobile devices can follow routes that can be predicted. For example, known techniques for network-based mobility prediction can be used to predict the route of a mobile device, for example by extrapolating past route data. Another example is that a mobile device can be expected to follow a route planned by a route planning component. In a specific example, a passenger of a networked vehicle may have entered a destination for navigation guidance purposes, or in the case of an autonomous vehicle, enable the autonomous vehicle to drive autonomously to the destination. This route can be obtained and used through the network and, in particular, by the orchestration function to more accurately predict which geographical locations along the route may require edge migration. These geographical locations can then be transmitted to the mobile device, for example, in the form of migration data.

[0045] The mobile device can then provide the orchestration function with advance warning notification of the upcoming migration point before reaching such a migration point. This advance warning notification, in the form of an initiate message, can allow the orchestration function to begin the migration of edge computing resources, such as by instantiating a virtual machine (VM) from a VM image, initiating the transfer of the VM's state from the first edge node to the second edge node, and the like.

[0046] More specifically, the orchestration function may identify these geographic locations as corresponding migration points. A migration point may represent a geographic location where another edge node is expected to better serve the mobile device than the edge node that previously served the mobile device. Here, the term 'better served' may be expressed as the new (second) edge node being able to provide the mobile device with higher bandwidth and / or lower latency than the previous (first) edge node. Furthermore, 'edge node that previously served the mobile device' may refer to an edge node that served the mobile device before reaching the migration point. It should be noted that these migration points may be predicted along the route, and therefore, this edge node may not yet be serving the mobile device but may be predicted to serve the mobile device in the future as the mobile device further along the planned route.

[0047] Obtaining route data by the orchestration function may enable the orchestration function to predict migration points. However, simply by knowing the migration points, the orchestration function may not yet be able to optimally time the start of the migration. That is, it may not yet be known when the mobile device will arrive at the migration point. For example, a simple extrapolation of the previous speed of the mobile device by the network may not be sufficient because, for example, the speed of the vehicle may change due to congestion. By providing the migration points to the mobile device, the mobile device may be able to provide an advance warning notification to the orchestration function before arriving at the corresponding migration point and thereby enable the orchestration function to start the migration of edge computing resources at an appropriate time. In other words, rather than attempting to predict when the mobile device will arrive at a migration point along the route, the network and more specifically the orchestration function may be configured to collaborate with the mobile device such that knowledge of the mobile device, for example, the time of arrival at the migration point, can be used to optimally time the start of the migration of the edge computing resources.

[0048] Thus, a mobile device can be enabled to trigger the migration of edge computing resources at the appropriate moment without having to understand the intricacies of the migration. Instead, the mobile device can be provided with one or more geographic locations and configured to notify the orchestration function before arriving at the corresponding geographic location. Such information is generally available to the mobile device or can be easily generated, for example, using the same technology used to plan routes.

[0049] Compared to the mobility prediction of [1] to [4], the timing of starting the migration of edge computing resources may be better because the migration can be started before the migration point is reached rather than after the migration point has been reached (at which point it may be too late to start the migration). In addition, the start of the migration can be based on the current location of the mobile device relative to the migration point, which may be more accurate than timing the start of the migration without the current location of the mobile device. However, the orchestration function itself does not need to know the current location of the mobile device (for example, in terms of GPS coordinates), but the mobile device itself can trigger the start of the migration based on its current location. Therefore, it may not be necessary to transmit GPS coordinates, etc. from the mobile device to the orchestration function.

[0050] The following embodiments are described with reference to a system and corresponding computer-implemented method for providing orchestration functionality in a network, but may represent corresponding embodiments of a mobile device and a computer-implemented method for use with the mobile device.

[0051] In an embodiment, the processor subsystem may be configured to obtain route data from a mobile device via a network interface, wherein the route data may indicate a planned route for the mobile device. Accordingly, instead of obtaining route data from elsewhere, such as from a network-based mobility prediction, the orchestration function may obtain route data directly from the mobile device. That is, the mobile device may have such route data available or may easily generate such route data if the mobile device is planned to travel on a route. For example, when the mobile device is a connected vehicle or part of such a connected vehicle, a passenger of the connected vehicle may have entered a destination for navigation guidance purposes, and a local or online route planning component may then generate a route to the destination for the connected vehicle. Thus, the planned route may indicate a route that the connected vehicle is predicted to travel along. It should be noted that, in general, a planned route may be a form of predicted route, as it is possible for the mobile device to travel along the planned route, but it may still deviate from this route. By obtaining route data indicating the planned route of the mobile device from the mobile device itself, a more accurate prediction may be obtained, for example, when the route of the mobile device is not simply an extrapolation of its previous trajectory. For example, when using a mobile device in a vehicle driving around along city streets, the vehicle may make various turns through which the vehicle's actual route may frequently deviate from a simple extrapolation of its previous trajectory. Compared to the mobility predictions of [1] to [4], edge computing resources can be migrated to more accurately selected edge nodes because the accuracy of the predicted route may be better. This can avoid unnecessary resource allocation at other edge nodes and / or can ensure that migration to the correct edge node is performed.

[0052] In an embodiment, a mobile device may connect to a network via a corresponding base station, and the processor subsystem may be configured to determine a migration point as a corresponding geographic location where a handover from one base station to another is expected to occur, and where, after the handover, the second edge node is expected to have better bandwidth and / or latency for the mobile device at these geographic locations than the first edge node. In many cases, the need to migrate edge computing resources may be triggered by the mobile device being handed off from one (e.g., a first) base station to another (e.g., a second) base station. That is, while the first base station may be best served by the first edge node (or first set of edge nodes), the second base station may be best served by the second edge node (or second set of edge nodes). Accordingly, when the mobile device connects to the second base station, it may be preferred that the edge computing resources be provided by the second edge node rather than the first edge node.

[0053] Accordingly, the orchestration functionality may be configured to determine migration points as geographic locations at which a handover from one base station to another is expected to occur and at which migration of edge computing resources is expected to be required given that the second edge node, when connected to the second base station, is able to better serve the mobile device, e.g., in terms of bandwidth and / or latency, than the previously serving edge node.

[0054] In an embodiment, the processor subsystem may be configured to:

[0055] - determining a time at which the mobile device sends the initiation message, wherein the time is defined as a period of time before reaching a corresponding one of the migration points; and

[0056] - providing the time period to the mobile device.

[0057] According to this embodiment, the orchestration function can determine the time when the mobile device is to send a prior warning notification, for example in the form of an initiation message, that is, as a time period before arriving at the corresponding migration point. For example, the orchestration function can specify that the mobile device is to send a prior warning notification 5 minutes or 1 minute or 30 seconds or 10 seconds, etc. before arriving at the corresponding migration point. The mobile device itself can estimate when it should arrive at the migration point, for example based on a simple extrapolation of its current speed or based on an estimate of the route planning component, and can therefore send the prior warning notification in time. Accordingly, the orchestration function can start the migration of edge computing resources at a more optimal moment, for example, not too early to avoid unnecessary resource allocation and not too late to avoid that the mobile device has to continue to use the first edge node and thereby be affected by high latency and / or low bandwidth.

[0058] In an embodiment, the processor subsystem may be configured to determine the time based on the type of edge computing resource to be migrated to the second edge node. The migration of edge computing resources may take time, which may depend on the type of edge computing resource. For example, if a relatively large VM is to be transferred, this may take more time than if only the current state of the VM is to be transferred. In order to be able to complete the migration at the appropriate time, the orchestration function may determine the time at which the mobile device is to send a prior warning notification before arriving at the migration point based on the type of edge computing resource to be migrated. This may allow the migration of different types of edge computing resources to be started and completed in a timely manner.

[0059] In an embodiment, the processor subsystem may be configured to, in response to changes in the network infrastructure or network resource configuration:

[0060] - redetermining one or more migration points based on changes in the network infrastructure or network resource allocation, thereby obtaining updated migration data; and

[0061] - Sending the updated migration data to the mobile device.

[0062] Changes in network infrastructure or network resource allocation may affect the ability of edge nodes to provide services to mobile devices. The orchestration function can be aware of these changes, for example, based on communications with other network functions, and can therefore redetermine migration points based on these changes, for example, continuously or periodically, or in response to change notifications. For example, if a second edge node experiences high resource allocation (due to which the first edge node will continue to better serve the mobile device even after the initial migration point), the initial migration point can simply be deleted. Another example is that changes in network infrastructure may mean that additional edge nodes have become available along a route where no migration points were previously planned. Accordingly, migration points can be added along that route.

[0063] In an embodiment, the processor subsystem can be configured to send resource data to the mobile device in response to the initiation message, the resource data identifying a second edge node to which the edge computing resource is to be migrated. To facilitate the migration to the second edge node, the orchestration function can identify the second edge node to the mobile device, for example, by specifying a network address or similar type of network identifier. Accordingly, the mobile device can timely reroute its traffic, for example, by sending raw sensor data to be processed from the first edge node to the second edge node, which can further facilitate seamless migration.

[0064] In an embodiment, the processor subsystem may be configured to initiate the migration of edge computing resources from a first edge node to a second edge node by transferring a virtual machine image of the virtual machine from the first edge node to the second edge node. Due to the size of the virtual machine image, transferring the virtual machine image may take time. By responding to an advance warning notification received from the mobile device and thus initiating the transfer of such an image before the mobile device actually reaches the migration point, the transfer may be complete or at least well underway by the time the migration point is reached. This may further facilitate seamless migration.

[0065] In an embodiment, the processor subsystem may be further configured to perform at least one of the group of the following:

[0066] - Transmitting the state of the virtual machine from the first edge node to the second edge node;

[0067] - Starting a virtual machine on the second edge node based on the virtual machine image; and

[0068] - Reroutes the mobile device's network traffic from the first edge node to the second edge node.

[0069] In addition to or in lieu of transmitting the virtual machine image, the orchestration function can also take any of the actions mentioned above, alone or in combination, in response to receiving the advance warning notification from the mobile device.

[0070] The following embodiments are described with reference to mobile devices and computer-implemented methods for use with the mobile devices, but may represent corresponding embodiments of systems and corresponding computer-implemented methods that provide orchestration functionality in a network.

[0071] In an embodiment, the initiation message may include at least one of the group of the following items:

[0072] - The identification or representation of the edge computing resource;

[0073] - Expected migration point;

[0074] - the absolute or relative time of arrival at the migration point; and

[0075] - The current geographic location of the mobile device.

[0076] Including these types of data in the initiation message can assist the orchestration function in orchestrating the migration of edge computing resources. For example, the mobile device can identify the edge computing resources being used, for example in terms of type, which can enable the orchestration function to adapt the migration to the edge computing resources. Another example is that the mobile device can explicitly indicate the migration point to be reached, which can avoid the orchestration function having to estimate which migration point to be reached in other ways. Yet another example is that the absolute or relative time of arrival at the migration point can assist the orchestration function in starting the migration in a timely manner, for example, not too late but not too early. Similarly, the current geographic location of the mobile device can enable the orchestration function to estimate when the migration point will be reached, which can also enable the orchestration function to start the migration in a timely manner.

[0077] In an embodiment, the processor subsystem may be further configured to:

[0078] - generating route data indicating a planned route along which the mobile device is planned to travel; and

[0079] - sending the route data to the orchestration function via the network interface.

[0080] As previously described, in the case of planning a route that a mobile device will travel, the mobile device can generate route data. For example, when the mobile device is or is part of a connected vehicle, a passenger of the connected vehicle may have entered a destination for navigation guidance purposes, and a local or online route planning component may then generate a route for the connected vehicle to reach the destination. Thus, the planned route may indicate the route along which the connected vehicle is predicted to travel. Typically, the mobile device may obtain route data from a route planning component, which may be performed by the mobile device but also performed elsewhere. By providing route data to the orchestration function, the orchestration function may be enabled to migrate edge computing resources to a more accurately selected edge node because the accuracy of the predicted route may be better. This may avoid unnecessary resource allocation at other edge nodes and / or may ensure that migration to the correct edge node is performed.

[0081] In an embodiment, the route data may include at least one of the group of:

[0082] - a waypoint list defining geographical locations characterizing at least a portion of the planned route;

[0083] - a list of trajectory points defining geographical locations that together form a trajectory between at least two subsequent waypoints;

[0084] - the identifier of the destination of the planned route; and

[0085] - The current geographic location of the mobile device.

[0086] There may be various ways of providing route data to the orchestration function, such as as a list of waypoints, a list of trackpoints, or a combination of an identifier of the destination of the planned route and the current geographic location of the mobile device. The latter data combination may enable the orchestration function to reconstruct the planned route, for example, using a route planning component.

[0087] In an embodiment, the processor subsystem may be configured to:

[0088] - based on the migration data, identifying a notification point representing a geographical location to which the initiation message is to be sent; and

[0089] - The initiation message is sent when the current geographic location of the mobile device reaches the notification point.

[0090] The mobile device can determine when to send a notification of arriving at a migration point in the near future by explicitly identifying a geographic location on the route that precedes the migration point, such as a notification point, and sending a prior warning notification in the form of an initiation message to the orchestration function upon arrival at the notification point. This can be an efficient way for the mobile device to determine when to send a notification point, as the mobile device can simply compare its current geographic location to (a list of) notification point(s) and send the initiation message immediately upon arrival at the corresponding notification point.

[0091] In an embodiment, the processor subsystem may be configured to send an initiation message at a time defined as a time period before reaching a corresponding migration point. For example, the time period may be defined by the orchestration function as part of the migration data, or may be determined by the mobile device itself, for example, based on the type of edge computing resource to be migrated.

[0092] In an embodiment, the migration data may include at least one of the group of the following items:

[0093] - define the geographical location of the migration point;

[0094] - define the geographical location and radius of the migration point, wherein the migration point is reached by arriving within the radius of the migration point; and

[0095] - a set of at least two geographical locations defining a migration point line, wherein the line is reached by crossing the migration point line.

[0096] There may be various ways of defining migration points, such as as a single geographical location or as a combination of a geographical location and a radius (e.g. defining a circle) or as a migration point line. The latter two may have the advantage that they allow for (lateral) deviations of the mobile device from the planned route.

[0097] In an embodiment, the migration data may include at least two migration points, and the processor subsystem may be configured to identify, in the initiation message, the migration point for which the initiation message is to be sent.

[0098] In an embodiment, the processor subsystem may be configured to obtain updated route data indicating an updated route along which the planned mobile device is to travel when a change occurs to the planned route and to send the updated route data to the orchestration function.

[0099] In an embodiment, the processor subsystem may be configured to send a declaration message to the orchestration function, wherein the declaration message may be configured to trigger the orchestration function to prepare for migration of edge computing resources from a first edge node to a second edge node. For example, such preparation may involve downloading an image, such as a VM image or a container image, to the second edge node, whereas starting the migration may involve instantiating a VM based on the VM image (e.g., by starting the VM), transferring the state of the VM, etc. This may also apply to application executable files that represent or provide edge computing resources. Here, preparation for the migration may involve transferring the application executable file to the second edge node, and starting the migration may involve configuring and executing the application executable file.

[0100] According to this embodiment, a mobile device can notify the orchestration function of its approach to a migration point in two phases. As described elsewhere, the mobile device can send an initiation message before reaching the migration point to trigger the orchestration function to begin ('initiate') the migration of edge computing resources. Additionally, the mobile device can send a previous notification (e.g., an announcement message) to the orchestration function, which may have preceded the initiation message in time. The mobile device can use the announcement message to provide the orchestration function with an estimate of the time it will reach the migration point. More specifically, the announcement message can include or indicate the time it will reach the migration point, or the time at which the mobile device will send the announcement message before reaching the migration point can be predefined. The orchestration function can use this information to prepare for the migration of edge computing resources. Providing this announcement message to the orchestration function provides the orchestration function with more freedom to make the necessary preparations for the migration, for example, when the load on the edge node is low or there is less competing network traffic. Advantageously, when all or most of the substantial data (e.g., VM images or container images or substantial application executable files) is already available at the second edge node, the subsequent initiation of the migration, for example by instantiating a VM or container based on its image, executing the application executable file, etc., can be much faster.

[0101] It will be appreciated by those skilled in the art that two or more of the above-mentioned embodiments, implementations, and / or aspects of the invention may be combined in any way deemed useful.

[0102] Modifications and variations of any one of the systems, methods and / or computer programs (corresponding to described modifications and variations of another of these systems, methods and / or computer programs, and vice versa) may be performed by those skilled in the art based on the present description. BRIEF DESCRIPTION OF THE DRAWINGS

[0103] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. In the drawings:

[0104] Figure 1 A mobile UE is shown moving between base stations located on its route, wherein a first group of base stations is served by a first edge node and a second group of base stations is served by a second edge node;

[0105] Figure 2 shows message exchanges between an orchestration function, a mobile UE, and other entities to orchestrate the migration of edge computing resources from a first edge node to a second edge node;

[0106] Figure 3 An example of migration data defining a set of at least two geographical locations defining a migration point line and thereby a migration line is shown;

[0107] Figure 4 shows a message exchange in which the mobile UE first sends an announce message and later sends an initiate message to the orchestration function to trigger the orchestration function to first prepare for the migration of edge computing resources and then later start the migration of the edge computing resources;

[0108] Figure 5 A system configured to orchestrate functionality is shown;

[0109] Figure 6 A mobile device or mobile user equipment is shown;

[0110] Figure 7 A computer-readable medium including data is shown; and

[0111] Figure 8 An exemplary data processing system is shown.

[0112] It should be noted that items with the same reference numerals in different drawings have the same structural features and the same functions, or are the same signals. In the case where the function and / or structure of such items have been explained, there is no need to repeat the explanation thereof in the detailed description.

[0113] List of reference symbols and abbreviations

[0114] The following list of reference numerals and abbreviations is provided to facilitate explanation of the drawings and should not be construed as limiting the claims.

[0115] AMF Access and Mobility Management Function

[0116] BS X base station X

[0117] CC Central Cloud

[0118] EM Edge Migration Process

[0119] EN X edge nodes X

[0120] MME Mobility Management Entity

[0121] OF arrangement function

[0122] QoS Quality of Service

[0123] UE User Equipment

[0124] VM virtual machine

[0125] VM-REPO Virtual Machine Repository

[0126] 1, 2, 4, 7, 9 to 11 steps in the message exchange

[0127] 20 Migration Line

[0128] 30 Coverage area of the base station served by the source edge node

[0129] 40 Coverage area of the base station served by the destination edge node

[0130] 100 Systems configured for orchestration

[0131] 110 Network Interface

[0132] 120 Processor Subsystem

[0133] 130 Data Storage Area

[0134] 200 User devices, mobile devices

[0135] 210 Network Interface

[0136] 220 Processor Subsystem

[0137] 300 Computer readable medium

[0138] 310 Non-transient data

[0139] 1000 Exemplary Data Processing System

[0140] 1002 processor

[0141] 1004 memory elements

[0142] 1006 System Bus

[0143] 1008 Local Storage

[0144] 1010 Mass Storage Device

[0145] 1012 Input Devices

[0146] 1014 Output Devices

[0147] 1016 Network Adapter

[0148] 1018 applications. DETAILED DESCRIPTION

[0149] Figure 1 A mobile UE (also referred to elsewhere as a 'mobile device' or simply 'UE') is shown moving between base stations along its route, where a first group of base stations is served by a first edge node EN1 and a second group of base stations is served by a second edge node EN2. For example, it can be seen that along its route, the UE may connect to a first base station BS1, which may be served by the first edge node EN1, at one moment and to a second base station BS2, which may be served by the second edge node EN2, at a later moment. When handing over wireless connectivity to the second base station BS2, it may be preferable to utilize the edge computing resources provided by the second edge node EN2, as the mobile UE's connection to the first edge node EN1 via the second base station BS2 may be suboptimal, for example, in terms of bandwidth and / or latency, since the connection may be routed, for example, via a central cloud CC.

[0150] Providing suitable edge computing resources at the second edge node EN2 may involve migrating the edge computing resources from the first edge node EN1 to the second edge node EN2. For example, this may involve one or more entities (e.g., entities in the central cloud CC) obtaining a virtual machine (VM) image, instantiating the VM, transferring the VM state from the source edge node EN1 to the destination edge node EN2, and updating the routing to the VM. While the migration of edge computing resources is known per se, existing techniques may not adequately address the timing of migrating edge computing resources from one edge node to another.

[0151] In order to better solve the timing of starting the migration of edge computing resources, an orchestration function (OF, Figure 1(not shown) and the UE may be configured to interact with the OF. The OF may be configured to determine migration points along the UE's route so that the UE can provide advance warning notification to the OF in the form of an initiation message that triggers the OF to begin migration of edge computing resources, allowing the migration to be completed in a timely manner. Thus, information available in both the UE's domain of knowledge (e.g., the UE's physical location and resource requirements) and the operator's domain of knowledge (e.g., network infrastructure and edge deployment) is leveraged.

[0152] The following embodiments describe that route data is obtained from a mobile device, and specifically as route data indicative of a planned route for the mobile device. For example, the mobile device may plan a route using a local or remote ('online') route planner and may transmit route data indicative of the route to the orchestration function. However, this is not a limitation, as the orchestration function may also obtain route data indicative of the route along which the mobile device is predicted to travel in other ways, such as using network-based mobility predictions as are known per se. For example, such network-based mobility predictions may be based on a serving base station, a serving edge node, or GPS information, which may be based on actual or historical mobility traces. In yet another embodiment, the orchestration function may obtain route data indicative of the planned route from a route planning entity (e.g., a server configured to generate a route for the mobile device), rather than obtaining such route data directly from the mobile device.

[0153] Figure 2 The message exchange between the orchestration function OF, the mobile UE and other entities to orchestrate the migration of edge computing resources from the first edge node EN1 to the second edge node EN2 is shown. This message exchange may involve the following messages and steps (some of which are not shown in the figure). Figure 2 , for example, because they are internal steps of the respective entities and are not messages exchanged between the entities; Figure 2 Steps 1, 2, 4, 7, 9 to 11 are shown):

[0154] 1. The UE can determine a route to the destination. For example, the UE can use an offline or online route planning tool or application that can be used to Figure 2 It is depicted as a separate entity 'RP' in the UE but may also be an internal component of the UE. The UE may thereby obtain its route as route data, which may be in a suitable format, such as the XML-based GPS Exchange Format (GPX).

[0155] 2. The UE can send the route data to the OF. This also allows the UE to register with the OF.

[0156] 3. The OF may determine which base station(s) the UE is likely to connect to along its route and which edge nodes these base stations are served by. For each or a combined subset of two base stations that the UE is expected to successively cross (e.g., transition between their coverage areas) along its route and that are best served by different edge nodes, the OF may add a location approximately at the intersection between the two base stations to a list of migration points, where a migration point may represent a location (e.g., a physical geographic location) encoded in a format that the UE can parse and process.

[0157] 4. The OF may provide the UE with a migration point list by sending migration data to the UE.

[0158] 5. In some embodiments, the OF may register a trigger for each migration point so that the OF can be notified when the UE is handed over to a base station served by another edge node. For example, in an LTE mobile network, the OF may register such a trigger at the MME (Mobility Management Entity), and in a 5G mobile network, at the AMF (Access and Mobility Management Function).

[0159] 6. Based on the UE's route data and resource requirements, the UE may determine when to provide advance warning notifications to the OF in the form of an Origination message. These points may be referred to as 'Notification Points' and may, but need not, be expressed in a format similar to Migration Points.

[0160] 7. When the notification point is reached, the UE may provide an initiation message to the OF, which may contain, for example, a description of the edge computing resources that the UE needs to be available immediately after the migration.

[0161] 8. In some embodiments, the OF may provide the UE with additional information about the edge computing resources in the destination edge node EN2 and the network path to the destination edge node EN2.

[0162] 9. The OF may start the migration of edge computing resources, for example, by instantiating one or more VMs and optionally by initiating a state transfer. This may involve sending a request to the VM repository ( Figure 2 The VM-REPO in the request requests the VM image to be downloaded to the destination edge node EN2.

[0163] 10. When the UE is handed over to a new base station (the trigger of which can be provided by the MME or AMF), the routing of traffic from the UE to the destination edge EN2 in the network can be configured.

[0164] 11. The VM of the source edge node EN1 can be terminated and cleaned up.

[0165] Through the above steps, the OF can inform the UE where migration may occur along its route, but can leave the timing of starting the migration up to the UE, as migration can only begin upon receiving an initiation message from the UE. This allows the UE to use information available to it rather than the OF (e.g., current speed, traffic flow, etc.) to optimally time the start of the migration. A timely start can prevent edge computing resources from being blocked (starting too early) or unavailable (starting too late). Furthermore, because the UE is aware of edge migration, for example, through the migration point, applications running on the UE can also prepare for the migration, for example, to mitigate the potential negative impact of a lack of connectivity during the migration.

[0166] If the UE's destination or route changes, the UE can repeat the process described above. Accordingly, the OF can determine new migration points for the new route, which can be provided to the UE to 'override' the previously communicated migration points. Similarly, when changes occur to the network or infrastructure, the OF can redetermine the migration points and communicate the new migration points to the UE.

[0167] Exchange route information

[0168] The UE can obtain route data indicating its planned route in various ways. For example, the UE can obtain its route through an online (e.g., Google Maps) or offline (e.g., Tongteng) route planner tool. These tools typically provide detailed route planning information, including precise definition of track points and arrival time information. The UE can transmit this type of information (e.g., start and destination waypoints, followed by track points defining the route) to the OF, for example, by issuing an HTTP POST request to the OF's RESTful API endpoint.

[0169] Example 1 The following provides an example of route information data, or simply route data, provided by a UE to an OF in the GPS Exchange Format (GPX). Here, a starting point and a destination are designated as waypoints, where a waypoint is defined as a latitude / longitude pair according to a geographic coordinate system. Following the starting point and destination is a list of track points that define the UE's intended route. Similar to waypoints, track points are defined as latitude / longitude combinations.

[0170]

[0171] In another example, precise route information may not be available at the UE. In this case, for example, the UE can transmit the origin and destination waypoints followed by a list of basic route points (e.g., points where the route changes or may change), such as forks and junctions along the route. Route definition using a list of route points rather than track points may be less precise because the route points are only basic track points. However, this level of detail may be sufficient when a multi-access edge computing (MEC)-based cloud provides services to a larger area covered by multiple base stations (e.g., eNodeBs).

[0172] In another example, the UE may communicate the destination and origin of its route or its current location. The destination, origin, or current location may be provided in various ways, such as geographic coordinates, street address, etc. This may enable the OF to plan the most likely route for the UE, for example, using a route planning component (such as an online or offline route planning tool or application).

[0173] In yet another example, the UE may only pass a (short) list of waypoints (e.g., origin and destination waypoints), optionally combined with multiple waypoints on the route to the destination. In this example, the OF may also use an online or offline route planning tool to estimate the UE's route.

[0174] Providing route information to the OF, for example in the form of route data, may initiate a new session with the OF, which means that it may trigger a collaboration between the UE and the OF until the provided destination is reached. However, the route provided by the UE (e.g. the destination and the list of trackpoints / waypoints) does not have to be fixed during the session. If the UE deviates from the route it passed to the OF, the UE may provide updated route data to the OF. The new route data may define the current location of the UE as a starting point, a possibly updated destination location and / or a new list of trackpoints / waypoints. An example of an update of a route registration at the OF may be an HTTP PUT request to a RESTful API endpoint of the OF. It should be noted that the PUT request may indicate that it is an update to an existing resource (i.e. the route data) and that it is intended to replace the previously passed route.

[0175] Example 2 Below is an example of updating an existing route, where the update defines the route through a list of waypoints, including a starting waypoint, intermediate waypoints, and a destination waypoint in the common GPX format. In this example, the update is performed as an HTTP PUT to a RESTful API at the OF, where the URL contains an identifier for the current route.

[0176]

[0177] Provide a migration point

[0178] After providing the OF with the route data, the response from the OF to the UE may be a list of migration points. Migration points may be defined as expected locations where the UE is expected to perform a handover from one base station to another, and where both base stations are best served by different edge nodes, for example, in terms of bandwidth and / or latency of the respective edge nodes.

[0179] To determine the migration point, the OF can map the UE's physical location (as its current or future location along the route) to the serving base station, and from there to the serving edge node. In one example, this mapping can be performed based on a static configuration. For example, a coverage map can be used to map the physical location to the base station, where the number of antennas, antenna type, orientation, and transmit power can determine the base station's coverage area.

[0180] For example, the second mapping from base stations to edge nodes can depend on where and how edge computing is deployed. In the case of a hyperlocal edge deployment where the edge node is located at the base station, the mapping between the base station and the edge node can be one-to-one. When an edge node provides services to multiple base stations, the OF can perform the mapping based on the network layout and topology (for example, selecting the edge node closest to the base station as the edge node providing the service).

[0181] In another example, the mapping between the UE location and the serving base station can still be static, but the mapping between the base station and the edge node can be dynamic. In this example, the OF can select the edge node based on the distance from the base station, the availability of resources at one of the edge locations, and / or based on the application requirements. An example of the latter case is that the OF can choose to serve the UE with an application requiring ultra-low latency or very high bandwidth by the edge node closest to the base station, rather than other less critical applications on the edge node serving a larger number of base stations.

[0182] Typically, a migration point can be specified as a point on a route provided by the UE. This point can be defined using a small radius around it and is typically specified in a way that the UE can understand it (e.g., as a longitude, latitude tuple). Defining a migration point as a location point is often possible when the UE's route is relatively precisely defined and the UE is expected to traverse the location point with relatively high accuracy. For example, if the UE is a vehicle or part of a vehicle traveling on an inter-city road network, it is possible to define a migration point as a location point on one of the roads along the planned route, as the UE is not expected to stray from the road, for example, when driving off-road.

[0183] Figure 3An example of migration data defining a set of at least two geographical locations is shown, which define migration point lines, for example in the form of a list of physical locations, and thereby define a migration line 20. The migration line 20 can be roughly placed at each of the first edge nodes ( Figure 3 The coverage areas 30 of the base stations BS1 to BS3 served by the second edge nodes (not shown) are connected to the coverage areas 30 of the base stations BS1 to BS3 served by the second edge nodes ( Figure 3 BS1 to BS3) and BS4 to BS6). When traveling from the coverage area 30 of one of base stations BS1 to BS3 to the coverage area 40 of one of base stations BS4 to BS6, edge computing resources for the UE can be migrated from the first edge node to the second edge node. For this purpose, the UE can interpret the migration point list as a line 20 that, when intersected by the UE, causes the UE to send an initiation message to the OF.

[0184] Migration lines may be appropriate when the UE's route is less precisely defined, as it may not require the OF to precisely determine every possible point along which the UE may be handed off between base stations. Note that a migration line may be provided for each respective migration from a source edge node to a destination edge node. When the UE may migrate to different edge nodes, the OF may have to provide a different migration point or a different set of migration points for each different destination edge node as different migration lines.

[0185] The UE may indicate a migration point in its initiation message, which may enable the OF to initiate a migration to an appropriate destination edge node immediately after receiving the initiation message. In other examples, the UE may not indicate a migration point in its initiation message, and the OF may instead estimate which migration point is crossed, for example, based on route data and the time elapsed since receiving the route data, or based on the UE's current location, which may be provided to the OF, for example, as part of the initiation message or via a different mechanism. An example of such a different mechanism is determining the UE's current location by identifying which base station is currently serving the UE.

[0186] Example 3 Below is an example of a response from an OF containing a list of migration points, where these migration points are designated as migration lines, i.e. by assigning a common identifier rather than having a separate identifier for each migration point. The response further includes an indication that the UE should give advance warning by sending an Origination message at least 180 seconds before reaching the migration line. In this example, the list of migration points is provided as a response to the

[0187]

[0188] HTTP response to a request at the RESTful API at OF. The "Location" response header contains the URL that the UE should use as the basis for providing prior warning.

[0189] The time at which the UE is expected to send the initiation message to the OF before reaching the corresponding migration point can be statically defined, for example, always five minutes, one minute, 30 seconds, or 10 seconds before reaching the migration point. In another example, the time at which the initiation message is sent may depend on the type of edge computing resource to be migrated, such as the type of virtualization technology used to run the application at the edge node. For example, initializing a virtual machine may take more time (typically on the order of minutes) than starting a Linux container or Docker container (typically on the order of seconds). Therefore, the UE can provide advance warning by sending the initiation message at a time before reaching the migration point that depends on the virtualization technology or generally on the type of edge computing resource to be migrated.

[0190] In yet another example, the OF can dynamically determine the time ('time range') by which the UE is expected to send an initiation message to the OF before reaching the corresponding migration point. This can allow the OF to set the time range based on, for example, the type of virtualization technology, the load on the edge node, whether an application image is already available, the expected volume or speed of data transfer from the source edge node to the destination edge node, and so on. The OF can provide the time range to the UE as a number or, alternatively, as a function of the requested resources. This may be particularly suitable for situations where the UE initiates an edge computing session and the OF is unaware of the resource requirements set by the UE (e.g., they are not predefined and negotiated by the application provider, but are instead requested on demand by the UE).

[0191] Provide initiation message

[0192] The UE may be configured to provide advance warning to the OF in the form of an initiation message before reaching a migration point. The initiation message may contain information such as identifying the migration point, the UE's location, and / or the expected time when the UE will pass through the migration point. An example of an initiation message may be an HTTP POST request to the OF's RESTful API endpoint.

[0193]

[0194] Example 4 An example of an HTTP POST formatted initiation message provided by the UE at the OF's RESTful API is given above. The initiation message refers to the migration point previously delivered by the OF to the UE. The initiation message is formatted in the common JSON format.

[0195] In another example, the initiation message may also include a definition of the desired edge computing resources. This may allow the UE to specify or change edge computing resources as needed and may allow the UE to initiate an edge computing session. In such an initiation message, for example, the UE may specify the format of the VM image to be instantiated at the destination edge node (e.g., a VM image with an installation script, a VM disk image, a container, a Lambda function), the location where the image can be obtained (e.g., a URL, a Docker hub location), and the instance type (e.g., specifications for the number of CPUs, amount of RAM, and disk space, or by reference to a predefined instance type).

[0196] Example 5 Below is an example of an HTTP POST message provided by a UE at the OF's RESTful API in the common JSON format. This message also includes the specifications of the requested resources, specifying the QEMU virtual disk image and the details of the compute instance (2 CPUs, 2048 MB of RAM, 10 GB of disk, and GPU acceleration enabled).

[0197]

[0198] Two-stage notification

[0199] Figure 4 A message exchange is shown in which a mobile UE first sends a Announce message and later sends an Initiate message to an orchestration function, triggering the orchestration function to first prepare for the migration of edge computing resources and then later initiate the migration of the edge computing resources. This message exchange may be related to the following. The UE may notify the OF of its proximity to a migration point in two stages. As described elsewhere, the UE may send an Initiate message before reaching the migration point to trigger the OF to begin ('initiate') the migration of edge computing resources. Additionally, the UE may send a previous notification (e.g., an Announce message) to the OF, which may precede the Initiate message. The UE may use the Announce message to provide the OF with an estimate of the time it will arrive at the migration point. The OF may use this information to prepare for the migration of edge computing resources. Such preparation may involve downloading VM images and other data that may need to be available at the destination edge node but is not yet available at the destination edge node. For example, one or more VM images may need to be downloaded from a VM repository or from the source edge node. The OF may then use the Initiate message to instantiate a VM based on the VM image and initiate the migration to the destination edge node, for example by transferring state from the source edge node.

[0200] Figure 4The following diagram shows a possible sequence of events for a two-phase notification, indicating that the announcement can be sent in advance, and in the case of EN2, even before the initiation message is sent to migrate to the previous edge node EN1. In this example, the UE announces the migration to edge nodes EN1 and EN2, and the OF then prepares the edge nodes by downloading VM images from the VM repository VM-REPO. These preparations are followed by two initiations of the migration, including instantiation of the corresponding virtual machines on the corresponding edge nodes.

[0201] Data processing entity

[0202] Figure 5 A system 100 is shown that can be configured to perform orchestration functions as described elsewhere in this specification. System 100 may include a network interface 110 with a mobile network (e.g., with a core network of the mobile network). Network interface 110 may take any suitable form, including but not limited to a wired network interface based on Ethernet or fiber optics, or a wireless network interface such as a satellite or microwave-based wireless communication interface. Typically, network interface 110 may be a physical network interface, but in some examples, it may also be a virtual network interface, for example, in the form of a software-defined interface. System 100 may further include a processor subsystem 120, which may be configured, for example, through hardware design or software, to perform operations related to orchestration functions described herein. For example, processor subsystem 120 may be embodied by a single central processing unit (CPU), but may also be a combination or system of such a CPU and / or other types of processing units. Typically, system 100 may be embodied by a (single) device or apparatus (e.g., a network server). However, system 100 may also be embodied by a distributed system of such devices or apparatuses (e.g., a distributed system of network servers).

[0203] Figure 5 The system 100 is further shown to include a data storage area 130 (such as a hard disk, solid-state drive, hard disk array, or solid-state disk array), which the system 100 can use to store data. For example, the system 100 can cache route data received from a mobile device, cache migration data to be transmitted to a mobile device, etc.

[0204] Figure 6A mobile device 200 as described elsewhere in this specification is shown. The mobile device 200 may include a network interface 210 for wirelessly connecting to a mobile network via a corresponding base station BS of the mobile network. The network interface 210 may take any suitable form, including but not limited to a 4G, 5G or next generation radio interface or a Wi-Fi radio interface for wirelessly connecting to an access point. The mobile device 200 may further include a processor subsystem 220, which may be configured, for example, by hardware design or software, to perform the operations described in this specification in relation to the mobile device. For example, the processor subsystem 220 may be embodied by a single central processing unit (CPU) but may also be embodied by a combination or system of such CPUs and / or other types of processing units. Although not described herein, the processor subsystem 220 may be a processor subsystem 220. Figure 6 Although not explicitly shown in FIG, mobile device 200 may include a data storage area, such as a solid-state drive or flash memory, that mobile device 200 may use to store data. For example, mobile device 200 may temporarily buffer route data to be sent to or migration data received from the orchestration function.

[0205] Typically, mobile device 200 may be embodied by a (single) device or apparatus (e.g., a smartphone, personal computer, laptop, tablet, smartwatch, smart glasses, head-mounted display, etc.). Mobile device 200 may also be a vehicle, such as a car, motorcycle, truck, bicycle, scooter, or part of such a vehicle. Mobile device 200 may also be part of an autonomous entity, such as an unmanned aerial or non-aerial (e.g., road-based) vehicle or robot. However, mobile device 200 may also be embodied by a distributed system of such devices or apparatuses. Typically, mobile device 200 may be a so-called user equipment (UE) or a mobile UE of a mobile telecommunication network, such as a 5G mobile network.

[0206] In general, system 100 and mobile device 200, representing orchestrated functionality, can each be implemented at least in part by a device or apparatus. The device or apparatus may include one or more (micro)processors executing appropriate software. The software implementing the functionality of the functionality(ies) may have been downloaded and / or stored in one or more corresponding memories, for example, volatile memory such as RAM or non-volatile memory such as flash memory. Alternatively, the functionality(ies) may be implemented in the device or apparatus in the form of programmable logic, for example, as a field programmable gate array (FPGA). In general, each functionality of the system or mobile device may be implemented as a circuit.

[0207] It should be noted that any of the methods described in this specification, for example in any of the claims, can be implemented on a computer as a computer-implemented method, dedicated hardware, or a combination of both. Instructions for a computer (for example, executable code) can be stored in a computer such as, for example, Figure 7 , for example, in the form of a series of machine-readable physical marks 310 and / or as a series of elements having different electrical properties or values (e.g., magnetic properties or values or optical properties or values). Executable code can be stored in a transient or non-transitory manner. Examples of computer-readable media include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Figure 7 An optical storage device 300 is shown by way of example.

[0208] exist Figure 7 In an alternative embodiment of the computer-readable medium 300 , the computer-readable medium 300 may include transient or non-transient data 310 representing at least one of: route data, migration data, and an initiation message.

[0209] Figure 8 is a block diagram illustrating an exemplary data processing system that may be used in the embodiments described in this specification. Such a data processing system includes the data processing entities described in this specification, including but not limited to orchestration functionality or a system implementing orchestration functionality or a mobile device or (mobile) user device.

[0210] The data processing system 1000 may include at least one processor 1002 coupled to a memory element 1004 via a system bus 1006. In this manner, the data processing system may store program codes in the memory element 1004. Furthermore, the processor 1002 may execute program codes accessed from the memory element 1004 via the system bus 1006. In one aspect, the data processing system may be implemented as a computer suitable for storing and / or executing program codes. However, it should be understood that the data processing system 1000 may be implemented in the form of any system including a processor and a memory capable of performing the functions described in this specification.

[0211] The memory element 1004 may include one or more physical memory devices, such as, for example, a local memory 1008 and one or more mass storage devices 1010. Local memory may refer to random access memory or other (multiple) non-persistent memory devices typically used during the actual execution of the program code. The mass storage device may be implemented as a hard drive, solid-state drive, or other persistent data storage device. The processing system 1000 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code to reduce the number of times the program code must be retrieved from the mass storage device 1010 during execution.

[0212] Input / output (I / O) devices, depicted as input device 1012 and output device 1014, may optionally be coupled to the data processing system. For example, examples of input devices may include, but are not limited to, microphones, keyboards, pointing devices such as mice, game controllers, Bluetooth controllers, VR controllers, and gesture-based input devices. For example, examples of output devices may include, but are not limited to, monitors or displays, speakers, and the like. Input devices and / or output devices may be coupled to the data processing system directly or through intervening I / O controllers. A network adapter 1016 may also be coupled to the data processing system to enable coupling to other systems, computer systems, remote network devices, and / or remote storage devices via intervening private or public networks. A network adapter may include a data receiver for receiving data transmitted by the system, device, and / or network to the data, and a data transmitter for transmitting data to the system, device, and / or network. Modems, cable modems, and Ethernet cards are examples of different types of network adapters that may be used with data processing system 1000.

[0213] like Figure 8 As shown in FIG, memory element 1004 can store application programs 1018. It should be understood that data processing system 1000 can further execute an operating system (not shown) that can facilitate the execution of application programs. Application programs implemented in the form of executable program code can be executed by data processing system 1000 (e.g., by processor 1002). In response to executing the application programs, the data processing system can be configured to perform one or more operations to be described in further detail herein.

[0214] In one aspect, for example, data processing system 1000 may implement an orchestration function or a system representing an orchestration function. In this case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described herein with reference to the orchestration function or its system. In another aspect, data processing system 1000 may implement a mobile device or (mobile) user device. In this case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described herein with reference to the mobile device or (mobile) user device.

[0215] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims.

[0216] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The use of the verb "comprise" and its conjugations does not exclude the presence of elements or levels other than those stated in the claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as "at least one of" preceding a list or group of elements select all or any subset of the elements from the list or group. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The present invention may be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A system configured to orchestrate functions for a mobile network, wherein: The mobile network includes an edge node configurable to provide edge computing resources to mobile devices, wherein the system comprises: - a network interface with the mobile network; - a processor subsystem for orchestrating, at least in part, a migration of edge computing resources for a mobile device from a first edge node to a second edge node by being configured to: - obtaining route data indicating a route along which the mobile device is predicted to travel; - based on the route data, identifying one or more migration points along the route, the one or more migration points defining respective geographic locations at which the second edge node is expected to have better bandwidth and / or latency for the mobile device than the first edge node; - sending migration data to the mobile device via the network interface, the migration data indicating the one or more migration points; - receiving, via the network interface, an initiation message from the mobile device, the initiation message indicating a notification that the mobile device is expected to arrive at a corresponding migration point among the migration points; and -Based on the initiation message, start migrating the edge computing resource from the first edge node to the second edge node.

2. The system according to claim 1, wherein: The processor subsystem is configured to obtain the route data from the mobile device via the network interface, wherein the route data indicates a planned route of the mobile device.

3. The system according to claim 1 or 2, wherein: The mobile device is connected to the network via respective base stations, and wherein the processor subsystem is configured to determine the migration points as respective geographic locations at which a handover from one base station to another is expected to occur, and at which, after the handover, the second edge node is expected to have better bandwidth and / or latency for the mobile device than the first edge node.

4. The system according to any one of claims 1 to 2, wherein: The processor subsystem is configured to: - determining a time at which the mobile device sends the initiation message, wherein the time is defined as a period of time before reaching a corresponding one of the migration points; and - providing the time period to the mobile device.

5. The system according to claim 4, wherein: The processor subsystem is configured to determine the time based on a type of edge computing resource to be migrated to the second edge node.

6. The system according to any one of claims 1 to 2, wherein: The processor subsystem is configured to send resource data to the mobile device in response to the initiation message, the resource data identifying a second edge node to which the edge computing resource is to be migrated.

7. The system according to any one of claims 1 to 2, wherein: The processor subsystem is configured to initiate migration of the edge computing resource from the first edge node to the second edge node by transferring a virtual machine image of a virtual machine from the first edge node to the second edge node.

8. A mobile device for a mobile network, wherein: The mobile network includes an edge node configurable to provide edge computing resources to a mobile device, wherein the mobile device includes: - a network interface for wirelessly connecting to the mobile network via a corresponding base station of the mobile network; - a processor subsystem configured to: receiving, via the network interface, migration data from an orchestration function of the mobile network, wherein the migration data indicates one or more migration points along a route along which the mobile device is predicted to travel, the one or more migration points defining respective geographic locations at which the second edge node is predicted to have better bandwidth and / or latency for the mobile device than the first edge node; -Based on the migration data and the current geographic location of the mobile device, sending an initiation message to the orchestration function before reaching a corresponding migration point among the migration points, wherein the initiation message is configured to trigger the orchestration function to start the migration of the edge computing resource from the first edge node to the second edge node.

9. The mobile device according to claim 8, wherein: The initiation message includes at least one of the group of the following items: - The identification or representation of the edge computing resource; - Expected migration point; - the absolute or relative time of arrival at the migration point; and -The current geographic location of the mobile device.

10. The mobile device according to claim 8 or 9, wherein: The processor subsystem is further configured to: - generating route data indicative of a planned route along which the mobile device is planned to travel; and - sending the route data to the orchestration function via the network interface. The mobile device according to claim 10 , wherein: The route data includes at least one of the group consisting of: - a waypoint list defining geographical locations characterizing at least a portion of the planned route; - a list of trajectory points defining geographical locations that together form a trajectory between at least two subsequent waypoints; - an identifier of the destination of the planned route; and -The current geographic location of the mobile device.

12. The mobile device according to any one of claims 8 to 9, wherein: The processor subsystem is configured to: - based on the migration data, identifying a notification point representing a geographical location to which the initiation message is to be sent; and -Sending the initiation message when the current geographic location of the mobile device reaches the notification point.

13. The mobile device according to any one of claims 8 to 9, wherein: The processor subsystem is configured to send the initiation message at a time defined as a time period before reaching a corresponding migration point.

14. The mobile device according to any one of claims 8 to 9, wherein: The migration data includes at least one of the group of the following items: - define the geographical location of the migration point; - defining a geographical location and radius of a migration point, wherein the migration point is reached by arriving within the radius of the migration point; and - a set of at least two geographical locations defining a migration point line, wherein the line is reached by crossing the migration point line.

15. A computer-implemented method for orchestrating, at least in part, migration of edge computing resources for a mobile device from a first edge node to a second edge node in a mobile network, the mobile network comprising an edge node configurable to provide edge computing resources to the mobile device, in, The method includes: - obtaining route data indicating a route along which the mobile device is predicted to travel; - based on the route data, identifying one or more migration points along the route, the one or more migration points defining respective geographic locations at which the second edge node is expected to have better bandwidth and / or latency for the mobile device than the first edge node; - sending migration data to the mobile device, the migration data indicating the one or more migration points; - receiving an initiation message from the mobile device, the initiation message indicating a notification that the mobile device is expected to arrive at a corresponding one of the migration points; and -Based on the initiation message, start migrating the edge computing resource from the first edge node to the second edge node.

16. A computer-implemented method for use with a mobile device for a mobile network, wherein: The mobile network includes an edge node configurable to provide edge computing resources to a mobile device, wherein the method comprises: receiving migration data from an orchestration function of the mobile network, wherein the migration data indicates one or more migration points along a route along which the mobile device is predicted to travel, the one or more migration points defining respective geographic locations at which the second edge node is predicted to have better bandwidth and / or latency for the mobile device than the first edge node; -Based on the migration data and the current geographic location of the mobile device, sending an initiation message to the orchestration function before reaching a corresponding migration point among the migration points, wherein the initiation message is configured to trigger the orchestration function to start the migration of the edge computing resource from the first edge node to the second edge node.

17. A computer-readable medium comprising transitory or non-transitory data representing a computer program comprising instructions for causing a processor system to perform the method according to claim 15 or 16.

Images