Network Flow-Based Hardware Allocation

Abstract

To provide systems, devices, methods, programs and machine-readable media for network flow-based hardware allocation.SOLUTION: A method comprises obtaining a workload for execution. Here, the workload includes a flow that has a processing component and a network component. Then, during execution of the workload, the flow is repeatedly profiled and assigned a network service and a processing service during a next execution based on a network metric and a processing metric obtained from the profiling.SELECTED DRAWING: Figure 15

Description

Technical Field

[0001] The embodiments described herein generally relate to the partitioning of computer hardware, and more specifically, to network flow-based hardware allocation.

Background Art

[0002] In edge computing, data and processing functions are moved closer to the consumers of these services. Edge platforms provide storage and processing at locations physically close to client devices. Examples of edge locations can include, among other places, in the home or within an enterprise (e.g., as part of a router or other networking device), roadside units (RSUs) for supporting vehicle services, or within a cellular base station. Due to the number and location variations of edge computing platforms, resources tend to be constrained with respect to storage, processing, functions, and power. Edge platforms often include mechanisms for hosting various services from many unrelated vendors, such as partitioning of resources implemented by hardware and software.

Brief Description of the Drawings

[0003] The drawings are not necessarily drawn to scale, and in the drawings, like reference numerals may describe like components from different perspectives. Like reference numerals with different subscripts may represent different examples of like components. The drawings generally illustrate various embodiments described herein by way of example and not limitation.

[0004] [Figure 1] FIG. 1 is a block diagram of an example of an environment including a system for network flow-based hardware allocation according to one embodiment.

[0005] [Figure 2] FIG. 2 shows an exemplary architecture according to one embodiment.

[0006] [Figure 3] An example of network characteristic association according to one embodiment is shown.

[0007] [Figure 4] An example of a learning agent for assigning network services and processing services according to one embodiment is shown.

[0008] [Figure 5] An example of real-time learning and telemetry using one embodiment is shown.

[0009] [Figure 6] An example of telemetry, actions, and rewards for learning behavior according to one embodiment is shown.

[0010] [Figure 7] An example of flow management according to one embodiment is shown.

[0011] [Figure 8] This document outlines an edge cloud configuration for edge computing.

[0012] [Figure 9] This shows the operational layer within the endpoint, the edge cloud, and the cloud computing environment.

[0013] [Figure 10] This document presents an exemplary approach to networking and services within edge computing systems.

[0014] [Figure 11] This demonstrates the deployment of a virtual edge configuration within an edge computing system that can operate across multiple edge nodes and multiple tenants.

[0015] [Figure 12] Shows various computing arrangements in which containers are deployed in an edge computing system.

[0016] [Figure 13A] Provides an overview of exemplary computing components deployed on computing nodes within an edge computing system.

[0017] [Figure 13B] Provides a further overview of exemplary components within a computing device in an edge computing system.

[0018] [Figure 14] Shows an exemplary software distribution platform for distributing software.

[0019] [Figure 15] Shows a flowchart of an example of a method for network flow-based hardware allocation according to one embodiment.

[0020] [Figure 16] Is a block diagram showing an example of a machine in which one or more embodiments can be implemented.

MODE FOR CARRYING OUT THE INVENTION

[0021] Edge platforms are transitioning towards a mass-market hardware approach, where no single entity controls platform resources. Rather, services (e.g., workloads) negotiate resource usage, resulting in a fair and decentralized distribution of edge platform resources. Connectivity within such platforms is diverse, highly configurable, and often asynchronous with respect to workload execution. In traditional implementations, when multiple connectivity technologies are available, such as those compliant with IEEE 802.11 standards, cellular standards, Ethernet®, optical connectivity, etc., connectivity is assigned to services in a static (e.g., immutable) manner.

[0022] With the increasing deployment of the 3rd Generation Partnership Project (3GPP®) 5G standards family and the growth of Internet of Things (IoT) services driving the need for edge computing, there is a need for resource democratization to form an effective edge cloud infrastructure using edge platforms that provide edge cloud capabilities to host multi-tenant applications belonging to multiple tenants (e.g., telecommunications companies, content service providers (CSPs), or other service providers) and from a diverse range of independent software vendors (ISVs) and service providers. The emergence of democratized edge has made fixed resource allocation in a cloud-native manner for virtual machine (VM) containers or applications inefficient.

[0023] Furthermore, fixed allocation of network services (e.g., network interfaces, whether physical or virtual) is inefficient and often hinders compliance with service level agreements (SLAs). Intelligent frameworks are used to address these challenges. These frameworks learn the resource (e.g., processing or network) characteristics of workload flows, negotiate service providers and services (e.g., 5G services, ultra-high bandwidth, ultra-low latency, etc.), and negotiate processing resources within the democratized edge platform (e.g., hardware acceleration, frequency of operation, storage, etc.) to dynamically support dedicated network flows for each workload. This allows workloads to negotiate the optimal network services for connection in real time and update network services as needed.

[0024] The systems and technologies described herein differ from other approaches to addressing similar challenges. For example, this approach uses an intelligent framework to select network services that learn workload traffic flow characteristics and performs network service negotiation before the workload (e.g., applications, executable programs, VMs, containers, etc.) is instantiated. This approach addresses edge platform connectivity but does not necessarily address end-user devices (e.g., user equipment (UE)) with multiple network connectivity options. Rather, the intelligent framework supports workloads by providing resource estimation, reconfiguring hardware and facilitating negotiation of network services (e.g., High Reliability Low Latency Communications (URLLC), Enhanced Mobile Broadband (EMBB), etc.) with service providers (e.g., 5G connectivity operators). In contrast, UE device technologies may select between different radio technologies to maximize, for example, speed or power efficiency, but these devices generally do not have multiple tenants competing for throughput, as is the case in the edge platform.

[0025] Another aspect that distinguishes this approach using UE communications addresses the nature of the problem being addressed. Typically, a single tenant device, such as a UE, attempts to maximize the performance of a single tenant. This can be achieved by tracking communications across the network, such as multipath, using protocols that facilitate this performance enhancement, thereby optimizing bandwidth and latency between source and destination across multiple links. However, these techniques typically require technology-aware protocols such as multipath TCP, thus requiring prior knowledge. Multipath is used to effectively manage communications across multiple links between source and destination devices. However, the techniques described herein address a different challenge: which network service to assign a workload to. Therefore, these techniques eliminate many options for informing the selection of a service for a workload. For example, if a VM requires two independent physical network connections on an edge node with eight network interfaces, which two of these network interfaces should be selected for the VM? This situation becomes even more complex if these eight network interfaces change their operating characteristics based on negotiations with their respective service providers. These types of selection decisions are not performed by the current approach.

[0026] In many mass-market edge platforms, network services are mass-marketed without designated QoS assignments. Therefore, numerous connections can exist providing a variety of QoS services. Thus, intelligent frameworks may include negotiation agents, learning components, or assignment frameworks to meet workload requirements. Generally, in this specification, a network interface capable of meeting workload requirements for the lowest cost over a given period is synonymous with the “best” interface.

[0027] The following scenarios illustrate a few challenges related to edge platforms and the subsequent actions of an intelligent framework to address them. Consider session-based requests, where Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTP) connections may prevail for the network flow of workloads in the cloud and at the edge. HTTP session initiation is often the most commonly used workload, benefiting from dynamic interface selection because connection establishment is frequent, short-lived, and operates through multiple 5-tuple flow IDs, each independent for each session. Before each end-to-end HTTP or HTTPS connection is established based on the workload's session requirements, the intelligent framework negotiates, reconfigures platform resources, and selects the best interface.

[0028] Consider the deployment of microservices. Here, when VMs or containers are deployed on an edge platform, the operating system (OS) or hypervisor must decide which network interfaces to select for a given workload. Edge platforms do not have the same service set availability for network interfaces as those in cloud or data center infrastructure. Traditionally, these network selections are static and pre-configured. The intelligent framework described herein dynamically selects the optimal set of physical network interfaces to meet the requirements of the VMs or containers, based on workload requirements and network behavior learned by the intelligent framework.

[0029] We consider a pay-as-you-go model for a democratized edge platform. Here, whenever a workload requests a network interface with a dedicated service and provides compensation for that dedicated network service, the intelligent framework allows the application to negotiate for the service. The intelligent framework selects the network interface that allows the service to be negotiated during runtime. The intelligent framework also reconfigures the platform to support network flows with dedicated platform resources. Additional details and examples are provided below.

[0030] Figure 1 is a block diagram of an example environment including a system for network flow-based hardware allocation according to one embodiment. As shown, a workload 120 (e.g., an application, VM, container, etc.) has a flow 115. The flow 115 operates via a network service 110 (e.g., a network interface card (NIC)) managed by an edge platform 105.

[0031] The edge platform 105 includes computer-readable media. The computer-readable media includes instructions that, when executed by the edge platform's processing circuitry, implement an intelligent framework. Thus, the instructions configure the processing circuitry to acquire workloads 120 for execution. Workloads 120 can be acquired in any number of ways, but a typical approach involves receiving requests or schedules to instantiate the workload (whether it be an application, a VM, a container, a microservice, or another workload). What the workloads 120 have in common is the presence of flows 115. In this context, flows 115 are processing pipelines that include network communications. The scope of flows 115 can vary. For example, flows 115 may encompass a single stateless HTTP transaction, as is common in servicing a web page or executing a microservice call. In one example, flows 115 may encompass an entire execution of an application, or an entire single session over an application execution, and the entire may include several sessions. In one example, the scope of all flows 115 is the same across workloads 120, such that each flow 115 is session-based or network request-based.

[0032] What all flows 115 have in common is the combination of processing components and network components. Therefore, each flow 115 involves the use of certain processing hardware, such as central processing unit (CPU) time, accelerator (e.g., graphics processing unit (GPU), field-programmable gate array (FPGA), artificial intelligence (AI) processor (e.g., neuromorphic processor)), state memory (e.g., random access memory RAM), and storage (e.g., hard drive, solid-state storage, etc.), in order to generate data to be transmitted to another device through the network service 110.

[0033] The processing circuit is configured to execute workload 120. While workload 120 is running, the intelligent framework observes the use of allocated processing and network resources 110, records the results, and applies the usage data to adjust the selection of processing and network resources 110 during the current or next run of workload 120. This profiling and adjustment is repeated while workload 120 is running.

[0034] Therefore, the processing circuit is configured to profile flow 115 to determine network metrics for network components and processing metrics for processing components. Here, network metrics may include any of the following in relation to the execution of network service 110: timing of use, bandwidth consumption, latency experience, packet degradation, or other network metrics. Similarly, processing metrics may include any of the following: CPU or accelerator usage (e.g., power consumption, idle time, percentage of cores used), memory usage, storage usage, etc. The metrics are used to determine whether the processing or network service 110 is the "right size" for workload 120. Ideally, the requirements of workload 120 regarding speed, latency, bandwidth, etc., should be met without oversubscribing to processing or network resources. Therefore, network metrics indicating that less bandwidth is being used than is available or processed by the processing service (e.g., because the receiving device cannot process as much) indicate that fewer processing resources and slower network interfaces can be allocated to workload 120 without issue.

[0035] In one example, profiling is performed at predefined time intervals. Thus, while workload 120 is running, measurements of network metrics or processing metrics are taken and recorded. In another example, profiling is performed in response to an event. For example, an event may include contention on a resource, exceeding a threshold for waiting for workload 120, etc. In yet another example, profiling is performed when a query about flow 115 or workload 120 is received.

[0036] In one example, profiling involves tagging the communications of flow 115 using network service 110 with identification information. Here, the ID tagging allows the profiler to track these activities in order to correlate different activities within flow 115. Thus, the identification information can be mapped to flow 115. In one example, the identification information is a tuple containing source address, source port, destination port, or communication type. This ID reflects the connection-based orientation of the network components of flow 115.

[0037] In one example, profiling updates the interface profile and ranking database. Recording profiling metrics enables processing for subsequent assignment of services to workload 120. In one example, entries in the interface profile and ranking database are 30 bits long. In one example, interfaces are ranked in the interface profile and ranking database by flow. Assigning network service 110 and processing service to flow 115 in the next execution based on network metrics and processing metrics includes selecting the interface with the highest rank for flow 115. In one example, interfaces are ranked based on the combination of flow 115 and the processing service selected for flow 115. The table provided below in the description of Figure 4 shows an example of such a database and ranking.

