Patent Description:
<NPL> provides a survey of the IoT ecosystem. The smart sensors collaborate through wireless communication and internet, with zero human activity, to deliver automated intelligent applications. Bansal et al provides an overview of the taxonomy of the IoT ecosystem. Then, it provides a technical overview of IoT enabling architectures, devices, gateways, operating systems (OS), middleware, platforms, data storage, security, communication protocols and interfaces for the data flow in an ecosystem. <NPL> describes communication between sensor nodes and loT middleware based on 6LoWPAN. Neighbor Discovery Protocol (NDP) suggests the ability to self-configure communication between IoT middleware and sensor nodes using Stateless Address Autoconfiguration (SLAAC) mechanism. Experiments show that the sensor nodes have automatic IP addressing and can discover the middleware's existence and address. The discovery delay is around <NUM> with the number of exchanged NDP control message of each node is six.

"Reference architecture for IoT device capabilities exposure; Y. <NUM> (<NUM>/<NUM>)", no. <NUM> (<NUM>/<NUM>), (<NUM>), pages <NUM> - <NUM>, ITU-T STANDARD Y. <NUM>, INTERNATIONAL TELECOMMUNICATION UNION, GENEVA ; CH, URL: http://mirror. int/dms/pay/itu-t/rec/y/T-REC-Y. <NUM>-<NUM>-I!!PDF-E. pdf specifies the reference architecture of IoT device capability exposure (IoT DCE) which supports IoT applications in DCE devices (e.g., smart phones, tablets and home gateways) to access device capabilities exposed by IoT devices connected to the DCE device.

<CIT> describes how a messaging meta broker gateway for publish-subscribe messaging environments provides connectivity, message routing, and subscription management between large numbers of clients and large numbers of brokers. The messaging meta broker gateway can provide access to large numbers of brokers to a client through a single connection. To a broker, the messaging meta broker gateway provides extremely wide fan-in and fan-out to gateway clients. To a service provider, the messaging meta broker gateway is a single system providing easy scaling with lightweight replication of instances, and shared, private, or virtual messaging environments supporting multiple customers and applications. The meta broker gateway can also connect gateway clients with other clients of the brokers, and also with archiving facilities. Protocol translation, security, and statistics logging are supported. The messaging meta broker gateway is suitable for cloud-based Internet-of Things environments.

<NPL> describes how publish/subscribe paradigm is often adopted to create the communication infrastructure of the Internet of Things (loT) for many clients to access enormous real-time sensor data. The emerging Software Defined Networking (SDN) provides opportunities to improve the QoS of publish/subscribe facilities for delivering events in IoT owing to its customized programmability and centralized control. Yulong et al propose encoding event topics, priorities and security policies into flow entries of SDN-enabled switches to satisfy personalized QoS needs. Yulong et all further propose a cross-layer QoS enabled SDN-like publish/subscribe communication infrastructure. They first present an SDN-like topic-oriented publish/subscribe middleware architecture with a cross-layer QoS control framework. Then they discuss prototype implementation, including topic management, topology maintenance, event routing and policy management. They use differentiated services and cross-layer access control as cross-layer QoS scenarios to verify the prototype.

In order to describe the manner in which the above-recited and other features of the disclosure can be obtained, a more particular description will be rendered by reference to specific implementations thereof which are illustrated in the appended drawings. For better understanding, the like elements have been designated by like reference numbers throughout the various accompanying figures. While some of the drawings may be schematic or exaggerated representations of concepts, at least some of the drawings may be drawn to scale. Understanding that the drawings depict some example implementations, the implementations will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

This disclosure generally relates to linking IoT devices with cloud services. Distributed nature of IoT devices is a reality when building connected logistics, such as fleets of trucks or ships that haul goods from one country to another. IoT infrastructures establish connectivity between the IoT devices and remote applications. As the IoT devices move around, the applications for the IoT devices do not move. Today there are IoT hubs in each region and if the IoT device moves to a different location, the IoT device first needs to be programmed to the new IoT hub. In addition, the application needs to change to pick up data from the new IoT hub. The IoT hub is a device homing endpoint for IoT devices to connect to for sending and receiving information. Applications are typically aware of which IoT hub the IoT devices are connected to and the applications will read the data from the identified IoT hub.

For example, an application on a cellphone may be used to open or close a car door. The IoT device may be the car or a smart door lock. An in-between infrastructure from the IoT hub may be used to facilitate communications between the application and the IoT device. Currently, for communications to occur between the application and the IoT device, the application, the IoT device, and the IoT hub must be aware of one another ahead of time.

The present disclosure relates to a globally connected fabric of nodes of device connectivity endpoints whose sole responsibility is to establish dial tone with the device session manager nodes. The messaging route and procession disposition of the information can be declaratively provided by the developers depending on, for example, customer needs, the processing needs, and/or the data sovereignty needs. An IoT device connects with the nearest or a nearby connectivity global IoT connectivity fabric (GCF) node (similar to a cell tower in cellphone connectivity) and that GCF node knows the owner of the device session and establishes a messaging relationship. The GCF node forwards and receives network traffic. The IoT devices may be agnostic of the infrastructure that the IoT device is connecting to (e.g., the GCF node). The present disclosure includes several practical applications that provide benefits and/or solve problems associated with linking IoT devices with cloud services.

The connectivity fabric nodes may own the device network connection. If one node is down, the IoT device may retry and pick up a next available node. Besides cached session node information, the connectivity fabric nodes are completely stateless. Through a dynamically updated connectivity directory, the session node will always be able to send and receive traffic to and from the IoT device. Connectivity Fabric Nodes may form a graph between geographies and regions through messaging bus topology for well controlled interactions that may be governed by declarative controls to enforce customer data sovereignty and/or regulatory needs.

The session manager nodes may be stateful and may publish application programming interfaces (API)s for the applications to interact with IoT devices. The IoT device's last known state is known to the session manager all the time with some advertised latency. The session manager nodes always know how to communicate with the IoT device through the discovery of the connectivity fabric node that owns the device network connection. The session manager nodes may also form a graph depending on the application needs.

The present disclosure allows IoT devices to not have prior knowledge of which GCF node to connect to ahead of time and allows IoT devices to locate or find a nearest or nearby connectivity endpoint; the information from the connectivity endpoint will flow to the application no matter where the application is located. For example, if an IoT device is changing locations, the IoT devices may locate a connectivity endpoint in a new location to connect to without having prior knowledge of which GCF nodes to connect with. In addition, if an IoT device is stationary and a connectivity endpoint goes down or is disabled, the IoT device may locate another connectivity endpoint to connect with nearby without having to have prior knowledge of the GCF nodes nearby the IoT device.

One example use case with the present disclosure may include an IoT system with a globally distributed IoT device population that may be stationary (e.g., oil drilling and producing all over the world) or IoT devices that move (e.g., connected logistics, such as, ships, containers, and/or trucks). In addition, the IoT system may include an application that provides services to the IoT devices. The application may be located in one geography due to data sovereignty and user population of the IoT system. Since the IoT device population is distributed globally, a highly available and disaster proof solution is needed. For example, information from some IoT devices may be processed locally while for other IoT devices, the processing may occur at a remote geography. The present disclosure may allow all the information pathways needed for enabling the above communications between the globally distributed IoT devices and the application to be declared by developers through a control plane. The control plane may include any functionality that enables infrastructure setup for the IoT devices, such as, but not limited to, registering the IoT device, setting policies for message pathways, and/or setting access control policies on the IoT devices.

The present disclosure may enable global connectivity with developer controlled state management and a highly reliable IoT platform which will allow customers to achieve declarative high availability and disaster recoverability based on the need of the application. For example, a smart mousetrap and a switchgear in a power grid have different high availability (HA) and/or disaster recovery (DR) requirements and COGS implications. The present disclosure allows customers to achieve objectives while the IoT system absorbs the complexity of global connectivity.

As such, no matter where the applications and/or the IoT devices are located, the applications and/or IoT devices may always find each other through dynamic GCF node discovery, information path policies, and/or shared device metadata.

Referring now to <FIG>, illustrated is an example layered view of an IoT system <NUM> for use with connecting a plurality of IoT devices <NUM> with one or more remote applications <NUM> that provide cloud services. IoT system <NUM> may facilitate communications between applications <NUM> and the IoT devices <NUM>.

IoT system <NUM> may communicate with an application layer <NUM> with a plurality of applications <NUM>. Example applications <NUM> may include customer management or monitoring applications for monitoring and managing IoT devices <NUM> and/or analytical applications used for running the physical environments efficiently. The cloud services may include, but are not limited to, performance monitoring, command and control, and/or analytics measuring. The application layer <NUM> may be owned by one or more customers of the IoT system <NUM>.

The application layer <NUM> may communicate with an IoT middleware layer <NUM> of IoT system <NUM>. The IoT middleware layer <NUM> may include a plurality of IoT middleware <NUM> devices, such as, but not limited to, data pipeline nodes, event processor nodes, security extensions, application extensions, digital twins, and/or topology nodes.

