Methods, system, articles of manufacture, and apparatus to manage telemetry data in an edge environment

[Priority application]

This application claims the benefit of priority to U.S. Provisional Application No. 62/907,597, filed September 28, 2019, and U.S. Provisional Application No. 62/939,303, filed November 22, 2019, the entire contents of all of which are incorporated by reference.

[Technical field]

TECHNICAL FIELD Embodiments described herein relate generally to data processing, network communication and communication system implementations, and more particularly to edge computing and techniques for adapting data flows between edge computing nodes and connected devices in Internet of Things (IoT) device networks to address dynamic network conditions.

At a general level, edge computing refers to the transition of computing and storage resources closer to endpoint devices (e.g., consumer computing devices, user equipment, etc.) to optimize total cost of ownership, reduce application latency, improve service capabilities, and improve compliance with security or data privacy requirements. Edge computing may, in some scenarios, provide cloud-like distributed services that provide orchestration and management for applications across many types of storage and computing resources. As a result, some implementations of edge computing are referred to as "edge clouds" or "fog." This is because powerful computing resources that were previously only available in large remote data centers are now closer to the endpoints and available for consumer use at the "edge" of the network.

Use cases for edge computing in mobile network settings are being developed to integrate with the multi-access edge computing (MEC) approach, also known as "mobile edge computing". The MEC approach is designed to enable application developers and content providers to access computing power and information technology (IT) service environments in dynamic mobile network settings at the edge of the network. Limited standards are being developed by the industry specification group (ISG) of the European Telecommunications Standards Institute (ETSI) in an attempt to define common interfaces for the operation of MEC systems, platforms, hosts, services and applications.

Edge computing, MEC and related technologies attempt to provide lower latency, improved responsiveness and available computing power than is offered by traditional cloud network services and wide area network connections. However, the integration of mobility and dynamically initiated services into some mobile and device processing use cases brings limitations and challenges in orchestration, collaboration and resource management, especially in complex mobility settings involving many participants (devices, hosts, tenants, service providers, operators).

Similarly, Internet of Things (IoT) networks and devices are designed to provide distributed computing from various endpoints. IoT devices are physical or virtualized objects that can communicate over a network and may include sensors, actuators, and other input/output components that can be used to collect data or perform actions in real-world environments. For example, IoT devices may include low-power endpoint devices embedded or attached to everyday objects such as buildings, vehicles, packages, etc., to provide an additional level of artificial perception of these objects. As IoT devices have become more common in recent years, applications using these devices have proliferated.

The deployment of various edge, fog, MEC and IoT networks, devices and services introduces many advanced use cases and scenarios that occur at and towards the edge of the network. Enterprise and cloud edge deployments may include wired or wireless connections. However, these advanced use cases also bring technical challenges related to security, processing and network resources, serviceability and efficiency, among many other issues. One such challenge is related to security and reliability, and the ability to establish trusted computing relationships and domains. As the concept of trusted computing is increasingly implemented in computing systems and deployments, use cases for authentication, trust claims and trust attestation are expanded to improve operations with trusted entities (or conversely, to exclude or protect against untrusted entities).

In the drawings, which are not necessarily drawn to scale, like numbers in different figures may describe similar components. Like numbers with different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

<figref num="1">1 illustrates an overview of an edge cloud configuration for edge computing, according to an example.</figref><figref num="2">1 illustrates the deployment and orchestration of a virtual edge configuration across an edge computing system operating among multiple edge nodes and multiple tenants, according to an example.</figref><figref num="3">1 illustrates a vehicular computing and communications use case including mobile access to applications in an edge computing system, according to an example.</figref><figref num="4">1 illustrates an overview of layers of distributed computation deployed among an edge computing system, according to an example.</figref><figref num="5A">1 illustrates an overview of exemplary components deployed on a compute node system, according to one example.</figref><figref num="5B">1 illustrates a further overview of exemplary components within a computing device, according to one example.</figref><figref num="6">1 illustrates an overview of an architecture for adaptive data flow transformation in an edge computing environment, according to an example.</figref><figref num="7">FIG. 1 is a block diagram of an environment and system for adaptive data flow transformation in an edge computing environment, according to an example.</figref><figref num="8">1 illustrates a flowchart of a method for adaptive data flow transformation in an edge computing environment, according to an example.</figref>

Edge Computing service level agreements, performance, and user experience may be correlated with the capacity of the edge computing infrastructure. The edge computing infrastructure may be utilized to provide data plane capacity directly from devices or users (or Customer Premise Equipment (CPE)) to edge services where data is to be processed. Given the dynamic nature of edge computing environments with variables such as dynamic load, data movement, user movement, etc., providing adequate capacity can be a complex problem to address.

The systems and techniques discussed herein measure network hops (e.g., node hops, network hops, etc.) (e.g., Base Station, The present invention solves this problem by facilitating partial exchange of available information on data plane capacity and delay at BSs (e.g., BS1, BS2, etc.) to enable cooperation between the edge infrastructure and edge-attached devices (e.g., user equipment (UE)). A base station may be a kind of street cabinet that serves devices within its communication range. The devices may be equipped with transformation functions that may enable the devices to adapt the data flow in various ways. The transformation functions may include operations that the edge-attached device may use to modify the data flow of a particular data type. The edge-attached device may maintain a table of available transformation functions that may be invoked when metrics indicate a negative impact on the data flow. For example, the device may pre-fetch more data, buffer more data, compress more (e.g., at a higher computational cost), (4) reduce or improve the quality of the data (e.g., reduce the resolution of an image, reduce the entropy of the data, etc.).

Traditional capacity management solutions may be based on static solutions that initially map data sources based on intelligence residing in a central location (e.g., a service that provides source mapping based on intelligence running on the cloud) and the mapping rarely changes unless the connection is reset, or may not utilize predictive methods that use UE requirements, mobility and edge infrastructure to perform data flow adaptation.

In contrast, the systems and techniques discussed herein provide coordination between the UE and the edge infrastructure to adapt the data flow (e.g., change the bit rate, etc.) to match the type of content (e.g., casual free content, paid content, etc.) along with the UE device capabilities, current network connection characteristics, current computational demands, user subscription or access mode, and Service Level Agreement (SLA) and bandwidth requirements. A Service Level Objective (SLO) as used herein is an application goal (e.g., bit rate per second, frames per second, etc.), and the SLO may define the resources (e.g., how many, etc.) required to meet a particular service level indicator (SLI). For example, to achieve a particular bit rate, two processor cores and 10 gigabits of memory per second may be required, etc.

For example, in the context of video streaming, the content stream may be high resolution by default and may be temporarily reduced to a lower resolution. In other examples, very low jitter may be prioritized over audio or video resolution quality. For example, a business conference taking place over a secure virtual channel may allow reduced audio fidelity to reduce jitter, since timely and reliable delivery of audio packets may be more important to the user experience than high fidelity.

A mechanism is provided in the UE that can evaluate acceptable data flow conversion for the service application and evaluate dynamic backhaul capacity and dynamic peer-to-peer network capacity. The evaluation may determine the rate at which content is stored and retrieved locally (e.g., local edge storage versus backhaul, etc.). The UE mechanism may consider the distance to the cloud backend in addition to the bandwidth to the cloud, since distance (e.g., number of hops) may affect the delay. The UE mechanism may also evaluate locations where the UE may be connected and what operating conditions may exist when the UE is connected from that location. For example, the UE may currently be connected to base station (BS) 1, which has a bandwidth of 10 Megabits per Second (MBS) to a street cabinet, e.g., where the service is located, but within 10 minutes it may be connected to BS 2, which has an expected bandwidth of 20MBS for the service.

The systems and techniques discussed herein provide various advantages over traditional capacity management solutions, including: (i) content origin servers do not need to generate all variants of content (e.g., videos of different resolutions, etc.); (ii) content adaptation can be performed more effectively at the network edge, so that users with different capabilities and network conditions receive content appropriate to those capabilities; (iii) cooperation between edge servers improves cache hit rates and balances the processing load in the network; and (iv) user feedback and SLAs and corresponding SLOs are taken into account in choosing at what bitrate and where transcoding is performed, and pre-ordering can be performed for X seconds, such that at least f(X) amount of content can be pre-cached and pre-processed to hide delays. This allows pre-caching of different amounts of popular content according to the level of popularity (e.g., as estimated by applying a Zipf mathematical statistical model), and where possible, scheduled delivery may be used to further optimize the UE cache.

Example Edge Computing Architecture Figure 1 is a block diagram 100 illustrating an overview of a configuration for edge computing, including a layer of processing referred to in many of the present examples as an "edge cloud." This network topology, which may include many traditional networking layers (including some not shown here), may be extended through the use of the authentication techniques and network configurations discussed herein.

As shown, the edge cloud 110 is co-located at an edge location, such as a base station 140, a local processing hub 150, or a central office 120, and thus may include multiple entities, devices, and equipment instances. The edge cloud 110 is located 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 city and building devices 166, sensors and IoT devices 167, etc.) than the cloud data center 130. The computation, memory, and storage resources provided at the edge in the edge cloud 110 are critical to provide ultra-low latency response times for the services and functions used by the endpoint data sources 160 and to reduce network backhaul traffic from the edge cloud 110 to the cloud data center 130, thus improving energy consumption and overall network utilization, among other benefits.

