Migration Method for Enhancing Lightweight IoT Device Applications

Abstract

An exemplary method includes: receiving an input regarding a movable IoT device, and the input includes information about the location of the movable IoT device; information about whether the movable IoT device is moving; and, when the movable IoT device is moving, information about the range, speed, and orientation of the movable IoT device. Next, the method includes: generating a predicted location of the movable IoT device based on the received input; using the predicted location of the movable IoT device and a node map in the environment where the movable IoT device is located to make a migration decision regarding the application used by the movable IoT device; and when the movable IoT device reaches the predicted location, migrating the application from the current location to a node that the movable IoT device is expected to access, and the node is physically separated from the current location by a distance.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to applications for lightweight "Internet of Things" (IoT) devices. More specifically, at least some embodiments of the present invention relate to systems, hardware, software, computer-readable media, and methods for enabling mobile IoT devices to use resource-intensive applications. Background Art

[0002] Modern IoT networks are expected to include mobile devices that require large amounts of data and low-latency data processing. For example, an autonomous drone may require complex computations for image processing applications. However, typically, such applications require more power and CPU resources than are locally available on the drone. Additionally, the necessary computations cannot always be performed in the cloud or at corporate headquarters because, at least in some applications, the latency of the connection between the drone and the site performing the computations may be too great. This includes applications such as real-time navigation and real-time calibration. To run these and other applications on these lightweight machines, more computing power and low-latency connections are needed. Summary of the Invention

[0003] Embodiments of the present invention generally relate to applications for lightweight IoT devices. More specifically, at least some embodiments of the present invention relate to systems, hardware, software, computer-readable media, and methods for enabling mobile IoT devices to use resource-intensive applications. As used herein, "lightweight" IoT devices include, among other things, IoT devices that lack sufficient processing power for one or more applications and / or are unable to communicate with remote sites with an acceptable latency. An IoT device is any device capable of communicating with one or more other devices, whether mobile or otherwise, via a computer network, one example of which is the Internet. In at least some embodiments of the present invention, such communication typically occurs via wireless communication systems and devices (some examples of which are disclosed herein).

[0004] Generally speaking, the present disclosure paves the way for new applications for fast-moving, lightweight IoT devices such as flying drones. By automatically leveraging computing and memory resources with extremely low latency, new applications can be written to perform operations such as real-time navigation based on image processing, real-time calibration, real-time image and face recognition, profiling, and operations with instant response, which are currently not possible with such lightweight drones and other IoT devices.

[0005] Embodiments of the present invention can be used in conjunction with IoT networks and micro data centers. Such micro data centers can be installed in, for example, busy locations such as street corners and skyscrapers, and / or other locations. Embodiments of the present invention utilize such data centers to implement dedicated migration applications that automatically follow IoT devices as they move in the environment and deliver computing services as close as possible to the moving client IoT devices. Embodiments of the present invention also operate in conjunction with the movable IoT device before it moves or changes its location.

[0006] Thus, for example, embodiments of the present invention take into account the location of the device, its planned travel trajectory, etc., and calculate where to migrate the application in real time. Embodiments of the present invention can, but do not have to, employ various means and solutions to pre-deploy resources, code, and data for use by the movable IoT device. Examples of such means and solutions include, but are not limited to, replication solutions such as CMotion for replicating containers and / or Dell EMC RecoverPoint for VMs for replicating VMs to automatically pre-allocate computing resources such as processing resources and storage resources, and pre-fetch code and data. An application such as vMotion can be used to migrate the IoT device application so that it is available for the client once the client moves to a new location. In this way, the client can provide data to the application for processing by the application. The above is provided only as an example and does not have to be used by any embodiment.

[0007] In this way, embodiments of the present invention can effectively address the inherent limitations of drones and other small movable IoT devices, which typically cannot perform intensive and complex computations, at least because they cannot lift and carry the relatively large power supply and storage space / memory / CPU components required to perform such processing. At least some embodiments of the present invention are also capable of providing relatively low-latency computing and communication that may be required, for example, in signal and image processing operations that need to be performed on data collected and / or generated by the movable IoT device, some of which are latency-sensitive. In addition, drones and other movable IoT devices / moving IoT devices have available location and trajectory information that can be used to help ensure that the necessary resources are delivered to the right place at the right time.

[0008] Then, advantageously, even if the IoT device may stop, move, and change its location in the environment, sometimes unpredictably, the IoT device can still be able to access pre-deployed processing power assets and associated functions, applications, data, and code, collectively referred to as "resources", which are relatively close to the location of the IoT device, regardless of where they are. Additionally, because the IoT device is close to the resources, the latency of communication between the IoT device and these resources is reduced. Thus, the lightweight IoT device can access the resources required to support its resource-intensive operations, and this is done through a low-latency connection. However, the IoT device lacks and cannot deliver its own sufficient on-board resources to support these operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] To describe the manner in which at least some advantages and features of the present invention can be obtained, a more specific description of embodiments of the present invention will be presented by reference to specific embodiments of the present invention shown in the drawings. It should be understood that these drawings only depict typical embodiments of the present invention and are therefore not considered to limit its scope. Embodiments of the present invention will be described and explained with additional specificity and detail by using the drawings.