[0038] The processing circuit is configured to assign network services 110 (e.g., network interfaces, whether physical or virtual) and processing services to flow 115 in the next execution based on network metrics and processing metrics. Here, the next execution may include the next instantiation of workload 120, the next action during the current instantiation of workload 120 (e.g., instruction, connection, etc.), or something in between. The recorded metrics allow the intelligent framework to track the execution of the flow-to-resource assignment as workload 120 is executed. Thus, multiple factors attributable to network 110 and processing services are correlated to the execution of flow 115. The intelligent framework can then match the next flow to a service that satisfies the requirements of flow 115. In one example, the processing circuit is configured to assign network services 110 by selecting a network service 110 that contains the minimum network metric required to satisfy the network component of flow 115. In one example, the network metric is bandwidth or latency.

[0039] In one example, the processing circuit is configured to assign network services 110 and processing services by selecting a network service 110 that includes the minimum network metric necessary to meet the maximum output associated with the processing service's network metric. Here, the problem of oversubscribing network service 110 to a processing service with less capacity is addressed. Therefore, if a processing service capable of outputting only 1 megabyte per second (1 Mbps) is assigned to workload 120, assigning a 1 gigabit per second (1 Gbps) network interface to this flow is wasteful and should be avoided. Rather, it is generally most efficient to match the processing service output capability to the network service 110 output capability.

[0040] Figure 2 shows an exemplary architecture according to one embodiment. The architecture hosts workloads such as applications, virtual machines, and containers, and provides various services such as audio or video processing, storage, or distribution, data storage (e.g., caching, backup, etc.), or other edge services.

[0041] The architecture includes management components such as the hypervisor's operating system to provide hardware to host workloads. The hardware shown includes various interfaces (shown as IP1 through IP8) for various physical media, such as wired or wireless service provider networks (e.g., Frame Relay physical connections shown as ISP1 and ISP2), radio wave media, and wired Ethernet®.

[0042] The box shown on the left illustrates that network interface hardware is a service that can be provided to a workload. The workload has requirements, and the intelligent framework matches these requirements with the offerings. The dashed line shows the intelligent framework 205 within the edge platform. The intelligent framework includes a telemetry agent 210, a learning agent 215, and an allocation agent 220. In operation, the intelligent framework 205 allocates network interfaces to VMs, containers, or applications based on requirements and learning characteristics. The intelligent framework enables applications to request, change, and operate by dynamically acquiring network interface functionality using a pay-as-you-go model.

[0043] Figure 3 shows an example of network characteristic association according to one embodiment. Platform resource telemetry works with network characteristic telemetry to meet quality of service (QoS) and service level agreement (SLA) specifications for the workload. Consider a scenario where a selected network interface with high capacity is allocated to the workload, but computing resources are insufficient. This scenario results in a waste of network resource allocation. Therefore, dynamic allocation of appropriate network interfaces to meet application requirements while considering available computing resources is useful to avoid over-provisioning.

[0044] Figure 4 shows an example of a learning agent for assigning network and processing services according to one embodiment. In the component shown, each workload can transparently connect to an end host via a network interface that is selected based on learning which connectivity is "best" for that workload.

[0045] Platform resources are dynamically tracked and learned for a given workload. This is used to predict how much networking resources can be utilized "potentially" and "effectively." In one example, platform resources are learned based on tagging IDs that are mapped to each flow, each having a 5-tuple: source IP: destination IP: source port: destination port: IP type [UDP, TCP]. The 5-tuple flow ID is used to map end-to-end connections because network behavior can vary between two different end-to-end (E2E) connections over the same interface.

[0046] Network characteristics reporting can be implemented in several ways. For example, it can be implemented through periodic reporting at regular time intervals, through event-based responsiveness reporting, or through on-demand query-based reporting.

[0047] The learned capabilities extend to end-to-end connectivity from the platform to the backend applications. Such characteristics considered may include, among other things, base station scheduling, cable modem or optical network unit scheduling, and gateway or switch behavior.

[0048] Interface profiles and ranking databases track features that are dynamically learned in relation to network characteristics and application requirements. An example of such a database is shown in the table below. In this example, the representation of each entry in the database is approximately 32 bits wide, including a compact representation. This bit width is sufficient to host numerous flows for each application with a few MB of static memory cells in DRAM (or persistent memory such as NAND on Intel platforms, for example) that can be enumerated during OS boot. In this example, the database is updated every 2-3 minutes. This rate does not increase the size of the database because new data overwrites old data.

[0049] The learned capabilities can be used to populate an interface ranking profile database. This database can be used to trigger the selection of end-to-end connections for an application.

[0050] The resolution (e.g., parameters across inference) and ranking of dynamic learning can be based on a 5-tuple ID, where each 5-tuple ID is unique across all network flows and interfaces. Where required by the workload, the intelligent framework may request service providers (e.g., operators providing network connectivity) to negotiate services and reconfigure the platform. [Table 1] [Table 2] [Table 3]

[0051] Figure 5 shows an example of real-time learning and telemetry according to one embodiment. The illustrated components show an example of telemetry, actions, and reward functions for learning behavior. This can be combined with Figure 6 to implement a dynamic learning solution for the selection of an intelligent network interface.

[0052] Supervised reinforcement learning can be used to continuously learn workload requirements. Unsupervised learning can be used to maximize workload QoS through the selection of appropriate network interfaces by learning network interface characteristics. More specifically, historical data on application hardware platform resource usage can be used to estimate network requirements (e.g., processing metrics or internal information) and generate Table 2 above.

[0053] Network characteristics can be learned from various factors to estimate the functions described in Table 1 above. Inferences can be derived (e.g., based on switches, gateways, or schedulers) from the physical layer (e.g., received signal strength, total power, etc.) or the network itself to estimate bandwidth allocation, latency, etc., for a workload. Scheduler or gateway information can be learned from observed bandwidth and latency changes at the network interface for a given flow. For example, in a base station or cable model termination system, the scheduler prioritizes certain traffic flows (e.g., video streaming services) that can be inferred by the learning agent.

[0054] As shown in Figure 6, the reward function compares actual application QoS requirements and provides the best interface selection to satisfy as many QoS requirements as possible.

[0055] Figure 6 shows an example of telemetry, actions, and rewards for learning behavior according to one embodiment. The shown neural network interacts with input data (e.g., flow, network service, and processing service database) and flow performance in a given configuration. Performance is used as punishment or reward to adjust ranking within the database. Thus, if the performance of a given service combination for a flow is insufficient, the neural network is trained to lower the ranking of this combination. This ensures that the combination is less likely to be selected for the next execution of the flow.

[0056] The reward-based reinforcement described here is a form of unsupervised learning. Generally, in neural network learning (e.g., modification or training), a set of inputs is processed, outputs are realized, and a goodness-of-fit function (e.g., error estimate) is computed. Traditional training techniques use backpropagation to modify connection weights (often called synapses, but this terminology can vary) so that for future runtime inputs, the probability of an inaccurate output given the same input is reduced, and the probability of a desired (e.g., correct) output is increased. The degree to which the weights are modified is a design choice, and this choice affects the speed and accuracy of the neural network's convergence.

[0057] In the reinforcement (e.g., reward) learning shown in Figure 6, the reward function calculates the required accuracy of the neural networks in Blocks 1 and 2 from the evaluation of Block 3. Block 3 is a pre-trained network that accepts real-time telemetry of the application on the network interface and provides its output (e.g., features, metrics, etc.) to the reward function. The reward function also accepts the outputs of Block 1 (features or metrics of the application state of the processor service) and Block 2 (network service rankings with different classifications for the application on the processing service). The reward function then compares the expected performance of the outputs of Blocks 1 and 2 with the actual performance measured by Block 3 and adjusts the weights of Blocks 1 and 2 accordingly. This arrangement provides continuous improvement of the intelligent agent performance, thereby addressing the changing conditions to satisfy the actual performance of the selection between processing services and network services for the workload.

[0058] Figure 7 shows an example of flow management according to one embodiment. The flow shown illustrates an example of interaction between the components described above. As shown, initial network service allocation may be performed based on provided metrics about the workload. A learning (e.g., artificial intelligence, statistical analysis, etc.) agent observes the performance of the workload through the performance of the workload flow through processing and network services. This results in ranked combinations of flows, processing services, and network services, enabling rapid selection of processing or network services (or pairs thereof) when the next execution of the flow is imminent.

[0059] Figure 8 is a block diagram illustrating an overview of the edge computing configuration. This configuration includes a processing layer referred to as the “edge cloud” in many of the following examples. As shown, the edge cloud 810 may include multiple entities, devices, and equipment instances because it is located in the same location as the edge locations, such as an access point or base station 840, a local processing hub 850, or a central station 820. The edge cloud 810 is located much closer to the endpoint (consumer and producer) data sources 860 (e.g., autonomous vehicles 861, user equipment 862, business and industrial equipment 863, video capture devices 864, drones 865, smart city and building devices 866, sensors, and IoT devices 867, etc.) than the cloud data center 830. The compute, memory, and storage resources provided at each edge within the edge cloud 810 are crucial for providing ultra-low latency response times for services and functions used by the endpoint data source 860, and also reduce network backhaul traffic from the edge cloud 810 to the cloud data center 830, resulting in improved energy consumption and overall network usage, among other benefits.

[0060] Computation, memory, and storage are scarce resources, and generally decrease with edge location (for example, consumer endpoint devices have fewer available processing resources than base stations or central stations). However, the closer the edge location is to the endpoint (e.g., user equipment (UE)), the more space and power constraints are often imposed. Therefore, edge computing attempts to reduce the amount of resources required for network services by distributing more resources that are geographically closer and have better network access time. In this way, edge computing attempts to bring computing resources to workload data where appropriate, or brings workload data to computing resources.

[0061] The following describes embodiments of edge cloud architectures that cover multiple potential deployments and address limitations that some network operators or service providers may have within their own infrastructure. These include configurations based on edge location (in multi-tenant scenarios, edges at the base station level may have, for example, more constrained performance and functionality), configurations based on the type of compute, memory, storage, fabric, acceleration, or similar resources available at edge location, location tier, or group of locations, and variations of service functions, security functions, management functions, and orchestration functions, along with related objectives for achieving end-service usability and performance. These deployments can realize processing within network layers that may be considered “near edge” layer, “near edge” layer, “local edge” layer, “central edge” layer, or “far edge” layer depending on latency, distance, and timing characteristics.

[0062] Edge computing is an evolving paradigm. In this paradigm, computation is performed at or near the "edge" of the network, typically through the use of a computing platform (e.g., x86 or ARM computing hardware architecture) implemented in base stations, gateways, network routers, or other devices much closer to the endpoint devices that generate and consume data. For example, an edge gateway server may be equipped with a pool of memory and storage resources for performing real-time computations for low-latency use cases of connected client devices (e.g., autonomous driving or video surveillance). Alternatively, as an example, a base station may be augmented with computing and acceleration resources to directly handle service workloads of connected user equipment without further data transmission over the backhaul network. Or, as another example, central station network management hardware may be replaced with standardized computing hardware that performs virtualized network functions and provides computing resources for performing service and consumer functions for connected devices. Within an edge computing network, there may be scenarios in services where computing resources "move" to data, and scenarios where data "move" to computing resources. Alternatively, for example, to manage corner cases, emergencies, or to provide the lifespan of resources deployed over significantly longer lifecycles, base station computing, acceleration, and network resources can be provided to scale to workload demands as needed by activating idle capacity (subscription, on-demand capacity).