Computation, memory, and storage are scarce resources that generally decrease depending on the edge location (e.g., there are fewer processing resources available at a consumer endpoint device than at a base station or central office). However, the closer the edge location is to the endpoint (e.g., UE), the more space and power are constrained. Thus, as a general design principle, edge computing attempts to minimize the amount of resources required for network services through distributing more resources closer in location, both geographically and in network access time.

Below, aspects of the edge cloud architecture are described that cover several potential deployments and address constraints that some network operators or service providers may have in their infrastructure, including configuration changes based on edge location (e.g., as base station level edges may have more constrained performance), configuration based on the type of resources, such as compute, memory, storage, fabric, acceleration, etc., available to an edge location, tier of locations or group of locations, services, security, and management and orchestration capabilities, and related objectives to achieve end service availability and performance.

Edge computing is a deployment paradigm in which computing is performed at or closer to the "edge" of a network, typically through the use of computational platforms implemented in base stations, gateways, network routers, or other devices closer to the end-point devices that generate and consume data. For example, an edge gateway server may comprise a pool of memory and storage resources to perform computations in real time for low-latency use cases (e.g., autonomous driving or video surveillance) for connected client devices. Alternatively, as one example, a base station may be extended with computational and acceleration resources to directly handle service workloads for connected user devices without further communicating data over a backhaul network. Alternatively, as another example, the network management hardware of a central office may be replaced with computational hardware that performs virtualized network functions to provide computational resources for the execution of services and consumer functions for connected devices. These and other scenarios may include the use of authentication, as provided in the discussion below.

In contrast to the network architecture of Figure 1, traditional endpoint (e.g., UE, vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), etc.) applications rely on local device or remote cloud data storage and processing to exchange and collaborate on information. Cloud data placement enables long-term data collection and storage, but is not optimal for highly time-varying data, such as collisions, traffic light changes, etc., and can fail in its attempt to address latency challenges.

Depending on the real-time requirements in the communication context, a hierarchy of data processing and storage nodes may be defined in an edge computing deployment. For example, such a deployment may include local ultra-low latency processing, regional storage and processing, as well as remote cloud data center based storage and processing. Key Performance Indicators (KPIs) may be used to identify where the sensor data is best transferred and where it is processed or stored. This typically depends on the ISO layer dependencies of the data. For example, lower layer (PHY, MAC, routing, etc.) data typically changes quickly and is better processed locally to meet latency requirements. Higher layer data, such as application layer data, is typically less urgent and may be stored and processed in remote cloud data centers.

FIG. 2 illustrates the deployment and orchestration of a virtual edge configuration across an edge computing system operating among multiple edge nodes and multiple tenants. Specifically, FIG. 2 illustrates the coordination of a first edge node 222 and a second edge node 224 in an edge computing system 200 to fulfill requests and responses for various client endpoints 210 from various virtual edge instances. The virtual edge instances provide computing power and processing in the edge cloud with access to clouds/data centers 240 for higher latency requirements for websites, applications, database servers, etc. Thus, the edge cloud enables the coordination of processing among multiple edge nodes for multiple tenants or entities.

In the example of FIG. 2, these virtual edge instances include a first virtual edge 232 provided to a first tenant (tenant 1) that provides a first combination of edge storage, computing, and services, and a second virtual edge 234 that provides a second combination of edge storage, computing, and services to a second tenant (tenant 2). The virtual edge instances 232, 234 may be distributed among edge nodes 222, 224, including scenarios where requests and responses are fulfilled from the same or different edge nodes. The configuration of each edge node 222, 224 to operate in a distributed but coordinated manner occurs based on an edge provisioning function 250. The ability of the edge nodes 222, 224 to provide coordination for applications and services among multiple tenants occurs based on an orchestration function 260. In one embodiment, multiple tenants may share the virtual edge 232.

It should be understood that some of the devices in 210 are multi-tenant devices where tenant 1 may function within tenant 1's "slice" while tenant 2 may function within tenant 2's slice. A trusted multi-tenant device is one in which the key-slice combination is a "root of trust." The RoT may further include a tenant-specific cryptographic key, which may be considered a "RoT" or tenant-specific RoT. The RoT may be computed and dynamically configured using a security architecture such as the Device Identity Composition Engine (DICE) architecture, where the DICE hardware building blocks are used to build layered trusted computing infrastructure contexts (such as Field Programmable Gate Arrays) for layering of device capabilities. The RoT may also be used in trusted computing contexts to support operations, etc. for each tenant. The use of this RoT and security architecture may be extended by authentication operations as discussed further herein.

Edge computing nodes may partition resources (memory, CPU, GPU, interrupt controller, I/O controller, memory controller, bus controller, etc.), each partition may include RoT capabilities, and fan-out and layering according to the DICE model may be further applied to edge nodes. Cloud computing nodes consisting of containers, function as a service (FaaS) engines, servlets, servers, or other computing abstractions may be partitioned according to the DICE layering and fan-out structure to support each RoT context. Thus, each RoT across entities 210, 222, and 240 may coordinate the establishment of a distributed trusted computing base (DTCB) such that a tenant-specific virtual trusted secure channel can be established linking all elements end-to-end.

Additionally, edge computing systems may be extended to provide orchestration of multiple applications through the use of containers (housed, deployable units of software that provide code and necessary dependencies) in a multi-owner, multi-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 in FIG. 2. The orchestrator may use the DICE layering and fan-out structure to create tenant-specific trust context roots. Thus, the orchestration functionality provided by the orchestrator may act as a tenant-specific orchestration provider.

Thus, an edge computing system may be configured to fulfill requests and responses for various client endpoints from multiple virtual edge instances (and clouds or remote data centers (not shown)). The use of these virtual edge instances supports multiple tenants and multiple applications (e.g., AR/VR, enterprise applications, content delivery, gaming, compute offload) simultaneously. Furthermore, within a virtual edge instance, there may be multiple types of applications (e.g., regular applications, latency sensitive applications, latency critical applications, user plane applications, networking applications, etc.). A virtual edge instance may also span between systems of multiple owners in different geographic locations.

In a further example, an edge computing system may deploy containers in the edge computing system. As a simple example, a container manager is adapted to launch instances of containerized pods, functions, and functions-as-services through execution via compute nodes, or to separately run containerized virtualized network functions through execution via compute nodes. This arrangement may be adapted for use by multiple tenants in a system arrangement, where instances of containerized pods, functions, and functions-as-services are launched in virtual machines specific to each tenant (separate from running virtualized network functions).

Within the edge cloud, a first edge node 222 (e.g., operated by a first owner) and a second edge node 224 (e.g., operated by a second owner) may act or respond to a container orchestrator to coordinate the execution of various applications within the virtual edge instances provided to the respective tenants. For example, the edge nodes 222, 224 may be coordinated based on an edge provisioning function 250, while the execution of the various applications is coordinated with an orchestration function 260.

Various system deployments may provide architectures that treat virtual machines, containers, and functions equally in terms of application composition (and the resulting application is a combination of these three components). Each component may include the use of one or more accelerator (e.g., FPGA, ASIC) components as local backends. In this way, an application can be partitioned across multiple edge owners coordinated by an orchestrator.

It should be appreciated that the edge computing systems and arrangements discussed herein may be applicable to a variety of solutions, services, and/or use cases. As an example, FIG. 3 illustrates a simple vehicular computing and communication use case involving mobile access to applications in an edge computing system 300 implementing the edge cloud 110. In this use case, each client computing node 310 may be embodied as an in-vehicle computing system (e.g., an in-vehicle navigation and/or information gathering system) located in a corresponding vehicle that communicates with an edge gateway node 320 while traveling along a road. For example, the edge gateway node 320 may be located in a roadside cabinet, which may be located along the road, at a road intersection, or at another location near the road. As each vehicle progresses along the road, the connection between its client computing node 310 and a particular edge gateway node 320 may ripple out to maintain a consistent connection and context for the client computing node 310. Each of the edge gateway nodes 320 includes some processing and storage capabilities, and thus some processing and/or storage of data for the client computing nodes 310 may be performed in one or more of the edge gateway nodes 320.

Each of the edge gateway nodes 320 may communicate with one or more edge resource nodes 340, which are illustratively embodied as a computing server, appliance, or component located at or within a communications base station 342 (e.g., a base station of a cellular network). As described above, each edge resource node 340 includes some processing and storage capabilities, and thus some processing and/or storage of data for the client computing nodes 310 may be performed at the edge resource node 340. For example, processing of less urgent or important data may be performed by the edge resource node 340, while processing of more urgent or important data may be performed by the edge gateway device or the client node itself (e.g., depending on the capabilities of each component). Furthermore, various wired or wireless communication links (e.g., fiber optic wired backhaul, 5G wireless links) may exist between the edge nodes 320, the edge resource nodes 340, the core data center 350, and the network cloud 360.

The edge resource nodes 340 also communicate with a core data center 350, which may include computing servers, appliances, and/or other components located in a central location (e.g., a central office of a cellular communication network). The core data center 350 may provide a gateway to a global network cloud 360 (e.g., the Internet) for operation of the edge cloud 110 formed by the edge resource nodes 340 and the edge gateway nodes 320. Additionally, in some examples, the core data center 350 may include a certain amount of processing and storage capabilities, such that some processing and/or storage of data for client computing devices (e.g., processing of low urgency or importance or processing of high complexity) may be performed in the core data center 350. The edge gateway nodes 320 or edge resource nodes 340 may provide for the use of stateful applications 332 and geo-distributed data storage 334 (e.g., databases, data stores, etc.).