[0010] Figure 1 Exemplary architectures and aspects of an IoT environment of some embodiments of the present invention are disclosed.

[0011] Figure 2 Aspects of an exemplary host configuration are disclosed.

[0012] Figure 3 Aspects of an exemplary operating environment of some embodiments of the present invention are disclosed.

[0013] Figure 4 Aspects of an exemplary auto-migration system configuration are disclosed.

[0014] Figure 5 Aspects of an exemplary method are disclosed. DETAILED DESCRIPTION

[0015] It should be noted that the foregoing advantageous aspects of various embodiments are presented by way of example only, and various other advantageous aspects of the exemplary embodiments of the present invention will be apparent from this disclosure. It should be further noted that it is not necessary for any embodiment to achieve or enable any of these advantageous aspects disclosed herein.

[0016] A. EXEMPLARY ARCHITECTURES AND ASPECTS OF AN IoT ENVIRONMENT

[0017] The following is a discussion of aspects of an exemplary operating environment of various embodiments of the present invention. This discussion is not intended to limit the scope or applicability of the present invention in any way.

[0018] Generally, embodiments of the present invention can be implemented in conjunction with systems, software, and components that individually and / or jointly implement and / or cause the implementation of data generation, data processing, and data management operations. Such data management operations can include, but are not limited to, data read / write / delete operations, deduplication operations, data backup operations, data restoration operations, data cloning operations, data archiving operations, and disaster recovery operations. More generally, the scope of the present invention encompasses any operating environment in which the disclosed concepts may be useful.

[0019] In conjunction with some embodiments, new and / or modified data, such as that collected and / or generated by a removable IoT device, can be stored in a data protection environment, which can take the form of a public or private cloud storage environment, a local storage environment, and a hybrid storage environment including both public and private elements. Any of these exemplary storage environments can be partially or fully virtualized. The storage environment can include or consist of a data center that can operate to serve one or more client-initiated read and write operations, examples of such clients including one or more mobile IoT devices.

[0020] In addition to the storage environment, the operating environment can also include one or more clients, such as, for example, a removable IoT device capable of collecting, modifying, and creating data. Thus, a particular client can adopt one or more instances of each of one or more applications that perform such operations on the data, or otherwise be associated therewith. Some examples of applications that can reside on and operate on a removable IoT device are disclosed elsewhere herein.

[0021] Devices in the operating environment can take the form of software, a physical machine, or a virtual machine (VM), or any combination thereof, but no particular device implementation or configuration is required for any embodiment. Similarly, data protection system components (such as, for example, databases, storage servers, storage volumes (LUNs), storage disks, replication services, backup servers, restoration servers, backup clients, and restoration clients) can also take the form of software, a physical machine, or a virtual machine (VM), but no particular component implementation is required for any embodiment. In the case of adopting a VM, a hypervisor or other virtual machine monitor (VMM) can be used to create and control the VM.

[0022] As used herein, the term "data" has a broad scope. Thus, the term encompasses, by way of example and not limitation, data segments, data chunks, data blocks, atomic data, emails, any type of object, files, address books, directories, subdirectories, volumes, and any group of one or more of the foregoing.

[0023] Exemplary embodiments of the present invention are applicable to any system capable of storing and processing various types of objects in analog, digital, or other forms. Although terms such as documents, files, segments, blocks, or objects may be used by way of example, the principles of the present disclosure are not limited to any particular form of representing and storing data or other information. Instead, such principles are equally applicable to any object capable of representing information.

[0024] Now paying particular attention Figure 1 , an example of an architecture for an embodiment of the present invention is generally designated by 100. Generally, the architecture 100 may include one or more IoT devices 200, which may be implemented and operated as IoT edge devices, although this is not required. Exemplary IoT devices may include sensors, actuators, applications, or any other system, device, or apparatus that is operable to collect, generate, process, and transmit information related to the environment in which the IoT device 200 is located. Any number “n” of IoT devices 200a, 200b, 200c, 200d, ……, 200n may be employed. IoT devices may be more generally referred to herein as clients.

[0025] As described herein, the IoT devices 200 that may be employed in conjunction with embodiments of the present invention include mobile IoT devices. Mobile IoT devices include IoT devices that may be mobile under their own power or, for example, a mobile phone or other device that may be connected to a vehicle or apparatus capable of moving. Some exemplary mobile IoT devices that may be employed in conjunction with embodiments of the present invention include, but are not limited to, remotely controlled vehicles and autonomous vehicles. Either or both of these types of vehicles may operate in various environments including water, air, and / or land. Mobile IoT devices include vehicles such as cars, as well as devices such as drones, sometimes referred to as unmanned aerial vehicles (UAVs). Mobile IoT devices may carry human or other living occupants or may be unmanned. Additionally, mobile IoT devices may be airplanes, ships, vehicles configured to travel on land, or vehicles having any combination of these capabilities.