[0063] Figure 9 illustrates the operational layers within the endpoint, the edge cloud, and the cloud computing environment. Specifically, Figure 9 illustrates an example of compute use case 905 using the edge cloud 810 among several exemplary layers of network computing. These layers begin at the endpoint (device and thing) layer 900. The endpoint layer 900 accesses the edge cloud 810 to perform data generation, data analysis, and data consumption activities. The edge cloud 810 may span multiple network layers. These multiple network layers include the edge device layer 910, which has gateways, on-premises servers, or network equipment (nodes 915) located within physically close edge systems; the network access layer 920, which encompasses base stations, radio processing units, network hubs, regional data centers (DCs), or local network equipment (equipment 925); and any equipment, devices, or nodes located between them (within layer 912, but not shown in detail). Network communications within the edge cloud 810 and across the various layers may occur via any number of wired or wireless media, including through connectivity architectures and technologies not shown.

[0064] Examples of latency resulting from network communication distance and processing time constraints can range from less than milliseconds (ms) in the endpoint layer 900, to less than 5ms in the edge device layer 910, and further to 10-40ms when communicating with nodes in the network access layer 920. Beyond the edge cloud 810 are the core network 930 and cloud data center 940 layers, where latency increases (for example, from 50-60ms in the core network layer 930 to over 100ms in the cloud data center layer). As a result, operation at latencies of at least 50-100ms or more in the core network data center 935 or cloud data center 945 will not enable many of the time-critical functions of use case 905. Each of these latency values ​​is provided for illustrative and comparative purposes only. It will be understood that these latencies can be further reduced using other access network media and technologies. In some examples, each part of the network may be categorized as “near edge,” “local edge,” “near edge,” “central edge,” or “far edge” layers relative to the network source and destination. For example, from the perspective of a core network data center 935 or a cloud data center 945, a central office or content data network may be considered to be located in the “near edge” layer (near the cloud with high latency values ​​when communicating with devices and endpoints in use case 905), while access points, base stations, on-premises servers, or network gateways may be considered to be located in the “far edge” layer (far from the cloud with low latency values ​​when communicating with devices and endpoints in use case 905). It will be understood that other categorizations of specific network layers that make up the “near” edge, “local” edge, “near” edge, “central” edge, or “far” edge may be based on latency, distance, number of network hops, or other measurable characteristics measured from the source in any of the network layers 900-940.

[0065] Various use cases 905 may access resources under usage pressure from incoming streams, resulting from multiple services utilizing the edge cloud. To achieve low-latency results, services running within the edge cloud 810 must balance varying requirements with respect to (a) priority (throughput or latency) and quality of service (QoS) (e.g., autonomous vehicle traffic may have a higher priority than a temperature sensor in terms of response time requirements, or performance sensitivity / bottlenecks may exist in compute / accelerators, memory, storage, or network resources, depending on the application), (b) reliability and flexibility (e.g., some input streams must operate in line with mission-critical reliability, and traffic must be routed with mission-critical reliability, while some other input streams may tolerate accidental failures, depending on the application), and (c) physical constraints (e.g., power, cooling, and form factor).

[0066] The end-to-end service diagrams for these use cases are accompanied by the service-flow concept and are associated with transactions. A transaction details the overall service requirements of the entities consuming the service, as well as the associated services of resources, workloads, and workflows, and the business function requirements and business-level requirements. Services performed using the described "terms" may be managed at each tier in a manner that ensures real-time and runtime contract compliance for transactions throughout the service lifecycle. If a component within a transaction fails to agree to the SLA, the system as a whole (each component within the transaction) may provide (1) the ability to understand the impact of the SLA breach, (2) the ability to extend other components in the system to restore the entire transaction SLA, and (3) the ability to implement and remediate the steps.

[0067] Therefore, with these variations and service characteristics in mind, edge computing within edge cloud 810 can provide the ability to serve and respond to multiple applications in use case 905 (e.g., object tracking, video surveillance, connected cars, etc.) in real time or near real time, meeting the ultra-low latency requirements of these multiple applications. These advantages enable a whole new class of applications (virtual networking functions (VNFs), functions as a service (FaaS), edge as a service (EaaS), standard processing, etc.) that cannot leverage traditional cloud computing due to latency or other limitations.

[0068] However, the advantages of edge computing come with the following caveats: Devices located at the edge are often constrained resources, and therefore there is pressure on the use of edge resources. Typically, this is addressed through pooling memory and storage resources for use by multiple users (tenants and devices). The edge may have constrained power and cooling, and therefore power consumption by the most power-consuming applications must be considered. These pooled memory resources may have inherent power-performance trade-offs, as many of them may utilize newly emerging memory technologies that require greater memory bandwidth for more power. Similarly, improved hardware security and trust base capabilities are also required, as edge locations may be unattended and may even require permission to access (e.g., if housed in a third-party location). Such challenges are amplified in edge cloud 810 in multi-tenant, multi-owner, or multi-access configurations. In these configurations, services and applications are demanded by many users, particularly as network usage fluctuates dynamically and the composition of multiple stakeholders, use cases, and services changes.

[0069] At a more general level, an edge computing system can be described as encompassing any number of deployments in the aforementioned layers operating within an edge cloud 810 (network layers 900-940) that provides coordination from clients and distributed computing devices. One or more edge gateway nodes, one or more edge aggregation nodes, and one or more core data centers, distributed across network layers, can provide implementations of the edge computing system by telecommunications service providers ("telco" or "TSP"), Internet of Things service providers, cloud service providers (CSP), enterprise entities, or any number of other entities, or on their behalf. Various implementations and configurations of the edge computing system can be provided dynamically, for example, when orchestrated to meet service objectives.

[0070] In the examples provided herein, a client compute node may be embodied as any type of endpoint component, device, appliance, or other thing that can communicate as a data producer or consumer. Furthermore, the labels “node” or “device” used within an edge computing system do not necessarily imply that such a node or device operates in the role of a client or agent / minion / follower; rather, any node or device within an edge computing system refers to an individual entity, node, or subsystem, which includes separate or connected hardware or software configurations for facilitating or using the edge cloud 810.

[0071] Therefore, the edge cloud 810 is formed from network components and functional features that operate within the network layers 910-930 by edge gateway nodes, edge aggregation nodes, or other edge compute nodes. Thus, the edge cloud 810 can be embodied as any type of network providing edge computing or storage resources located in close proximity to the radio access network (RAN)-enabled endpoint devices described herein (e.g., mobile computing devices, IoT devices, smart devices, etc.). In other words, the edge cloud 810 can be envisioned as an “edge” connecting endpoint devices and conventional network access points, which also provide storage or compute capabilities while acting as an input point to service provider core networks, including mobile carrier networks (e.g., Global Systems for Mobile Communications (GSM®) networks, Long-Term Evolution (LTE) networks, 5G / 6G networks, etc.). Other types and forms of network access (e.g., Wi-Fi® networks including optical networks, long-range wireless networks, wired networks) may also be used instead of, or in combination with, such 3GPP® carrier networks.

[0072] The network components of the Edge Cloud 810 may be servers, multi-tenant servers, appliance computing devices, or any other type of computing device. For example, the Edge Cloud 810 may include an appliance computing device, which is a self-contained electronic device including a housing, chassis, case, or shell. In some situations, the housing may be sized for portability so that it can be transported or carried by a person. An exemplary housing may include materials forming one or more external surfaces that partially or completely protect the contents of the appliance. This protection may include protection against weather, protection against hazardous environments (e.g., EMI, vibration, extreme temperature), and may be submersible. An exemplary housing may include a power circuit for providing power to a stationary or portable implementation. This power circuit may include an AC power input, a DC power input, an AC / DC or DC / AC converter, a power regulator, a transformer, a charging circuit, a battery, a wired input, or a wireless power input. The exemplary housing or its surfaces may include, and may connect to, mounting hardware that enables attachment to structures such as buildings, telecommunications structures (e.g., poles, antenna structures, etc.) or racks (e.g., server racks, blade mounts, etc.). The exemplary housing or its surfaces may support one or more sensors (e.g., temperature sensors, vibration sensors, light sensors, acoustic sensors, capacitive sensors, proximity sensors, etc.). One or more such sensors may be included in the surface, held by the surface, otherwise embedded in the surface, or mounted on the surface of the appliance. The exemplary housing or its surfaces may support mechanical connectivity, such as propulsion hardware (e.g., wheels, propellers, etc.) or articulated hardware (e.g., robotic arms, swivel avenges, etc.). In some situations, sensors may include any type of input device, such as user interface hardware (e.g., buttons, switches, dials, sliders, etc.).In some situations, the exemplary housing includes output devices that are contained within, held within, embedded in, or mounted within such input devices. Output devices may include displays, touchscreens, lighting, LEDs, speakers, I / O ports (e.g., USB), etc. In some situations, edge devices are devices that are displayed in the network for a specific purpose (e.g., traffic lights), but may have processing or other capacities that can be used for other purposes. Such edge devices may be independent of other network devices, may be provided with housing having a form factor suitable for their primary purpose, and may further be available for other computing tasks that do not interfere with their primary task. Edge devices include Internet of Things devices. Appliance computing devices may include hardware and software components for managing local issues such as device temperature, vibration, resource utilization, updates, power issues, physical security, and network security. Exemplary hardware for implementing appliance computing devices is described in conjunction with Figure 13B. The edge cloud 810 may also include one or more servers or one or more multi-tenant servers. Such servers may include an operating system and may implement a virtual computing environment. A virtual computing environment may include a hypervisor that manages (e.g., create, deploy, destroy, etc.) one or more virtual machines, one or more containers, etc. Such a virtual computing environment provides an execution environment within which one or more applications or other software, code, or scripts can be executed while being isolated from one or more other applications, software, code, or scripts.

[0073] In Figure 10, various client endpoints 1010 (in the form of mobile devices, computers, autonomous vehicles, business computing equipment, and industrial processing equipment) exchange requests and responses specific to the type of endpoint network aggregation. For example, a client endpoint 1010 may obtain network access over a wired broadband network by exchanging requests and responses 1022 through an on-premises network system 1032. Some client endpoints 1010, such as mobile computing devices, may obtain network access over a wireless broadband network by exchanging requests and responses 1024 through an access point (e.g., a cellular network tower) 1034. Some client endpoints 1010, such as autonomous vehicles, may obtain network access for requests and responses 1026 over a wireless vehicle network via a road-based network system 1036. However, regardless of the type of network access, the TSP may deploy aggregation points 1042, 1044 within the edge cloud 810 to aggregate traffic and requests. Therefore, within the edge cloud 810, the TSP can deploy various computing and storage resources, for example, at the edge aggregation node 1040, to provide the requested content. The edge aggregation node 1040 and other systems in the edge cloud 810 are connected to the cloud or data center 1060. The cloud or data center 1060 uses the backhaul network 1050 to fulfill higher latency requests from the cloud / data center for websites, applications, database servers, etc. Additional or integrated instances of the edge aggregation node 1040 and aggregation points 1042, 1044, including those deployed on a single server framework, may also exist within the edge cloud 810 or other areas of the TSP infrastructure.

[0074] Figure 11 illustrates the deployment and orchestration of a virtualized container-based edge configuration across an edge computing system using such edge nodes, which can operate across multiple edge nodes and multiple tenants (e.g., users, providers). Specifically, Figure 11 shows the coordination of a first edge node 1122 and a second edge node 1124 within the edge computing system to fulfill requests and responses for various client endpoints 1110 (e.g., smart city / building systems, mobile devices, computing devices, business / logistics systems, industrial systems, etc.) accessing various virtual edge instances. Here, virtual edge instances 1132 and 1134 access the cloud / data center 1140 for higher latency requests for websites, applications, database servers, etc., and provide edge computing capabilities and processing within the edge cloud. However, the edge cloud allows for the coordination of processing across multiple edge nodes for multiple tenants or entities.

[0075] In the example in Figure 11, these virtual edge instances include a first virtual edge 1132 provided to a first tenant (tenant 1) and providing a first combination of edge, storage, compute, and services, and a second virtual edge 1134 providing a second combination of edge, storage, compute, and services. The virtual edge instances 1132 and 1134 are distributed among edge nodes 1122 and 1124. The virtual edge instances 1132 and 1134 may include scenarios in which requests and responses are fulfilled from the same or different edge nodes. The configuration of edge nodes 1122 and 1124 to operate in a distributed yet coordinated manner is performed based on the edge provisioning function 1150. The ability of edge nodes 1122 and 1124 to provide coordinated operation to applications and services across multiple tenants is performed based on the orchestration function 1160.