The IoT middleware layer <NUM> may communicate with a connectivity layer <NUM> of IoT system <NUM>. The connectivity layer <NUM> may include a plurality of GCF nodes <NUM> that create a global IoT connectivity fabric <NUM>. A GCF node <NUM> is a cloud gateway node with which the IoT devices <NUM> establishes a connection using, for example, any of the hypertext transfer protocol secure (HTTPS), advanced message queuing protocol (AMQP), and/or message queuing telemetry transport (MQTT) protocols. A transport layer security (TLS) session terminates at the GCF node <NUM>. The connectivity layer <NUM> may be a layer <NUM> router of messages within the IoT system <NUM>.

The connectivity layer <NUM> may also include a GCF node discovery service <NUM> that may be used by IoT devices <NUM> to discover GCF nodes <NUM> to connect with. The GCF nodes <NUM> may form a graph between geographies and regions through a messaging bus topology for well controlled interactions that may be governed by declarative controls to enforce customer data sovereignty and/or regulatory needs.

Any IoT device <NUM>, stationary or moving, may use a GCF node discovery service <NUM> to dynamically discover one or more GCF nodes <NUM> nearby to connect with. One example may include an IoT device <NUM> implicitly discovering a nearest GCF node <NUM> through Domain Name System (DNS) proximity. Discovering of GCF nodes <NUM> nearby IoT device <NUM> using DNS proximity may incur DNS infrastructure induced latency. Another example may include an IoT device <NUM> discovering GCF node <NUM> located nearby by explicitly calling the GCF node discovery service <NUM> to find a nearest GCF node <NUM>.

By using the GCF node discovery service <NUM> to identify one or more GCF nodes <NUM> to connect with, IoT device <NUM> may locate or find a nearby connectivity endpoint and the information from the connectivity endpoint will flow to the application <NUM> no matter where the application <NUM> is located. For example, if an IoT device <NUM> changes locations, the IoT device <NUM> may locate a connectivity endpoint in a new location without having prior knowledge of which connectivity endpoints to connect with. In addition, if an IoT device <NUM> is stationary and a connectivity endpoint goes down or is disabled, the IoT device <NUM> may locate another connectivity endpoint to connect with nearby without having prior knowledge of the connectivity endpoints nearby the IoT device <NUM>.

The connectivity layer <NUM> may also include a device session manager <NUM> that may provide the device session information <NUM> for the IoT devices <NUM>. The device session information <NUM> may include, for example, a connectivity state of the IoT device <NUM>. The device session information <NUM> may be synchronized upon device connectivity. In addition, the device session manager <NUM> may associate the GCF node information <NUM> of the GCF node <NUM> currently connected to the IoT device <NUM> with the device session information <NUM>. The device sessions information <NUM> may be updated as the connectivity status of the IoT device <NUM> changes (e.g., disconnects or connects) and/or the IoT device <NUM> moves locations and connects with a different GCF node <NUM>. As such, the device session information <NUM> reflects a current state of overall connectivity of the IoT device <NUM>.

In addition, the device session manager <NUM> may include channel subscription information <NUM> received from the device metadata <NUM>. The channel subscription information <NUM> may identify which channels the IoT device <NUM> declared for sending and/or receiving information. For example, the IoT device <NUM> may specify a publisher channel to send data, such as telemetry data and/or events observed by the IoT device <NUM>. In addition, the IoT device <NUM> may specify one or more channels that the IoT device <NUM> is subscribed to for receiving commands or other control messages from applications <NUM> and/or services. The IoT device <NUM> may also specify one or more channels for receiving broadcast messages from applications <NUM> and/or services.

The GCF nodes <NUM> may own the device network connection. If one GCF node <NUM> is down, the IoT device <NUM> may retry and pick up a next available GCF node <NUM>. Besides cached session node information, the GCF nodes <NUM> are completely stateless. Through a dynamically updated device session manager <NUM>, the GCF nodes <NUM> will always be able to send and receive traffic to and from the IoT device <NUM>.

The device session manager <NUM> may be stateful and may publish application programming interfaces (API)s for the applications <NUM> to interact with IoT devices <NUM>. The IoT device <NUM> last known state is known to the device session manager <NUM> with some advertised latency. The device session manager <NUM> communicates with the IoT devices <NUM> through the discovery of the GCF node <NUM> that owns the device network connection. The device session manager <NUM> may also form a graph depending on the application <NUM> needs.

The connectivity layer <NUM> may communicate with a device layer <NUM>. The device layer <NUM> may include a plurality of IoT devices <NUM>. IoT devices <NUM> may include any device with a sensor and/or an actuator or any edge gateway that facilitates communications with remote services. The IoT devices <NUM> may include, but are not limited to, the sensors and gateways installed at buildings, pipelines, factories, pumping stations, homes, trucks, mines, and/or ships. The IoT devices <NUM> may be distributed in different geographic locations across the world.

Applications <NUM> may use the IoT system <NUM> to send messages to IoT devices <NUM> and/or receive messages from IoT devices <NUM>. In addition, IoT devices <NUM> may use the IoT system <NUM> to send messages to applications <NUM> and/or receive messages from applications <NUM>. As such, the IoT system <NUM> may be used to link IoT devices <NUM> with cloud services provided by one or more applications <NUM>.

The global IoT connectivity fabric <NUM> may support different types of messaging patterns between the IoT devices <NUM> and the IoT middleware <NUM>. One example messaging pattern supported by the global IoT connectivity fabric <NUM> may include a publish message. An IoT device <NUM> and/or a cloud hosted service by applications <NUM> may publish messages to other actors in the IoT system <NUM>. For example, the IoT devices <NUM> and/or applications <NUM> may have insights and/or other information to share with the rest of the actors in the IoT system <NUM>. The actors may include IoT devices <NUM>, such as, but not limited to, smart trash cans, smart mouse traps, smart homes, and/or air quality monitoring sensors. The actors may also include services that send commands to devices in the IoT system <NUM> by publishing a command payload to the device specific channel.

Another example messaging pattern supported by the global IoT connectivity fabric <NUM> may include a subscribe message. An IoT device <NUM>, processing pipeline nodes, and/or a cloud hosted service by applications <NUM> may subscribe to channels for receiving messages necessary for operations. For example, an event processor may want to know when a smart trashcan is full, a motor vibration is out of bounds, air quality at a national park is not safe, and/or a mouse is trapped in smart mouse trap. A time-series service in the backend will subscribe to all the telemetry events for enabling time-series analytics. A digital twin service may also care about certain system events like subscription event to channels so that distributed publication of messages can be implemented.

Another example messaging pattern supported by the global IoT connectivity fabric <NUM> may include a request and response message. Data driven IoT devices <NUM>, such as, but not limited to, vending machines, handheld scanners (validate the boarding pass, validate the coupon, etc.), and/or other data driven equipment and devices require backend application programming interface (API) support for serving data. For example, a coupon scanner may call a remote application through an API, such as retailApp. isValid(couponId), or an IoT device <NUM> may call an API, such as myApp. getSecurityPolicies(deviceld), for downloading security policies before going offline. Additional examples of API calls originating from IoT devices <NUM> may include, but are not limited to, GetProducts and IsBoardingPassValid. A causal relationship exists between the request and response pairs, and thus, the request and response message mode of communication is different from the publish or subscribe models described above. Since the request and response model depends on the application <NUM>, the global IoT connectivity fabric <NUM> may establish the dial tone between the application <NUM> and the IoT device <NUM> for enabling this type of interaction.

Another example messaging pattern supported by the global IoT connectivity fabric <NUM> may include streaming connections. The IoT devices <NUM> may open streaming connections to applications <NUM> mediated by the global IoT connectivity fabric <NUM>. Example uses may include, but are not limited to, sonar equipment signals, video and audio surveillance, troubleshooting devices manually through SSH, and/or running on-demand remote diagnostics.

The IoT system <NUM> may use the global IoT connectivity fabric <NUM> to implement any preferences received for the communications pathways and/or declarative routes between the IoT devices <NUM> and the applications <NUM>. For example, users of the IoT system <NUM> may be able to declare and/or tailor communication pathways or routes between the IoT devices <NUM> and the IoT middleware <NUM>, <NUM> and the communication pathways or routes between the IoT middleware <NUM>, <NUM> and the applications <NUM>.

Metadata <NUM> may be created indicating any preferences received for the communications pathways or declarative routes received. For example, application program developers may create metadata <NUM> in response to information received from users indicating a preferred route for communications between IoT devices <NUM> and applications <NUM>. IoT devices <NUM> may download metadata <NUM>. Any component within the IoT system <NUM> that the IoT devices <NUM> may communicate with using the global IoT connectivity fabric <NUM> may have access to metadata <NUM>.

When IoT devices <NUM> download metadata <NUM>, metadata <NUM> may establish a connectivity type for the IoT devices <NUM>. The IoT devices <NUM> may use the information provided in metadata <NUM> to connect to a nearby GCF node <NUM> in the global IoT connectivity fabric <NUM>. The connectivity layer <NUM> may have access to the metadata <NUM> and the global IoT connectivity fabric <NUM> may use metadata <NUM> to determine where to send information sent by the IoT devices <NUM>.