[0026] In some embodiments, two or more of the mobile IoT devices may be configured to communicate with each other directly or through an intervening device or system such as a micro data center or other node. Such micro data centers may be more generally referred to herein as nodes. In some embodiments, the micro data centers may belong to one or more service providers, and the replication systems disclosed herein may employ multi-tenant support to isolate data between different clients and different providers using the same micro data center.

[0027] Continuing to refer Figure 1In the exemplary architecture 100 disclosed in [reference], the IoT device 200 can operate in conjunction with one or more gateways 300 (such as GW-1 302 and GW-n 304). Generally, the gateway 300 is used to integrate the communication and management of multiple IoT devices 200. The gateway 300 is not essential, but can be useful in cases where the networking capabilities of the IoT device 200 are local in nature (e.g., in terms of power and / or connectivity), and the gateway 300 is used by one or more IoT devices 200 to connect to a network, such as the Internet. In some embodiments, a general IoT system integrates IoT devices into a gateway and then into a central backend data center, where processing of the data collected by the IoT devices can be performed. As Figure 1 shown, there can be several layers of gateways 300.

[0028] As shown, the gateway can be dedicated to a specific array or group of IoT devices 200, but this is not essential. In the example shown, the IoT devices 200a, ……, 200n communicate through the gateway 302. Figure 1 Any connection between the elements shown can be a wireless or hardwired connection.

[0029] It should be noted here that the scope of protection of the present invention is not limited to any specific wireless communication system, device, or communication protocol. Some exemplary wireless communication systems and devices can include, for example, cellular networks such as 3G, 4G, and 5G networks, satellites, and / or other systems and devices to facilitate communication. Other examples of wireless communication systems include radio frequency (RF) systems, near-field communication systems, ultra-high frequency (UHF), and very high frequency (VHF) communication systems. Communication between the elements disclosed herein (including but not limited to IoT devices, elements for remotely controlling IoT devices, and nodes such as micro data centers) can be encrypted.

[0030] Also as noted, gateways such as gateway 302 and gateway 304 can be referred to as corresponding to respective layers, such as layer 1 and layer “n”. These layers can be layers in a communication configuration. Additionally, the gateway in the highest layer in the communication configuration (such as gateway 304) can communicate with one or more other gateways in the lower layer (such as gateway 302). Similarly, the gateways can be arranged serially with each other, but this is not necessarily essential, and a parallel gateway arrangement can also be used. In the example configuration shown, the layer “n” gateway 304 integrates all the communication from the lower layer (such as layer 1).

[0031] As Figure 1Further shown, the data storage functionality associated with architecture 100 can be implemented by data center 400. The data center 400 can include a storage device 500, which can include a database (DB) and / or a data lake configuration, and one or both of the database (DB) and the data lake configuration can also be elements of the data center. However, more generally, the storage device 500 encompasses any system and / or component operable to store data and respond to read and write requests. More specifically, the storage device 500 can be used to save the data after the incoming data from the IoT devices 200 has been processed by a processing server 600 capable of communicating with the storage device 500.

[0032] Typically, the processing server 600 and / or other components can be programmed to receive data from one or more IoT devices 200, such as via one or more gateways 300, and perform processing and / or analysis on the sensor data. That is, the raw data provided by the IoT devices 200 can be received and processed by the processing server 600. The processing server 600 can, but does not have to be, an element of the data center 400. Further details regarding the operations performed by the processing server 600 are disclosed elsewhere herein.

[0033] B. Exemplary Host and Server Configurations

[0034] Now briefly refer to Figure 2 , any one or more of the IoT devices 200, gateways 300, data center 400, storage device 500, processing server 600 and its components, and the automatic migration system 1000 can take the form of or include or be implemented on or be hosted by a physical computing device, an example of which is denoted by 700. Similarly, in the case where any of the foregoing elements includes a virtual machine (VM) or consists of VMs, the VM can constitute Figure 2 a virtualization of any combination of the physical components disclosed in

[0035] In Figure 2 the example of, the physical computing device 700 includes: a memory 702, which can include one, some, or all of the following: random access memory (RAM), non-volatile random access memory (NVRAM) 704, read-only memory (ROM), and permanent memory; one or more hardware processors 706; a non-transitory storage medium 708; a UI device 710; and a data storage device 712. One or more of the memory components 702 of the physical computing device 700 can take the form of a solid-state device (SSD) storage device. Similarly, one or more application programs 714 including executable instructions are provided.

[0036] Such executable instructions can take various forms, including, for example, instructions executable to perform any method or portion thereof disclosed herein, and / or instructions executable by / at any of the storage sites (whether enterprise on-premises or at a cloud storage site, client, data center, backup server, blockchain network, or blockchain network node) to perform any function disclosed herein. Similarly, such instructions can be executable to perform any other operation disclosed herein, including but not limited to data collection, data processing (including data analysis), data read / write / delete operations, instantiation of one or more applications, IoT device location determination and prediction, migration of applications and / or other resources from one location to another, and operation of applications located at one or more nodes.