[0076] It should be understood that some of the devices within 1110 are multitenant devices, in which tenant 1 may operate within tenant 1 “slice,” tenant 2 may operate within tenant 2 slice (and in further examples, additional tenants or subtenants may exist, each tenant further specifically entitled and linked with respect to a particular set of functions with respect to transactions up to specific hardware functions). Trusted multitenant devices may further include tenant-specific cryptographic keys, such that a key-slice combination may be considered a “RoT” or tenant-specific RoT. The RoT may further be configured and dynamically computed using a DICE architecture, so that a single DICE (Device Identification Composition Engine) hardware configuration unit may be used to build layered trusted compute-based contexts (such as field-programmable gate arrays (FPGAs)) for layering device functions. The RoT may further be used in trusted compute contexts to enable “fan-out,” which is useful for supporting multitenancy. Within a multi-tenant environment, each edge node 1122, 1124 can act as a security function enforcement point for local resources allocated to multiple tenants per node. Furthermore, tenant runtimes and application executions (e.g., those on instances 1132, 1134) can act as security function enforcement points, potentially generating virtual edge abstractions of resources spanning multiple physical host platforms. Finally, the orchestration function 1160 in the orchestration entity can act as a security function enforcement point for marshalling resources along tenant boundaries.

[0077] Edge computing nodes may partition their resources (memory, central processing unit (CPU), graphics processing unit (GPU), interrupt controller, input / output (I / O) controller, memory controller, bus controller, etc.). Each partitioning may include RoT functionality, and fan-out and tiering according to the DICE model may be further applied to the edge nodes. Cloud computing nodes often use containers, FaaS engines, servlets, servers, or other compute abstractions that can be partitioned according to the DICE tiering and fan-out structure to support the RoT context. Therefore, each RoT spanning device 1110, 1122, and 1140 may coordinate the establishment of a distributed trusted compute base (DTCB) so that a tenant-specific virtual trusted secure channel can be established that links all elements end-to-end.

[0078] Furthermore, it will be understood that a container may have data or workload-specific keys that protect its contents from the previous edge node. As part of the container migration, the pod controller on the source edge node may obtain the migration key from the target edge node pod controller. The target edge node pod controller uses the migration key to wrap the container-specific key. When the container / pod is migrated to the target edge node, the unwrapping key is exposed to the pod controller that will next decrypt the wrapping key. These keys can then be used to perform actions on the container-specific data. The migration functionality can be gated by appropriately proven edge nodes and pod managers (as described above).

[0079] In a further example, edge computing systems are extended to provide orchestration of multiple applications through the use of containers (deployable units containing software that provides 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 Figure 11. For example, an edge computing system may be configured to fulfill requests and responses for various client endpoints from multiple virtual edge instances (and from the cloud or remote data centers). These virtual edge instances can simultaneously support multiple tenants and multiple applications (e.g., augmented reality (AR) / virtual reality (VR), enterprise applications, content delivery, game computation offload). Furthermore, multiple types of applications (e.g., normal applications, latency-sensitive applications, latency-critical applications, user plane applications, networking applications, etc.) may reside within a virtual edge instance. Also, virtual edge instances may span systems owned by multiple owners in different geographical locations (or each computing system and resource jointly owned or jointly managed by multiple owners).

[0080] For example, each edge node 1122, 1124 may implement the use of containers, for example, with the use of container "pods" 1126, 1128 that provide a group of one or more containers. In a configuration using one or more container pods, a pod controller or orchestrator is responsible for the local control and orchestration of the containers within the pod. Various edge node resources provided for each edge slice 1132, 1134 (e.g., storage, computing services, indicated by hexagons) are partitioned according to the needs of each container.

[0081] Using container pods, the pod controller oversees the partitioning and allocation of containers and resources. The pod controller receives instructions from an orchestrator (e.g., orchestrator 1160) that instructs the controller on how and for how long to best partition physical resources, for example by receiving key performance indicator (KPI) targets based on an SLA agreement. The pod controller determines which containers need which resources and for how long to complete the workload and meet the SLA. The pod controller also manages container lifecycle operations, such as creating containers, provisioning resources and applications, coordinating intermediate results between multiple containers working together on a distributed application, and removing containers when the workload is complete. Furthermore, the pod controller may play a security role, preventing resource allocation until the correct tenant is authenticated, or preventing the provisioning of data or workloads to containers until the proof conditions are met.

[0082] Furthermore, with the use of container pods, tenant boundaries may still exist, but within the context of each pod in the container. If each tenant-specific pod has a tenant-specific pod controller, there may be a shared pod controller that consolidates resource allocation requests to avoid typical resource exhaustion situations. In addition, controls may be provided to ensure the proof and reliability of pods and pod controllers. For example, orchestrator 1160 may provision a proof verification policy to the local pod controller that performs proof verification. If proof satisfies the policy for the first tenant pod controller rather than the second tenant pod controller, the second pod may be migrated to a different edge node that satisfies this policy. Alternatively, the first pod may be made runnable, and a different shared pod controller may be installed and invoked before the second pod runs.

[0083] Figure 12 shows an additional compute deployment with containers deployed within an edge computing system. As a simplified example, system deployments 1210 and 1220 show the configuration. In these configurations, the pod controller (e.g., container managers 1211, 1221) and container orchestrator 1231 are adapted to launch containerized pods, functions, and instances of functions as a service through execution via compute nodes (1215 in deployment 1210), or to separately run containerized virtualized network functions through execution via compute nodes (1223 in deployment 1220). This deployment can be adapted for use by multiple tenants within system deployment 1230 (using compute node 1237). In system deployment 1230, (in addition to running virtualized networking functions), containerized pods (e.g., pod 1212), functions (e.g., functions 1213, VNF 1222, 1236), and instances of functions as a service (e.g., FaaS instance 1214) are launched within virtual machines specific to each tenant (e.g., VMs 1234, 1235 for tenants 1232, 1233). This deployment can be further adapted for use within system deployment 1240 providing containers 1242, 1243, or for running various functions, applications, and features on compute node 1244, as coordinated by the container-based orchestration system 1241.

[0084] The system configuration shown in Figure 12 provides an architecture that treats VMs, containers, and functions equally with respect to application composition (and the resulting applications are combinations of these three components). Each component may involve the use of one or more accelerator (FPGA, ASIC) components as a local backend. In this way, multiple applications may be partitioned across multiple edge owners, which are coordinated by an orchestrator.

[0085] In the context of Figure 12, the pod controller / container manager, container orchestrator, and individual nodes can provide security enforcement points. However, while tenant isolation can be orchestrated if the resources allocated to one tenant are distinct from those allocated to a second tenant, the edge owner must work together to ensure that resource allocations are not shared across tenant boundaries. Alternatively, resource allocations can be isolated across tenant boundaries because tenants can enable "use" through subscriptions or transactions / contracts. In these contexts, virtualization, containerization, enclave, and hardware partitioning schemes can be used by the edge owner to enforce tenancy. Other isolation environments may include bare-metal (dedicated) equipment, virtual machines, containers, virtual machines on containers, or a combination thereof.

[0086] In further examples, software-defined or controlled silicon hardware and other configurable hardware configurations may be integrated with applications, functions, and services by edge computing systems. Software-defined silicon (SDSi) may be used to guarantee the ability of a resource or hardware component to fulfill a contract or service level agreement based on the ability of that component to repair itself or a portion of a workload (e.g., by upgrading, reconfiguring, or provisioning new functionality within the hardware configuration itself).

[0087] In further examples, any compute node or device described with reference to this edge computing system and environment may be realized based on the components shown in Figures 13A and 13B. Each edge compute node may be embodied as a type of device, appliance, computer, or other “thing” capable of communicating with other edge components, networking components, or endpoint components. For example, an edge compute device may be embodied as a personal computer, server, smartphone, mobile compute device, smart appliance, in-vehicle compute system (e.g., navigation system), self-contained device with an outer case, shell, etc., or other device or system capable of performing the described functions.

[0088] In the simplified example shown in Figure 13A, the edge compute node 1300 includes a compute engine (also referred to herein as the “Compute Circuit”) 1302, an input / output (I / O) subsystem 1308, data storage 1310, a communication circuit subsystem 1312, and optionally one or more peripheral devices 1314. In other examples, each compute device may include other or additional components, such as those typically found in a computer (e.g., displays, peripheral devices, etc.). Furthermore, in some examples, one or more of the exemplary components may be incorporated into another component, or otherwise form part of another component.

[0089] The compute node 1300 can be embodied as any type of engine, device, or device assembly capable of performing various computing functions. In some examples, the compute node 1300 can be embodied as a single device, such as an integrated circuit, embedded system, field-programmable gate array (FPGA), system-on-a-chip (SoC), or other integrated system or device. In exemplary examples, the compute node 1300 includes or is embodied as a processor 1304 and memory 1306. The processor 1304 can be embodied as any type of processor capable of performing the functions described herein (e.g., execution of applications). For example, the processor 1304 can be embodied as a multicore processor, microcontroller, processing unit, special or dedicated processing unit, or other processor or processing / control circuit.

[0090] In some examples, the processor 1304 may be embodied, include, or be coupled with an FPGA, an application-specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other specialized hardware that facilitates the performance of the functions described herein. In some examples, the processor 1304 may be embodied as a specialized x-processing unit (xPU), also known as a data processing unit (DPU), infrastructure processing unit (IPU), or network processing unit (NPU). Such an xPU may be integrated within a SoC or embodied as a standalone circuit or circuit package integrated with networking circuitry (e.g., a SmartNIC or enhanced SmartNIC), acceleration circuitry, storage device, or AI hardware (e.g., a GPU or programmed FPGA). Such an xPU may be designed to receive programming, process one or more data streams, and perform specific tasks and actions on these data streams (such as hosting microservices, performing service management or orchestration, organizing or managing server or data center hardware, managing a service mesh, or collecting and distributing telemetry) outside of the CPU or general-purpose processing hardware. However, it will be understood that xPUs, SoCs, CPUs, and other variations of processor 1304 can work together to perform many types of operations and instructions on behalf of compute node 1300 within compute node 1300.

[0091] Memory 1306 can be embodied as any type of volatile memory or data storage (e.g., dynamic random access memory (DRAM)) 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 the data stored in the medium. Non-limiting examples of volatile memory may include various types of random access memory (RAM), such as DRAM or static random access memory (SRAM). One specific type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM).

[0092] 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 crosspoint memory device (e.g., Intel® 3D XPoint® memory) or other byte-addressable, position-write, non-volatile memory devices. The memory device may refer to the die itself or a packaged memory product. In some examples, 3D crosspoint memory (e.g., Intel® 3D XPoint® memory) may include a transistorless, stackable crosspoint architecture in which memory cells are located at the intersections of word lines and bit lines and are individually addressable, and bit storage is based on changes in bulk resistance. In some examples, all or part of memory 1306 may be integrated into processor 1304. Memory 1306 may store various software and data used during operation, such as one or more applications, data, etc., that run on applications, libraries, and drivers.

[0093] The computing circuit 1302 is communicatively coupled to other components of the computing node 1300 via the I / O subsystem 1308. These other components may be embodied as circuits or components that facilitate input / output operations using the computing circuit 1302 (e.g., using the processor 1304 or main memory 1306 and other components of the computing circuit 1302). For example, the I / O subsystem 1308 may be embodied as a memory controller hub, an input / output control hub, an integrated sensor hub, a firmware device, a communication link (e.g., a point-to-point link, a bus link, wires, cables, optical guides, printed circuit board traces, etc.), or other components and subsystems that facilitate input / output operations, or otherwise may include these. In some examples, the I / O subsystem 1308 may form part of a system-on-a-chip (SoC) and may be integrated into the computing circuit 1302 together with one or more of the processor 1304, memory 1306 and other components of the computing circuit 1302.

[0094] One or more exemplary data storage devices 1310 may be embodied as any type of device configured for short-term or long-term storage of data, such as memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. Each data storage device 1310 may include a system partition for storing data and firmware code for the data storage device 1310. Each data storage device 1310 may also include one or more operating system partitions for storing data files and executable files for the operating system, depending on the type of compute node 1300, for example.