The application layer <NUM> may also have access to metadata <NUM> and may use metadata <NUM> to determine which data to accept from the IoT devices <NUM>. For example, if the data originates from an IoT device <NUM> identified by metadata <NUM>, the application layer <NUM> may accept the data and the applications <NUM> may receive the data from the IoT device <NUM>. However, if the data originates from an IoT device <NUM> not included in metadata <NUM>, the application layer <NUM> may reject the data and the application <NUM> may be unable to communicate with the IoT device <NUM>. As such, metadata <NUM> may be used by the global IoT connectivity fabric <NUM>, the IoT devices <NUM>, the IoT middleware <NUM>, and/or the applications <NUM> to implement any preferences or choices received for communication pathways or routes between the IoT devices <NUM> and applications <NUM>.

The global connectivity layer <NUM> may provide matchmaker services between IoT devices <NUM> and services provided by one or more applications <NUM> based on one or more policies or preference received. As such, no matter where the IoT devices <NUM> are located at any point in time, the IoT devices <NUM> may use the global IoT connectivity fabric <NUM> to find an optimal layer <NUM> route to the application <NUM> for both telemetry and command traffic. While the IoT devices <NUM> may be distributed all over the world, through declarative routes, how traffic flows from the IoT devices <NUM> to the applications <NUM> may be controlled.

The global IoT connectivity fabric <NUM> may be completely stateless. As such, the global IoT connectivity fabric <NUM> may be deployed globally without worrying about state synchronization complexity. The connectivity layer <NUM> may be deployed in an individual scale unit as the connectivity layer <NUM> may have different scaling semantics than the services that consume information from the connectivity layer <NUM>. The connectivity layer <NUM> may be completely abstract and may only understand the messaging constructs, such as, but not limited to, sessions, messages, channels, and/or streams.

By the global IoT connectivity fabric <NUM> being stateless and abstracted, the global IoT connectivity fabric <NUM> may be ubiquitous, reliable, available, disaster resilient, and/or perform well under diverse deployment situations. In addition, by global IoT connectivity fabric <NUM> being abstracted, increasingly concrete and stateful components can be stacked on top (e.g., in middleware layer <NUM>) for a progressive customization required by domain specific applications <NUM>.

The global IoT connectivity fabric <NUM> may implement the concept of a channel. The channel may be a transient construct that comes to life if there is at least one publisher or subscriber to the channel. The channel may be a logical messaging mode on top of a network connection owned by the global IoT connectivity fabric <NUM>. One example network connection may include, but is not limited to, a physical transmission control protocol (TCP) connection. The client libraries of the global IoT connectivity fabric <NUM> may expose channels as well as the ability to unwrap the underlying socket for sending and receiving byte streams.

Applications <NUM> may declaratively specify any number of channels. The number of channels may be saved, for example, in metadata <NUM> available to the different components and/or devices of the IoT system <NUM>. In addition, applications <NUM> may link the necessary telemetry and command processors in publish, subscribe, request/response, and/or streaming modes for the different channels through services stacked on top of the global IoT connectivity fabric <NUM>. Such layering keeps the connectivity layer <NUM> simple and stateless (e.g., only transient publish and/or subscription state and in-flight buffers may be present in the connectivity layer <NUM>) so that the global IoT connectivity fabric <NUM> may be deployed globally without the complexity of state synchronization.

Any stationary or moving IoT device <NUM> may connect to a GCF node <NUM> located nearby to send or receive information from the respective channels known a priori. One example may include an IoT device <NUM> implicitly discovering a nearby GCF node <NUM> through DNS proximity. Discovering GCF nodes <NUM> nearby IoT device <NUM> using DNS proximity may incur DNS infrastructure induced latency. Another example may include an IoT device <NUM> discovering a GCF node <NUM> located nearby by explicitly calling the GCF node discovery service <NUM> to find a nearby GCF node <NUM>.

IoT devices <NUM> may select a GCF node <NUM> to connect to based on proximity to a location of the IoT devices <NUM>. For example, the IoT devices <NUM> may select a GCF node <NUM> located the nearest to the IoT devices <NUM>.

In another implementation, IoT devices <NUM> may use a quality of service criteria in selecting which GCF node <NUM> to connect with. For example, IoT devices <NUM> may discover a plurality of GCF nodes <NUM> located nearby IoT devices <NUM>. IoT devices <NUM> may take into account additional quality of service criteria for the GCF nodes <NUM>, such as, but not limited to, a load of the GCF node <NUM> (e.g., a total number of IoT devices <NUM> currently connected to the GCF node <NUM>) and/or the performance characteristics of the GCF node <NUM>, when selecting which GCF node <NUM> to connect with.

One example use case may include a container being shipped from China to the United States. The container may include an IoT device <NUM>. When the container is in China, the IoT device <NUM> connects to the global IoT connectivity fabric <NUM> in China and communicates a location of the container. When the container arrives in the United States, the IoT device <NUM> connects to the global IoT connectivity fabric <NUM> in the United States and communicates a location of the container. Typically, applications <NUM> are located in a single location. As such, when an application <NUM> subscribes to the device data from the IoT device <NUM> associated with the container, no matter where the container is located, whenever the IoT device <NUM> connects to the global IoT connectivity fabric <NUM>, the data from the IoT device <NUM> may be transmitted to the application <NUM> using the global IoT connectivity fabric <NUM>.

The IoT devices <NUM> and the IoT services provided by the application <NUM> rely on simple channel APIs thereby making the entire interaction between the IoT devices <NUM> and the services provided by application <NUM> configurable declaratively. The channels can be part of a device model where the device definitions for the IoT devices <NUM> may have a linked channel definition for communications.

For example, an IoT device <NUM> is added in the shared device registry. At the time of modeling, the IoT device <NUM> may be annotated with the necessary channels based on the communications needs. The services provided by application <NUM> and the IoT device <NUM> may use the same channel monikers for a loosely coupled interaction through publish and/or subscribe semantics.

The global IoT connectivity fabric <NUM> may be a ubiquitous IoT connectivity infrastructure whose role is to establish the dial tone between the applications <NUM> and the IoT devices <NUM>. An IoT device <NUM> may always find a nearby endpoint for publishing and subscribing to IoT traffic using the global IoT connectivity fabric <NUM>. Developers may be able to control the location of IoT devices <NUM>, services provided by applications <NUM>, and the network interaction through policies exposed by the global IoT connectivity fabric <NUM>. For example, a policy can say IoT devices <NUM> located in Europe may only connect cloud services hosted in data centers located in Europe. Due to the separation of application state from the transient device session state, high availability (HA) and/or disaster recovery (DR) of the global IoT connectivity fabric <NUM> becomes simpler.

As such, no matter where the applications <NUM> and/or the IoT devices <NUM> are located, the applications <NUM> and/or IoT devices <NUM> may always find each other through dynamic GCF node <NUM> discovery, information path policies, and/or shared device metadata <NUM>.

Referring now to <FIG>, illustrated is an example of IoT system <NUM> with a distributed IoT middleware deployment using a global IoT connectivity fabric <NUM> to connect one or more IoT devices <NUM> to one or more applications <NUM>. For example, the middleware layer <NUM> may have IoT middleware <NUM> located in west Europe and IoT middleware <NUM> located in the west coast of the United States. The global IoT connectivity fabric <NUM> may be part of the connectivity layer <NUM> and may be used to link remote IoT devices <NUM> with cloud services provided by one or more applications <NUM>. IoT system <NUM> may use the different layers (e.g., middleware layer <NUM> and connectivity layer <NUM>) and/or components discussed in <FIG>.

The IoT devices <NUM> may send messages to the global IoT connectivity fabric <NUM> and/or may receive messages from the global IoT connectivity fabric <NUM>. The global IoT connectivity fabric <NUM> may be used to establish connections between the plurality of IoT devices <NUM> with IoT middleware <NUM>, <NUM>. The connections may enable the IoT devices <NUM> to communicate with IoT middleware <NUM>, <NUM> by sending and/or receiving messages between the IoT devices <NUM> and the IoT middleware <NUM>, <NUM>.

IoT middleware <NUM>, <NUM> may be in communication with one or more applications <NUM> providing cloud services to IoT devices <NUM>. The IoT system <NUM> may have an active customer management and monitoring area <NUM> located in the west coast of the United States and a passive customer management and monitoring area <NUM> located in the east coast of the United States.

The active management and monitoring area <NUM> may include a plurality of applications <NUM> that are actively in communication with IoT middleware <NUM>, <NUM>. As such, messages sent from applications <NUM> for IoT devices <NUM> may be transmitted to IoT middleware <NUM>, <NUM>. In addition, any messages received by IoT middleware <NUM>, <NUM> from IoT devices <NUM> may be sent to applications <NUM> within the active management and monitoring area <NUM>.

The passive customer management and monitoring area <NUM> may include a plurality of applications <NUM> that are not actively in communication with IoT middleware <NUM>, <NUM>. As such, applications <NUM> in the passive management monitoring area <NUM> may not send messages to IoT devices <NUM> and/or may not receive messages from IoT devices <NUM>.

The global connectivity layer <NUM> may provide matchmaker services between IoT devices <NUM> and services provided by one or more applications <NUM> based on one or more policies or preferences received.