[0037] In addition, other executable instructions can be executed to perform various operations involving one or more IoT devices and any of a micro data center, regional data center, cloud backend, or other data collection and processing entity. These operations include but are not limited to tracking, calibration (including real-time calibration), image capture (still and video), electronic monitoring, signal collection and analysis, listening, navigation, image recognition (including facial recognition), profiling, and processing and transmission of the collected data (including image processing) and data collection using one or more sensors of various types, where such data can be any data related to the characteristics of the physical environment.

[0038] C. Exemplary Operating Environments

[0039] Now note Figure 3 , details are provided regarding an operating environment for an embodiment of the present invention, where one exemplary operating environment is generally designated 800. In the illustrated example, one or more regional data centers 802 and micro data centers 804A-E are distributed across an urban area. The micro data centers 804 can, but need not, be interconnected with a certain degree of redundancy, and the micro data centers 804 also have connections to the regional data centers 802, which can operate as gateways to the cloud backend 806. As disclosed herein, data processing and analysis can be performed at any one or more of the micro data centers 804, regional data centers 802, and / or cloud backend 806. In some embodiments, the cloud backend 806 takes the form of, or includes, a cloud data center. Depending on the implementation, the regional data centers 802 can be omitted, and the micro data centers 804 can be directly connected to the cloud backend 806, which need not be in the cloud (public or private) at all.

[0040] The micro data center 804 can take various different forms. For example, one or more micro data centers 804 can be implemented as a hyper-converged software-defined data center, based on products such as Dell-EMC VxRail or Nutanix, for example. The micro data center 804 can be mobile and / or fixed. In some embodiments, the micro data center 804 is connected to an IoT framework. The micro data center 804 can be located, for example, inside a traffic light, inside a road sign, on a roof, or any other suitable location. Compared to the mobile unit inside a device such as the movable IoT device 200, not being movable allows the micro data center 804 to have a larger storage space and have greater power consumption and processing capabilities. Thus, due to the limitations on the storage space, power consumption, and processing capabilities of the movable IoT device 200, the micro data center 804 can perform resource-intensive calculations and processing beyond the capabilities of the small and movable IoT device 200.

[0041] In some cases, an application at the micro data center 804 or other node can start processing data inline when data is received from the IoT device 200. An application at the micro data center 804 or other node can additionally or alternatively wait to perform any processing until the entire data set is received from the IoT device 200. The processing of the data by the application can be triggered by the IoT device 200, a third-party entity, and / or can be performed automatically.

[0042] It should be noted that Figure 3 the arrangements in Figure 3 are provided only as examples. Thus, the size, quantity, location, geographical spacing, interconnectivity, latency, and / or other parameters related to the micro data center 804 can be selected as needed. Additionally, although the examples in

[0043] In an environment such as an urban environment, the density of the micro data centers 804 (micro data centers 804 per unit area) may be high enough such that the IoT device 200 is always or almost always close enough to at least one micro data center 804 so that latency issues are substantially avoided (if not completely avoided). However, in other environments, such as a desert or wilderness environment, for example, the density of the micro data centers 804 may be relatively low, and the IoT device 200 may experience unacceptably high latency for a relatively long time. In these environments, the IoT device 200 may or may not communicate with, or attempt to communicate with, the micro data center 804 during these periods when high latency is expected or experienced.

[0044] In some environments, such as the urban environment example herein, the IoT device may maintain continuous communication with the micro data center, but the latency associated with the IoT device connection may vary as the IoT moves within its environment. However, in other environments, such as the wilderness example herein, the IoT device may experience a complete interruption in communication as it moves between small data centers that may be widely dispersed geographically. In the latter case, the IoT device may still be able to transmit its range, bearing, and speed, for example, via satellite, such that when it can be predicted when it will enter the range of another micro data center, the IoT device can communicate with the other micro data center with acceptable latency.

[0045] Continuing to refer Figure 3 to, one or more IoT devices 200 (such as drones, for example) moving in the operating environment 800 have one or more companion applications, such as application 900, running in the nearest micro data center 804(A). As the IoT device 200 moves in the operating environment 800, the application 900 will be automatically migrated to the nearest micro data center 804(C). As discussed in more detail elsewhere herein, the application 900 can be migrated based on the predicted movement and path of the IoT device, which in turn can be generated based on various inputs and information, for example, the inputs and information including the latency experienced at the micro data center 804(A) and the latency expected at the micro data center 804(C). The migration of the application 900 can be performed, for example, when a change in the expected location of the IoT device 200 is anticipated, or can be performed in real time as the IoT device 200 is moving closer to another micro data center 804.

[0046] In the event that multiple applications 900 are associated with an IoT device 200, not all of the applications 900 may be migrated. Instead, only the applications 900 that are expected to be needed by the IoT device at the next expected destination are migrated to the micro data center 804 closest to that destination. Therefore, within a set of applications 900 associated with a given IoT device 200 or group of IoT devices 200, different applications 900 may be migrated at different respective times and / or to different respective locations based on the expected needs of the IoT device 200. Depending on the circumstances, one or more applications 900 may not be migrated at all. Likewise, the order in which the applications 900 are migrated and / or whether an application 900 is to be migrated may be determined based on a priority scheme that may, for example, specify that one application 900 be migrated with relative priority over another application 900.

