Connectivity Service Level Orchestrator and Arbiter in the Internet of Things (IoT) Platform

Abstract

The disclosed embodiments relate to an orchestrator and an arbiter in an Internet of Things (IoT) platform. In one embodiment, a method for servicing multiple data streams of multiple wireless devices using multiple protocols includes: monitoring one or more interfaces that communicate using multiple protocols; activating the first interface after detecting a need to exchange data on the first interface, wherein a connectivity manager performs the monitoring and activation; extracting packet metadata from one or more of the multiple data streams by a packet analyzer; determining a latency experienced by one or more of the data streams and a bandwidth utilized by one or more of the data streams based on the packet metadata; applying a latency reduction strategy by an Adaptive Connectivity Manager (ACM) to attempt to meet a latency criterion; and applying a bandwidth reduction strategy by a Bandwidth Utilization Manager (BUM) to attempt to meet a bandwidth criterion.

Description

Technical Field

[0001] The field of the present invention generally relates to computer processor architectures, and more particularly to connectivity service level orchestrators and arbitrators in Internet of Things (IoT) platforms. Background Art

[0002] The Internet of Things (IoT) is driving the need for multiple wireless network interfaces for different radio technologies in IoT platforms. This is particularly relevant for IoT gateway platforms that communicate with multiple sensors and IoT devices for data aggregation and processing, as well as for communication with the cloud. Existing IoT gateway platforms face numerous challenges.

[0003] One challenge faced by some existing IoT gateways is the support for multiple radio technologies and dynamic switching between multiple radio technologies, such as low energy (“BLE”), WiFi, cellular 2G, 3G, and 4G, and 5G in the near future. Sensors and IoT devices equipped with multiple radio technologies create the need for IoT gateways to switch between different radio interfaces during communication with these devices.

[0004] Another challenge faced by some existing IoT gateways is the need to process various types of data for various types of applications with various requirements (e.g., mission-critical applications, real-time applications, smart metering, video surveillance, etc.), which requires an adaptive selection of the type of connectivity to the cloud to meet application requirements and service provider (SP) service level agreements (SLAs).

[0005] Yet another challenge faced by some existing IoT gateways is the need to handle different data throughput requirements for each of various IoT devices and sensors (e.g., some sensors transmit 3 bytes per second, while a camera can transmit 2 Mbps), which creates the need to arbitrate the bandwidth usage of each selected type of connectivity in a cost-effective manner.

[0006] Currently, there is no solution in the IoT platform that addresses the above drawbacks. Brief Description of the Drawings

[0007] The present invention is illustrated by way of example and not limitation in the accompanying drawings, in which like reference numerals indicate like elements, wherein:

[0008] Figure 1 is a block diagram illustrating processing components for use by a connectivity service level orchestrator and arbitrator, according to some embodiments;

[0009] Figure 2 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments;

[0010] Figure 3 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments;

[0011] Figure 4 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments;

[0012] Figure 5 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments;

[0013] Figure 6 is a block diagram of a wireless communication technology supported by a connectivity service level orchestrator and arbiter according to some embodiments;

[0014] Figure 7 is a flowchart of a process performed by a connectivity service level orchestrator and arbiter according to some embodiments;

[0015] Figure 8 is a flowchart of a process performed by an adaptive connectivity manager (ACM) of a connectivity service level orchestrator and arbiter according to some embodiments;

[0016] Figure 9 is a flowchart of a process performed by a bandwidth utilization manager (BUM) of a connectivity service level orchestrator and arbiter according to some embodiments;

[0017] Figure 10 illustrates a domain topology of various Internet of Things (IoT) networks coupled via a link to respective gateways according to an example;

[0018] Figure 11 illustrates a cloud computing network according to an example, the cloud computing network communicating with a mesh network of IoT devices operating as fog devices at the edge of the cloud computing network;

[0019] Figure 12 illustrates a block diagram of a network according to an example, the network illustrating communication between a large number of IoT devices;

[0020] Figure 13 illustrates a block diagram of an example IoT processing system architecture on which any one or more of the technologies (e.g., operations, processes, methods, and methodologies) discussed herein may be performed;

[0021] Figure 14 is a block diagram of a processor 1400 that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to an embodiment of the present invention;

[0022] Figures 15 - 18 is a block diagram of an exemplary computer architecture;

[0023] Figure 15 A block diagram showing a system according to an embodiment of the present invention;

[0024] Figure 16 is a block diagram of a first more specific exemplary system according to an embodiment of the present invention;

[0025] Figure 17 is a block diagram of a second more specific exemplary system according to an embodiment of the present invention;

[0026] Figure 18 is a block diagram of a SoC according to an embodiment of the present invention; and

[0027] Figure 19 is a block diagram comparing the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present invention. DETAILED DESCRIPTION

[0028] In the following description, numerous specific details are set forth. However, it should be understood that embodiments of the present invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this description.

[0029] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0030] The embodiments disclosed herein provide a connectivity manager for on-demand network interface activation, adaptive selection of connectivity, and bandwidth usage arbitration in a manner transparent to applications and to the underlying operating system (OS). The connectivity manager is primarily a software agent that can be in a physical component or implemented via a virtual machine in an IoT platform, such as a field-programmable gate array (FPGA) built into an IoT platform device (the "greenfield" described hereinafter) or attached to an IoT platform device (the "brownfield" described hereinafter), a controller).

[0031] The disclosed embodiments improve upon some existing platforms that include an IoT gateway equipped with multiple radio technologies and multiple sensors and IoT devices, such as low-energy "BLE", WiFi, cellular 2G, 3G, 4G, and 5G. Challenges are presented when the presence of multiple radio technologies creates a need for the IoT gateway to switch between different radio interfaces during communication with these sensors and devices. However, some existing solutions are constrained by requiring the user equipment or IoT equipment to switch between multiple radio technologies, rather than having the IoT gateway acting as an aggregator dynamically switch between multiple radio technologies in a manner transparent to the user equipment or IoT equipment, as in some of the embodiments disclosed herein.

[0032] The disclosed embodiments also improve upon some existing platforms that include an IoT gateway and multiple different types of applications, such as mission-critical applications, real-time applications, smart metering, video surveillance, etc., each of which uses different types of data and has specific requirements as defined in a service level agreement (SLA).

[0033] But some existing IoT gateways are constrained by the inability to serve various applications with various data types and various SLAs. In some of the disclosed embodiments, the connectivity service level orchestrator and arbiter provide the benefit of dynamically adapting to the specific data type and SLA requirements of various IoT devices and sensors.

[0034] The disclosed embodiments also improve upon some existing platforms that include multiple devices and multiple sensors each having different data throughput requirements. For example, some sensors transmit 3 bytes per second, while a camera can transmit 2 Mbps. But some existing IoT gateways are unable to arbitrate bandwidth usage for each of multiple different applications. However, in some of the disclosed embodiments, the connectivity service level orchestrator and arbiter beneficially arbitrate between the bandwidth demands of multiple IoT devices and sensors, thereby attempting to meet each requirement in the SLA bandwidth requirements of each.

[0035] IoT Community

[0036] The disclosed embodiments implement an IoT community that includes a large number of IoT functional entities with various capabilities and various SLA requirements. The IoT functional entities can be composed of networked software, hardware, or any combination of software and hardware. The IoT functional entities can be a personal computer, a mobile computing device, a cellular phone, or any similar device. The IoT functional entities do not necessarily need to include a CPU. For example, a remotely connected sensor device can be an IoT functional entity. As used herein, the IoT community can refer to any one of an IoT platform, an edge system, a fog system, etc. As used herein, the IoT entity can refer to any one of an IoT functional unit, an IoT device, an IoT module, a fog device, and an edge device, etc. In the context of an IoT community, the IoT functional entity can refer to any one of a member, a citizen, a voter, a participant, etc.

[0037] The IoT community can be as simple as including a single member, such as an IoT functional entity composed of a personal computer. The IoT community can be composed of multiple citizens (e.g., multiple virtual machines hosted on a computer and managed by a hypervisor). The IoT community can be composed of multiple voters (e.g., multiple containers running on a container environment and using container technologies such as or ). The IoT community can be composed of dozens, hundreds, or thousands of members, citizens, and voters, each having different processing powers and different SLA requirements.

[0038] The embodiments disclosed herein support an IoT community having: (i) a large number of IoT functional entities using different radio technologies for communication; (ii) various application requirements and SLA requirements; (iii) various types of data having different throughputs and thus different bandwidth requirements for communicating with the cloud; and (iv) cost-effective communication with the cloud without sacrificing the SLA.

[0039] Some IoT functional entities have software that allows these IoT functional entities to be self-aware (understand the functions to be performed by these IoT functional entities and their SLA requirements) and environmental (recognize and maintain connections with partner community members and participate in community-wide interactions). Some of the disclosed embodiments implement such an IoT community that includes such self-aware, environmental IoT functional entities, and these self-aware, environmental IoT functional entities cooperate to perform their respective functions in a manner that meets their SLA requirements.

[0040] Some embodiments introduce a solution for connectivity management in an IoT platform (e.g., an IoT gateway or any edge device having direct communication with sensors and IoT devices and communication with the cloud) that provides on-demand network interface activation, adaptive selection of connectivity, arbitration of bandwidth usage, and cost effectiveness.

[0041] Figure 1 A high-level overview of a solution according to some embodiments is given, which is intended to be transparent to the application and the underlying OS and support an IoT community of voter IoT functional entities.

[0042] Figure 1 FIG. is a block diagram of processing components for use by a connectivity service level orchestrator and arbiter according to some embodiments. As shown, the connectivity service level orchestrator and arbiter 100 includes a connectivity manager (CM) 102, an adaptive connectivity manager (ACM) 104, a bandwidth utilization manager (BUM) 106, and a packet analyzer (PA) 108. In some embodiments, the modules 102-108 are implemented as software agents in physical components or implemented via virtual machines in the IoT platform, physical components such as FPGAs, controllers (MCUs) built into the IoT platform device (“greenfield” device) or attached to the IoT platform device (“brownfield” device).

[0043] As used herein, an SLA (service level agreement) is an agreement between a service provider (internal or external) and the owner of one or more IoT devices or sensors. The SLA defines the service level expected by the IoT device or sensor or the end consumer of the service “user” from the service provider. The SLA is output-based, in that it is intended to define what the consumer will receive. The SLA does not define how the service itself is provided or delivered. The SLA that an Internet service provider (ISP) will provide to its consumers is a basic example of an SLA from an external service provider. In some embodiments, the metrics that define the required service level include one or more of the following: the minimum required bandwidth, the maximum required latency, and the minimum uptime requirement (such as the mean time between network failures), to name a few.

[0044] In some embodiments, when the system is initialized, an SLA is assigned to each IoT functional entity or sensor. In some embodiments, the SLA requirements are at least partially included in the header or payload of a network packet or application packet (so as to, for example, distinguish between service SLAs, e.g., in a smart home system, an upload of temperature readings to the cloud will not have the same SLA as an upload of a fire alarm to the cloud). In some embodiments, individual IoT devices or sensors can request an updated SLA from the connectivity service level orchestrator and arbiter 100.

[0045] Connectivity Manager (CM 102)

[0046] CM 102 enables an IoT functional entity (e.g., an edge device) to switch between different network interfaces on demand based on the transmission activities of sensors / devices attached to the edge device and the type of attachment (e.g., WiFi, Ethernet, etc.). This action can be initiated via a policy and is two-way for each configuration. The IoT functional entity can initiate connectivity based on data availability and readiness, and / or a remote system can initiate a request based on a timer or other policy-based control.

[0047] In some embodiments, as further detailed below, when the SLA of the IoT functional entity calls for more bandwidth, e.g., based on a large amount of data to be transmitted or received, CM 102 switches to a higher bandwidth interface, such as, from switching to a WiFi interface, which provides an order of magnitude higher bandwidth. In some embodiments, as further detailed below, CM 102 attempts to meet the SLA bandwidth and latency requirements by switching to a different protocol (e.g., from a 2G wireless protocol to a 4G wireless protocol). In some embodiments, as further detailed below, CM 102 attempts to meet the SLA bandwidth and latency requirements by using multiple interfaces simultaneously (redundant packets generated will be discarded).