One example is illustrated for using the global IoT connectivity fabric <NUM> to connect applications <NUM> located in the west coast of the United States with IoT devices <NUM> located in the United States and in Europe. The example may include the user choosing to connect the IoT devices <NUM> located in the United States with IoT middleware <NUM> located in the west coast of the United States, and the user choosing to connect the IoT devices <NUM> located in Europe with IoT middleware <NUM> located in the west of Europe. For example, the global IoT connectivity fabric <NUM> may connect the IoT devices <NUM> located in the west coast and the east coast of the United States with state machines hosted by IoT middleware <NUM>. The global IoT connectivity fabric <NUM> may also connect the IoT devices <NUM> located in the north and west of Europe with state machines hosted by IoT middleware <NUM> in the west of Europe. IoT middleware <NUM> and IoT middleware <NUM> may both communicate with applications <NUM> located in the active customer and management area <NUM> located in the west coast of the United States.

Another example (not illustrated) for connecting applications <NUM> located in the west coast of the United States with IoT devices <NUM> located in the United States and in Europe may include a user declaring a communication route for the IoT devices <NUM>. For example, the user may specify that the IoT devices <NUM> located in north and west Europe and the IoT devices <NUM> located in the west and east coast of the United States communicate with IoT middleware <NUM> located in the west coast of the United States. The global IoT connectivity fabric <NUM> may connect the IoT devices <NUM> located in the west coast and the east coast of the United States and the IoT devices <NUM> located in north and west Europe with state machines hosted by IoT middleware <NUM>. IoT middleware <NUM> may communicate with applications <NUM> located in the active customer and management area <NUM> located in the west coast.

As such, no matter where the IoT devices <NUM> are located at any point in time, the IoT devices <NUM> may use the global IoT connectivity fabric <NUM> to find an optimal layer <NUM> route to the application <NUM> for both telemetry and command traffic. While the IoT devices <NUM> may be distributed all over the world, through declarative routes, how traffic flows from the IoT devices <NUM> to the applications <NUM> may be controlled.

Referring now to <FIG>, illustrated is an example of IoT system <NUM> with a unified IoT middleware deployment using a global IoT connectivity fabric <NUM> to connect one or more IoT devices <NUM> to one or more applications <NUM>. For example, the middleware layer <NUM> may have IoT middleware <NUM> located in the west coast of the United States. The global IoT connectivity fabric <NUM> may be part of the connectivity layer <NUM> and may be used to link remote IoT devices <NUM> with cloud services provided by one or more applications <NUM>. IoT system <NUM> may use the different layers (e.g., middleware layer <NUM> and connectivity layer <NUM>) and/or components discussed in <FIG>.

The IoT devices <NUM> may send messages to the global IoT connectivity fabric <NUM> and/or may receive messages from the global IoT connectivity fabric <NUM>. The global IoT connectivity fabric <NUM> may be used to establish connections between the plurality of IoT devices <NUM> with IoT middleware <NUM>. For example, IoT middleware <NUM> may be located in the west coast of the United States. The connections may enable the IoT devices <NUM> to communicate with IoT middleware <NUM> by sending and/or receiving messages between the IoT devices <NUM> and IoT middleware <NUM>.

IoT middleware <NUM> may be in communication with one or more applications <NUM> providing cloud services to IoT devices <NUM>. IoT system <NUM> may have an active customer management and monitoring area <NUM> located in the west coast of the United States and a passive customer management and monitoring area <NUM> located in the east coast of the United States.

The active management and monitoring area <NUM> may include a plurality of applications <NUM> that are actively in communication with IoT middleware <NUM>. As such, messages sent from applications <NUM> for IoT devices <NUM> may be transmitted to IoT middleware <NUM>. In addition, any messages received by IoT middleware <NUM> from IoT devices <NUM> may be sent to applications <NUM> within the active management and monitoring area <NUM>.

The passive customer management and monitoring area <NUM> may include a plurality of applications <NUM> that are not actively in communication with IoT middleware <NUM>. As such, applications <NUM> in the passive management monitoring area <NUM> may not send messages to IoT devices <NUM> and/or may not receive messages from IoT devices <NUM>.

The global connectivity layer <NUM> may provide matchmaker services between IoT devices <NUM> and services provided by one or more applications <NUM> based on one or more policies or preference received. For example, a user may specify that the IoT devices <NUM> located in north and west Europe and the IoT devices <NUM> located in the west and east coast of the United States communicate with IoT middleware <NUM> located in the west coast of the United States.

As such, the global IoT connectivity fabric <NUM> may connect the IoT devices <NUM> located in the west coast and the east coast of the United States and the IoT devices <NUM> located in north and west Europe with state machines hosted by IoT middleware <NUM>. IoT middleware <NUM> may communicate with applications <NUM> located in the active customer and management area <NUM> located in the west coast.

No matter where the IoT devices <NUM> are located at any point in time, the IoT devices <NUM> may use the global IoT connectivity fabric <NUM> to find an optimal layer <NUM> route to the application <NUM> for both telemetry and command traffic. While the IoT devices <NUM> may be distributed all over the world, through declarative routes, how traffic flows from the IoT devices <NUM> to the applications <NUM> may be controlled.

Referring now to <FIG>, illustrated is an example of IoT system <NUM> using a global IoT connectivity fabric <NUM> with a global IoT connectivity fabric scale unit deployment model to connect one or more IoT devices <NUM> to one or more applications <NUM>. For example, the middleware layer <NUM> may have IoT middleware <NUM> located in the west coast of the United States. The global IoT connectivity fabric <NUM> may be part of the connectivity layer <NUM> and may be used to link remote IoT devices <NUM> with cloud services provided by one or more applications <NUM>. IoT system <NUM> may use the different layers (e.g., middleware layer <NUM> and connectivity layer <NUM>) and/or components discussed in <FIG>.

The global IoT connectivity fabric <NUM> may include one or more graphs <NUM>, <NUM> of GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Graphs <NUM>, <NUM> may be in different geographies and/or regions and graphs <NUM>, <NUM> may communicate with each other through messaging bus topology for well controlled interactions that may be governed by declarative controls to enforce customer data sovereignty and/or regulatory needs.

Graph <NUM> may include GCF nodes <NUM>, <NUM>, <NUM>, <NUM> and graph <NUM> may include GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Graph <NUM> may be located in the United States and graph <NUM> may be located in Europe. Graphs <NUM> and <NUM> may communicate through inter geographies and/or region message bus traffic <NUM>.

IoT middleware <NUM> may communicate with applications <NUM> in the active management and monitoring area <NUM>. As such, messages sent from applications <NUM> for IoT devices <NUM> may be transmitted to IoT middleware <NUM>. In addition, any messages received by IoT middleware <NUM> from IoT devices <NUM> may be sent to applications <NUM> within the active management and monitoring area <NUM>. The passive customer management and monitoring area <NUM> may include a plurality of applications <NUM> that are not actively in communication with IoT middleware <NUM>.

For example, IoT devices <NUM> in Europe may transmit telemetry information to application <NUM> by connecting with one or more of the GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in graph <NUM> and sending the telemetry information to the GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. IoT middleware <NUM> may communicate with GCF node <NUM> in graph <NUM>. Since IoT middleware <NUM> is communicating with GCF node <NUM>, graph <NUM> may transmit the receive telemetry to graph <NUM>, where GCF node <NUM> is located, using inter geographies and/or region message bus traffic <NUM>. GCF node <NUM> may receive the telemetry information from IoT device <NUM> and may transmit the telemetry information to IoT middleware <NUM>. IoT middleware <NUM> may send the telemetry information to application <NUM>.

As such, no matter where the IoT devices <NUM> are located at any point in time, the IoT devices <NUM> may use the global IoT connectivity fabric <NUM> to find an optimal layer <NUM> route to the application <NUM> for both telemetry and receiving command traffic. While the IoT devices <NUM> may be distributed all over the world, through declarative routes, how traffic flows from the IoT devices <NUM> to the applications <NUM> may be controlled.

Referring now to <FIG>, an example channel architecture <NUM> for use with global IoT system <NUM> may include one or more IoT devices <NUM> using channel architecture <NUM> to communicate with one or more services <NUM> provided by one or more applications <NUM>. A channel is an application layer <NUM> concept to group messages and enable routing between channels through a publish and subscribe pattern. Channel architecture <NUM> may allow multiple channels <NUM>, <NUM>, <NUM> on a single network connection <NUM> to ensure IoT devices <NUM> conserve power. An IoT device <NUM> may publish and subscribe to multiple channels to cover the necessary functionality. While three channels <NUM>, <NUM>, <NUM> are illustrated, a fewer number of channels may be used or more channels may be used.

In channel architecture <NUM>, IoT device <NUM> may open three channels <NUM>, <NUM>, <NUM> to send telemetry data, receive commands, and/or listen to any broadcast messages. For example, channel <NUM> may be a publisher channel used by IoT device <NUM> to send or publish telemetry data to services <NUM> and/or applications <NUM>. Channel <NUM> may be a subscriber channel used by IoT device <NUM> to receive commands from services <NUM> and/or applications <NUM>. Channel <NUM> may be a broadcast channel used by IoT devices <NUM> to listen to any broadcast messages from services <NUM> and/or applications <NUM>.