[0047] D. Automatic migration of resources including applications

[0048] Now refer to Figure 4 , and continue to refer to Figure 1 and Figure 3 , provides details regarding various aspects of an automated migration system (AMS) 1000 that migrates one or more applications and / or other resources based on various inputs. Figure 3 In the case of the disclosed elements, Figure 4 The elements disclosed in the can communicate with each other via wireless and / or hardwired connections, including communicating with each other via one or more computer networks.

[0049] As discussed in more detail below, the automated migration system 1000 includes a brain 1002, a storage device 1004, a prediction engine 1006, and a replication system 1008. The automated migration system 1000 can reside or be hosted in any suitable location, including but not limited to a micro data center, a regional data center, a cloud backend, a processing server in a data center, or elsewhere. Generally, the AMS 1000 is configured to receive inputs that are then used by the prediction engine 1006 to determine the expected location of the IoT device. The input module 1050 can receive inputs from sensors 1052 and 1054 and / or other sources 1056. Although in Figure 4 Although not specifically noted in the , the input received by the input module 1050 may include information received directly from one or more onboard sensors of any of the IoT devices 1150, 1152, and 1154. In some embodiments, the IoT devices 1150, 1152, and 1154 may transmit their sensor data directly to the AMS 1000 rather than through the input module 1050.

[0050] Similarly, the AMS 1000 communicates with one or more micro data centers 1102, 1104, and 1106, which may or may not communicate with each other, and the AMS 1000 may also communicate directly with one or more IoT devices (such as IoT devices 1150, 1152, and 1154) to transmit data to and / or receive data from these IoT devices. Finally, the IoT devices 1150, 1152, and 1154 each communicate with one, some, or all of the micro data centers 1102, 1104, and 1106, for example, via a telemetry process.

[0051] Continuing to refer to the drawings, further details regarding the operational aspects of some example embodiments of the present invention are provided. Generally, as has been noted, the automatic migration of resources may be performed by the AMS 1000, which includes a brain 1002 and a replication system 1008 that is used to automatically migrate resources based on information (such as IoT location predictions) generated by the brain 1002 in conjunction with a prediction engine 1006. The replication system 1008 may take any suitable form, one example of which is a cloud motion framework (CMotion) that may be based on Dell-EMC RecoverPoint for VMs or similar technologies.

[0052] Generally, the brain 1002 operates to track IoT devices using the prediction engine 1006, which attempts to predict where the IoT devices are going next. Sometimes, determining the destination of an IoT device will be relatively straightforward, for example, in the case of a pre-configured drone flight plan. In other cases, determining the destination of an IoT device will be more complex, as will be appreciated from the following discussion of some exemplary inputs to the prediction engine 1006.

[0053] More specifically, the inputs employed by the prediction engine 1006 can be of various types and can come from any of a variety of sources, including IoT devices and their associated sensors and equipment, sensors in the IoT operating environment, third-party information and applications, social media, and the results of previous resource migration operations. Some specific examples of the prediction engine 1006 inputs received from the input module 1050 and / or elsewhere include, but are not limited to: IoT device location (which can be derived from GPS); IoT device current direction and orientation (from GPS and gyroscope); IoT current speed (from GPS and accelerometer); planned trajectory or travel path (e.g., from a flight plan, a phone / car navigation application); traffic information (e.g., from a cloud map service); weather information (e.g., from a cloud weather service); calendar information (e.g., a car passenger has a meeting at a specific time and location); date / time and usage history (retaining the history of a specific client or client type and using it to predict where he / she is going); social media and chat information (e.g., learned from events in the area, previous communications with contacts); the (multiple) applications accompanying the IoT device may also have information related to the movement of the IoT device, such as a real-time navigation application for a flying drone; and, a feedback loop from previous attempts - learned from prediction errors and attempting to correct based on the actual route taken.

[0054] The prediction engine 1006 can use any combination of the above inputs and / or other inputs related to the IoT device and / or its environment as a basis for generating predictions regarding: (i) the next one or more locations of one or more IoT devices, (ii) when the IoT device will reach that location, and (iii) how long the IoT device may stay at that location. At least in some embodiments, the prediction engine 1006 employs machine learning techniques and prediction methods to process the various inputs and generate location predictions. Exemplary algorithms that the prediction engine 1006 may employ will be discussed below in connection with Figure 5 the discussion of exemplary algorithms that the prediction engine 1006 may employ.

[0055] Continuing to refer to the drawings, and in particular Figure 4, the brain 1002 knows the map of the micro data centers, i.e., the quantity and location, and can feed this information into the prediction engine 1006. Based on the input and the micro data center map, the output of the prediction engine 1006 can be a set of the next locations or micro data centers that the client is expected to move to, the expected movement time, and a set of confidence scores. The brain 1002 takes this information into account and can also take into account the estimated time taken by the companion applications of the migrating IoT and / or other resources that the migration of the IoT may require. Such input can be learned from history, and the current load on the micro data center hardware, networking equipment, resources, the current free bandwidth, and other considerations can be taken into account.