[0048] In some embodiments, all network interfaces 110 - 116 are in a low power mode and are idle. Subsequently, one or more interfaces transition to an active state after packet reception.

[0049] In some embodiments, CM 102 continuously monitors the status of network interfaces and monitors the reception of data by each active network interface. For example, when an active interface has not received data for a threshold amount of time, CM 102 sends a signal to that interface to place it in a low power mode.

[0050] Adaptive Connectivity Manager (ACM 104)

[0051] In some embodiments, the Adaptive Connectivity Manager (ACM) 104 attempts to provide an optimal selection of connectivity across different network interfaces used by IoT functional entity citizens of the IoT community in an adaptive manner. This includes using local transport mechanisms (such as BLE for the first hop or ) to match the SLA. In some embodiments, at least part of the SLA is detailed in the packet header. In some embodiments, at least part of the SLA is detailed in the packet payload.

[0052] The Adaptive Connectivity Manager (ACM) 104 attempts to establish an optimal selection of connectivity across different network interfaces to meet the SLA requirements of various IoT functional entities in the IoT community. Depending on the IoT functional entities that are the constituents of the IoT community, the ACM 104 may implement a deterministic control algorithm or a probabilistic control algorithm.

[0053] For example, in the case of an industrial IoT community (such as a nuclear power plant with multiple remote sensors and shut-off valves), the ACM 104 attempts to control and strictly manage the behavior of each individual IoT functional entity. Failure to shut off a valve is unacceptable. Such IoT functional entities follow an SLA with the most stringent connectivity requirements.

[0054] Alternatively, in some embodiments, the ACM 104 applies a probabilistic approach to attempt to meet the service level requirements. For example, when the IoT functional entity is a distributed temperature and barometric pressure sensor in an IoT community consisting of hundreds of such IoT weather sensing functional entities, the SLA requirements may tolerate dropped connections here and there, and a probabilistic control algorithm would be sufficient. In such an IoT community, a failure that occurs in a given IoT functional entity does not need to abort the continued progress of the peer IoT functional entities of the given IoT functional entity. In some embodiments, the ACM 104 attempts to satisfy one or more SLA requirements within a predetermined range. For example, if a business hall requires maintaining a temperature of 74 degrees, then whenever the temperature is within plus or minus one degree of the target value, the ACM 104 will consider the SLA to be satisfied.

[0055] In some embodiments, the ACM 104 provides an optimal hop-by-hop routing decision by analyzing the data received from the IoT functional entities. In some embodiments, the ACM 104 participates in Deep Packet Inspection (DPI) to examine the data portion of each received data packet and in some cases multiple portions of one or more headers of each received data packet to determine which network interface will be used to transmit the packet. For example, the ACM 104 may attempt to optimize power and performance by selecting a network interface that is expected to be low-cost and low-power to transmit a data stream that includes non-real-time data. In some embodiments, the ACM 104 examines the metadata incorporated into each received packet to decide which network interface will be used to relay the packet.

[0056] In some embodiments, ACM 104 adaptively selects a data transmission path to meet the service level agreement associated with the data stream. For example, ACM 104 may relay the same data packet along a multi-hop path to ensure that at least one of these paths meets the latency requirements specified in the SLA. The multi-hop path has various network interfaces along the path. To eliminate receiving duplicates due to other copies of the data packets being transmitted simultaneously, the receiver node checks the packet ID and discards duplicate packets (the packet ID is part of the metadata included in each packet).

[0057] In some embodiments, ACM 104 simultaneously transmits the same data packet through multiple network interfaces to ensure that at least one interface allows the data to arrive on time as specified in the SLA. To eliminate receiving duplicates due to other copies of the data packets being transmitted simultaneously, the receiver node checks the packet ID and discards duplicate packets (the packet ID is part of the metadata included in each packet).

[0058] In some embodiments, when selecting a transmission path in an adaptive manner, ACM 104 uses the Serialized Packet Protocol (SSP) to ensure that the complete message is correctly received by the recipient in the correct sequence. SPP is a byte stream protocol that can be used to provide reliable, flow-controlled bi-directional transmission of data.

[0059] In some embodiments, ACM 104 adaptively selects the transmission path of data packets for mission-critical and time-sensitive applications by harvesting any available interfaces and network resources. To meet the mission-critical timing requirements, in some embodiments, ACM 104 uses Time-Sensitive Networking (TSN) (if such a network exists). TSN can be the default preferred interface for a special class of services (e.g., remote surgery in e-health applications). Time-Sensitive Networking is a collection of IEEE 802 Ethernet sub-standards defined by the IEEE TSN task group. These standards enable deterministic real-time communication over Ethernet. In some embodiments, even in the presence of WiFi, ACM 104 attempts to ensure reliability by simultaneously using LTE or 5G to meet the SLA requirements.

[0060] Bandwidth Utilization Manager (BIM 106)

[0061] The Bandwidth Utilization Manager (BUM) 106 adapts the bandwidth utilization to attempt to meet one or more of several criteria such as: network cost (e.g., data plan limits), the exact throughput required, real-time requirements, power consumption constraints, etc. BUM 106 analyzes the data received from sensors (e.g., through DPI, or from the metadata incorporated into each received packet).

[0062] Based on the inspection results, BUM 106 can take one or more of several actions:

[0063] In one embodiment, if the data does not show real-time service demand, there is no real-time SLA, and the only available connectivity is cellular with a limited data plan, then BUM 106 buffers the data for delayed transmission during off-peak / low-cost times (e.g., midnight), or for delayed transmission until more data to be transmitted in an aggregated transmission is received.

[0064] In one embodiment, if the data packet is small (such as a few thousand bytes), and the available network interface is broadband, then BUM 106 allocates dedicated bandwidth for the data, and the dedicated bandwidth is limited by the data size. To do this, BUM 106 applies immediate bandwidth throttling techniques.

[0065] In one embodiment, if several data packets are simultaneously received by an edge device from multiple sensors and through different network interfaces (e.g., WiFi, ) for transmission to the cloud via a cellular interface, then BUM 106 sends all the packets simultaneously to the cloud over that cellular interface while complying with the SLA. This can occur by allocating dedicated bandwidth to each packet (bandwidth splitting).

[0066] In some embodiments, as further detailed below, BUM 106 attempts to meet the SLA bandwidth requirements of a given device by borrowing bandwidth from at least one peer device. In some embodiments, as further detailed below, BUM106 attempts to meet the SLA bandwidth requirements of a given device or sensor by throttling at least one peer device.

[0067] Implement CM, ACM, and BUM

[0068] In some embodiments, CM 102, ACM 104, and BUM 106 are present together in one edge device. In some embodiments, any one of CM 102, ACM 104, and BUM 106 is present in a stand-alone device. The choice of how to implement the components depends on the required level of intelligence and the capacity of each edge device.

[0069] In some embodiments, ACM 104 and BUM 106 are present in one device, while PA 108 is a separate module that acts as these two modules. In other embodiments, ACM 104 and BUM 106 each have their own integrated packet analyzer module.

[0070] In some embodiments, if all of CM 102, ACM 104, and BUM 106 are present in a device simultaneously, they operate in a coordinated manner as follows: (i) CM 102 is the first module to trigger the connectivity management state upon receiving a packet; (ii) ACM 104 makes a decision on the transport interface; and (iii) BUM 106 performs arbitration on the transport interface.

[0071] Figure 2 FIG. is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments. As shown, IoT community 100 includes brownfield device 204, which includes several IoT functional entities: sensors 208, IoT devices 210, and hubs 214A - 214D, as well as device hub 216 and IoT devices 218A - 218B. IoT community 200 also includes greenfield device 206, which includes several IoT functional entities: device hub 202 and IoT devices 222A - 222B, sensor hub 224, and sensors 226A - 226D, IoT device 228, and sensor 230. Brownfield device 204 and greenfield device 206 are illustrated by a dashed region, which is merely an abstract identifier for grouping them: the dashed line does not represent any physical arrangement or relationship; by way of non - limitation, IoT functional entities 208 - 230 can be arranged at any distance from each other.

[0072] As shown, connectivity service level orchestrator and arbiter 202 is connected to cloud 232 via one of four paths: through fog node 234, through edge node 240, via a multi - hop path through peer nodes 236 and 238, or a direct connection. In operation, depending on which path is most suitable for the SLA cost and performance of its constituent IoT functional entities, connectivity service level orchestrator and arbiter 202 can select any of these four paths to exchange data with cloud 232. For example, due to cost considerations, the multi - hop path through peer nodes 236 and 238 can be used instead of (or in addition to) a direct connection. For example, a direct connection may provide better performance and thus be selected over a path through fog node 234.

[0073] As used herein, "brownfield" describes billions of existing devices and legacy software applications that perform discrete functions in isolation. In some embodiments, connectivity service level orchestrator and arbiter 202 is external to brownfield device 204 and is wirelessly connected to brownfield device 204.

[0074] In some embodiments, a brownfield device includes a processor, a memory, a network interface, and a non-transitory computer-readable medium that includes instructions that, when loaded and executed by the processor, cause the brownfield device to interact with a connectivity service level orchestrator and arbiter 202 according to embodiments disclosed herein.

[0075] In some embodiments, a brownfield device such as a thermostat or a washing machine may be electronically controlled but lack networking capabilities. In such cases, the brownfield device may be coupled to a hardware device that includes processing circuitry and a network interface and that enables the brownfield device to communicate with and be controlled by a connectivity service level orchestrator and arbiter 202 according to embodiments disclosed herein.

[0076] On the other hand, “greenfield” describes devices that are built from scratch to leverage IoT. In some embodiments, a connectivity service level orchestrator and arbiter 202 is external to a greenfield device 206, which is wirelessly connected to the connectivity service level orchestrator and arbiter 202. In some embodiments, the greenfield device includes at least part of the circuitry of the connectivity service level orchestrator and arbiter 202, such as a packet analyzer.

[0077] Figure 3 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments. Here, the IoT community is an exemplary residence 302, which is shown as including IoT (wireless) functional entities 306 - 330. In operation, the IoT (wireless) functional entities 306 - 330 are used to wirelessly connect to a connectivity service level orchestrator and arbiter 304, which is similar to the connectivity service level orchestrator and arbiter discussed and shown with reference to Figure 1 The IoT (wireless) functional entities 306 - 330 are used to communicate with the connectivity service level orchestrator and arbiter 304 using any one or more of the wireless technologies (sometimes referred to as wireless protocols) shown and discussed with reference to Figure 6 In this way, Figure 3 embodiments of

[0078] The IoT platform 302 illustrates exemplary brownfield or greenfield devices that are coupled to the Connectivity Service Level Orchestrator and Arbiter 304 and are capable of receiving commands from the cloud and, in some embodiments, also providing acknowledgments or status back to the cloud. Some of the IoT (wireless) functional entities are sensors for sensing local physical or electrical phenomena and reporting the results to the cloud.

[0079] Physical Phenomenon Sensor:

[0080] One class of IoT devices (IoT functional entities) and sensors supported by the embodiments disclosed herein includes wireless sensors for detecting physical phenomena such as light, heat, temperature, barometric pressure, pH level, altitude, location, radioactivity, carbon monoxide, carbon dioxide, and methane, to name just a few examples. Figure 3 Illustrated are exemplary IoT physical phenomenon sensors: water heater temperature sensor 312, bedroom smoke detector 322, and bedroom carbon monoxide detector 324. In some of the disclosed embodiments, the Connectivity Service Level Orchestrator and Arbiter 304 collects wireless sensor data via a local area network (LAN) and transmits the wireless sensor data to the cloud 332, which may include the Internet or other wide area network (WAN). It should be understood that the embodiments disclosed herein are not intended to limit the scope of the invention to any particular set of IoT functional entities.

[0081] Electrical / Acoustic Sensor:

