CN114697362B - Cognitive edge processing for internet of things - Google Patents

Abstract

The application discloses cognitive edge processing for the Internet of things. In one embodiment, an apparatus comprises circuitry, wherein the circuitry is configured to: transmitting first context information of a first edge device to one or more second edge devices via a communication network, wherein the first context information identifies an operating environment of the first edge device based on information from one or more sensors; receiving, via the communication network, second context information for the one or more second edge devices, wherein the second context information identifies an operating environment of the one or more second edge devices based on information from one or more sensors; and performing a network management function based on the first context information and the second context information.

Description

Cognitive edge processing for internet of things

The invention relates to a patent application, which is a divisional application of the invention patent application with the international application number of PCT/US2016/040898, the international application date of 2016, 7 months and 2 days, and the application number of 201680086343.1 entering the national stage of China, namely 'cognitive edge treatment for the Internet of things'.

Technical Field

The present disclosure relates generally to the field of computer systems, and more particularly to cognitive edge processing for the internet of things.

Background

The internet has allowed different computer networks to be interconnected worldwide. While internet connectivity was previously limited to conventional general purpose computing systems, an increasing number and type of products are being redesigned to accommodate connectivity to other devices over computer networks, including the internet. For example, smartphones, tablet computers, wearable devices, and other mobile computing devices have become popular, even replacing larger, more traditional general purpose computing devices, such as traditional desktop computers in recent years. Tasks traditionally performed on general purpose computers are increasingly being performed using mobile computing devices with smaller form factors and more constrained feature sets and operating systems. Furthermore, traditional appliances and devices are becoming "more intelligent" as they are ubiquitous and equipped with functionality to connect to the internet or consume content from the internet. For example, devices (such as televisions, gaming systems, home appliances, thermostats, automobiles, watches) have been equipped with network adapters to allow the device to connect with the internet (or another device) either directly or through a connection to another computer connected to the network. In addition, this ever-increasing range of interconnection devices has also prompted the proliferation of computer-controlled sensors that are likewise interconnected and collect new and large data sets. It is believed that the interconnection of an increasing number of devices (or "things") is predictive of a new era of advanced automation and interconnectivity, which is sometimes referred to as the internet of things (IoT).

Drawings

Fig. 1 illustrates an example embodiment of a communication system.

Fig. 2 illustrates a simplified block diagram of a cognitive edge device.

Fig. 3 illustrates an example embodiment of a cognitive edge device.

Fig. 4 illustrates a flow chart of an example embodiment for cognitive edge processing.

FIG. 5 illustrates an example embodiment of a centralized resource orchestration agent.

FIG. 6 illustrates an example embodiment of a distributed resource orchestration agent.

FIG. 7 illustrates an example embodiment of a federated resource orchestration agent.

FIG. 8 illustrates a flow chart of an example embodiment for a resource orchestration agent.

Fig. 9 illustrates a block diagram of an example embodiment of a processor.

FIG. 10 illustrates a block diagram of an example embodiment of a computing system.

Detailed description of exemplary embodiments

Fig. 1 illustrates an example embodiment of a communication system 100. Communication system 100 includes edge device 120, network 140, and cloud service 180. Edge devices 120 include various devices deployed at the "edge" of communication system 100, including sensor and/or actuator devices 105, end user devices 130 (e.g., mobile devices, laptops), resource broker (brooker) 160, and gateway 170. The edge device 120 may communicate with other remote networks and/or services (e.g., cloud services 180) to connect to the internet through a back-have network, such as Wide Area Network (WAN) 140 a.

The sensor/actuator devices 105 of the edge device 120 may include one or more types of sensors (e.g., 110) and/or actuators (e.g., 115) and other resources (such as processors, storage, power, and/or communication functions) that may be used and utilized within the machine-to-machine (M2M) or internet of things (IoT) communication system 100. For example, the sensor/actuator device 105 may include a computer processor and/or a communication interface to allow interoperability with other edge devices 120 (e.g., end user devices 130, agents 160, and/or gateways 170) or network services (e.g., cloud services 180, ioT management services 190) as needed (e.g., if these devices are not in proximity to the gateway 170).

The sensor 110 of each device 105 may include an internal sensor and/or an external sensor. The internal sensors 110 (also referred to as "soft" sensors) may be configured to sense or monitor contextual information related to the internal operating environment of the device 105 itself, such as processor usage, device workload, memory capacity, battery capacity, network usage, internal temperature (e.g., heating of the processor), software security alarms, software errors and anomalies, and other attributes and events. External sensors 110 (also referred to as hardware or physical sensors) may be configured to detect, measure, and generate sensor data describing characteristics and contextual information of the external operating environment in which device 105 resides. For example, a given sensor 110 may be configured to detect contextual information of the device 105, such as movement, weight, physical contact, temperature, wind, noise, light, computer communications, wireless signals, location, humidity, presence of radiation, liquids or specific compounds, and several other examples. Indeed, the device sensor 110 as described herein contemplates a potentially infinite range of various sensors, each designed to detect and generate corresponding sensor data for new and unknown operating environment characteristics.

The actuator 115 of each device 105 is a component configured to perform a specific action that affects the device environment. For example, the device (e.g., 105b, d) may include an actuator 115 that accepts input and performs a corresponding action in response. The actuators may include a controller for activating additional functions, such as an actuator for selectively switching power or operation of an alarm, a camera (or other sensor), a heating-ventilation-air conditioning (HVAC) appliance, a home appliance, an on-board device, and/or a light, among other examples.

As described above, the sensors 110 and actuators 115 of the device 105 may be incorporated into an internet of things (IoT) and/or machine-machine (M2M) system. IoT or M2M systems (both used interchangeably herein) may refer to new or improved ad-hoc (ad-hoc) systems and networks composed of a number of different devices that cooperate to deliver one or more results, services, or deliverables. As more and more products and equipment evolve to become "intelligent," such ad hoc systems are emerging, meaning that they are controlled and/or monitored by computing processors and equipped with facilities for communicating with other computing devices (and products having network communication capabilities) through computer-implemented mechanisms. For example, ioT systems may include networks established from sensors and communication modules integrated in or attached to "objects" such as equipment, toys, tools, vehicles, and even living things (e.g., plants, animals, people). The sensor and/or actuator device 105 may be a "green field" ("greenfield") device that developed IoT capabilities from scratch, or a "brown field" ("brownfield") device created by integrating IoT capabilities into existing legacy devices that did not originally develop IoT capabilities. In some instances, ioT systems may evolve, either organized or unexpected, in which a set of sensors monitor various contextual attributes of their operating environment, which are then interconnected with a data analysis system and/or a system controlling one or more other intelligent devices to implement various novel use cases and applications. Furthermore, ioT systems may be formed from devices that are not initially in relationship or communication with each other, wherein the systems are automatically configured (e.g., according to IoT applications that define or control interactions) either spontaneously or in operation. Furthermore, ioT systems often may be composed of a complex and diverse set of connected devices (e.g., edge devices 120), such as devices powered or controlled by various groups of entities and employing various hardware, operating systems, software applications, and technologies.

Facilitating successful interoperability of such diverse systems, as well as other example considerations, is an important issue when building or defining IoT systems. A software application may be developed to manage how a set of IoT devices may interact to achieve a particular goal or service. In some cases, ioT devices may not initially be built or initially not intended to participate in such services or cooperate with one or more other types of IoT devices. Indeed, a part of the promise of the internet of things is that as such devices become more popular and new "smart" devices or "connected" devices emerge, innovations in many areas will create new applications involving a wide variety of IoT device groups.