[0056] Using this information, the brain 1002 then decides whether to migrate the application and / or other resources and where to migrate them, and can then initiate the migration process. In some cases, the AMS 1000 can notify the IoT device that a resource migration is in progress and also notify which resources are expected to be available at the next location of the IoT device and when the resources are expected to be available. Additionally or alternatively, the IoT device can verify which resources are available when it contacts the next micro data center or other node. It should be noted that if the prediction engine 1006 does not determine a good prediction of the next location of the IoT, the brain 1002 can decide not to pre-migrate the application until the IoT is closer to another micro data center. In this case, the IoT may be affected by non-optimal latency but will still remain connected. Additionally, the brain 1002 can also decide to copy resources such as applications in parallel to several candidate micro data centers and then perform the actual migration at a later stage when there is an acceptable level of certainty about which micro data center the IoT device will be closest to next.

[0057] When the brain 1002 determines that resources such as one or more applications should be migrated from one node to another, such as from one micro data center to another, the brain will use one or more replication systems 1008 (such as RP4VM or CMotion) to effect the migration. The implementation of the replication system 1008 has various useful functions. For example, the replication system 1008 copies applications (code and data) and / or other resources to one or more remote locations either in parallel or sequentially in time. Similarly, the replication system 1008 can be used to migrate applications and / or other resources to one or more remote locations or nodes without loss of information and with little to no downtime, for example, using features such as planned failover. As a final example, at least in some embodiments, the replication system 1008 is implemented as a pure software solution that is easy to install and remove via automation (scripts and APIs). This configuration enables the replication system 1008 to be installed on demand and when needed.

[0058] After the brain 1002 is configured to handle automatic migration, for example, for a specific application and IoT device, the brain 1002 will consult the prediction engine 1006 and will configure the replication system 1008 to protect the application in the current micro data center and will begin copying the application to one or more candidate micro data centers. At a time that the brain 1002 deems most appropriate, it will failover (i.e., handover or migrate) the application to the selected micro data center and then delete the application copies from the original micro data center and other replicas. In some cases, the migration may involve copying the application to another location or simply removing the application from one location and transporting the application to another location.

[0059] In some cases, the application copy can be retained in the selected micro data center and when the application is needed at the next micro data center, only the changes to the application are copied from the selected micro data center to the next micro data center, that is, it is not necessary to copy the entire application from the selected micro data center to the next data center. In this way, the copy time can be reduced. This functionality may be useful in an environment where IoT devices move relatively quickly and / or unpredictably.

[0060] It should be noted that the operations of the application are not limited to local data, and the application can utilize data from the backend / cloud to perform its operations. Similarly, the application can include a virtual machine (VM), a container, or other components, or be composed of a virtual machine (VM), a container, or other components. In at least some embodiments, no specific hardware or software is required to implement the resource migration function. Instead, in such embodiments, an application programming interface (API) can be used to affect resource migration.

[0061] E. Exemplary Method

[0062] Attention is now turned to Figure 5 , and aspects of a method for migrating an application are disclosed, where one particular exemplary method is generally designated as 1200. Figure 5 Any part or all of the method of Figure 5 can be automatically executed without human action or intervention. Similarly, Figure 5 the method of Figure 5 can be iteratively executed as one or more IoT devices change position or are expected to change position in the environment. In another way, Figure 5 the method of Figure 5 can be iteratively executed regardless of whether the IoT device position is expected to change. Additionally, Figure 5 part or all of the method of

[0063] can be automatically executed in response to the occurrence or non-occurrence of one or more events. For example, the IoT device position prediction can be executed in response to the movement of the IoT device, but such a relationship is not required to be implemented.

[0063] When the prediction engine receives various inputs that can be used as a basis for predicting the future position of the IoT device, method 1200 can begin at 1202. As disclosed herein, such inputs can include, for example, the current position of the IoT device and the speed, range, and orientation of the IoT device. These inputs can be received from sensors in the operating environment, on-board sensors of the IoT device, and any other sources. The prediction engine can also receive location information about one or more micro data centers in the operating environment of the IoT device as an input. Such location information of the micro data center can be in the form of a map and can be received by the prediction engine from the brain at 1202. Also as Figure 5 shown, one of the inputs received by the prediction engine at 1202 can be the location information previously determined by the prediction engine for the IoT device. Thus, the prediction engine can operate in a feedback loop. The prediction engine can also receive information such as micro data center location from the brain as an input.