[0082] Another class of IoT devices (IoT functional entities) supported by the embodiments disclosed herein includes wireless sensors for detecting electrical, electromagnetic, and / or acoustic phenomena and for relaying the detected phenomena to the Connectivity Service Level Orchestrator and Arbiter 304 and thus to the cloud 332, such as wireless signal strength, radio signal strength, battery level, static current or voltage, to name just a few examples. Figure 3 Illustrated is a signal strength detector 330 that measures and provides one or more of the following: WiFi (IEEE 802.11) signal strength, cellular spectrum signal strength (e.g., 1900 cellular band using frequencies in the range of 1840 - 1990 and PCS 800 MHz band using frequencies in the range of 802 - 894), radio signal strength (e.g., AM radio using a 10 kHz band within the frequencies in the range of 535 - 1650 kHz and FM radio using frequencies in the range of 88 - 108 MHz). It should be understood that the embodiments disclosed herein are not intended to limit the scope of the invention to any particular set of IoT functional entities.

[0083] Control Device:

[0084] Another class of IoT devices (IoT functional entities) supported by the embodiments herein includes a wireless controller that is configured to receive commands from the cloud via a connectivity service level orchestrator and arbiter 304 and optionally provide an acknowledgement and / or status to the cloud via the connectivity service level orchestrator and arbiter 304. Figure 3 Illustrated are wireless controllers for the following operations: wireless controller 306 for unlocking a front door; wireless controller 308 for operating a garage door opener; wireless controller 310 for remotely starting a vehicle; wireless controller 314 for controlling a coffee maker; wireless controller 316 for controlling a dishwasher; wireless controller 318 for controlling a thermostat; wireless controller 320 for controlling lights; and wireless controllers 326, 328 for controlling a washer and dryer. In some embodiments, the controlled IoT devices (wireless devices) provide status and / or acknowledgement to the connectivity service level orchestrator and arbiter 304. In some embodiments, the wirelessly controlled thermostat 318 communicates with the connectivity service level orchestrator and arbiter 304 to provide the current temperature as status and provide an acknowledgement upon receipt of a command. It should be understood that the embodiments disclosed herein are not intended to limit the scope of the present invention to any particular set of IoT devices (IoT functional entities).

[0085] Figure 4 is a block diagram of an IoT community using a connectivity service level orchestrator and arbiter according to some embodiments. The IoT community in the illustrated embodiment is an office building 400, which is an example of an IoT community and is shown to include IoT (wireless) devices 402 - 414 that are configured to wirelessly and locally connect to a connectivity service level orchestrator and arbiter 416 in operation, and the connectivity service level orchestrator and arbiter 416 includes components identical to those discussed and illustrated with reference to Figure 1 The IoT (wireless) devices 402 - 414 are configured to communicate with the connectivity service level orchestrator and arbiter 416 using any one of the wireless technologies (sometimes referred to herein as wireless protocols) illustrated and discussed with reference to Figure 6 As shown, the IoT community 400 includes sensors for sensing physical phenomena (e.g., motion sensor 402), sensors for sensing electrical and acoustic phenomena (e.g., audio / video sensor 408, server farm health sensor 412 located in the conference room 406), and IoT control devices (e.g., air conditioner control 404, controller for exercise equipment in the fitness center 410, and control of appliances in the kitchen and café 414). In this manner,

[0086] Figure 4 ​Embodiments allow a remote operator on a WAN, such as cloud 418, to remotely control a local community of IoT devices and remotely monitor a local community of IoT sensors.

[0087] Figure 5 FIG. is a block diagram of an IoT community that utilizes a connectivity service level orchestrator and arbiter, in accordance with some embodiments. As shown, the IoT community 550 is coupled to the cloud 570 using a connectivity service level orchestrator and arbiter 568. As shown, the IoT community 550 is a virtual reality environment that includes a user 560, a computer 558, a chair 564, and a plurality of IoT devices and sensors, the plurality of IoT devices and sensors including a virtual reality headset 566, a handheld input controller 552, a headset and controller tracking device 554, a room camera 556, and a body motion capture device 562.

[0088] The IoT community 550 illustrates an example of a real-time requirement: a remote player needs to observe the position of the user. If the real-time requirement is not met, the multi-player virtual world will get out of sync. In some embodiments, users enter into a service level agreement to pay to use the IoT community 550, and in return, these users are guaranteed a certain amount of bandwidth and / or latency.

[0089] In some embodiments, the IoT devices and sensors in the IoT community 550 have various different SLA requirements, data requirements, and use different protocols and technologies. In some embodiments, each of the IoT devices and sensors (IoT functional entities) in the IoT community 550 subscribes to a different SLA that specifies bandwidth and latency requirements. In some embodiments, each of the IoT devices and sensors (IoT functional entities) in the IoT community 550 uses a different communication protocol, e.g., one of the protocols illustrated and described with reference to Figure 6 FIG. and described. In some embodiments, each of the IoT devices and sensors (IoT functional entities) in the IoT community 550 has different data requirements; for example, some devices need to transmit data in real time, while other devices may need to transmit mission-critical data.

[0090] In some embodiments, the connectivity service level orchestrator and arbiter 568 dynamically connects the various IoT devices and sensors in the IoT community 550 to the cloud 570 according to various different communication protocols and arbitrates between the IoT devices and sensors in order to attempt to meet the various SLA bandwidth and latency requirements.

[0091] In some embodiments, the Connectivity Service Level Orchestrator and Arbiter 568 dynamically switches to different radio or network technologies to meet the bandwidth and latency requirements of a particular IoT device SLA. For example, in some embodiments, the virtual reality headset 566 subscribes to an SLA that specifies mission-critical real-time bandwidth and latency requirements to avoid lags in visible motion that could potentially cause motion sickness. In some embodiments, the Connectivity Service Level Orchestrator and Arbiter 568 employs one or more of the strategies further described with reference to Figure 8 to meet the SLA requirements of the virtual reality headset 566.

[0092] Figure 6 is a block diagram illustrating wireless communication technologies supported by a Connectivity Service Level Orchestrator and Arbiter according to some embodiments. As shown, the IoT community 600 includes a Connectivity Service Level Orchestrator and Arbiter 602, which includes the same components as those discussed and illustrated with reference to Figure 1 —NIC, CM, ACM, BUM, PA. As shown, the wireless devices 620 - 640 include wireless communication capabilities according to a variety of different radio technologies, which different radio technologies include 620, Bluetooth Low Energy (BLE) 622, Long Term Evolution (LTE) 624, Universal Mobile Telecommunications Service (UTMS) 626, Global System for Mobile Communications (GSM) 628, Second Generation Wireless Protocol (2G) 630, Third Generation Wireless Protocol (3G) 628, Fourth Generation Wireless Protocol (4G) 634, Near Field Communication (NFC) 636, 638, and protocols standardized by the Institute of Electrical and Electronics Engineers (IEEE) under IEEE 802. IEEE 802 protocols relevant to wireless devices include at least IEEE 802.11, IEEE 802.16, and IEEE 802.18, to name a few. In operation, each of the IoT functional entities is connected to the cloud 618 via the Connectivity Service Level Orchestrator and Arbiter 602. It will be understood that Figure 6 the exemplary wireless communication protocols illustrated are only intended to be illustrative and are not intended to limit the scope of the invention to any particular one or more protocols. Having the ability to conform to a large number of wireless technologies is beneficial because the disclosed Connectivity Service Level Orchestrator and Arbiter 602 can be used with a wide variety of IoT functional entities using Figure 6 any of the wireless communication technologies disclosed.

[0093] Figure 7is a flowchart of a process for execution by a connectivity service level orchestrator and arbiter, according to some embodiments. In some embodiments, process 700 is for execution by a virtual machine implementation of a connectivity service level orchestrator and arbiter. For example, referring to Figure 1 , connectivity manager 102, adaptive connectivity manager (ACM) 104, bandwidth utilization manager (BUM) 106, and packet analyzer 116 may each be implemented as a virtual machine and executed on a processor that supports virtual machines.

[0094] In other embodiments, process 700 is for execution by an edge device, which as used herein refers to a device for connecting a local area network (LAN) or personal area network (PAN) to a wide area network (WAN). In some embodiments, the LAN and PAN include multiple IoT functional entities, and the WAN includes the Internet. Figure 4 An example of such a configuration is shown, as IoT community 400 represents the LAN and the connection to cloud 418 represents the WAN.

[0095] As shown, after process 700 starts, at 702, the connectivity manager is used to monitor one or more wireless interfaces that communicate using multiple protocols, activate the first interface after detecting a need to exchange data on the first interface, and power down the second interface after a threshold amount of idle time.

[0096] At 704, the packet analyzer is used to extract packet metadata from one or more data streams and determine the latency experienced by and the bandwidth utilized by the one or more data streams based on the packet metadata. In a packet-switched network, and as used herein, a "data stream" is a sequence of data packets from a source device (such as an IoT functional entity) to a destination (such as a location on the cloud). As used in this disclosure, a "data stream" may sometimes refer to a "traffic flow" or "packet flow" or "network flow". As used herein, "packet metadata" refers to information that describes a packet. Packet metadata is often included in the header of each packet and may include fields such as: destination port, source port, header length, total length, protocol, checksum, and packet options. A timestamp stored in the packet header may be used to measure packet latency, for example, by comparing the timestamp inserted by the packet source with the timestamp at the packet destination.

[0097] At 706, an Adaptive Connectivity Manager (ACM) is used to apply a latency reduction policy in an attempt to make the experienced latency conform to the latency criteria specified by the SLA of the associated IoT functional entity. In some embodiments, the SLA latency requirements are included in packet metadata. In some embodiments, the SLA latency requirements of the IoT functional device are stored in a memory and accessed by the ACM. Figure 8 And its associated description describes a process for execution by the ACM according to some embodiments, including the application of a latency reduction policy.

[0098] At 708, a Bandwidth Utilization Manager (BUM) is used to apply a bandwidth reduction policy in an attempt to make the utilized bandwidth conform to the bandwidth criteria specified by the SLA of the associated IoT functional entity. In some embodiments, the SLA bandwidth requirements are included in packet metadata. In some embodiments, the SLA bandwidth requirements of the IoT functional device are stored in a memory and accessed by the ACM. Figure 9 And its associated description describes a process for execution by the BUM according to some embodiments, including the application of a bandwidth reduction policy.

[0099] Figure 8 Is a flowchart illustrating a process for execution by an Adaptive Connectivity Manager of a Connectivity Service Level Orchestrator and Arbiter according to some embodiments. As shown, after starting, at 802, the Adaptive Connectivity Manager is used to determine whether there are any more flows to service. If not, the process ends. Otherwise, at 804, the Adaptive Connectivity Manager is used to determine the latency experienced by one or more data flows and the latency criteria for the one or more data flows. At 806, the Adaptive Connectivity Manager is used to determine whether the experienced latency conforms to the latency criteria. If so, the Adaptive Connectivity Manager is used to update a counter and a pointer (not shown) to move to the next flow, and the process returns to 802 to determine whether there are more data flows to service.

[0100] Otherwise, if it is determined at 806 that the latency criteria are not met, at 808, the Adaptive Connectivity Manager is used to determine whether there is still a latency reduction policy available to attempt to meet the criteria. If not, a fault is generated at 811.

[0101] Optionally, before generating the fault, at 810, the Adaptive Manager is used to back off and try again. To back off, in some embodiments, the Adaptive Connectivity Manager is used to relax the latency criteria, for example, by switching to a lower-cost and lower-performance service level protocol, and return to 806. If the experienced latency still does not meet the criteria after backing off, a fault is generated at 810.

[0102] If it is determined at 808 that there are still latency reduction strategies to be attempted, the illustrated embodiment includes five available latency reduction strategies described at 812, 814, 816, 818, and 820, which may not be attempted in a particular order. Some embodiments provide more latency reduction strategies. Some embodiments provide fewer latency reduction strategies.

[0103] At 812, the adaptive connectivity manager is used to simultaneously send the same data packet through multiple interfaces and discard redundant packets. In this way, the fastest interface among the multiple interfaces will be selected, potentially reducing the total latency experienced by the data stream.

[0104] At 814, the adaptive connectivity manager is used to relay one or more data streams using different lower-latency protocols. For example, the adaptive connectivity manager may use IEEE 802.11 instead of the 3G cellular protocol; IEEE 802.11 provides an order of magnitude higher bandwidth than 3G and would be expected to also have a lower latency for the data stream. In this way, the data stream will utilize an interface expected to have a lower latency, thereby potentially reducing the latency experienced by the data stream.