In a further example, FIG. 3 may utilize various types of mobile edge nodes, such as edge nodes hosted in vehicles (e.g., cars, trucks, trams, trains, etc.) or other mobile units as the edge nodes move to other geographic locations along the platform that hosts them. In vehicle-to-vehicle communications, individual vehicles may even act as network edge nodes for other vehicles (e.g., to perform caching, reporting, data aggregation, etc.). Thus, it will be appreciated that application components provided at various edge nodes may be distributed in a variety of configurations, including coordination between some functions or operations at individual endpoint devices or edge gateway nodes 320, some other functions or operations at edge resource nodes 340, and other functions or operations at core data center 350 or global network cloud 360.

In a further configuration, an 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 (e.g., "computer code" herein) that represents 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, for example, a service use case or an edge processing event, initiates the execution of the function code on the FaaS platform.

In the FaaS example, containers are used to provide an environment in which function code executes. A container may be any isolated execution entity, such as a process, a Docker or Kubernetes container, a virtual machine, etc. Within an edge computing system, various data center, edge, and endpoint (including mobile) devices are used to "spin up" (e.g., activate and/or assign function actions) functions that are scaled on demand. Function code executes on physical infrastructure (e.g., edge computing nodes) devices and the underlying virtualized containers. Finally, containers are "spin down" (e.g., deactivated and/or deallocated) on the infrastructure in response to completing execution.

Further aspects of FaaS may include support for each function that supports edge computing as a service, enabling the deployment of edge functions in the form of a service. Further features of FaaS may include a fine-grained billing component that allows a customer (e.g., a computer code developer) to pay only when their code is executed, common data storage for storing data reused by one or more functions, orchestration and management among individual functions, function execution management, parallel processing and integration, management of container and function memory space, coordination of acceleration resources available to functions, and distribution of functions among containers (including "warm" containers that are already deployed or running versus "cold" containers that need to be deployed or configured).

Exemplary Computing Devices At a more general level, an edge computing system may be described as encompassing any number of deployments operating within an edge cloud 110 that provide collaboration from clients and distributed computing devices. Figure 4 provides a further abstracted overview of the layers of distributed computation deployed among an edge computing environment for illustrative purposes.

4 generally illustrates an edge computing system 400 for providing edge services and applications to multi-stakeholder entities, such as those distributed across layers of a network, among one or more client compute nodes 402, one or more edge gateway nodes 412, one or more edge aggregation nodes 422, one or more core data centers 432, and a global network cloud 442. Implementations of edge computing systems may be implemented by telecommunications service providers ("telcos" or "TSPs"), Internet of Things service providers, cloud service providers, CSP), an enterprise entity, or any other number of entities. Various types of wired or wireless connections may be configured to establish connections between the nodes 402, 412, 422, 432, including the interconnections between such nodes (e.g., connections between edge gateway nodes 412 and connections between edge aggregation nodes 422).

Each node or device of the edge computing system is located at a particular layer corresponding to layers 410, 420, 430, 440, 450. For example, the client computing nodes 402 are located at the endpoint layer 410, while each of the edge gateway nodes 412 is located at the edge device layer 420 (local level) of the edge computing system. Furthermore, each of the edge aggregation nodes 422 (and/or fog devices 424 when deployed in or operating between fog networking configurations 426) is located at the network access layer 430 (middle level). In general, fog computing (or "fogging") refers to the extension of cloud computing to the edge of an enterprise's network, typically in a cooperative distributed network or a multi-node network. Some forms of fog computing provide the deployment of computing, storage, and networking services between end devices and cloud computing data centers instead of cloud computing locations. Such forms of fog computing provide operations consistent with edge computing as discussed herein, and many of the aspects of edge computing discussed herein are applicable to fog networks, fogging, and fog configurations. Furthermore, aspects of edge computing systems discussed herein may be configured as fog, or fog aspects may be integrated into an edge computing architecture.

Core data centers 432 are located in the core network layer 440 (e.g., at a regional or geographically central level), while global network clouds 442 are located in the cloud data center layer 450 (e.g., at a national or global layer). The use of "core" is provided as a term for a central network location deeper within the network that is accessible by multiple edge nodes or components, but "core" does not necessarily indicate the "center" or deepest location of the network. Thus, core data centers 432 may be located in, at, or near edge cloud 110.

Although an exemplary number of client computing nodes 402, edge gateway nodes 412, edge aggregation nodes 422, core data centers 432, and global network clouds 442 are shown in FIG. 4, it should be appreciated that an edge computing system may include more or fewer devices or systems at each layer. Additionally, as shown in FIG. 4, the number of components at each layer 410, 420, 430, 440, 450 generally increases at the respective lower levels (i.e., as one moves closer to the endpoints). Thus, one edge gateway node 412 may serve multiple client computing nodes 402, and one edge aggregation node 422 may serve multiple edge gateway nodes 412.

In accordance with the examples provided herein, each client computing node 402 may be embodied as any type of endpoint component, device, appliance, or "thing" capable of communicating as a producer or consumer of data. Additionally, the labels "node" or "device" used in edge computing system 400 do not necessarily imply that such node or device operates in a client or slave role, but rather, any of the nodes or devices in edge computing system 400 may denote individual entities, nodes, or subsystems that include individual or connected hardware or software configurations for facilitating or using edge cloud 110.

Thus, the edge cloud 110 is formed from the network components and functional features operating by or within the edge gateway nodes 412 and edge aggregation nodes 422 of layers 420, 430, respectively. The edge cloud 110 is formed from the radio access network (RAN), shown in FIG. 4 as client and compute nodes 402. The edge cloud 110 may be embodied as any type of network that provides edge computing and/or storage resources located near RAN (Global Access Point)-enabled endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.). In other words, the edge cloud 110 may be thought of as an "edge" that connects endpoint devices with traditional mobile network access points that serve as entry points into service provider core networks, including carrier networks (e.g., Global System for Mobile Communications (GSM) networks, Long-Term Evolution (LTE) networks, 5G networks, etc.), while also providing storage and/or computational capabilities. Other types and forms of network access (e.g., Wi-Fi, long-range wireless networks) may also be utilized in place of or in combination with such 3GPP carrier networks.

In some examples, the edge cloud 110 may form part of or provide an ingress point to or across the fog networking configuration 426 (e.g., a network of fog devices 424 (not shown in detail)), which may be embodied as a system-level horizontal and distributed architecture that distributes resources and services to perform specific functions. For example, a federated and distributed network of fog devices 424 may perform computing, storage, control, or networking aspects of an IoT system deployment. Other networking, aggregation, and distribution functions may exist in the edge cloud 110 between the cloud data center layer 450 and client endpoints (e.g., client compute nodes 402). Some of these are discussed in the following paragraphs with respect to network function or service virtualization, including the use of virtual edges and virtual services organized for multiple stakeholders.

The edge gateway nodes 412 and edge aggregation nodes 422 cooperate to provide various edge services and security to the client computing nodes 402. Additionally, because each client computing node 402 may be stationary or mobile, each edge gateway node 412 may cooperate with other edge gateway devices to propagate currently provided edge services and security as the corresponding client computing node 402 moves around the region. To do so, each of the edge gateway nodes 412 and/or edge aggregation nodes 422 may support a multi-tenant and multi-stakeholder configuration, and services from (or hosted for) multiple service providers and multiple consumers may be supported and coordinated among single or multiple computing devices.

In various examples, as further described below with reference to Figures 8 and 9, the authentication techniques may be implemented between a client computing node 402 (e.g., a client receiving an authentication token) at an edge gateway node 412 or an aggregation node 422 (e.g., a resource node having a resource to be authenticated) and other intermediate nodes in the edge cloud 110 (e.g., intermediate nodes performing an orchestrator function, an authentication service function, etc.).

In further examples, any of the computing nodes or devices discussed with reference to the present edge computing systems and environments may be implemented based on the components illustrated in Figures 5A and 5B. Each edge computing node may be embodied as a type of device, appliance, computer, or other "thing" capable of communicating with other edge, networking, or endpoint components. For example, an edge computing device may be embodied as a smartphone, a mobile computing device, a smart appliance, an in-vehicle computing system (e.g., a navigation system), or other device or system capable of performing the described functions.

In the simple example shown in Figure 5A, edge computing node 500 includes a computing engine (also referred to herein as "computational circuitry") 502, an input/output (I/O) subsystem 508, data storage 510, a communications circuitry subsystem 512, and optionally one or more peripheral devices 514. In other examples, each computing device may include other or additional components such as those used in personal or server computing systems (e.g., displays, peripheral devices, etc.). Furthermore, in some examples, one or more of the illustrative components may be incorporated into or otherwise form part of other components.

Computational node 500 may be embodied as any type of engine, device, or collection of devices capable of performing various computational functions. In some examples, computational node 500 may be implemented as an integrated circuit, an embedded system, a field-programmable gate array (FPGA), a system-on-a-chip (SOC), or a combination of these. In some examples, the processor 504 may be embodied as a single device such as a system on chip (SOC) or other integrated system or device. In an illustrative example, the computational node 500 includes or is embodied as a processor 504 and a memory 506. The processor 504 may be embodied as any type of processor capable of performing the functions described herein (e.g., executing an application). For example, the processor 504 may be embodied as a multi-core processor, a microcontroller, or other processor or processing/control circuitry. In some examples, the processor 504 may be embodied as, include, or be coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware, or hardware circuitry, or other specialized hardware to facilitate performance of the functions described herein.