[0095] The communication circuit 1312 can be embodied as any communication circuit, device, or collection thereof (e.g., an edge gateway in an implemented edge computing system) that can enable network-based communication between the computing circuit 1302 and another computing device. The communication circuit 1312 can be configured to achieve such communication using any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., cellular networking protocols such as 3GPP® 4G or 5G standards, wireless local area network protocols such as IEEE 802.11 / Wi-Fi®, wireless wide area network protocols, IoT protocols such as Ethernet®, Bluetooth®, Bluetooth Low Energy, IEEE 802.15.4 or ZigBee®, or low-power wide area network (LPWAN) or low-power wide area (LPWA) protocols, etc.).

[0096] An exemplary communication circuit 1312 includes a network interface controller (NIC) 1320, which may also be referred to as a host fabric interface (HFI). The NIC 1320 may be embodied as one or more add-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices (e.g., edge gateway nodes) that can be used by the compute node 1300 to connect to other computing devices. In some examples, the NIC 1320 may be embodied as part of a system-on-a-chip (SoC) including one or more processors, or it may be included in a multi-chip package also including one or more processors. In some examples, the NIC 1320 may include a local processor (not shown) or local memory (not shown), both of which are local to the NIC 1320. In such examples, the local processor of the NIC 1320 may perform one or more of the functions of the compute circuit 1302 described herein. Furthermore, or alternatively, in such examples, the local memory of the NIC1320 may be integrated into one or more components of the client compute node at the board level, socket level, chip level, or other levels.

[0097] Furthermore, in some examples, each compute node 1300 may include one or more peripheral devices 1314. Such peripheral devices 1314 may include any type of peripheral device found within a compute device or server, such as audio input devices, displays, other input / output devices, interface devices, or other peripheral devices, depending on the specific type of compute node 1300. In further examples, the compute node 1300 may be embodied by each edge compute node in an edge computing system (whether it be a client node, gateway node, or aggregation node) or by a similar form of appliance, computer, subsystem, circuit or other component.

[0098] In a more detailed example, Figure 13B shows a block diagram of an example of components that may reside within an edge computing node 1350 for implementing the technologies described herein (e.g., operations, processes, methods, and methodologies). When implemented as or as part of a computing device (e.g., a mobile device, base station, server, gateway, etc.), the edge computing node 1350 provides a closer view of each component of node 1300. The edge computing node 1350 may include any combination of the hardware or logical components referenced herein, and may include any device usable with an edge communication network or a combination of such networks, and may be coupled with any such device. These components may be implemented as integrated circuits (ICs), their individual parts, separate electronic devices or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or combinations thereof adapted within the edge computing node 1350, or as components otherwise integrated into the chassis of a larger system.

[0099] The edge computing device 1350 may include processing circuitry in the form of a processor 1352. The processor 1352 may be a microprocessor, a multicore processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, an xPU / DPU / IPU / NPU, a dedicated processing unit, a special processing unit, or other known processing element. The processor 1352 and other components may be part of a system-on-a-chip (SoC) formed within a single integrated circuit or within a single package such as an Edison® or Galileo® SoC substrate of Intel Corporation in Santa Clara, California. As an example, the processor 1352 may include an Intel® Architecture Core®-based CPU processor such as a Quark®, Atom®, i3, i5, i7, i9, or MCU-class processor, or another such processor available from Intel®. However, any number of other processors may be used, including MIPS-based designs from Advanced Micro Devices, Inc. (AMD®) of Sunnyvale, California, MIPS® Technologies, Inc. of Sunnyvale, California, ARM-based designs licensed from ARM® Holdings, Ltd., or those available from their customers, licensees, or adopters. These processors may include units such as Apple® Inc.'s A5-A13 processors, Qualcomm® Technologies, Inc.'s Snapdragon® processors, or Texas Instruments, Inc.'s OMAP® processors. The processor 1352 and associated circuitry may be supplied in a variety of other formats, including a single-socket form factor, a multi-socket form factor, or one or more limited hardware configurations containing fewer elements than all of those shown in Figure 13B.

[0100] The processor 1352 may communicate with system memory 1354 via an interconnect 1356 (e.g., a bus). A given amount of system memory may be provided using any number of memory devices. For example, memory 1354 may be random access memory (RAM) in accordance with the design of the Japan Electronics Technology Council (JEDEC), such as DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In a particular example, the memory component may conform to DRAM standards published by JEDEC, such as DDR SDRAM for JESD79F, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low-power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4. Such standards (and similar standards) are sometimes referred to as DDR-based standards, and the communication interface of storage devices implementing such standards is sometimes referred to as a DDR-based interface. In various implementations, individual memory devices may be in any number of different package types, such as single-die packages (SDP), dual-die packages (DDP), or quad-die packages (Q17P). 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 consequently connect to the motherboard via a given connector. Any number of other memory implementations may be used, such as other types of memory modules, including, but not limited to, different types of dual in-line memory modules (DIMMs), including microDIMM or MiniDIMM.

[0101] For example, to provide persistent storage of information such as data, applications, and operating systems, storage 1358 may also be coupled to processor 1352 via interconnect 1356. In one example, storage 1358 may be implemented via a solid-state disk drive (SSDD). Other devices that may be used for storage 1358 include, for example, flash memory cards such as Secure Digital (SD) cards, microSD cards, and eXtreme Digital (XD) picture cards, and Universal Serial Bus (USB) flash drives. In one example, the memory device may be chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase-change memory (PCM), resistive random-access memory, nanowire memory, ferroelectric transistor random-access memory (FeTRAM), antiferroelectric memory, magnetoresistive random-access memory (MRAM) incorporating memristor technology, memory devices using resistive random-access memory including metal oxide groups, oxygen vacancy groups, and conductive bridge random-access memory (CB-RAM) or spin-transfer torque (STT)-MRAM, spintronic magnetic junction memory-based devices, magnetic tunnel junction (MTJ)-based devices, DW (domain wall) and SOT (spin-orbit transfer) transfer-based devices, thyristor-based memory devices, or any combination of the above, or other memories, and may include them.

[0102] In low-power implementations, storage 1358 may be on-die memory or registers associated with processor 1352. However, in some examples, storage 1358 may be implemented using a microhard disk drive (HDD). Furthermore, in addition to, or instead of, the described technologies such as resistive random-access memory, phase-change memory, holographic memory, or chemical memory, any number of new technologies may be used for storage 1358.

[0103] These components may communicate via interconnect 1356. Interconnect 1356 may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extension (PCIx), PCI Express (PCIe), or any number of other technologies. Interconnect 1356 may be, for example, a proprietary bus used in SoC-based systems. Other bus systems may include, in particular, inter-integrated circuit (I2C) interfaces, serial peripheral interfaces (SPI), point-to-point interfaces, and power buses.

[0104] The interconnect 1356 can couple the processor 1352 to the transceiver 1366 for communication with the connected edge device 1362. The transceiver 1366 can use any number of frequencies and protocols, including 2.4 gigahertz (GHz) transmission based on the IEEE 802.15.4 standard, using, among other things, the Bluetooth® low energy (BLE) standard or the ZigBee standard as defined by the Bluetooth® Special Interest Group. Any number of radios configured for a specific wireless communication protocol can be used to connect to the connected edge device 1362. For example, a wireless local area network (WLAN) unit can be used to implement Wi-Fi® communication in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. In addition, wireless wide-area communication, for example, cellular or other wireless wide-area protocols can be performed via a wireless wide-area network (WWAN) unit.

[0105] A wireless network transceiver 1366 (or multiple transceivers) may communicate using multiple standards or radios for communication at different ranges. For example, an edge computing node 1350 may conserve power by using a local transceiver based on Bluetooth Low Energy (BLE) or another low-power radio to communicate with nearby devices, for example, within about 10 meters. A more distant connected edge device 1362, for example, within about 50 meters, may be reached via ZigBee® or other intermediate-power radios. Both communication techniques may be performed over a single radio at different power levels, or over multiple separate transceivers, for example, a local transceiver using BLE and separate mesh transceivers using ZigBee®.

[0106] A wireless network transceiver 1366 (e.g., a wireless transceiver) may be included to communicate with a device or service in the cloud (e.g., edge cloud 1395) via a local area network protocol or wide area network protocol. The wireless network transceiver 1366 may, among other things, be a low-power wide-area (LPWA) transceiver conforming to the IEEE 802.15.4 or IEEE 802.15.4g standard. The edge computing node 1350 may communicate over a wide area using LoRaWAN® (Long-Range Wide Area Network), developed by Semtech and the LoRa Alliance. The technologies described herein are not limited to these technologies but may be used in conjunction with any number of other cloud transceivers and other technologies that implement long-range low-bandwidth communication, such as Sigfox. Furthermore, other communication technologies, such as time-slot channel hopping as described in the IEEE 802.15.4e specification, may be used.

[0107] As described herein, in addition to the systems referred to with respect to the wireless network transceiver 1366, any number of other wireless communications and protocols may be used. For example, transceiver 1366 may include a cellular transceiver that uses spread spectrum (SPA / SAS) communication to implement high-speed communication. Furthermore, any number of other protocols may be used, such as Wi-Fi® networks for providing network communication and for medium-speed communication. Transceiver 1366 may include radios compatible with any number of 3GPP® (Third Generation Partnership Project) specifications, such as Long-Term Evolution (LTE) communication systems and fifth-generation (5G) communication systems, as described in more detail at the end of this disclosure. A network interface controller (NIC) 1368 may be included to provide wired communication to nodes of the edge cloud 1395 or to other devices such as connected edge devices 1362 (for example, operating in a mesh). Wired communication may provide Ethernet® connectivity, but may also be based on other types of networks, including, among many others, Controller Area Network (CAN), Local Interconnection Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET. Additional NICs 1368 may be included to enable connectivity to a second network, for example, a first NIC 1368 providing communication to the cloud via Ethernet® and a second NIC 1368 providing communication to other devices via another type of network.

[0108] Given that there are various types of applicable communication from a device to another component or network, the applicable communication circuit used by the device may include, or be embodied by, one or more of components 1364, 1366, 1368, or 1370. Thus, in various examples, means for applicable communication (e.g., receiving, transmitting, etc.) may be embodied by such communication circuit.

[0109] The edge computing node 1350 may include or be coupled to the acceleration circuit 1364. The acceleration circuit 1364 may be embodied by one or more artificial intelligence (AI) accelerators, neural computing sticks, neuromorphic hardware, FPGAs, arrangements of multiple GPUs, arrangements of multiple xPUs / DPUs / IPUs / NPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuits designed to perform 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, or rule analysis. These tasks may also include certain edge computing tasks related to service management and service operations as described elsewhere in this specification.

[0110] The interconnect 1356 may connect the processor 1352 to a sensor hub or external interface 1370 used to connect additional devices or subsystems. These devices may include sensors 1372 such as accelerometers, level sensors, flow sensors, optical sensors, camera sensors, temperature sensors, global navigation system (e.g., GPS) sensors, pressure sensors, and barometric pressure sensors. The hub or interface 1370 may further be used to connect the edge computing node 1350 to actuators 1374 such as power switches, valve actuators, audible sound generators, and visual warning devices.