Application <NUM> and/or services <NUM> may subscribe to channel <NUM> to receive telemetry data and/or other information sent from IoT devices <NUM>. In addition, application <NUM> and/or services <NUM> may publish commands using channel <NUM> to IoT devices <NUM>. Application <NUM> and/or services <NUM> may also send broadcast messages to IoT devices <NUM> using channel <NUM>.

Channel architecture <NUM> may decouple the communications layer from the application semantics so that, a telemetry only IoT device <NUM> may only publish to the telemetry channel <NUM> while a hybrid IoT device <NUM> (e.g., a sensor for measuring and an actuator for changing) may publish through the telemetry channel <NUM> while subscribing to the command channel <NUM>. Due to the separation of device semantics from the communications layer, the following communications patterns may be added to the IoT platform of IoT system <NUM>.

One communication pattern may relate to the publisher channel <NUM>. Several IoT devices <NUM> may use the same channel credentials for the publisher channel <NUM> for sending sensor telemetry data from the IoT devices <NUM>. Sensors only IoT devices <NUM> (e.g., read-only devices) may send telemetry data without requiring full-duplex communications. Examples of sensors only IoT device <NUM> may include, but are not limited to, remote sensors that measure pipeline flow at various segments of a gas pipeline, monitoring traffic flow in smart cities, and/or operational intelligence (OI) systems in process industries (e.g., oil refineries or water treatment centers) may only gather sensor telemetry for systems monitoring.

Having a telemetry channel only model may include the following benefits. Since the same publisher channel <NUM> may be used by many geographically distributed sensors only or read-only IoT devices <NUM> and non-device agents, the burden of maintaining pseudo device credentials for thousands of senders may be alleviated. The telemetry only publisher channel <NUM> may also prevent inadvertent permission escalation by preventing control commands from flowing back into the IoT devices <NUM> in cases where the IoT devices <NUM> also have actuators. Since the IoT device <NUM> is in control, the IoT device <NUM> may create a request-response channel and terminate the request-response channel right after the IoT device <NUM> receives the information needed. In addition, the telemetry channel only model may help the modeling of real-world scenarios where hundreds of IoT devices <NUM> connect through a single gateway. The gateway may create the necessary telemetry only publisher channel <NUM> based on the messaging semantics of the underlying IoT devices <NUM>.

Another communication pattern may relate to the subscriber channel <NUM>. Command and control may be integral elements of IoT systems. The commands can be sent to an individual IoT device <NUM> or may be broadcast through a broadcast channel <NUM> if largescale control/reconfiguration of IoT devices <NUM> may be required. Micro command and control may be synonymous with direct control of a single IoT device <NUM> while a Macro command and control involves the control of large IoT device populations.

Since publish and subscribe may be at the core of the IoT systems, the continuum of scenarios between the micro and macro control may be implemented. For example, actuator only IoT devices <NUM> may not need the telemetry publisher channel <NUM> and hence may only subscribe to the publisher channel <NUM> for publishing commands to the respective IoT devices <NUM>. Moreover, the IoT device population may also be global due to the ubiquitous nature of the connectivity layer <NUM>.

Another communication pattern may relate to a request-response channel. IoT devices <NUM> may request information and one of the GCF nodes <NUM> forwards the request to the appropriate application layer extension plugged into GCF layer. Data driven IoT devices <NUM> require information from master data sources to function. One example may include data driven IoT devices <NUM> requesting security and information governance policies from the global IoT connectivity fabric (GCF) <NUM>. The global IoT connectivity fabric <NUM> responds with policies and evaluation engine updates for the IoT devices <NUM>. Another example may include data driven IoT devices <NUM> requesting functional data (e. , a bar code scanner may check with an IoT Hub to see if the scanned coupon is valid in retail scenarios, a Redbox kiosk may request information about the latest movies to be browed by customers, and/or a data driven IoT device <NUM> may request the latest configuration settings for sensor thresholds). The global IoT connectivity fabric (GCF) <NUM> provides the connectivity between the applications <NUM> providing the management and monitoring services for the responses to the requests sent by the IoT devices <NUM>.

Another communication pattern may relate to a full-duplex channel. When sensors and actuators are fused into a single logical abstraction (e.g., a single IoT device <NUM>), then such an IoT device <NUM> may create a full duplex channel and mux-demux the outgoing telemetry data and received commands respectively. The services and/or application layer <NUM>, with the aid of the gateway-device relationships in the topology, may be able to interpret the telemetry and may also dispatch the commands to the correct IoT device <NUM> through the respective channel.

Another communication pattern may relate to a streaming channel. In an implementation, the messaging layer may be enhanced to receive video and/or audio streams processed through a video encoding and/or transcoding service that enables surveillance in security and monitoring scenarios for IoT devices <NUM>, as well as industrial and commercial security.

The channel model used by architecture <NUM> may be a transient concept where channels may be established when there is at least one publisher and/or subscriber. The publisher and/or subscriber process for the channels occurs in an authenticated context. The channel implementations may be near state-less from the registry point of view and hence the device connectivity may be global out of the box.

In addition, the channel model used by architecture <NUM> may allow the implementation of the natural device life cycle that separates the planning from the commissioning process. Today, systems may fuse these two distinct phases together into single step by creating the devices in an operational IoT messaging broker registry. Such a model can result in lots of phantom devices that exist in the registry but never are actually commissioned.

Moreover, since channels are globally available, the global IoT connectivity fabric <NUM> may decide to connect to an available channel with the help of a GCF Node discovery service <NUM> that knows the nearby GCF Nodes <NUM> with the available channel. The GCF Node discovery service <NUM> may be aware of the availability of the GCF nodes <NUM> and may redirect the channel connectivity requests through appropriate GCF nodes <NUM>.

The channel model, with the help of the GCF Node discovery service <NUM>, enables universally available connectivity deployments by redirecting the connection requests to a nearby available GCF node <NUM>. Once a connection is established, IoT devices <NUM> start publishing to the channels as dictated by the metadata <NUM> downloaded through the control channel. The GCF node <NUM> in turn publishes the messages to the respective subscribers after ensuring that the publishers and the subscribers have the necessary security credentials to do so. The IoT devices <NUM> may go to the nearest GCF node <NUM> and the GCF node <NUM> knows how to communicate with the corresponding application <NUM>.

IoT devices <NUM> that move within the same geography or even across continents may use the same channel without losing logical connectivity. For example, fleet of trucks, trains, equipment that gets rented, and/o shipping containers may use the global IoT connectivity fabric <NUM> to use channels to connect to the applications <NUM> across space and time.

As such, the channel architecture <NUM> of the global IoT connectivity fabric <NUM> may allow the natural composition of devices (e.g., gateways, single devices, clusters of devices that include trucks, and/or trains) to be connected to the messaging layer without being aware of the physics of the composition.

Referring now to <FIG>, an example IoT system <NUM> for use with architecture <NUM> (<FIG>) may use a telemetry channel only model. IoT system <NUM> may include one or more sensors only, or read-only, IoT devices <NUM>. Examples of sensors only IoT devices <NUM> may include, but are not limited to, remote sensors that measure pipeline flow at various segments of a gas pipeline, monitoring traffic flow in smart cities, and/or operational intelligence (OI) systems in process industries (e.g., oil refineries or water treatment centers) may only gather sensor telemetry data for systems monitoring.

IoT devices <NUM> may use sensors to acquire telemetry data <NUM>, such as, but not limited to, temperature readings, measurements of pipeline flows, measurements of traffic flows, and/or pressure readings. IoT devices <NUM> may subscribe to the same publisher channel <NUM> to transmit the telemetry data <NUM> to one or more device management and/or monitoring services <NUM> and/or one or more telemetry processing services <NUM>.

IoT devices <NUM> may be in the same geographic location and/or may be distributed across several different geographical locations. The global IoT connectivity fabric <NUM> may be used to facilitate the communications between the IoT devices <NUM> and the management and/or monitoring services <NUM> and/or the telemetry processing services <NUM> using publisher channel <NUM> to transmit the telemetry data <NUM>. For example, the global IoT connectivity fabric <NUM> may expose publisher channel <NUM> and may unwrap the underlying socket for sending and receiving byte streams using publisher channel <NUM>.

Referring now to <FIG>, an example IoT system <NUM> for use with architecture <NUM> (<FIG>) may use a subscriber channel model. IoT system <NUM> may include one or more actuator IoT devices <NUM>, <NUM>, <NUM>. Actuator only IoT devices <NUM>, <NUM>, <NUM> may not need a publisher channel <NUM> and may only subscribe to channel publishing commands. IoT system <NUM> may be a micro command system, where the commands may be sent from a device monitoring and management service <NUM> to individual actuator IoT devices <NUM>, <NUM>, <NUM>. Each actuator IoT device <NUM>, <NUM>, <NUM> may subscribe to a different subscriber channel <NUM>, <NUM>, <NUM> to receive the commands sent from device monitoring and management service <NUM>.