[0105] At 816, the adaptive connectivity manager is used to relay one or more data streams using different lower-latency interfaces. In some embodiments, different interfaces are empirically selected by maintaining and analyzing data transfer rate statistics experienced by various interfaces and selecting the fastest one.

[0106] At 818, the adaptive connectivity manager is used to borrow some bandwidth from at least one peer device. In some embodiments, the adaptive connectivity manager assigns a rank to each of the IoT devices, and the IoT devices with a higher rank are given a higher priority. In some embodiments, the adaptive connectivity manager attempts to meet the SLA bandwidth requirements of the IoT devices with a higher rank, even if doing so sacrifices the SLA bandwidth requirements of the IoT devices with a lower rank. In some embodiments, instead of assigning a specific rank, each IoT device is grouped into one of multiple service layers, and the IoT devices in the higher-ranked layers are given a higher share of the bandwidth than the IoT devices in the lower-ranked layers.

[0107] At 820, an adaptive connectivity manager is used to throttle at least one peer device. In some embodiments, for example, the adaptive connectivity manager throttles IoT devices in lower-ranked layers to comply with the SLA bandwidth requirements of higher-ranked IoT devices. In some embodiments, an IoT device broadcasts an SOS signal to indicate a need for more bandwidth or lower latency, and the adaptive connectivity manager responds to that need. In some embodiments, the adaptive connectivity manager asserts a DEAD_STOP signal to an IoT device or sensor (which may be a lower-ranked IoT device or sensor) to throttle that device or sensor or reduce the bandwidth utilized by that device or sensor.

[0108] At 822, the adaptive connectivity manager is optionally used to allow some time to elapse before measuring latency again. Figure 8 A dashed outline is used to denote the optional nature of this action. At 824, the adaptive connectivity manager is used to measure again the latency experienced by one or more data streams. Subsequently, the process returns to 808 to determine whether the latency experienced complies with the latency criteria.

[0109] Figure 9 is a flowchart illustrating a process for execution by a bandwidth utilization manager (BUM) of a connectivity service level orchestrator and arbiter according to some embodiments. As shown, after starting, at 902, the BUM is used to determine whether there are any more streams to service. If not, the process ends. Otherwise, at 904, the BUM is used to determine the bandwidth utilized by one or more data streams and the bandwidth criteria for the one or more data streams. At 906, the BUM is used to determine whether the utilized bandwidth complies with the bandwidth criteria. If so, the BUM is used to update a counter and pointer (not shown) to move to the next stream, and the process returns to 902 to determine whether any more data streams are to be serviced.

[0110] Otherwise, if the bandwidth criteria are not met, at 908, the BUM is used to determine whether there is still a bandwidth reduction strategy to attempt to comply with the criteria. If not, a fault is generated at 911.

[0111] Optionally, before generating the fault, at 910, the BUM is used to back off and try again. To back off, in some embodiments, the adaptive connectivity manager is used to relax the bandwidth criteria, for example, by switching to a lower-cost and lower-performance service level agreement, and return to 906. If the utilized bandwidth still does not meet the criteria after backing off, a fault is generated at 911.

[0112] If it is determined at 908 that there are still bandwidth reduction strategies to be attempted, the illustrated embodiment includes five available bandwidth reduction strategies described at 912, 914, 916, 918, and 920, which will not necessarily be attempted in a specific order. Some embodiments provide more bandwidth reduction strategies. Some embodiments provide fewer bandwidth reduction strategies, while other embodiments provide more bandwidth reduction strategies.

[0113] At 912, BUM is used to buffer non-mission-critical data packets of one or more data streams for later transmission during non-peak hours. In this way, one or more data streams will not transmit data during peak hours, thereby potentially reducing the bandwidth utilized during peak hours.

[0114] At 914, BUM is used to throttle the bandwidth of packets generated at the source of one or more data streams. To throttle this bandwidth, in some embodiments, BUM is used to indirectly do so by refusing to accept data packets at a rate greater than a threshold rate. In some embodiments, the source of the data stream will slow down the data rate in response to repeated non-acknowledgment responses. In other embodiments, BUM is used to indirectly throttle the bandwidth by sending a message requesting a reduction in the data rate to the source of the data stream.

[0115] At 916, BUM is used to relay one or more data streams using a different lower-bandwidth interface. In some embodiments, different interfaces are empirically selected by analyzing the data transfer rates experienced by various interfaces and selecting the fastest one.

[0116] At 918, BUM is used to borrow some bandwidth from at least one peer device. In some embodiments, BUM assigns a rank to each of the IoT devices and gives higher priority to IoT devices with a higher rank. In some embodiments, BUM attempts to meet the SLA bandwidth and latency requirements of IoT devices with a higher rank, even if doing so sacrifices the SLA bandwidth requirements of IoT devices with a lower rank. In some embodiments, instead of assigning a specific rank, each IoT device is grouped into one of multiple service layers, and IoT devices in a higher-ranked layer are given a higher share of the bandwidth than IoT devices in a lower-ranked layer.

[0117] At 920, the BUM is used to throttle at least one peer device. In some embodiments, for example, the BUM throttles IoT devices in lower-ranked layers to comply with the SLA bandwidth requirements of higher-ranked IoT devices. In some embodiments, the IoT device broadcasts an SOS signal to indicate a need for more bandwidth or lower latency, and the BUM responds to that need. In some embodiments, the BUM asserts a DEAD_STOP signal to an IoT device or sensor (which may be a lower-ranked IoT device or sensor) to throttle that device or sensor or reduce the bandwidth utilized by that device or sensor.

[0118] At 922, the BUM is optionally used to allow some time to elapse before measuring the bandwidth again. Figure 9 The optional nature of this action is expressed using a dashed outline. At 924, the BUM is used to measure again the bandwidth utilized by one or more data streams. Subsequently, the process returns to 908 to determine whether the utilized bandwidth meets the bandwidth criteria.

[0119] Internet of Things

[0120] Figure 10 An example domain topology of various Internet of Things (IoT) networks coupled via a link to respective gateways is illustrated. The Internet of Things (IoT) is the concept in which a large number of computing devices are interconnected to each other and to the Internet in order to provide functionality and data collection at a very low level. Thus, as used herein, an IoT device can include a semi-autonomous device that performs functions such as sensing or controlling, etc., and communicates with other IoT devices and a wider network such as the Internet.

[0121] IoT devices are often limited in memory, size, or functionality, thus allowing a larger number of devices to be deployed to achieve a similar cost to a smaller number of larger devices. However, an IoT device can be a smart phone, a laptop device, a tablet, or a PC, or another larger device. Additionally, an IoT device can be a virtual device, such as an application on a smart phone or other computing device. IoT devices can include IoT gateways that are used to couple IoT devices to other IoT devices and to cloud applications for data storage, process control, etc.

[0122] The network of IoT devices can include commercial and home automation devices such as water supply systems, power distribution systems, plumbing control systems, factory control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, etc. IoT devices can be accessible via remote computers, servers, and other systems so as to control systems or access data, for example.

[0123] Future growth of the Internet and similar networks can involve a very large number of IoT devices. Accordingly, in the context of the technologies discussed herein, a great deal of innovation for such future networking will address the need for all of these layers to grow without barriers, discover and make accessible connected resources, and support the ability to hide and segregate connected resources. Any number of network protocols and communication standards can be used, where each protocol and standard is designed to address specific goals. In addition, protocols are part of the fabric that enables human-accessible services to operate regardless of location, time, or space. Innovation includes: service delivery and associated infrastructure, such as hardware and software; security enhancements; and service provisioning based on quality of service (QoS) terms specified in service level and service delivery protocols. As will be understood, the use of IoT devices and networks such as those introduced in Figure 10 and Figure 11 presents a number of new challenges in heterogeneous connectivity networks that include a combination of wired and wireless technologies.

[0124] Figure 10 Specifically provided is a simplified diagram of a domain topology for a large number of Internet of Things (IoT) networks, the large number of IoT networks including IoT devices 1004, and IoT networks 1056, 1058, 1060, 1062 being coupled to respective gateways 1054 via backbone links 1002. For example, a large number of IoT devices 1004 can communicate with gateway 1054 and can communicate with each other via gateway 1054. To simplify the diagram, not every IoT device 1004 or communication link (e.g., link 1016, 1022, 1028, or 1032) is labeled. Backbone link 1002 can include any number of wired or wireless technologies (including optical networks) and can be part of a local area network (LAN), wide area network (WAN), or the Internet. In addition, such communication links facilitate an optical signal path between both IoT devices 1004 and gateway 1054, including the use of multiplexing / demultiplexing components that facilitate the interconnection of various devices.

[0125] The network topology can include any number of different types of IoT networks, such as those using A mesh network provided for low energy (BLE) link 1022. Other possible types of IoT networks include: a wireless local area network (WLAN) network 1058 for communicating with IoT device 1004 via an IEEE 802.11 (Wi-Fi) link 1028; a cellular network 1060 for communicating with IoT device 1004 via an LTE / LTE-A (4G) or 5G cellular network; a low power wide area (LPWA) network 1062, e.g., an LPWA network compatible with the LoRaWAN specification published by the LoRa Alliance; or IPv6 over a low power wide area network (LPWAN) network, which is compatible with the specification published by the Internet Engineering Task Force (IETF). In addition, each IoT network can use any number of communication links to communicate with an external network provider (e.g., a layer 2 or layer 3 provider), such communication links such as, an LTE cellular link, an LPWA link, or a link based on the IEEE 802.15.4 standard (such as, ). Each IoT network can also operate with the use of various network and internet application protocols (such as, the Constrained Application Protocol (CoAP)). Each IoT network can also be integrated with coordinator devices that provide a chain of links that form a cluster tree of linked devices and networks.

[0126] Each of these IoT networks can provide opportunities for new technology features (such as those described herein). Improved technologies and networks can enable exponential growth of devices and networks, including using IoT networks as fog devices or fog systems. As the use of such improved technologies grows, IoT networks can be developed without direct human intervention to achieve self-management, functional evolution, and collaboration. Improved technologies can even enable IoT networks to operate without a centralized controlled system. Accordingly, the improved technologies described herein can be used to automate and enhance network management and operation functions far beyond current implementations.

[0127] In an example, communication between IoT devices 1004 (such as on backbone link 1002) can be protected by a decentralized system for authentication, authorization, and accounting (AAA). In a decentralized AAA system, distributed payment, credit, auditing, authorization, and authentication systems can be implemented across an interconnected heterogeneous network infrastructure. This allows the system and network to move towards autonomous operation. In these types of autonomous operations, machines can even enter into human resource contracts and negotiate partnerships with other machine networks. This can allow for common goals and balanced service delivery for a general planned service level agreement, and enable solutions that provide metering, measurement, traceability, and trackability. The emergence of new supply chain structures and methods can enable a large number of services to be generated, have value mined, and collapse without any human involvement.

[0128] Such IoT networks can be further enhanced by integrating sensing technologies (such as sound, light, electronic traffic, face and pattern recognition, smell, vibration) into the self-organization among IoT devices. The integration of the sensing system can allow for systematic and autonomous communication and coordination for service delivery targeting contract service goals, clustering based on orchestration and quality of service (QoS), and resource fusion. Some of the individual examples of network-based resource processing include the following examples.

[0129] The mesh network 1056 can be enhanced, for example, by a system that performs serial data-to-information transformation. For example, a self-forming chain of processing resources including a multi-link network can distribute the transformation of raw data to information, the ability to distinguish between assets and resources, and the associated management of each in an efficient manner. In addition, trust and service indices of appropriate components based on infrastructure and resources can be inserted to improve data integrity, quality, assurance, and deliver data confidence metrics.

[0130] The WLAN network 1058 can use, for example, a system that performs standard conversion to provide multi-standard connectivity, thus enabling IoT devices 1004 that communicate using different protocols. Further systems can provide seamless inter-connectivity across a multi-standard infrastructure that includes visible Internet resources and hidden Internet resources.

[0131] Communication in the cellular network 1060 can be enhanced, for example, by a system that offloads data, a system that extends communication to more remote devices, or both a system that offloads data and a system that extends communication to more remote devices. The LPWA network 1062 can include a system that performs non-Internet Protocol (IP) to IP interconnection, addressing, and routing. In addition, each of the IoT devices 1004 can include an appropriate transceiver for wide-area communication with that device. Further, each IoT device 1004 can include additional transceivers for communicating using additional protocols and frequencies.

