EDGE RESOURCE MANAGEMENT

Abstract

Various aspects of processes, systems, and use cases involve the management of edge resources, such as a processor or an edge device. The edge device may include a processor for running an application and a device with an interface to the processor and a network interface. The device may include circuitry for monitoring the processor's status and, based on this status and an associated request, initiating a migration of the application's execution from the processor.

Description

BACKGROUNDGeneral-level edge computing refers to the implementation, coordination, and use of computing and resources at locations closer to the "edge" (border) or collection of "edges" of the network. The purpose of this arrangement is to improve overall operating costs, reduce application and network latency, reduce network backhaul traffic and associated power consumption, improve service functions, and improve compliance with security or privacy requirements (particularly as compared to conventional cloud computing). Components capable of performing edge computing ("edge nodes") may be located at any location required by the system architecture or ad hoc service (e.g., in a high performance data center or cloud installation; a designated edge node server, an enterprise server, a roadside server, a communication center; or a local or peer-to-the-edge device that is being served and consumes edge services).Applications adapted for edge computing include, among other things, virtualization of traditional network functions (e.g., to operate telecommunications or Internet services) and introduction of next generation features and services (e.g., to support 5G network services). Use cases whose planning provides for the substantial use of edge computing include networked self-driving cars, surveillance, Internet of Things (IoT) device data analytics, video coding and analytics, location-aware services, device detection in smart cities, among many other networks and compute-intensive services.Edge computing may, in some scenarios, provide or host a cloud-like distributed service to provide orchestration and management of applications and coordinated service instances among many types of storage and computing resources. Edge computing is also expected to be closely integrated with existing use cases and technology developed for IoT and fog / distributed network configurations because endpoint devices, clients, and gateways attempt to access network resources and applications at locations closer to the edge of the network.BRIEF DESCRIPTION OF THE DRAWINGSIn the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally by way of example, but not limitation, various embodiments discussed in the present document. FIG. 1 illustrates an overview of edge cloud configuration for edge computing, in accordance with some embodiments. FIG. 2 illustrates operating layers between endpoints, an edge cloud, and cloud computing environments, in accordance with some embodiments. FIG. 3 illustrates an example approach for networking and services in an edge computing system, in accordance with some embodiments. FIG. 4 illustrates the provision of a virtual edge configuration in an edge computing system operating between multiple edge nodes and multiple tenants, in accordance with some embodiments. FIG. 5 illustrates various computing arrangements employing containers in an edge computing system, in accordance with some embodiments. FIG. 6 illustrates a computing and communication usage case involving mobile access to applications in an edge computing system, in accordance with some embodiments. FIG. 7A provides an overview of example components for calculations provided at a compute node in an edge computing system, in accordance with some embodiments. FIG. 7B provides another overview of example components within a computing device in an edge computing system, in accordance with some embodiments. FIG. 8 illustrates an example edge platform, in accordance with some embodiments. FIG. 9 illustrates an example architecture for an edge platform, in accordance with some embodiments. FIG. 10 illustrates an example system with a virtual bus for communication with the edge platform, in accordance with some embodiments. FIG. 11 illustrates a flowchart illustrating a technique for managing edge resources, in accordance with some embodiments. FIGS. 12-13 illustrate an example architecture for a maintenance telemetry monitor, in accordance with some embodiments.DETAILED DESCRIPTIONThe systems and techniques described herein provide for the management of edge resources. An edge device (e.g., an edge platform) may include an infrastructure processing unit (IPU). The IPU may be used to offload service or application from a CPU, e.g., when the CPU loses power (e.g., due to maintenance or sudden loss of power). The IPU may execute a service or application and effectively replace the CPU, e.g., for a short period of time, in some examples. In other examples, the IPU may coordinate with a nearby edge device (or a remote edge device or cloud device) to perform service or application migration from the CPU. Although an IPU is referred to throughout this disclosure, other devices may be replaced without deviation or other names may be used to refer to an IPU. These other devices or other names may include an edge processing unit (EPU), a data processing unit (DPU), a smartNIC, an enhanced smartNIC, a network processing unit (NPU), a graphics processing unit (GPU), a programmed FPGA, or the like.In one example, the systems and techniques described herein utilize an interface of an IPU to register an application or service executing on a CPU. The application or service may include a service level agreement (SLA), such as zero downtime, low latency, etc. The IPU may include circuitry to monitor CPU status. The IPU may initiate a migration of the service or application from the CPU to the IPU or other edge device (e.g., by coordinating with an IPU of the other edge device) in response to the status of the CPU indicating an uncontainment of the SLA to execute the application or service according to SLA (or at least according to an improvement of the SLA over the CPU that may not be operable without power).An edge local area network may include a geographic area, such as all edge devices within a few kilometers. The edge devices in a local edge network, which may also be referred to as an hive or system, may have different energy profiles, such as different power supply levels (e.g., availability of sunlight, availability of wind, etc.) or power availability (e.g., battery charge) during a period of time, such as a day.An edge device may use a discovery mechanism, such as via a simple network management protocol (SNMP), to discover peers, or the peers may be specified (e.g., by an orchestrator). The edge device may use a discovery protocol to identify other edge devices and connect, authenticate, and exchange capabilities with these nearby edge devices. In some examples, microservice or power availability may be updated to peer devices, such as daily, every minute, every second, or the like. Telemetry data for published or available microservices or available or predicted performance may be provided at regular intervals. In another example, a publish / subscribe service may be used. For example, when a peer updates CPU availability, network availability, instantiated microservices, power availability, etc., it may publish an update. An IPU of an edge device in the network may subscribe to and receive the published updates from a nearby peer. In some examples, such as availability of power or battery or capacity, an edge device may retrieve the information about a publish / subscribe protocol, such as the MQTT protocol, the data distribution service (DDS), or an M2M communication protocol.FIG. 1 is a block diagram 100 showing an overview of an edge computing configuration that includes a processing layer referred to as an "edge cloud" in many of the following examples. As shown, the edge cloud 110 is located in common at an edge location, such as an access point or base station 140, a local processing hub 150, or a center 120, and thus may include multiple entities, devices, and device instances. The edge cloud 110 is located much closer to the endpoint (consumer and producer) data sources 160 (e.g., autonomous vehicles 161, user equipment 162, business and industrial equipment 163, video capture devices 164, drones 165, smart cities and building devices 166, sensors and IoT devices 167, etc.) than the cloud data center 130. Computing, storage, and storage resources offered at the boundaries in the edge cloud 110 are critical for providing ultra low latency response times for services and functions used by the endpoint data sources 160 as well as for reducing network backhaul traffic from the edge cloud 110 to the cloud data center 130, thereby improving power consumption and overall network uses among other advantages.Computation, storage, and storage are tight resources and generally decrease depending on the edge location (e.g., fewer processing resources are available at consumer endpoint devices than at a base station than at a center). However, the closer the edge location is to the endpoint (e.g., user equipment (UE)), the more space and power are often limited. Thus, edge computing attempts to reduce the amount of resources needed for network services by distributing more resources that are placed closer in both geographically and in network access time. In this way, edge data processing attempts to bring the computational resources to the workload data, if appropriate, or to bring the workload data to the computational resources.The following describes aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their own infrastructures. These include variation of configurations based on edge location (as edges at a base station level may have more constrained performance and capabilities in a multi-tenant scenario, for example); configurations based on the type of computation, storage, storage, tissue, acceleration, or similar resources available for edge locations, levels of locations, or groups of locations; the service, security, and management and orchestration capabilities; and associated goals to achieve the usability and performance of end services. These inserts may perform processing in network layers, which may be considered to be near edge, close edge, local edge, middle edge, or far edge layers depending on latency, distance, and timing characteristics.Edge computing is a developing paradigm in which the computation is performed at or near the "edge (edge)" of a network, usually through the use of a computing platform (e.g., x86 or ARM computing hardware architecture) implemented at base stations, gateways, switches, network routers, or other devices that are much closer to endpoint devices that generate and consume the data. For example, edge gateway servers may be equipped with pools of storage and storage resources to perform real-time computations for low latency use cases (e.g., autonomous driving or video monitoring) for connected client devices. Or as an example, base stations may be enhanced with computing and accelerating resources to directly process service workloads for edged user devices without further communicating data over backhaul networks. Or as another example, central office network management hardware may be replaced with standardized computing hardware that performs virtualized network functions and provides computing resources for executing services and consumer applications for attached devices. Within edge computing networks, there may be scenarios in services in which the computing resource is "moved" to the data, as well as scenarios in which the data is "moved" to the computing resource. Or as an example, base station computation, acceleration, and network resources may provide services to scale workload requirements as needed by enabling quiescent capacity (subscription, capacity as needed) to manage corner cases, incidents, or provide longevity for deployed resources over a substantially longer life cycle implemented.FIG. 2 illustrates operating layers between endpoints, an edge cloud, and cloud computing environments. In particular, FIG. 2 illustrates examples of computing use cases 205 that utilize the edge cloud 110 among multiple illustrative layers of network computing. The layers begin at an endpoint (devices and things) layer 200 that accesses the edge cloud 110 to perform data generation, analysis, and data consumption activities. The edge cloud 110 may span multiple network layers, such as an edge device layer 210 having gateways, on-site servers, or network devices (nodes 215) located in physically proximate edge systems; a network access layer 220 that encloses base stations, radio processing units, hubs, regional data centers (DC), or local network devices (equipment 225); and any devices, devices, or nodes located therebetween (in layer 212, not illustrated in detail). Network communications within the edge cloud 110 and between the various layers may occur over any number of wired or wireless media, including via connectivity architectures and technologies not shown.Examples of latencies resulting from limitations of network communication distance and processing time may range from less than one millisecond (ms) at the endpoint layer 200, less than 5 ms at the edge device layer 210, to even between 10 and 40 ms in communication with nodes at the network access layer 220. Beyond the edge cloud 110, layers of the core network 230 and the cloud data center 240 are located, each with increasing latency (e.g., between 50-60 ms on the core network layer 230 up to 100 or more ms on the cloud data center layer). As a result, operations at a core network data center 235 or cloud data center 245 with latencies of at least 50 to 100 ms or more will not be able to implement many time critical functions of the use cases 205. Each of these latency values is provided for illustrative and contrast purposes; it should be appreciated that the use of other access network media and technologies may further reduce latencies. In some examples, respective portions of the network relative to a network source and a network destination may be categorized as "close edge", "local edge", "near edge", "middle edge", or "far edge" layers. For example, from the perspective of the core network data center 235 or cloud data center 245, a center or content data network may be considered to be within a near edge ("close" to the cloud, with high latency values when communicating with the devices and endpoints of the use cases 205), whereas an access point, base station, on-site server, or network gateway may be considered to be within a far edge ("remote" from the cloud, with low latency values when communicating with the devices and endpoints of the use cases 205). It should be appreciated that other categorizations of a particular network layer that form a "near", "local", "near", "medium", or "far" edge may be based on latency, distance, number of network hops, or other measurable characteristics as measured from a source in any of the network layers 200- 240.The various instances of use 205 may access resources that are pressurized in use by incoming streams because multiple services use the edge cloud. To achieve low latency results, the services executing within the edge cloud 110 resemble varying requirements with respect to: (a) priority (throughput or latency) and quality of service (QoS) (for example, traffic for an autonomous vehicle may have a higher priority than a temperature sensor with respect to the response time request; or a power sensitivity / bottleneck may be present on a compute / accelerator, storage, storage, or network resource, depending on the application); (b) Reliability and Resistivity (e.g., some input streams must be processed and traffic routed with mission critical reliability, while some other input streams may tolerate occasional disturbance depending on the application); and (c) physical constraints (e.g., power, cooling, and form factor).The end-to-end service view for these use cases involves the concept of service flow and is associated with a transaction. The transaction accurately describes the overall service request for the entity that consumes the service, as well as the associated services for the resources, workloads, workflows, and business function and business level requests. The services executing with the described "conditions" may be managed at each layer in a manner to ensure real-time and runtime contract conformance for the transaction during the lifecycle of the service. If a component in the transaction fails to meet its Quality of Service (Level Agreement= SL), the system as a whole (components in the transaction) may provide the ability to (1) understand the effects of the SLA violation and (2) supplement other components in the system to restore the overall SLA of the transaction, and (3) implement remedial steps.Accordingly, considering these deviations and service characteristics, edge computing within the edge cloud 110 may provide the ability to service and respond to multiple applications of the use cases 205 (e.g., object tracking, video monitoring, connected vehicles, etc.) in real-time or near real-time and meet ultra low latency requirements for these multiple applications. These advantages enable a new class of applications (virtual network functions (VNF), function as a service (FaaS), edge as a service (EaaS), standard processes, etc.) that cannot efficiently utilize conventional cloud computing due to latency or other constraints.However, with the advantages of edge data processing, the following reservations are given. The devices placed on the edge are often resource constrained and therefore there is pressure on the use of edge resources. Typically, this is addressed by bundling storage and storage resources for use by multiple users (tenants) and devices. The edge may be constrained in power and cooling, and therefore power consumption by the applications that consume most of the power must be accounted for. These pooled memory resources may be compromised between power and power consumption because many of them are likely to use new memory technologies where more power requires a larger memory bandwidth. Also, improved security of hardware and trusted root-of-trust functions is required, as edge locations may be unmanned and even require authorized access (e.g., when located at a third party location). Such problems are magnified in the edge cloud 110 in a multi-tenant, multi-owner, or multi-access situation where services and applications are requested by many users, particularly as network usage varies dynamically and the composition of the multiple participants, use cases, and services changes.At a more generic level, an edge computing system may be described as including any number of deployments at the layers discussed above that operate in the edge cloud 110 (network layers 200- 240) that provide coordination of client and distributed computing devices. One or more edge gateway nodes, one or more edge aggregation nodes, and one or more core data centers may be distributed across layers of the network to provide an implementation of the edge computing system by or on behalf of a telecommunications service provider ("Telco" or "TSP"), Internet of Things service providers, cloud service providers (CSP), a enterprise entity, or any other number of entities. Various implementations and configurations of the edge computing system may be provided dynamically, such as when orchestration is performed to meet service objectives.In accordance with the examples provided herein, a client computing node may be embodied as any type of endpoint component, device, application, or other ping capable of communicating as a producer or consumer of data. Further, the label "node" or "device" as used in the edge computing system does not necessarily mean that such node or device operates in a client or agent / minion / follower role; rather, any of the nodes or devices in the edge computing system refer to individual entities, nodes, or subsystems that include special or interconnected hardware or software configurations to enable or use the edge cloud 110.As such, the edge cloud 110 is formed by network components and features that operate by and within edge gateway nodes, edge aggregation nodes, or other edge computing nodes between the network layers 210- 230. The edge cloud 110 may thus be embodied as any type of network that provides edge computing and / or storage resources that are proximate to radio access network (RAN)-enabled endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.) discussed herein. In other words, the edge cloud 110 may be considered an "edge" that connects the endpoint devices and traditional network access points that serve as an entry point into service provider core networks, including carrier mobile networks (e.g., Global System for Mobile Communication (GSM) networks, long-term evolution (LTE) networks, 5G / 6G networks, etc.), while also providing storage and / or computing capabilities. Other types and forms of network access (e.g., WiFi, long-range wireless, wired networks, including optical networks) may also be used in place of, or in combination with, such 3GPP carrier networks.The network components of the edge cloud 110 may be servers, multi-tenant servers, device computing devices, and / or any other type of computing device. For example, the edge cloud 110 may be a device computing device that is a stand-alone processing system including a housing, a shell, or a shell. In some cases, edge devices are devices that are presented in the network for a specific purpose (e.g., a traffic light), but that have processing or other capabilities that may be utilized for other purposes. Such edge devices may be independent of other networked devices and may be provided with a housing having a form factor suitable for its primary purpose; they may nevertheless be available for other computing tasks that do not interfere with their primary task. Edge devices include Internet of Things devices. The device computing device may include hardware and software components to manage local issues such as device temperature, vibration, resource utilization, updates, power issues, physical and network security, etc. Example hardware for implementing a device computing device is described in connection with FIG. 7B. The edge cloud 110 may also include one or more servers and / or one or more multi-tenant servers. Such a server may implement a virtual computing environment, such as a hypervisor for deploying virtual machines, an operating system that implements containers, etc. Such virtual computing environments provide an execution environment in which one or more applications may be executed while isolated from one or more other applications.In FIG. 3, various client endpoints 310 (in the form of mobile devices, computers, autonomous vehicles, business computing devices, industrial processing devices) exchange requests and responses specific to the type of endpoint network aggregation. For example, client endpoints 310 may obtain network access over a broadband wired network by exchanging requests and responses 322 through an on-site network system 332. Some client endpoints 310, such as mobile computing devices, may access the network via a broadband wireless network by exchanging requests and responses 324 via an access point (e.g., cell tower) 334. Some client endpoints 310, such as autonomous vehicles, may obtain network access for requests and responses 326 via a wireless vehicle network through a road-bound network system 336. However, regardless of the type of network access, the TSP may employ aggregation points 342, 344 within the edge cloud 110 to aggregate traffic and requests. Thus, the TSP within the edge cloud 110 may employ various computing and storage resources, such as at edge aggregation nodes 340, to provide requested content. The edge aggregation nodes 340 and other systems of the edge cloud 110 are connected to a cloud or data center 360 that uses a backhaul network 350 to satisfy higher latency requests from a cloud / data center for websites, applications, database servers, etc. Additional or consolidated instances of the edge aggregation nodes 340 and aggregation points 342, 344, including those deployed on a single server framework, may also be present within the edge cloud 110 or other areas of the TSP infrastructure.FIG. 4 illustrates deployment and orchestration for virtual edge configurations via an edge computing system operating between multiple edge nodes and multiple tenants. In particular, FIG. 4 illustrates coordination of a first edge node 422 and a second edge node 424 in an edge computing system 400 to meet requests and responses for various client endpoints 410 (e.g., smart cities / building systems, mobile devices, computing devices, enterprise / logistics systems, industrial systems, etc.) accessing various virtual edge instances. Here, the virtual edge instances 432, 434 provide edge computing capabilities and processing in an edge cloud with access to a cloud / data center 440 for higher latency requests for websites, applications, database servers, etc. However, the edge cloud enables coordination of processing between multiple edge nodes for multiple tenants or entities.In the example of FIG. 4, these virtual edge instances include: a first virtual edge 432 that is offered to a first tenant (tenant 1) and offers a first combination of edge storage, computation, and services; and a second virtual edge 434 that offers a second combination of edge storage, computation, and services. The virtual edge instances 432, 434 are distributed among the edge nodes 422, 424, and may include scenarios where a request and response from the same or different edge nodes are satisfied. The configuration of the edge nodes 422, 424 to operate in a distributed but coordinated manner occurs based on edge provisioning functions 450. The functionality of the edge nodes 422, 424 to provide coordinated operation for applications and services between multiple tenants occurs based on orchestration functions 460.It should be appreciated that some of the devices in 410 are multi-tenant devices, where tenant 1 may function within a tenant 1, segment', while tenant 2 may function within a tenant 2 segment (and in further examples, additional or sub-tenants may exist; and each tenant may even be specifically eligible and transactively bound to a specific set of features through to specific hardware features). A trusted multi-tenant device may further include a tenant-specific cryptographic key such that the combination of key and segment may be considered a "root confidence" (RoT) or tenant-specific RoT. A RoT may further be dynamically calculated using a Device Identity Composition (DICE) architecture, such that a single DICE hardware package may be used to construct layered trusted computing base contexts for layering device capabilities (such as a field programmable gate array (FPGA)). The RoT may also be used for a trusted computing context to enable "fanout" useful for supporting a tenant. Within a multi-tenant environment, the respective edge nodes 422, 424 may operate as security feature enforcement points for local resources allocated to multiple tenants per node. Additionally, tenant runtime and application execution (e.g., in cases 432, 434) may serve as a point of enforcement for a security feature that generates a virtual edge abstraction of resources that potentially span multiple physical hosting platforms. Finally, the orchestration functions 460 may operate on an orchestration entity as a security feature enforcement point for marshalling resources along tenant boundaries.Edge compute nodes may partition resources (memory, central processing unit (CPU), graphics processing unit (GPU), interrupt control, input / output (I / O) control, memory control, bus control, etc.), where respective partitionings may include RoT capability, and where fan-out and layering according to a DICE model may further be applied to edge nodes. Cloud compute nodes, consisting of containers, FaaS engines, servlets, servers, or other compute abstraction, may be partitioned according to a DICE layering and fan-out structure to each support a RoT context. Accordingly, the respective devices 410, 422 and 440 spanning RoTs may coordinate the creation of a distributed trusted computing base (DTCB) such that a tenant-specific virtual trusted secure channel that links all elements end-to-end may be created.Further, it should be appreciated that a container may have data or workload specific keys that protect its content from a previous edge node. As part of container migration, a pod controller at a source edge node may receive a migration key from a destination edge node pod controller, the migration key being used to wrap the container specific keys. When the container / pod is migrated to the destination edge node, the unwriting key is advertised to the pod controller, which then decrypts the tapped keys. The keys can now be used to perform operations on container specific data. The migration functions may be driven by correctly acknowledged edge nodes and pod managers (as described above).In further examples, an edge computing system is extended to provide orchestration of multiple applications through the use of containers (a closed, deployable software unit that provides code and required dependencies) in a multiple owner, multiple tenant environment. A multi-tenant orchestrator may be used to perform key management, trust anchor management, and other security functions related to the provisioning and lifecycle of the trusted "slice" concept of FIG. 4. For example, an edge computing system may be configured to satisfy requests and responses for different client endpoints from multiple virtual edge instances (and from a cloud or remote data center). Use of these virtual edge instances may support multiple tenants and multiple applications (e.g., augmented reality (AR) / virtual reality (VR), enterprise applications, content delivery, gaming, compute offload) simultaneously. Further, there may be multiple types of applications within the virtual edge instances (e.g., normal applications; latency sensitive applications; latency critical applications; user plane applications; networking applications, etc.). The virtual edge instances may also be spanning systems of multiple owners at different geographic locations (or respective computing systems and resources shared or managed jointly by multiple owners).For example, each edge node 422, 424 may implement the use of containers, such as using container pod 426, 428 providing a group of one or more containers. In a scenario using one or more container pods, a pod controller or orchestrator is responsible for locally controlling and orchestrating the containers in the pod. Different edge node resources (e.g., storage, computation, services represented with hexagon) provided to the respective edge slices 432, 434 are partitioned according to the needs of each container.When using container pods, pod control oversees the partitioning and assignment of containers and resources. The pod controller receives instructions from an orchestrator (e.g., orchestrator 460) that instructs the controller how to best partition physical resources and for what duration, as by receiving key performance indicator (KPI) targets based on SLA contracts. The pod controller determines which container needs which resources as long to complete the workload and satisfy the SLA. The pod controller also manages container lifecycle operations such as: creating the container, providing it with resources and applications, coordinating intermediate results between multiple containers working together on a distributed application, disassembling containers when the workload is complete, and the like. In addition, pod control may play a security role that prevents allocation of resources until the proper tenant authenticates itself or prevents provision of data or workload to a container until an assessment result is met.Also when using container pods tenant boundaries may still exist, but in the context of any pod of containers. If each tenant-specific pod has tenant-specific pod control, there will be shared pod control that consolidates resource allocation requests to avoid typical resource shortage situations. Further controllers may be provided to ensure an assessment and trustworthiness of the pod and pod controller. For example, the orchestrator 460 may provide an attestation verification policy to local pod controllers that perform an attestation verification. If an assessment satisfies a policy for a first tenant pod control but not for a second tenant pod control, then the second pod could be migrated to another edge node that satisfies it. Alternatively, the execution of the first pod may be enabled and another shared pod controller installed and invoked before the second pod is executed.FIG. 5 illustrates additional computing arrangements that employ containers in an edge computing system. As a simplified example, system arrangements 510, 520 represent settings where a pod controller (e.g., container manager 511, 521 and container orchestrator 531) is configured to launch containerized pods, functions, and functions as a service instances by execution via compute nodes (515 in arrangement 510) or to separately execute containerized virtualized network functions by execution via compute nodes (523 in arrangement 520). This arrangement is configured to use multiple tenants in a system arrangement 530 (using compute nodes 537), starting containerized tenants (e.g., tenants 512), functions (e.g., functions 513, VNFs 522, 536), and function as a service instances (e.g., FaaS instance 514) within virtual machines (e.g., VMs 534, 535 for tenants 532, 533) that are specific to respective tenants (except for executing virtualized network functions). This arrangement is further suitable for use in the system arrangement 540 which provides containers 542, 543 or the execution of the various functions, applications and functions on compute nodes 544 that are coordinated by a container-based orchestration system 541.The system arrangement shown in FIG. 5 provides an architecture that handles VMs, containers, and functions the same in terms of application composition (and the resulting applications are combinations of these three components). Each component may use one or more accelerator components (FPGA, ASIC) as a local backend. In this way, applications may be shared across multiple edge owners coordinated by an orchestrator.In the context of FIG. 5, the pod controller / container manager, container orchestrator, and the individual nodes may provide a security completion point. However, tenant isolation may be orchestrated where the resources allocated to one tenant are different from resources allocated to a second tenant, but edge owners cooperate to ensure that resource allocations are not shared across tenant boundaries. Or, resource assignments could be isolated across tenant boundaries, as tenants could enable "use" across a subscription or transaction / contract basis. In these contexts, edge owners virtualization, containerization, enclave, and hardware partitioning schemes may be used to enforce tenant capability. Other isolated environments may include: bare metal (dedicated) equipment, virtual machines, containers, virtual machines on containers, or combinations thereof.In further examples, aspects of software-defined or software-controlled silicon hardware and other configurable hardware may be incorporated into the applications, functions, and services of an edge computing system. Software-defined silicon may be used to ensure the ability for a resource or hardware component to meet a contract or quality of service agreement based on the ability of the component to correct a portion of itself or workload (e.g., by upgrading, reconfiguring, or providing new functions within the hardware configuration itself).It should be appreciated that the edge computing systems and arrangements discussed herein may be applicable in various solutions, services, and / or use cases involving mobility. As an example, FIG. 6 shows a simplified vehicle computing and communication application case involving mobile access to applications in an edge computing system 600 implementing an edge cloud 110. In this example application, respective client computing nodes 610 may be implemented as in-vehicle computing systems (e.g., in-vehicle navigation and / or infotainment systems) located in respective vehicles that communicate with edge gateway nodes 620 while traversing a road. For example, the edge gateway nodes 620 may be located in a switch cabinet or other enclosure that is incorporated into a structure having a different, separate, mechanical benefit and may be placed along the road, at intersections of the road, or other locations near the road. As respective vehicles travel along the road, the connection between their client compute node 610 and a particular edge gateway device 620 may propagate to maintain a consistent connection and context for the client compute node 610. Similarly, mobile edge nodes may aggregate (e.g., in the case of drones) at the high priority services or according to throughput or latency resolution requirements for the one or more underlying services. The respective edge gateway devices 620 include a set of processing and storage capabilities, and therefore, some processing and / or storage of data for the client compute nodes 610 may be performed on one or more of the edge gateway devices 620.The edge gateway devices 620 may communicate with one or more edge resource nodes 640, illustratively implemented as computing servers, devices, or components located at or in a communication base station 642 (e.g., a base station of a cellular network). As discussed above, the respective edge resource nodes 640 include a set of processing and storage capabilities, and thus processing and / or storage of data for the client computing nodes 610 may be performed at the edge resource node 640. For example, the processing of data that is less urgent or important may be performed by the edge resource node 640, while the processing of data that has a higher urgency or importance may be performed by the edge resource devices 620 (depending on, for example, the capabilities of each component or information in the request that indicates the urgency or importance). Based on data access, data location, or latency, work on edge resource nodes may continue as processing priorities change during processing activity. Similarly, configurable systems or hardware resources may themselves be activated (e.g., by a local orchestrator) to provide additional resources to satisfy the new request (e.g., adapt the computing resources to the workload data).The one or more edge resource nodes 640 also communicate with core data center 650, which may include compute servers, devices, and / or other components located at a central location (e.g., a central office of a cellular communication network). The core data center 650 may provide a gateway to the global network cloud 660 (e.g., Internet) for the operations of the edge cloud 110 formed by the one or more edge resource nodes 640 and the edge gateway devices 620. Additionally, in some examples, the core data center 650 may include a set of processing and storage capabilities, and thus some processing and / or storage of data for the client computing devices may be performed on the core data center 650 (e.g., low urgency or importance or high complexity processing).The edge gateway nodes 620 or the edge resource nodes 640 may provide the use of state-oriented applications 632 and geographic distributed database 634. Although applications 632 and database 634 are illustrated as being horizontally distributed in a layer of edge cloud 110, it should be appreciated that resources, services, or other components of the application may be vertically distributed throughout the edge cloud (including a portion of the application executing at client computing node 610, other portions executing at edge gateway node 620 or edge resource node 640, etc.). In addition, as previously stated, there may be peer relationships at any level to meet service objectives and obligations. Further, the data for a specific client or application may move edge-to-edge based on changing conditions (e.g., based on accelerator resource availability, vehicle movement consequences, etc.). For example, based on the "decay rate" of the access, a prediction may be made to identify the next owner to continue, or to identify when the data or computational access will no longer be implementable. These and other services may be used to complete the work needed to keep the transaction compliant and lossless.In other scenarios, container 636 (or a pod of containers) may be flexibly migrated from one edge node 620 to other edge nodes (e.g., 620, 640, etc.) such that the container does not need to be re-constituted, re-compiled, re-interpreted with an application and workload for the migration to function. In such settings, however, there may be some remedial or "swizling" translation operations that are applied. For example, the physical hardware at node 640 may be different from edge gateway node 620, and thus the hardware abstraction layer (HAL) that forms the bottom edge of the container is re-mapped to the physical layer of the destination edge node. This may involve some form of late binding technique, such as binary translation of the HAL from the native container format to the physical hardware format, or may involve mapping of interfaces and operations. Pod control may be used to direct interface mapping as part of the container life cycle, which involves migration to / from various hardware environments.The scenarios involving FIG. 6 may utilize various types of mobile edge nodes, such as an edge node hosted in a vehicle (car / truck / highway / railway) or other mobile unit, as the edge node will move to other geographic locations along the platform that hosts it. In vehicle-to-vehicle communications, individual vehicles may even function as network edge nodes for other cars (e.g., to perform caching, reporting, data aggregation, etc.). Thus, it should be appreciated that the application components provided in different edge nodes may be distributed in static or mobile settings, including coordination between some functions or operations at individual endpoint devices or edge gateway nodes 620, some others at edge resource node 640, and others at core data center 650 or global network cloud 660.In other configurations, the edge computing system may implement FaaS computing capabilities through the use of respective executable applications and functions. In one example, a developer writes function code (herein, for example, "computer code") representing one or more computer functions, and the function code is uploaded to a FaaS platform provided, for example, by an edge node or a data center. A trigger, such as a service application case or edge processing event, initiates execution of the function code with the FaaS platform.In an example of FaaS, a container is used to provide an environment in which function code (e.g., an application that may be provided by a third party provider) is executed. The container may be any entity of isolated execution, such as a process, a docker or Kubernetes container, a virtual machine, etc. Within the edge computing system, various central computing, edge, and endpoint devices (including mobile devices) are used to "boot" functions (e.g., enable and / or assign function actions) that are scaled on demand. The function code executes on the physical infrastructure device (e.g., edge computing nodes) and underlying virtualized containers. Finally, the container on the infrastructure is "spun down" (e.g., deactivated and / or released) in response to execution being completed.Further aspects of FaaS may enable provision of edge functions in a service form that includes support of respective functions that support edge computing as an edge-as-a-service ("EaaS"). Additional features of FaaS may include: a granular accounting component that enables customers (e.g., computer code developers) to pay only when their code is executed; shared storage for storing data for reuse by one or more functions; orchestration and management between individual functions; function execution management, parallelism, and consolidation; management of container and function storage spaces; coordination of acceleration resources available for functions; and distribution of functions between containers (including "warm" containers that are already deployed or operated versus "cold" that require initialization, deployment, or configuration).The edge computing system 600 may include or be in communication with an edge provisioning node. The edge deployment node may distribute software, such as the example computer readable instructions 782 of FIG. 7B, to various receiving parties to implement any of the methods described herein. The example edge deployment node 644 may be implemented by any computer server, home server, content delivery network, virtual server, software distribution system, central plant, storage device, storage node, data plant, cloud service, etc., that is / are capable of storing and / or transmitting software instructions (e.g., code, scripts, executable binary codes, containers, packages, compressed files, and / or derivatives thereof) to other computing devices. One or more components of the example edge deployment node 644 may be located in a cloud, a local area network, an edge network, a wide area network, the Internet, and / or any other location communicatively coupled to the one or more receiving parties. The receiving participants may be consumers, customers, associates, users, etc., of the entity owning and / or operating the edge provisioning node 644. For example, the entity that owns and / or operates the edge deployment node 644 may be a developer, seller, and / or licenser (or customer and / or consumer thereof) of software instructions, such as the example computer readable instructions 782 of FIG. 7B. The receiving participants may be consumers, service providers, users, retailers, OEMs, etc., that acquire and / or license the software instructions for use and / or resale and / or subliticence.In an example, the edge provisioning node 644 includes one or more servers and one or more storage devices. The storage devices host computer readable instructions, such as the example computer readable instructions 782 of FIG. 7B, as described below. Similar to the edge gateway devices 620 described above, the one or more servers of the edge provisioning node 644 are in communication with a base station 642 or other network communication entity. In some examples, the one or more servers are responsive to requests to transmit the software instructions to a requesting party as part of a commercial transaction. Payment for the delivery, sale, and / or license of the software instructions may be handled by the one or more servers of the software distribution platform and / or via a third party payment entity. The servers enable buyers and / or licensees to download the computer readable instructions 782 from the edge provisioning node 644. For example, the software instructions, which may correspond to the example computer readable instructions 782 of FIG. 7B, may be downloaded to the one or more example processor platforms that are to execute the computer readable instructions 782 to implement the methods described herein.In some examples, the processor platform(s) executing the computer readable instructions 782 may be physically located at different geographic locations, in different legal jurisdictions, etc. In some examples, one or more servers of the edge deployment node 644 periodically offer, transmit, and / or force updates to the software instructions (e.g., the example computer readable instructions 782 of FIG. 7B ) to ensure that improvements, patches, updates, etc., are distributed and applied to the software instructions implemented at the end user devices. In some examples, different components of the computer readable instructions 782 may be distributed from different sources and / or to different processor platforms; for example, different libraries, plug-ins, components, and other types of computing modules, whether compiled or interpreted, may be distributed from different sources and / or to different processor platforms. For example, a portion of the software instructions (e.g., a script that is not executable per se) may be distributed from a first source, while an interpreter (that is capable of executing the script) may be distributed from a second source.In further examples, any of the compute nodes or devices discussed with reference to the present edge computing systems and environment may be satisfied based on the components depicted in FIGS. 7A and 7B. Respective edge compute nodes may be embodied as a type of device, device, computer, or other "object" suitable for communicating with other edge, network, or endpoint components. For example, an edge computing device may be configured as a personal computer, server, smart phone, mobile computing device, smart device, in-vehicle computing system (e.g., navigation system), stand-alone device having an outer housing, a shell, etc., or other device or system capable of performing the described functions.In the simplified example shown in FIG. 7A, an edge compute node 700 includes a compute engine (also referred to herein as "compute circuitry") 702, an input / output (I / O) subsystem 708, a data storage 710, a communication circuitry subsystem 712, and optionally one or more peripheral devices 714. In other examples, respective computing devices may include other or additional components, such as those commonly found in a computer (e.g., a display, peripheral devices, etc.). Additionally, in some examples, one or more of the illustrative components may be integrated with or otherwise form a part of another component.The compute node 700 may be embodied as any type of engine, device, or collection of devices capable of performing various computing functions. In some examples, computing node 700 may be embodied as a single device, such as an integrated circuit, embedded system, field programmable gate array (FPGA), system-on-chip (SOC), or other integrated system or device. In the illustrative example, the compute node 700 includes or is configured as a processor 704 and a memory 706. Processor 704 may be implemented as any type of processor capable of performing the functions described herein (e.g., executing an application). The processor 704 may be implemented, for example, as one or more multi-core processors, a microcontroller, a processing unit, a special or special purpose processing unit, or another processor or processing / control circuit.In some examples, processor 704 may be embodied as, include, or coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other specialized hardware to enable performance of the functions described herein. In some examples, processor 704 may also be embodied as a specialized x-processing unit (xPU), also known as a data processing unit (DPU), infrastructure processing unit (IPU), or network processing unit (NPU). Such an xPU may be implemented as a stand-alone circuit or circuit package, integrated within an SOC, or integrated with networking circuitry (e.g., in a SmartNIC or enhanced SmartNIC), acceleration circuitry, storage devices, or Al hardware (e.g., GPUs or programmed FPGAs). Such an xPU may be configured to receive programming to process one or more data streams and perform specific tasks and actions for the data streams (such as hosting microservices, performing service management or orchestration, organizing or managing server or datacenter hardware, managing service networks or collecting and distributing telemetry), external to the CPU or general purpose processing hardware. However, it should be appreciated that an xPU, SOC, CPU, and other variations of processor 704 may operate in coordination with one another to perform many types of operations and instructions within and on behalf of computing node 700.The memory 706 may be embodied as any type of volatile (e.g., dynamic random access memory, DRAM, etc.) or nonvolatile memory or nonvolatile data storage suitable for performing the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of data stored by the medium. Non-limiting examples of volatile memory may include various types of random access memory (RAM), such as DRAM or static random access memory (SRAM). One particular type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM).In one example, the memory device is a block addressable memory device such as those based on NAND or NOR technologies. A memory device may also include a three-dimensional crosspoint memory device (e.g., Intel® 3D XPoint™ memory) or other byte addressable non-volatile memory devices for writing in place. The storage device may refer to the die itself and / or to a packaged storage product. In some examples, the 3D crosspoint memory (e.g., Intel® 3D XPoint™ memory) may comprise a transistorless stackable crosspoint architecture in which memory cells sit at the intersection of word lines and bit lines and are individually addressable, and in which bit storage is based on a change in bulk resistance. In some examples, all or a portion of memory 706 may be integrated with processor 704. The memory 706 may store various software and data used during operation, such as one or more applications, data processed by the one or more applications, libraries, and drivers.The computing circuit 702 is communicatively coupled to other components of the computing node 700 via the I / O subsystem 708, which may be embodied as circuitry and / or components to enable input / output operations with the computing circuit 702 (e.g., with the processor 704 and / or the main memory 706) and other components of the computing circuit 702. I / O subsystem 708 may be implemented as, or otherwise include, memory controller hubs, input / output controller hubs, integrated sensor hubs, firmware devices, communication links (e.g., point-to-point links, bus links, wires, cables, light pipes, traces, etc.), and / or other components and subsystems to enable the input / output operations. In some examples, the I / O subsystem 708 may form a portion of a system on a chip (SoC), and may be incorporated into the computation circuit 702 along with the processor 704 and / or the memory 706 and / or other components of the computation circuit 702.The one or more illustrative data storage devices 710 may be implemented as any type of devices configured for short-term or long-term storage of data, such as storage devices and circuits, memory cards, hard disk drives, solid state drives, or other data storage devices. Individual data storage devices 710 may include a system partition that stores data and firmware code for the data storage device 710. Individual data storage devices 710 may also include one or more operating system partitions that store files and executable files for operating systems depending on, for example, the type of computing node 700.Communication circuitry 712 may be embodied as any communication circuit, device, or collection thereof capable of enabling communications over a network between computing circuitry 702 and another computing device (e.g., an edge gateway of an implementing edge computing system). Communication circuitry 712 may be configured to communicate any one or more communication technologies (e.g., wired or wireless communications) and associated protocols (e.g., a cellular network protocol such as a 3GPP-4G or 5G standard, a wireless local area network protocol such as IEEE 802.11 / Wi-Fi® a wireless wide area network protocol, Ethernet, Bluetooth® Bluetooth Low Energy, an IoT protocol such as IEEE 802.15.4, or ZigBee®, To effect such communication, use low power wide area network (LPWAN) or low power wide area (LPWA) protocols, etc.).Illustrative communication circuitry 712 includes a network interface controller (NIC) 720, which may also be referred to as a host fabric interface (HFI). The NIC 720 may be embodied as one or more add-on boards, sub-cards, network interface cards, control chips, chipsets, or other devices that may be used by the compute node 700 to connect to another compute device (e.g., an edge gateway node). In some examples, the NIC 720 may be implemented as part of a system on a chip (SoC) that includes one or more processors, or included on a multichip package that also includes one or more processors. In some examples, the NIC 720 may include a local processor (not shown) and / or local memory (not shown), both of which are local to the NIC 720. In such examples, the local processor of the NIC 720 may be capable of performing one or more of the functions of the computing circuitry 702 described herein. Additionally or alternatively, in such examples, the local memory of the NIC 720 may be incorporated into one or more components of the client computing node at the board, socket, chip level and / or other levels.Additionally, in some examples, a respective compute node 700 may include one or more peripheral devices 714. Such peripheral devices 714 may include any type of peripheral device found in a computing device or server, such as audio input devices, a display, other input / output devices, interface devices, and / or other peripheral devices, depending on the particular type of computing node 700. In further examples, the compute node 700 may be embodied by a respective edge compute node (whether a client, gateway, or aggregation node) in an edge computing system or similar forms of devices, computers, subsystems, circuits, or other components.In a more detailed example, FIG. 7B illustrates a block diagram of an example of components that may be present in an edge compute node 750 for implementing the techniques (e.g., operations, processes, methods, and methods) described herein. This edge compute node 750 provides a closer view of the respective components of the node 700 when implemented as or as part of a computing device (e.g., a mobile device, a base station, a server, a gateway, etc.). The edge compute node 750 may include any combination of the hardware or logical components referenced herein, and may include or couple to any device usable with an edge communication network or combination of such networks. The components may be implemented as integrated circuits (ICs), portions thereof, dedicated electronic devices or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or a combination thereof, adapted in the edge computing node 750, or as components otherwise included in a chassis of a larger system.The edge computing device 750 may include processing circuitry in the form of a processor 752 which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, an xPU / DPU / IPU / NPU, a special purpose processing unit, a specialized processing unit, or other known processing elements. The processor 752 may be part of a system-on-chip (SoC) in which the processor 752 and other components are formed in a single integrated circuit or package, such as the Edison™ or Galileo™ SoC boards from Intel Corporation of Santa Clara, California. As an example, processor 752 may include a Intel® Architecture Core™ based CPU processor, such as a Quark™ Atom™ i3, i5, i7, i9, or MCU class processor, or other such processor available from Intel®. However, any number of other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD®) of Sunnyvale, California, USA, a MIPS® based design of MIPS Technologies, Inc. of Sunnyvale, California, USA, a ARM® based design licensed by ARM Holdings, Ltd., or a customer thereof, or their licensees or users. The processors may include entities such as an A5-A13 processor from Apple® Inc., an Snapdragon™ processor from QualCommon® Technologies, Inc., or an OMAP™ PROCESSOR from Texas Instruments, Inc. The processor 752 and the accompanying circuitry may be provided in a single socket shape factor, multiple socket shape factors, or a variety of other formats, including in limited hardware configurations or configurations that include less than all of the elements shown in FIG. 7B.Processor 752 may communicate with system memory 754 via an interconnect 756 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. As examples, the memory 754 may be random access memory (RAM) according to a joint electron device engineering council (JEDEC) design, such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In certain examples, a memory component may conform to a DRAM standard promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4. Such standards (and similar standards) may be referred to as DDR-based standards, and communication interfaces of the storage devices implementing such standards may be referred to as DDR-based interfaces. In various implementations, the individual memory devices may be any of a number of different package types, such as single die package (SDP), dual die package (DDP), or quad die package (Q17P). These devices may be soldered directly to a motherboard in some examples to provide a lower profile solution, while in other examples the devices are configured as one or more memory modules, which in turn are coupled to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different variants, including microDIMMs or miniDIMMs.To provide persistent storage of information such as data, applications, operating systems, etc., storage 758 may also be coupled to processor 752 via interconnect 756. In an example, storage 758 may be implemented via a solid state disk drive (SSDD). Other devices that may be used for storage 758 include flash memory cards, such as secure digital (SD) cards, microSD cards, eXtreme digital (XD) photo cards, and the like, and universal serial bus (USB) flash drives. In one example, the memory device may include memory devices using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), antiferromagnetic memory, magneto-resistive random access memory (MRAM) memory including memristor technology, resistive memory including metal oxide base, oxygen vacancy base, and conductive bridge random access memory (CB-RAM), or spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory-based device, a magnetic tunnel junction (MTJ)-based device, a domain wall (DW)- and spin orbit transfer (SOT)-based device, a thyristor-based memory device, or a combination of any of the above, or another memory, or may include these.In low-power implementations, the data store 758 may be on-chip memory or registers associated with the processor 752. However, in some examples, storage 758 may be implemented using a micro hard disk drive (HDD). Further, any number of new technologies for storage 758 may be used in addition to, or in place of, the technologies described, such as, but not limited to, AC resistor memories, phase change memories, holographic memories, or chemical memories.The components may communicate via the interconnect 756. The interconnect 756 may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The interconnect 756 may be a proprietary bus used in, for example, a SoC-based system. Other bus systems may be included, such as, but not limited to, an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI) interface, point-to-point interfaces, and a power bus.The interconnect 756 may couple the processor 752 to transceiver 766 for communications with connected edge devices 762. The transceiver 766 may use any number of frequencies and protocols, such as, but not limited to, transmissions at 2.4 gigahertz (GHz) under the IEEE 802.15.4 standard using the Bluetooth® low energy (BLE) standard as defined by the Bluetooth® Special Interest Group or the ZigBee® standard. Any number of radios configured for a particular wireless communication protocol may be used for connections to the connected edge devices 762. For example, a wireless local area network (WLAN) unit may be used to implement Wi-Fi® communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Additionally, wireless wide area communications may occur, for example, according to a cellular or other wide area protocol, via a wireless wide area network (WWAN) entity.The wireless network transceiver 766 (or multiple transceivers) may communicate using multiple standards or radios for different range communications. For example, the edge computing node 750 may communicate with nearby devices, e.g., within about 10 meters, using a local transceiver based on Bluetooth Low Energy (BLE) or other low-power radio to conserve power. More remote connected edge devices 762, e.g., within about 50 meters, may be reached via ZigBee® or other intermediate power radios. Both communication techniques may take place over a single radio with different power levels or may take place over separate transceivers, for example a local transceiver using BLE and a separate mesh network transceiver using ZigBee®.A wireless network transceiver 766 (e.g., a radio transceiver) may be included to communicate with devices or services in the edge cloud 795 via local or wide area network protocols. The wireless network transceiver 766 may be, but is not limited to, a low-power wide area (LPWA) transceiver that follows the IEEE 802.15.4 or IEEE 802.15.4g standards. The edge computing node 750 may communicate over a wide range by using LoRaWAN™ (long range wide area network) developed by Semtech and the LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers implementing long-range, low-bandwidth communications, such as Sigfox, and other technologies. Further, other communication techniques may be used, such as time slot channel hopping described in the IEEE 802.15.4e specification.Any number of other radio communications and protocols may be used in addition to the systems mentioned for the wireless network transceiver 766 as described herein. The transceiver 766 may include, for example, a cellular transceiver that uses spread spectrum (SPA / SAS) communications to implement high-speed communications. Further, any number of other protocols may be used, such as Wi-Fi® networks for medium speed communications and provision of network communications. The transceiver 766 may include radio devices compatible with any number of third generation partnership project (3GPP) specifications, such as long term evolution (LTE) and 5thgeneration (5G) communication systems discussed in more detail at the end of the present disclosure. A network interface controller (NIC) 768 may be included to provide wired communication to nodes of the edge cloud 795 or to other devices, such as the connected edge devices 762 (e.g., operating in a network). The wired communication may provide an Ethernet connection, or may be based on other types of networks, such as controller area network (CAN), local interconnect network (LIN), deviceNet, controlNet, data highway+, PROFIBUS, or PROFINET, among many others. An additional NIC 768 may be included to enable connection to a second network, for example, a first NIC 768 providing communications with the cloud over Ethernet and a second NIC 768 providing communications with other devices over a different type of network.Given the variety of types of applicable communications from the device to another component or network, applicable communication circuitry used by the device may include or be embodied by one or more of components 764, 766, 768, or 770. Accordingly, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communication circuitry.The edge computing node 750 may include or be coupled to an accelerator circuit 764, which may be embodied by one or more artificial intelligence (AI) accelerators, a neural computing stick, neuromorphic hardware, an FPGA, an array of GPUs, an array of xPU / DPU / IPU / NPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuits configured to perform one or more specialized tasks. These tasks may include Al processing (including machine learning, training, inference, and classification operations), visual data processing, network data processing, object recognition, rule analysis, or the like. These tasks may also include the specific edge computing tasks for service management and service operations discussed elsewhere in this document.The interconnect 756 may couple the processor 752 to a sensor hub or external interface 770 used to connect additional devices or subsystems. The devices may include sensors 772 such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, global navigation system (e.g., GPS) sensors, pressure sensors, barometric pressure sensors, and the like. The hub or interface 770 may further be used to connect the edge computing node 750 to actuators 774 such as circuit breakers, valve actuators, an acoustic sound generator, a visual warning device, and the like.In some optional examples, various input / output (I / O) devices may be present within or connected to edge compute node 750. For example, a display or other output device 784 may be included to display information such as sensor readings or actuator position. An input device 786, such as a touch screen or keypad, may be included to accept input. An output device 784 may include any number of forms of audio or visual display, including simple visual outputs such as binary status indicators (e.g., light emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display screens (e.g., liquid crystal display (LCD) screens), wherein the output of characters, graphics, multimedia objects, and the like is generated or generated from the operation of the edge compute node 750. Display or console hardware may be used in the context of the present system to provide output and receive input of an edge computing system; to manage components or services of an edge computing system; to identify a state of an edge computing component or service; or to perform any other number of management or administration functions or service application instances.Battery 776 may power edge computing node 750, although in examples where edge computing node 750 is mounted at a fixed location, it may have a power supply coupled to a power grid, or the battery may be used as failsafe or temporary capabilities. The battery 776 may be a lithium ion battery or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.A battery monitoring / charging unit 778 may be included in the edge compute node 750 to track the state of charge (SoCh) of the battery 776 if included. The battery monitoring / charging unit 778 may be used to monitor other parameters of the battery 776 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery 776. The battery monitoring unit / charging unit 778 may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix, Arizona, or an IC of the UCD90197 family from Texas Instruments of Dallas, TX. The battery monitoring / charging unit 778 may communicate the information about the battery 776 to the processor 752 via the interconnect 756. The battery monitoring / charging unit 778 may also include an analog-to-digital converter (ADC) that enables the processor 752 to directly monitor the voltage of the battery 776 or the current flow from the battery 776. The battery parameters may be used to determine actions that edge computing node 750 may perform, such as transmission frequency, mesh networking, sensing frequency, and the like.A power supply block 780 or other power supply coupled to a network may be coupled to the battery monitoring / charging device 778 to charge the battery 776. In some examples, the power block 780 may be replaced with a wireless power receiver to wirelessly receive the power, for example, via a loop antenna in the edge computing node 750. A wireless battery charging circuit, such as, but not limited to, an LTC1640 chip from Linear Technologies of Milpitas, California, may be included in the battery monitoring / charging unit 778. The specific charging circuits may be selected based on the size of the battery 776 and thus the required current. Charging may be performed using, among other things, the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power.The storage 758 may include instructions 782 in the form of software, firmware, or hardware instructions to implement the techniques described herein. Although such instructions 782 are shown as code blocks included in memory 754 and storage 758, it should be understood that any of the code blocks may be replaced with hardwired circuits incorporated in, for example, an application specific integrated circuit (ASIC).In an example, the instructions 782 provided via the memory 754, the storage 758, or the processor 752 may be embodied as a non-transitory machine readable medium 760 including code to direct the processor 752 to perform electronic operations in the edge computing node 750. The processor 752 may access the non-transitory machine readable medium 760 via the interconnect 756. For example, the non-transitory machine-readable medium 760 may be implemented by devices described for storage 758, or may include specific storage devices such as optical disks, flash drives, or any number of other hardware devices. The non-transitory machine readable medium 760 may include instructions to direct the processor 752 to perform a specific sequence or flow of actions, such as described with reference to the flowchart or flowcharts and the block diagram or blocks of operations and functionality set forth above. As used herein, the terms "machine-readable medium" and "computer-readable medium" are interchangeable.Also in a specific example, the instructions 782 on the processor 752 (separately or in combination with the instructions 782 of the machine readable medium 760) may configure the execution or operation of trusted execution environment (TEE) 790. In one example, the TEE 790 operates as a protected area accessible by the processor 752 for secure execution of instructions and for secure access to data. Various implementations of the TEE 790 and an accompanying secure area in the processor 752 or the memory 754 may be provided, for example, by using Intel® software guard extensions (SGX), or ARM® TrustZone® hardware security extensions, Intel® management engine (ME), or Intel® converged security management engine (CSME). Other aspects of security hardening, hardware roots of trust, and trusted or protected operations may be implemented in device 750 by TEE 790 and processor 752.In further examples, a machine-readable medium includes any tangible medium that is capable of storing, encoding, or carrying instructions for execution by a machine that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions. A "machine-readable medium" may accordingly include, among other things, solid-state memory and optical and magnetic media. Specific examples of machine readable media include non-volatile memory, including, for example, semiconductor memory (e.g., electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM)), and flash memory; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions embodied by a machine readable medium may be further transmitted or received over a communication network using a transmission medium via a network interface device that uses any of a number of transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)).A machine-readable medium may be provided by a storage device or other device capable of hosting data in a non-transitory format. In an example, information stored on or otherwise provided on a machine-readable medium may represent instructions, such as instructions themselves or a format from which the instructions may be derived. This format from which the instructions may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., split into multiple packets), or the like. The information representing the instructions in the machine readable medium may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions from the information (e.g., processing by the processing circuitry) may include: compiling (e.g., source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically connecting), encoding, decoding, encrypting, decrypting, packaging, unpackaging, or otherwise manipulating the information into the instructions.In an example, deriving the instructions may include composing, compiling, or interpreting the information (e.g., by the processing circuitry) to generate the instructions from an interim or pre-processed format provided by the machine readable medium. The information, if provided in multiple parts, may be combined, unpackaged, and modified to generate the instructions. For example, the information may be in multiple compressed source code packages (or object code or binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted when transited over a network, and may be decrypted, decompressed, assembled (e.g., connected) if necessary, and compiled or interpreted (e.g., into a library, stand-alone executable, etc.) at a local machine, and executed by the local machine.As discussed above, edge computing includes many scenarios in which computing is performed at the edge, such as closer users such as base stations / cell towers and central offices. An edge system may act based on predictions (e.g., estimates) or changes in power availability, workload constraints, scheduling, etc.Edge devices operate in a resource constrained environment and may include only edge servers deployed at different locations, for example, with a single server per location along a route. This server performs critical edge activities by offering services closer to the edge devices with the extremely low latencies required for the edge environment. This type of provisions, often in multifunction housings, are also referred to as road units (RSUs).Edge servers may be equipped with power efficient processors, such as an infrastructure processing unit (IPU) for various specialized processing. IPUs (also referred to as or replaced by smart NIC, EPU, etc.) may extend computing power of a platform (e.g., a CPU), such as by operating as an off-site vehicle.One problem with edge provisioning with remote locations is the need to restart a server to apply service patches, security upgrades, or the like. The downtime of the edge service can result in service issues. If there is more than one server at an edge location, down times for the servers can be handled by a coordinated round robin upgrade cycle. At remote locations, more than one server may not be practical or effective. In some cases, a nearby edge server at another location may be used to continue a service, however latencies may become high or a temporary loss of network connectivity may occur between the edge server and the base station. In cases where a single server is provided, restarting the RSU currently results in downtime for the edge service hosted on the processors.The systems and techniques described herein solve these technical problems with unique architectural constructs that enable service continuity for remote servers through seamless handover between CPU and IPU in the platform. For example, security patches or upgrade patches may be transferred to the RSU at times when network connectivity exists, and the patch may be applied at scheduled times regardless of connectivity without down times. The IPU may take the edge service during restart and remain powered up using independent power to further process the service queries as the CPU restarts to apply a patch. The IPU may return control to the CPU when the CPU is powered up again. To balance potentially reduced SLA capability, as IPU has less computing resources than the CPU, the systems and techniques described herein utilize accelerators or decoupled cores to alleviate the problem. A related problem arises when a user wishes to perform a remote restart, e.g., via the baseboard management controller (BMC), as forced service interruption occurs. In such cases, the BMC may check whether the IPU has adopted the service handling from the CPU before restarting the CPU. In some examples, an update to the CPU may include a change in BIOS, a change in firmware, a microcode patch, or the like. In some examples, a CPU may be identified as malicious or potentially malicious software. In these examples, the CPU may be restarted to a previous state, updated to a safe state, etc. Prior to restarting, the IPU may be used to save a portion of the CPU processing (e.g., without malicious or potentially malicious processing).FIG. 8 illustrates an example edge platform 800, in accordance with some embodiments. The edge platform 800 includes a CPU 802, BMC 804, and IPU 806. The IPU 806 includes monitoring logic that can be used to identify when the CPU 802 or other portion of the edge platform 800 hangs up or when there is a probability that the CPU 802 will be restarted (e.g., a crash, non-responsive operating system, etc.). The monitoring logic may monitor an operating system and coordinate with the BMC 804 to identify when an event is about to trigger migration without downtime.The IPU 806 includes zero touch migration logic that migrates an application (e.g., a critical application running on the CPU 802) to the IPU 806. The migration may be complete (e.g., when copying compute and storage data) or partial (e.g., when migrating only the computation). If the operating system or platform in the partial example supports partial migration, only the computation may be migrated. In this example, data (e.g., memory or hard disk) may be retained and not removed upon restart.The BMC 804 may include management logic to stop a remote restart. For example, if a remote restart is requested to the edge platform 800, BMC 804 may notify the IPU 806 of the restart using the management logic. The BMC 804 may check whether the IPU 806 is configured to perform the migration without downtime and then initiate a restart (e.g., from CPU 802 and optionally other components other than the IPU 806, for example).FIG. 9 illustrates an example architecture 900 for an edge platform, in accordance with some embodiments. Example architecture 900 may be used with edge plate shape 800 of FIG. 8. For example, example architecture 900 includes platform 902, which may be edge platform 800 of FIG. 8. In an example, the example architecture 900 may include a state of a discrete resource such as a GPU or other accelerator.Example architecture 900 illustrates architectural building blocks that may be used to facilitate the transfer of processing from the CPU to the IPU. The CPU may use an accelerator, such as a data streaming accelerator (DSA), to move data from different locations of the platform, such as CPU to IPU, memory to memory, etc. The accelerator may use an interface to facilitate data movement from the CPU to the IPU when the migration occurs. The data relocation may include identifying a source resource, a source data area (e.g., storage area), a destination resource in the IPU, a destination address, or the like.The CPU may provide a register for monitoring (e.g., a control register such as a model specific register (MSR)) for an operating system or application. An application or operating system may use the register as a heartbeat to indicate that they are active. In one example, the operating system may use a register to indicate to the IPU that it is restarted in the next M milliseconds or seconds. This indication may trigger migration on the IPU side. In some examples, the operating system delegates the migration to the IPU. The register may be managed via ring zero functions to prevent attacks and scaling.The IPU may include building blocks that enable the implementation of a transfer from the CPU. The IPU includes, for example, one or more interfaces that can be accessed out-of-order or in-band by the operating system. The one or more interfaces may be authenticated. An example interface may include an interface for registering applications or services without downtime. The registration of an application or service may include an address space identifier (e.g., a process address space ID (PASID)) of the application or service, a priority of the application, or a list of resources that are part of the application or service. For each resource, information may be registered, such as a resource ID where the resource is located (e.g., CPU, memory, device, etc.), a range of resources to be migrated, whether or not to move the resource range, or the like. If the resource area is accessible via a storage coherent switch, migration cannot be avoided (e.g., not required). Another example interface may provide SLA requests for an application. Information about SLA requests may include type or ID of the resource (e.g., CORE, memory, etc.) or a set (e.g., 4 cores, 10 GBS memory, etc.). In some examples, a service level objective (SLO) may be used instead of or with an SLA request.The IPU may include logic responsible for monitoring a status of the platform 902. The supervisory logic may access the register discussed above. In one example, the monitoring logic may access and cooperate with the BMC to identify possible crashes or restarts that are about to occur. The monitoring logic may trigger a data migration when a crash or restart is detected. If the BMC reports restart, the monitoring logic may respond to the BMC once the services have been migrated.The IPU may include migration logic responsible for performing the migration. The migration logic may confirm the start of migration to the BMC (or notify the BMC). The migration logic may start migrating services based on priority. For example, the migration logic may determine which resources to migrate, whether enough local resources are available (e.g., determine capacity), and migrate a resource. If there are not enough resources available, the IPU may indicate that the application cannot be migrated (e.g., if there is not enough memory space to copy status data), or the application may be migrated and scaled down. After completion of the migration, the IPU may notify the BMC of this.The BMC may be used to intercept remote restarts and determine with the IPU whether to migrate a service or application. If migration is possible, the BMC may receive an indication from the IPU. The BMC may restart the platform 902 (e.g., the CPU) and monitor the platform 902.FIG. 10 illustrates an example system 1000 having a virtual bus 1002 for communication with the edge platform, in accordance with some embodiments. Virtual bus 1002 may connect two or more platforms, such as platform 1004, 1006, or 1008. The virtual bus 1002 may be used for trusted multi-IPU monitoring, discovery, failover, or migration. As discussed above, the systems and techniques described herein may be used for migrating a service or application from a CPU to an IPU of a single edge platform. These systems and techniques may be used, in some examples, to migrate a service or application from a first edge platform to a second edge platform, such as using an IPU of the first edge platform to perform the migration and a CPU of the second edge platform to execute the service or application.An IPU of a platform, for example platform 1004, may monitor local critical services of platform 1004. The IPU may access, store, or otherwise include a thermal card that may be created with other IPUs (e.g., nearby peers) that are part of trusted edge platforms. The thermal map may provide an indication of which peers are available or are able to take on certain services. For example, the IPU of platform 1004 may include a thermal map of services that may be performed by platform 1006 or platform 1008. The IPU may use the thermal card upon failure of its CPU or other platform component to determine a list of peers for moving the critical service. The thermal map may be indexed, stored, or searched using a critical service signature (e.g., resources used).Platform 1004 IPU may send a request to another IPU or multicast one or more requests to peer IPUs (e.g., from platform 1006 or 1008). When the request is accepted from a peer IPU, platform 1004 IPU may select one of the accepting peer IPUs to receive the migration, for example, based on a first received acceptance, a lowest workload on accepting peers, a next peer, etc.The IPU of platform 1004 may match a remote IPU (e.g., platform 1006 or 1008) and acceleration schemes for migrating the service. The migration may include using a storage coherence mechanism to access the status (e.g., storage, cache, storage, etc.) of the service to migrate across the peer IPU with similar or similar constructs.In an example, the set of IPUs associated with a group of peer platforms (e.g., 1004, 1006, and 1008) may include an hive of edge servers that cooperate to implement low latency failover migration. In some examples, the peer group may include a universal card for the hive. In other examples, each IPU may generate its own heat map. An IPU may receive telemetry from peer platforms to update the thermal map for fast migration. In some examples, mechanisms for storage mirroring via edge locations with multiple edges may be implemented via the distributed IPUs. Once an error is detected, the various IPUs may cooperate to implement mirroring of the service and restart it at the selected location.The IPUs cooperate in migrating a service to use local acceleration schemes (e.g., DSA) to move the service and the status of the service, for example, using storage protocols (e.g., via a compute express link (CXL)). CXL can be used locally to access the original status of the service (even after the node crashes) that has been moved over the network to the destination IPU and restore the service.FIG. 11 illustrates a flow diagram illustrating a technique 1100 for managing edge resources, in accordance with some embodiments. The technique 1100 may be performed by an edge device, such as using memory to store instructions for execution by circuitry. The edge device may be part of a system or an hive (e.g., a group of edge devices in a particular area, within a particular distance or communication distance of each other, a designated group of devices such as an orchestrator, or the like).The technique 1100 includes an operation 1102 for executing an application using a processor of an edge device. The technique 1100 includes an operation 1104 to interface with the processor of the edge device using circuitry of a device of the edge device. Operation 1104 may include obtaining a list of resources corresponding to the application. In some examples, the processor is a CPU and the device is an IPU. In one example, the device is a second general purpose processor. In other embodiments, the device may be an FPGA, an ASIC, or other programmable hardware.The technique 1100 includes an operation 1106 for communicating over a network interface with a second edge device using the circuitry of the device. The technique 1100 includes an operation 1108 to monitor a processor status using the circuitry of the device. The status may include a scheduled downtime for the processor to perform an update. The status may include an unscheduled downtime of the processor due to a power failure.The technique 1100 includes an operation 1110 to initiate, based on the status and the application with an associated request, migration of execution of the application from the processor using the circuitry of the device. Operation 1110 may include sending an indication to an orchestrator. In some examples, migration to a second processor external to the edge device occurs at a second edge device. The second edge device may be within a communication threshold range. In other examples, migration to a second processor external to the edge device occurs at a cloud server. In still further examples, the migration occurs at the circuitry of the device. The associated request of the application may include a request without application downtime. In an example, the edge device communicates, orchestration, multicasted, or negotiates the migration of at least one processor or storage services from the edge device to the second edge device.The technique 1100 may include an operation to use a battery to power an event recording device and to store telemetry data received from at least one sensor of the edge device at the event recording device. The event recorder may be activated when the edge device loses power. The at least one sensor may include at least one of a thermal sensor, a motion sensor, a stylus in a device connector, an electrical charge detector, a pressure sensor, or the like.In an example, the edge device may include a baseboard management controller (BMC). The technique 1100 may include using the BMC to intercept a remote restart command directed to the processor and send the processor status to the device before restarting the processor.In one example, if a system needs to shut down or a predicted shutdown is determined based on the current battery or thermal conditions, the technique 110 may be used to migrate services that are executed locally on another edge node. For example, an estimation model (such as LSTM) may be used to predict whether the system will be shut down due to current circumstances (e.g., battery charge). If there is a probability (e.g., above a threshold) that the system will be powered down in a near time frame (e.g., in the next seconds or minutes), migration circuitry may be executed to migrate the local services into a peer, such as a peer that is preset or a group of peers. The system may be powered down and the MTU may be triggered after migration.FIG. 12 illustrates an example architecture 1200 for a maintenance telemetry monitor, in accordance with some embodiments. The architecture 1200 may be used with an edge platform located at a difficult-to-access location, a location that is not temperature controlled, a location that is subject to temperature variations, or the like. This can lead to higher failure rates. Edge servers are often subject to more movements with respect to cloud data centers, for example, due to the location of the edge server (e.g., on a balloon, robot, truck, etc.) or due to environmental conditions. Edge servers are more prone to errors and require more maintenance due to factors such as greater temperature variations, movement, etc. If a fault occurs, performing maintenance on an edge server is substantially more difficult than on a conventional server in a data center.This places the focus on efficiency during the maintenance process. Unfortunately, in current system provisions, the server maintenance approach is often unknown after the power supply has been disconnected. The systems and techniques described herein provide insight into the system status at the time of failure, before failure, or after failure. Information may include, for example, how much the server has been moved, which temperature fluctuations occurred during maintenance, in which order different components have been removed or replaced, etc.The systems and techniques described herein address the issue of lack of observability when power is disconnected from edge servers during maintenance. A set of platform sensors may be used to provide telemetry in an independent power domain, for example, supported by one or more batteries. The sensors may provide telemetry regarding thermal, motion, device connectivity (PCI-E devices, etc., plugged in or plugged out), or the like during maintenance work or anticipated downtime. This data can be used for traceability analysis for fault debug. Cross-location and observation over longer periods may be used for analysis-based efficiency in edge server maintenance.A system, such as a platform, chassis, or rack (e.g., depending on the deployment model), may include a battery (e.g., a custom battery) that powers one or more sensors of the system and architecture that are detected during a maintenance task or other downtime. The sensors and monitoring logic may be powered by the battery. In some examples, the sensors may be activated or triggered during maintenance when no power is present. The sensor collection that collects data may include a thermal sensor, such as in various parts of the system, a motion sensor (e.g., an accelerometer) in the system, a stylus in the device connector (e.g., in the Peripheral Component Interconnect Express (PCIE) bus) to identify whether a particular device is disconnected or connected, or the like.The platform, chassis, or rack may include maintenance telemetry logic responsible for collecting telemetry when performing the maintenance operation or when a power failure occurs. Telemetry may be stored on a persistent medium and may be accessible offline or at a later time, such as with appropriate authentication. After performing a telemetry store operation, the telemetry operation may be processed or stored locally by the platform. In local processing, logic that applies machine learning may be used to identify potential issues. In other examples, data may be processed on a larger scale in the cloud.FIG. 13 illustrates an example architecture 1300 for a maintenance telemetry monitor, in accordance with some embodiments. The architecture 1300 may include logic that determines how much power is provided to various components of the system, e.g., when there is a power availability issue. Different configurations may be specified (e.g., by an operator), such as priority of the sensors, sampling rate per sensor, identification of the sensors that need to be collected, sensors that do not require power, etc.The battery and power domain may be hierarchically defined. For example, a rack plane, then a chassis plane, then a platform plane, then a device plane. The provision of battery placement and power flow may occur at different locations within the system.Each of the elements of the system architecture (e.g., platform, chassis, devices, etc.) may include a set of sensors activated during maintenance or without power. Example sensors include thermal sensors in different portions of the platform, motion sensors in a platform 1302 and devices, a stylus in device connectors (e.g., in the PCIE bus) to identify that a particular device (e.g., device 1304) is disconnected or connected, an electrical charge that can be identified at a particular time, an amount of pressure in a device (e.g., to identify how much weight has been applied to the device or platform 1302 itself), or the like. Platform 1302 may include an event recorder.The devices may include sensors that operate for a few seconds, minutes, or hours even after the device is removed from the chassis and the power domain. This may be facilitated by a battery in the device that collects telemetry during a period of time. For example, the collected telemetry may be used to identify what has been passed on a device that is moved from one PCIe slot to another. When a new device is reconnected to platform 1302 (or to the maintenance performance domain), the maintenance telemetry unit (MTU) on platform 1302 may identify the device to map the sensor data to the device itself.Platform 1302 or chassis may include the MTU responsible for collecting telemetry in the maintenance operation or in the event of a power failure. The MTU logic may be placed at one or more locations (e.g., platform 1302, chassis, device 1304, etc.). Each MTU may act hierarchically. For example, an MTU of device 1304 may provide sensor data to the MTU on platform 1302. The MTU on the platform 1302 may provide sensor data to a chassis-level MTU (if used). The optional chassis-level MTU may provide sensor data to the rack-level MTU (if used).Telemetry may be stored on persistent media that may be accessed after maintenance. The persistent storage may be stored on the platform 1302 or on the device 1304. When a power failure or maintenance operation occurs, the logic may be used to activate one or more sensors, such as based on an operator-provided configuration. The logic may provide the configuration of how frequently data is to be updated in each of the sensors. Sensor collection may take place, such as by actively sampling the value at each time sample or by recalling the sensor at a time when a change is to be reported.The system may use one or more interfaces to perform out-of-band access to the maintenance telemetry data after the maintenance period. This may require authentication. In one example, platform 1302 provides a different level of access to the data depending on how the data is accessed. For example, more data may be accessible directly on platform 1302 than via remote access, or different authentication levels may be used. In some examples, the different levels of access may depend on the configuration of the MTU sensors, the priority of the sensors, the sampling rate required for each of the sensors, the sensors to be collected, the sensors without power consumption, or the like.It should be understood that the functional units or capabilities described in this specification may be referred to or identified as components or modules to more particularly emphasize their implementation independence. Such components may be embodied in any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit that includes very large scale integrated (VLSI) circuits or gate arrays, commercially available semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices, such as programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for example, comprise one or more physical or logical blocks of computer instructions, which may, for example, be organized as an object, procedure, or function. Nevertheless, the executable files of an identified component or module need not be physically arranged together, but may include dissimilar instructions stored in different locations that, when logically interconnected (e.g., including via a wire, via a network, using one or more platforms, wirelessly, via a software component, or the like), comprise the component or module and fulfil the stated purpose for the component or module.Indeed, a component or module of executable code may be a single instruction or multiple instructions, and may even be distributed across multiple different code segments, among different programs, and across multiple storage devices or processing systems. In particular, some aspects of the described process (such as code rewriting and code analysis) may take place on a different processing system (e.g., in a computer in a data center) than that in which the code is deployed (e.g., in a computer embedded in a sensor or robot). Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized in any suitable type of data structure. The operational data may be collected as a single dataset or may be distributed across different locations including across different storage devices and may exist, at least in part, only as electronic signals in a system or network. The components or modules may be passive or active, including agents that may be operated to perform desired functions.Further examples of the method, system, and device embodiments described herein include the following non-limiting implementations. Each of the following non-limiting examples may stand on their own or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure.Each of these non-limiting examples may stand on their own or may be combined with one or more of the other examples in various permutations or combinations.Example 1 is an edge device comprising: a processor to execute an application; and a device including: an interface to the processor; a network interface; and circuitry to: monitor a processor status; and based on the status and the application having an associated task, initiate migration of execution of the application from the processor.In Example 2, the subject matter of Example 1 includes, wherein to initiate the migration, the circuitry is to send an indication to an orchestrator.In Example 3, the subject matter of Examples 1 to 2 includes, wherein the migration to a second processor external to the edge device occurs at a second edge device, wherein the second edge device is within a communication threshold range.In Example 4, the subject matter of Examples 1-3 includes, wherein the migration to a second processor external to the edge device occurs at a cloud server.In Example 5, the subject matter of Examples 1-4 includes, wherein the migration to the circuitry of the device occurs.In Example 6, the subject matter of Examples 1-5 includes, wherein the interface to the processor includes a list of resources corresponding to the application.In Example 7, the subject matter of Examples 1-6 includes, wherein the status includes a scheduled downtime for the processor to perform an update.In Example 8, the subject matter of Examples 1-7 includes, wherein the status includes an unscheduled downtime for the processor due to a power failure.In Example 9, the subject matter of Examples 1-8 includes, wherein the processor is a central processing unit (CPU), and the device is one of an infrastructure processing unit (IPU), a computing unit (DPU), or an edge processing unit (EPU).In Example 10, the subject matter of Examples 1-9 includes, wherein the edge device includes an event recording device, the event recording device including: a battery to power the event recording device; and memory to store telemetry data received from at least one sensor of the edge device.In Example 11, the subject matter of Example 10 includes, wherein the event recording device is activated when the edge device loses power.In Example 12, the subject matter of Examples 10-11 includes, wherein the at least one sensor includes at least one of a thermal sensor, a motion sensor, a stylus in a device connector, an electrical charge detector, or a pressure sensor.In Example 13, the subject matter of Examples 1-12 includes, wherein the edge device includes a baseboard management controller (BMC) to: intercept a remote restart command directed to the processor; and send the processor status to the device prior to restarting the processor.In Example 14, the subject matter of Examples 1-13 includes, wherein the associated task of the application includes a zero downtime request of the application.Example 15 is at least one machine readable medium including instructions that, when executed by circuitry of a device of an edge device, cause the circuitry to perform operations of: interfacing with a processor of the edge device executing an application; communicating, via a network interface, with a second edge device; monitoring a processor status; and based on the status and the application with an associated task, initiating migration of execution of the application from the processor.In Example 16, the subject matter of Example 15 includes, wherein the edge device includes an event recorder, the event recorder including: a battery to provide power to the event recorder; and memory to store telemetry data received from at least one sensor of the edge device.In Example 17, the subject matter of Examples 15 to 16 includes, wherein the associated task of the application includes a request for zero downtime of the application.In Example 18, the subject matter of Examples 15-17 includes, wherein the processor is a central processing unit (CPU), and the device is one of an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).Example 19 is a method comprising: executing an application using a processor of an edge device; interfacing, using circuitry of a device of the edge device, with the processor of the edge device; communicating, using the circuitry of the device, over a network interface with a second edge device; monitoring, using the circuitry of the device, a processor status; and based on the status and the application with an associated task, initiating, using the circuitry of the device, a migration of execution of the application from the processor.In Example 20, the subject matter of Example 19 includes, wherein initiating the migration includes executing the application on the circuitry of the device.Example 21 is an edge device, comprising: a first processor; and a second processor including: an interface to register an application executed using the first processor and having no downtime request; circuitry to: monitor a status of the first processor; and in response to the status of the first processor indicating that the request for the application having no downtime is not satisfied, initiate migration of at least one resource from the first processor to a third processor to execute the application according to the request having no downtime.In Example 22, the subject matter of Example 21 includes, wherein to initiate the migration, the circuitry is to send an indication to an orchestrator.In Example 23, the subject matter of Examples 21 to 22 includes, wherein the third processor is external to the edge device at a second edge device, wherein the second edge device is within a communication threshold range.In Example 24, the subject matter of Examples 21-23 includes, wherein the third processor is external to the edge device at a cloud server.In Example 25, the subject matter of Examples 21-24 includes, wherein the third processor is the second processor.In Example 26, the subject matter of Examples 21-25 includes, wherein the interface includes a list of resources corresponding to the application including at least one resource.In Example 27, the subject matter of Examples 21-26 includes, wherein the status includes a scheduled downtime for the first processor to perform an update.In Example 28, the subject matter of Examples 21-27 includes, wherein the status includes an unscheduled downtime for the first processor due to a power failure.In Example 29, the subject matter of Examples 21-28 includes, wherein the first processor is a central processing unit (CPU) and the second processor is an infrastructure processing unit (IPU).In Example 30, the subject matter of Examples 21-29 includes, wherein the edge device includes an event recorder, the event recorder including: a battery to power the event recorder; and memory to store telemetry data received from at least one sensor of the edge device.In Example 31, the subject matter of Example 30 includes, wherein the event recording device is initiated when the edge device loses power.In Example 32, the subject matter of Examples 30 to 31 includes, wherein the at least one sensor includes at least one of a thermal sensor, a motion sensor, a stylus in a device connector, an electrical charge detector, or a pressure sensor.In Example 33, the subject matter of Examples 21-32 includes, wherein the edge device includes a baseboard management controller (BMC) to: intercept a remote restart command directed to the first processor; and send the status indicating that the application's zero downtime request is not satisfied to the second processor before the first processor restarts.Example 34 is at least one machine readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1 to 33.Example 35 is an apparatus comprising means for implementing any of Examples 1 to 33.Example 36 is a system for implementing any of Examples 1-33.Example 37 is a method of implementing any of Examples 1-33.Another example implementation is an edge computing system including respective edge processing devices and nodes for invoking or performing the operations of Examples 1-33, or other subject matter described herein.Another example implementation is a client endpoint node operable to invoke or perform the operations of examples 1-33, or other subject matter described herein.Another example implementation is an aggregation node, network hub nodes, gateway nodes, or core computing nodes in or coupled to an edge computing system and operable to invoke or perform the operations of examples 1-33, or other subject matter described herein.Another example implementation is an access point, a base station, a path edge unit, a road edge unit, or an on-site unit, within or coupled to an edge computing system operable to invoke or perform the operations of Examples 1-33, or other subject matter described herein.Another example implementation is an edge provisioning node, a service orchestration node, an application orchestration node, or a multi-tenant management node, within or coupled to an edge computing system operable to invoke or perform the operations of examples 1-33, or other subject matter described herein.Another example implementation is an edge node that operates an edge provisioning service, application, or service orchestration service, virtual machine deployment, container deployment, function deployment, and compute management in or coupled to an edge computing system, and is operable to invoke or perform the operations of examples 1-33, or other subject matter described herein.Another example implementation is an edge computing system that includes aspects of network functions, acceleration functions, acceleration hardware, storage hardware, or computation hardware resources and is operable to invoke or perform the use cases discussed herein using Examples 1-33, or other subject matter described herein.Another example implementation is an edge computing system configured to support client mobility, vehicle-to-vehicle (V2V), vehicle-to-environment (V2X), or vehicle-to-infrastructure (V2I) scenarios, and optionally operating in accordance with ETSI MEC specifications, operable to invoke or perform the use cases discussed herein using Examples 1-33, or other subject matter described herein.Another example implementation is an edge computing system configured for mobile wireless communications including configurations according to 3GPP 4G / LTE or 5G network capabilities operable to invoke or perform the use cases discussed herein using examples 1 to 33, or other subject matter described herein.Another example implementation is an edge compute node operable in a layer of an edge computing network or system as an aggregation node, network hub node, gateway node, or core computing node, operating in a near edge, local edge, enterprise edge, in-situ edge, near edge, mid, edge, or far edge network layer, or operable in a set of nodes having common latency, timing, or far characteristics, operable to invoke or perform the use cases discussed herein using Examples 1 to 33, or other subject matter described herein.Another example implementation is network hardware, acceleration hardware, storage hardware, or computing hardware with capabilities implemented thereon, operable in an edge computing system to invoke or perform the use cases discussed herein using examples 1-33, or other subject matter described herein.Another example implementation is an edge computing system configured to perform use cases provided by one or more of: compute offload, data caching, video processing, network function virtualization, radio access network management, augmented reality, virtual reality, industrial automation, retail services, manufacturing operations, smart buildings, power management, autonomous driving, vehicle support, vehicle communication, internet of things operations, object detection, speech recognition, health care applications, gaming applications, or accelerated content processing using examples 1 to 33, or other subject matter described herein.Another example implementation is an apparatus of an edge computing system, comprising: one or more processors; and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to invoke or perform the use cases discussed herein using Examples 1 to 33, or another subject matter described herein.Another example implementation is one or more computer readable storage media comprising instructions to cause an electronic device of an edge computer system, when executed by one or more processors of the electronic device, to invoke or perform the use cases discussed herein using Examples 1-33, or another subject matter described herein.Another example implementation is an apparatus of an edge computing system that includes means, logic, modules, or circuitry for invoking or performing the use cases discussed herein using examples 1 to 33, or another subject matter described herein.Although these implementations have been described with reference to specific exemplary aspects, it should be understood that various modifications and changes may be made to these aspects without departing from the broader scope of the present disclosure. Many of the arrangements and processes described herein may be used in combination or in parallel implementations to provide greater bandwidth / throughput and support edge service balancing that may be provided to the edge systems to be served. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings, which form a part hereof, show by way of illustration, but not limitation, specific aspects in which the subject invention may be practiced. The illustrated aspects are described in sufficient detail to enable one skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived therefrom such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description is therefore not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.Such aspects of the subject matter of the invention may be referred to herein individually and / or collectively for convenience only, and without intending to freely limit the scope of this application to any single aspect or spirit, if indeed more than one is disclosed. Thus, although specific aspects have been illustrated and described herein, it should be understood that any arrangement calculated to achieve the same purpose may replace the specific aspects shown. This disclosure is to be understood to cover all adaptations or variations of the various aspects, collectively and specifically. Combinations of the above aspects and other aspects not specifically described herein will become apparent to those skilled in the art upon review of the above description.The method examples described herein may be at least partially machine- or computer-implemented. Some examples may include a computer readable medium or a machine readable medium encoded with instructions operable to configure an electronic device to perform the methods described in the above examples. An implementation of such methods may include code, such as microcode, assembly language code, higher level code, or the like. Such code may include computer readable instructions for performing various methods. The codes may form parts of computer program products. Further, in one example, the code may be tangibly stored on one or more transitory, non-transitory, or non-transitory tangible computer readable media, such as during execution or at other times. Examples of these subject computer readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.