As shown in the example of fig. 1, ioT system 100 may include various IoT edge devices 120, including sensor/actuator devices 105, end user devices 130, resource broker 160, and/or gateway 170, among other examples. For example, ioT devices 120 may include such examples as: mobile personal computing devices (e.g., 130 a) (such as smart phones or tablet devices), wearable computing devices (e.g., smart watches, smart apparel, smart glasses, smart helmets, headphones, etc.), smaller conventional computer-enhanced products (such as houses, buildings, and vehicle automation devices (e.g., intelligent heating-ventilation-air conditioning (HVAC) controllers and sensors, light detection and control, and energy management tools)), smart appliances (e.g., smart televisions, smart refrigerators, etc.), among other examples. Some devices may be purposefully built into host sensors and/or actuator resources (i.e., a "green field" device), such as weather sensor devices including multiple sensors associated with weather monitoring (e.g., temperature sensors, wind sensors, humidity sensors, etc.), traffic sensors and controllers, as well as many other examples. Some devices may be statically positioned (such as devices installed in a building, devices installed on a lamppost, sign, water tower, devices fixed to the ground (e.g., indoor or outdoor), or other fixed or static structures). Other devices may be mobile (such as sensors preset inside or outside of the vehicle, sensors within the package (e.g., for tracking cargo), wearable devices worn by active human users or animals, and/or aerial, ground-based, or underwater drones, among other examples). Indeed, it may be desirable for certain sensors to move within an environment, and applications may be built around use cases involving mobile devices, mobile users, and/or changing environments.

Continuing with the example of fig. 1, an IoT management platform 190 may be provided to allow developers and end users to build and configure IoT applications and systems. IoT applications may provide software support to organize and manage the operation of a set of IoT devices for a particular purpose or use case. In some cases, the IoT application may be embodied as an application on the operating system of the user computing device (e.g., laptop computer 130 b); a mobile application for execution on a smart phone, tablet, smart watch, or other mobile device (e.g., 130 a); and/or an IoT application on another edge device (e.g., gateway 170). In some cases, the IoT management system 190 may provision one or more deployed devices in an IoT system with the appropriate IoT application(s).

In some cases, ioT applications may utilize a special or generic management utility or management tool 190 that allows a user to configure settings and policies to manage how a set of devices (e.g., ioT edge devices 120) operate when deployed in an IoT system. IoT management utility 190 may also be used to select which IoT devices are to be used with a particular IoT application. In other cases, a dedicated IoT management application may be provided that may manage a potential plurality of different IoT applications or systems. The IoT management utility 190 or system may be hosted on a single system, such as a single server system (e.g., 180) or a single device (e.g., 105, 130, 160, 170), or alternatively, the IoT management system may be distributed across multiple hosting devices at the edge (e.g., 180, 105, 130, 160, 170).

In some cases, the IoT systems may interface (through a corresponding IoT management system or application, or through one or more of the participating IoT devices) with remote services (such as data storage, information services (e.g., media services, weather services), geographic location services, and computing services (e.g., data analysis, search, diagnostics, etc.) hosted in the cloud-based system and other remote systems. For example, ioT systems may be connected to remote services through one or more networks 140. In some cases, the remote service itself may be considered an asset to IoT applications and systems. Data received by the remotely hosted service may be consumed by one or more of the managed IoT applications and/or component IoT devices to cause one or more results or actions to be performed, and so on.

The one or more networks 140 may facilitate communication between IoT devices 120 and other remote networks or services (such as cloud services 180 and/or IoT management services 190) to enable or manage IoT applications and devices. Such networks may include wired and/or wireless local networks, public networks, wide area networks, broadband cellular networks, the internet, and the like. In some implementations, one or more gateway devices 170 may be utilized to facilitate communication with IoT devices 120 (e.g., sensor/actuator devices 105 and end user devices 130) within a given IoT system 100 or communication between IoT devices 120. For example, gateway 170 may be utilized to extend the geographic scope of IoT systems to provide a mechanism to communicate with IoT devices (e.g., sensors/actuators 105) that possess limited or dedicated communication capabilities, or to form a subset of devices within an IoT system deployment. For example, in some cases, gateway 170 may extend the range of IoT devices that are configured with short-range communication capabilities (e.g., bluetooth, zigBee devices) by providing those IoT devices with their native communication capabilities and providing the backhauls to the cloud over Wi-Fi, ethernet, cellular, and/or any other wired or wireless communication medium.

With the development of IoT devices and systems, there are an increasing number of smart devices and connected devices available in the marketplace (such as devices that can be used in home automation, factory automation, smart agriculture, and other IoT applications and systems). For example, in home automation systems, the automation of a home typically increases as more IoT devices are added for sensing and controlling additional aspects of the home. However, as the number and variety of devices increases, the management of "things" (or devices contained in IoT systems) becomes extremely complex and challenging.

Furthermore, ioT systems are generating unprecedented large and diverse amounts of data. Existing IoT edge devices typically offload this data to the cloud for processing and/or storage. However, existing cloud-based services are not adapted to the rapidly growing amount, variety, and speed of IoT data. Cloud-based services may not be ideal in certain situations, such as when processing time-sensitive data or highly confidential data, or when faced with network bandwidth constraints, and so forth. For example, when time sensitive data eventually reaches the cloud for analysis, opportunities for action on this data may have already passed.

In some embodiments, "edge" processing may be used to remedy the inadequacies of cloud-based processing (e.g., when cloud-based processing is inefficient, and/or unsafe), better process the growing amount, variety, and speed of IoT data, and conserve network and internet resources. Edge processing is a way to process certain IoT data at (near) the network edge, where the data is generated, rather than simply pooling large amounts of data into the cloud for processing and storage. In some cases, processing IoT data near the source of the IoT data rather than in the cloud may improve performance and avoid system failures or disasters. Edge processing may also conserve network bandwidth, which is particularly beneficial when faced with bandwidth constraints and/or limited network connectivity. However, some data may still be sent to the cloud for historical analysis and long term storage. Edge processing may be referred to as "misting" because they are used to spread the "cloud" to the edge of the network, thereby forming a "mist" on the edge of the network. The mist may be considered a large-scale interconnected network, where a large number of IoT devices 120 communicate with each other, e.g., over radio links. In some embodiments, this may be done using the open interconnect alliance (OIC) standard specification 1.0 published by the open connectivity foundation ^TM (OCF) at 12, 23, 2015. The standard allows devices to discover each other and establish communication for interconnection. Another protocol that may be used in smart homes and similar deployments is Thread, a networking protocol for internet of things (IoT) "smart" home automation devices, which has been developed by an organization alliance named "Thread Group". Other interconnection protocols may also be used including, for example, the Optimal Link State Routing (OLSR) protocol, or better ways to mobile ad hoc networking (b.a.t.m.a.n.), and so forth.

In some embodiments, edge device 120 may be implemented with cognitive edge processing capabilities to facilitate intelligent network management decisions. The cognitive edge device 120 may detect and utilize contextual information about its operating environment based on information from the sensors 110, other edge devices 120 (e.g., end user devices 130, agents 160, gateways 170), cloud services 180, and/or other network resources. This context information of edge device 120 may be used for various purposes including cognitive edge processing and service delivery, resource orchestration, and/or intelligent network configuration. The cognitive edge device 120 may utilize the context information, for example, to decide where (e.g., cloud or edge) the data should be processed and/or stored, and by which network entities (e.g., gateway 170, end user device 130, cloud 190) the data should be processed and stored. These cognitive decisions may be based on, for example, contextual information about the data that needs to be processed (e.g., type, amount, and/or age of the data), expected response time, network resource availability and bandwidth constraints, the ability to meet service delivery requirements (e.g., from Service Level Agreements (SLAs) or other service delivery specifications), availability and health of edge devices 120 (e.g., gateway 170, end user devices 130), availability and health of cloud services 190, physical location of edge devices 120, and other examples. The cognitive edge devices 120 may include any type of edge devices, components, and/or nodes that leverage cognitive and/or context-aware processing capabilities (e.g., local or edge-based data aggregation, processing, and storage capabilities), including gateways 170, proxies 160 (or other orchestration nodes), end-user computing devices 130, sensor/actuator devices 105, local servers, edge servers, and edge (or mist) IoT applications, among other examples. In some embodiments, the cognitive edge device 120 may be formed from a plurality of interconnected edge devices 120 that operate effectively as a single device. For example, if the context information of the edge device 120 indicates that its resources are insufficient, the edge device may be interconnected with one or more additional edge devices such that the edge device 120 then includes the edge device when multiple interconnected edge devices.

In some embodiments, the awareness and/or context aware edge processing capabilities may also be utilized by resource orchestration agent 160. For example, the resource broker 160 may provide resource orchestration and workload distribution services for the edge devices 120 managed by the broker 160. The resource broker 160 may use the context information from the cognitive edge device 120 to make intelligent workload distribution decisions that maximize performance and ensure service delivery. The resource broker 160 may be implemented as a standalone edge device, as functionality in an existing edge device, and/or as functionality distributed across multiple edge devices and/or network components. In some embodiments, the resource broker 160 itself may be the cognitive edge device 120.

In some embodiments, cognitive and/or context-aware edge processing capabilities may also be utilized to provide intelligent IoT configurations and deployments, including, for example, autonomic gateway 170 configurations. In some embodiments, the deployment, configuration, and management of IoT systems may be significantly improved by facilitating the cognitive context aware edge devices 120 of autonomous network configuration and management, which significantly reduces human intervention and labor required in complex and evolving IoT systems. For example, ioT management and applications may employ an paradigm in which the systems may autonomously configure and deploy (and redeploy) IoT systems using contextual information about the operating environment of cognitive IoT devices 120 and intelligently manage IoT systems with minimal human intervention, rather than being programmed and/or configured to operate with particular IoT devices 120 and/or cloud services 180 in a static environment and/or use case. For example, the context aware gateways 170 may autonomously configure themselves based on their use cases and context information about their operating environments, thereby autonomously updating this configuration as their operating environments and/or use cases change.

In some embodiments, the IoT management system 190 may be used to facilitate autonomous configuration and/or deployment of IoT devices and applications (such as the IoT gateway 170). For example, the IoT management system 190 may utilize asset abstraction to simplify IoT device configuration and deployment procedures. For example, a user may simply select a use case, class, or classification of IoT device 120 and logically assemble a set of select device classes to establish and/or deploy at least a portion of an IoT system or application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). Indeed, in some cases, the use cases of a particular IoT device or application may be automatically determined based on context information from the IoT device 120 (such as the context-aware IoT gateway 170).