[0132] Finally, a cluster of IoT devices can be equipped to communicate with other IoT devices as well as with a cloud network. This can allow the IoT devices to form an ad-hoc network among multiple devices, thus allowing them to act as a single device, which can be referred to as a fog device. This configuration is further discussed below with reference to Figure 11 to discuss this configuration.

[0133] Figure 11The figure shows a cloud computing network that communicates with a mesh network of IoT devices (device 1102) operating as fog devices at the edge of the cloud computing network. The mesh network of IoT devices can be referred to as fog 1120 operating at the edge of cloud 1100. To simplify the illustration, not every IoT device 1102 is labeled.

[0134] Fog 1120 can be regarded as a large-scale interconnected network where a large number of IoT devices 1102 communicate with each other, for example, via radio links 1122. As an example, this interconnected network can be facilitated using the interconnection specifications published by the Open Connectivity Foundation TM (OCF). This standard allows devices to discover each other and establish communication for interconnection. Other interconnection protocols can also be used, including, for example, the Optimized Link State Routing (OLSR) protocol, or the Better Approach to Mobile Ad-hoc Networking (B.A.T.M.A.N) routing protocol, or the OMA Lightweight M2M (LWM2M) protocol, and so on.

[0135] In this example, three types of IoT devices 1102 are shown, namely, gateway 1104, data aggregator 1126, and sensor 1128, but any combination of IoT devices 1102 and functions can be used. Gateway 1104 can be an edge device that provides communication between cloud 1100 and fog 1120, and can also provide backend processing functions for data obtained from sensors 1128, such as motion data, stream data, temperature data, etc. Data aggregator 1126 can collect data from any number of sensors 1128 and perform backend processing functions for analysis. The results, raw data, or both can be passed to cloud 1100 via gateway 1104. Sensor 1128 can be a complete IoT device 1102, for example, capable of both collecting and processing data. In some cases, sensor 1128 may be more functionally restricted, for example, collecting data and allowing data aggregator 1126 or gateway 1104 to process the data.

[0136] Communications from any IoT device 1102 can be passed along a convenient path (e.g., the most convenient path) between any of the devices in IoT device 1102 to reach gateway 1104. In these networks, the number of interconnections provides a large amount of redundancy, thus allowing communication to be maintained even in the case of the loss of a large number of IoT devices 1102. In addition, the use of a mesh network can allow the use of IoT devices 1102 with very low power or located at a certain distance from the infrastructure, because the range of connection to another IoT device 1102 may be much smaller than the range of connection to gateway 1104.

[0137] The fog 1120 provided by these IoT devices 1102 can be presented to devices in the cloud 1100 (such as, server 1106) as a single device located at the edge of the cloud 1100, e.g., a fog device. In this example, an alert from the fog device can be sent without being recognized as coming from a specific IoT device 1102 within the fog 1120. In this way, the fog 1120 can be regarded as a distributed platform that provides computing and storage resources to perform processing or data-intensive tasks (such as, data analysis, data aggregation, and machine learning, etc.).

[0138] In some examples, an imperative programming style can be used to configure the IoT devices 1102. For example, each IoT device 1102 has a specific function and communication partner. However, the IoT devices 1102 that form the fog device can be configured in a declarative programming style, allowing the IoT devices 1102 to reconfigure their operations and communications, such as, determining the required resources in response to conditions, queries, and device failures. As an example, a query from a user located at the server 1106 regarding the operation of a subset of the equipment monitored by the IoT devices 1102 can cause the fog 1120 devices to select the IoT devices 1102 required to answer the query, such as, a specific sensor 1128. Subsequently, before the data from these sensors 1128 is continued to be sent by the fog 1126 devices to the server 1106 to answer the query, the data from these sensors 1128 can be aggregated and analyzed by any combination of the sensor 1128, the data aggregator 1128, or the gateway 1104. In this example, the IoT devices 1102 in the fog 1120 can select the sensors 1128 to be used based on the query, such as, adding data from a traffic sensor or a temperature sensor. Additionally, if some of the IoT devices 1102 are inoperable, other IoT devices 1102 in the fog 1120 devices can provide similar data (if available).

[0139] In other examples, the operations and functions of the embodiments described herein may be embodied by a machine of the IoT device in the form of an example of an electronic processing system, within which a set of executable instruction sequences enables the electronic processing system to perform any of the methods discussed herein according to example embodiments. The machine may be an IoT device or an IoT gateway, including a machine embodied by multiple aspects of the following: a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile phone or a smart phone, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. Further, although only a single machine is depicted and referenced in the above examples, such a machine should also be considered to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein. Additionally, these examples and similar examples of processor-based systems should be considered to include any collection of one or more machines controlled or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methods discussed herein.

[0140] Figure 12 FIG. A diagram of a cloud computing network or cloud 1200 communicating with a large number of Internet of Things (IoT) devices. Cloud 1200 may represent the Internet, or may be a local area network (LAN), or a wide area network (WAN), such as a private network for a company. IoT devices may include any number of different types of devices grouped in various combinations. For example, traffic control group 1206 may include IoT devices along the streets in a city. These IoT devices may include red lights, traffic flow monitors, cameras, weather sensors, and so on. Traffic control group 1206 or other subgroups may communicate with cloud 1200 via a wired or wireless link 1208 (such as an LPWA link, an optical link, etc.). Additionally, a wired or wireless subnet 1212 may allow IoT devices to communicate with each other via a local area network, a wireless local area network, etc. IoT devices may use another device (such as gateway 1310 or 1328) to communicate with a remote location (such as cloud 1300); IoT devices may also use one or more servers 1330 to facilitate communication with cloud 1300 or with gateway 1310. For example, one or more servers 1330 may act as intermediate network nodes to support local edge cloud or fog implementations between local area networks. Additionally, the depicted gateway 1328 may operate in a cloud-gateway-many edge devices configuration such as with various IoT devices 1314, 1320, 1324, and the various IoT devices 1314, 1320, 1324 are constrained or dynamic with respect to the allocation and use of resources in cloud 1300.

[0141] Other example groups of IoT devices can include remote weather stations 1214, local information terminals 1216, alarm systems 1218, automated teller machines 1220, alarm panels 1222, or mobile vehicles such as emergency vehicles 1224 or other vehicles 1226, and so on such examples. Each of these IoT devices can communicate with other IoT devices, with the server 1204, with another IoT fog device or system (not shown but depicted in Figure 11 ), or with a combination thereof. These groups of IoT devices can be deployed in a variety of residential, commercial, and industrial settings, including both private and public environments.

[0142] As can be seen from Figure 12 , a large number of IoT devices can communicate through the cloud 1200. This can allow different IoT devices to autonomously request information or provide information to other devices. For example, a group of IoT devices (such as the traffic control group 1206) can request the current weather forecast from a group of remote weather stations 1214 that can provide forecasts without human intervention. In addition, an automated teller machine 1220 can alert an emergency vehicle 1224 that a theft is in progress. As the emergency vehicle 1224 continues to travel towards the automated teller machine 1220, it can access the traffic control group 1206 to request clearing of the location, for example, by turning on a red light for a sufficient amount of time to stop the cross traffic flow at an intersection, so that the emergency vehicle 1224 can enter the intersection unobstructed.

[0143] Clusters of IoT devices (such as remote weather stations 1214 or traffic control groups 1206) can be equipped to communicate with other IoT devices as well as with the cloud 1200. This can allow IoT devices to form an ad-hoc network among multiple devices, thereby allowing them to act as a single device, which can be referred to as a fog device or system (for example, as described above with reference to Figure 11 ).

[0144] Figure 13 is a block diagram of an example of components that can be present in an IoT device 1350 for implementing the techniques described herein. The IoT device 1350 can include any combination of the components shown or referenced in the above disclosure examples. These components can be implemented as ICs, multiple parts of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations suitable for the IoT device 1350, or as components otherwise incorporated within the chassis of a larger system. In addition, Figure 13 The block diagram of is intended to depict a high-level view of the components of the IoT device 1350. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the shown components may occur in other implementations.

[0145] The IoT device 1350 may include a processor 1352, which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, or other known processing elements. The processor 1352 may be part of a system-on-chip (SoC) in which the processor 1352 and other components are formed into a single integrated circuit or a single package, such as the Edison or Galileo SoC boards from Intel. As an example, the processor 1352 may include a processor based on Core (such as QUARK, ATOM, i3, i5, i7, or MCU-class processors), or another such processor available from a company in Santa Clara, California. However, any number of other processors may be used, such as processors available from Advanced Micro Devices (AMD) in Sunnyvale, California, MIPS-based designs from MIPS Technologies in Sunnyvale, California, ARM-based designs licensed from ARM Holdings plc, or processors obtained from customers, licensees, or adopters of the above companies. The processor may include units such as the A5 - A10 processors from a company, the SNAPDRAGON processors from Technology Company, or the OMAP processors from Texas Instruments.

[0146] The processor 1352 may communicate with the system memory 1354 via an interconnect 1356 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. As an example, the memory may be a random access memory (RAM) designed according to the Joint Electron Device Engineering Council (JEDEC), such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In various implementations, a single memory device may be of any number of different package types, such as single die package (SDP), dual die package (DDP), or quad die package (QDP). In some examples, these devices may be directly soldered onto the motherboard to provide a lower profile solution, while in other examples, the devices are configured as one or more memory modules that are in turn coupled to the motherboard via a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., different kinds of dual in-line memory modules (DIMM), including but not limited to microDIMM (micro DIMM) or MiniDIMM (mini DIMM).

[0147] To provide persistent storage of information such as data, applications, operating systems, etc., storage 1358 can be coupled to processor 1352 via interconnect 1356. In an example, storage 1358 can be implemented via a solid state disk drive (SSDD). Other devices that can be used for storage 1358 include flash memory cards such as SD cards, microSD cards, xD picture cards, etc., and USB flash drives. In a low-power implementation, storage 1358 can be on-die memory or registers associated with processor 1352. However, in some examples, storage 1358 can be implemented using a micro hard disk drive (HDD). Additionally, in addition to or in place of the described technologies, any number of new technologies can be used for storage 1358 such as resistive random access memory, phase change memory, holographic memory, or chemical memory, etc.

[0148] Components can communicate via interconnect 1356. Interconnect 1356 can include any number of technologies including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), or any number of other technologies. Interconnect 1356 can be, for example, an exclusive bus used in a System-on-Chip (SoC) based system. Other bus systems can be included such as I2C interface, SPI interface, point-to-point interface, power bus, etc.

[0149] Interconnect 1356 can couple processor 1352 to grid transceiver 1362 to communicate with other grid devices 1364, for example. Grid transceiver 1362 can use any number of frequencies and protocols such as 2.4 gigahertz (GHz) transmissions under the IEEE 802.15.4 standard, using as defined by the Bluetooth Low Energy (BLE) standard, or standards, etc. Any number of radios configured for a particular wireless communication protocol can be used for connection to grid devices 1364. For example, a WLAN unit can be used to implement Wi-Fi communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Additionally, for example, wireless wide area communication according to cellular or other wireless wide area protocols can occur via a WWAN unit.

[0150] Grid transceiver 1362 can communicate using multiple standards or radios for different ranges of communication. For example, IoT device 1350 can communicate with nearby (e.g., within about 10 meters) devices using a local transceiver based on BLE or another low-power radio to save power. More distant (e.g., within about 50 meters) grid devices 1364 can communicate via or other intermediate-power radios. These two communication technologies can occur through a single radio at different power levels, or can occur through separate transceivers, such as a local transceiver using BLE and a separate mesh transceiver using .

[0151] A wireless network transceiver 1366 can be included to communicate with devices or services in the cloud 1300 via a local area network protocol or a wide area network protocol. The wireless network transceiver 1366 can be an LPWA transceiver compliant with standards such as IEEE 802.15.4 or IEEE 802.15.4g. The IoT device 1350 can communicate over a wide area using LoRaWAN (Long Range Wide Area Network) developed by and the LoRa Alliance. The techniques described herein are not limited to these techniques and can be used with any number of other cloud transceivers that implement long-range, low-bandwidth communication, such as SIGFOX and other technologies. Additionally, other communication techniques can be used, such as time division channel hopping described in the IEEE 802.15.4e specification.