In an implementation, each actuator IoT device <NUM>, <NUM>, <NUM> may have a corresponding actuator twin <NUM>, <NUM>, <NUM> in the device monitoring and management service <NUM>. The actuator twins <NUM>, <NUM>, <NUM> may communicate with the actuator IoT devices <NUM>, <NUM>, <NUM> using the subscriber channels <NUM>, <NUM>, <NUM> to send one or more commands from the device monitoring and management service <NUM>. For example, actuator twin <NUM> may use subscriber channel <NUM> to send commands to actuator IoT device <NUM>. Actuator twin <NUM> may use subscriber channel <NUM> to send commands to actuator IoT device <NUM>, and actuator twin <NUM> may use subscriber channel <NUM> to send commands to actuator IoT device <NUM>.

One example use case may include device monitoring and management services <NUM> changing a temperature of different rooms of a building controlled by different actuator IoT devices <NUM>, <NUM>, <NUM>. For example, device monitoring and management services <NUM> may use actuator twin <NUM> to send a command using subscriber channel <NUM> to increase the temperature of the room controlled by actuator IoT device <NUM> from <NUM> degrees Fahrenheit to <NUM> degrees Fahrenheit. Device monitoring and management services <NUM> may use actuator twin <NUM> to send a command using subscriber channel <NUM> to lower the temperature of the room controlled by actuator IoT device <NUM> from <NUM> degrees Fahrenheit to <NUM> degrees Fahrenheit. In addition, device monitoring and management services <NUM> may use actuator twin <NUM> to send a command using subscriber channel <NUM> to maintain the temperature of the room controlled by actuator IoT device <NUM> at <NUM> degrees Fahrenheit.

Actuator IoT devices <NUM>, <NUM>, <NUM> may be in the same geographic location and/or may be distributed across several different geographical locations. The global IoT connectivity fabric <NUM> may be used to facilitate the communications between the actuator IoT devices <NUM>, <NUM>, <NUM> and the management and/or monitoring services <NUM> using subscriber channels <NUM>, <NUM>, <NUM>. For example, the global IoT connectivity fabric <NUM> may expose subscriber channels <NUM>, <NUM>, <NUM> and may unwrap the underlying socket for sending and receiving byte streams using subscriber channels <NUM>, <NUM>, <NUM>.

Referring now to <FIG>, an example IoT system <NUM> for use with architecture <NUM> (<FIG>) may use a broadcast subscriber channel model. IoT system <NUM> may include one or more actuator IoT devices <NUM>, <NUM>, <NUM>. IoT system <NUM> may be a macro command system, where the commands may be sent from a command broadcaster <NUM> within a device monitoring and management service <NUM> to a plurality of devices, such as, all the actuator IoT devices <NUM>, <NUM>, <NUM>.

Each actuator IoT device <NUM>, <NUM>, <NUM> may subscribe to a broadcast channel <NUM> to listen to any broadcast messages from device monitoring and management service <NUM>. Broadcast channel <NUM> may be used for publishing commands to the actuator IoT devices <NUM>, <NUM>, <NUM>.

One example use case may include device monitoring and management services <NUM> sending a broadcast message to change a temperature of different rooms of a convention center controlled by different actuator IoT devices <NUM>, <NUM>, <NUM>. Command broadcaster <NUM> may send a broadcast message The broadcast message may be sent using broadcast channel <NUM> to all the actuator IoT devices <NUM>, <NUM>, <NUM> to lower the temperature in all of the rooms controlled by the actuator IoT devices <NUM>, <NUM>, <NUM> to <NUM> degrees Fahrenheit. As such, instead of instructing each of the IoT devices <NUM>, <NUM>, <NUM> individually with the temperate change for the convention center, the broadcast message may be sent to all the actuator IoT devices <NUM>, <NUM>, <NUM> with the temperature change information.

Actuator IoT devices <NUM>, <NUM>, <NUM> may be in the same geographic location and/or may be distributed across several different geographical locations. The global IoT connectivity fabric <NUM> may be used to facilitate the communications between the device monitoring and management service <NUM> and actuator IoT devices <NUM>, <NUM>, <NUM> using broadcast channel <NUM>. For example, the global IoT connectivity fabric <NUM> may expose broadcast channel <NUM> and may unwrap the underlying socket for sending and receiving byte streams using broadcast channel <NUM>.

Referring now to <FIG>, a method <NUM> for sending a command from a device monitoring and management application <NUM> to an IoT device <NUM> using the global IoT connectivity fabric <NUM> may be implemented by IoT system <NUM>. Command and control may be enabled by the global IoT connectivity fabric <NUM> to allow a remote application <NUM> to control an IoT device <NUM> with the state change command sent through the previously established communications channels. The global IoT connectivity fabric <NUM> may use a plurality of GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in different geographic regions to facilitate the command and control messaging. The actions of method <NUM> may be discussed below with reference to IoT system <NUM> and the architectures of <FIG>.

At <NUM>, method <NUM> may include receiving GCF Nodes nearby a current location of an IoT device. IoT device <NUM> may send a request to GCF node discovery service <NUM> for a list of one or more GCF nodes <NUM>, <NUM> nearby a current location of the IoT device <NUM>. The request may include the current location of the IoT device <NUM>. GCF node discovery service <NUM> may provide the one or more GCF nodes <NUM>, <NUM> to IoT device <NUM> in response to IoT device <NUM> explicitly calling GCF node discovery service <NUM> to find a nearby connectivity node. GCF node discovery service <NUM> may also provide the one or more GCF nodes <NUM>, <NUM> to IoT device <NUM> through DNS proximity. As such, as a location of the IoT device <NUM> changes, the one or more GCF nodes <NUM>, <NUM> nearby IoT device <NUM> may change.

At <NUM>, method <NUM> may include connecting to a GCF node. The IoT device <NUM> may select GCF node <NUM> to connect to based on the proximity in location of the GCF node <NUM> relative to the IoT device <NUM>. For example, the IoT device <NUM> may select GCF node <NUM> because GCF node <NUM> is located nearest or closest to the IoT device <NUM>. For example, both the IoT device <NUM> and GCF node <NUM> may be in Region <NUM>, e.g., Europe. In addition, if IoT device <NUM> received a plurality of GCF nodes <NUM>, <NUM> located within a radius of the IoT device <NUM>, the IoT device <NUM> may also use a quality of service criteria of the GCF nodes <NUM>, <NUM> when selecting which connectivity node for connecting with.

At <NUM>, method <NUM> may include publishing device session information. For example, GCF node <NUM> may publish the device session information <NUM> (<FIG>) for IoT device <NUM> to a device session manager <NUM>. The device session information <NUM> may include, for example, a connectivity state of the IoT device <NUM> and GCF node information <NUM> (<FIG>). The GCF node information <NUM> may identify the GCF node <NUM> currently connected to the IoT device <NUM>. The device session information <NUM> may be updated as a connectivity status of the IoT device <NUM> changes (e.g., disconnects or connects) and/or the IoT device <NUM> moves locations and connects with a different GCF node <NUM>, <NUM>, <NUM>, <NUM>. As such, the device session information <NUM> reflects a current state of overall connectivity of the IoT device <NUM>.

In addition, GCF node <NUM> may publish channel subscription information <NUM> (<FIG>) received from the device metadata <NUM>. The channel subscription information <NUM> may identify which channels IoT device <NUM> declared for sending and/or receiving information. For example, IoT device <NUM> may specify a publisher channel to send data, such as telemetry data. IoT device <NUM> may also specify one or more channels for receiving commands or other control messages from applications <NUM> and/or services. In addition, IoT device <NUM> may specify one or more channels for receiving broadcast messages from applications <NUM> and/or services.

At <NUM>, method <NUM> may include sending a command to an IoT device. A device monitoring and management application <NUM> may want to send a command and/or a control message to IoT device <NUM>. The device monitoring and management application <NUM> may be located in a different region than the IoT device <NUM>. For example, the device monitoring and management application <NUM> may be located in region <NUM> (e.g., the United States) and the IoT device <NUM> may be located in region <NUM> (e.g., Europe).

The device monitoring and management application <NUM> may access device metadata <NUM> for IoT device <NUM> and the channel subscription information <NUM>. The device monitoring and management application <NUM> may use the channel subscription information <NUM> to identify which channel to use when sending the command and/or control message to IoT device <NUM>. For example, the channel subscription information <NUM> may include an in-memory distributed hash table with the channel ID, subscriber ID, and/or the GCF node ID.

Application <NUM> may connect to IoT middleware <NUM>. For example, application <NUM> may connect to IoT middleware <NUM> located in the same region (e.g., Region <NUM>, the United States) as the application <NUM>. Application <NUM> may instruct the IoT middleware <NUM> to send the command to IoT device <NUM> using the declared channel in the channel subscription information <NUM>.

At <NUM>, method <NUM> may include sending the command to a GCF node. IoT middleware <NUM> may access the GCF node discovery service <NUM> to identify one or more GCF nodes <NUM>, <NUM> nearby a location of the IoT middleware <NUM>. For example, the IoT middleware <NUM> may connect to GCF node <NUM> located nearest to a location of the IoT middleware <NUM> (e.g., Region <NUM>, the United States).

IoT middleware <NUM> may send the command from application <NUM> to the GCF node <NUM> and may instruct the GCF node <NUM> to send the command to IoT device <NUM> using the specified channel.