Claims

An edge device comprising: a processor for executing an application; and an apparatus comprising: an interface to the processor; a network interface; and circuitry for: monitoring a processor status; and based on the status and the application with an associated request; initiating migration of execution of the application from the processor.The edge device of claim 1, wherein the circuitry is to send an indication to an orchestrator to initiate the migration.The edge device of claim 1, wherein the migration to a second processor external to the edge device occurs at a second edge device, the second edge device being within a communication threshold range.The edge device of claim 1, wherein the migration to a second processor external to the edge device occurs at a cloud server.The edge device of claim 1, wherein the migration to the circuitry of the device occurs.The edge device of claim 1, wherein the interface to the processor includes a list of resources corresponding to the application.The edge device of claim 1, wherein the status includes a scheduled downtime for the processor to perform an update.The edge device of claim 1, wherein the status includes an unscheduled downtime for the processor due to a power failure.The edge device of claim 1, wherein the processor is a central processing unit (CPU) and the device is an infrastructure processing unit (IPU).The edge device of claim 1, wherein the edge device includes an event recorder, the event recorder including: a battery for powering the event recorder; and memory for storing telemetry data received from at least one sensor of the edge device.The edge device of claim 10, wherein the event recording device is activated when the edge device loses power.The edge device of claim 10, wherein the at least one sensor includes at least one of a thermal sensor, a motion sensor, a stylus in a device plug, an electrical charge detector, or a pressure sensor.The edge device of claim 1, wherein the edge device comprises a baseboard management controller (BMC) to: intercept a remote restart command directed to the processor; and send the processor status to the device before restarting the processor.The edge device of any of claims 1 to 13, wherein the associated request of the application includes a zero failure request of the application.At least one machine readable medium, including instructions that, when executed by circuitry of a device of an edge device, cause the circuitry to perform operations to: interface with a processor of the edge device executing an application; communicate, via a network interface, with a second edge device; monitor a processor status; and based on the status and the application with an associated request; initiate migration of execution of the application from the processor.The at least one machine readable medium of claim 15, wherein the edge device includes an event recorder, the event recorder including: a battery for powering the event recorder; and memory for storing telemetry data received from at least one sensor of the edge device.The at least one machine readable medium of claim 15, wherein the associated request of the application includes a zero failure request of the application.At least one machine readable medium according to any of claims 15 to 17, wherein the processor is a central processing unit (CPU) and the apparatus is an infrastructure processing unit (IPU).An apparatus comprising: means for executing an application on a processor of an edge device; means for interfacing between circuitry of a device of the edge device and the processor of the edge device; means for communicating from circuitry of the device over a network interface with a second edge device; means for monitoring processor status; and based on the status and the application having an associated request, means for initiating migration of execution of the application from the processor.The apparatus of claim 19, wherein the means for initiating migration includes means for executing the application.

Images