[0064] After receiving various inputs 1202, the prediction engine can use this information as a basis to predict the location 1204 of the IoT device. For example, if the prediction engine knows the speed, range, and orientation of the IoT device, the prediction engine can estimate the location of the IoT device at a given point in time and predict when the IoT device will reach a specific location, such as the location of a micro data center. In some cases, the input to the prediction engine can be such that at a given point in time, it is possible that the IoT device is moving towards or may be moving towards multiple possible different destinations, such as when the IoT device is approximately equidistant from two different micro data centers. Therefore, the prediction engine can generate a set of multiple locations as output.

[0065] Then, the location information generated by the prediction engine can be received by the brain as input 1206. Other inputs or information that the brain may consider include information such as the time required to migrate an application to a specific location and the resources available at that destination. As Figure 5 shown, the information received by the brain can also be returned to the prediction engine and used as a basis for future IoT location predictions.

[0066] Once the brain receives the location 1204 and other information, the brain can analyze the information received and decide 1208 whether, when, and where to migrate the application or other resources. Migration of an application can include instantiating an instance of the application at a new location or copying the application from one location (such as a micro data center) to a new location. In some cases, the brain can decide not to migrate the application for a period of time. For example, the decision can be based on the brain determining that the latency associated with a possible future location is too long. As another example, the brain can determine that the location prediction provided by the prediction engine is ambiguous or unreliable for some reason. Therefore, in such cases, the brain can delay the migration process until it receives 1206 information that the brain decides supports the decision to migrate the application.

[0067] In other cases, the brain may decide not to migrate the application at all, such as when a drone crashes, for example, before reaching its destination. In this example case, since the drone is unusable, there may be no need to migrate the application. The decision not to migrate the application, whether it is delayed or simply cancelled, can be communicated back to the prediction engine for future prediction processes and / or can be retained by the brain as part of the information received 1206 by the brain for making the migration decision 1208.

[0068] As another example, the brain can decide 1208 to migrate the application and / or other resources to multiple different locations when resources permit, but can also delay the instantiation of the application instance until the movable IoT device moves within an acceptable range of one of the multiple locations. As noted herein, what constitutes an acceptable range can be determined based on, for example, the expected latency between the movable IoT device and the resources at that location. When the movable IoT device has moved within a certain location range, the resources pre-deployed at the application can be instantiated and / or otherwise made available for the movable IoT device to use.

[0069] When and if the brain has decided 1208 to migrate the application, the brain can then decide where to migrate the application and when to start the migration process. Then, at the determined time, the brain migrates 1210 the application(s) and / or other resources to the new location(s). After the migration is complete 1210, the brain can then perform a cleanup 1212 at the previous location, for example, by deleting any copies or data related to the migrated application. Then, the process 1200 can return to 1202 and start over.

[0070] In some cases, the cleanup 1212 can be omitted. For example, it may be useful not to perform the cleanup 1212 and instead use an older version of the application that was previously migrated to another location "X" at a later time (e.g., when the movable IoT device is close to that location). In such a case, only the differences between the current application state and the existing application at location "X" are migrated. That is, less than the entire application is migrated, and it is not necessary to migrate the entire application from scratch.

[0071] F. Exemplary Computing Devices and Associated Media

[0072] Embodiments disclosed herein may include using a special-purpose or general-purpose computer that includes various computer hardware or software modules, as discussed in more detail below. The computer can include a processor and a computer storage medium bearing instructions that, when executed by the processor and / or causing execution by the processor, perform any one or more of the methods disclosed herein.

[0073] As noted above, embodiments within the scope of the present invention also include a computer storage medium that is a physical medium for bearing or having computer-executable instructions or data structures stored thereon. Such computer storage media can be any available physical medium accessible by a general-purpose or special-purpose computer.

[0074] By way of example and not limitation, such computer storage media can include hardware storage devices such as solid state disk / drives (SSDs), RAM, ROM, EEPROM, CD-ROMs, flash memory, phase change memory (“PCM”) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer-executable instructions or data structures that can be accessed and executed by a general or special purpose computer system to implement the functions disclosed herein. Combinations of the above should also be included within the scope of computer storage media. Such media are also examples of non-transitory storage media, and non-transitory storage media also encompasses cloud-based storage systems and architectures, but the scope of the present invention is not limited to these examples of non-transitory storage media.

[0075] Computer-executable instructions include, for example, instructions and data that cause a general purpose computer, special purpose computer, or special purpose processing device to perform a particular function or a group of functions. Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts disclosed herein are disclosed as example forms of implementing the claims.

[0076] As used herein, the term “module” or “component” can refer to software objects or routines executing on a computing system. The different components, modules, engines, and services described herein can be implemented as objects or processes executing on a computing system (e.g., as separate threads). Although the systems and methods described herein can be implemented in software, implementation in hardware or a combination of software and hardware is also possible and contemplated. In the present disclosure, a “computing entity” can be any computing system as previously defined herein, or any module or combination of modules running on a computing system.

[0077] In at least some instances, a hardware processor is provided that is operable to execute executable instructions for performing a method or process such as the methods and processes disclosed herein. The hardware processor may or may not include other hardware elements such as the computing devices and systems disclosed herein.