At <NUM>, method <NUM> may include discovering the device session information of the IoT device. The GCF node <NUM> may access the device session manager <NUM> and may determine whether GCF node <NUM> hosts the device session for IoT device <NUM>. GCF node <NUM> may use the device session information <NUM> and the associated GCF node information <NUM> to determine whether the device session information <NUM> is associated with GCF node <NUM>. If a match occurs between the GCF node information <NUM> and GCF node <NUM>, GCF node <NUM> may determine that the device session for IoT device <NUM> is hosted by GCF node <NUM> and may transmit the control command to IoT device <NUM>.

However, if a match does not occur between the GCF node information <NUM> and GCF node <NUM>, GCF node <NUM> may use the GCF node information <NUM> to determine which GCF node is hosting the device session for IoT device <NUM>, in this example, GCF node <NUM> in Region <NUM>.

At <NUM>, method <NUM> may include forwarding the command and any IoT device information to the GCF node hosting the device session for the IoT device. The global IoT connectivity fabric <NUM> may enable communications between the different GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. One example may include using inter geographies and/or region message bus traffic for enabling communications between the different GCF nodes. As such, GCF node <NUM> may forward the command from the device and monitoring and management application <NUM> to GCF node <NUM>, the GCF node hosting the device session for IoT device <NUM>. In addition, GCF node <NUM> may forward the channel information for IoT device <NUM>.

At <NUM>, method <NUM> may include sending the command to the IoT device. GCF node <NUM> may send the command to IoT device <NUM> using the channel specified by IoT device <NUM>. The IoT device <NUM> receives the message and handles it as appropriate to the contents of the message. For example, the command may instruct IoT device <NUM> to unlock a door controlled by IoT device <NUM>.

As such, method <NUM> may use the global IoT connectivity fabric <NUM> to send commands from an application and deliver the commands to a remote IoT device.

Method <NUM> may also be used to broadcast messages to a plurality of IoT devices <NUM>. Assuming that the broadcast channel is configured at the application level, when the broadcast message is sent to IoT middleware <NUM>, IoT middleware <NUM> sends the broadcast message to all the GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> that are configured to receive messages from the application. The GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> with the help of the device session information <NUM>, may locate the IoT devices <NUM> that subscribed to the broadcast channel. The GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> forward the messages to the IoT devices <NUM> through the cached network connection.

Referring now to <FIG>, a method <NUM> for sending a command from a device monitoring and management application <NUM> to an IoT device <NUM> using the global IoT connectivity fabric <NUM> may be implemented by IoT system <NUM>. For example, device IoT device <NUM> may move to a new location relative to the location used in <FIG> and method <NUM> may be used to send a command to IoT device <NUM> at the new location. The actions of method <NUM> may be discussed below with reference to IoT system <NUM> and the architectures of <FIG>.

The global IoT connectivity fabric <NUM> allows a remote application <NUM> to control an IoT device <NUM> with a command sent through previously established communications channels. In addition, the global IoT connectivity fabric <NUM> may use a plurality of GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in different geographic regions to facilitate the command messaging.

At <NUM>, method <NUM> may include receiving GCF Nodes nearby a current location of an IoT device. IoT device <NUM> may send a request to GCF node discovery service <NUM> for a list of one or more GCF nodes <NUM>, <NUM> nearby a current location of the IoT device <NUM>. The request may include the current location of the IoT device <NUM>. IoT device <NUM> may have moved to a new location relative to the location of IoT device <NUM> in <FIG>. GCF node discovery service <NUM> may provide the one or more GCF nodes <NUM>, <NUM> that are nearby the new location of IoT device <NUM>. As such, as a location of the IoT device <NUM> changes, the one or more GCF nodes <NUM>, <NUM> nearby IoT device <NUM> may change.

At <NUM>, method <NUM> may include connecting to a GCF node. The IoT device <NUM> may select GCF node <NUM> to connect to based on the proximity in location of the GCF node <NUM> relative to the new location of IoT device <NUM>. For example, the IoT device <NUM> may select GCF node <NUM> because GCF node <NUM> is located nearest or closest to the IoT device <NUM>. In addition, if IoT device <NUM> received a plurality of GCF nodes <NUM>, <NUM> located within a radius of the IoT device <NUM>, the IoT device <NUM> may also use a quality of service criteria of the GCF nodes <NUM>, <NUM> when selecting which connectivity node for connecting with.

At <NUM>, method <NUM> may include publishing device session information. For example, GCF node <NUM> may publish the device session information <NUM> (<FIG>) for IoT device <NUM> to a device session manager <NUM>. The device session information <NUM> may include, for example, a connectivity state of the IoT device <NUM> and GCF node information <NUM> (<FIG>). The GCF node information <NUM> may identify the GCF node <NUM> currently connected to the IoT device <NUM>. The device session information <NUM> may change as a connectivity status of the IoT device <NUM> changes. For example, the device session information <NUM> reflect that IoT device <NUM> disconnected with GCF node <NUM> (<FIG>) and connected with GCF node <NUM> in response to IoT device <NUM> moving to a new location. As such, the device session information <NUM> reflects a current state of overall connectivity of the IoT device <NUM>.

In addition, GCF node <NUM> may publish channel subscription information <NUM> (<FIG>) received from the device metadata <NUM>. The channel subscription information <NUM> may identify which channels IoT device <NUM> declared for sending and/or receiving information. For example, the channels may be the same channels that IoT device <NUM> previously declared, such as, the one or more channels specified for receiving commands or other control messages from applications <NUM> and/or services. As such, the channel subscription information <NUM> may not change in response to IoT device <NUM> moving to a new location.

At <NUM>, method <NUM> may include sending a command to an IoT device. A device monitoring and management application <NUM> may want to send a command and/or a control message to IoT device <NUM>. The device monitoring and management application <NUM> may be located in a different region than the IoT device <NUM>. For example, the device monitoring and management application <NUM> may be located in region <NUM> (e.g., the United States) and the IoT device <NUM> may be located in region N (e.g., Australia).

The device monitoring and management application <NUM> may access device metadata <NUM> for IoT device <NUM> and the channel subscription information <NUM>. The device monitoring and management application <NUM> may use the channel subscription information <NUM> to identify which channel to use when sending the command and/or control message to IoT device <NUM>. The channel subscription information <NUM> may include an in-memory distributed hash table with the channel ID, subscriber ID, and/or the GCF node ID. For example, application <NUM> may use the same channel to send the command and/or control message to IoT device <NUM> as previously used to communicate with IoT device <NUM>.

At <NUM>, method <NUM> may include sending the command to a GCF node. IoT middleware <NUM> may access the GCF node discovery service <NUM> to identify one or more GCF nodes <NUM> nearby a location of the IoT middleware <NUM>. For example, the IoT middleware <NUM> may connect to GCF node <NUM> located nearest to a location of the IoT middleware <NUM> (e.g., Region <NUM>, the United States). IoT middleware <NUM> may send the command from application <NUM> to the GCF node <NUM> and may instruct the GCF node <NUM> to send the command to IoT device <NUM> using the specified channel.

However, if a match does not occur between the GCF node information <NUM> and GCF node <NUM>, GCF node <NUM> may use the GCF node information <NUM> to determine which GCF node is hosting the device session for IoT device <NUM>, in this example, GCF node <NUM> in Region N.

At <NUM>, method <NUM> may include forwarding the command and any IoT device information to the GCF node hosting the device session for the IoT device. The global IoT connectivity fabric <NUM> may enable communications between the different GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> using, for example, inter geographies and/or region message bus traffic. As such, GCF node <NUM> may forward the command from the device and monitoring and management application <NUM> to GCF node <NUM>, the GCF node hosting the device session for IoT device <NUM>, using inter geographies and/or region message bus traffic. In addition, GCF node <NUM> may forward the channel information for IoT device <NUM>.

At <NUM>, method <NUM> may include sending the command to the IoT device. GCF node <NUM> may send the command to IoT device <NUM> using the channel specified by IoT device <NUM>. The IoT device <NUM> receives the message and handles it as appropriate to the contents of the message. For example, the command may instruct IoT device <NUM> to take a pressure reading.

Referring now to <FIG>, a method <NUM> for sending telemetry data from an IoT device to a monitoring and management application <NUM> using the global IoT connectivity fabric <NUM>. The global IoT connectivity fabric <NUM> may use a plurality of GCF nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in different geographic regions to facilitate the transmission of data from the IoT device <NUM> to the monitoring and management application <NUM>. The actions of method <NUM> may be discussed below with reference to IoT system <NUM> and the architectures of <FIG>.

At <NUM>, method <NUM> may include receiving GCF Nodes nearby a current location of the IoT device. IoT device <NUM> may send a request to GCF node discovery service <NUM> for one or more GCF nodes <NUM> located nearby a current location of the IoT device <NUM>. For example, GCF node discovery service <NUM> may provide the one or more GCF nodes <NUM> to IoT device <NUM> through domain name server (DNS) proximity. The GCF node discovery service <NUM> may also provide the one or more GCF nodes <NUM> to IoT device <NUM> in response to IoT device <NUM> explicitly calling GCF node discovery service <NUM> to find a nearby connectivity node. As such, as a location of the IoT device <NUM> changes, the one or more GCF nodes <NUM> nearby IoT device <NUM> may change.