In addition to facilitating autonomous and efficient IoT network management, the context-aware IoT devices 120 may also improve the resiliency of IoT systems, which are often expected to provide a high level of reliability and resiliency. Indeed, in some implementations, such characteristics may be critical, where increased failure of IoT systems may even result in costly damage or even potential loss of life. Providing such reliability and resiliency in IoT systems can be challenging, particularly given the dynamic and evolving nature of IoT systems, the number and diversity of devices in IoT systems, and the mobility and changing environment of IoT devices. Especially in large IoT systems (with dozens or hundreds of devices) managing the health and reliability of each device can be overly complex for human administrators. Continued failure of a single device may lead to failure of the entire system. Managing a large number of potential failure points can be daunting. Indeed, given the potential variety of devices (and device manufacturers), certain devices may be expected to have a higher level of inherent elasticity and reliability than others. Furthermore, since many devices may be powered by batteries, the trustworthiness of the various power sources may also be a factor in how individual devices and collective IoT systems perform.

In one implementation, a scalable system management framework for an elastic internet of things (IoT) system is provided that facilitates the ability of IoT devices 120 (e.g., gateway 170) to dynamically adapt to changes in the system (e.g., battery level changes, microprocessor idle time, network topology, device workload changes, etc.) and do so in a distributed and cost-effective manner. Furthermore, the system management framework may improve system flexibility at both the system level and the device level by enabling automated self-repair and self-optimization of the system. For example, self-healing may be achieved by continuously collecting the operating state of individual component devices and causing them to restart or reset as appropriate. This self-healing action may be performed at the device level. Self-healing may involve executing tasks and processes on a device to return the device to its healthy operating state. Furthermore, given the collection of operational states in the background, the framework can utilize machine learning techniques to derive meaning from the data and learn patterns within the system. Based on this learning, a model can be developed that can be used to prescribe actions for restarting or reconfiguring components individually, or to reconfigure all or part of the system as a whole. Reconfiguration may refer to making operational changes to applications/services running on a given device within an IoT system. Redeployment may refer to moving an application/service from a device to other nearby but compatible devices (e.g., replacing a device in an IoT system with other compatible devices, etc.), or alternatively to a device that moves to a new operating environment.

Reliability of an IoT system may refer to the reliability of the system in delivering a desired result or outcome in the face of intrinsic influencing factors. System resiliency may refer to the ability of a system to maintain an acceptable level of service regardless of runtime challenges (such as hardware and software failures, communication interruptions, security threats, or other external issues). In some cases, elasticity may contemplate that the system maintains a degraded but acceptable level of service.

As IoT systems become increasingly difficult to manage in scale and dynamics, the flexibility of IoT systems becomes increasingly important, particularly in implementations seeking to push out economically viable IoT solutions on a large scale. Many conventional IoT solutions have proven to be susceptible to real world conditions. For example, the static nature and unreliable operation of certain current IoT technologies in dynamic and challenging operating environments makes certain IoT deployments cost prohibitive (thereby somewhat impeding future attempts to employ similar systems in certain situations).