[0152] In addition to the systems mentioned for the mesh transceiver 1362 and the wireless network transceiver 1366 as described herein, any number of other radio communications and protocols can be used. For example, the radio transceivers 1362 and 1366 can include LTE or other cellular transceivers that use spread spectrum (SPA / SAS) communication to achieve high-speed communication. Additionally, any number of other protocols can be used, such as Wi-Fi networks for medium-speed communication and supply network communication.

[0153] The radio transceivers 1362 and 1366 can include radios compatible with any number of 3GPP (Third Generation Partnership Project) specifications, especially Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-A Pro). Note that radios compatible with any number of other fixed, mobile, or satellite communication technologies and standards can be selected. These can include, for example, any cellular wide area radio communication technology, which can include, for example, a fifth generation (5G) communication system, a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, or an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, a UMTS (Universal Mobile Telecommunications System) communication technology. In addition to the standards listed above, any number of satellite uplink technologies can be used for the wireless network transceiver 1366, including, for example, radios compliant with standards issued by the ITU (International Telecommunication Union) or ETSI (European Telecommunications Standards Institute), and so on. Thus, the examples provided herein are understood to be applicable to a variety of other communication technologies, both existing and yet to be developed.

[0154] A network interface controller (NIC) 1368 may be included to provide wired communication to the cloud 1300 or to other devices such as grid device 1364. The wired communication may provide an Ethernet connection or may be based on other types of networks such as Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus, PROFIBUS, or PROFINET, among other examples. Additional NICs 1368 may be included to allow connection to a second network. For example, one NIC 1368 provides communication to the cloud via Ethernet and a second NIC 1368 provides communication to other devices via another type of network.

[0155] The interconnect 1356 may couple the processor 1352 to an external interface 1370 that is used to connect to external devices or subsystems. External devices may include sensors 1372 such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, Global Positioning System (GPS) sensors, pressure sensors, barometric pressure sensors, and the like. The external interface 1370 may further be used to connect the IoT device 1350 to actuators 1374 such as power switches, valve actuators, audible sound generators, visual warning devices, and the like.

[0156] In some optional examples, various input / output (I / O) devices may be present within or connected to the IoT device 1350. For example, a display or other output device 1384 may be included to display information such as sensor readings or actuator positions. Input devices 1386 such as touchscreens or keypads may be included to accept input. The output device 1384 may include any number of audio or visual display forms including: simple visual outputs such as binary state indicators (e.g., LEDs); multi-character visual outputs; or more complex outputs such as display screens (e.g., LCD screens) that have outputs of characters, graphics, multimedia objects, etc. generated or produced from the operation of the IoT device 1350.

[0157] The battery 1376 may power the IoT device 1350, but in examples where the IoT device 1350 is installed in a fixed location, the IoT device 1350 may have a power supply coupled to the power grid. The battery 1376 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.

[0158] The battery monitor / charger 1378 can be included in the IoT device 1350 to track the state of charge (SoCh) of the battery 1376. The battery monitor / charger 1378 can be used to monitor other parameters of the battery 1376 to provide failure prediction, such as the state of health (SoH) and the state of function (SoF) of the battery 1376. The battery monitor / charger 1378 can include a battery monitoring integrated circuit, such as the LTC4020 or LTC2990 from Linear Technologies, the ADT7488A from ON Semiconductor in Phoenix, Arizona, or an IC from the UCD90xxx family from Texas Instruments in Texas. The battery monitor / charger 1378 can transfer information on the battery 1376 to the processor 1352 via the interconnect 1356. The battery monitor / charger 1378 can also include an analog-to-digital (ADC) converter that allows the processor 1352 to directly monitor the voltage of the battery 1376 or the current from the battery 1376. The battery parameters can be used to determine actions that the IoT device 1350 can perform, such as transmission frequency, grid network operation, sensing frequency, and so on.

[0159] The power block 1380 or other power source coupled to the power grid can be coupled to the battery monitor / charger 1378 to charge the battery 1376. In some examples, the power block 1380 can be replaced with a wireless power receiver to wirelessly obtain power, for example, through a loop antenna in the IoT device 1350. A wireless battery charging circuit (such as the LTC4020 chip from Linear Technologies in Milpitas, California, etc.) can be included in the battery monitor / charger 1378. The particular charging circuit selected depends on the size of the battery 1376 and thus on the required current. Charging can use the (Airfuel ) promulgated AIRFUEL standard, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, and so on.

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

[0161] In an example, instructions 1382 provided via the memory 1354, the storage 1358, or the processor 1352 may be embodied as a non-transitory machine-readable medium 1360 that includes code for instructing the processor 1352 to perform electrical operations in the IoT device 1350. The processor 1352 may access the non-transitory machine-readable medium 1360 via the interconnect 1356. For example, the non-transitory machine-readable medium 1360 may be embodied by the devices described above for the storage 1358 and may include specific storage units such as optical discs, flash drives, or any number of other hardware devices. The non-transitory machine-readable medium 1360 may include instructions for instructing the processor 1352 to perform a specific sequence or flow of actions described, for example, with reference to the (multiple) flowcharts and (multiple) block diagrams depicting the operations and functions above.

[0162] In a further example, a machine-readable medium also includes any tangible medium that can store, encode, or carry instructions for execution by a machine and that cause the machine to perform any one or more of the methods of the present disclosure, or that can store, encode, or carry data structures used by or associated with such instructions. The term "machine-readable medium" should thus include, but not be limited to, solid-state memories, optical media, and magnetic media. Specific examples of machine-readable media include non-volatile memories, including by way of example but not limitation semiconductor memory devices (e.g., 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; and CD-ROM and DVD-ROM disks. Instructions embodied by a machine-readable medium may be further transmitted or received via a communication network using a transmission medium via a network interface device using any one of several transmission protocols (e.g., HTTP).

[0163] It should be understood that the functional units or capabilities described in this specification may be referred to or labeled as components or modules, thus particularly emphasizing their implementation independence. Such components may be embodied in any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit, which includes custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. A component or module may also be implemented in software for execution by various types of processors. The identified component or module of the executable code may include, for example, one or more physical or logical blocks of computer instructions, which may be organized, for example, as objects, procedures, or functions. However, the executable objects of the identified component or module need not be physically together, but may include different instructions stored at different locations, which, when logically combined, include the component or module and achieve the claimed purpose for the component or module.

[0164] In fact, the components or modules of the executable code may be a single instruction or many instructions, and may even be distributed over several different code segments, distributed among different programs, and distributed across several memory devices or processing systems. Specifically, some aspects of the described processes, such as code rewriting and code analysis, may occur on a processing system different from the processing system in which the code is deployed (e.g., in a computer embedded in a sensor or a robot) (e.g., in a computer in a data center). Similarly, the operating data may be identified and shown within a component or module here, and can be embodied in any suitable form and can be organized within any suitable type of data structure. The operating data may be collected as a single data set, or may be distributed at different locations (including distributed over different storage devices), and may exist at least partially only as electronic signals on a system or network. A component or module may be passive or active, including an agent for performing the required functions.

[0165] Exemplary processor

[0166] Figure 14 is a block diagram of a processor 1400 that may have more than one core, may have an integrated memory controller, and may have an integrated graphics device according to an embodiment of the present invention. Figure 14The solid box illustration in shows a processor 1400 with a single core 1402A, a system agent 1410, and a set 1416 of one or more bus controller units, while the optional addition illustrated by the dashed box shows an alternative processor 1400 with multiple cores 1402A-N, a set 1414 of one or more integrated memory controller units in the system agent unit 1410, and dedicated logic 1408.

[0167] Thus, different implementations of the processor 1400 can include: 1) a CPU, where the dedicated logic 1408 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and the cores 1402A-N are one or more general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, a combination of both); 2) a coprocessor, where the cores 1402A-N are a large number of dedicated cores designed primarily for graphics and / or scientific (throughput); and 3) a coprocessor, where the cores 1402A-N are a large number of general-purpose in-order cores. Thus, the processor 1400 can be a general-purpose processor, a coprocessor, or a special-purpose processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (general-purpose graphics processing unit), a high-throughput integrated many-core (MIC) coprocessor (including 30 or more cores), an embedded processor, and so on. The processor can be implemented on one or more chips. The processor 1400 can be part of one or more substrates, and / or can be implemented on one or more substrates using any of a variety of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

[0168] The memory hierarchy includes one or more cache levels within the core, a set 1406 of one or more shared cache units, and external memory (not shown) coupled to the set 1414 of integrated memory controller units. The set 1406 of shared cache units can include one or more intermediate-level caches, such as a second-level (L2), third-level (L3), fourth-level (L4) or other-level caches, a last-level cache (LLC), and / or a combination of the above. Although in one embodiment, a ring-based interconnect unit 1412 interconnects the integrated graphics logic 1408 (the integrated graphics logic 1408 is an example of dedicated logic and is also referred to herein as dedicated logic), the set 1406 of shared cache units, and the system agent unit 1410 / (multiple) integrated memory controller units 1414, alternative embodiments can use any number of well-known techniques to interconnect such units. In one embodiment, coherence is maintained between one or more cache units 1406 and the cores 1402A-N.

[0169] In some embodiments, one or more of the cores 1402A-N are capable of multithreading. The system agent 1410 includes those components that coordinate and operate the cores 1402A-N. The system agent unit 1410 may include, for example, a power control unit (PCU) and a display unit. The PCU may be the logic and components required to regulate the power states of the cores 1402A-N and the integrated graphics logic 1408, or may include such logic and components. The display unit is used to drive one or more externally connected displays.

[0170] The cores 1402A-N may be homogeneous or heterogeneous in terms of the architectural instruction set; that is, two or more of the cores 1802A-N may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of that instruction set or a different instruction set.

[0171] Exemplary Computer Architecture

[0172] Figures 15 - 18 is a block diagram of an exemplary computer architecture. Other system designs and configurations of laptop devices, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices known in the art are also suitable. Generally, a wide variety of systems or electronic devices capable of incorporating a processor and / or other execution logic as disclosed herein are generally suitable.

[0173] Now referring Figure 15 , shown is a block diagram of a system 1500 according to an embodiment of the present invention. The system 1500 may include one or more processors 1510, 1515, which are coupled to a controller hub 1520. In one embodiment, the controller hub 1520 includes a graphics memory controller hub (GMCH) 1590 and an input / output hub (IOH) 1550 (which may be on separate chips); the GMCH 1590 includes a memory and a graphics controller, to which a memory 1540 and a coprocessor 1545 are coupled; the IOH 1550 couples input / output (I / O) devices 1560 to the GMCH 1590. Alternatively, one or both of the memory and the graphics controller are integrated within the processor (as described herein), the memory 1540 and the coprocessor 1545 are directly coupled to the processor 1510, and the controller hub 1520 and the IOH 1550 are in a single chip.

[0174] The optionality of the additional processor 1515 is in Figure 15is represented by a dashed line. Each of the processors 1510, 1515 may include one or more of the processing cores described herein and may be a certain version of the processor 1400.

[0175] The memory 1540 can be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one embodiment, the controller hub 1520 communicates with the processors 1510, 1515 via a multi-branch bus such as a front side bus (FSB), a point-to-point interface such as QuickPath Interconnect (QPI), or a similar connection 1595.

[0176] In one embodiment, the coprocessor 1545 is a specialized processor, such as, for example, a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and so on. In one embodiment, the controller hub 1520 may include an integrated graphics accelerator.

[0177] There can be various differences in a series of quality metrics including architecture, microarchitecture, thermal, power consumption characteristics, etc. between the physical resources 1510, 1515.

[0178] In one embodiment, the processor 1510 executes instructions that control general types of data processing operations. Coprocessor instructions may be embedded within these instructions. The processor 1510 identifies these coprocessor instructions as being of a type that should be executed by the attached coprocessor 1545. Accordingly, the processor 1510 issues these coprocessor instructions (or control signals representing coprocessor instructions) to the coprocessor 1545 on a coprocessor bus or other interconnect. The coprocessor(s) 1545 receive and execute the received coprocessor instructions.