The main memory 506 may be embodied as any type of volatile memory (e.g., dynamic random access memory (DRAM), etc.) or non-volatile memory or data storage capable of performing the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of data stored by the storage 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 the memory module is synchronous dynamic random access memory (SDRAM).

In one example, the memory device is a block addressable memory device, such as one based on NAND or NOR technology. The memory device may also include a three-dimensional cross-point memory device (e.g., Intel 3D XPoint® memory) or other byte addressable write-in-place non-volatile memory device. The memory device may refer to the die itself and/or the packaged memory product. In some examples, the 3D cross-point memory (e.g., Intel 3D XPoint® memory) or other byte addressable write-in-place non-volatile memory device may refer to the die itself and/or the packaged memory product. XPoint® memory may include a transistorless stackable cross-point architecture in which memory cells are located at the intersections of wordlines and bitlines and are individually addressable, and bit storage is based on changes in bulk resistance. In some examples, all or a portion of the main memory 506 may be integrated into the processor 504. The main memory 506 may store various software and data used during operation, such as one or more applications, data manipulated by the applications, libraries, and drivers.

The computing circuit 502 is communicatively coupled to other components of the computing node 500 via an I/O subsystem 508, which may be embodied as circuits and/or components for facilitating input/output operations with the computing circuit 502 (e.g., the processor 504 and/or the main memory 506) and other components of the computing circuit 502. For example, the I/O subsystem 508 may be embodied as or may otherwise include a memory controller hub, an input/output control hub, an integrated sensor hub, firmware devices, communications links (e.g., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and/or other components and subsystems for facilitating input/output operations. In some examples, the I/O subsystem 508 may form part of a system-on-chip (SoC) and be integrated into the computing circuit 502 along with one or more of the processor 504, the main memory 506, and other components of the computing circuit 502.

The one or more exemplary data storage devices 510 may be embodied as any type of device configured for short-term or long-term storage of data, such as, for example, memory devices and circuits, memory cards, hard disk drives, solid state drives, or other data storage devices. Each data storage device 510 may include a system partition that stores data and firmware code for the data storage device 510. Each data storage device 510 may also include one or more operating system partitions that store data files and executable files for an operating system, for example, depending on the type of compute node 500.

The communications circuitry 512 may be embodied as any communications circuitry, device, or collection thereof capable of enabling communications over a network between the computing circuitry 502 and other computing devices (e.g., the edge gateway nodes 412 of the edge computing system 400). The communications circuitry 512 may be configured to perform such communications using any one or more communications technologies (e.g., wired or wireless communications) and associated protocols (e.g., cellular networking protocols such as the 3GPP 4G or 5G standards, wireless local area network protocols such as IEEE 802.11/Wi-Fi®, wireless wide area network protocols, Ethernet®, Bluetooth®, etc.).

The exemplary communications circuit 512 includes a network interface controller, which may also be referred to as a host fabric interface (HFI). The computing node 500 includes a network interface card (NIC) 520. The NIC 520 may be embodied as one or more add-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that may be used by the computing node 500 to connect with other computing devices (e.g., the edge gateway node 412). In some examples, the NIC 520 may be embodied as part of a system-on-chip (SoC) that includes one or more processors, or may be included on a multi-chip package that also includes one or more processors. In some examples, the NIC 520 may include a local processor (not shown) and/or local memory (not shown), both of which are local to the NIC 520. In such examples, the local processor of the NIC 520 may be capable of performing one or more of the functions of the computing circuit 502 described herein. Additionally or alternatively, in such examples, the local memory of the NIC 520 may be integrated into one or more components of the client computing node at the board level, socket level, chip level, and/or other levels.

Additionally, in some examples, each computing node 500 may include one or more peripheral devices 514. Such peripheral devices 514 may include any type of peripheral device found on a computing device or server, such as audio input devices, displays, other input/output devices, interface devices, and/or other peripheral devices, depending on the particular type of computing node 500. In further examples, the computing nodes 500 may be embodied by respective edge computing nodes (e.g., client computing nodes 402, edge gateway nodes 412, edge aggregation nodes 422) or similar types of appliances, computers, subsystems, circuits, or other components in an edge computing system.

In a more detailed example, Figure 5B illustrates a block diagram of an example of components that may be present in an edge computing node 550 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein. The edge computing node 550 may include any combination of the components described above, or any device usable in an edge communications network or combination of such networks. The components may be implemented as an IC, part thereof, a discrete electronic device or other module adapted to the edge computing node 550, logic, hardware, software, firmware, or a combination thereof, or as a component otherwise integrated within the chassis of a larger system.

The edge computing node 550 may include processing circuitry in the form of a processor 552, which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. The processor 552 may be part of a system-on-chip (SoC) in which the processor 552 and other components are formed on a single integrated circuit or in a single package, such as the Edison® or Galileo® SoC boards from Intel Corporation of Santa Clara, Calif. By way of example, the processor 552 may include a processor based on the Intel® Architecture Core®, such as a Quark®, Atom®, i3, i5, i7, i9 or MCU class processor, or other such processor available from Intel®. However, other processors may be available from Advanced Micro Devices, Inc. of Sunnyvale, Calif. Any number of other processors may be used, such as those available from Advanced Micro Devices, Inc. (AMD), MIPS-based designs from MIPS Technologies, Inc. of Sunnyvale, Calif., ARM-based designs licensed from ARM Holdings, Ltd., or customers or licensees or adopters thereof. Processors may include units such as the A5-A12 processors from Apple Inc., the Snapdragon processors from Qualcomm Technologies, Inc., or the OMAP processors from Texas Instruments, Inc.

The processor 552 may communicate with a system memory 554 over an interconnect 556 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. By way of example, the memory may be random access memory (RAM) according to a Joint Electron Devices Engineering Council (JEDEC) design such as a DDR or mobile DDR standard (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In a particular example, the memory components may be standardized according to JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, Low Power DDR, The memory devices may conform to DRAM standards promulgated by JEDEC, such as JESD209 for LPDDR (LPDDR2), 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 the communication interfaces of storage devices implementing such standards may be referred to as DDR-based interfaces. In various implementations, the individual memory devices may be packaged in a single die package (SDP), a dual die package (DDP), or a quad die package (QDPP). The memory devices may be in any number of different package types, such as 1000MHz to 1000MHz (1.8GHz to 1.8GHz), 17 ...). In some examples, these devices may be soldered directly onto the motherboard to provide a lower profile solution, while in other examples, the devices are configured as one or more memory modules that 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, for example, different kinds of dual inline memory modules (DIMMs), including, but not limited to, microDIMMs or miniDIMMs.

Storage 558 may also be coupled to the processor 552 via interconnect 556 to provide persistent storage of information such as data, applications, operating systems, and the like. In one example, storage 558 may be implemented via a solid-state disk drive (SSDD). Other devices that may be used for storage 558 include flash memory cards, such as SD cards, microSD cards, XD picture cards, and the like, and USB flash drives. In one example, memory devices include chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single-level or multi-level Phase Change Memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory, The memory device may be or may include a memory device using FeTRAM, antiferroelectric memory, magneto-resistive random access memory (MRAM) incorporating memristor technology, resistive memory including metal oxide-based, oxygen vacancy-based and conductive bridge random access memory (CB-RAM) or spin transfer torque (STT)-MRAM, spin magnetic injection memory based devices, magnetic tunneling junction (MTJ) based devices, domain wall (DW) and spin orbit transfer (SOT) based devices, thyristor based memory devices, or any combination of these, or other memories.

In low power implementations, storage 558 may be on-die memory or registers associated with processor 552. However, in some examples, storage 558 may be implemented using a micro hard disk drive (HDD). Furthermore, any number of emerging technologies may be used for storage 558, such as resistive memory, phase change memory, holographic memory, or chemical memory, among others, in addition to or in place of the above technologies.

The components may communicate through an interconnect 556. The interconnect 556 may include any number of technologies, including industry standard architecture (ISA), extended ISA, peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The interconnect 556 may be, for example, a proprietary bus used in SoC-based systems. Other bus systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

The interconnect 556 may couple the processor 552 to a transceiver 566 for communicating with the connecting edge device 562. The transceiver 566 may use any number of frequencies and protocols, such as 2.4 gigahertz (GHz) transmissions in the IEEE 802.15.4 standard using the Bluetooth low energy (BLE) standard or the ZigBee standard defined by the Bluetooth Special Interest Group, among others. Any number of radios configured for a particular wireless communication protocol may be used for connection to the connecting edge device 562. For example, a wireless local area network (WLAN) may be used. A WLAN unit may be used to implement Wi-Fi® communications according to the Institute of Electrical and Electronics Engineers (IEEE) standard. Furthermore, wireless wide area communications may occur via a wireless wide area network (WWAN) unit, for example according to cellular or other wireless wide area protocols.

The wireless network transceiver 566 (or multiple transceivers) may communicate using multiple standards or radios for communication at different ranges. For example, the edge computing node 550 may communicate with nearby devices, for example within about 10 meters, using a local transceiver based on BLE or other low power radio to conserve power. A more distant connected edge device 562, for example within about 50 meters, may be reached by ZigBee or other medium power radio. Both communication technologies may be on a single radio at different power levels, or may be on separate transceivers, for example a local transceiver using BLE and a separate mesh transceiver using ZigBee.

A wireless network transceiver 566 (e.g., a radio transceiver) may be included to communicate with devices or services in the edge cloud 590 via a local area network or wide area network protocol. The wireless network transceiver 566 may be an LPWA transceiver following the IEEE 802.15.4 or IEEE 802.15.4g standard, among others. The edge computing node 550 may communicate over a wide area using the Long Range Wide Area Network (LoRaWAN®) developed by Semtech and the LoRa Alliance. The techniques described herein are not limited to these techniques and may be used with any number of other cloud transceivers implementing long range, low bandwidth communication such as Sigfox and other techniques. Additionally, other communication techniques may be used such as time slotted channel hopping as described in the IEEE 802.15.4e specification.

In addition to the systems mentioned for the wireless network transceiver 566 as described herein, any number of other wireless communications and protocols may be used. For example, the transceiver 566 may include a cellular transceiver using spread spectrum (SPA/SAS) communications to implement high speed communications. Additionally, any number of other protocols may be used, such as Wi-Fi networks for medium speed communications and providing network communications. The transceiver 566 may include radios compatible with any number of Third Generation Partnership Project (3GPP) specifications, such as Long Term Evolution (LTE) and 5th Generation (5G) communications systems, which are described in more detail at the end of this disclosure. A network interface controller, A first NIC 568 may be included to provide wired communications to other devices, such as nodes of the edge cloud 590 or connected edge devices 562. The wired communications may provide an Ethernet connection or may be based on other types of networks, such as a Controller Area Network (CAN), a Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among others. A further NIC 568 may be included to enable connection to a second network, e.g., a first NIC 568 provides communications over Ethernet to the cloud and a second NIC 568 provides communications over another type of network to other devices.

In consideration of various types of applicable communications from the device to other components or networks, applicable communications circuitry used by the device may include or be embodied by any one or more of components 564, 566, 568, or 570. Thus, in various examples, any applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communications circuitry.

The edge computing node 550 may include or be coupled to acceleration circuitry 564, which may be embodied by one or more AI accelerators, neural computing sticks, neuromorphic hardware, FPGAs, arrangements of GPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, special purpose ASICs, or other forms of specialized processors or circuits designed to accomplish one or more specialized tasks. These tasks may include AI processing (including machine learning, training, inference, and classification operations), visual data processing, network data processing, object detection, rule analysis, etc. Thus, in various examples, any applicable means for acceleration may be embodied by such acceleration circuitry.

The interconnect 556 may couple the processor 552 to a sensor hub or external interface 570 used to connect additional devices or subsystems. The devices may include sensors 572 such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, global positioning system (GPS) sensors, pressure sensors, barometric pressure sensors, etc. The hub or interface 570 may further be used to connect the edge computing node 550 to actuators 574 such as power switches, valve actuators, audible sound generators, visual warning devices, etc.

In some optional examples, various input/output (I/O) devices may be present in or connected to the edge computing node 550. For example, a display or other output device 584 may be included to show information such as sensor readings or actuator positions. An input device 586 such as a touch screen or keypad may be included to accept input. The output device 584 may include any number of forms of audio or visual display, including simple visual output such as binary status indicators (e.g., LEDs) and multi-character visual output, or more complex output such as a display screen (e.g., an LCD screen), along with output of text, graphics, multimedia objects, etc. generated or created from the operation of the edge computing node 550.

The battery 576 may power the edge computing node 550, or in instances where the edge computing node 550 is mounted in a fixed location, may have a power source coupled to a power grid. The battery 576 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, etc.

A battery monitor/charger 578 may be included in the edge computing node 550 to track the charging status of the battery 576. The battery monitor/charger 578 may also track the state of health (SoH) and state of function (Sof) of the battery 576. The battery monitor/charger 578 may be used to monitor other parameters of the battery 576 to provide failure prediction, such as SoF. The battery monitor/charger 578 may include a battery monitoring integrated circuit, such as the LTC4020 or LTC2990 from Linear Technologies, the ADT7488A from On Semiconductor of Phoenix, Arizona, or an IC from the UCD90xxx family from Texas Instruments of Dallas, Texas. The battery monitor/charger 578 may communicate information about the battery 576 to the processor 552 over the interconnect 556. The battery monitor/charger 578 may also include an analog-to-digital (ADC) converter that allows the processor 552 to directly monitor the voltage of the battery 576 or the current flow from the battery 576. The battery parameters may be used to determine actions that the edge computing node 550 may take, such as transmission frequency, mesh network operation, sensing frequency, etc.

A power block 580 or other power source coupled to the grid may be coupled to a battery monitor/charger 578 to charge the battery 576. In some examples, the power block 580 may be replaced with a wireless power receiver to obtain power wirelessly, for example, through a loop antenna in the edge computing node 550. A wireless battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, Calif., among others, may be included in the battery monitor/charger 578. The particular charging circuit may be selected based on the size of the battery 576 and thus the current required. Charging may be performed using 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, among others.

Storage 558 may include instructions 582 in the form of software, firmware, or hardware commands for implementing the techniques described herein. Although such instructions 582 are illustrated as code blocks contained in memory 554 and storage 558, it will be understood that any of the code blocks may be replaced by hardwired circuitry incorporated, for example, in an application specific integrated circuit (ASIC). Thus, in various examples, the applicable means for storage may be embodied by such storage circuitry.

In one example, the instructions 582 provided via the memory 554, storage 558, or processor 552 may be embodied as a non-transitory machine-readable medium 560 including code that instructs the processor 552 to perform electronic operations within the edge computing node 550. The processor 552 may access the non-transitory machine-readable medium 560 over the interconnect 556. Thus, in various examples, the applicable means for processing may be embodied by such a processor circuit. For example, the non-transitory machine-readable medium 560 may be embodied by a device described for the storage 558, or may include a specific storage unit such as an optical disk, a flash drive, or any number of other hardware devices. The non-transitory machine-readable medium 560 may include instructions that instruct the processor 552 to perform a particular sequence or flow of actions, for example, as described with respect to the operational and functional flow charts and block diagrams above. As used herein, the terms "machine-readable medium" and "computer-readable medium" are interchangeable. Thus, in various examples, the applicable means for memory may be embodied by such a memory circuit.

In a further example, machine-readable media also includes any tangible medium capable of storing, encoding or carrying instructions for execution by a machine to cause a machine to perform any one or more of the methodologies of the present disclosure, or capable of storing, encoding or carrying data structures used by or associated with such instructions. Accordingly, "machine-readable medium" may include, but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media are semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM)), electrically erasable programmable read-only memory (EEROM), and the like. Non-volatile memory, including but not limited to, memory devices such as EEPROMs) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. Instructions embodied by the machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP).