[0111] In some optional examples, various input / output (I / O) devices may reside within or be connected to the edge computing node 1350. For example, a display or other output device 1384 may be included to show information such as sensor readings or actuator positions. An input device 1386, such as a touchscreen or keypad, may be included to accept input. Output devices 1384 may include any number of forms of audio or visual displays. These displays may include simple visual outputs such as binary status indicators (e.g., light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display screens (e.g., liquid crystal display (LCD) screens), where outputs such as characters, graphics, and multimedia objects are generated or arise from the operation of the edge computing node 1350. Display or console hardware in the context of this system may be used to manage components or services of the edge computing system by providing outputs and receiving inputs of the edge computing system, to identify the state of edge computing components or edge computing services, or to perform any number of other management or administration functions or service use cases.

[0112] Battery 1376 can power the edge computing node 1350, but in examples where the edge computing node 1350 is mounted in a fixed location, it may have a power supply coupled to the electrical grid and may be used as a backup or for temporary functions. Battery 1376 may be a lithium-ion battery or a metal-air battery such as a zinc-air battery, aluminum-air battery and lithium-air battery.

[0113] To track the charge state (SoCh) of battery 1376 (if included), the edge computing node 1350 may include a battery monitor / charger 1378. The battery monitor / charger 1378 may be used to monitor other parameters of battery 1376 to provide failure prediction, such as the health (SoH) and functionality (SoF) of battery 1376. The battery monitor / charger 1378 may include a battery monitoring integrated circuit, such as an IC from Linear Technologies' LTC4020 or LTC2990, ON Semiconductor's ADT7488A in Phoenix, Arizona, or Texas Instruments' UCD90xxx family in Dallas, Texas. The battery monitor / charger 1378 may transmit information about battery 1376 to processor 1352 via interconnect 1356. The battery monitor / charger 1378 may also include an analog-to-digital (ADC) converter, which allows processor 1352 to directly monitor the voltage of battery 1376 or the current from battery 1376. Battery parameters can be used to determine the actions that the edge computing node 1350 can perform, such as transmission frequency, mesh network operation, and sensing frequency.

[0114] To charge battery 1376, a power block 1380, or another grid-coupled power source, may be coupled with the battery monitor / charger 1378. In some examples, power may be obtained wirelessly, for example, through a loop antenna in an edge computing node 1350, by replacing the power block 1380 with a wireless power receiver. The battery monitor / charger 1378 may include a wireless battery charging circuit, such as the LTC4020 chip from Linear Technologies of Milpitas, California, among others. The specific charging circuit may be selected based on the size of battery 1376 and, therefore, the current required. Charging may be performed using, among others, the Airfuel standard published by the Airfuel Alliance, the Qi wireless charging standard published by the Wireless Power Consortium, or the Rezence charging standard published by the Alliance for Wireless Power.

[0115] Storage 1358 may include instructions 1382 in the form of software commands, firmware commands, or hardware commands for implementing the techniques described herein. Although such instructions 1382 are shown as code blocks contained in memory 1354 and storage 1358, it can be understood that any of the code blocks may be replaced, for example, by hardwired circuits embedded in an application-specific integrated circuit (ASIC).

[0116] In one example, an instruction 1382 provided via memory 1354, storage 1358, or processor 1352 may be embodied as a non-temporary machine-readable medium 1360 containing code for instructing processor 1352 to perform electronic operations within edge computing node 1350. Processor 1352 may access the non-temporary machine-readable medium 1360 via interconnect 1356. For example, the non-temporary machine-readable medium 1360 may be embodied by a device described for storage 1358, and may include a specific storage unit such as an optical disc, flash drive, or any number of other hardware devices. The non-temporary machine-readable medium 1360 may contain instructions for instructing processor 1352 to perform a specific sequence or flow of actions, as described with respect to the flowcharts and block diagrams of operations and functions shown above. As used herein, the terms “machine-readable medium” and “computer-readable medium” are interchangeable. Furthermore, in specific examples, instruction 1382 on processor 1352 may constitute the execution or operation of a trusted execution environment (TEE) 1390 (either separately or in combination with instruction 1382 on machine-readable medium 1360). In one example, TEE 1390 operates as a protected area accessible to processor 1352 for secure execution of instructions and secure access to data. Various implementations of TEE 1390 and associated secure areas within processor 1352 or memory 1354 may be provided, for example, through the use of Intel® Software Guard Extensions (SGX) or ARM® TrustZone® hardware security extensions, Intel® Management Engine (ME), or Intel® Converged Security Manageability Engine (CSME). Security hardening, hardware trust bases, and other aspects of trusted or protected operation may be implemented within device 1350 through TEE 1390 and processor 1352.

[0117] Figure 14 shows an exemplary software distribution platform 1405 for distributing software, such as the exemplary computer-readable instruction set 1482 in Figure 14, to one or more devices, such as an exemplary processor platform 1400 or connected edge devices. The exemplary software distribution platform 1405 may be implemented by any computer server, data facility, cloud service, etc., that can store and transmit software to other computing devices (e.g., third parties or connected edge devices). The exemplary connected edge devices may be customers, clients, management devices (e.g., servers), or third parties (e.g., customers of the entity that owns or operates the software distribution platform 1405). The exemplary connected edge devices may operate in a commercial or home automation environment. In some examples, the third party is the developer, seller, or licensor of the software, such as the exemplary computer-readable instruction set 1482 in Figure 14. The third party may be a consumer, user, retailer, OEM, etc., who purchases or licenses the software for use, resale, or sublicense. In some examples, the distributed software causes one or more user interface (UI) or graphical user interface (GUI) displays to identify one or more geographically or logically separated devices (e.g., connected edge devices) (e.g., physically isolated, leased IoT devices responsible for water supply control (e.g., pumps), power distribution control (e.g., relays), etc.).

[0118] In the example shown in Figure 14, the software distribution platform 1405 includes one or more servers and one or more storage devices. The storage devices store computer-readable instructions 1482. The computer-readable instructions 1482 may correspond to exemplary computer-readable instructions shown in the figure and described herein. One or more servers of the exemplary software distribution platform 1405 communicate with a network 1410. The network 1410 may correspond to the Internet or one or more of the exemplary networks described herein. In some examples, one or more servers respond to requests to transmit software to requesting parties as part of a commercial transaction. Payment for the distribution, sale, or licensing of the software may be handled by one or more servers of the software distribution platform or through a third-party payment entity. The servers enable purchasers or licensors to download computer-readable instructions 1482 from the software distribution platform 1405. For example, software that may correspond to the exemplary computer-readable instructions described herein may be downloaded to an exemplary processor platform 1400 (e.g., an exemplary connected edge device) that executes the computer-readable instructions 1482 and implements the technology. In some examples, one or more servers of the software distribution platform 1405 are communicably connected to one or more security domains or security devices through which requests and transmissions of exemplary computer-readable instructions 1482 must be passed. In some examples, one or more servers of the software distribution platform 1405 ensure that improvements, patches, updates, etc., are distributed to and applied to the software on end-user devices by periodically providing, transmitting, or enforcing updates to the software (e.g., exemplary computer-readable instructions 1482 in Figure 14).

[0119] In the example shown in Figure 14, the computer-readable instruction 1482 is stored in a specific format on the storage device of the software distribution platform 1405. The format of the computer-readable instruction may include, but is not limited to, a specific code language (e.g., Java®, JavaScript®, Python, C, C#, SQL, HTML, etc.) or a specific code state (e.g., uncompiled code (e.g., ASCII), interpreted code, linked code, executable code (e.g., binary), etc.). In some examples, the computer-readable instruction 1482 stored on the software distribution platform 1405 is in a first format when transmitted to an exemplary processor platform 1400. In some examples, the first format is an executable binary that a particular type of processor platform 1400 can run on. However, in some examples, the first format is uncompiled code that requests one or more preparatory tasks to convert the first format to a second format to enable execution on the exemplary processor platform 1400. For example, the receiving processor platform 1400 may need to compile the computer-readable instruction 1482 into a first format to generate executable code in a second format that can be executed on the processor platform 1400. In yet another example, the first format is interpreted code that, upon reaching the processor platform 1400, is interpreted by an interpreter to facilitate instruction execution.

[0120] Figure 15 shows a flowchart of an example of Method 1500 for network flow-based hardware allocation according to one embodiment. The operation of Method 1500 is performed by computing hardware, such as those described above or below (e.g., processing circuits).

[0121] In operation 1505, the workload is acquired for execution. Here, the workload includes a flow. The flow includes processing components and network components.

[0122] In operation 1510, the workload is executed. While the workload is running, operations 1515 and 1520 are repeated until the workload is finished.

[0123] In operation 1515, the flow is profiled to determine the network metrics of the network component and the processing metrics of the processing component. In one example, profiling is performed at predefined time intervals. In one example, profiling is performed in response to an event. In one example, profiling is performed when a query about the flow or workload is received.

[0124] In one example, profiling involves tagging the communication of a flow using a network service with identification information. This identification information can then be mapped to the flow. In one example, the identification information is a tuple containing the source address, source port, destination port, or communication type.

[0125] In one example, profiling updates the interface profile and ranking database. In one example, entries in the interface profile and ranking database are 30 bits long. In one example, interfaces are ranked in the interface profile and ranking database by flow. Here, assigning network services and processing services to flows in the next execution based on network metrics and processing metrics includes selecting the interface with the highest rank for the flow. In one example, interfaces are ranked based on the combination of flow and the processing service selected for the flow.

[0126] In operation 1520, network services and processing services are assigned to a flow in the next execution based on network metrics and processing metrics. In one example, the network service is a network interface card (NIC). In another example, the network service is a channel or virtual channel. In another example, the network service or processing service is hardware partitioning.

[0127] In one example, assigning network services based on network metrics involves selecting network services that have the minimum network metric required to satisfy the network components of a flow. In one example, the network metric could be bandwidth or latency.

[0128] In one example, assigning network services and processing services involves selecting network services that have the minimum network metrics necessary to satisfy the maximum output related to the processing service's network metrics.

[0129] Figure 16 shows a block diagram of an exemplary machine 1600 in which one or more of the techniques (e.g., methodologies) described herein may be implemented. The examples described herein may include, and may operate by, logic or multiple components or mechanisms within the machine 1600. A circuit (e.g., a processing circuit) is a collection of circuits implemented on the tangible entities of the machine 1600, including hardware (e.g., simple circuits, gates, logic, etc.). Circuit components may be flexible over time. A circuit includes members that can perform a specified operation at runtime, either individually or in combination. In one example, the hardware of a circuit may be designed to perform a particular operation (e.g., hardwired). In one example, the hardware of a circuit may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a machine-readable medium (e.g., a magnetically or electrically movable arrangement of particles of invariant mass, etc.) that is physically modified to encode instructions for a particular operation. When physical components are connected, the underlying electrical properties of the hardware components are changed, for example, from an insulator to a conductor, or vice versa. Instructions allow embedded hardware (e.g., an execution unit or load mechanism) to generate members of circuits within the hardware via variable connections to execute a specific part of the operation during operation. Thus, in one example, a machine-readable medium element is part of a circuit or is communicatively coupled to other components of a circuit when the device is operating. In one example, any of the physical components may be used in more than one member of more than one circuit. For example, during operation, an execution unit may be used at one point in time in a first circuit of a first circuit configuration, and at a different point in time by a second circuit in the first circuit configuration, or by a third circuit in a second circuit configuration. Additional examples of these components relating to machine 1600 are described below.

[0130] In alternative embodiments, machine 1600 may operate as a standalone device or be connected to other machines (e.g., network-connected). In a network-connected deployment, machine 1600 may operate as a server machine, a client machine, or both in a server-client network environment. For example, machine 1600 may function as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Machine 1600 may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify the actions to be taken by that machine. Furthermore, although only a single machine is shown, the term “machine” shall also be interpreted to include any set of machines that individually or collectively execute one or more sets of instructions to perform any one or more of the methodologies described herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.

[0131] The machine (e.g., a computer system) 1600 may include a hardware processor 1602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 1604, static memory (e.g., memory or storage for firmware, microcode, basic input / output (BIOS), unified expansion firmware interface (UEFI), etc.) 1606, and mass storage 1608 (e.g., a hard drive, tape drive, flash storage, or other block devices), some or all of which may communicate with each other via an interlink (e.g., a bus) 1630. The machine 1600 may further include a display unit 1610, an alphanumeric input device 1612 (e.g., a keyboard), and a user interface (UI) navigation device 1614 (e.g., a mouse). In one example, the display unit 1610, the input device 1612, and the UI navigation device 1614 may be touchscreen displays. The machine 1600 may further include a storage device (e.g., a drive unit) 1608, a signal generating device 1618 (e.g., a speaker), a network interface device 1620, and one or more sensors 1616 such as a Global Positioning System (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 1600 may also include an output controller 1628, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near-field communication (NFC), etc.) connection) for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0132] The registers of the processor 1602, main memory 1604, static memory 1606, or mass storage 1608 may be a machine-readable medium 1622 storing one or more sets of data structures or instructions 1624 (e.g., software) that embody or utilize one or more of the technologies or functions described herein, and may include such a machine-readable medium 1622. Furthermore, the instructions 1624 may reside entirely or at least partially within the registers of the processor 1602, main memory 1604, static memory 1606, or mass storage 1608 during their execution by the machine 1600. In one example, one or any combination of the hardware processor 1602, main memory 1604, static memory 1606, or mass storage 1608 may constitute the machine-readable medium 1622. Although machine-readable medium 1622 is shown as a single medium, the term “machine-readable medium” may include a single or multiple mediums configured to store one or more instructions 1624 (e.g., a centralized or distributed database or associated cache and server).