[0179] Now referring to Figure 16 , shown is a block diagram of a first more specific exemplary system 1600 in accordance with an embodiment of the present invention. As Figure 16 shown, the multi-processor system 1600 is a point-to-point interconnect system and includes a first processor 1670 and a second processor 1680 coupled via a point-to-point interconnect 1650. Each of the processors 1670 and 1680 may be a certain version of the processor 1400. In one embodiment of the present invention, the processors 1670 and 1680 are the processors 1610 and 1615 respectively, and the coprocessor 1638 is the coprocessor 1545. In another embodiment, the processors 1670 and 1680 are the processors 1510 and the coprocessor 1545 respectively.

[0180] Processors 1670 and 1680 are shown as including integrated memory controller (IMC) units 1672 and 1682, respectively. Processor 1670 also includes point-to-point (P-P) interfaces 1676 and 1678 as part of its bus controller unit; similarly, second processor 1680 includes P-P interfaces 1686 and 1688. Processors 1670, 1680 may exchange information via P-P interface 1650 using point-to-point (P-P) interface circuits 1678, 1688. As Figure 16 shown, IMCs 1672 and 1682 couple the processors to respective memories, namely memories 1632 and 1634, which may be portions of main memories locally attached to the respective processors.

[0181] Processors 1670, 1680 may each exchange information with chipset 1690 via respective P-P interfaces 1652, 1654 using point-to-point interface circuits 1676, 1694, 1686, 1698. Chipset 1690 may optionally exchange information with coprocessor 1638 via high performance interface 1639. In one embodiment, coprocessor 1638 is a special purpose processor such as, for example, a high throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and the like.

[0182] A shared cache (not shown) may be included in either processor or external to both processors but connected to these processors via P-P interconnect such that if a processor is placed in a low power mode, local cache information of either or both processors may be stored in the shared cache.

[0183] Chipset 1690 may be coupled to first bus 1616 via interface 1696. In one embodiment, first bus 1616 may be a Peripheral Component Interconnect (PCI) bus or a bus such as a PCI Express bus or another third generation I / O interconnect bus, but the scope of the present invention is not limited thereto.

[0184] As Figure 16As shown, various I / O devices 1614 can be coupled to a first bus 1616 along with a bus bridge 1618 that couples the first bus 1616 to a second bus 1620. In one embodiment, one or more additional processors 1615, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array, or any other processor, are coupled to the first bus 1616. In one embodiment, the second bus 1620 can be a low pin count (LPC) bus. In one embodiment, various devices can be coupled to the second bus 1620, including, for example, a keyboard and / or mouse 1622, a communication device 1627, and a storage unit 1628, such as a disk drive or other mass storage device that can include instructions / code and data 1630. Additionally, audio I / O 1624 can be coupled to the second bus 1620. Note that other architectures are possible. For example, instead of Figure 16 a point-to-point architecture, the system can implement a multi-branch bus or other such architecture.

[0185] Now referring to Figure 17 , shown is a block diagram of a second more specific exemplary system 1700 in accordance with an embodiment of the present invention. Figure 16 And 17 similar elements in Figure 17 are designated with similar reference numerals, and certain aspects of Figure 16 are omitted from Figure 16 to avoid obscuring other aspects of

[0186] Figure 17 Illustrated processors 1670, 1680 can each include integrated memory and I / O control logic ("CL") 1672 and 1682. Thus, CL 1672, 1682 includes an integrated memory controller unit and includes I / O control logic. Figure 17 Illustrated is that not only memories 1632, 1634 are coupled to CL 2072, 1682, but also I / O devices 1714 are coupled to control logic 1672, 1682. Conventional I / O devices 1715 are coupled to a chipset 1690.

[0187] Now referring to Figure 18 , shown is a block diagram of a SoC 1800 in accordance with an embodiment of the present invention. Figure 14 Similar elements in Figure 18In [the figure], the (multiple) interconnect units 1802 are coupled to: an application processor 1810, which includes a set 1402A-N of one or more cores (which includes cache units 1404A-N) and the (multiple) shared cache units 1406; a system agent unit 1410; the (multiple) bus controller units 1416; the (multiple) integrated memory controller units 1414; a set 1820 of one or more coprocessors, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 1830; a direct memory access (DMA) unit 1832; and a display unit 1840 for coupling to one or more external displays. In one embodiment, the (multiple) coprocessors 1820 include dedicated processors such as, for example, a network or communication processor, a compression engine, a GPGPU, a high throughput MIC processor, or an embedded processor, and so on.

[0188] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as a computer program or program code executed on a programmable system that includes at least one processor, a storage system (including volatile and nonvolatile memory and / or storage elements), at least one input device, and at least one output device.

[0189] Program code (such as, Figure 16 the code 1630 illustrated in [the figure]) may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0190] The program code may be implemented in a high-level procedural programming language or an object-oriented programming language in order to communicate with the processing system. If desired, the program code may also be implemented in assembly language or machine language. In fact, the mechanisms described herein are not limited to any specific programming language scope. In any case, the language may be a compiled language or an interpreted language.

[0191] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logics in a processor, and the instructions, when read by the machine, cause the machine to fabricate the logics for performing the techniques described herein. Such representations, referred to as “IP cores,” may be stored on a tangible machine-readable medium and supplied to various customers or production facilities to be loaded into the manufacturing machines that actually fabricate the logics or processors.

[0192] Such machine-readable storage media may include, but are not limited to, non-transitory, tangible arrangements of articles of manufacture formed or created by a machine or device, which include storage media such as hard disks; any other type of disk, including floppy disks, optical disks, compact disk read-only memory (CD-ROM), rewritable compact disks (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); phase change memory (PCM); magnetic or optical cards; or any other type of medium suitable for storing electronic instructions.

[0193] Accordingly, embodiments of the present invention also include non-transitory, tangible machine-readable media that contain instructions or contain design data, such as a hardware description language (HDL), that define the structures, circuits, devices, processors, and / or system features described herein. These embodiments are also referred to as program products.

[0194] Emulation (including binary translation, code morphing, etc.)

[0195] In some cases, an instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may transform (e.g., using static binary translation, dynamic binary translation including dynamic compilation), morph, emulate, or otherwise convert an instruction or instructions into one or more other instructions to be processed by a core. The instruction converter may be implemented in software, hardware, firmware, or any combination thereof. The instruction converter may be on the processor, off the processor, or partly on the processor and partly off the processor.

[0196] Figure 19 is a block diagram of an example of using a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set in accordance with an embodiment of the present invention. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Figure 19It is shown that a program in the form of a high-level language 1902 can be compiled using an x86 compiler 1904 to generate x86 binary code 1906 that can be natively executed by a processor 1916 having at least one x86 instruction set core. The processor 1916 having at least one x86 instruction set core represents any processor that performs substantially the same functions as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise performing the following: 1) an essential part of the instruction set of the Intel x86 instruction set core, or 2) a target code version of an application or other software targeted to run on an Intel processor having at least one x86 instruction set core to achieve substantially the same results as an Intel processor having at least one x86 instruction set core. The x86 compiler 1904 represents a compiler operable to generate x86 binary code 1906 (e.g., target code) that can be executed on a processor 1916 having at least one x86 instruction set core with or without additional linking processing. Similarly, Figure 19 It is shown that a program in the form of a high-level language 1902 can be compiled using an alternative instruction set compiler 1908 to generate alternative instruction set binary code 1910 that can be natively executed by a processor 1914 not having at least one x86 instruction set core (e.g., a processor having cores that execute the MIPS instruction set of MIPS Technologies, Inc. of Sunnyvale, California, and / or the ARM instruction set of ARM Holdings plc of Sunnyvale, California). An instruction converter 1912 is used to convert the x86 binary code 1906 into code that can be natively executed by a processor 1914 not having an x86 instruction set core. The converted code is not likely to be the same as the alternative instruction set binary code 1910 because instruction converters capable of doing so are difficult to manufacture; however, the converted code will perform general operations and be composed of instructions from an alternative instruction set. Thus, the instruction converter 1912 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device not having an x86 instruction set processor or core to execute the x86 binary code 1906 through emulation, simulation, or any other process.

[0197] Further examples

[0198] Example 1 provides a method for serving multiple data streams of multiple wireless devices using multiple protocols. The method includes: monitoring one or more interfaces communicating using multiple protocols; activating the first interface after detecting a need to exchange data on the first interface; and powering down the second interface after a threshold amount of idle time, where a connectivity manager performs the monitoring, activation, and power-down steps; extracting packet metadata from one or more of the multiple data streams by a packet analyzer; determining an experienced latency and a latency criterion for the one or more data streams based on the packet metadata, and applying a latency reduction strategy to attempt to meet the latency criterion, where an Adaptive Connectivity Manager (ACM) performs the determining and applying steps; and determining an utilized bandwidth and a bandwidth criterion for the one or more data streams, and applying a bandwidth reduction strategy to attempt to meet the bandwidth criterion, where a Bandwidth Utilization Manager (BUM) performs the determining and applying steps.

[0199] Example 2 includes the substance of the exemplary method of Example 1, where the connectivity manager, ACM, and BUM include circuitry for being incorporated into an edge device for connecting a Local Area Network (LAN) to a Wide Area Network (WAN), the LAN including multiple wireless devices, and the WAN including the Internet.

[0200] Example 3 includes the substance of the exemplary method of Example 1, where at least one of the connectivity manager, ACM, and BUM is implemented using a virtual machine.

[0201] Example 4 includes the substance of the exemplary method of Example 1, further including: receiving a data reception status from each of the multiple interfaces; at least activating the first interface when the data reception status of the first interface indicates that a data packet has been received; and at least setting the second interface to a low power mode when the data reception status of the second interface indicates that no packet has been received for a threshold amount of time, where the connectivity manager performs the receiving, activation, and setting steps.

[0202] Example 5 includes the substance of the exemplary method of Example 1, where the latency reduction strategy includes at least one of the following: sending the same data packet simultaneously through multiple interfaces and discarding redundant data packets; relaying one or more data streams using different interfaces with reduced latency; and relaying one or more data streams using different protocols.

[0203] Example 6 includes the substantial content of the exemplary method of Example 1, wherein the bandwidth reduction strategy includes at least one of the following: buffering data packets of one or more data streams for later transmission during off-peak hours; throttling the bandwidth of packets generated at the source of one or more data streams; and when multiple packets are received simultaneously, dividing the bandwidth utilized by one or more data streams into multiple parts and allocating different bandwidth parts to transmit multiple packets simultaneously.

[0204] Example 7 includes the substantial content of the exemplary method of Example 1, wherein the multiple protocols at least include: Low Energy (BLE), Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), Second Generation Wireless Protocol (2G), Third Generation Wireless Protocol (3G), Fourth Generation Wireless Protocol (4G), Near Field Communication (NFC), and protocols standardized by the Institute of Electrical and Electronics Engineers (IEEE), and the IEEE protocols include IEEE 802.11, IEEE 802.16, and IEEE 802.18.

[0205] Example 8 includes the substantial content of the exemplary method of any one of Examples 1-7, wherein at least some of the wireless devices are brownfield devices that were not originally designed to connect to a WAN.

[0206] Example 9 includes the substantial content of the exemplary method of any one of Examples 1-7, wherein at least some of the wireless devices are Internet of Things (IoT) devices.

[0207] Example 10 includes the substantial content of the exemplary method of any one of Examples 1-7, wherein the packet analyzer, connectivity manager, ACM, and BUM are parts of an IoT gateway.

[0208] Example 11 provides a system that includes: a wireless network; multiple interfaces for communicating data streams with multiple wireless devices using multiple protocols; a connectivity manager (CM) for: monitoring one or more of the multiple interfaces; activating the first interface after detecting a need to exchange data on the first interface; and powering down the second interface after a threshold amount of idle time; a packet analyzer (PA) for extracting packet metadata from one or more of the data streams; an adaptive connectivity manager (ACM) for: determining the experienced waiting time and waiting time criteria for one or more data streams based on the packet metadata and applying a waiting time reduction strategy to attempt to meet the waiting time criteria; and a bandwidth utilization manager (BUM) for: determining the utilized bandwidth and bandwidth criteria for one or more data streams and applying a bandwidth reduction strategy to attempt to meet the bandwidth criteria.