The machine-readable medium may be provided by a storage device or other device capable of hosting data in a non-transitory format. In one example, information stored or otherwise provided on the machine-readable medium may represent instructions, such as the instructions themselves or a format from which instructions may be derived. This format from which instructions may be derived may include source code, encoded instructions (e.g., in a compressed or encrypted form), packaged instructions (e.g., split into multiple packages), and the like. The information representing instructions in the machine-readable medium may be processed by a processing circuit into instructions for implementing any of the operations discussed herein. For example, deriving instructions from information (e.g., processing by a processing circuit) may include compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decrypting, encrypting, decrypting, packaging, unpackaging, or otherwise manipulating the information into instructions.

In one example, deriving the instructions may include assembling, compiling, or interpreting (e.g., by a processing circuit) the information to generate the instructions from some intermediate format or pre-processed format provided by a machine-readable medium. If the information is provided in multiple parts, it may be combined, unpacked, 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 and decrypted during transfer over a network, unpacked, assembled (e.g., linked) as necessary, compiled or interpreted on the local machine (e.g., into libraries, standalone executable programs, etc.), and executed by the local machine.

Each of the block diagrams in Figures 5A and 5B is intended to depict a high-level view of the arrangement of components, subsystems, or edge computing nodes of a device, but it is understood that some of the depicted components may be omitted, additional components may be present, and different arrangements of the depicted components may occur in other implementations.

FIG. 6 illustrates an overview of an architecture 600 for adaptive data flow transformation in an edge computing environment, according to an example. The architecture 600 may include a device 605 (e.g., a UE) connected to the edge computing environment. The architecture 600 includes an edge connectivity information service 650 logic element that provides the device 605 with information regarding the current state of various routes to a particular service (e.g., delivered via an application 655 via an edge network adaptation layer 610). The device 605 may register with the edge computing environment using registration logic 625 to receive network characteristics (e.g., bandwidth connection, delay, etc.) from one or more edge connectivity information services 650 that have information regarding edge access to the service. The edge connectivity information service 650 (or other location-based service) may track where the service is located within the edge computing environment (e.g., the service may move to different locations over time) and send updates to a device such as the device 605, so that the device 605 has connectivity information for the service. The network characteristics may be provided from one or more access points to which the device 605 may be connected during the N time units. For example, a mobile device in a vehicle may have a trajectory based on the movement of the device or vehicle that indicates access points that can be contacted at various time intervals.