[0078] In terms of a computing environment, embodiments of the present invention can be executed in a client-server environment, whether a network environment or a local environment, or in any other suitable environment. An operating environment suitable for at least some embodiments of the present invention includes a cloud computing environment where one or more of the client, server, or other machines can reside in and operate within the cloud environment.

[0079] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Thus, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within these claims.

Claims

1. A method for enabling a movable IoT device to use resource-intensive applications, comprising: Receiving an input regarding the movable IoT device, and the input includes: information about the location of the movable IoT device; information about the direction and orientation of the movable IoT device; resources available at a set of nodes; the time required to migrate the application; information about whether the movable IoT device is moving; and, when the movable IoT device is moving, information about the range, speed, planned trajectory, and orientation of the movable IoT device; Generating a predicted position of the movable IoT device at a given point in time based on the received input; Using the predicted position of the movable IoT device, a node map in the environment where the movable IoT device is located and containing the set of nodes, and the input, to make a decision regarding whether part or all of the application used by the movable IoT device is to be migrated from a first node running the application to a second node that the movable IoT device is expected to be able to access when the movable IoT device reaches the predicted position; Migrating a part of the application from the first node to the second node, where the part of the application contains the difference between the current application state and an instance of the application existing at the second node, and the second node is physically separated from the first node by a distance; Automatically pre-deploying resources on the second node in response to obtaining information about the predicted position, the resources including resources required to support the running of the application, where pre-deploying the resources includes replicating virtual machines and / or replicating containers on the second node; and Notifying the movable IoT device that the resources are in the process of migration and are expected to be available for the movable IoT device at the second node, and notifying based on the estimated time required for the resource migration when the resources are expected to be available.

2. The method according to claim 1, wherein the movable IoT device lacks sufficient on-board processing capacity to run the application on the movable IoT device.

3. The method according to claim 1, further comprising initially deciding to copy the application in parallel to multiple candidate nodes before making the decision.

4. The method according to claim 1, wherein the second node is selected to receive the application from the first node based on the expected communication latency between the second node and the movable IoT device.

5. The method according to claim 1, wherein when the movable IoT device reaches the predicted position, the part of the application is automatically migrated from the first node to the second node.

6. The method according to claim 1, wherein the migration of the part of the application starts before the movable IoT device reaches the predicted position.

7. The method according to claim 1, wherein the node includes a micro data center configured to communicate with the movable IoT device.

8. The method according to claim 1, wherein the movable IoT device is an unmanned vehicle or an autonomous vehicle.

9. The method according to claim 1, wherein when the movable IoT device reaches the predicted location, the application program can be accessed and used by the movable IoT device at the second node.

10. A non-transitory storage medium storing instructions executable by one or more hardware processors to perform operations including the following: Receive input regarding a movable IoT device, and the input includes: Information about the location of the movable IoT device; information about the direction and orientation of the movable IoT device; Resources available at a set of nodes; The time required to migrate the application program; Information about whether the movable IoT device is moving; And, when the movable IoT device is moving, information about the range, speed, planned trajectory, and orientation of the movable IoT device; Generate a predicted location of the movable IoT device at a given point in time based on the received input; Use the predicted location of the movable IoT device, a node map in the environment where the movable IoT device is located and includes the set of nodes, and the input to make a decision on whether part or all of the application program used by the movable IoT device is migrated from a first node running the application program to a second node that the movable IoT device is expected to access when the movable IoT device reaches the predicted location; Migrate a part of the application program from the first node to the second node, wherein the part of the application program includes the difference between the current application state and an instance of the application program existing at the second node, and the second node is physically separated from the first node by a distance; In response to obtaining information about the predicted location, automatically pre-deploy resources on the second node, the resources including resources required to support the operation of the application program, wherein pre-deploying the resources includes replicating virtual machines and / or replicating containers on the second node; And Notify the movable IoT device that the resources are in the process of migration and are expected to be available for the movable IoT device at the second node, and notify based on the estimated time required for the resource migration when the resources are expected to be available.

11. The non-transitory storage medium according to claim 10, wherein the movable IoT device lacks sufficient on-board processing power to run the application program on the movable IoT device.

12. The non-transitory storage medium according to claim 10, further including making a preliminary decision to replicate the application program in parallel to multiple candidate nodes before making the decision.

13. The non-transitory storage medium according to claim 10, wherein the second node is selected to receive the application program from the first node based on an expected communication delay between the second node and the movable IoT device.

14. The non-transitory storage medium according to claim 10, wherein when the movable IoT device reaches the predicted location, the portion of the application program is automatically migrated from the first node to the second node.

15. The non-transitory storage medium according to claim 10, wherein the migration of the portion of the application program starts before the movable IoT device reaches the predicted location.

16. The non-transitory storage medium according to claim 10, wherein the node includes a micro data center configured to communicate with the movable IoT device.

17. The non-transitory storage medium according to claim 10, wherein the movable IoT device is an unmanned vehicle or an autonomous vehicle.

18. The non-transitory storage medium according to claim 10, wherein when the movable IoT device reaches the predicted location, the application program can be accessed and used by the movable IoT device at the second node.

Images