[0209] Example 12 includes the substantial content of the exemplary system of Example 11, wherein the connectivity manager, ACM, and BUM include circuitry for incorporation into an edge device for connecting a local area network (LAN) to a wide area network (WAN), the LAN including a plurality of wireless devices, and the WAN including the Internet.

[0210] Example 13 includes the substantial content of the exemplary system of Example 11, further including a processor for implementing a virtual machine host system, wherein at least one of the connectivity manager, ACM, and BUM is to be implemented by the processor using virtual machines.

[0211] Example 14 includes the substantial content of the exemplary system of Example 11, wherein the connectivity manager is configured to: receive a data reception status from each of a plurality of interfaces; activate the first interface when the data reception status of the first interface indicates that a data packet has been received; and set the second interface to a low power mode when the data reception status of the second interface indicates that no packets have been received for a threshold amount of time.

[0212] Example 15 includes the substantial content of the exemplary system of Example 11, wherein the latency reduction strategy includes at least one of the following: simultaneously transmit the same data packet through a plurality of interfaces and discard redundant data packets; relay one or more data streams using different interfaces with reduced latency; and relay one or more data streams using different protocols.

[0213] Example 16 includes the substantial content of the exemplary system of Example 11, wherein the bandwidth reduction strategy includes at least one of the following: buffer data packets of a second data stream for later transmission during off-peak hours; throttle the bandwidth of packets generated by the second data stream; and when multiple packets are received simultaneously, divide the bandwidth utilized by one or more data streams into multiple portions and allocate different bandwidth portions for use by the multiple packets.

[0214] Example 17 includes the substantial content of the exemplary system of Example 11, wherein the multiple protocols include at least: Bluetooth Low Energy (BLE), Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), Second Generation Wireless Protocol (2G), Third Generation Wireless Protocol (3G), Fourth Generation Wireless Protocol (4G), Near Field Communication (NFC), and protocols standardized by the Institute of Electrical and Electronics Engineers (IEEE), the IEEE protocols including IEEE 802.11, IEEE 802.16, and IEEE 802.18.

[0215] Example 18 includes the substantial content of the exemplary system of Example 11, wherein at least some of the wireless devices are brownfield devices that were not originally designed to connect to a WAN.

[0216] Example 19 includes the substantial content of the exemplary system of Example 11, wherein at least some of the wireless devices are Internet of Things (IoT) devices.

[0217] Example 20 includes the substantial content of the exemplary system of Example 11, wherein the packet analyzer, connectivity manager, ACM, and BUM are part of an IoT gateway.

[0218] Example 21 provides a non-transitory computer-readable medium that contains instructions which, when executed by a processor, cause the processor to serve multiple data streams of multiple wireless devices using multiple protocols by the following steps: monitoring one or more interfaces that communicate using multiple protocols; activating the first interface after detecting a need to exchange data on the first interface; and powering down the second interface after a threshold amount of idle time, wherein the connectivity manager performs the monitoring, activation, and power-down steps; extracting packet metadata from one or more of the multiple data streams by the packet analyzer; determining the experienced latency and latency criteria for the one or more data streams based on the packet metadata and applying a latency reduction strategy to attempt to meet the latency criteria, wherein the determination and application steps are performed by an Adaptive Connectivity Manager (ACM); and determining the utilized bandwidth and bandwidth criteria for the one or more data streams and applying a bandwidth reduction strategy to attempt to meet the bandwidth criteria, wherein the determination and application steps are performed by a Bandwidth Utilization Manager (BUM).

[0219] Example 22 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, wherein the connectivity manager, ACM, and BUM include circuitry for being incorporated into an edge device that connects a local area network (LAN) to a wide area network (WAN), the LAN includes multiple wireless devices, and the WAN includes the Internet.

[0220] Example 23 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, wherein at least one of the connectivity manager, ACM, and BUM is implemented using a virtual machine.

[0221] Example 24 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, further including: receiving data reception status from each of a plurality of interfaces; when the data reception status of the first interface indicates that a data packet has been received, at least activating the first interface; and when the data reception status of the second interface indicates that no packet has been received for a threshold amount of time, at least setting the second interface to a low power mode, wherein the receiving, activating, and setting steps are to be performed by a connectivity manager.

[0222] Example 25 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, wherein the latency reduction strategy includes at least one of the following: simultaneously sending the same data packet through a plurality of interfaces and discarding redundant data packets; using different interfaces with reduced latency to relay one or more data streams; and using different protocols to relay one or more data streams.

[0223] Example 26 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, wherein the bandwidth reduction strategy includes at least one of the following: buffering data packets of one or more data streams for later transmission during off-peak hours; throttling the bandwidth of packets generated at the source of one or more data streams; and when multiple packets are received simultaneously, dividing the bandwidth utilized by one or more data streams into multiple parts and allocating different bandwidth parts to simultaneously transmit multiple packets.

[0224] Example 27 includes the substantial content of the exemplary non-transitory computer-readable medium of Example 21, wherein the multiple protocols at least include: Low Energy (BLE), Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), Second Generation Wireless Protocol (2G), Third Generation Wireless Protocol (3G), Fourth Generation Wireless Protocol (4G), Near Field Communication (NFC), and protocols standardized by the Institute of Electrical and Electronics Engineers (IEEE), and the IEEE protocols include IEEE802.11, IEEE 802.16, and IEEE 802.18.

[0225] Example 28 includes the substantial content of the exemplary non-transitory computer-readable medium of any one of Examples 21-27, wherein at least some of the wireless devices are brownfield devices that were not originally designed to be connected to a WAN.

[0226] Example 29 includes the substantial content of the exemplary non-transitory computer-readable medium of any one of Examples 21-27, wherein at least some of the wireless devices are Internet of Things (IoT) devices.

[0227] Example 30 includes the substantial content of the exemplary non-transitory computer-readable medium of any one of Examples 21-27, wherein the packet analyzer, connectivity manager, ACM, and BUM are part of the IoT gateway.

Claims

1. A system for an Internet of Things (IoT) platform, comprising: a plurality of interfaces for communicating multiple data streams with multiple wireless devices using multiple protocols; a Connectivity Manager (CM) for: monitoring one or more of the plurality of interfaces, activating a first interface upon detecting a need to exchange data on the first interface, and powering down a second interface after a threshold amount of idle time; a Packet Analyzer (PA) for extracting packet metadata from one or more of the multiple data streams and for determining a waiting time experienced by the one or more data streams and a bandwidth utilized by the one or more data streams based on the packet metadata; an Adaptive Connectivity Manager (ACM) for applying a waiting time reduction strategy to attempt to bring the experienced waiting time into compliance with a waiting time standard; and a Bandwidth Utilization Manager (BUM) for applying a bandwidth reduction strategy to attempt to bring the utilized bandwidth into compliance with a bandwidth standard.

2. The system according to claim 1, wherein each of a subset of the plurality of wireless devices includes a plurality of different interfaces.

3. The system according to claim 1, wherein the CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device for connecting a network to a WAN via a multi-hop path having different network interfaces along the path.

4. The system according to claim 1, wherein the CM, the PA, the ACM, and the BUM are incorporated into a fog device at the edge of a cloud computing network for connecting the network to a plurality of other fog devices.

5. The system according to any one of claims 1-4, wherein the plurality of wireless devices are IoT functional entities and are networked via one or more of a local area network (LAN) and a personal area network (PAN), wherein the CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device for connecting the network to a wide area network (WAN) including the Internet.

6. The system according to any one of claims 1-4, wherein at least one of the CM, the PA, the ACM, and the BUM is implemented using at least one of a virtual machine, a container, and a field programmable gate array (FPGA).

7. The system according to any one of claims 1-4, wherein the CM is for: receiving a data reception status from each of the plurality of interfaces; activating the first interface when the data reception status of the first interface indicates that a data packet has been received; and setting the second interface to a low power mode when the data reception status of the second interface indicates that no packet has been received for a threshold amount of time.

8. The system according to any one of claims 1-4, wherein the waiting time reduction strategy includes at least one of the following: sending the same data packet simultaneously through multiple interfaces and discarding redundant data packets; relaying the multiple data streams using different interfaces with reduced waiting time; and relaying the multiple data streams using different protocols.

9. The system according to any one of claims 1-4, wherein, the bandwidth reduction strategy includes at least one of the following: buffering data packets of the one or more data streams for later transmission during off-peak hours; throttling the source of packets of the one or more data streams; and when multiple packets are received simultaneously, dividing the bandwidth utilized by the multiple data streams into multiple parts and allocating different bandwidth parts for use by the multiple packets.

10. The system according to any one of claims 1-4, wherein, The multiple protocols include a subset of the group consisting of: Bluetooth, Low Energy BLE, Long Term Evolution LTE, Universal Mobile Telecommunications System UMTS, Global System for Mobile Communications GSM, Second Generation Wireless Protocol 2G, Third Generation Wireless Protocol 3G, Fourth Generation Wireless Protocol 4G, Near Field Communication NFC, and Institute of Electrical and Electronics Engineers IEEE protocols, the IEEE protocols including IEEE 802.11, IEEE 802.16 and IEEE 802.

18.

11. A method for an Internet of Things platform, comprising: communicating multiple data streams with multiple wireless devices using multiple interfaces and multiple protocols; monitoring, by a connectivity manager CM, one or more of the multiple interfaces, activating, by the CM, the first interface after detecting a need to exchange data on the first interface, and powering off, by the CM, a second interface after a threshold amount of idle time; extracting, by a packet analyzer PA, packet metadata from one or more of the multiple data streams and determining, by the PA, the waiting time experienced by the one or more data streams and the bandwidth utilized by the one or more data streams based on the packet metadata; applying, by an adaptive connectivity manager ACM, a waiting time reduction strategy to attempt to make the experienced waiting time comply with a waiting time standard; and applying, by a bandwidth utilization manager BUM, a bandwidth reduction strategy to attempt to make the utilized bandwidth comply with a bandwidth standard.

12. The method according to claim 11, wherein, each of a subset of the multiple wireless devices includes multiple different interfaces.

13. The method according to claim 11, wherein, the CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device that connects a network to a WAN via a multi-hop path having different network interfaces along the path.

14. The method according to claim 11, wherein, the CM, the PA, the ACM, and the BUM are incorporated into a fog device at the edge of a cloud computing network, and the fog device connects the network to multiple other fog devices.

15. The method according to any one of claims 11-14, wherein, the multiple wireless devices are Internet of Things (IoT) functional entities and are networked via one or more of a local area network (LAN) and a personal area network (PAN), and wherein the CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device for connecting the network to a wide area network (WAN) that includes the Internet.

16. A device for an Internet of Things platform, comprising: means for aggregating multiple data streams from multiple wireless devices using multiple interfaces; a connectivity manager CM for: monitoring one or more of the multiple interfaces, activating the first interface after detecting a need to exchange data on the first interface, and powering off a second interface after a threshold amount of idle time; A packet analyzer PA for extracting packet metadata from one or more of the plurality of data streams and for determining a latency experienced by the one or more data streams and a bandwidth utilized by the one or more data streams based on the packet metadata; An adaptive connectivity manager ACM for applying a latency reduction strategy to attempt to bring the experienced latency into compliance with a latency standard; And A bandwidth utilization manager BUM for applying a bandwidth reduction strategy to attempt to bring the utilized bandwidth into compliance with a bandwidth standard.

17. The apparatus according to claim 16, Wherein, Each of the subsets of the plurality of wireless devices includes a plurality of different interfaces.

18. The apparatus according to claim 16, Wherein, The CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device for connecting the network to a WAN via a multi-hop path having different network interfaces along the path.

19. The apparatus according to claim 16, Wherein, The CM, the PA, the ACM, and the BUM are incorporated into a fog device at the edge of a cloud computing network, the fog device for connecting the network to a plurality of other fog devices.

20. The apparatus according to any one of claims 16-19, Wherein, The plurality of wireless devices are Internet of Things (IoT) functional entities and are networked via one or more of a local area network (LAN) and a personal area network (PAN), wherein the CM, the PA, the ACM, and the BUM include circuitry incorporated into an edge device for connecting the network to a wide area network (WAN), the WAN including the Internet.

21. A machine-readable medium comprising code that, when executed, causes a machine to perform the method according to any one of claims 11-15.

Images