The device 605 includes an edge connectivity prediction logic 620 that enables the device 605 to determine how to send and receive data to and from a particular service over time, depending on the information provided by the edge connectivity information service 650. The edge connectivity prediction logic 620 may include prediction schemes (e.g., based on Long-Short-Term Memory (LSTM) neural networks, trained artificial intelligence models, etc.) that can be used to predict how the network will evolve over time based on the information provided. The device 605 includes an edge network adaptation layer 610 that can be implemented using software or custom hardware or a combination of software and custom hardware modules. The edge network adaptation layer 610 is implemented using an application programming interface, The edge connectivity service 650 may provide an application 655 with an API that allows the application to request and receive information from the edge connectivity service 650 about connectivity information along multiple locations. The device 605 or application 655 may use the connectivity information on multiple paths to identify a better path for receiving data plane services. It may also use the connectivity information on multiple paths to select an appropriate data flow transformation for a particular location or path.

The device 605 may include a transformation policy 615 that may indicate when to invoke the transformation function 630. The transformation function may be executed by the device 605 and may perform various transformations on the data flow. For example, one type of data (e.g., video, raw sensor data, text, etc.) may be provided and a transformation function may be provided that may convert the data to another format that has a different resolution or less rich data, but allows the device 605 to send or receive more data or to send or receive data to a service more expediently over the current route or at the current location. The interface management component 635 may reference a transformation table 640 that includes various transformation functions that may be utilized to generate the transformed data flow 645. The interface management component 635 may register the transformation function 630 and may provide an edge network API that interacts with the edge network adaptation layer 610, which allows the application 655 to provide hints to the data being sent to the edge computing node and utilize the transformation functions to adapt the data flow.

In one example, a root of trust (RoT), such as a device identifier composition engine (DICE), may be used to secure communications between the device 605 and the edge cloud 110. Additionally, authentication may be used in the RoT to communicate to a verifier that it is interacting with a trusted edge node (such as an edge node providing edge connectivity information services 650) as a prerequisite for performing several operations on the network, including data transformation.

The conversion function 630 may perform a variety of functions. The conversion function 630 may, for example, cause the device 605 to send more data because it is expected that the device will experience insufficient bandwidth at the next hop, or may cause the device 605 to send more data to adapt the current bandwidth to the service when it connects to a next hop with increased bandwidth. Other examples of conversion functions 630 may include, but are not limited to, in a Content Delivery Network (CDN), reducing the quality of the requested image to begin buffering more data to mitigate poor connectivity to the next hop, in video analytics, reducing the quality of the image to maintain a required frame per second rate, in sensor data, reducing the number of samples sent or increasing buffering of samples sent on a predicted hop with better connectivity.

Taking into account the application's SLO, the type of data, and the expectations provided by the application, the transformation function may perform various individual or combined adaptive transformations on the data flow, including changing the resolution or quality of the data being sent/received, increasing the current throughput with or without changing the resolution or quality of the data, temporarily buffering the data, flushing the data from the local buffer at the next hop if or when the connection improves.

FIG. 7 is a block diagram of an environment 700 and a system 720 for adaptive data flow transformation in an edge computing environment, according to an example. The system 720 may provide the features described in FIG. 6. The environment includes an edge cloud 110 (e.g., as described in FIG. 1) including devices 705 (e.g., the endpoint data source 160 described in FIG. 1, the various client endpoints 210 described in FIG. 2, the client computing node 310 described in FIG. 3, the client computing node 402 described in FIG. 4, the connectivity edge device 562 described in FIG. 5B, etc.) and edge computing nodes 710 associated with base stations (e.g., the base station 140 described in FIG. 1, the first edge node 222 or the second edge node 224 described in FIG. 2, the communication base station 342 described in FIG. 3, one or more edge gateway nodes 412 described in FIG. 4, the edge computing node 550 described in FIG. 5B, etc.). In one example, the entities of the network are managed by the European Telecommunications Standards Institute, The server 715 may operate according to the Multi-access Edge Computing (MEC) standard provided in accordance with the ETSI (Equipment, Infrastructure, Transport and Systems) standard. The server 715 (e.g., a standalone server, a cloud service, a containerized service, etc.) may operate within the data center or elsewhere within the edge cloud 110. The server 715 may execute the system 720. For example, the server 715 may execute on the edge computing node 710. In one example, the system 720 may be an adaptive flow engine. The system 720 may include various components including a device manager 725, a transformation generator 730, a network monitor 735, and a metric packager 740.

The transform generator 730 may generate a set of transforms for the services and associated edge nodes operating in the edge cloud 110. In one example, the set of transforms may include one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a pre-fetch transform. The transforms may be derived by analyzing the workload and data flows associated with the services to determine how changes in aspects of data flow processing affect service delivery. For example, network usage history for nodes providing audio conferencing services may be evaluated using machine learning to identify that reducing the bit rate of the audio stream reduces jitter and results in a higher quality of service. A transform may then be generated to reduce the bit rate for an exemplary audio conferencing service when jitter is predicted to occur on the network.

The device manager 725 may interact with the device 705. For example, the device manager 725 may send and receive data between the system 720 and the device 705. The device manager may receive a transformation compatibility indication from the device 705. In one example, the device 705 may be registered with a registration service of the edge computing system of the edge cloud 110 to enable the device to utilize services available in the edge cloud 110. In one example, a transformation compatibility indicator may be received during registration. The compatibility indicator may include information about the device including, but not limited to, hardware specifications, software information, mechanisms available to perform data flow transformation, and the like. For example, the indicator may include an identification of a transcoding accelerator or processor mode available in the device 705. The device manager 725 may send a set of transformations to the device 705. In one example, the set of transformations may be created based on the transformation compatibility indication. For example, a transformation including a function to offload video transcoding from the edge computing node 710 to the device 70 may be included in the set of transformations sent to the device 705 if the indicator indicates that the device 705 includes a transcoding accelerator. In one example, the device manager 725 may send an application programming interface (API) to the device 705. The API may be used by the device 705 to obtain data and perform transformations.

The network monitor 735 may collect metrics about data flow and workload occurring through the edge cloud 110. The network monitor 735 may determine values of operational metrics for edge computing nodes 710 of the network. The edge computing nodes 710 may provide services to the devices 705 over the network. In one example, the operational metrics include one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric. In one example, the operational metric is an indication of operational performance between the edge computing node 710 and the device 705. For example, the network monitor 735 may track available bandwidth between the device 705 and the edge computing node 710 for an audio conferencing session.

The network monitor 735 may include a machine learning processor that may be used to evaluate network operational metrics to predict operational metrics for portions of the network. In one example, a network model may be trained for the edge computing nodes of the network using a set of training operational metrics collected from the edge computing nodes. Services and edge computing nodes 710 may be evaluated using the network model to establish operational metrics. For example, current operational metrics for the edge computing node 710 and metrics for an audio conferencing service may be provided as inputs to the network model to determine bandwidth metrics for the edge computing node 710 when an audio conferencing data flow is added to the workload of the edge computing node 710.

The metric packager 740 may aggregate the set of metrics into a set of edge connectivity information that may be delivered to the device 705 via the device manager 725 using an edge connectivity information service. The device manager 725 may send a transformation request to the device manager 725 based on the value of the operational metric. In one example, the metric may be sent to the device 705, and the device 705 may select a transformation to apply based on the capabilities of the device 705 and the metric value. The transformation request may cause the device 705 to perform a transformation from the set of transformations to transform the data flow of the service. For example, the device may receive a metric indicating that network bandwidth is decreasing, and the device 705 may apply a transformation function to reduce the bit rate of the audio conference data flow occurring between the device 705 and the edge computing node 710. In one example, the transformation may instruct the device 705 to process at least a portion of the workload associated with the service. For example, the transformation may offload video transcription from the edge computing node 710 to the device 705. In one example, the device 705 may utilize an API to obtain the metrics.

In one example, future values may be predicted for operational metrics for a destination edge computing node predicted to provide service to the device 705 in a future time period. For example, the service may move from the edge computing node 710 to another predicted destination edge computing node in the network, and bandwidth metrics may be predicted for delivery of the audio conference data flow between the device 705 and the other edge computing node. A transformation may be selected from a set of transformations based on the future values. In one example, the transformation request may include instructions to perform the selected transformation while the service is being delivered by the destination edge computing node. In one example, the device 705 may be in motion and may move from a base station providing access to the edge computing node 710 to yet another base station along a travel path that may provide access to another edge computing node that can accommodate the handoff of the audio conference data flow, and the device 705 may adapt the data flow by reducing the bit rate based on the reduced bandwidth available at the other edge computing node. In one example, the transformation of the data flow may be performed in advance while the device 705 is still connected to the edge computing node 710 to reduce interruptions in service quality during the handoff.

In one example, it may be determined that execution of a workload associated with the service has been moved from edge computing node 710 to a second edge computing node. A second value of the operational metric may be determined for the second edge computing node. A secondary transformation request may be sent to device 705 based on the second value. The transformation request may cause device 705 to perform a transformation of a set of transformations to transform a data flow of the service by the second edge computing node.

In one example, an SLO corresponding to the SLA may be determined for a data flow of the service to the device 705, and the SLO may be compared to the operational metric. The transformation request may be sent based at least in part on a result of the comparison. In another example, a second value may be determined for a second operational metric for the edge computing node 710, and the first value and the second value may be compared to a service delivery performance matrix for the service. A transformation may be selected from a set of transformations based on a result of the comparison, and the transformation may cause the device to perform an adaptation related to the second operational metric.