In some embodiments, an improved management framework may be implemented by utilizing telemetry to remotely monitor the physical context and conditions of each device (e.g., resource utilization from the device's sensors and actuators, environmental sensor observations, and instrumentation) to ensure that the proper operating environment of the device is maintained. In some instances, such monitoring may enable possible self-repair and self-optimization. Further, through resource abstraction, devices within a particular use case, class, or category may be handled indifferently in applications and systems. Thus, in such implementations, ioT devices and applications may be automatically configured, deployed, and redeployed as they are written and stored to specify only resource requirements (by corresponding applications or taxonomies) without specific identity information for each deployed device. Further, machine learning tasks for enhancing elasticity and reliability in a system may be distributed such that deployed devices use data local to the devices to process at least a portion of the tasks. This may facilitate expansion of the system with an improved management framework.

As described above and further explained throughout the following figures, the cognitive and/or context aware device 120 may provide many benefits in IoT systems, including improved performance and service delivery, intelligent resource orchestration, and/or intelligent network configuration.

In general, the systems, servers, clients, computing devices, network elements, hosts, end-user devices 130, sensor/actuator devices 105, and/or any other IoT edge devices 120 or network services (e.g., cloud services 180, ioT management services 190) in the example IoT system 100 may include electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with the IoT system 100. As used herein, the terms "computer," "processor device," or "processing device" are intended to encompass any suitable processing device. For example, elements shown as a single device within IoT system 100 may be implemented with multiple computing devices and processors, such as a server pool with multiple server computers. Moreover, any, all, or some of the computing devices may be adapted to execute any operating system (including Linux, UNIX, microsoft Windows, apple MacOS, apple iOS, valley singer, windows servers, etc.) and virtual machines adapted to virtualize the execution of particular operating systems (including custom and proprietary operating systems).

Systems, such as those shown and illustrated herein, may include machine logic implemented in hardware and/or software, and/or machine logic embodied in a computer readable medium to implement the solutions described throughout this disclosure.

Although fig. 1 is described as containing or being associated with a plurality of elements, not all of the elements shown within communication system 100 of fig. 1 may be used in each alternative implementation of the present disclosure. Furthermore, one or more of the elements described in connection with the example of fig. 1 may be located external to communication system 100, while in other embodiments, particular elements may include or be part of one or more of the other elements described, as well as other elements not described in the example implementation. Moreover, the particular elements shown in FIG. 1 may be combined with other components, as well as used for alternative or additional purposes other than those described herein.

Fig. 2 illustrates a simplified block diagram 200 of a cognitive edge device 220. In some embodiments, the cognitive edge device 220 may be similar to the cognitive edge device 120 of fig. 1.

Existing (non-cognitive) edge devices have limited utility such as simple data aggregation tasks and static methods of operation. For example, existing IoT gateway solutions are primarily used to aggregate data from IoT sensors and devices without any cognitive processing or analysis of this data. These existing IoT gateways follow static methods of operation that lack platform, network, and data awareness. IoT systems are pushing the need for wireless edge network infrastructure to handle large data closer to its source, to enable and guarantee real-time operation (e.g., for time sensitive data), and to avoid access network bottlenecks that may result from pooling (funneling) large amounts of data into the cloud. For example, cognitive features are needed on IoT edge devices (e.g., ioT gateways) to implement management policies for data storage, processing and transmission, workload distribution, and autonomic network configuration between edge devices in an IoT system. The solutions described throughout this disclosure enable cognitive features (e.g., platform aware, network aware, and data aware) of IoT gateways and other edge devices (such as cognitive edge device 220) to allow context-aware decisions regarding data storage, processing and transmission, workload distribution, and network configuration.

In the illustrated embodiment, the cognitive edge device 220 includes an operating system 230, sensors 210, a cognitive module 221, and interfaces 240a-e. The cognitive edge device 220 may be any type of edge device (i.e., deployed at an "edge" of a network), component, and/or node that is enhanced with cognitive and/or context-aware processing capabilities (e.g., local or edge-based data aggregation, processing, and storage capabilities), including gateways, proxies (or other orchestration nodes), end-user computing devices (e.g., mobile devices, laptops), sensor/actuator devices, local servers, edge servers, and edge (or fog) IoT applications, among other examples. In some embodiments, the cognitive edge device 220 may be implemented as a physical device or as a virtual machine running on a physical device. The cognitive features of the cognitive edge device 220 may be, for example, a set of functions implemented in a physical device (e.g., gateway or other edge device), a microcontroller unit (MCU), a router with a virtual machine running the gateway, a Field Programmable Gate Array (FPGA) in a physical device (e.g., gateway or router), etc.

The cognitive edge device 220 may be adapted to execute any operating system 230 (including Linux, UNIX, microsoft Windows, apple MacOS, apple iOS, valley-singer, windows servers, etc.) as well as virtual machines adapted to virtualize the execution of particular operating systems (including custom and proprietary operating systems).

The cognitive edge device 220 may be implemented with cognitive edge processing capabilities to facilitate intelligent network management decisions. For example, the cognitive edge device 220 may detect and utilize contextual information about its operating environment based on information from the sensors 210, from other edge devices 220 (e.g., end user devices, proxies, gateways), from cloud services, and/or from other network resources. This context information may be utilized for various purposes, including cognitive edge processing and service delivery, resource orchestration, and/or intelligent network configuration. The cognitive edge device 220 may utilize the context information, for example, to decide where (e.g., cloud or edge) the data should be processed and/or stored, and by which network entities (e.g., gateway, end user device, cloud) the data should be processed and stored. These cognitive decisions may be based on, for example, contextual information about the data that needs to be processed (e.g., type, amount, and/or age of the data), expected response time, network resource availability and bandwidth constraints, the ability to meet service delivery requirements (e.g., from Service Level Agreements (SLAs) or other service delivery specifications), availability and health of other edge devices (e.g., gateways, end user devices), availability and health of cloud services, physical locations of edge devices, and other examples.

The cognitive edge device 220 may utilize context information from its own sensors and/or from sensors of other IoT devices. In some embodiments, the sensor may be an internal sensor or an external sensor. The internal sensors may, for example, sense or monitor contextual information related to the device's own internal operating environment (such as processor usage, device workload, memory capacity, battery capacity, network usage, internal temperature (e.g., heating of the processor), software security alarms, and software errors and anomalies, as well as other attributes and events). The external sensors may, for example, detect, measure, and generate sensor data describing characteristics and contextual information of the external operating environment in which the device resides. For example, external sensors may be configured to detect contextual information of the device, such as movement, weight, physical contact, temperature, wind, noise, light, computer communications, wireless signals, location, humidity, presence of radiation, liquids or specific compounds, and several other examples. Indeed, the device sensors as described herein contemplate a potentially infinite range of various sensors, each designed to detect and generate corresponding sensor data for new and unknown operating environment characteristics. The context information from the sensors may be utilized by the cognitive edge device 220 to facilitate intelligent network management decisions, as described throughout this disclosure. For example, the cognitive gateway device may utilize contextual information about the data that needs to be processed (e.g., type, amount, and/or age of the data), network connectivity (e.g., wi-Fi, cellular), network bandwidth, processing and memory availability, battery life, physical location, and the like to determine whether to process the data itself, send the data to other edge devices for processing, and/or send the data to the cloud for processing.

The cognitive edge device 220 may be used to remedy the inadequacies of cloud-based processing (e.g., when cloud-based processing is inefficient, and/or unsafe), as well as to better handle the growing amount, variety, and speed of IoT data. The cognitive edge device 220 may intelligently process certain IoT data at (near) the network edge (data generated by) rather than simply aggregate large amounts of data to the cloud for processing and storage. Edge processing may be referred to as "misting" because they are used to spread the "cloud" to the edge of the network, thereby forming a "mist" on the edge of the network. In some cases, processing IoT data near the source of the IoT data rather than in the cloud may improve performance and avoid system failures or disasters. The cognitive edge processing may also conserve network bandwidth, which is particularly beneficial when faced with bandwidth constraints and/or limited network connectivity. In addition, cognitive edge processing allows for maximum utilization of IoT device resources (e.g., ioT gateway's communication, processing, and storage resources).

The cognitive processing capabilities of the cognitive edge device 220 provide platform awareness, network awareness, and data awareness. For example, platform awareness may refer to the awareness of a device to its own operating platform, including resource capabilities and availability (e.g., processing, storage, and communication capabilities, as well as the current utilization of those resources). For example, network awareness may refer to a device's awareness of available communication networks, bandwidth limitations, network connectivity or availability, traffic patterns, connectivity scope, and the like. For example, data awareness may refer to awareness of a device about data that needs to be processed (e.g., type, amount, and/or age of data), time sensitivity of processing data, storage policy of data (e.g., long-term or short-term storage), and so forth.

These cognitive functions facilitate intelligent decision making by the cognitive edge device 220. For example, cognitive processing capabilities may facilitate data processing, storage and transmission, and workload distribution, as well as intelligent decision-making of autonomous network configuration with respect to data from sensors and IoT devices. Further, the improved edge analysis may provide insight into the optimal processing of data, e.g., based on learning or knowledge of network descriptions, data descriptions, and descriptions of resources/capabilities of IoT gateways and other edge devices. The cognitive processing capability may also extend the concept of big data on gateways and other edge devices to consider metadata about network descriptions, data descriptions, and/or descriptions of the edge devices and their neighboring edge devices' resources/capabilities. The cognitive processing capabilities may also allow workload distribution management and resource orchestration to intelligently distribute workloads among the cognitive edge devices 220 for incoming data from sensors and other IoT devices (e.g., through resource orchestration agents such as those described in connection with other figures throughout this disclosure). The cognitive processing capability may also facilitate autonomous network setup between the gateway and other edge devices.

Existing edge devices and gateways communicate with the cloud using only northbound communication (i.e., simple upload) without southbound control/actuation or traceability/reciprocity between data and actions. Such static processing and communication models are not suitable for the dynamic service requirements of IoT systems. However, the cognitive processing capabilities of the cognitive edge nodes 220 may facilitate tracking and tracing capabilities, allowing the identification of the location of each edge device 220 within the service delivery chain (both upstream and downstream) and its resource availability/utilization. This enables multi-hop service delivery and peer-to-peer communication between cognitive edge devices 220 (i.e., communication between devices that do not pass through a backhaul network) in some cases. The tracking and tracing capabilities may provide insight into network resources involved in delivering a particular service (upstream and downstream), which may allow for identifying and isolating sources of service interruption and for adapting the network to eliminate or minimize service interruption. For example, the tracking and tracing functionality may allow the IoT system to identify bottlenecks that affect the performance of the videoconference session and adjust the network accordingly to mitigate interruptions (e.g., by utilizing less congested nodes in the service delivery chain, or eliminating the cause of full congestion). Tracking and trace capabilities may improve the ability to comply with service delivery requirements (e.g., from a Service Level Agreement (SLA) or other service delivery specification).

In the illustrated embodiment, the cognitive processing capabilities of the cognitive edge device 220 are implemented by the cognitive module 221. In some embodiments, the awareness module 221 may be implemented as a software module in the awareness edge device 220. The awareness module 221 includes an intelligent decision making (SDM) module 222, a manageability agent 223, a context engine 224, and a context awareness module 225.

As described throughout this disclosure, the context awareness module 225 is a context sensor that provides context information about the operating environment of the cognitive edge device 220. The context awareness module 225 may be provided using physical sensors 210 (e.g., a GPS chipset providing location information, a network interface card showing a network interface type, a battery showing remaining battery life, etc.) or soft sensors 210 (e.g., metadata in data packets showing a service type, a bandwidth estimation method showing available bandwidth, etc.).

As described throughout this disclosure, the context engine 224 collects context information from the context awareness module in real-time, aggregates the context information, and makes inferences about the operating environment of the cognitive edge device 220 based on the context information.

Manageability agent 223 enforces policies for data processing, distribution, and transmission based on real-time context information and any service delivery requirements (e.g., from a Service Level Agreement (SLA) or other service delivery specification). This module also communicates context information of the edge device 220 to, and receives similar context information from, the neighboring edge device or gateway in real-time.

As described throughout this disclosure, intelligent decision-making (SDM) module 222 implements intelligent network management and workload distribution decisions. For example, this module may facilitate decisions regarding: whether the data is processed locally or remotely in another edge device or gateway, whether the data is stored locally or remotely (e.g., based on a storage policy of the data and/or a local storage capacity of the device), which network interface is used to transfer the data, etc

The cognitive edge device 220 also includes a plurality of interfaces 240a-e. As described throughout this disclosure, the out-of-band interface 240e may be used, for example, for reliable communication with other gateways or edge devices (e.g., sharing information regarding resource capabilities and/or availability, exchanging control signals, etc.) for management and orchestration purposes. The in-band interface 240d may be used, for example, for data transmission between the IoT gateway and other edge devices for workload distribution. For example, in some cases, IB interface 240d may utilize a short-range communication protocol, such as Wi-Fi, bluetooth, zigBee, and the like. The network interface 240c may be used for data transmission to the cloud, for example. In some cases, networking interface 240c may utilize long range communications, such as Ethernet, cellular, wi-Fi, and the like. In some embodiments, network interface 240c and in-band interface 240d may be the same interface that operates in dual modes (e.g., short range communication for communicating with neighboring edge devices and gateways and long range communication for communicating with the cloud). IoT device interface 240a may be used, for example, for communication with other IoT devices, and IoT API interface 240b may be used, for example, as an interface between edge device or gateway 220 and an IoT application.

Fig. 3 illustrates an example embodiment 300 of a cognitive edge device 230. In some embodiments, the cognitive edge device 320 may be similar to the cognitive edge device 220 of fig. 2.

In the illustrated embodiment, the user space of the cognitive edge device 230 includes a cognitive module 321 and a driver API 352. The kernel space of the cognitive edge device 320 includes memory drivers 350a-d, which memory drivers 350a-d may interface with the sensors 310 and/or other internal and/or external components of the cognitive edge device 320, such as a GPS chipset, battery, memory module, and network interface card.

An operating system corresponding to "kernel space" in the illustrated embodiment may utilize the driver APIs 350a-d to provide information regarding the battery level, location, memory status, and available network interfaces of the cognitive edge device 320. The driver API 352 may serve as a user login interface for the associated driver 350 in kernel space. The drivers 350 may serve as an interface between the operating system kernel and the associated hardware components and/or sensors 310 (such as device batteries, GPS chipsets, memory modules, and network interface cards) of each driver.

The context engine 324 is in user space and it continuously extracts the above context information via the driver API 352. The context engine includes a context module 325 for processing battery context information 325a, location context information 325b, memory context information 325c, and network interface context information 325 d. The context engine 324 may use context information as described throughout this disclosure, for example, to perform intelligent network management decisions, such as decisions regarding data storage, processing, and transmission, and workload distribution, among others.

Manageability agent 323 is implemented on top of context engine 324 and uses the provided context information in real-time: (i) Sharing context information with neighboring gateways or other edge devices, and (ii) setting rules for workload distribution, whether distributed locally in the same edge device or externally among other gateways or edge devices in the cloud, through scheduler submodule 326 (or, in some embodiments, a resource orchestration proxy).

As described throughout this disclosure, intelligent decision-making (SDM) module 322 is triggered by manageability agent 323 to set policies regarding storage, processing, and transmission of data (e.g., use of low-throughput network interfaces for non-real-time data, acceleration of hardware for mass analysis, storage of data in memory, solid state drives, or in the cloud).

Fig. 4 illustrates a flowchart 400 of an example embodiment for cognitive edge processing. The flowchart 400 may be implemented, for example, by a cognitive edge device, such as those described throughout this disclosure (e.g., 120 of fig. 1, 220 of fig. 2, and 320 of fig. 3).

Flowchart 400 may begin at block 402, where context information of a first edge device is detected. As described throughout this disclosure, the first edge device may be, for example, a cognitive edge device, such as a cognitive gateway. In addition, the first edge device may be configured to connect to the communication network at an edge of the communication network. As described throughout this disclosure, the context information may identify an operating environment of the first edge device based on information from the one or more sensors.

The flow chart may then proceed to block 404 where the first edge device communicates its context information to the neighboring edge device. The neighboring edge device may also be a cognitive edge device, such as a cognitive gateway, for example.

The flow diagram may then proceed to block 406 where the first edge device receives context information from its neighboring edge devices. The context information from the neighboring edge device may identify an operating environment of the neighboring edge device based on information from the one or more sensors. Finally, the flow chart may then proceed to block 408, wherein the first edge device performs a network management function based on the context information of the first edge device and the neighboring edge devices. As described throughout this disclosure, the network management functions may be, for example, data processing, storage and/or transmission functions, resource orchestration and/or workload distribution functions, and/or autonomous network configuration functions.

At this point, flowchart 400 may be complete, but in particular embodiments, the flowchart may resume at block 402 to continue detecting updated context information and performing network management functions.

Fig. 5-7 illustrate example embodiments of resource orchestration agents in different agent configurations.

The resource orchestration agent may provide resource orchestration and workload distribution services for IoT sensor/actuator devices by distributing the workload among gateways and other edge devices managed by the agent. For example, ioT sensor/actuator devices may generate IoT data from one or more sensors, and a resource broker may distribute data processing workloads for the generated IoT data among other edge devices (e.g., edge gateways) managed by the broker. In some cases, the IoT device itself may be an edge device managed by the broker such that the IoT device both provides IoT data for workload distribution by the broker and receives workload distribution assignments from the broker. In some embodiments, the agent may be used with cognitive edge devices, such as those described throughout this disclosure (e.g., cognitive edge device 120 of fig. 1, 220 of fig. 2, and 320 of fig. 3). For example, when used with a cognitive edge device (such as a cognitive gateway), the resource broker may use context information from the cognitive edge device to make intelligent workload distribution decisions that optimize performance and service delivery. In some embodiments, the resource broker itself may be a cognitive edge device.

In some embodiments, the resource broker may be implemented as a stand-alone edge device, functionality in an existing edge device, and/or functionality distributed across multiple edge devices and/or network components. For example, in some embodiments, the agent may be implemented as a software component in another physical edge device (e.g., a controller embedded in or attached to an edge device "green farm"), as part of an operating system of an edge device (e.g., a service green farm and brown farm device), or by a virtual machine on the edge device. For example, a proxy feature may be a set of functions implemented in a physical device (e.g., gateway or other edge device), a microcontroller unit (MCU), a router with a virtual machine running the gateway, a Field Programmable Gate Array (FPGA) in a physical device (e.g., gateway or router), etc.

In general, an "agent" is an arbiter that, in addition to simply facilitating a particular task or process, also relates to a task or process for facilitating an appropriate end result and/or goal. Thus, agents are considered to be enacted and interacted with throughout the process.

Agents may be introduced in IoT systems to automate the process of resource orchestration and dynamic workload distribution for network edges. The agent provides: (i) Distributed manageability for IoT gateways and other edge devices, which expands cloud resources to enable edge or fog computing; (ii) Workload distribution between IoT gateways and other edge devices for data from sensors and IoT devices; and (iii) access to all service level specifications for resources involved in the service delivery chain, thereby improving the ability to adhere to service delivery requirements (e.g., from a Service Level Agreement (SLA) or other service delivery specifications).

In some embodiments, the IoT edge network may reside in front of the access network (e.g., in front of a Wi-Fi access point or cellular base station), acting as a back-off for IoT sensor/actuator devices and a front-off network for the access network. The resource orchestration agent may be deployed in the IoT system as a last mile node of the IoT edge network (i.e., the first mile node of the IoT sensors/devices in the IoT edge network).

Resource orchestration agents may be deployed in a variety of configurations, including centralized agent systems, distributed agent systems, inter-edge agent systems, and federated agent systems. For example, fig. 5 illustrates an example of a centralized agent system 500, fig. 6 illustrates an example of a distributed agent system 600, and fig. 7 illustrates an example of a federated agent system 700 (which includes an inter-edge agent).

A centralized broker system (such as the broker system 500 of fig. 5) wherein all gateways and other edge devices in a subnet are connected to a centralized broker 560 for resource orchestration and workload distribution. The centralized agent 560 provides permanent services to the cloud, the internet, or other back-haul network, and relays all control and management signals from the cloud to the edge devices 520 that it manages. According to embodiments, ioT sensor/actuator devices 510 may transmit their IoT data to agents 560 periodically (i.e., push mode) or upon request of agents (i.e., push mode). The agent 560 acts as an arbiter and distributes workload among the cognitive edge devices 520 (such as gateways) that reside in the same management domain based on resource availability and other context information. This may be referred to as intra-cluster distribution because there is only a single cluster of devices managed by the agent 560.

Each cognitive gateway and cognitive edge device 520 publishes context information about its platform and resources to the broker 560 through an out-of-band channel. The broker 560 tracks information about the resources of the cognitive gateway and other cognitive edge devices 520 based on the context information provided to the broker 560 periodically by those cognitive devices 520. The agent 560 also receives data processing workloads from IoT sensor/actuator devices 510 and then distributes workload assignments between the cognitive gateway and edge devices 520.

A distributed broker system (such as the broker system 600 of fig. 6) is one in which several distributed brokers 660 exist in the same administrative domain, which may include a single subnet or multiple subnets, and each broker 660 is responsible for managing multiple IoT gateways and edge devices 620 for resource orchestration and workload distribution. Each agent 660 provides permanent services to the cloud, the internet, or other back-haul network, and relays all control and management signals from the cloud to its managed edge devices 620. Each distributed agent 660 also ensures connections with other distributed agents 660 for workload distribution in other subnets, which allows for an increase in administrative domain size.

The cognitive gateway and edge devices 620 form distributed clusters, with the distributed agent 660 managing each cluster. Each cognitive gateway and cognitive edge device 620 publishes context information about its platform and resources to its clustered distributed agents 660 over an out-of-band channel. The agents 660 of this cluster track information about their cognitive gateway and the resources of the edge devices 620 based on the context information provided to the agents 660 periodically by those cognitive devices 620. The distributed agents 660 of each cluster also receive data processing workloads from IoT sensor/actuator devices 610 and then distribute workload assignments among all cognitive gateways and edge devices 620 (managed by the various distributed agents 660) within the same administrative domain based on their resource availability. This is considered intra-cluster workload distribution between clusters. These clusters must be located within the same administrative domain and have services that are close to each other so that resources can be assigned or collected to match service level agreements. If the offloading agent 660 lacks the necessary resources in its own cluster while the agents 660 of another cluster have available resources, the agents 660 of each cluster may offload the workload to the agents 660 of the other clusters. Such offloading between clusters may be performed by direct communication between the agents 660 of a cluster and agents 660 of other clusters (e.g., by querying the resource availability of each cluster). Based on the resource availability of each cluster, the agent 660 that offloads the cluster distributes the workload to the agents 660 of the neighbor clusters, and then the resource distribution process follows the intra-cluster workload distribution approach described above.

An inter-edge proxy system is a system in which distributed proxies exist as inter-edge proxies (e.g., inter-edge proxy 760-1 of fig. 7) that do not communicate with a backhaul network (e.g., cloud, internet), and one of the inter-edge proxies is selected to select a leader to coordinate resource proxy functions among the other proxies, rather than simply residing in the network edge or fog.

A federated broker system, such as the broker system 700 of fig. 7, is one in which the broker 760 is distributed across multiple administrative domains 790a-c, providing resource orchestration and workload distribution services across multiple primary owners. The federated proxy system 700 uses the inter-edge proxy 760-1 to extend the distributed proxy system across different administrative domains 790a-c to coordinate between the different administrative domains 790 a-c. For example, in the federated proxy system 700, the inter-edge proxies 760-1 connect to their own clustered proxies 760-2 via an out-of-band interface and to the inter-edge proxies 760-1 that manage other clusters to constantly acquire information for all cluster resources. The agent 760-2 of each cluster that cannot find a resource in its own administrative domain 790 (whether in its own cluster or in other clusters in its administrative domain) wishes to offload workload to other administrative domains 790 and query its inter-edge agents 760-1 for resource availability. The inter-edge proxy 760-1 sends workload off-load requests to other inter-edge proxies 760-1, which proxy 760-1 distributes the workload over its own cluster through communication with its clustered proxy 760-2, and the resource distribution process then follows the intra-cluster workload distribution process described above.

FIG. 8 illustrates a flow chart 800 of an example embodiment for a resource orchestration agent. Flowchart 800 may be implemented, for example, by a resource orchestration agent, such as those cognitive edge devices described throughout this disclosure (e.g., 160 of fig. 1, 560 of fig. 5, 660 of fig. 6, 760 of fig. 7).

Flowchart 800 may begin at block 802, where a resource orchestration agent receives context information for a first set of edge devices. As described throughout this disclosure, the first set of edge devices may be, for example, cognitive edge devices, such as cognitive gateways. In addition, the first set of edge devices may be configured to connect to the communication network at an edge of the communication network. As described throughout this disclosure, the context information may identify an operating environment of the first set of edge devices based on information from the one or more sensors.

The flow diagram may then proceed to block 804, wherein the orchestration agent receives workload information for the second set of edge devices. As described throughout this disclosure, the second set of edge devices may be, for example, ioT sensor devices that use sensors to generate data that may require further processing. The workload information may be, for example, information about the amount, type, age, etc. of data generated by the IoT sensor device that requires further processing. In some embodiments, the second set of edge devices may also be cognitive edge devices.

The flow diagram may then proceed to block 806, wherein the orchestration agent determines workload assignments for the first set of edge devices based on the context information for the first set of edge devices and based on the workload information for the second set of edge devices. For example, the resource orchestration agent may determine workload assignments for the first set of edge devices based on its resource availability and other context information about its operating environment and the size of the workload that needs to be processed.

The flow diagram may then proceed to block 808, wherein the orchestration agent communicates the workload assignment to the first set of edge devices.

At this point, flowchart 800 may be complete, but in particular embodiments, the flowchart may resume at block 802 to continue receiving context information and workload information, determining workload assignments, and transmitting workload assignments.

Fig. 9-10 are block diagrams of exemplary computer architectures that may be used in accordance with embodiments disclosed herein. Other computer architecture designs known in the art of processors and computing systems may also be used. In general, suitable computer architectures suitable for use with the embodiments disclosed herein may include, but are not limited to, the configurations shown in FIGS. 9-10.

Fig. 9 illustrates a block diagram of an example embodiment of a processor 900. Processor 900 is an example of the types of hardware devices that may be used in connection with the implementations described above. Processor 900 may be any type of processor, such as a microprocessor, an embedded processor, a Digital Signal Processor (DSP), a network processor, a multi-core processor, a single-core processor, or other device for executing code. Although only one processor 900 is shown in fig. 9, the processing elements may alternatively include more than one processor 900 shown in fig. 9. Processor 900 may be a single-threaded core, or for at least one embodiment, processor 900 may be multi-threaded in that for each core, processor 900 may include more than one hardware thread context (or "logical processor").

Fig. 9 also illustrates a memory 902, this memory 902 being coupled to the processor 900, according to an embodiment. The memory 902 may be any of a variety of memories (including various layers of a memory hierarchy) known to or otherwise available to those skilled in the art. Such memory elements may include, but are not limited to, random Access Memory (RAM), read Only Memory (ROM), logic blocks of Field Programmable Gate Arrays (FPGAs), erasable Programmable Read Only Memory (EPROM), and Electrically Erasable Programmable Read Only Memory (EEPROM).

The processor 900 may execute any type of instructions associated with the various algorithms, processes, or operations described in detail herein. In general, the processor 900 may transform an element or article of manufacture (e.g., data) from one state or thing to another.

Code 904 (which may be one or more instructions executed by processor 900) may be stored in memory 902; alternatively, code 904 may be stored in software, hardware, firmware, or any suitable combination of software, hardware, and firmware; or may be stored in any other internal or external component, device, element, or object, as appropriate, based on particular needs. In one example, processor 900 may follow a program sequence of instructions indicated by code 904. Each instruction enters front-end logic 906 and is processed by one or more decoders 908. The decoder may generate micro-operations (such as fixed width micro-operations in a predefined format) or may generate other instructions, micro-instructions, or control signals reflecting the original code instructions as its output. Front-end logic 906 may also include register renaming logic and scheduling logic that generally distribute resources and queue operations corresponding to instructions for execution.

Processor 900 may also include execution logic 914, with the execution logic 914 having a set of execution units 916a, 916b, 916n, etc. Some embodiments may include multiple execution units that are dedicated to a particular function or set of functions. Other embodiments may include only one execution unit or only one execution unit that may perform certain functions. Execution logic 914 performs the operations specified by the code instructions.

After completion of execution of the operations specified by the code instructions, the backend logic 918 may retire the instructions of the code 904. In one embodiment, processor 900 allows out-of-order execution, but requires in-order instruction retirement. Retirement logic 920 may take a variety of known forms (e.g., reorder buffers, etc.). In this way, processor 900 is converted during execution of code 904, at least for the output generated by the decoder, the hardware registers and tables utilized by register renaming logic 910, and any registers (not shown) modified by execution logic 914.

Although not shown in fig. 9, the processing elements may include other elements on a chip with the processor 900. For example, the processing elements may include memory control logic with the processor 900. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (such as flash memory or fuses) may also be included on-chip with the processor 900.

Fig. 10 illustrates a block diagram of an example embodiment of a computing system 1000. The computing system 1000 is arranged in a point-to-point (PtP) configuration, according to an embodiment. In particular, FIG. 10 illustrates a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. In general, one or more of the computing systems described herein may be configured in the same or similar manner as computing system 1000.

Processors 1070 and 1080 may also include integrated memory controller logic (MC) 1072 and 1082, respectively, to communicate with memory elements 1032 and 1034. In alternative embodiments, memory controller logic 1072 and 1082 may be separate logic from processors 1070 and 1080. Memory elements 1032 and/or 1034 may store various data used by processors 1070 and 1080 to implement the operations and functions outlined herein.

Processors 1070 and 1080 may be any type of processor such as those discussed in connection with the other figures. Processors 1070 and 1080 may exchange data via a point-to-point interface 1050 using point-to-point (PtP) interface circuits 1078 and 1088, respectively. Processors 1070, 1080 may each exchange data with a chipset 1090 via individual point-to-point interfaces 1052 and 1054 using point-to-point interface circuits 1076, 1086, 1094, and 1098. The chipset 1090 may also exchange data with a high-performance graphics circuit 1039 via a high-performance graphics interface 1038, using an interface circuit 1092, which may be a PtP interface circuit. In alternative embodiments, any or all of the PtP links shown in FIG. 10 may be implemented as a multi-drop bus instead of PtP links.

The chipset 1090 may communicate with a bus 1020 via an interface circuit 1096. Bus 1020 may have one or more devices through which it communicates, such as a bus bridge 1018 and I/O devices 1016. Via bus 1010, bus bridge 1018 may communicate with other devices such as a user interface 1012 (such as a keyboard, mouse, touch screen, or other input device), a communication device 1026 (such as a modem, network interface device, or other type of communication device that may communicate over computer network 1060), an audio I/O device 1014, and/or a data storage device 1028. Data storage device 1028 may store code 1030, which code 1030 may be executed by processors 1070 and/or 1080. In alternative embodiments, any portion of the bus architecture may be implemented using one or more PtP links.

The computer system depicted in FIG. 10 is a schematic diagram of an embodiment of a computing system that may be used to implement the embodiments discussed herein. It should be appreciated that the various components of the system depicted in fig. 10 may be incorporated in a system-on-a-chip (SoC) architecture or in any suitable configuration capable of implementing the functions and features of the examples and implementations provided herein.

Although the present disclosure has been described in terms of particular implementations and generally associated methods, alterations and substitutions to those implementations and methods will be apparent to those skilled in the art. For example, the acts described herein may be performed in a different order than described, and still achieve desirable results. As an example, the processes depicted in the accompanying drawings do not necessarily require the particular order shown, or sequence, to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous. In addition, other user interface layouts and functions may be supported. Other variations are within the scope of the following claims.

In general, one aspect of the subject matter described in this specification can be embodied in methods and executed instructions that include or result in the following actions: the method includes identifying a sample including software code, generating a control flow graph for each of a plurality of functions included in the sample, and identifying features in each function corresponding to instances of a set of control flow fragment types. The identified features may be used to generate a feature set of the sample from the identified features.

These and other embodiments may each optionally include one or more of the following features. Features identified for each of the functions may be combined to generate a merged string of samples, and a feature set may be generated from the merged string. A string may be generated for each of the functions, each string describing a respective feature identified for the function. Combining the features may include: a call in a particular one of the plurality of functions is identified as another one of the plurality of functions, and a portion of a string referencing the particular one of the other functions is replaced with the content of the string of the other function. Identifying the features may include abstracting each of the strings of functionality such that only features of the control flow fragment type set are described in the strings. The set of control flow fragment types may include memory accesses by functions and functions called by functions. Identifying features may include identifying instances of memory accesses by each of the functions and identifying instances of function calls by each of the functions. The feature set may identify each of the features identified for each of the functions. The feature set may be an n-gram.

Further, these and other embodiments may each optionally include one or more of the following features. A feature set may be provided for classifying the sample. For example, classifying the sample may include clustering the sample with other samples based on corresponding features of the sample. Classifying the sample may further include determining a feature set associated with the cluster of samples. Classifying the sample may also include determining whether to classify the sample as malware and/or determining whether the sample is likely to be one of one or more families of malware. Identifying features may include abstracting each of the control flow graphs such that only features of the control flow fragment type set are described in the control flow graph. A plurality of samples may be received, including the samples. In some cases, multiple samples may be received from multiple sources. The feature set may identify a subset of features identified in a control flow graph of the functionality of the sample. The subset of features may correspond to memory accesses and function calls in the sample code.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as being used in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged together into multiple software products.

The following examples relate to embodiments according to the present description.

One or more embodiments may provide at least one machine accessible storage medium having instructions stored thereon that, when executed on a machine, cause the machine to: transmitting first context information of the first edge device to the one or more second edge devices via the communication network, wherein the first context information identifies an operating environment of the first edge device based on information from the one or more sensors; receiving, via the communication network, second context information for the one or more second edge devices, wherein the second context information identifies an operating environment of the one or more second edge devices based on information from the one or more sensors; and performing a network management function based on the first context information and the second context information.

In one example, a first edge device and one or more second edge devices are configured to connect to a communication network at an edge of the communication network.

In one example, the first context information and the second context information include edge device resource capacity.

In one example, the first context information and the second context information include edge device resource availability.

In one example, the edge device resource availability includes battery life information.

In one example, the edge device resource availability includes network resource availability.

In one example, the first context information and the second context information include edge device location information.

In one example, the first context information and the second context information include an identification of an amount of data that needs to be processed.

In one example, the first context information and the second context information include an identification of one or more types of data that needs to be processed.

In one example, the first context information and the second context information include an identification of an age of the data that needs to be processed.

In one example, the network management function includes workload distribution decisions.

In one example, the network management function includes an autonomous network setting.

In one example, the instructions that cause the machine to perform the network management function based on the first context information and the second context information further cause the machine to perform the network management function based on the service delivery requirements.

In one example, the instructions that cause the machine to perform the network management function based on the first context information and the second context information further cause the machine to allocate resources to the first edge device by: the first edge device is interconnected with one or more additional edge devices such that the first edge device includes a plurality of interconnected edge devices.

One or more embodiments may provide an apparatus comprising circuitry, wherein the circuitry is configured to: transmitting first context information of the first edge device to the one or more second edge devices via the communication network, wherein the first context information identifies an operating environment of the first edge device based on information from the one or more sensors; receiving, via the communication network, second context information for the one or more second edge devices, wherein the second context information identifies an operating environment of the one or more second edge devices based on information from the one or more sensors; and performing a network management function based on the first context information and the second context information.

In one example, a first edge device and one or more second edge devices are configured to connect to a communication network at an edge of the communication network.

In one example, the first context information and the second context information include edge device resource capacity.

In one example, the first context information and the second context information include edge device resource availability.

In one example, the edge device resource availability includes battery life information.

In one example, the edge device resource availability includes network resource availability.

In one example, the first context information and the second context information include edge device location information.

In one example, the first context information and the second context information include an identification of one or more types of data that needs to be processed.

In one example, the network management function includes workload distribution decisions.

In one example, the network management function includes an autonomous network setting.

One or more embodiments may provide a system comprising: a processor; a memory; one or more sensors configured to collect first context information of the first edge device, wherein the first context information identifies an operating environment of the first edge device based on information from the one or more sensors; logic that, when executed by a processor, is configured to: transmitting first context information of the first edge device to one or more second edge devices via the communication network; receiving, via the communication network, second context information for the one or more second edge devices, wherein the second context information identifies an operating environment of the one or more second edge devices based on information from the one or more sensors; and performing a network management function based on the first context information and the second context information.

In one example, a first edge device and one or more second edge devices are configured to connect to a communication network at an edge of the communication network.

One or more embodiments may provide a method comprising: transmitting first context information of the first edge device to the one or more second edge devices via the communication network, wherein the first context information identifies an operating environment of the first edge device based on information from the one or more sensors; receiving, via the communication network, second context information for the one or more second edge devices, wherein the second context information identifies an operating environment of the one or more second edge devices based on information from the one or more sensors; and performing a network management function based on the first context information and the second context information.

In one example, a first edge device and one or more second edge devices are configured to connect to a communication network at an edge of the communication network.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the various processes depicted in the accompanying drawings do not necessarily require the particular order shown, or require the order shown, to achieve desirable results.

Claims (10)

1. A method for internet of things, comprising:

executing at the IoT edge device at least one application from a management server system in the cloud;

Executing software to collect operational status of the application on the IoT edge device;

Executing the software to manage communications between the IoT edge device and a downstream IoT device;

executing the software to manage communications between the IoT edge device and the cloud;

determining that the operational state of the application is unhealthy;

restarting the application to return the operating state of the application to a healthy state;

Accessing data from the downstream IoT device; and

Executing, at the IoT edge device, a machine learning model with an FPGA to generate an output using the data from the downstream IoT device.

2. The method of claim 1, wherein the application is an IoT application.

3. The method of claim 1, further comprising: causing the IoT edge device to manage communications between modules of the IoT edge device.

4. The method of claim 1, further comprising: causing the IoT edge device to transmit the application to another IoT edge device.

5. The method of claim 1, wherein the unhealthy state corresponds to a presence of at least one software error associated with executing the application.

6. The method of claim 1, wherein the FPGA is to execute the machine learning model to process the data at the IoT edge device.

7. The method of claim 1, further comprising: determining that the operational state of the application is in an unhealthy state based on an event.

8. The method of claim 1, further comprising: the application is reconfigured by making operational changes to the application.

9. A computer-readable storage medium comprising instructions that, when executed, cause an IoT edge device to perform any of the methods recited in claims 1-8.

10. An apparatus for the internet of things comprising means for performing any of the methods of claims 1 to 8.