At <NUM>, method <NUM> may include connecting to a GCF node. The IoT device <NUM> may select GCF node <NUM> to connect to based on the proximity in location of the GCF node <NUM> relative to a current location of the IoT device <NUM>. For example, the IoT device <NUM> may select GCF node <NUM> because GCF node <NUM> is located nearest or closest to the IoT device <NUM> in Region N. , e.g., Australia.

At <NUM>, method <NUM> may include publishing device session information. For example, GCF node <NUM> may publish the device session information <NUM> (<FIG>) for IoT device <NUM> to a device session manager <NUM>. The device session information <NUM> may include, for example, a connectivity state of the IoT device <NUM> and GCF node information <NUM> (<FIG>). The GCF node information <NUM> may identify the GCF node <NUM> currently connected to the IoT device <NUM>. The device sessions information <NUM> may be updated as a connectivity status of the IoT device <NUM> changes (e.g., disconnects or connects) and/or the IoT device <NUM> moves locations and connects with a different GCF node <NUM>, <NUM>, <NUM>, <NUM>. As such, the device session information <NUM> reflects a current state of overall connectivity of the IoT device <NUM>.

In addition, GCF node <NUM> may publish channel subscription information <NUM> (<FIG>) received from the device metadata <NUM>. The channel subscription information <NUM> may identify which channels IoT device <NUM> declared for sending and/or receiving information. For example, IoT device <NUM> may specify a publisher channel to send data (e.g., telemetry data or other information). IoT device <NUM> may also specify one or more channels for receiving commands or other control messages from applications <NUM> and/or services. IoT device <NUM> may also specify one or more channels for receiving broadcast messages from applications <NUM> and/or services.

At <NUM>, method <NUM> may send the telemetry data to the GCF node. For example, IoT device <NUM> may use sensors to acquire telemetry data, such as, but not limited to, temperature readings, measurements of pipeline flows, measurements of traffic flows, and/or pressure readings. IoT device <NUM> may use the connection established with GCF node <NUM> to send the telemetry data acquired by the sensor of the IoT device <NUM> to GCF node <NUM>.

At <NUM>, method <NUM> may include discovering subscribers of the IoT device. GCF node <NUM> may access the channel subscription information <NUM> to determine one or more applications subscribed to receiving information and/or data transmitted from IoT device <NUM>. The channel subscription information <NUM> may identify any channels subscribed to by applications. As such, the channel subscription information <NUM> may provide the channel information for the channels that IoT device <NUM> is using to publish or send the telemetry data and which applications have subscribed to receive the information sent from IoT device <NUM>. For example, device and monitoring application <NUM> may have specified to receive information and/or data from IoT device <NUM>.

At <NUM>, method <NUM> may include forwarding the telemetry data to the device subscribers. The GCF node <NUM> may forward the telemetry data from IoT device <NUM> and the channel information to the GCF node <NUM> connected to the IoT middleware <NUM> communicating with device monitoring and management application <NUM>. For example, the device monitoring and management application <NUM> may be located in Region <NUM>, e.g., the United States, while the IoT device <NUM> is located is Region N, e.g., Australia. Device monitoring and management application <NUM> may communicate with IoT middleware <NUM> located in the same region as the device monitoring and management application <NUM> (e.g., Region <NUM>, the United States).

At <NUM>, method <NUM> may include publishing the telemetry data to the IoT middleware. IoT middleware <NUM> may receive the telemetry data from GCF node <NUM>.

At <NUM>, method <NUM> may include publishing telemetry data to the application. IoT middleware <NUM> may publish the telemetry data and/or any device state information received from IoT device <NUM> to the device monitoring and management application <NUM>.

While method <NUM> illustrates a single application receiving the telemetry data from IoT device <NUM>, if a plurality of applications subscribed to receive the telemetry data from IoT device <NUM>, method <NUM> may be used to transmit the telemetry data to the plurality of applications.

Each of the components described herein may be in communication with each other using any suitable communication technologies. In addition, while the components are shown to be separate, any of the components or subcomponents may be combined into fewer components, such as into a single component, or divided into more components as may serve a particular implementation.

Moreover, the components may include hardware, software, or both. For example, the components may include one or more instructions stored on a computer-readable storage medium and executable by processors of one or more computing devices. The processors may be a general-purpose single or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. When executed by the one or more processors, the computer-executable instructions of one or more computing devices can perform one or more methods described herein. Alternatively, the components may include hardware, such as a special purpose processing device to perform a certain function or group of functions. Additionally, or alternatively, the components may include a combination of computer-executable instructions and hardware.

Instructions and data may be stored in memory. The instructions may be executable by the processor to implement some or all of the functionality disclosed herein. Executing the instructions may involve the use of the data that is stored in the memory. Any of the various examples of modules and components described herein may be implemented, partially or wholly, as instructions stored in memory and executed by the processor. Any of the various examples of data described herein may be among the data that is stored in memory and used during execution of the instructions by the processor. For example, the memory may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage mediums, optical storage mediums, flash memory devices in RAM, on-board memory included with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, and so forth, including combinations thereof.

The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a specific manner. Any features described as modules, components, or the like may also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a non-transitory processor-readable storage medium comprising instructions that, when executed by at least one processor, perform one or more of the methods described herein. The instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform particular tasks and/or implement particular data types, and which may be combined or distributed as desired in various embodiments.

Computer-readable mediums may be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable mediums that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable mediums that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable mediums: non-transitory computer-readable storage media (devices) and transmission media.

As used herein, non-transitory computer-readable storage mediums (devices) may include RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

The steps and/or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

The articles "a," "an," and "the" are intended to mean that there are one or more of the elements in the preceding descriptions. Additionally, it should be understood that references to "one implementation" or "an implementation" of the present disclosure are not intended to be interpreted as excluding the existence of additional implementations that also incorporate the recited features. For example, any element described in relation to an implementation herein may be combinable with any element of any other implementation described herein. Numbers, percentages, ratios, or other values stated herein are intended to include that value, and also other values that are "about" or "approximately" the stated value, as would be appreciated by one of ordinary skill in the art encompassed by implementations of the present disclosure. A stated value should therefore be interpreted broadly enough to encompass values that are at least close enough to the stated value to perform a desired function or achieve a desired result. The stated values include at least the variation to be expected in a suitable manufacturing or production process, and may include values that are within <NUM>%, within <NUM>%, within <NUM>%, or within <NUM>% of a stated value.

A person having ordinary skill in the art should realize in view of the present disclosure that equivalent constructions do not depart from the scope of the present invention and that various changes, substitutions, and alterations may be made to implementations disclosed herein without departing from the scope of the present invention as defined by the appended claims.

Equivalent constructions, including functional "means-plus-function" clauses are intended to cover the structures described herein as performing the recited function, including both structural equivalents that operate in the same manner, and equivalent structures that provide the same function. It is the express intention of the applicant not to invoke means-plus-function or other functional claiming for any claim except for those in which the words 'means for' appear together with an associated function. Each addition, deletion, and modification to the implementations that falls within the meaning and scope of the claims is to be embraced by the claims.

Claim 1:
An internet of things, IoT, system (<NUM>), comprising:
a middleware layer (<NUM>) including IoT middleware (<NUM>) in communication with an application (<NUM>) that provides services to at least one IoT device (<NUM>), wherein the at least one IoT device (<NUM>) includes metadata (<NUM>) with a communication channel (<NUM>,<NUM>,<NUM>) declared for communicating with the application (<NUM>), wherein the metadata further includes declarative communication pathways or routes for communications between the at least one IoT device and the application; and
a connectivity fabric layer (<NUM>) that accesses the metadata and implements communication pathways or routes for communications between the at least one IoT device and the application, the connectivity fabric layer including:
a plurality of global IoT connectivity fabric nodes (<NUM>) that create a global IoT connectivity fabric (<NUM>) that enables establishment of the communication channel (<NUM>, <NUM>, <NUM>) between the application (<NUM>) and the at least one IoT device (<NUM>), wherein the plurality of global IoT connectivity fabric nodes (<NUM>) communicate using inter geographies message bus traffic;
a device session manager (<NUM>) that manages channel subscription information (<NUM>) for the communication channel (<NUM>, <NUM>, <NUM>) from the metadata (<NUM>), wherein the application (<NUM>) subscribes to the communication channel (<NUM>, <NUM>, <NUM>); and
a global IoT connectivity fabric node discovery service (<NUM>) that provides to the at least one IoT device (<NUM>) dynamic discovery of a nearby global IoT connectivity fabric node of the plurality of global IoT connectivity fabric nodes (<NUM>), wherein the at least one IoT device (<NUM>) establishes a network connection (<NUM>) with the nearby global IoT connectivity fabric node to communicate with the application (<NUM>), wherein the network connection (<NUM>) comprises the communication channel (<NUM>, <NUM>, <NUM>) and wherein the global IoT connectivity fabric node discovery service (<NUM>) provides the nearby global IoT connectivity fabric node using domain name server, DNS, proximity.