8 shows a flow chart of a method 800, according to one example, which may provide the features described in FIGS.

The translation compatibility indication may be received from the device (e.g., by device manager 725 of FIG. 7, etc.) (e.g., operation 805). In one example, the device may be registered with a registration service of the edge computing system to enable the device to use services, and the translation compatibility indicator may be received during registration.

A set of transforms available for use by devices connected to the network may be determined (e.g., by device manager 725 as generated by transform generator 730 as described in FIG. 7) based on the transform compatibility indicators (e.g., operation 810). In one example, the set of transforms may include one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a pre-fetch transform. In one example, the transforms may instruct the devices to process at least a portion of a workload associated with the service. The set of transforms may be sent (e.g., by device manager 725 as described in FIG. 7) to the devices (e.g., operation 815). In one example, the entities of the network may operate in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

Values may be determined (e.g., by network monitor 735, as described in FIG. 7) for operational metrics for edge computing nodes of the network. The edge computing nodes may provide services to devices over the network. In one example, the operational metrics may be indicative of operational performance between the edge computing nodes and the devices. In one example, the operational metrics may include one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric. In one example, a network model may be trained for the edge computing nodes of the network using a set of training operational metrics collected from the edge computing nodes, and the services and edge computing nodes may be evaluated using the network model to establish the operational metrics.

A transformation request may be sent (e.g., by device manager 725 as described in FIG. 7 ) to the device based on the value (e.g., operation 825). The transformation request may cause the device to perform a transformation from a set of transformations to transform the data flow of the service. In one example, future values may be predicted for operational metrics for a prior edge computing node that is predicted to provide the service to the device in a future time period, and a transformation may be selected from the set of transformations based on the future values. The transformation request may include instructions to perform the selected transformation while the service is provided by the prior edge computing node. In one example, an application programming interface (API) may be sent to the device, and the API may be used by the device to perform the transformation.

In one example, an SLO corresponding to the SLA may be determined for a data flow of the service to the device, and the SLO may be compared to an operational metric. The transformation request may be sent based at least in part on a result of the comparison. In another example, a second value may be determined for a second operational metric for the edge computing node, and the first value and the second value may be compared to a service delivery performance matrix for the service. A transformation may be selected from a set of transformations based on a result of the comparison, and the transformation may cause the device to perform an adaptation related to the second operational metric.

In one example, it may be determined that execution of a workload associated with the service has been moved from an edge computing node to a second edge computing node. A second value may be determined for an operational metric for the second edge computing node, and a secondary transformation request may be sent to the device based on the second value. The transformation request may cause the device to perform a transformation of a set of transformations to transform a data flow of the service by the second edge computing node.

Further Notes and Examples Example 1 is a method for adaptive data flows in a network for an edge computing system, comprising the steps of receiving a transformation compatibility indication from a device, determining a set of transformations available for use by a device connected to the network based on the transformation compatibility indicator, transmitting the set of transformations to the device, determining a value for an operational metric for an edge computing node of the network, the edge computing node providing a service to the device over the network, and transmitting a transformation request to the device based on the value, the transformation request causing the device to perform a transformation from the set of transformations to transform a data flow of the service.

In Example 2, the subject matter of Example 1 includes registering a device with a registration service of the edge computing system to enable the device to utilize a service, and a conversion compatibility indicator is received during registration.

In Example 3, the subject matter of Examples 1-2 includes where each transform of the set of transforms includes instructions for causing a device to perform an operation to adapt a delivery component of a service.

In Example 4, the subject matter of Examples 1-3 includes where the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 5, the object of Examples 1-4 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 6, the object of Examples 1-5 includes predicting future values for an operational metric for a destination edge computing node predicted to provide a service to a device in a future time period, and selecting a transformation from a set of transformations based on the future values, wherein the transformation request includes instructions for performing the selected transformation while the service is being delivered by the destination edge computing node.

In Example 7, the subject matter of Examples 1-6 includes the operational metric being an indication of operational performance between the edge computing node and the device.

In Example 8, the subject matter of Examples 1-7 includes the transforming includes instructing the device to process at least a portion of a workload associated with the service.

In Example 9, the subject matter of Examples 1-8 includes training a network model for edge computing nodes of the network using a set of training performance metrics collected from the edge computing nodes, and evaluating services and edge computing nodes using the network model to establish performance metrics.

In Example 10, the subject matter of Examples 1-9 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 11, the subject matter of Examples 1-10 includes sending an application programming interface (API) to a device, where the API is used by the device to perform the conversion.

In Example 12, the object of Examples 1-11 includes determining a service level objective (SLO) for a data flow of the service to the device and comparing the SLO to an operational metric, and the conversion request is sent based at least in part on a result of the comparison.

In Example 13, the object of Examples 1-12 includes determining a second value for a second operational metric for the edge computing node, and comparing the value and the second value to a service delivery performance matrix for the service, where a transformation is selected from a set of transformations based on a result of the comparison, the transformation causing the device to perform an adaptation associated with the second operational metric.

In Example 14, the subject matter of Examples 1-13 includes determining that execution of a workload associated with the service has moved from an edge computing node to a second edge computing node, determining a second value for an operational metric for the second edge computing node, and sending a secondary transformation request to the device based on the second value, the transformation request causing the device to perform a transformation from a set of transformations to transform a data flow of the service by the second edge computing node.

Example 15 may be at least one machine-readable medium containing instructions or stored data that, when configured and executed by a machine, cause the machine to perform any of the methods of Examples 1-14.

Example 16 is a system including means for carrying out the method of any one of Examples 1 to 14.

Example 17 is a system for adaptive data flows in a network for an edge computing system, comprising at least one processor and a memory containing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations of receiving a transformation compatibility indication from a device, determining a set of transformations available for use by a device connected to the network based on the transformation compatibility indicator, transmitting the set of transformations to the device, determining a value for an operational metric for an edge computing node of the network, the edge computing node providing a service to the device over the network, and transmitting a transformation request to the device based on the value, the transformation request causing the device to perform a transformation from the set of transformations to transform the data flow of the service.

In Example 18, the subject matter of Example 17 further includes the memory further including instructions for causing the at least one processor to register the device with a registration service of the edge computing system to enable the device to utilize the service, and the translation compatibility indicator is received during registration.

In Example 19, the subject matter of Examples 17-18 includes where each transform of the set of transforms includes instructions for causing a device to perform an operation to adapt a delivery component of a service.

In Example 20, the subject matter of Examples 17-19 includes where the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 21, the subject matter of Examples 17-20 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 22, the subject matter of Examples 17-21 further includes the memory further including instructions for causing the at least one processor to perform operations of predicting a future value for the operational metric for a destination edge computing node predicted to provide service to the device in a future time period and selecting a transformation from the set of transformations based on the future value, wherein the transformation request includes instructions for performing the selected transformation while the service is being delivered by the destination edge computing node.

In Example 23, the subject matter of Examples 17-22 includes the operational metric being an indication of operational performance between the edge computing node and the device.

In Example 24, the subject matter of Examples 17-23 includes the transforming instructing the device to process at least a portion of a workload associated with the service.

In Example 25, the subject matter of Examples 17-24 includes the memory further including instructions that cause at least one processor to perform operations of training a network model for edge computing nodes of the network using the set of training performance metrics collected from the edge computing nodes, and evaluating services and edge computing nodes using the network model to establish performance metrics.

In Example 26, the subject matter of Examples 17-25 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 27, the subject matter of Examples 17-26 includes the memory further including instructions for causing the at least one processor to send an application programming interface (API) to the device, the API being used by the device to perform the conversion.

In Example 28, the subject matter of Examples 17-27 further includes instructions where the memory causes the at least one processor to perform operations of determining a service level objective (SLO) for a data flow of the service to the device and comparing the SLO to an operational metric, and where the conversion request is sent based at least in part on a result of the comparison.

In Example 29, the subject matter of Examples 17-28 further includes instructions where the memory causes at least one processor to perform operations of determining a second value for a second operational metric for the edge computing node and comparing the value and the second value to a service delivery performance matrix for the service, where a transformation is selected from the set of transformations based on a result of the comparison, the transformation including causing the device to perform an adaptation related to the second operational metric.

In Example 30, the subject matter of Examples 17-29 further includes instructions where the memory causes the at least one processor to perform operations of determining that execution of a workload associated with the service has moved from the edge computing node to a second edge computing node, determining a second value for the operational metric for the second edge computing node, and sending a secondary transformation request to the device based on the second value, the transformation request including causing the device to perform a transformation from the set of transformations to transform a data flow of the service by the second edge computing node.

In Example 31, the subject matter of Examples 17-30 includes the set of transformations being transmitted through a network interface circuit of an edge node operating on the network.

In Example 32, the subject matter of Examples 17-31 includes the device being communicatively coupled to a network via a network interface circuit.

In Example 33, the subject matter of Examples 17-32 includes wherein communications between a network and a device are secured using a root of trust.

In Example 34, the subject matter of Example 33 includes the root of trust using authentication to verify the trustworthiness of the set of transformations.

Example 35 is at least one non-transitory machine-readable medium including instructions for adapting data flows in a network for an edge computing system, the instructions, when executed by a processing circuit, cause the processing circuit to perform operations of obtaining a transformation compatibility indication from a device, determining a set of transformations available for use by a device connected to the network based on the transformation compatibility indicator, transmitting the set of transformations to the device, determining a value for an operational metric for an edge computing node of the network, the edge computing node providing a service to the device over the network, and transmitting a transformation request to the device based on the value, the transformation request causing the device to perform a transformation of the set of transformations to transform a data flow of the service.