[0133] The term “machine-readable medium” can include any medium capable of storing, encoding, or carrying instructions for execution by machine 1600, and causing machine 1600 to execute one or more of the technologies of the Disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting machine-readable mediums may include solid-state memory, optical mediums, magnetic mediums, and signals (e.g., radio frequency signals, other photon-based signals, sound signals, etc.). In one example, a non-temporary machine-readable medium is a composition, comprising a machine-readable medium having a plurality of particles having constant (e.g., stationary) mass. Thus, a non-temporary machine-readable medium is a machine-readable medium that does not contain a transient propagation signal. Specific examples of non-temporary machine-readable media may include semiconductor memory devices (e.g., non-volatile memory such as electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices), magnetic disks such as internal hard disks and removable disks, magneto-optical disks, CD-ROM disks, and DVD-ROM disks.

[0134] In one example, information stored in or otherwise provided in the machine-readable medium 1622 may represent an instruction 1624, which may be the instruction 1624 itself or a format from which the instruction 1624 can be derived. This format from which the instruction 1624 can be derived may include source code, encoded instructions (e.g., in a compressed or encrypted form), or packaged instructions (e.g., divided into multiple packages). The information representing the instruction 1624 in the machine-readable medium 1622 may be processed by a processing circuit to implement any of the operations described herein to become an instruction. For example, deriving an instruction 1624 from this information (e.g., processing by a processing circuit) may include compiling this information into an instruction 1624 (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, decrypting, packaging, unpackaging, or otherwise manipulating this information.

[0135] In one example, the derivation of instruction 1624 may involve the assembly, compilation, or interpretation (e.g., by a processing circuit) of information for generating instruction 1624 from some intermediate or pre-processed format provided by a machine-readable medium 1622. If the information is provided in multiple parts, it may be combined, unpacked, and modified to generate instruction 1624. For example, the information may be multiple compressed source code packages (or object code or binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted when moving over the network, and if necessary, they may be decrypted, uncompressed, assembled (e.g., linked), compiled or interpreted on the local machine (e.g., into a library, a standalone executable, etc.), and executed by the local machine.

[0136] Instruction 1624 may further be transmitted or received via a communication network 1626 using a transmission medium via a network interface device 1620 that utilizes one of several transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Illustrative communication networks may include, among others, local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), LoRa / LoRaWAN or satellite communication networks, cellular networks (e.g., cellular networks such as those conforming to 3G, 4G LTE / LTE-A, or 5G standards), basic telephone (POTS) networks, and wireless data networks (e.g., the IEEE 802.11 standard family known as Wi-Fi®, the IEEE 802.16 standard family known as WiMAX®, and the IEEE 802.15.4 standard family), and peer-to-peer (P2P) networks. In one example, the network interface device 1620 may include one or more physical jacks (e.g., Ethernet® jacks, coaxial jacks, or telephone jacks) or one or more antennas) for connecting to the communication network 1626. In one example, the network interface device 1620 may include multiple antennas for wireless communication using at least one of single-input multiple-output (SIMO) technology, multiple-input multiple-output (MIMO) technology, or multiple-input single-output (MISO) technology. The term “transmission medium” is to be interpreted as including any intangible medium on which instructions for execution by machine 1600 can be stored, encoded, or carried, including digital or analog communication signals or other intangible mediums to facilitate the communication of such software. The transmission medium is a machine-readable medium. [Additional notes and examples]

[0137] Example 1 is a device for network flow-based hardware allocation, comprising a machine-readable medium having instructions and a processing circuit, wherein the processing circuit is configured in operation by the instructions to acquire a workload for execution, the workload comprising a flow, the flow comprising processing components and network components; repeatedly, during the execution of the workload, profile the flow in runtime to determine network metrics of the network components and processing metrics of the processing components; and assign network services and processing services to the flow in the next execution based on the network metrics and processing metrics.

[0138] In Example 2, the network service is a network interface card (NIC), as described in Example 1.

[0139] In Example 3, the network service is a channel, virtual channel, or bandwidth slice, as described in any of Examples 1 or 2.

[0140] In Example 4, the processing circuit is configured to perform the task of selecting a network service that includes the minimum network metric necessary to satisfy the network component of the flow, as described in any of Examples 1 to 3, in order to assign the network service based on the network metric.

[0141] In Example 5, the network metric is bandwidth or latency, as described in Example 4.

[0142] In Example 6, the processing circuit is configured to select a network service that includes the minimum network metric to satisfy the maximum output associated with the network metric of the processing service, as described in any of Examples 1 to 5.

[0143] In Example 7, the network service or the processing service is a hardware partition, as described in any of Examples 1 to 6.

[0144] In Example 8, the subject according to any one of Examples 1 to 7, the processing circuit is configured to tag the communication of the flow using the network service with identification information and to map the identification information to the flow, in order to profile the flow.

[0145] In Example 9, the identification information is a tuple containing a source address, source port, destination port, or communication type, as described in Example 8.

[0146] In Example 10, the processing circuit is configured to perform profiling of the flow in response to an event or upon receipt of a query at a predetermined time interval, as described in any of Examples 1 to 9.

[0147] In Example 11, the processing circuit is configured to perform updating interface profiles and ranking databases in order to profile the flow, as described in any of Examples 1 to 10.

[0148] In Example 12, the interface profile and entries in the ranking database are 30 bits in length, as described in Example 11.

[0149] In Example 13, interfaces are ranked by flow in the interface profile and ranking database, and the processing circuit is configured to select the interface having the highest rank for the flow in order to assign the network service and the processing service to the flow in the next execution based on the network metric and the processing metric, as described in any of Examples 11 to 12.

[0150] In Example 14, the interface is ranked based on the combination of the flow and the processing service selected for the flow, as described in Example 13.

[0151] Example 15 is a method for network flow-based hardware allocation, comprising the steps of: acquiring a workload for execution, wherein the workload includes a flow, the flow includes processing components and network components; repeatedly profiling the flow during execution of the workload to determine network metrics for the network components and processing metrics for the processing components; and allocating network services and processing services to the flow in subsequent executions based on the network metrics and processing metrics.

[0152] In Example 16, the network service is a network interface card (NIC), as described in Example 15.

[0153] In Example 17, the network service is a channel, virtual channel, or bandwidth slice, as described in any of Examples 15 to 16.

[0154] In Example 18, the step of assigning the network service based on the network metric includes the step of selecting a network service that includes the minimum network metric necessary to satisfy the network component of the flow, as described in any of Examples 15 to 17.

[0155] In Example 19, the network metric is bandwidth or latency, as described in Example 18.

[0156] In Example 20, the step of allocating the network service and the processing service includes the step of selecting a network service that includes the minimum network metric to satisfy the maximum output related to the network metric of the processing service, as described in any of Examples 15 to 19.

[0157] In Example 21, the network service or the processing service is a hardware partition, as described in any of Examples 15 to 20.

[0158] In Example 22, the profiling step comprises the steps of tagging identification information to the communication of the flow using the network service and mapping the identification information to the flow, as described in any one of Examples 15 to 21.

[0159] In Example 23, the identification information is a tuple containing a source address, source port, destination port, or communication type, as described in Example 22.

[0160] In Example 24, the profiling step is performed at predefined time intervals, in response to events, or upon receipt of queries, and pertains to any subject described in Examples 15 to 23.

[0161] In Example 25, the profiling step involves updating the interface profile and ranking database, as described in any of Examples 15 through 24.

[0162] In Example 26, the interface profile and entries in the ranking database are 30 bits in length, as described in Example 25.

[0163] In Example 27, the interface is ranked by the flow in the interface profile and ranking database, and the step of assigning network services and processing services to the flow in the next execution based on the network metrics and processing metrics includes the step of selecting the interface having the highest rank for the flow, as described in any of Examples 25 to 26.

[0164] In Example 28, the interface is ranked based on the combination of the flow and the processing service selected for the flow, as described in Example 27.

[0165] Example 29 is at least one machine-readable medium comprising instructions for network flow-based hardware assignment, wherein, when executed by a processing circuit, the instructions include acquiring a workload for execution, the workload comprising a flow, the flow comprising processing components and network components; repeatedly profiling the flow in runtime during the execution of the workload to determine network metrics for the network components and processing metrics for the processing components; and assigning network services and processing services to the flow in subsequent executions based on the network metrics and processing metrics.

[0166] In Example 30, the network service is a network interface card (NIC), as described in Example 29.

[0167] In Example 31, the network service is a channel, virtual channel, or bandwidth slice, as described in any of Examples 29 to 30.

[0168] In Example 32, the step of assigning the network service based on the network metric includes the step of selecting a network service that includes the minimum network metric necessary to satisfy the network component of the flow, as described in any of Examples 29 to 31.

[0169] In Example 33, the network metric is bandwidth or latency, as described in Example 32.

[0170] In Example 34, the step of allocating the network service and the processing service includes the step of selecting the network service which includes the minimum network metric to satisfy the maximum output related to the network metric of the processing service, as described in any of Examples 29 to 33.

[0171] In Example 35, the network service or the processing service is a hardware partition, as described in any of Examples 29 to 34.

[0172] In Example 36, the profiling step comprises the steps of tagging identification information to the communication of the flow using the network service and mapping the identification information to the flow, as described in any one of Examples 29 to 35.

[0173] In Example 37, the identification information is a tuple containing a source address, source port, destination port, or communication type, as described in Example 36.

[0174] In Example 38, the profiling step is performed at predefined time intervals, in response to events, or upon receipt of queries, and is based on the subject described in any of Examples 29 to 37.

[0175] In Example 39, the profiling step involves updating the interface profile and ranking database, as described in any of Examples 29 through 38.

[0176] In Example 40, the interface profile and entries in the ranking database are 30 bits in length, as described in Example 39.

[0177] In Example 41, the interface is ranked by the flow in the interface profile and ranking database, and the step of assigning network services and processing services to the flow in the next execution based on the network metrics and processing metrics includes the step of selecting the interface having the highest rank for the flow, as described in any of Examples 39 to 40.

[0178] In Example 42, the interface is ranked based on the combination of the flow and the processing service selected for the flow, as described in Example 41.

[0179] Example 43 is a system for network flow-based hardware allocation, comprising means for acquiring a workload for execution, wherein the workload includes a flow, the flow includes processing components and network components; application means for repeatedly profiling the flow during execution of the workload to determine network metrics of the network components and processing metrics of the processing components; and application means for assigning network services and processing services to the flow in subsequent executions based on the network metrics and processing metrics.

[0180] In Example 44, the network service is a network interface card (NIC), as described in Example 43.

[0181] In Example 45, the network service is a channel, virtual channel, or bandwidth slice, as described in any of Examples 43 to 44.

[0182] In Example 46, the means for assigning the network service based on the network metric includes means for selecting a network service that includes the minimum network metric necessary to satisfy the network component of the flow, as described in any of Examples 43 to 45.

[0183] In Example 47, the network metric is bandwidth or latency, as described in Example 46.

[0184] In Example 48, the means for assigning the network service and the processing service includes means for selecting a network service that includes a minimum network metric to satisfy the maximum output related to the network metric of the processing service, as described in any of Examples 43 to 47.

[0185] In Example 49, the network service or the processing service is a hardware partition, as described in any of Examples 43 to 48.

[0186] In Example 50, the means for profiling comprises means for tagging identification information to communications of the flow using the network service, and means for mapping the identification information to the flow, as described in any one of Examples 43 to 49.

[0187] In Example 51, the identification information is a tuple containing a source address, source port, destination port, or communication type, as described in Example 50.

[0188] In Example 52, the profiling step is performed at predefined time intervals, in response to events, or upon receipt of queries, on subjects as described in any of Examples 43 to 51.