In Example 36, the subject matter of Example 35 includes instructions for causing at least one processor to register the device with a registration service of the edge computing system to enable the device to utilize a service, and wherein the translation compatibility indicator is received during registration.

In Example 37, the subject matter of Examples 35-36 includes where each transform of the set of transforms includes instructions for causing a device to perform an operation to adapt a delivery component of a service.

In Example 38, the subject matter of Examples 35-37 includes where the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 39, the subject matter of Examples 35-38 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 40, the object of Examples 35-39 includes instructions for causing at least one processor to perform operations of predicting a future value for an operational metric for a destination edge computing node predicted to provide a service to the device in a future time period, and selecting a transformation from a set of transformations based on the future value, wherein the transformation request includes instructions for performing the selected transformation while the service is being delivered by the destination edge computing node.

In Example 41, the subject matter of Examples 35-40 includes the operational metric being an indication of operational performance between the edge computing node and the device.

In Example 42, the subject matter of Examples 35-41 includes the transforming includes instructing the device to process at least a portion of a workload associated with the service.

In Example 43, the object of Examples 35-42 includes instructions to cause at least one processor to perform operations of training a network model for edge computing nodes of the network using a set of trained performance metrics collected from the edge computing nodes, and evaluating services and edge computing nodes using the network model to establish performance metrics.

In Example 44, the subject matter of Examples 35-43 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 45, the subject matter of Examples 35-44 includes instructions for causing the at least one processor to send an application programming interface (API) to a device, the API being used by the device to perform the transformation.

In Example 46, the object of Examples 35-45 includes instructions for causing at least one processor to perform operations of determining a service level objective (SLO) for a data flow of the service to the device and comparing the SLO to an operational metric, wherein the conversion request is transmitted based at least in part on a result of the comparison.

In Example 47, the object of Examples 35-46 includes instructions for causing at least one processor to perform operations of determining a second value for a second operational metric for the edge computing node and comparing the value and the second value to a service delivery performance matrix for the service, where a transformation is selected from a set of transformations based on a result of the comparison, the transformation causing the device to perform an adaptation related to the second operational metric.

In Example 48, the subject matter of Examples 35-47 includes instructions for causing at least one processor to perform operations of determining that execution of a workload associated with the service has moved from the edge computing node to a second edge computing node, determining a second value for an operation metric for the second edge computing node, and sending a secondary transformation request to the device based on the second value, the transformation request causing the device to perform a transformation from a set of transformations to transform a data flow of the service by the second edge computing node.

Example 49 is a system for adaptive data flows in a network for an edge computing system, including means for receiving a transformation compatibility indication from a device, means for determining a set of transformations available for use by a device connected to the network based on the transformation compatibility indicator, means for transmitting the set of transformations to the device, means for determining a value for an operational metric for an edge computing node of the network, the edge computing node providing a service to the device over the network, and means for transmitting a transformation request to the device based on the value, the transformation request causing the device to perform a transformation of the set of transformations to transform a data flow of the service.

In Example 50, the object of Example 49 includes means for registering a device with a registration service of the edge computing system to enable the device to utilize a service, wherein the conversion compatibility indicator is received during registration.

In Example 51, the subject matter of Examples 49-50 includes where the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 52, the object of Examples 49-51 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 53, the object of Examples 49-52 includes means for predicting a future value for the operational metric for a destination edge computing node predicted to provide service to the device in a future time period, and means for selecting a transformation from a set of transformations based on the future value, wherein the transformation request includes instructions for performing the selected transformation while the service is being delivered by the destination edge computing node.

In Example 54, the subject matter of Examples 49-53 includes the operational metric being an indication of operational performance between the edge computing node and the device.

In Example 55, the subject matter of Examples 49-54 includes the transforming includes instructing the device to process at least a portion of a workload associated with the service.

In Example 56, the object of Examples 49-55 includes means for training a network model for the edge computing nodes of the network using the set of training performance metrics collected from the edge computing nodes, and means for evaluating services and the edge computing nodes using the network model to establish the performance metrics.

In Example 57, the subject matter of Examples 49-56 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 58, the subject matter of Examples 49-57 includes means for transmitting an application programming interface (API) to the device, the API being used by the device to perform the conversion.

In Example 59, the object of Examples 49-58 includes means for determining a service level objective (SLO) for a data flow of the service to the device and means for comparing the SLO to an operational metric, and the conversion request is sent based at least in part on a result of the comparison.

In Example 60, the object of Examples 49-59 includes means for determining a second value for a second operational metric for the edge computing node, and means for comparing the value and the second value to a service delivery performance matrix for the service, where a transformation is selected from a set of transformations based on a result of the comparison, the transformation causing the device to perform an adaptation related to the second operational metric.

In Example 61, the subject matter of Examples 49-60 includes means for determining that execution of a workload associated with the service has moved from an edge computing node to a second edge computing node, means for determining a second value for the operational metric for the second edge computing node, and means for sending a secondary transformation request to the device based on the second value, the transformation request causing the device to perform a transformation from the set of transformations to transform a data flow of the service by the second edge computing node.

Example 62 is an apparatus for adaptive data flow in a network for an edge computing system, comprising at least one processor and a memory containing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations of sending a transformation compatibility indication to a registration service of the edge computing system, receiving a set of transformations based on the transformation compatibility indicator, receiving a value for an operational metric for an edge computing node of the network, the edge computing node providing a service over the network to the device, selecting a transformation from the set of transformations based on the value, and performing the transformation to transform a data flow of the service.

In Example 63, the subject matter of Example 62 includes the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 64, the object of Examples 62-63 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 65, the subject matter of Examples 62-64 includes the operational metric being an indication of operational performance between the edge computing node and the device.

In Example 66, the subject matter of Examples 62-65 includes the transformation being a local execution of at least a portion of a workload associated with the service.

In Example 67, the subject matter of Examples 62-66 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 68, the subject matter of Examples 62-67 includes the memory further including instructions for causing the at least one processor to perform operations of receiving an application programming interface (API) from a node of the edge computing system and performing a transformation using the API.

Example 69 is a method for adapting data flows in a network for an edge computing system, including sending a transformation compatibility indication to a registration service of the edge computing system, receiving a set of transformations based on the transformation compatibility indicator, receiving a value for an operational metric for an edge computing node of the network, the edge computing node providing a service to the method over the network, selecting a transformation from the set of transformations based on the value, and performing the transformation to transform the data flow of the service.

In Example 70, the subject matter of Example 69 includes the set of transforms includes one or more of a bit rate transform, a data collection transform, a data granularity transform, a transmission timing transform, a buffer transform, a compression transform, or a prefetch transform.

In Example 71, the subject matter of Examples 69-70 includes where the performance metric includes one or more of a delay metric, a distance metric, a network congestion metric, or a bandwidth metric.

In Example 72, the subject matter of Examples 69-71 includes the performance metric being an indication of performance between the edge computing node and the method.

In Example 73, the subject matter of Examples 69-72 includes the transformation being a local execution of at least a portion of a workload associated with the service.

In Example 74, the subject matter of Examples 69-73 includes the entities of the network operating in accordance with a Multi-Access Edge Computing (MEC) standard provided in accordance with a European Telecommunications Standards Institute (ETSI) standard.

In Example 75, the object of Examples 69-74 includes receiving an application programming interface (API) from a node of an edge computing system and performing a transformation using the API.

Example 76 may include one or more computer-readable storage media containing data that, upon loading, executing, configuring or providing the data by one or more processors or electronic circuitry of an electronic device, causes the electronic device to perform one or more elements of the method described or related to any of Examples 1-75.

Example 77 is an apparatus including means for implementing any of examples 1-75.

Example 78 is a system that implements any of Examples 1 to 75.

Example 79 is a method for implementing any of Examples 1 to 75.

The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Moreover, the inventors also contemplate examples that use any combination or permutation of these elements (or one or more aspects thereof) shown or described, with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

All publications, patents, and patent documents referenced in this document are incorporated by reference in their entirety as if each were individually incorporated by reference. In the event of inconsistent usage between this document and those documents incorporated by reference, the usage in the incorporated documents should be considered supplementary to the usage in this document; i.e., in the event of irreconcilable discrepancies, the usage in this document will control.

In this document, the singular forms "a," "an," and "the" are used, as is common in patent documents, to include one or more than one, independent of any other instance or usage of either "at least one" or "one or more." In this document, the term "or" is used to indicate a non-exclusive or, whereby "A or B" includes "A but not B," "B but not A," and "A and B." In the appended claims, the terms "including" and "in The term "which" is used as the plain English equivalent of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, i.e., systems, devices, articles, or methods that include elements in addition to those recited after such terms in a claim are still intended to fall within the scope of that claim. Moreover, in the following claims, terms such as "first," "second," and "third" are used merely as labels and are not intended to impose numerical requirements on their objects.

The above description is intended to be illustrative and not limiting. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments may be used by those of ordinary skill in the art upon review of the above description. The Abstract is submitted with the understanding that it is intended to enable the reader to quickly ascertain the nature of the technical disclosure, and will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be construed as intending that an unclaimed feature of the disclosure is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. The scope of the embodiments should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.