[0189] In Example 53, the profiling step involves updating the interface profile and ranking database, as described in any of Examples 43 through 52.

[0190] In Example 54, the interface profile and entries in the ranking database are 30 bits in length, as described in Example 53.

[0191] In Example 55, interfaces are ranked by flow in the interface profile and ranking database, and the means for assigning network services and processing services to the flow in the next execution based on the network metrics and processing metrics includes means for selecting the interface having the highest rank for the flow, as described in any one of Examples 53 to 54.

[0192] In Example 56, the interface is ranked based on a combination of the flow and the processing service selected for the flow, as described in Example 55.

[0193] Example 57 is at least one machine-readable medium comprising instructions that cause the processing circuit to perform an operation to implement any of Examples 1 to 56 when executed by the processing circuit.

[0194] Example 58 is a device that includes means for implementing any of Examples 1 to 56.

[0195] Example 59 is a system for implementing any of Examples 1 through 56.

[0196] Example 60 is a method for implementing any of Examples 1 through 56.

[0197] The above detailed description includes references to accompanying drawings, which form part of the detailed description. The drawings illustrate specific embodiments that may be implemented. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those illustrated or described. However, the inventors also envision examples in which only the illustrated or described elements are provided. Furthermore, the inventors also envision examples relating to specific examples (or one or more embodiments thereof) or other examples (or one or more embodiments thereof) illustrated or described herein using any combination or substitution of the illustrated or described elements (or one or more embodiments thereof).

[0198] All publications, patents, and patent documents referenced herein are incorporated herein by reference, as if they were individually incorporated by reference. In the event of any inconsistency between the usage herein and the documents incorporated by reference, the usage in the incorporated reference documents should be considered supplementary to the usage herein, and in the event of any irreconcilable inconsistency, the usage herein shall prevail.

[0199] In this specification, the terms “a” or “an” are used to include one or more, regardless of any other examples or uses of “at least one” or “one or more,” as is common in patent literature. Unless otherwise stated, in this specification, the term “or” is used to refer to non-exclusive or such that “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 which” are used as plain English equivalents of the terms “comprising” and “wherein.” Furthermore, in the following claims, the terms “including” and “in which” are non-limiting; that is, a system, device, article or process that includes elements in addition to those enumerated after such terms in a claim is still considered to be within the scope of that claim. Furthermore, 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 respective subjects.

[0200] The above description is intended to be illustrative, not restrictive. For example, the above examples (or one or more of them) may be used in combination with each other. In consideration of the above description, those skilled in the art may use other embodiments. The abstract is submitted with the understanding that it is intended to allow the reader to quickly confirm the nature of this technical disclosure and is not to be used to interpret or limit the claims or their meaning. Also, in the embodiments for carrying out the invention described above, various features may be grouped together in order to simplify the disclosure. This should not be interpreted as meaning that any disclosed features not described in the claims are essential to any claim. Rather, the subject matter of the invention may be found in fewer features than all of the features of a particular disclosed embodiment. Accordingly, the following claims are hereby incorporated into embodiments for carrying out the invention, with each claim standing independently as a separate embodiment. The scope of the embodiments should be determined with reference to the appended claims, along with the entire scope of equivalents to which such claims are granted. [Other adjacent items] (Item 1) A device for network flow-based hardware allocation, A machine-readable medium containing instructions, Processing circuit and Equipped with, The aforementioned processing circuit is Acquiring a workload for execution, wherein the workload includes a flow, and the flow includes processing components and network components. During the execution of the said workload, repeatedly, During execution, the flow is profiled to determine the network metrics of the network component and the processing metrics of the processing component, Based on the aforementioned network metrics and processing metrics, the following execution will assign network services and processing services to the flow: The instruction is configured to perform the following during operation: Device. (Item 2) The network service is a channel, virtual channel, or bandwidth slice, as described in item 1. (Item 3) The apparatus according to item 1, wherein, in order to assign the network service and the processing service, the processing circuit is configured to select a network service that includes the minimum network metric to satisfy the maximum output associated with the network metric of the processing service. (Item 4) To profile the aforementioned flow, the processing circuit, Tag identification information with the communication of the flow using the aforementioned network service, Mapping the aforementioned identification information to the aforementioned flow Configured to perform, The device described in item 1. (Item 5) The apparatus according to item 1, wherein the processing circuit is configured to perform updating of interface profiles and ranking databases in order to profile the aforementioned flow. (Item 6) The interface profile and entries in the ranking database are 30 bits in length, as described in item 5 for the device. (Item 7) The apparatus according to item 5, wherein interfaces are ranked in the interface profile and ranking database by flow, and the processing circuit is configured to select the interface having the highest rank for the flow in order to assign the network service and the processing service to the flow in the next execution based on the network metric and the processing metric. (Item 8) The interface is ranked based on a combination of the flow and a processing service selected for the flow, as described in item 7. (Item 9) A method for network flow-based hardware allocation, A step of acquiring a workload for execution, wherein the workload includes a flow, and the flow includes processing components and network components. During the execution of the said workload, repeatedly, The steps include profiling the flow at runtime to determine the network metrics of the network component and the processing metrics of the processing component, The next step in the execution is to assign network services and processing services to the flow based on the network metrics and processing metrics. A method that includes [a certain feature]. (Item 10) The method according to item 9, wherein the network service is a channel, virtual channel, or bandwidth slice. (Item 11) The method according to item 9, wherein the step of allocating the network service and the processing service includes the step of selecting a network service that includes the minimum network metric to satisfy the maximum output related to the network metric of the processing service. (Item 12) The aforementioned profiling stage is A step of tagging identification information to the communication of the flow using the aforementioned network service, The step of mapping the aforementioned identification information to the aforementioned flow Having, The method described in item 9. (Item 13) The profiling step described above is the method described in item 9, which updates the interface profile and ranking database. (Item 14) The interface profile and entries in the ranking database are 30 bits in length, as described in item 13. (Item 15) The method according to item 13, wherein interfaces are ranked by flow in the interface profile and ranking database, and the step of assigning network services and processing services to the flow in the next execution based on the network metrics and processing metrics includes the step of selecting the interface having the highest rank for the flow. (Item 16) The method according to item 15, wherein the interface is ranked based on a combination of the flow and the processing service selected for the flow. (Item 17) A machine-readable medium comprising instructions for network flow-based hardware allocation, wherein the instructions, when executed by a processing circuit, Acquiring a workload for execution, wherein the workload includes a flow, and the flow includes processing components and network components. During the execution of the said workload, repeatedly, During execution, the flow is profiled to determine the network metrics of the network component and the processing metrics of the processing component, Based on the aforementioned network metrics and processing metrics, the following execution will assign network services and processing services to the flow: The processing circuit is made to perform an operation that includes the following: At least one machine-readable medium. (Item 18) The network service is at least one machine-readable medium as described in item 17, which is a channel, virtual channel, or bandwidth slice. (Item 19) Assigning the network service and the processing service comprises selecting the processing network service which includes the minimum network metric to satisfy the maximum output related to the network metric of the processing service, as described in item 17, for at least one machine-readable medium. (Item 20) The aforementioned profiling is, Tag identification information with the communication of the flow using the aforementioned network service, Mapping the aforementioned identification information to the aforementioned flow Having, At least one machine-readable medium as described in item 17. (Item 21) The profiling described above involves updating the interface profile and ranking database in at least one machine-readable medium as described in item 17. (Item 22) The interface profile and entries in the ranking database are in at least one machine-readable medium as described in item 21, with a length of 30 bits. (Item 23) The interface is ranked by flow in the interface profile and ranking database, and assigning network services and processing services to the flow in the next execution based on the network metrics and processing metrics comprises selecting the interface having the highest rank for the flow, in at least one machine-readable medium as described in item 21. (Item 24) The interface is ranked based on a combination of the flow and a processing service selected for the flow, and is at least one machine-readable medium as described in item 23.

Claims

1. A device for network flow-based hardware allocation, A machine-readable medium containing instructions, Processing circuit and Equipped with, The processing circuit executes the instruction, Acquiring a workload for execution, wherein the workload includes a flow, and the flow includes processing components and network components. During the execution of the said workload, repeatedly, During the execution of the aforementioned flow, the flow is profiled to determine the network metrics of the network component and the processing metrics of the processing component. Based on the network metrics and processing metrics, network resources and processing resources are allocated to the next flow to be executed. Configured to perform, Device.

2. The apparatus according to claim 1, wherein the network resource is a network interface card (NIC).

3. The apparatus according to claim 1 or 2, wherein the network resource is a channel, a virtual channel, or a bandwidth slice.

4. The apparatus according to any one of claims 1 to 3, wherein, in order to allocate the network resources based on the network metric, the processing circuit is configured to perform the task of selecting a network resource that includes the minimum network metric necessary to satisfy the network components of the flow.

5. To profile the aforementioned flow, the processing circuit, Tag identification information with the communication of the flow using the aforementioned network resources, Mapping the aforementioned identification information to the aforementioned flow Configured to perform, The apparatus according to any one of claims 1 to 4.

6. The apparatus according to any one of claims 1 to 5, wherein the processing circuit is configured to perform updating of interface profiles and ranking databases in order to profile the flow.

7. The apparatus according to claim 6, wherein the interface profile and entries in the ranking database are 30 bits in length.

8. The apparatus according to claim 6 or 7, wherein interfaces are ranked in the interface profile and ranking database by flow, and the processing circuit is configured to select the interface having the highest rank for the flow in order to allocate the network resources and processing resources to the flow to be executed next, based on the network metrics and the processing metrics.

9. The apparatus according to claim 8, wherein the interface is ranked based on a combination of the flow and processing resources selected for the flow.

10. A method that a processing circuit performs for network flow-based hardware allocation, A step of acquiring a workload for execution, wherein the workload includes a flow, and the flow includes processing components and network components. During the execution of the said workload, repeatedly, The steps include: profiling the flow during its execution to determine the network metrics of the network component and the processing metrics of the processing component; Based on the network metrics and processing metrics, the next step is to allocate network resources and processing resources to the flow to be executed. A method that includes [a certain feature].

11. The method according to claim 10, wherein the network resource is a network interface card (NIC).

12. The method according to claim 10 or 11, wherein the network resource is a channel, a virtual channel, or a bandwidth slice.

13. The method according to any one of claims 10 to 12, wherein the step of allocating the network resource based on the network metric includes the step of selecting a network resource that includes the minimum network metric necessary to satisfy the network component of the flow.

14. The method according to claim 13, wherein the network metric is bandwidth or latency.

15. The method according to any one of claims 10 to 14, wherein the step of allocating the network resources and the processing resources includes the step of selecting a network resource that includes a minimum network metric to satisfy the maximum output related to the network metric of the processing resource.

16. The method according to any one of claims 10 to 15, wherein the network resource or the processing resource is a hardware partition.

17. The aforementioned profiling stage is A step of tagging identification information with the communication of the flow using the aforementioned network resources, The step of mapping the aforementioned identification information to the aforementioned flow Having, The method according to any one of claims 10 to 16.

18. The method according to claim 17, wherein the identification information is a tuple including a source address, a source port, a destination port, or a communication type.

19. The method according to any one of claims 10 to 18, wherein the profiling step is performed at a predetermined time interval, in response to an event, or upon receipt of a query.

20. The method according to any one of claims 10 to 19, wherein the profiling step updates the interface profile and ranking database.

21. The method according to claim 20, wherein the interface profile and entries in the ranking database are 30 bits in length.

22. The method according to claim 20 or 21, wherein interfaces are ranked in the interface profile and ranking database by flow, and the step of allocating network resources and processing resources to the next flow to be executed, based on the network metrics and processing metrics, includes the step of selecting the interface having the highest rank for the flow.

23. The method according to claim 22, wherein the interface is ranked based on a combination of the flow and the processing resources selected for the flow.

24. A computer program comprising an instruction that, when executed by a processing circuit, causes the processing circuit to execute the method according to any one of claims 10 to 23.

25. A system comprising means for carrying out the method described in any one of claims 10 to 23.

26. At least one machine-readable medium for storing the computer program according to claim 24.

Images