Common Interface System for Mesh Networking and Fog Computing Systems

Abstract

Methods, systems, and storage media for an Internet of Things (IoT) hub and an IoT bracket in a Mesh network and / or a fog computing system while providing interoperability between IoT devices provided by various manufacturers, suppliers, and service providers. The IoT devices may be connected or attached to the IoT brackets, and the IoT brackets may transfer data among themselves via a bracket network. The IoT brackets may also transfer IoT data to and from an IoT hub via a hub network. The IoT hub may transfer IoT data to and from a client and / or a server via a wide area network using a wired or wireless communication protocol. The client may access the resources and / or services provided by the IoT devices by accessing the IoT hub via a dedicated application. Other embodiments may be described and / or claimed.

Description

Technical Field

[0001] The present disclosure relates to the technical fields of Mesh (mesh) networks and fog computing, and more particularly, to apparatuses, methods, and storage media that are to be used as hubs and cradles in Mesh networks and for computing systems while providing IoT device interoperability capabilities. Background Art

[0002] Mesh networking is a type of ad hoc network in which each node in the network relays data to other nodes in the network. Many implementations of Mesh networks involve the Internet of Things (“IoT”), which is a network of objects or “things,” each of which is embedded with hardware and / or software that enables connectivity to the network. Objects, devices, sensors, or “things” (also referred to as “IoT devices”) connected to the network typically provide information to manufacturers, operators, and / or other connected devices in order to track the usage of the objects and / or obtain services. IoT devices are deployed in homes, offices, manufacturing facilities, and / or other similar environments. When IoT devices (e.g., autonomous sensors) are deployed in an environment, that environment may be referred to as a “smart environment.” For example, when IoT devices (e.g., autonomous sensors) are deployed in a home, that home may be referred to as a “smart home.” To provide various services, service providers, vendors, or device manufacturers (MFGs) may allow consumers / users to deploy and operate their own networks of IoT devices, and service providers, vendors, and MFGs may provide platforms to control the IoT devices in the IoT network and / or analyze data based on sensed information or captured events.

[0003] Most Mesh network solutions for IoT devices implement a walled garden approach, in which sensors, sensor hubs, and other devices (e.g., electromechanical components (EMCs)) provided by a particular service provider, vendor, or MFG are only able to operate with other sensors / hubs / devices produced or sold by that particular service provider, vendor, or MFG. This means that devices provided by different service providers, vendors, or MFGs typically do not interact with each other and separate platforms are required to control the devices provided by each service provider, vendor, and MFG. This can lead to network degradation as different devices compete for the same network resources without a common traffic management scheme.

[0004] One solution to address these issues includes using a dedicated hub to control the various IoT devices deployed in the environment. These hubs are sometimes referred to as "sensor hubs", "gateways", "home controllers", "smart things hubs", etc. To provide interoperability between IoT devices provided by different service providers, vendors, or MFGs, conventional hubs need to install drivers and / or install middleware applications for protocol conversion for each brand or model of IoT device, so that the hub can interact with devices provided by various service providers, vendors, and MFGs. In addition to occupying the limited memory of the hub, it may also be necessary to update the middleware or drivers regularly, which means that the operation of the hub and / or the quality of interoperability between IoT devices depends on the quality of management provided by the hub users and the quality of updates released by each service provider, vendor, and MFG. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. In the figures of the drawings, embodiments are shown by way of example and not by way of limitation.

[0006] Figure 1 Shows an arrangement depicting the interconnection that can exist between a network and an Internet of Things (IoT) network according to various embodiments;

[0007] Figure 2 Shows an example domain topology according to various embodiments;

[0008] Figure 3 Shows an example cloud computing network or cloud communicating with multiple IoT devices according to various embodiments;

[0009] Figure 4 Shows an arrangement of a cloud computing network or cloud communicating with a Mesh network of IoT devices or an IoT fog according to various embodiments;

[0010] Figure 5 Shows an example environment in which various embodiments described in the present disclosure can be implemented;

[0011] Figure 6 Shows an example implementation of a computing platform to be adopted by an IoT device bracket according to various embodiments;

[0012] Figure 7 Shows an example implementation of a computing platform to be adopted by an IoT device hub according to various embodiments;

[0013] Figure 8 Shows an example protocol stack according to various embodiments;

[0014] Figure 9 Illustrates an example bootstrapping process for a newly installed bracket according to various embodiments;

[0015] Figure 10 Illustrates an example process for starting a new IoT device according to various embodiments; and

[0016] Figure 11 Illustrates an example process for transferring data in a Mesh network or a fog computing system according to various embodiments. DETAILED DESCRIPTION

[0017] The embodiments discussed herein relate to hubs and brackets for Mesh networking and fog computing while providing device interoperability capabilities. In an embodiment, in a building (e.g., a home, office, retail establishment, restaurant, factory, or manufacturing facility, etc.), for one or more levels of complexity, a hub and one or more brackets are provided as a base layer to transform the building into a "smart" building. Most existing smart buildings (e.g., a single-family home or a multi-story office building) require a collection of sensors, actuators, and hubs in order to control different aspects / services. Existing solutions for implementing smart buildings have the following disadvantages:

[0018] ● Lack of a single platform or system for controlling all categories of sensors and actuators;

[0019] ● Incompatibility of systems from various manufacturers (MFG) and suppliers is insufficient to share data for sensors deployed at relatively large distances from the hub and bridge bandwidth gaps;

[0020] ● Different categories of smart devices / services (e.g., surveillance systems, connected lighting systems, temperature control systems, etc.), which may be provided by different MFG, suppliers, etc., typically include their own hubs and applications for authentication, policy management, and enforcement, making it difficult to manage and access the various systems or services;

[0021] ● Smart devices and / or categories of smart devices / services provided by different MFG, suppliers, etc. may include different communication technologies and thus lack common device interconnectivity;

[0022] ● Smart devices provided by different MFG, suppliers, etc. may have their own installation processes, which may be specific to the deployment area / region (e.g., when one or more smart devices are migrated to a new area, the installation process may need to be repeated);

[0023] ● Most hubs are not scalable because the number of devices they can control is limited; there is no standard communication protocol for securely sharing data between devices provided by different MFG, suppliers, etc.;

[0024] ● Conventional routers have a limited number of local area network (LAN) ports, and the router can only handle a limited number of wireless devices in an efficient manner, which makes the conventional router not meet the expectations of a smart building hub; and

[0025] ● Multiple devices connected to a public wireless LAN may cause network or smart building system degradation because each device competes for network resources, and conventional hubs / routers cannot provide proper traffic management.

[0026] Embodiments of the smart building system discussed herein solve or mitigate the previously mentioned disadvantages by providing standard access and control interfaces for various smart devices (also referred to as "Internet of Things devices" or "IoT devices") via a carriage or a backplane and a hub. The hub can be a gateway device (e.g., a router, a switch, a cable modem, etc.) that provides communication to a remote system (e.g., the Internet) for the carriage and each IoT device connected to each carriage and also manages policies / configurations for communication between carriages. The carriage can be a device to which one or more IoT devices (e.g., autonomous sensors, EMCs, etc.) can be connected using a standard interconnection interface. The interface can include a wireless interface, a wired connection, and / or input / output pins. Each carriage can also include a programmable communication interface (e.g., a field programmable device (FPD)) that allows each carriage to communicate with other carriages via a carriage-carriage network and communicate with one or more hubs via a carriage-hub network.

[0027] In addition, each carriage can implement a data plane entity or layer and a control plane entity / layer. The data plane entity / layer can be used to collect IoT data from the attached IoT devices and provide the IoT data to other IoT devices attached to other carriages and / or hubs. The control plane entity / layer can be used to collect hardware capability data (HCD) and / or hardware status data (HSD) from the attached IoT devices, and these data can be provided to other carriages and / or hubs. IoT devices provided by different service providers, suppliers, and / or manufacturers (MFG) can use the HCD and / or HSD to interact with each other via their corresponding carriages without specific middleware or drivers provided by different service providers, suppliers, and / or MFG.

[0028] In some cases, the arrangement 50 can be a base installation of empty carriages, and the hub can be easily provided by a building contractor for a new building, or it can be added to an existing home / office location.

[0029] In the following detailed description, reference is made to the accompanying drawings, which form a part of the detailed description, wherein like reference numerals refer to like parts throughout, and the drawings are shown by way of illustration of embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural and / or logical changes may be made without departing from the scope of the present disclosure. Accordingly, the following detailed description should not be taken in a limiting sense, and the scope of the embodiments is defined by the appended claims and their equivalents.

[0030] The various operations may be described sequentially as a number of discrete actions and / or operations in a manner most helpful in understanding the claimed subject matter. However, the order of description should not be construed as implying that the various operations are necessarily order dependent. Specifically, these operations may not be performed in the order presented. The described operations may be performed in an order different from the described embodiments. Various additional operations may be performed in additional embodiments and / or the described operations may be omitted.

[0031] For the purposes of the present disclosure, the phrase "A and / or B" means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). For the purposes of the present disclosure, the phrase "at least one of A and B" means (A), (B), or (A and B).

[0032] The description may use the phrases "in one embodiment" or "in embodiments", which may all refer to one or more of the same or different embodiments. Additionally, the terms "comprising", "including", "having", etc., used with respect to embodiments of the present disclosure are synonymous.

[0033] Furthermore, it should be noted that an embodiment may be described as a process, which is depicted as a flowchart, process diagram, data flow diagram, structure diagram, or block diagram. Although a flowchart may describe operations as sequential processing, many of the operations may be performed in parallel, concurrently, or simultaneously. Additionally, the order of the operations may be rearranged. The process may terminate when its operations are completed, but may also have additional steps not included in the figures. The process may correspond to a method, function, procedure, subroutine, subprogram, etc. When the process corresponds to a function, its termination may correspond to the function returning to the calling function and / or the main function. Additionally, the process may be implemented by hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the necessary tasks may be stored in a machine or computer-readable medium. A code segment may represent any combination of a process, function, subroutine, program, routine, subroutine, module, program code, software package, class, or instructions, data structures, program statements, etc.

[0034] As used herein, the term "circuit" may refer to, be part of, or include the following: application specific integrated circuit (ASIC), field programmable gate array (FPGA), electronic circuit, processor (shared, dedicated, or grouped) executing one or more software or firmware programs with machine instructions (generated from assembly instructions or compiled from higher level language instructions), graphics processing unit (GPU) and / or memory (shared, dedicated, or grouped), combinational logic circuit, and / or other suitable components providing the described functionality. As used herein, the term "module" may include logic (including operating system or application instructions, data, etc.) that is at least partially operable in a circuit. A circuit may implement a module to cause the module to perform the operations described herein. As used herein, the term "memory" may refer to one or more hardware devices for storing data, including random access memory (RAM), magnetic RAM, core memory, read only memory (ROM), disk storage media, optical storage media, flash devices, and / or other machine readable media for storing data. The term "computer readable medium" may include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying instructions and / or data.

[0035] As used herein, the term "computer device" may describe any physical hardware device capable of performing the following operations: sequentially and automatically performing a sequence of arithmetic or logical operations, being equipped to record / store data on a machine-readable medium, and sending and receiving data from one or more other devices in a communication network. A computer device may be considered synonymous with the following terms and may sometimes be referred to as such hereinafter: computer, computing platform, computing device, client, mobile, mobile unit, mobile terminal, mobile station, mobile user, mobile device, user equipment (UE), user terminal, machine type communication (MTC) device, machine-to-machine (M2M) device, M2M device (M2ME), Internet of Things (IoT) device, subscriber, user, receiver, etc. The term "computer system" may include any type of interconnected electronic device, computer device, or its components (e.g., cellular phone or smartphone, tablet personal computer, wearable computing device, autonomous sensor, laptop computer, desktop personal computer, video game console, digital media player, handheld messaging device, personal data assistant, e-book reader, augmented reality device, in-vehicle infotainment (IVI) and / or in-vehicle entertainment (ICE) device, vehicle-to-vehicle (V2V) or vehicle-to-everything (V2X) communication system, universal serial bus (USB) hub, keyboard video mouse (KVM) switch / hub, docking station, dock, sensor bracket, IoT bracket, bracket, port replicator, server computer device (e.g., stand-alone, rack-mounted, blade, etc.), cloud computing service / system, network element, and / or any other similar electronic device). Additionally, the term "computer system" and / or "system" may refer to various components of a computer that are communicatively coupled to each other. Additionally, the term "computer system" and / or "system" may refer to multiple computer devices and / or multiple computing systems that are communicatively coupled to each other and are configured to share computing resources and / or networking resources.

[0036] As used herein, the term "network element" may refer to one or more computer devices or one or more electronic devices that provide one or more wired or wireless networks (or provide access thereto). A "network element" may be considered synonymous with and / or refer to a networked computer, networking hardware, network device, access point, router, switch, hub, bridge, gateway, base station, core network element, server, and / or other similar devices. The term "network element" may describe a device that provides radio baseband functionality for data and / or voice connectivity between a network element and one or more users. As used herein, a "network element" may include one or more devices that provide multiple radio frequency networks.

[0037] As used herein, the term "link" as used herein may refer to any tangible or intangible transmission medium for transmitting data or a data stream. Additionally, the term "link" may be synonymous with and / or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "channel", "data link", "radio link", "carrier", "radio frequency carrier", and / or any other similar term denoting the path or medium through which data is transmitted.

[0038] As used herein, the term "network operator" may be considered synonymous with and / or refer to a mobile network operator (MNO), cellular network operator, wireless service provider, wireless carrier, mobile network operator, virtual MNO, etc. The term "network operator" may describe any service provider related to a communication network including wired and wireless communication networks. Additionally, the term "network operator" may describe an entity that owns or controls the elements necessary for providing services related to a communication network (including radio spectrum allocation, billing and subscription related services, provisioning of computer systems and / or other similar services from a regulatory body, wireless network infrastructure, and / or backhaul infrastructure for one or more radio spectrum authorizations).

[0039] As used herein, terms such as "computing resource", "hardware resource", "resource", etc. may refer to physical or virtual devices, physical or virtual components within a computing environment, and / or physical or virtual components within a particular device (e.g., computer device, mechanical device, memory space, processor / CPU time and / or processor / CPU utilization, hardware time or utilization, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, etc.). As used herein, the term "network resource" may refer to computing resources accessible to a computer device via a communication network.

[0040] As used herein, the term "Mesh network" may refer to a network topology in which each node in the network collaborates in distributing data in the network by relaying the data sent by a source node along a route or path until it reaches a destination node. The route or path may include multiple nodes, where the data propagates along the route or path by hopping from one node to another in the route / path until it reaches the destination node. As used herein, terms such as "fog device", "fog computing", "fog computing system", etc. may refer to a distributed infrastructure or network topology in which various application processing and / or services are managed or operated by devices (e.g., "edge devices") located at the edge or end of the network, rather than establishing a communication channel for cloud computing services to perform these functions.

[0041] 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 at a very low level to provide functionality and data collection. As used herein, IoT devices can include semi-autonomous devices that perform functions (such as sensing or controlling, etc.) and communicate with other IoT devices and a broader network (such as the Internet). Generally, IoT devices are limited in terms of memory, size, or functionality, thus allowing for a larger number to be deployed for a similar cost as a smaller number of larger devices. However, IoT devices can be smartphones, laptop devices, tablets, or PCs or other larger devices. Additionally, IoT devices can be virtual devices (such as applications on a smartphone or other computing device). IoT devices can include an IoT gateway for coupling the IoT device to other IoT devices and cloud applications for data storage, processing control, etc.

[0042] The network of IoT devices can include commercial and home automation devices (such as water distribution 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, for example, to control the system or access data.

[0043] Future growth of the Internet can include a very large number of IoT devices. Thus, as described herein, many innovations regarding the future Internet address the following requirements for all these layers: unhindered growth, discovery of connected resources and making them accessible, and support for 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 a specific purpose. Additionally, protocols are part of the construction of human-accessible services that operate regardless of location, time, or space. These innovations include the infrastructure for service delivery and association (such as hardware and software). Services can be provided according to the quality of service (QoS) terms specified in the service level and service delivery agreements. The use of IoT devices and networks presents many new challenges in heterogeneous networks with connectivity including a combination of wired and wireless technologies such as Figure 1 and Figure 2 depicted.

[0044] Figure 1 Arrangement 10 is shown that depicts an interconnection that can exist between the Internet 100 and an IoT network according to various embodiments. The interconnection can couple a smaller network 102 (and even individual IoT devices 104) to the fiber optic backbone 106 of the Internet 100. For simplicity of the drawing, not every device 104 or other object is labeled.

[0045] In Figure 1Among them, the top - level provider (which can be called the tier - 1 provider 108) is coupled to other providers (e.g., the secondary or tier - 2 provider 110) through the fiber - optic backbone of the Internet. In one example, the tier - 2 provider 110 can be coupled to the tower 112 of the LTE cellular network, for example, through other fiber - optic links, through microwave communication 114, or through other communication technologies. The tower 112 can be coupled to the Mesh network including IoT devices 104 through the LTE communication link 116 (e.g., through the central node 118). The communication between each IoT device 104 can also be based on the LTE communication link 116. In another example, the high - speed uplink 120 can couple the tier - 2 provider 110 to the gateway (GW) 120. Multiple IoT devices 104 can communicate with the GW 120 and communicate with each other through the GW 120 (e.g., via the BLE link 122).

[0046] The fiber - optic backbone 106 can couple lower - level service providers (e.g., the tier - 3 provider 124) to the Internet. The tier - 3 provider 124 can be regarded as a general Internet service provider (ISP) that, for example, purchases access to the fiber - optic backbone 110 from the tier - 2 provider 110 and provides access to the corporate GW 126 and other consumers. From the corporate GW 126, communication with the IoT devices 104 can be carried out through the wireless local area network (WLAN) through the link 128. The Wi - Fi link 128 can also be used to couple to the low - power wide - area (LPWA) GW 130, and the LPWA GW 130 can communicate with the IoT devices 104 through, for example, an LPWA link 132 that is compatible with the LoRaWan specification promulgated by the LoRa Alliance.

[0047] The tier - 3 provider 124 can also provide access to the Mesh network 134 through the coordinator device 136, and the coordinator device 136 communicates with the tier - 3 provider 124 using any number of communication links (e.g., the LTE cellular link, the LPWA link, or the link 138 based on the IEEE 802.15.4 standard (e.g., )). Other coordinator devices 136 can provide a chain of links that form a cluster tree of the linked devices.

[0048] The IoT device 104 can be any object, device, sensor, or "thing" that is embedded with hardware components and / or software components enabling an object, device, sensor, or "thing" to capture and / or record data associated with an event and to transfer such data over a network to one or more other devices with little or no user intervention. For example, in various embodiments, the IoT device 104 can be a non-biological device, such as an autonomous sensor, a gauge, a meter, an image capture device, a microphone, an MTC device, an M2M device, a lighting device, an audio transmitting device, an audio and / or video playback device, an electromechanical device (e.g., a switch, an actuator, etc.), and the like. In some embodiments, the IoT device 104 can be a biological device, such as a monitoring implant, a biosensor, a biochip, and the like. In other embodiments, the IoT device 104 can be a computer device embedded in a computer system and coupled to the communication circuitry of the computer system. In these embodiments, the IoT device 104 can be a system on a chip (SoC), a universal integrated circuit card (UICC), an embedded UICC (eUICC), etc., and the computer system can be a mobile station (e.g., a smart phone) or a UE, a laptop computer, a wearable device (e.g., a smart watch, a health tracker, etc.), a "smart" appliance (e.g., a television, a refrigerator, a security system, etc.), and the like.

[0049] Each IoT device 104 can include one or more memory devices and one or more processors to capture and store / record data. Each IoT device 104 can include appropriate communication circuitry (e.g., a transceiver, a modem, antenna elements, etc.) to transfer (e.g., send and receive) the captured and stored / recorded data. Additionally, each IoT device 104 can include other transceivers that communicate using additional protocols and frequencies. This is further discussed with reference to Figures 5 - 8 herein.

[0050] According to various embodiments, the IoT device 104 can be attached to or coupled to a bracket within a Mesh network or a fog computing system. The network or system can include multiple brackets (each bracket including one or more attached IoT devices 104) and at least one hub or gateway device. The hub can manage the communication between the individual brackets and the attached IoT devices 104 in the network / system, and can also provide connectivity to a larger network (such as the Internet, an enterprise or private network, a local area network (LAN) or a wireless LAN (WLAN), etc.). The brackets and the hub can be equipped with information (such as what is referred to herein as a "modem profile") to configure configurable communication circuitry to perform communication in the corresponding network. This can allow the IoT device 104 to communicate using multiple wireless communication protocols without the IoT device 104 including separate hardware communication modules for each wireless communication protocol. The wireless communication protocol can be any suitable set of standardized rules or instructions implemented by the IoT device 104 to communicate with other devices, including instructions for packetizing / depacketizing data, instructions for modulating / demodulating signals, instructions for implementing a protocol stack, etc.

[0051] In an embodiment, one or more of the tower 112, GWs 120, 126, and 130, the coordinator device 136, etc. can also be combined with the modem technologies specifically referred to herein Figures 5 - 9 as described.

[0052] Technologies and networks can enable exponential growth of devices and networks. As technology grows, the development of networks can be targeted at self-management, functional evolution, and collaboration without direct human intervention. Thus, technology will enable networks to operate without a central control system. The technologies described herein can go beyond current capabilities to automate network management and operation functions.

[0053] Figure 2 An example domain topology 200 of multiple IoT networks that can be coupled to GW 204 via a backbone link 202 is shown according to various embodiments. Items with the same number are as described with respect to Figure 1 that. Additionally, to simplify the drawings, not every device 104 or communication link 116, 122, 128, or 132 is labeled. The backbone link 202 can include any number of wired or wireless technologies and can be part of a local area network (LAN), a wide area network (WAN), or the Internet. Similarly, in an embodiment, one or more of the IoT devices 104, GW 204, etc. can be combined with the modem technologies specifically referred to herein Figure 1 as described. Figures 5 - 9 that.

[0054] The network topology 200 may include any number of types of IoT networks (e.g., Mesh network 206 using BLE link 122). Other IoT networks that may exist include WLAN network 208, cellular network 210, and LPWA network 212. Each of these IoT networks may provide opportunities for new developments as described herein. For example, communication between IoT devices 104 (e.g., via backbone link 202) may 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 may be implemented on an interconnected heterogeneous infrastructure. This allows the systems and networks to move towards autonomous operation.

[0055] In these types of autonomous operations, machines can contract for human resources and negotiate partnerships with other machine networks. This may allow for the achievement of mutual goals and balanced service delivery against the outlined and planned service level agreements, and the implementation of solutions that provide metering, measurement, and traceability and trackability. The creation of new supply chain structures and methods may enable a large number of services to be created, mined for value, and collapsed without human involvement.

[0056] The IoT network can be further enhanced by integrating sensing technologies (e.g., sound, light, electronic traffic, face and pattern recognition, smell, vibration) into the autonomous organization. The integration of the sensing system may allow for systematic and autonomous communication and coordination for service delivery towards contract-based service goals, orchestration of resources, and swarming and fusion based on quality of service (QoS).

[0057] A system that performs in-line data-to-information transformation may enhance Mesh network 206. For example, a self-forming chain of processing resources including multi-link networks may distribute the transformation of raw data to information in an efficient manner, as well as the ability to distinguish between assets and resources and their respective association management. Additionally, appropriate components of the infrastructure and resource-based trust and service indices may be inserted to improve data integrity, quality, assurance, and the delivery of measures of data confidence.

[0058] WLAN network 208 may use a system that performs standard conversion to provide multi-standard connectivity, enabling IoT devices 104 using different protocols to communicate. Other systems may provide seamless interconnectivity on a multi-standard infrastructure including visible and hidden Internet resources.

[0059] Offloading data, extending communication to more remote devices, or both can enhance communication in the cellular network 210. The LPWA network 212 can include a system that performs non-Internet Protocol (IP) to IP interconnection, addressing, and routing.

[0060] Figure 3 An example cloud computing network or cloud 302 for communicating with multiple Internet of Things (IoT) devices according to various embodiments is shown. The cloud 302 can represent the Internet, one or more cellular networks, a local area network (LAN) or wide area network (WAN) including a proprietary and / or enterprise network for a company or organization, or a combination thereof. The components for these communication systems can depend at least in part on the type of network and / or environment selected. The protocols and components for communicating via these networks are well known and will not be discussed in detail herein. However, it should be understood that the cloud 302 can be associated with a network operator that owns or controls the devices and other elements necessary for providing network-related services (e.g., one or more base stations or access points, and one or more servers for routing digital data or telephone calls (e.g., a core network or backbone network)).

[0061] Figure 3 The IoT devices in can be the same as or similar to the IoT devices 104 discussed with respect to Figures 1 - 2 The IoT devices can include any number of different types of devices grouped in various combinations (e.g., the IoT group 306, which can include IoT devices that provide one or more services for a particular user, consumer, organization, etc.). A service provider can deploy the IoT devices in the IoT group 306 to a specific area (e.g., a geographical location, a building, etc.) to provide one or more services. In one example, the IoT group 306 can be a traffic control group, where the IoT devices in the IoT group 306 can include traffic lights, traffic flow monitors, cameras, weather sensors, etc., to provide traffic control and traffic analysis services for a municipality or other similar entity. Similar to Figures 1 - 2 In an embodiment, one or more of the IoT devices 314 - 324, GW 310, etc. can be combined with the modem technology specifically described herein with reference to Figures 5 - 9

[0062] ​The IoT group 306 or other subgroups can communicate with the cloud 302 via a wireless link 308 (e.g., an LPWA link, etc.). Additionally, a wired or wireless subnet 312 can allow IoT devices to communicate with each other, for example, via a local area network, a wireless local area network, etc. IoT devices can use another device (e.g., GW 310) to communicate with the cloud 302. Other groups of IoT devices can include remote weather stations 314, local information terminals 316, alarm systems 318, automated teller machines 320, alarm panels 322, or mobile vehicles (e.g., emergency vehicle 324 or other vehicle 326), etc. Each of these IoT devices can communicate with other IoT devices, with the server 304, or with both.

[0063] From Figure 3 It can be seen that a large number of IoT devices can be communicating via the cloud 302. This can allow different IoT devices to autonomously request or provide information to other devices. For example, the IoT group 306 can request the current weather forecast from a group of remote weather stations 314 that can provide weather forecasts without human intervention. Additionally, the automated teller machine 320 can warn the emergency vehicle 324 that a theft is in progress. When the emergency vehicle 324 is approaching the automated teller machine 320, it can access the traffic control group 306 to request the clearing of the location, for example, by turning the lights red in enough time to stop the cross-street traffic at the intersection so that the emergency vehicle 324 can enter the intersection unobstructed.

[0064] In another example, the IoT group 306 can be an industrial control group (also known as a "connected factory", an "Industry 4.0" group, etc.), where the IoT devices in the IoT group 306 can include machines or appliances with embedded IoT devices, radio frequency identification (RFID) readers, cameras, client computer devices within a manufacturing plant, etc., to provide production control, self-optimizing or decentralized task management services, analysis services, etc. for a specific manufacturer or factory operator. In this example, the IoT group 306 can communicate with the server 304 via the GW 310 and the cloud 302 to provide the captured data, which can be used to provide performance monitoring and analysis to the manufacturer or factory operator. Additionally, the IoT devices in the IoT group 306 can communicate with each other and / or with other IoT devices of other IoT groups to make their own judgments and execute their tasks as autonomously as possible.

[0065] A cluster of IoT devices (e.g., Figure 3 the depicted IoT group) can be equipped to communicate with other IoT devices as well as with the cloud 302. This can allow IoT devices to form an ad-hoc network among the devices, thus allowing them to work as a single device that can be referred to as a fog device or a fog system. This refers to Figure 4Further discussion.

[0066] Figure 4 Shows an arrangement 400 of a cloud computing network or cloud 302 that communicates with a Mesh network of IoT devices (which may be referred to as fog devices 402) operating at the edge of cloud 302. Items with the same number are as described with respect to Figures 1 - 3 In this example, the fog devices 402 are a group of IoT devices at an intersection. The fog devices 402 can be established according to specifications issued by the OpenFog Consortium (OFC), Open Connectivity Foundation TM (OCF), etc.

[0067] Data can be captured, stored / recorded, and transferred between IoT devices 404. Analysis of traffic flow and control schemes can be implemented by an aggregator 406, which communicates with IoT devices 404 and with each other via the Mesh network. Data can be uploaded to cloud 302 via GW 310 and commands can be received from cloud 302. GW 310 communicates with IoT devices 404 and aggregator 406 via the Mesh network. Similarly, in an embodiment, one or more of IoT devices 404, aggregator 406, etc. can be combined with the modem technology specifically referred to herein Figures 1 - 3 In a similar manner, in an embodiment, one or more of IoT devices 404, aggregator 406, etc. can be combined with the modem technology specifically referred to herein Figures 5 - 9 described.

[0068] Any number of communication links can be used in fog devices 402. For example, shorter distance links 408 compatible with IEEE 802.15.4 can provide local communication between IoT devices that are close to each other or to other devices. For example, longer distance links 410 compatible with LPWA standards can provide communication between IoT devices and GW 310. For simplicity of illustration, each communication link 408 or 410 is not labeled with a reference number.

[0069] The fog devices 402 can be regarded as a large-scale interconnected network, where multiple IoT devices communicate with each other, for example, via communication links 408 and 410. The network can be established using the Open Interconnect Consortium (OIC) standard specification 1.0 issued by the Open Connectivity Foundation TM (OCF) on December 23, 2015. This standard allows devices to discover each other and establish communication for interconnection. Other interconnection protocols can also be used, including, for example, the AllJoyn protocol from the AllSeen Alliance, the Optimized Link State Routing (OLSR) protocol, or the Better Approach to Mobile Ad-hoc Networking (B.A.T.M.A.N), etc.

[0070] Communication from any IoT device can be routed along the most convenient path between any IoT devices to reach the GW 310. In these networks, the number of interconnections can provide significant redundancy, allowing communication to be maintained even in the event of the loss of multiple IoT devices.

[0071] Not all IoT devices can be permanent members of the fog device 402. In the example in drawing 400, three transient IoT devices (the first mobile device 412, the second mobile device 414, and the third mobile device 416) have joined the fog device 402. The fog device 402 can present itself as a single device located at the edge of the cloud 302 to a client (e.g., the server 304) in the cloud 302. In this example, control communication for a particular resource within the fog device 402 can occur without identifying any particular IoT device 404 within the fog device 402. Thus, if any IoT device 404 fails, other IoT devices 404 can be able to discover and control the resource. For example, the IoT devices 404 can be wired to allow any one of the IoT devices 404 to control measurements, inputs, outputs, etc. for the other IoT devices 404. The aggregator 406 can also provide redundancy in terms of the control of the IoT devices 404 and other functions of the fog device 402.

[0072] In some examples, an imperative programming style can be used to configure IoT devices, e.g., each IoT device has a specific function and communication partners. However, the IoT devices that form the fog device 402 can be configured in a declarative programming style, allowing the IoT devices to reconfigure their operations and communications in response to conditions, queries, and device failures to, for example, determine the resources required. This can be performed when transient IoT devices (e.g., devices 412, 414, 416) join the fog device 402. As transient or mobile IoT devices enter or leave the fog 402, the fog device 402 can reconfigure itself to include those devices. This can be performed by forming a temporary group of devices 412, 414, and the third mobile device 416 to control or communicate with the IoT devices 404. If one or both of the devices 412, 414 are autonomous, the temporary group can provide instructions to the devices 412, 414. As the transient devices 412, 414, and 416 move away from the vicinity of the fog device 402, it can reconfigure itself to eliminate those IoT devices from the network. The fog device 402 can also divide itself into functional units (e.g., IoT devices 404 and other IoT devices proximate to a particular area or geographical feature, or other IoT devices that perform a particular function). This type of combination can enable the formation of larger IoT constructs using resources from the fog device 402.

[0073] As shown in fog device 402, the organic evolution of the IoT network is centered around maximizing the utility, availability, and resilience of IoT implementation methods. Additionally, the example indicates the usefulness of strategies for improving trust and thus security. The local identity of a device can be important in an implementation because the decentralization of identity ensures that a central authority cannot be exploited to allow impersonation of objects that may exist within the IoT network. Additionally, local identity reduces communication overhead and latency.

[0074] Figure 5 Illustrates arrangement 50 according to various embodiments. Items with the same number are as described with respect to Figures 1 - 4 In Figure 5 , arrangement 50 may include cloud 302, IoT devices 504-1 through 504-N (collectively referred to as "IoT devices 504", etc.), server 304, client computer device 560 (also referred to as "client" 560"), hub 510, and trays 500-1 through 500-N (collectively referred to as "trays 500", "multiple trays 500", etc.). Arrangement 50 may include many more devices, components, or other elements than Figure 5 shown, and thus, Figure 5 the depiction of arrangement 50 in

[0075] Each IoT device 504 may be a physical hardware device capable of sequentially and automatically performing a sequence of arithmetic or logical operations, recording and storing digital data, and / or transmitting digital data via a wired or wireless connection to one or more network elements and / or one or more other devices. In an embodiment, IoT device 504 may be an IoT device that is the same as or similar to the previously discussed IoT devices (e.g., IoT devices 104, 304, 404). In other embodiments, IoT device 504 may be a computer device embedded within a computer system, or IoT device 504 may be some other type of computer device.

[0076] IoT device 504 may include event capture circuitry capable of capturing and / or recording data associated with an event with little or no user intervention ( Figure 5(not shown). The event capture circuit may include one or more sensors, processors, memory devices, and / or other similar components configured to sense / detect an event and generate and record / store data associated with the sensed / detected event. An event can be any occurrence of an action, such as a change in a meter / sensor / gauger reading, detected motion, electrical output and / or electrical input, receipt or transmission of one or more messages to / from other devices, biological actions (e.g., heart rate, glucose level, etc.), state / position / orientation change, a change in the operating mode of the IoT device 504, etc. In some embodiments, the IoT device 504 may be associated with a remote or detached accessory IoT device (also referred to as an “accessory device”, “auxiliary device”, “auxiliary IoT device”, etc.), and the event may be captured by the accessory device. In one example, the accessory device may be a remote temperature sensor that measures / captures relative temperature, which may capture a specific temperature as an event and report the event to the paired IoT device 504. In another example, the IoT device 504 may be a camera, and the accessory device may be a paired motion sensor, where when the accessory device detects motion, it may trigger an action on the camera IoT device 504.

[0077] A service provider (e.g., the operator of the server 304), a user of the client 560, or the client 560 itself, and the IoT device 504 may take appropriate actions based on the notification of the event. In various embodiments, the event capture circuit may detect, capture, and record / store an event based on sensor input and / or output, timer values, user actions, etc. Once the event capture circuit captures and stores / records data associated with the event, the event capture circuit may notify the service provider (e.g., the operator of the server 304) and / or the client 560 of the event by providing the captured data (or a message containing the captured data) to the carriage 500 to which it is attached via the interconnect 506. This type of data may be considered synonymous with and may sometimes be referred to hereinafter as “IoT data”, “sensor data”, “user data”, “data plane data”, etc.

[0078] In addition, each IoT device 504 can generate hardware status data (HSD) and provide the hardware status data (HSD) to the carriage 500 to which it is attached via the interconnect 506. The HSD can be any data that describes the overall operation state or operation mode of the entire IoT device 504, the various hardware components / devices within the IoT device 504, or the execution or runtime environment of the software components for executing the IoT device 504. In an embodiment, the HSD can indicate the operation state or operation mode of one or more resources provided by the IoT device 504. For example, the various capabilities of each IoT device 504 can be organized as a set of resources, and each resource can monitor, manage, and / or control a part of the hardware platform or virtualization platform, physical or virtual components within the computing environment, and / or physical or virtual components within a specific device. These resources can include information about or access to: the entire IoT device 504, mechanical devices attached to or embedded in the IoT device 504, sensors attached to or embedded in the IoT device 504, memory space, processor / CPU time, processor / CPU usage, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, etc. The HSD can be considered synonymous with and may sometimes be referred to hereinafter as "hardware status information" or "HSI", "control data", "capability information" or "capability data", "control plane data", etc.

[0079] The process by which the IoT device 504 captures, records, and sends IoT data and HSD can be referred to as "reporting". During operation, the IoT device 504 can report IoT data and / or HSD to the attached carriage 500 periodically or cyclically and / or in response to a trigger identified by the IoT device 504 (e.g., upon receiving a request, in response to an internal or external event, etc.). The trigger and / or reporting period / cycle can be configured by the carriage 500 and / or the hub 510. In various embodiments, other processes for the carriage 500 to report data can be used.

[0080] Each carriage 500 can be a substrate, dock, docking station, etc., to which one or more IoT devices 504 can be connected using the corresponding interconnect 506. In some embodiments, the carriage 500 can be referred to as a "sensor carriage", "IoT device carriage", "IoT carriage", etc. Each carriage 500 can provide the necessary infrastructure for the attached IoT devices 504 to transfer data and control commands / instructions and actuate electromechanical devices. Although Figure 5 only each carriage 500 attached or coupled to a single IoT device 504 is shown, in various embodiments, each carriage 500 can be attached or coupled to multiple IoT devices 504. As shown, each carriage includes an interconnect 506 and a communication circuit 505 (refer to Figures 6 - 7Discuss these components in more detail).

[0081] In an embodiment, the interconnect 506 may include a wired connection between one or more IoT devices 504 and the cradle 500, a wireless radio link between one or more IoT devices 504 and the cradle 500, or input / output (I / O) pins between the IoT device 504 and the cradle 500. In various embodiments, the cradle 500 may implement an interface abstraction layer 639 to send and receive data to / from the attached IoT device 504 via the interconnect 506. Additionally, the cradle 500 may implement one or more collection entities including a data plane entity (DP) 637 and a control plane entity (CP) 638, which may be used to send / receive data to / from the attached IoT device 504 via the IAL 639 and the interconnect 506 and send / receive the data collected from the attached IoT device 504 to / from other cradles 500 and the hub 510. Additionally, to simplify the drawings, only the cradle 500-N is shown as including the collection entities 637-638 and the IAL 639; however, it should be understood that all cradles 500 may include the same or similar entities / layers as the cradle 500-N. More details about Figure 6 the collection entities 637-638 and the IAL 639 are discussed below.

[0082] The communication circuit 505 may include one or more hardware devices / components (e.g., transceivers, modems, antenna elements, etc.) that allow the cradle 500 to communicate (e.g., send and receive) with other devices (e.g., other cradles 500 and the hub 510). According to various embodiments, the communication circuit 505 may be a configurable device (e.g., a field programmable device (FPD), etc.) that can be loaded or provisioned with a modem configuration file that allows the communication circuit 505 to perform communication in a corresponding network.

[0083] For example, the cradle 500 may be equipped with a cradle profile 675 (see, for example Figure 6 ), which when loaded or provisioned in the configurable modem 640 of the communication circuit 505 (see, for example Figure 6 ), may enable the cradle 500 to communicate via the respective cradle links 508 over the cradle network. In an embodiment, the cradle network may be a Mesh network or a fog computing system / network, and the cradle links 508 may be short-range radio links. The short-range radio links may be established and maintained according to various wireless communication protocols discussed herein.

[0084] In another example, the cradle 500 may be equipped with a hub profile 677 (see, for example Figure 6 ), which when loaded or provisioned in the configurable modem 640 of the communication circuit 505 (see, for exampleFigure 6 ) When it is, it can enable the carriage 500 to communicate with the hub 510 via each hub link 511 through the hub network. In an embodiment, the hub network can be a wireless local area network (WLAN) (e.g., a WiFi infrastructure or an ad-hoc network), a cellular network, or some other network discussed herein; and the hub link 511 can be a long-range radio link established and maintained according to the implemented WLAN or cellular communication protocol. In some embodiments, the hub link 511 can be a short-range radio link similar to the carriage link 508. In these embodiments, the hub link 511 can operate according to a different short-range communication protocol than that used for the carriage link 508, or the hub link 511 can operate according to the same short-range communication protocol as the carriage link 508 but use a different frequency band, use a closed subscriber group (CSG) list including the hub 510, or some other mechanism to distinguish the hub network from the carriage network.

[0085] The hub 510 (also referred to as a "sensor hub", "IoT device hub", "IoT hub", etc.) can be a network element that employs multi-radio frequency network technology to provide communication services to IoT devices 504 and / or the carriage 500 in a given environment 50. In this regard, the hub 510 can act as a centralized hub and / or scheduler for IoT devices 504 and / or the carriage 500. The hub 510 can also relay data to / from the server 304 and / or the client 560 via the cloud 302 on behalf of the IoT devices 504 and / or the carriage 500. In this way, the hub 510 can act as a single point of contact between devices that cannot directly connect to a larger network (e.g., the cloud 302) and remote computer devices (e.g., the server 304 and the client 560).

[0086] The hub 510 can be the same as or similar to the previously discussed GWs 120, 126, and 130, 204, and 310. In some embodiments, the hub 510 can be a stand-alone device (e.g., an IoT GW, an automation hub, a "smart" building hub, etc.) specifically manufactured to provide connectivity for the carriage 500 and / or IoT devices 504 to the cloud 302. In these embodiments, the hub 510 can be associated with elements in the arrangement 50 ( Figure 5A wireless access point (WAP) or other similar device (not shown) for network connectivity is communicatively coupled. Additionally, in these embodiments, the hub 510 can be communicatively coupled to the WAP via a wired or wireless connection. In other embodiments, the hub 510 can be a WAP, a home server coupled to an RF communication circuit, a small cell base station (e.g., femtocell, picocell, home evolved Node B (HeNB), etc.), a router, a switch, a wireless beacon, and / or any other similar network element.

[0087] To perform these functions, the hub 510 can include one or more processors, a communication circuit 705 (e.g., including a network interface, one or more transmitters / receivers connected to one or more antennas, etc.), and a computer-readable medium. The communication circuit 705 can be the same as or similar to the communication circuit 505 discussed previously. Additionally, the hub 510 can implement a data collection entity that is the same as or similar to the carriage 500 to send / receive HSD and IoT data. In an embodiment, one or more transmitters / receivers of the communication circuit 705 can be configured to wirelessly send / receive RF signals to / from one or more carriages 500 / IoT devices 504 within the environment 50, and the network interface of the communication circuit 705 can be configured to send / receive data to / from the server 304 via the cloud 302 using a wired or wireless connection 517. The hub 510 can process and / or route data packets via the wired / wireless connection 517 according to one or more communication protocols discussed herein.

[0088] In an embodiment, the hub 510 can provide a single hardware and software stack such that all information from the connected IoT devices 504 can be shared among them. The processor circuit of the hub 510 can operate a suitable operating system (OS) (e.g., a hub operating system (hOS) that provides the user (e.g., the client 560) with the ability to manage the hub 510 platform). By using the hOS, the client 560 can configure different applications or services to utilize those IoT devices 504 even when multiple IoT devices 504 are originally incompatible with each other, for example, because they are provided by different manufacturers, vendors, service providers, etc. To this end, the hOS can host a single application or a panel graphical user interface (GUI) (collectively referred to as an "app") that provides the ability to define one or more configurations for the IoT devices 504 in the environment 50 when operated by a user of the client 560. The configuration can define the operations of the various IoT devices 504 to obtain a specific service and define various policies for controlling and accessing those IoT devices 504. Based on the defined configuration, the hub 510 can generate an appropriate device-specific configuration 635 (see Figure 6) and then can be allocated or provided to the carriage 500. The hub 510 along with the application can act as a standard platform for developers, MFG, suppliers, service providers, etc. to build plugins or channels for each IoT device 504 they develop. In this way, users can access and control all IoT devices 504 without having to go through different cloud computing services and / or use separate applications for each function or service.

[0089] Still referring to Figure 5 , the server 304 can include one or more hardware computer devices and / or network elements for providing one or more services to the client 560. These services can utilize the data captured and reported by the IoT devices 504. The server 304 can obtain event-based data from the IoT devices 504, analyze the event-based data, and can be capable of generating content (e.g., text, graphics, audio, and / or video) that can be transmitted to the client 560 via a web server (not shown) that can process requests and responses (e.g., requests for information / content and the information / content provided in response thereto). In various embodiments, the server 304 can operate to provide analysis and / or various services to a user / consumer (e.g., the client 560) for the ability to use the previously discussed app to log in and manage an array of IoT devices 504. In an embodiment, the operator of the server 304 can develop and deploy an app that can be hosted by the hub 510. In other embodiments, the server 304 can host the app and can generate appropriate device-specific configurations and push them to the hub 510 for dissemination to the respective carriages 500. In either embodiment, the hub 510 or the server 304 can host the app by operating one or more server-side applications that generate and provide responses to requests obtained from the client 560. Server-side applications (whether operated by the hub 510 or the server 304) can be developed using any suitable server-side scripting or programming language (e.g., Active Server Pages (ASP), ASP.NET, Java, JavaServer Pages (JSP), node.js, Ruby, PHP, Python, etc.). Other languages or development tools (e.g., proprietary scripting languages) can also be used.

[0090] The server 304 may include a suitable OS and may include a computer-readable medium storing instructions. The OS may provide executable program instructions for the general management and operation of the server. The instructions, when executed by the processor of the server, may allow the server to perform its intended functions. Suitable implementations for the OS and general functions of the server are known or commercially available and can be readily implemented by a person of ordinary skill in the art. Additionally, the server 304 may include a single physical hardware device or may be physically or logically connected to other network devices such that the server 304 may be located on one or more physical hardware devices. Additionally, the server 304 may be connected to or associated with one or more data storage devices (not shown).

[0091] The client 560 may be a physical hardware device capable of running one or more applications (e.g., the apps discussed previously). The client 560 may include a transmitter / receiver (or alternatively, a transceiver or RF circuit), a memory, one or more processors, one or more sensors (e.g., accelerometers, gyroscopes, image sensors, Global Positioning System (“GPS”) receivers, etc.) and / or other similar components. The client 560 may transmit (send / receive) data with one or more IoT devices 504 via the cloud 302 and / or the hub 510 and transmit data with the server 304 via the cloud 302. The client 560 may communicate with each device in the arrangement 50 according to one or more of the wireless or wired communication protocols discussed herein. The client 560 may communicate with one or more IoT devices 404 and IoT devices 504 according to one or more of the wireless communication protocols discussed herein. The client 560 may be a desktop personal computer (PC), a laptop PC, a wireless cellular phone or smartphone, a tablet, a wearable computing device, a handheld messaging device, a personal digital assistant, an e-book reader, an augmented reality head-mounted (or helmet-mounted) display device, and / or any other physical or logical device capable of recording, storing, and / or transmitting digital data.

[0092] The client 560 may implement an app to define policies and / or configurations for accessing and / or managing desired services and subscriptions / purchases and accessing / managing the IoT devices 504. The app may be executed within an application container or a web browser of the client 560. In this regard, the app may execute programs / scripts and may render markup language documents (e.g., HTML, Extensible Markup Language (XML), JavaScript Object Notation (JSON), etc.) and other content. It may be through client-side scripting languages / programming languages (e.g., HTML, Cascading Style Sheets (CSS), JavaScript, ActionScript, Ruby, Python, etc.) and / or by using platform-specific development tools (e.g., Visual Studio TM Integrated Development Environment (IDE), software development kit (SDK), etc.) to write programs / scripts executed in an application container or a web browser. Other languages or development tools (e.g., proprietary scripting languages) can also be used. The app can be platform-specific, such as when implemented in a mobile device (e.g., smartphone, tablet computer, etc.) as the client 560. The term "platform-specific" can refer to the platform on which the client 560 is implemented and / or the platform on which the server 304 is implemented.

[0093] Using the app, the user can define configurations by selecting operations of the IoT devices 504 for various services. The app can include a user interface that allows the user to define configurations for using the IoT devices 504. For example, the app can present a graphical user interface (GUI) including one or more graphical control elements (GCEs) corresponding to various functions / services or operations of the IoT device 504 in the application container or browser implemented by the client 560. The GCEs can enable the user to select desired functions / services, IoT device operations, preferences, rules / policies, etc. to define the respective configurations 735 (see Figure 7 ). In some embodiments, the specific functions / services, IoT device operations, preferences, rules / policies, etc. that the user can select / define can be restricted or extended according to MFG / vendor / service provider policies, subscription plans, and / or purchase and / or other similar criteria.

[0094] In response to the selection of one or more GCEs, the app can generate respective configurations (CFGs) 735 and CFG messages for including the CFGs 735. Details of the content and functions of the CFGs 735 are discussed below with respect to Figure 7 . The CFG message can indicate that a new bracket-specific CFG 635 is to be generated and allocated based on the CFG 735 included in the CFG message and / or an existing bracket-specific CFG 635 stored in the bracket 500 is to be updated. Additionally or alternatively, the CFG message can indicate that an existing CFG 635 stored in the bracket 500 is to be deleted based on the CFG 735 included in the CFG message and replaced with the deleted CFG 635.

[0095] In response to generating a CFG message, the app may send the CFG message to a host (e.g., hub 510 or server 304). In an embodiment, the app may use a web-based service (e.g., Representational State Transfer (REST) web service, Constrained Application Protocol (CoAP), Simple Object Access Protocol (SOAP) web service, Really Simple Syndication (RSS) service, Message Queuing Telemetry Transport (MQTT) service, and / or any other suitable messaging service) to directly and / or via cloud 302 deliver the CFG message to the host. Based on the defined configuration, hub 510 (or server 304) may generate an appropriate device-specific configuration and update it on carriage 500. In one example, the CFG message may be an HTTP request message (e.g., POST, PUT, etc.), where the body portion of these messages may include CFG 735. In this example, hub 510 may provide an HTTP response message to confirm or acknowledge receipt of the CFG message, or indicate failure by a reason for failure (e.g., using a suitable HTTP status code). Other message types may be used to convey CFG 735 and receive a response thereto, such as any Internet Protocol (IP) message known and / or discussed herein, or a message of a proprietary protocol, where CFG 735 may be located in the header or body portion of these messages.

[0096] According to various embodiments, the elements of arrangement 50 may operate as follows.

[0097] (A) The bracket 500 and the hub 510 can be installed at various locations in a building. In one example, the bracket 500 and the hub 510 can be located in a section of the building (e.g., a single room in the building, the ground floor of a multi-story building, etc.), where each section of the building includes a corresponding system of IoT devices 504, the bracket 500, and the hub 510 that all operate in the same or a similar manner as previously discussed. In some implementations, the devices in each section of the building can be part of an integrated intelligent building system, where each hub 510 communicates with a central GW device (e.g., a server stack, a small cell base station, and / or any other similar network element) that provides access to a larger network (e.g., a corporate network, the Internet, etc.). The installation of these devices can occur during the construction of the building, or the bracket 500 and the hub 510 can be installed in an existing building. In some embodiments, one or more booster devices can also be installed in a section of the building. The booster device can be a computing device configured to obtain and rebroadcast the signals provided by one or more of the brackets 500 and / or hubs 510, and can include a wireless repeater, a WiFi range extender, a WAP, or other similar devices. In some implementations, the booster device can utilize power line communication (PLC) or power line networking (PLN) to obtain or rebroadcast the signals.

[0098] (B) After the bracket 500 and the hub 510 are installed in the building, a bracket installation / boot process can be performed (see, for example Figure 9 process 900). In an embodiment, when the bracket is empty (e.g., when there are no connected / attached IoT devices 504), the bracket installation / boot process is performed. Additionally, during the bracket installation / boot process, the bracket 500 can receive a routing information base (RIB) 636 from the hub 510 (see, for example Figure 6 ). The RIB 636 can indicate the routes for sending IoT data and HSD to the respective IoT brackets 500 and hubs 510. The RIB 636 is discussed in more detail below with respect to Figure 6 .

[0099] (C) One or more IoT devices 504 are connected to the bracket 500. The IoT devices 504 can be connected to the bracket 500 at any time after the installation process. For example, a first group of IoT devices 504 can be connected to the bracket 500 right after the bracket / hub installation, and a second group of IoT devices 504 can be connected to the bracket 500 one month after the bracket / hub installation and after the first group of IoT devices 504 becomes operational. Additionally, a previously connected IoT device 504 can be disconnected and replaced with, for example, an updated or improved version of the IoT device 504. When a new IoT device 504 is connected to the bracket 500, an IoT device startup process can be executed (see, for example Figure 10 for process 1000).

[0100] (D) After executing the sensor startup process, the bracket 500 can start transmitting IoT data and HSD to the attached IoT devices 504 via the interconnect 506. The bracket 500 can transmit HSD and / or IoT data between them via the respective bracket links 508 over the bracket network, and / or transmit HSD and / or IoT data to / from the hub 510 via the respective hub links 511 over the hub network. The transmission of HSD / IoT data can be completed according to one or more policies / configurations allocated in the bracket 500 by the hub 510 during the sensor startup process and using the RIB 636.

[0101] (D.1) When the bracket 500 obtains HSD and / or IoT data from another bracket 500 or from the hub 510, the bracket 500 can provide the HSD or IoT data to one or more attached IoT devices 504 that can be used to provide one or more services / functions.

[0102] For example, the IoT device 504-1 can be a motion sensor provided by a security monitoring service, the IoT device 504-2 can be a smart thermostat (including one or more temperature sensors) provided by a temperature control device manufacturer, and the IoT device 504-3 can be an electromechanical component (EMC) that opens / closes a window developed by an enthusiast using a computing board (e.g., Arduino board, Raspberry Pi, etc.). In this example, the user can use an app to define a temperature control configuration for using all three IoT devices 504 for a temperature control service, and define a home security configuration for using only the IoT devices 504-1 and 504-3 for a home security service.

[0103] Accordingly, the bracket 500-1 can control the communication circuit 505 to provide the collected IoT data indicating that a person is in the building to the brackets 500-2 and 500-3 via the bracket network for temperature control services, so that, for example, a desired temperature can be maintained in the building (e.g., by commanding the IoT device 504-3 to turn off or keep the window closed and commanding the IoT device 504-2 to turn on the air conditioning unit). In this case, the bracket 500-1 can perform a lookup operation on its locally stored RIB 636 to determine the optimal route for sending the IoT data to each of the brackets 500-2 and 500-3.

[0104] In addition, the control plane entity 638 of the bracket 500-3 can control the communication circuit 505 to provide the collected HSD indicating the state of the EMC to the bracket 500-2 for temperature control services, so that a desired temperature can be maintained in the building. In this case, the bracket 500-3 can perform a lookup operation on its locally stored RIB 636 to determine the optimal route for sending the HSD to the bracket 500-2. Once received, the hub 510 can provide the HSD or some other indication to the IoT device 504-2 via the interconnect 506 to take the desired action (e.g., turn off the air conditioning unit to conserve energy when the HSD indicates that the window has been manually opened, etc.).

[0105] In addition, the bracket 500-3 can control the communication circuit 505 to provide the collected HSD indicating the state of the EMC to the hub 510 for home security services. Once received, the hub 510 can provide the HSD or some other indication (e.g., a break-in alert when the HSD indicates that the window has been pried open or damaged) to the security monitoring service via the cloud 302. In this case, the bracket 500-3 can perform a lookup operation on its locally stored RIB 636 to determine the optimal route for sending the HSD to the hub 510.

[0106] (D.2) When the hub 510 obtains the HSD and / or IoT data from the bracket 500, the hub 510 can directly pass the HSD and / or IoT data to other brackets 500 in the arrangement 50 or other hubs 510 in other sections of the building ( Figure 5(not shown). The HSD / IoT data can be sent to the cradle 500 in the arrangement 50 in the same or similar manner as previously discussed in D.1, except that the data can be transmitted through a hub network instead of a cradle network. The HSD / IoT data can be sent to other hubs 510 in other sections of the building through the previously discussed hub network or through another hub network different from the hub network in the arrangement 50. In addition, the hub 510 can transmit IoT data / HSD to the client 560 and / or the server 304 via the cloud 302. To send data via the cloud 302, the hub 510 can encapsulate and / or envelope the HSD / IoT data according to a wired or wireless communication protocol, and send the encapsulated data through the channel 517. The channel 517 can be used to transmit data through a suitable wired or wireless network (e.g., the networks discussed herein), and the wired / wireless communication protocol of the channel 517 can be different from the protocol used for the hub network and / or the cradle network. The encapsulated / enveloped data can ultimately be provided to the server 304 and / or the client 560 via the cloud 302.

[0107] Figure 6 Components showing an example implementation of the cradle 500 according to various embodiments. Figure 6 A block diagram showing examples of components that can be present in the cradle 500. The cradle 500 can include any combination of the components shown in the example. The components can be implemented as applicable ICs in the cradle 500, parts thereof, discrete electronic devices or other modules, logic, hardware, software, firmware, or a combination thereof, or as components incorporated within a rack of a larger system. Figure 6 The block diagram is intended to show a high-level view of the components of the cradle 500. However, in other implementations, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur.

[0108] The cradle 500 can include a processor 602, which can be a microprocessor, multi-core processor, multi-threaded processor, ultra-low voltage processor, embedded processor, or other known processing element. The processor 602 can be part of a system-on-chip (SoC), where the processor 602 and other components are formed as a single integrated circuit or a single package (e.g., the Edison TM or Galileo TM SoC board) from Intel. As an example, the processor 602 can include a processor based on the architecture core available from a company in Santa Clara, California Architecture Core TM (e.g., Quark TM or Atom TM, i3, i5, i7, or an MCU-class processor) or another such processor. However, any number of other processors may be used (e.g., processors available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, California, MIPS-based designs from MIPS Technologies, Inc. of Sunnyvale, California, ARM-based designs licensed from ARM Holdings, Ltd., or its customers, or its licensees or adopters). The processor may include, for example, A5-A9 processors from Inc., Snapdragon from Technologies Inc., TM processors, or OMAP TM processors from Texas Instruments, Inc.

[0109] Processor 602 may communicate with system memory 604 via bus 606. Any number of memory devices may be used to provide a given amount of system storage. By way of example, the memory may be a random access memory (RAM) according to a Joint Electron Device Engineering Council (JEDEC) low power double data rate (LPDDR)-based design (e.g., the current LPDDR2 standard according to JEDEC JESD209-2E (published in April 2009) or a next generation LPDDR standard (e.g., LPDDR3 or LPDDR4, which will provide an extension to LPDDR2 to increase bandwidth)). In various implementations, each memory device may be any number of different package types (e.g., single die package (SDP), dual die package (DDP), or quad die package (Q17P)). In some embodiments, these devices may be soldered directly to the motherboard to provide a lower profile solution, while in other embodiments, these devices are configured as one or more memory modules, which in turn are coupled to the motherboard by a given connector. Any number of other memory implementations may be used (e.g., other types of memory modules (e.g., different kinds of dual in-line memory modules (DIMMs), including but not limited to microDIMM or MiniDIMM)). For example, the memory may be sized between 2 GB and 16 GB and may be configured as a DDR3LM package or LPDDR2 or LPDDR3 memory, which is soldered to the motherboard via a ball grid array (BGA).

[0110] To provide permanent storage of information (e.g., data, applications, operating systems, etc.), a mass storage device 608 can also be coupled to the processor 602 via the bus 606. To enable thinner and lighter system designs, the mass storage device 608 can be implemented via a solid state disk drive (SSDD). Other devices that can be used for the mass storage device 608 include flash memory cards (e.g., SD cards, microSD cards, xD picture cards, etc.) and USB flash drives. In a low power implementation, the mass storage device 608 can be on-die memory or registers associated with the processor 602. However, in some examples, a micro hard disk drive (HDD) can be used to implement the mass storage device 608. Additionally, in addition to or instead of the technologies described, any number of new technologies (e.g., resistive random access memory, phase change memory, holographic memory, or chemical memory, etc.) can be used for the mass storage device 608. For example, the carrier 500 can include three-dimensional cross-point (“3D XPOINT”) memory from and . In an embodiment, the memory 604 and / or the storage device 608 can be partitioned into one or more trusted memory regions for storing applications or software modules for a secure or trusted execution environment. In some embodiments, the secure / trusted execution environment can include one or more secure enclaves defined using SGX instructions, which are discussed in the commonly assigned and incorporated by reference International Application No. PCT / US2016 / 037634 and the commonly assigned and incorporated by reference U.S. Application No. 15 / 473,370. In some embodiments, the secure / trusted execution environment can include a management engine (ME) circuit, which can be an isolated and tamper-resistant chipset that is different from and generally operates independently of the processor 602. A detailed discussion of various ME circuit implementations is detailed in the commonly assigned and incorporated by reference International Application No. PCT / US2016 / 037634 and the commonly assigned and incorporated by reference U.S. Application No. 15 / 473,370. Additionally or alternatively, the secure / trusted execution environment can include a universal integrated circuit card (UICC), an embedded UICC (eUICC), or a smart card (not shown) of the carrier 500.

[0111] The mass storage device 608 may include multiple modules to implement the group creation functionality and / or Mesh networking / fog computing functionality described herein. Although shown as code blocks in the mass storage device 608, it can be understood that any module can be replaced with hard-wired circuitry, such as being built into a programmable device (e.g., ASIC, SoC, field programmable device (FPD), etc.). The FPD may include an FPGA or a hardware accelerator; a programmable logic device (PLD) (e.g., complex PLD (CPLD), high-capacity PLD (HCPLD), etc.); a structured ASIC, etc.; a programmable SoC (PSoC); and / or other similar devices. In an embodiment where the carriage 500 includes a hardware accelerator (e.g., an FPGA tile) and a processor core, the hardware accelerator (e.g., an FPGA tile) may be pre-configured with logic (e.g., an appropriate bitstream, logic blocks / structures, etc.) to perform some of the functions of the various modules shown in the storage device 608 (instead of using programming instructions to be executed by the processor core of the processor 602). This may include, for example, (FPGA-based) DP 637, (FPGA-based) CP 638, (FPGA-based) IAL 639, (FPGA-based) IoT device launcher 1001, (FPGA-based) modem manager 634, etc.

[0112] The mass storage device 608 may include a list of sub-objects 630 of atomic and composite objects that can be used to form group objects (e.g., the IoT group 306 discussed previously). The collection group identifier 632 may use the list of sub-objects 630 to generate a group ID, such as by using a hash formula on the list of sub-objects

[0113] 630. The mass storage device 608 may also include a modem manager

[0114] 634, a routing information base (RIB) 636, a data plane entity (DP) 637, a control plane entity (CP) 638, an interface abstraction layer (IAL) 639, a configuration (CFG) 636, and a protocol stack 800, an IoT device launcher 1001. In some embodiments, one or more of the foregoing modules may be implemented in a secure / trusted execution environment in the same or similar manner as discussed in co-owned and incorporated-by-reference International Application No. PCT / US2016 / 037634 and U.S. Patent Application No. 15 / 473,370.

[0115] The Modem Manager 634 may configure the communication circuitry 505 to communicate using different wireless protocols. This may include: detecting a trigger to reconfigure the communication circuitry 505; selecting a Modem Profile (MP) in response to the trigger; (re)configuring the communication circuitry 505 according to the selected MP; etc. As shown, the Modem Manager 634 includes a Dock Profile 675 and a Hub Profile 677. The Dock Profile 675 may be an MP for configuring the communication circuitry 505 to communicate over a dock network, while the Hub Profile 677 may be an MP for configuring the communication circuitry 505 to communicate over a hub network.

[0116] Each MP may define the digital signal flow through the digital circuitry and the logical operations performed on those signals. The digital signal flow and logical operations may be defined by or based on one or more protocol / network stacks or other similar implementations of a computer networking protocol suite and / or a wireless communication protocol (e.g., the protocols discussed herein). In some embodiments, the MP may be or include a Network Access Profile (NAP), which when enabled may allow the dock 500 to access a particular service provided by a particular network infrastructure or service provider of a network. A detailed description of NAP elements, allocation, operations, etc. (including communication between two or more NAPs and between a NAP and a remote device) is discussed in commonly assigned and incorporated by reference International Application No. PCT / US2016 / 037634 and U.S. Application No. 15 / 473,370. In embodiments where the modem 640 is implemented as an FPD, the MP may be configured or defined using a Hardware Description Language (HDL) (e.g., Register Transfer Logic (RTL), Very High Speed Integrated Circuit (VHSIC) HDL (VHDL), Verilog, etc.). In embodiments, the MP may be obtained from the server 304 or the hub 510 and locally stored in the storage device 608 (or a secure storage area of the storage device 608).

[0117] The MP may be used to dynamically configure the communication circuitry 505 (or components thereof). For example, the Modem Manager 634 may allocate the Dock Profile 675 to the communication circuitry 505 (or components thereof), which when enabled by the communication circuitry 505 (or components thereof), may allow the communication circuitry 505 to process digital signals of IoT data for transmission to other docks 500, or process signals received from other docks 500 for providing to other components of the dock 500 or the attached IoT device 504.

[0118] The modem manager 634 can select an MP based on one or more configurations, which can be device-specific or bay-specific. The configuration 635 can define a set of rules that govern the behavior of the bay 500, which can include one or more conditions and / or criteria that actions are subject to. For example, the configuration 635 can define one or more triggers (or events) to prompt the selection of a particular MP based on the type of data collected from one or more attached IoT devices 504. In another example, the configuration 635 can define one or more triggers (or events) to prompt the selection of an MP based on the intended destination of the collected data and the optimal route depicted by the RIB 636. In another example, the configuration 635 can define actions to be taken when a fault occurs. Here, a fault can include such situations as: an MP is not correctly or cannot be allocated in the communication circuit 505; a message indicating an error / fault is received from another component or an attached IoT device 504; when a radio link failure (RLF) is detected as indicated by the communication circuit 505; when a subscription needs to be renewed, or the allocated credit for accessing a service drops below a threshold; when a threshold quality of service (QoS) level drops below a threshold; when a data rate or bandwidth allocation (e.g., assigned to the bay by a network element, or defined by a data plane or network subscription) drops below a threshold; when a service provider is unreachable; etc.

[0119] The RIB 636 can indicate routes for sending IoT data and HSD to the respective bays 500, hubs 510, and / or other environments (e.g., in another section of a building, etc.) of bays and hubs. In an embodiment, a collection entity can perform a lookup operation on the RIB 636 to determine the optimal route for sending IoT data / HSD to the bay 500 and / or the hub 510. In an embodiment, the RIB 636 can be formed as one or more database objects. In Figure 6 an embodiment where the module is replaced with hardwired circuitry, the RIB 636 can be implemented as a content-addressable memory (CAM), a ternary CAM, an associative cache memory, or some other associative memory device.

[0120] The route indicated by the RIB 636 can be based on the physical distances between the carriage 500 and other carriages 500 and hubs 510, and the communication capabilities of the carriage 500 (e.g., supported communication protocols, hardware platforms including RF circuits, etc.). The RIB 636 can store the network addresses or identifiers of other carriages 500, hubs 510, and / or IoT devices 504 attached to other carriages. The network address / identifier can be an Internet Protocol (IP) address or some other unique identifier. In some embodiments, the RIB 636 can store the number of hops / nodes for data to reach the intended destination and / or the identifier of each hop / node. This can include next-hop associations, which indicate that a particular destination can be optimally reached by sending a data packet representing the address of the "next hop" or next node on the way to the intended destination to a particular carriage 500 or hub 510. The RIB 636 can store interface information, which indicates the particular interface for reaching the next hop / node. This can include the address or identifier of components within the carriage 500 and information for delivering data to the next hop / node.

[0121] In one example, the interface information can indicate the address or identifier of the communication circuit 505 or modem 640 and the address / identifier of the MP to be loaded into the modem 640 when the next node is another carriage 500 or hub 510. In another example, when the next node or the final destination is the attached IoT device 504, the interface information can indicate the address or identifier of the interface 618 and the connected port or pin through which the IoT device 504 is connected to the carriage 500. Additionally, the RIB 636 can include a Forwarding Information Base (FIB) for packet forwarding. Any suitable hashing scheme (e.g., perfect hashing function, cuckoo hashing function, jHash function, etc.) can be used to construct the RIB 636.

[0122] The Interface Abstraction Layer (IAL) 639 can be an interface that unifies the communication between various applications (e.g., the apps implemented by the previously discussed client 560) and the attached / coupled IoT devices 504. Typically, IoT device manufacturers (MFGs), suppliers, service providers, etc. provide their own interfaces that are customized for their device suites and can be independent of other IoT device interfaces provided by other MFGs, suppliers, service providers, etc. The IAL 639 can provide a single interface or a unified set of interfaces that allow users to access the IoT devices 504 attached to the cradle 500. In an embodiment, the IAL 639 can obtain instructions or data from the collection entities 637-638 and convert the instructions / data into commands, parameters, messages, control signals, etc. for accessing data from and / or controlling the IoT devices 504. For example, the IAL 639 can convert a REST message (or the information contained therein) into an Integrated Circuit Bus (I2C or I 2 C) message or signal for accessing / controlling the IoT devices 504. In other embodiments, other parameters, messages, control signals, etc. can be used to access / control the IoT devices 504, such as Small Computer System Interface (SCSI) parallel interface (SPI) signals / messages, Joint Test Action Group (JTAG) protocol signals / messages, Universal Asynchronous Receiver / Transmitter (UART) protocol signals / messages, Musical Instrument Digital Interface (MIDI) protocol signals / messages, GSM / LTE Attention (AT) commands, etc.

[0123] As previously discussed, the bracket 500 may implement one or more collection entities including the DP 637 and the CP 638. The collection entities may provide a standard data access and control interface for the attached IoT devices 504. In an embodiment, the DP 637 may obtain IoT data from the attached IoT device 504 via an Interface Abstraction Layer (IAL) 639, and may send the IoT data obtained from another bracket 500 or the hub 510 to one or more attached IoT devices 504 via the IAL 639. The IoT data obtained by the DP 637 may include measurement data generated by a specific sensor 620 and / or actuation data generated by a specific Electro-Mechanical Component (EMC) 622. In one example, if one of the sensors 620 is a temperature sensor, the DP 637 may provide access to the temperature data generated by the sensor 620. In another example, if one of the EMCs 622 is an electro-mechanical lock, the DP 637 may provide access to the status data (e.g., user 1 locked at 10:00 am on September 1, 2017, user 2 unlocked at 10:05 am on September 1, 2017) and / or location and / or orientation data (e.g., the position of the bolt / latch, the orientation of the cylinder / lock body, etc.) generated by the EMC 622 at a specific time / date.

[0124] Similarly, the CP 638 may obtain HSD from the attached IoT device 504 via the IAL 639, and may send the HSD obtained from another bracket 500 or the hub 510 to one or more attached IoT devices 504 via the IAL 639. These entities may control the communication circuit 505 to transfer IoT data and HSD to other brackets 500 and / or the hub 510. The HSD obtained by the CP 638 may include control data generated by a specific sensor 620 and / or a specific EMC 622. In one example, if one of the sensors 620 is a temperature sensor, the CP 638 may provide access to the temperature sensor itself, the components of the temperature sensor, and / or the physical connection to the temperature sensor, which may allow a user (e.g., the client 560) to ensure the proper operation of the temperature sensor. In another example, if one of the EMCs 622 is an electro-mechanical lock, the CP 638 may provide access to the electro-mechanical lock itself, such that the user may control or manipulate the lock state (e.g., engage the bolt / latch of the lock, etc.) and / or change the position and / or orientation of one or more components of the electro-mechanical lock (e.g., change the position of the bolt / latch, change the orientation of the cylinder / lock body, etc.) according to the capabilities of the EMC 622.

[0125] Note that the data obtained and passed by DP 637 and CP 638 is not limited to the specific sensors 620 and / or EMC 622 provided by a particular MFG, vendor, service provider, etc. Instead, the collecting entity can identify the attached or connected sensors 620 and / or EMC 622, determine the sensor / EMC type of the attached or connected sensors 620 and / or EMC 622, separate the data plane and control plane activities of the sensors 620 and / or EMC 622 based on the sensor / EMC type, understand / determine the different types of data generated by each attached / coupled IoT device 504 and passed through the IAL 639, understand the differences between the different types of data generated by each attached / coupled IoT device 504, and physically interface with the attached IoT devices 504 via the IAL 639 to ensure the correct operation of the attached / coupled IoT devices 504. In this way, each sensor 620 / EMC 622 can provide general access to various IoT devices 504 and allow various IoT devices 504 to be swapped or turned off without changing or reconfiguring the network architecture, physical system, and / or communication protocol / process.

[0126] In some embodiments, the entities 637 / 638 / 639 can be implemented as application programming interfaces (APIs) to provide access to the IoT data / HSD of the attached / coupled IoT devices 504. In these embodiments, the entities 637 / 638 / 639 can provide methods or procedure calls that can be invoked by different components (e.g., hardware devices (e.g., client 560, server 304, one or more IoT devices 504, hub 510, etc.); virtualized devices; protocol entities / layers; applications; drivers / plugins, etc.). In response to these method or procedure calls, the entities 637 / 638 / 639 can transfer data to / from various attached / coupled IoT devices 504 and to / from other trays 500 and / or hubs 510.

[0127] In some embodiments, each of entities 637 / 638 / 639 may be implemented as a connector to provide access to IoT data / HSD of the attached IoT device 504. When implemented as a connector, each of entities 637 / 638 / 639 may be responsible for routing messages to / from different components or layers and translating or formatting the messages for consumption by other components / layers. In these embodiments, collection entities 637 - 638 may encapsulate the IoT data / HSD obtained from IAL 639 for transmission via a rack network or a hub network and may (de)encapsulate and / or translate the IoT data / HSD obtained from communication circuit 505 for transmission via IAL 639 to the attached / coupled IoT device 504 through interconnect 506. In some implementations, entities 637 / 638 / 639 may be external connectors that coordinate and control the entirety of the interaction / communication between various components / layers. In these implementations, components / layers may not call methods or procedure calls via entities 637 / 638 / 639; rather, entities 637 / 638 / 639 may execute method or procedure calls on behalf of the requesting / calling components / layers. Additionally or alternatively, the collection entity may be of the type of middleware or "software glue" that is used to connect two or more separate components / layers by translating or adapting instructions / commands obtained from one component / layer into instructions / commands that can be understood by another component / layer.

[0128] In some embodiments, each of entities 637 / 638 / 639 may provide a publisher and subscriber (publish / subscribe) service to provide access to IoT data / HSD of the attached IoT device 504. In these embodiments, a particular component / layer may act as a subscriber and / or a publisher. The publisher and subscriber may communicate with each other using topic (or service)-based messages, where the publisher may be associated with one or more topics and may send topic-based messages to subscribers that have subscribed to the topics. In these implementations, each of entities 637 / 638 / 639 may evaluate IoT data / HSD from the attached / coupled IoT device 504 and may evaluate and filter the data based on various topics. Additionally, the publisher may send IoT data / HSD generated by different IoT devices 504 to different types of subscribers, but the publisher may be responsible for implementing policies / configurations regarding the types of devices that are allowed to subscribe to a particular topic. This may provide the ability to add topics that capture data for new functions / services / features of currently installed IoT devices 504 and / or different sets of data provided by newly added IoT devices 504 without changing the underlying network architecture, communication protocols, etc.

[0129] In one example, referring to Figure 5, the bracket 500-3 can subscribe to the temperature control topic regarding one or more attached IoT devices 504-3, and the bracket 500-2 can subscribe to the home security topic regarding one or more attached IoT devices 504-2. The bracket 500-1 can be a publisher for both the temperature control topic and the home security topic based on one or more attached IoT devices 504-1 (e.g., temperature sensor 620 and pressure sensor 620). Based on events or triggers defined by the device-specific CFG 635, the collection entities 637-638 of the publisher bracket 500-1 can query or poll the attached IoT devices 504-1 for topic-related data (e.g., for the temperature control topic, polling / querying the temperature sensor for temperature data, and for the home security topic, polling / querying the pressure sensor 620 for pressure data). Additionally or alternatively, the collection entities 637-638 of the publisher bracket 500-1 can be subscribers to one or more attached IoT devices 504-1 that act as temperature-related publishers (e.g., temperature sensor 620) and / or home security-related publishers (e.g., pressure sensor 620). The bracket 500-1 acting as a publisher can then provide home security-related data to the subscribing bracket 500-2 and can provide home security-related data to the subscribing bracket 500-2.

[0130] The IoT device initiator 1001 (also referred to as "initiator 1001", etc.) can be used to perform the IoT device startup process (e.g., Figure 10 the process depicted). The initiator 1001 can be used to detect the bracket 500 and pair it with the IoT device 504 newly attached / connected to the bracket 500. For example, when the IoT device 504 is attached / connected to an empty bracket 500 newly deployed in the environment, when a new IoT device 504 is added to an already paired bracket 500, when the IoT device 504 is replaced with a new IoT device 504, etc., the bracket 500 can invoke and operate the initiator 1001. Regarding Figure 10 showing and describing the details of the processes / operations performed by the IoT device initiator 1001.

[0131] The bus 606 can couple the processor 602 to a modem circuit 640 (also referred to as “baseband circuit 640”, “modem 640”, etc.) for communication with other devices. The modem 640 can include circuits such as, but not limited to, the following: circuits of one or more FPDs (e.g., FPGAs, etc.); PLDs (e.g., CPLDs, HCPLDs, etc.); ASICs (e.g., structured ASICs, etc.); PSoCs; etc. The circuits of the modem 640 can include logic blocks or logic constructs, which include but are not limited to configuration logic 641, update logic 642, memory cells 643, input / output (I / O) blocks 644, and other interconnected resources that can be programmed to perform various modem functions (e.g., processing signals received from the receive signal paths of the transceivers 610, 611, and generating signals for the transmit signal paths of the transceivers 610, 611). The modem 640 can interface with the application circuits of the carriage 500 for generating and processing signals and controlling the operation of the transceivers 610, 611.

[0132] For example, in various embodiments, the modem manager 634 can allocate an MP to the circuits of the modem 640. As previously discussed, the MP can be configured or defined using HDL (e.g., RTL, VHDL, Verilog, etc.). Such allocation can include: the modem manager 634 loading the MP into the memory cells 643. The memory cells 643 can be used to store data in lookup tables (LUTs) that the modem 640 uses to implement various logic functions. The memory cells 643 can include any combination of suitable volatile and / or non-volatile memories, including any combination of various levels of memory / storage devices (including but not limited to any combination of erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)).

[0133] The allocation may further include: the update logic 642 obtains the MP from the memory cell 643 and applies the MP to the configuration logic 641. Once the MP is enabled, the configuration logic 641 can define a set of signal paths and a set of logic operations to be performed on the signal paths, which can be used to process various radio control functions that enable communication with one or more radio networks via the transceivers 610, 611 according to one or more specific wireless communication protocols. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shift, implementing protocol stacks, etc. In some embodiments, the modulation / demodulation performed by the modem 640 can include fast Fourier transform (FFT), precoding, and / or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the modem 640 can include convolutional, tail-biting convolutional, turbo, Viterbi, and / or low-density parity-check (LDPC) encoder / decoder functions. Embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples and can include other suitable functions in other embodiments. The modem 640 can pass the demodulated signals obtained from the transceivers 610, 611 to other components of the carriage 500 and can pass the modulated signals to the transceivers 610, 611 for transmission to other devices.

[0134] The carriage transceiver 610 (also referred to as "Mesh transceiver", "fog transceiver", etc.) can be used to communicate with other carriages 500 that can be included in the previously discussed fog and / or Mesh networks. The carriage transceiver 610 can use any number of frequencies and protocols. For example, when the modem 640 is configured with a carriage profile 675 indicating the IEEE 802.15.4 standard, the carriage transceiver 610 can send / receive signals in the 2.4 gigahertz (GHz) range specified by the IEEE 802.15.4 standard. Upon detection of a trigger, the modem 640 can be configured to utilize other wireless communication protocols (e.g., the low-power (BLE) standard defined by the Special Interest Group or TM other standards, etc.) for communicating with other carriages 500 and / or other Mesh / fog devices. The modem 640 can be configured for any specific wireless communication protocol used for connections to other carriages 500 and / or other mesh / fog devices. For example, according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, the carriage profile 675 can be used to implement Wi-Fi TM communication via WLAN. Additionally, for example, wireless wide area communication according to cellular or other wireless wide area protocols can occur via a wireless wide area network (WWAN) carriage profile 675 or via a specific cellular network carriage profile 675.

[0135] The carriage transceiver 610 may include multiple radios (e.g., including hardware devices for facilitating air communication (e.g., switches, filters, amplifiers, antenna elements, etc.)) to communicate using multiple standards for communication at different distances. For example, the IoT device 504 may use a BLE-based local transceiver or another low-power radio to communicate with nearby devices (e.g., within approximately 10 meters) to save power. Other carriages 500 and / or other mesh / fog devices at greater distances (e.g., within approximately 50 meters) may be reached via ZigBee or other medium-power radios. These two communication technologies may occur at different power levels via a single radio or may occur via separate transceivers / radios (e.g., a local transceiver / radio using BLE and a separate Mesh transceiver / radio using ZigBee). Utilizing different wireless communication protocols may or may not include: utilizing different radios within the carriage transceiver 610. The carriage transceiver 610 may be incorporated into the MCU as an address directly accessible by the chip (e.g., in a unit available from Intel ).

[0136] The hub transceiver 611 (also referred to as a "cloud transceiver", etc.) may include one or more radios to communicate with devices in the hub 510 and / or the cloud 302. For example, when the modem 640 is configured with a hub profile 677 indicating the use of standards such as IEEE802.15.4 or IEEE 802.15.4g, the hub transceiver 611 may transmit / receive signals in the 2.4 GHz range specified by the IEEE802.15.4 / g standard to access the LPWAN. Upon detection of a trigger, the modem 640 may be configured to utilize other wireless communication protocols for communication via the cloud 302 (e.g., LoRaWAN TM (Long Range Wide Area Network), one or more WiFi protocols, and / or one or more cellular protocols discussed herein). Utilizing different wireless communication protocols may or may not include: utilizing different radios within the hub transceiver 611. The techniques described herein are not limited to these techniques but may be used with any number of other hub transceivers 611 that implement long-range low-bandwidth communication (e.g., Sigfox and other technologies). Additionally, other communication techniques described in the IEEE 802.15.4e specification (e.g., slotted channel hopping) may be used.

[0137] As described herein, in addition to the systems mentioned regarding the carriage transceiver 610 and the hub transceiver 611, any number of other radio communications and protocols may be used. For example, the radio transceivers 610 and 611 may include LTE or other cellular transceivers that use spread spectrum (SPA / SAS) communication for high-speed communication (e.g., for video transmission). Additionally, any number of other protocols may be used (e.g., for medium-speed communication (e.g., for the allocation of still pictures, sensor readings, and network communication)) networks).

[0138] Transceivers 610 and 611 may include radios that are compatible with any number of 3GPP (Third Generation Partnership Project) specifications, in particular Long-Term Evolution (LTE), Long-Term Evolution-Advanced (LTE-A), and Long-Term Evolution-Advanced Pro (LTE-A Pro). It should be noted that radios that are compatible with any number of other fixed, mobile, or satellite communication technologies and standards may be selected. They may include, for example, any cellular wide-area radio communication technology (which may include, for example, 5th Generation (5G) communication systems, Global System for Mobile Communications (GSM) radio communication systems, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rate for GSM Evolution (EDGE) radio communication technology, and / or Third Generation Partnership Project (3GPP) radio communication systems (e.g.,Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), LTE-Advanced, Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, Third Generation (3G), Circuit Switched Data (CSD), High Speed Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (Third Generation) (UMTS(3G)), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA(UMTS)), High Speed Packet Access (HSPA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), High Speed Packet Access+ (HSPA+), Universal Mobile Telecommunications System - Time Division Duplex (UMTS-TDD), Time Division - Code Division Multiple Access (TD-CDMA), Time Division - Synchronous Code Division Multiple Access (TD-CDMA), 3GPP Release (Rel-8) (Pre-Fourth Generation), 3GPP Rel-9 to 3GPP Rel-18, 3GPP Fifth Generation (5G), 3GPP New Radio (NR) System, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution-Advanced (Fourth Generation) (LTE-Advanced(4G)), cdmaOne(2G), Code Division Multiple Access 2000 (Third Generation) (CDMA2000(3G)), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (First Generation) (AMPS(1G)), Total Access Communication System / Extended Total Access Communication System (TACS / ETACS), Digital AMPS (Second Generation) (D-AMPS(2G)), Push-to-Talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Norwegian for Offentlig Landmobil Telefoni,Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem D or Mobile Telephone System D), Public Automatic Land Mobile (Autotel / PALM), ARP (Finnish for “Autoradiopuhelin”, “Car Radiotelephone”), NMT (Nordic Mobile Telephone), the High Capacity version (Hicap) of NTT (Nippon Telegraph and Telephone), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handyphone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), also known as the 3GPP Generic Access Network or GAN standard), WiFi (IEEE 802.11 standard), or Low Energy Bluetooth (BLE), IEEE802.15.4 (6LoWPAN), WiFi Direct, ANT or ANT+)); LTE Device-to-Device (D2D) or Proximity Services (ProSe); Z-Wave (also known as “Zig-Wave”); Linear; SigFox; Platanus; Universal Plug and Play (UPnP), IEEE 802.16 or Worldwide Interoperability for Microwave Access (WiMAX), Wireless Gigabit Alliance (WiGig) standard, Generic mmWave standard (wireless systems operating at 10 - 300 GHz and above (e.g., WiGig, IEEE 802.11ad, IEEE 802.11ay, etc.)), technologies operating above 300 GHz and THz bands (3GPP / LTE-based or IEEE 802.11p and others) Vehicle-to-Vehicle (V2V), Vehicle-to-X (V2X) and Vehicle-to-Infrastructure (V2I) and Infrastructure-to-Vehicle (I2V) communication technologies, 3GPP Cellular V2X, DSRC (Dedicated Short Range Communication) communication systems (e.g., Intelligent Transportation Systems), etc. In addition to the standards listed above, any number of satellite uplink technologies (including, for example, radios compliant with standards issued by ITU (International Telecommunication Union) or ETSI (European Telecommunications Standards Institute)) may also be used for the uplink transceiver 611. The examples provided herein should therefore be understood to be applicable to a variety of other existing and yet-to-be-developed communication technologies.

[0139] The bus 606 can couple the processor 602 to the interface 618, which can be any suitable hardware device for connecting external devices of the carriage 500. The external devices can include the IoT device 504. The IoT device can include one or more sensors 620 and / or one or more EMCs 622. The sensor 620 can be any device capable of detecting events and / or changes in the surrounding environment. The sensor 620 can include accelerometers, level sensors, flow sensors, temperature sensors, pressure sensors, atmospheric pressure sensors, motion sensors, position / proximity sensors, etc. The EMC 622 can allow the IoT device 504 to change state, position, and / or orientation, or move or control mechanisms or systems. The EMC 622 can include one or more power switches, actuators (e.g., valve actuators), audible sound generators, visual warning devices, motors, wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components.

[0140] In an embodiment, the carriage 500 can be configured to operate one or more EMCs 622 based on one or more captured events and / or instructions, commands, control signals, etc. The events can be based on the policies / rules defined by the CFG 635, the data collected from one or more sensors 620, and / or the instructions, commands, control signals, etc. received from the hub 510, the server 304, and / or the client 560. In an embodiment, the IAL 639 can provide parameters, messages, control signals, etc. to the interface 618 based on the sensor data and / or the received instructions, commands, etc. In response thereto, the interface 618 can perform general-purpose input / output (GPIO) operations to access the resources of the IoT device 504. In an embodiment, the interface 618 can be capable of directly accessing the IoT device 504 using suitable techniques (e.g., those discussed below with respect to the bus 606). In some embodiments, the interface 618 can access or control a suitable relay module or I / O controller (e.g., RS-232 / 485 relay module, USB relay, Ethernet relay, a programmable computing board programmed as a relay module (e.g., Arduino board, Edison board, RaspberryPi board, etc.)). In an embodiment, the interface 618, the sensor 620, and the EMC 622 can be collectively referred to as an "event capture circuit". In some embodiments, the event capture circuit can also be a battery monitor / charger 626, the processor 602, and / or other components in or coupled to the platform 504.

[0141] The battery 624 can power the cradle 500, but in an example where the IoT device 504 is installed in a fixed location, it can have a power source coupled to the power grid. The battery 624 can be a lithium-ion battery, a metal-air battery (e.g., zinc-air battery, aluminum-air battery, lithium-air battery), etc.

[0142] A battery monitor / charger 626 can be included in the IoT device 504 to track the state of charge (SoCh) of the battery 624. The battery monitor / charger 626 can be used to monitor other parameters of the battery 624 to provide fault prediction (e.g., the state of health (SoH) and the state of function (SoF) of the battery 624). The battery monitor / charger 626 can include a battery monitoring integrated circuit (e.g., the LTC4020 or LTC2990 from Linear Technologies, the ADT7488A from ON Semiconductor in Phoenix, Arizona, or the UCD90xxx IC from Texas Instruments in Dallas, Texas). The battery monitor / charger 626 can transfer information about the battery 624 to the processor 602 via the bus 606. The battery monitor / charger 626 can also include an analog-to-digital (ADC) converter that allows the processor 602 to directly monitor the voltage of the battery 624 or the current from the battery 624. The battery parameters can be used to determine the actions that the IoT device 504 can perform (e.g., transmission frequency, Mesh network operation, sensing frequency, etc.).

[0143] A power block 628 or other power source coupled to the power grid can be coupled to the battery monitor / charger 626 to charge the battery 624. In some examples, the power block 628 can be replaced with a wireless power receiver to obtain power wirelessly, for example, via a loop antenna in the IoT device 504. A wireless battery charging circuit (e.g., the LTC4020 chip from Linear Technologies in Milpitas, California, etc.) can be included in the battery monitor / charger 626. The specific charging circuit selected depends on the size of the battery 624 and thus on the required current. Charging can be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, etc.

[0144] The components of the carrier 500 may communicate via the bus 606. The bus 606 may 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. The bus 606 may be, for example, a dedicated bus used in an SoC-based system. Other bus systems may be included (e.g., I 2 C interface, SPI interface, point-to-point interface, and power bus, etc.).

[0145] Although not shown, various input / output (I / O) devices may be present within or connected to the carrier 500. For example, a display may be included to display information (e.g., sensor readings or actuator positions). An input device (e.g., a touch screen or keypad) may be included to accept input. In another example, a Near Field Communication (NFC) circuit (which includes an NFC controller coupled to an antenna element and a processing device) may be included to read an electronic tag and / or connect to another NFC-enabled device.

[0146] Figure 7 Components of an example implementation of the hub 510 according to various embodiments are shown. As Figure 7 shown, the hub 510 may include components similar to those Figure 6 shown, where like-numbered elements may represent similar parts throughout. For example, the processor 702 may be the same as or similar to the processor 602, the memory 704 may be the same as or similar to the memory 604, the bus 706 may be the same as or similar to the bus 606, the interface 718 may be the same as or similar to the interface 618, the storage device 708 may be the same as or similar to the storage device 608, the battery 724 may be the same as or similar to the battery 624, the battery monitor 726 may be the same as or similar to the battery monitor 626, the power block 728 may be the same as or similar to the power block 628, etc. Each of these elements may operate in the same or similar manner as the like-numbered elements discussed with respect to Figure 6 Although not shown in Figure 7 , the mass storage device 708 may include Figure 6 the same or similar modules / entities as shown (e.g., RIB 636, collection entities 637-638, IAL 639, etc.), which may operate in the same or similar manner as previously discussed. For the sake of brevity, elements different from those Figure 6 shown and described are discussed below.

[0147] The hub 510 may include a communication circuit 705, which may be the same as or similar to the communication circuit 505 discussed previously. In this regard, the modem circuit 740 and the transceivers 710-711 may be the same as or similar to the modem circuit 640 and the transceivers 610-611, respectively. However, in some embodiments, the modem circuit 740 and the transceiver 710 may allow the hub 510 to communicate with the respective cartridges 500 via multiple channels using different wireless communication protocols. In these embodiments, the cartridge transceiver 710 may include multiple radios (e.g., including hardware devices for facilitating air communication (e.g., switches, filters, amplifiers, antenna elements, etc.)) to communicate using multiple standards for communication. For example, the cartridge transceiver 710 may include: a first radio for communicating with a first cartridge 500 (e.g., Figure 5 the cartridge 500-1 shown) using BLE; a second radio for communicating with a second cartridge 500 (e.g., Figure 5 the cartridge 500-2 shown) using ZigBee; and so on. To this end, the communication circuit 705 may include multiple modems 740 to communicate with multiple cartridges 500 simultaneously (if needed), or a modem manager 734 may operate a suitable scheduling algorithm that allows the hub 510 to switch the MPs loaded and enabled by the modems 740.

[0148] It may include a network interface controller (NIC) 716 to provide wired communication to the cloud 302 or other devices (e.g., other cartridges 500 and / or other devices). The wired communication may provide an Ethernet connection or may be based on other types of networks (e.g., Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, DataHighway+, PROFIBUS, or PROFINET, etc.). An additional NIC 716 may be included to allow connection to a second network (e.g., NIC 716 provides communication to the cloud via Ethernet, and the second NIC 716 provides communication to other devices via another type of network).

[0149] The storage device 708 may include program code for the hub operating system (hOS) 801, configuration (CFG) 735, RIB 736, protocol stack 800, and boot installer 901. The hOS 801 may be included to perform operations for various components of the hub 510, manage hub resources by performing operations such as controlling and allocating memory, prioritizing system requests and processes, controlling I / O devices, managing the file system, etc. The hOS 801 may provide access to the various cartridges 500 and enforce policies / configurations on the cartridges 500. Regarding Figure 8Describe the operation in more detail. hOS 801 can support real-time operations (e.g., the operation of protocol stack 800 (see, for example, Figure 8 ). hOS 801 can also support the operation of various applications (which may be non-real-time). hOS 801 can be any suitable operating system or firmware (e.g., a real-time operating system (RTOS), a router OS or network OS customized for a network switch or a commercial router, a general-purpose OS, or hOS 801 can be a proprietary OS specifically written and customized for hub 510.

[0150] RIB 736 can indicate the routes for sending IoT data and HSD to each carriage 500, entity, or device (e.g., server 304, client 560, network elements in cloud 302, etc.) and / or other environments (e.g., in a federated network and / or another section of a building, etc.) for carriages 500 and hub 510. RIB 736 can be the same as or similar to (or have the same or similar format as) RIB 636 discussed previously. However, in some embodiments, RIB 736 can be a master RIB or a global RIB that stores the routes for all carriages 500 in environment 50 (see Figure 5 ), as well as the routing information for sending data to external entities / devices. In addition, the collection entity of hub 510 can perform a lookup operation on RIB 736 to determine the optimal routes for sending IoT data / HSD to carriages 500, external entities / devices, and / or carriages 500 and hub 510 in other environments.

[0151] CFG 735 can include documents or data structures in a format that can be interpreted and presented by hub 510 (e.g., XML (or any of its variants), JSON, markdown (or any of its variants), IFTTT ("If This Then That"), PADS markup language (PADS / ML), routing policy language (RPL), click router configuration language, Nettle, and / or some other suitable data format). In an embodiment, an application implemented by a user device (e.g., client 560) can generate a document or data structure based on various selections within a user interface.

[0152] The document or data structure of CFG 735 may include a "description" (which is a collection of software modules, program codes, logic blocks, parameters, policies, rules, etc.), which may be used by one or more brackets 500 to control and / or monitor various IoT devices 504 and share the data generated by the IoT devices 504. The description may indicate relevant information to be implemented and / or integrated into one or more IoT devices 504 by one or more brackets 500. For example, the description may indicate information to be implemented in or by a specific type of IoT device 504, information to be implemented in or by a bracket 500 or an IoT device 504 to be deployed at a specific location, etc. In some embodiments, the description may include information for each bracket 500 or IoT device 504 to generate device-specific configuration 635 and / or executable software modules or software components. In these embodiments, when the bracket 500 and / or the IoT device 504 implements CFG 735, the bracket 500 and / or the IoT device 504 may generate executable code for execution in the corresponding runtime environment (RTE), which enables the bracket 500 and / or the IoT device 504 to interpret the data generated by the sensor 620 and / or the EMC 622 and control the sensor 620 and / or the EMC 622 according to the device-specific CFG 635. In embodiments where the bracket 500 and / or the IoT device 504 are implemented as field-programmable devices (FPDs) (e.g., FPGAs, structured ASICs, programmable SoCs (PSoCs), etc.), a hardware description language (HDL) (e.g., register transfer logic (RTL), very high speed integrated circuit (VHSIC) HDL (VHDL), Verilog, etc.) may be used to configure or define CFG 735.

[0153] The boot installer 901 (also referred to as the "installer", "installation engine", etc.) may be used to perform a basic installation or boot process for a newly installed bracket 500. When the bracket 500 is first installed or newly deployed in an environment (e.g., when a building contractor installs various brackets 500 throughout one or more new buildings, or when a bracket 500 is installed at an existing home / office location), the hub 510 may invoke and operate the boot installer 901. Additionally, the boot installer 901 may be invoked and operated when an IoT device 504 is not yet attached or coupled to a newly deployed bracket 500 or an empty bracket 500. As used herein, the term "empty bracket 500" may refer to a bracket 500 without an attached IoT device 504. Regarding Figure 9 Show and describe the details of the process / operation performed by the boot installer 901.

[0154] The protocol stack 800 may be an implementation of various protocols for communicating data between a user device (e.g., client 560) and an IoT device 504 via the hub 510 and the cradle 500. The stack 800 may include various protocols, preferences, configurations, etc. for preparing and providing data for consumption by a user device and preparing and providing data for consumption by various IoT devices 504. Figure 8 The details of protocol stack 800 are discussed in more detail.

[0155] Figure 8 An example protocol stack 800 is depicted in accordance with various embodiments. The protocol stack 800 may be used to communicate between the hub 510, the cradle 500, and the user device (e.g., regarding Figure 5 Mesh network and / or fog computing functions are established between the client 560 shown and described. As shown, the stack 800 may include an application interface 810 including hOS 801, an application layer (AL) 812, an Internet protocol layer (IPL) 814, a transport protocol layer (TPL) 816, a link control layer (LCL) 818 and a physical layer (PHY) 820.

[0156] The application interface 810 may provide an interface through which a user may access and / or interact with the hub 510 in order to access the cradle 500 and / or IoT devices 504. As shown, the application interface 810 may include the hOS 801. In an embodiment, the hOS 801 may be used to host user applications (e.g., the "apps" discussed previously) for accessing resources provided by the hub 510 and various IoT devices 504 and / or cradles 500, as well as resources provided by various IoT groups (e.g., IoT group 306, etc.). Through the hOS 801 and / or by hosting the app, the application interface 810 may also allow a user to view IoT devices 504 within the network, the location of IoT devices 504 within the network, the status, availability or operating mode of IoT devices 504 in the network, and / or other analytics associated with IoT devices 504. The hOS 801 may host the app to enable users of user devices to define various configurations for obtaining services provided by various IoT devices 504. In some embodiments, the application interface 810 may be implemented solely by the hub 510.

[0157] The AL 812 can provide an interface for the bracket 500 and / or the IoT device 504 to present information to the user via the application interface of the app. The AL 812 can be a layer responsible for encapsulating or formatting the data obtained from the IoT device 504 for presentation to the user, and for encapsulating / formatting the data obtained from the user application for consumption by the IoT device 504. The AL 812 can be implemented as a library, API, etc., which allows application developers, vendors, MFGs, service providers, etc. to use the desired modules and / or components in various software modules and / or software components of the library, API, etc., so that their applications can interact with the hardware elements of the hub 510. In an embodiment, each IoT device 504 can have corresponding plugins 802-1 to 802-N (collectively referred to as "plugins 802") within the AL 812, which can describe the calculations, parameters, actions, etc. required to present the data obtained from the corresponding IoT device 504 to the user and for the user to provide data to the corresponding IoT device 504. Any programming language and / or development tool discussed herein can be used to define and / or generate the plugins 802.

[0158] The IPL 814 can be responsible for packet routing and interworking between different networks (e.g., the cloud 302, the hub network, the bracket network, etc.). This can include identifying and addressing data packets to be routed from a source to a destination. In an embodiment, each IoT device 504 can have corresponding policies 803-1 to 803-N (collectively referred to as "policies 803" or "policy configurations 803") within the IPL 814, which can describe the policies, rules, capabilities, etc. for each corresponding IoT device 504. In one example, the policy 803 can indicate to the various IoT devices 504 which types of data (e.g., IoT data or HSD, or certain parts of IoT data or HSD) can be shared with various types of IoT devices 504 (e.g., the type of sensor 620 or the type of EMC 622) and / or a specific IoT device 504 (e.g., the IoT device 504 deployed at a specified location, etc.). In another example, the policy 803 can indicate the IoT devices 504 and client devices 560 that are allowed to access the IoT data and HSD or other hardware resources of the corresponding IoT device 504. In another example, the policy 803 can indicate the IoT device capabilities (e.g., the hardware and / or software platform, the versions of various software components, the communication capabilities, etc.). The policy 803 can be based on the configuration defined by the user using the various interfaces provided by the application interface 810 and / or the hOS 801. The policy 803 can be formed by any programming language, markup language, schema language, etc. discussed herein. The sharing of data can be based on the permissions set for the various IoT devices 504 and / or the capabilities of the IoT devices 504. In an embodiment, the IPL 814 can include a policy layer ( Figure 8(not shown), so as to implement the policy 803 for the corresponding IoT devices 504 to which each bracket 504 is communicatively attached.

[0159] The TPL 816 can be responsible for sharing data and providing flow control functions for transferring data between the user device and the IoT devices 504. The TPL 816 can include an interface for indicating the current status, preferences, and set of configuration (SPC) 804-1 to 804-N (collectively referred to as "SPC 804") of each IoT device 504. The TPL 816 can determine or identify the status of each IoT device 504, the current preferences of each IoT device 504, and the current configuration of each IoT device 504 based on the HSD and / or IoT data obtained from the physical layer 820. Once identified, the TPL 816 can generate the SPC 804 and provide it to the higher layer and / or lower layer of the stack 800. The status of the SPC 804 can indicate the current condition or operating mode of each IoT device 504. The preferences of the SPC 804 can indicate the data for which each IoT device 504 wants or needs to perform various functions. The configuration of the SPC 804 can indicate the current settings of each IoT device 504.

[0160] The LCL 818 can provide an interface between the higher / upper layer and the lower / lower layer. The LCL 818 can provide service flow management and error control functions, and identify the communication protocol to be used for transferring data between the hub 510, the cloud 302, and each IoT device 504 via each bracket 500. In this regard, the LCL 818 can establish a flow for the protocol data unit (PDU) (e.g., frame, packet, etc.) to be transferred between various devices by defining or allocating flow parameters to the flow. The flow parameters can include flow category (e.g., network control, remote computing / programming, emergency, voice, data monitoring, logging, etc.), flow priority, quality of service (QoS) parameters, network type (e.g., protocol for hub network, bracket network, cloud 302, etc.), service type (e.g., permanent or switched service), data type of the flow (e.g., IoT data or HSD), etc. In an embodiment, the LCL 818 can allocate flow parameters to the flow based on the data type to be transferred between each IoT device 504, the hub 510, the client 560, etc. In this regard, the LCL 818 can be responsible for identifying the data type of a single flow and determining the flow parameters associated with the data type. The LCL 818 can also assign a sequence number to the PDU. In an embodiment, the LCL 818 can include a QoS sublayer ( Figure 8(not shown) to identify and label PDUs according to the QoS requirements of the PDUs and allocate interrupts to high-priority data. In an embodiment, the LCL 818 may allocate sequence numbers and flow parameters to PDUs based on operations to be performed by one or more IoT devices 504, priorities associated with services or IoT devices 504, and / or other criteria that may be defined by the policy 803.

[0161] The PHY 820 may include a hardware infrastructure (e.g., communication circuits 705, NIC 716, etc.) for transmitting data in the rack network, hub network, and / or cloud 302 and providing an interface (e.g., API) between the protocol stack 800 and the driver / plugin 802 for the platform of the hub 510 or rack 500. The main functions of the PHY 820 may include: transmitting / receiving (e.g., raw bits of data) through various air or wired interfaces (e.g., physical links (e.g., links 508, 511, 517, etc.)); performing link adaptation, power control; loading modem configurations (e.g., switching between the hub and the rack network); etc. The PHY 820 may also indicate to higher layers how the corresponding IoT device 504 is connected or attached to each rack 500, the specific technology used by various IoT devices 504 to connect to the network, how various IoT devices 504 are powered, and / or other similar information. In an embodiment, the PHY 820 may transfer IoT data and HSD obtained from each rack 500 through the hub network to other racks 500, may provide IoT data / HSD to the client device 560 via the LCL 818, TPL 816, IPL 814, AL 812, and the application interface 810 and hOS 801, and may obtain data to be provided to each IoT device 504 via the application interface 810 and hOS 801, AL 812, IPL 814, TPL 816, and LCL 818.

[0162] In an embodiment, the protocol stack 800 may be implemented by the hub 510, which may be used to transfer IoT data and HSD directly or via the cloud 302 between the hub 510 and the client 560 / server 304. The protocol stack 800 implemented by the DP 737 and / or CP 738 may also be used to transfer IoT data and HSD between the hub 510 and the client 560 (and / or server 304), which may be accomplished via a direct link or via the cloud 302. In some embodiments, the DP 637 and / or CP 638 of the rack 500 may implement a protocol stack 800 without an application interface 810, which may be used to transfer IoT data and HSD between the IoT devices 504 and the racks 500 to which they are attached and transfer IoT data and HSD between the racks 500 through various air interfaces.

[0163] Figures 9 - 11 Illustrates processes 900 - 1200 for allocating and implementing a modem manager 634 according to various embodiments. For illustrative purposes, the operations of processes 900 - 1200 are described as being performed by various elements as described with respect to Figures 1 - 8 Some of the operations in processes 900 - 1200 are described as being between the hub 510, one or more cartridges 500, IoT devices 504, and other components / modules of arrangement 50 (e.g., cloud 302, server 304, client 560, etc.). It should be understood that, as described with respect to Figures 5 - 8 The communication circuits 505 / 705 can facilitate these communications between components / modules / devices. Additionally, although specific examples and an order of operations are shown in Figures 9 - 11 The order of operations depicted should not be construed as limiting the scope of the embodiments in any way. Instead, while remaining within the spirit and scope of the present disclosure, the depicted operations can be reordered, broken into additional operations, combined, and / or omitted together.

[0164] Referring to the drawings, Figure 9 Is a flowchart showing an example process 900 for a basic installation or boot process according to various embodiments. For illustrative purposes, the operations of process 900 are described as being performed by a boot installer 901 of a hub 510 with an empty cartridge 500. However, it should be understood that process 900 can be performed by a cartridge 500 with an attached IoT device 504 (e.g., “non - empty cartridge 500”) and / or other similar devices. In an embodiment, the boot installer 901 can be program code stored in one or more computer - readable media (e.g., storage device 708) that, when executed by a processor circuit (e.g., processor 702), can cause the hub 510 to perform the operations of process 900. In an embodiment where the boot installer 901 is implemented as a hardware accelerator (e.g., FPGA cell), the boot installer 901 (e.g., FPGA cell) can be pre - configured with logic (e.g., appropriate bitstream, logic blocks / configurations, etc.) to perform the operations of process 900 (instead of using programming instructions to be executed by the processor 702).

[0165] The process 900 may begin with operation 905, where the bootstrapper 901 causes the hub 510 to enter a pairing mode with the empty cradle 500. This may occur when the hub 510 and / or the empty cradle 500 are powered on. In operation 905, any suitable pairing mechanism may be used, such as: exchanging capability information via pairing request and pairing response messages; generating and exchanging keys or digital certificates (e.g., using Elliptic Curve Key Agreement Algorithm (ECKA), Elliptic Curve Diffie Hellman (ECDH) public key cryptography algorithm, and / or other similar key exchange algorithms); synchronizing audio and / or visual patterns, etc. A user interaction mechanism (e.g., compare and confirm, copy and confirm, select and enter, device authentication with enabled button (BEDA), and other similar methods that require user involvement) may be used to pair the devices.

[0166] In operation 910, the bootstrapper 901 may obtain the unique identifier (ID) of the cradle 500. In some embodiments, the communication circuit 705 of the hub 510 may receive a capability message from the empty cradle 500, which includes the unique ID of the empty cradle 500 and other capability information.

[0167] In operation 915, the bootstrapper 901 may command the communication circuit 705 to establish an end-to-end encryption tunnel (EET) with the empty cradle 500. The EET may be a secure channel for transmitting data between the cradle 500 and the hub 510 in a manner that resists eavesdropping and / or tampering of data. A known process / protocol (e.g., using digital signatures, public key infrastructure, etc.) may be used to establish the EET. The key and / or digital signature used to establish the EET may be provisioned therein during the manufacture of the cradle 500 and / or the hub 510, or may be provisioned remotely in the cradle 500 and / or the hub 510. Example implementations and processes for such remote provisioning are discussed in co-assigned International Application No. PCT / US2016 / 037634, which is incorporated by reference. Additionally, in various embodiments, operations 905 - 915 may be combined into a single process or procedure.

[0168] In operation 920, the bootstrapper 901 determines / identifies the cradle capabilities of the empty cradle 500. The cradle capabilities may be based on the capability information exchanged during the pairing process in operation 905. The cradle capabilities may include various platform and / or runtime environment parameters associated with the cradle 500, such as the hardware components implemented by the cradle 500 (e.g., processor type and model, memory device, RF chipset, etc.), the specific communication protocols supported by the cradle 500, the installed OS, firmware, etc., type and version, device identifier, etc.

[0169] At operation 925, the boot installer 901 determines whether the empty tray 500 requires any updates. In an embodiment, the updates may be based on the tray capabilities identified at operation 920. If at operation 925, the boot installer 901 determines that the empty tray 500 requires an update, the boot installer 901 may proceed to operation 930 to obtain the required updates via the EET and allocate those updates in the empty tray 500. In one example, the boot installer 901 may identify the version of the currently installed firmware at operation 925, and if the identified version is not the latest version, the boot installer 901 may schedule the tray 500 for a firmware update at operation 930. After updating the empty tray 500, the boot installer 901 may proceed to operation 935 to determine the route between the empty tray 500 and the hub 510.

[0170] If at operation 925, the boot installer 901 determines that the empty tray 500 does not require any updates, the boot installer 901 may proceed to operation 935 to determine one or more communication routes from the empty tray 500 to the hub 510. In an embodiment, the boot installer 901 may measure the distance between the hub 510 and the empty tray 500 in order to find the best or optimal route to the empty tray 500 with the least number of hops / next nodes. In various embodiments, the boot installer 901 may use any suitable routing protocol to determine the communication route, such as distance-vector routing protocols (e.g., Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Babel, etc.), path-vector protocols (e.g., Border Gateway Protocol (BGP), etc.), link-state routing protocols (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), etc.

[0171] At operation 940, the boot installer 901 may generate a RIB (e.g., RIB 636) for the empty tray 500 based on the route determined / identified at operation 935 and allocate the generated RIB 636 in the empty tray 500 via the EET. At operation 945, the boot installer 901 may determine whether any IoT devices 504 connected to the tray 500 require sensor activation. If at operation 945, the boot installer 901 determines that no IoT devices 504 require sensor activation, the boot installer 901 may proceed to operation 955 to determine whether there are any remaining unpaired trays 500 that need to be paired with the hub 510. If at operation 945, the boot installer 901 determines that there is at least one connected IoT device 504 that requires IoT device activation, the boot installer 901 may proceed to operation 950 to activate the IoT device starter 1001 and / or invoke the execution of the IoT device startup process 1000, which is performed by Figure 10Shown and described. During or after execution of process 1000, the boot installer 901 may enter operation 955 to determine if there are any remaining unpaired carriers 500.

[0172] In operation 955, the boot installer 901 may determine if there are any unpaired carriers 500 that need to be paired with the hub 510. If, in operation 955, the boot installer 901 determines that there is at least one remaining unpaired carrier 500, the boot installer 901 may loop back to perform operation 905. If, in operation 955, the boot installer 901 determines that there are no remaining unpaired carriers 500, the boot installer 901 may enter operation 960 to end process 900. After operation 960, process 900 may be invoked at some point in the future and repeated as needed.

[0173] Now refer to Figure 10 , Figure 10 is a flow chart showing an example process 1000 for booting a new IoT device 504 according to various embodiments. Process 1000 may operate concurrently with, or after completion of, Figure 9 process 900. For illustrative purposes, the operations of process 1000 are described as being performed by a launcher 1001 of a carrier 500 with a newly attached IoT device 504. In an embodiment, the launcher 1001 may be program code stored in one or more computer-readable media (e.g., storage device 608) that, when executed by a processor circuit (e.g., processor 602), may cause the carrier 500 to perform the operations of process 1000. In an embodiment where the launcher 1001 is implemented as a hardware accelerator (e.g., FPGA cell), the launcher 1001 (e.g., FPGA cell) may be pre-configured with logic (e.g., appropriate bitstream, logic blocks / configurations, etc.) to perform the operations of process 1000 (instead of using programming instructions to be executed by processor 602).

[0174] Process 1000 may begin at operation 1005, where the IAL 639 of the carrier 500 may detect a new IoT device connected or attached to the carrier 500. In an embodiment, the launcher 1001 may implement the IAL 639 to interact with the interface 618 to detect (digital or analog) signals or voltages generated by the new IoT device 504 via the interconnect 506 when the new IoT device 504 is powered on or at some point during operation of the new IoT device 504. In other embodiments, the new IoT device 504 may broadcast an indicator wirelessly (which may be received by the communication circuit 505), and the launcher 1001 may implement a data collection entity to obtain the indicator from the communication circuit 505. In other embodiments, other methods for detecting the new IoT device 504 may be used.

[0175] At operation 1010, the initiator 1001 may identify information related to the new IoT device 504 (also referred to as "IoT device information", "IoT information", etc.). The IoT information may indicate the unique ID of the IoT device 504, the device type of the IoT device 504 (e.g., the type of sensor or EMC), the MFG or vendor of the IoT device 504, the model of the IoT device 504, and various capabilities of the IoT device 504 (e.g., the communication capabilities of the IoT device 504 (e.g., the supported communication protocols, the versions of these protocols, etc.), the hardware and / or software platforms implemented by the IoT device 504, the resources provided by the IoT device 504, etc.).

[0176] At operation 1015, the initiator 1001 may determine whether the plug-in 802 is currently available for the new IoT device 504. In some embodiments, the initiator 1001 may check whether the plug-in 802 for the new IoT device 504 is stored in the local storage device 608. In other embodiments, the initiator 1001 may command the communication circuit 505 to transmit the IoT information to the hub 510 and receive an indication from the hub 510 as to whether the hub 510 currently includes the plug-in 802.

[0177] If, at operation 1015, the initiator 1001 determines that the plug-in 802 is currently available for the new IoT device 504, the initiator 1001 may proceed to operation 1035 to load the plug-in for the new IoT device 504. If, at operation 1015, the initiator 1001 determines that the plug-in 802 is not currently available for the new IoT device 504, the initiator 1001 may proceed to operation 1020 to obtain the plug-in 802 for the new IoT device 504. In an embodiment, the plug-in 802 may be obtained from the hub 510 that may have obtained the plug-in 802 via the cloud 302. In other embodiments, operation 1015 may include: obtaining from the hub 510 an indication that the hub 510 has obtained and installed the plug-in 802 for the new IoT device 504.

[0178] At operation 1025, the launcher 1001 can determine whether the plugin 802 has been obtained correctly. If at operation 1025, the launcher 1001 determines that the plugin 802 has not been obtained correctly, the launcher 1001 can proceed to operation 1030 to report the failure to the hub 510, which can then be reported to the client 560 and / or the server 304. If at operation 1025, the launcher 1001 determines that the plugin 802 has been obtained correctly, the launcher 1001 can proceed to operation 1035 to load the plugin 802 for the new IoT device 504. At operation 1035, the launcher 1001 can load the plugin 802 for the new IoT device 504. At operation 1040, the launcher 1001 can implement the default policy 803 and variables for the IoT device 504.

[0179] At operation 1045, the launcher 1001 can determine the device pairing configuration for the new IoT device 504. The device pairing configuration can indicate whether the new IoT device 504 is to be paired or combined with one or more other IoT devices 504 for operation to provide the desired functionality / service. In an embodiment, when two or more IoT devices 504 are paired, they can exchange HSD and / or IoT data with each other to perform the desired functions and / or provide the desired services. At operation 1050, the launcher 1001 can determine the data sharing configuration for the IoT device 504. The data sharing configuration can indicate other devices or device types (e.g., other IoT devices 504 or other computing devices) with which the new IoT device 504 can share its data (including IoT data and / or HSD). In some embodiments, the previously discussed capabilities information can indicate the device pairing configuration and / or the data sharing configuration. In other embodiments, the user can be prompted to enter the device pairing configuration and / or the data sharing configuration via the previously discussed app.

[0180] At operation 1055, the launcher 1001 can run a test loop for the IoT device 504 to determine whether the IoT device 504 is operating correctly and whether the carriage 500 is operating according to the set of configurations / parameters for the IoT device 504. In an embodiment, the test loop can be run by the new IoT device 504, and the obtained values / data can be reported to the hub 510. This can be done to confirm the correct installation and connectivity of the new IoT device 504. After completing the test loop, the launcher 1001 can proceed to operation 1060 to end the process 1000, or the launcher 1001 can repeat the process 1000 as needed.

[0181] Now referring to Figure 11 , Figure 11is a flowchart showing an example process 1100 for transferring data in a Mesh network and / or fog computing system. After completing Figures 9 to 10 processes 900 - 1000 of, the hub 510 and / or the carriage 500 may operate process 1100. For illustrative purposes, the operations of process 1100 are described as being performed by various entities of the hub 510 and / or the carriage 500 with attached IoT devices 504. In an embodiment, the hub 510 and / or the carriage 500 may include program code stored in one or more computer-readable media (e.g., storage devices 608 / 708), which when executed by a processor circuit (e.g., processors 602 / 702) may cause the hub 510 and / or the carriage 500 to perform the operations of process 1100. In an embodiment where process 1100 is implemented as a hardware accelerator (e.g., FPGA tile), the hub 510 and / or the carriage 500 (e.g., FPGA tile) may be pre-configured with logic (e.g., appropriate bitstream, logic blocks / structures, etc.) to perform the operations of process 1100 (instead of using programming instructions to be executed by processors 602 / 702).

[0182] Process 1100 may begin at operation 1105, where data may be obtained from attached IoT devices 504, hub 510, client 560 / server 304, etc. At operation 1110, IoT device information may be identified from the obtained data, which may indicate the device type, device ID, etc. of the IoT device 504 that generated the data. At operation 1115, a policy may be enforced based on the device type of the IoT device 504 that generated the data and / or other criteria. At operation 1120, a destination node may be determined for the data, and at operation 1125, the next node for sending the data may be determined based on the destination node. At operation 1130, an appropriate modem profile may be loaded into the communication circuits 505 / 705 based on the device type of the next node. At operation 1135, a message may be generated to include the obtained data, and the message may also indicate the destination node and / or the next node. At operation 1140, the generated message may be sent to the next node.

[0183] In an embodiment where process 1100 is operated by the carriage 500, process 1100 may operate according to the following example.

[0184] At operation 1105, data can be obtained from the attached IoT device 504 or hub 510. To obtain data from the attached IoT device 504, the IAL 639 can be activated to interact with the interface 618 to obtain data via the interconnect 506. To obtain data from the hub 510, the communication circuit 505 can be configured with an appropriate modem profile (e.g., hub profile 677) to obtain data via the hub network. In an embodiment, the IAL 639 or the communication circuit 505 can determine whether the obtained data is HSD or IoT data.

[0185] If the obtained data is HSD, the CP 638 can be activated to identify IoT device information at operation 1110 and obtain and enforce the policy 803 corresponding to the IoT device 504 at operation 1115. If the obtained data is IoT data, the DP 637 can be activated to identify IoT device information at operation 1110 and obtain and enforce the policy 803 corresponding to the IoT device 504 at operation 1115. The policy 803 for HSD and IoT data can be indicated by the CFG 636 corresponding to the IoT device 504 (or the device ID of the IoT device 504) that generated the data. In some cases, the policy 803 can indicate different preferences, permissions, etc. for HSD and for IoT data, even if they are generated by the same IoT device 504. For example, IoT data can be permitted to be shared with the sensor 620 and the EMC 622, while HSD can only be permitted to be shared with the EMC 622.

[0186] At operation 1120, the DP 637 or the CP 638 can determine the destination node for the IoT data or HSD. In an embodiment, the destination node can be indicated by the IoT device information identified at operation 1110, indicated in the packet (e.g., the destination field of the packet header) for transmitting the data, based on the information in the policy 803 and / or the CFG 636, based on the data type of the obtained data (e.g., HSD or IoT data), etc. At operation 1125, the DP 637 or the CP 638 can identify the next node based on the determined destination node. In an embodiment, the DP 637 or the CP 638 can perform a lookup operation on the locally stored RIB 635 regarding the address of the next node based on the identifier or address of the destination node. The lookup operation can include hashing the address / identifier of the destination or performing some other suitable operation.

[0187] At operation 1130, DP 637 or CP 638 may command modem manager 634 to load the carriage configuration file 675 or the hub configuration file 677 according to whether the next node is carriage 500 or hub 510. If the next node is hub 510, DP 637 or CP 638 may command modem manager 634 to load the hub modem configuration file 677 into modem 640 to transfer data through the hub network. If DP 637 or CP 638 determines that the next node is another carriage 500, DP 637 or CP 638 may command modem manager 634 to load the carriage modem configuration file 675 into modem 640 to transfer data through the carriage network.

[0188] At operation 1135, DP 637 or CP 638 may generate a message including the obtained data. For example, if the obtained data is IoT data, DP 637 may generate a message including the IoT data, and if the obtained data is HSD, CP 638 may generate a message including the IoT data. At operation 1140, DP 637 or CP 638 may control the transmission of the generated message to the next node by, for example, commanding communication circuit 505 to send the message according to the wireless protocol of the modem configuration file loaded at operation 1130.

[0189] In an embodiment where process 1100 is operated by hub 510, process 1100 may operate according to the following example.

[0190] At operation 1105, data may be obtained from carriage 500 through the hub network or from client 560 (or server 304) via cloud 302. In a first example, the data is obtained from carriage 500, and in a second example, the data is obtained from client 560.

[0191] First example: When the data is obtained from carriage 500, the data may have been generated by the attached IoT device 504. To obtain data from carriage 500, communication circuit 705 may be configured with an appropriate modem configuration file (e.g., hub configuration file 777) to obtain data through the hub network. In an embodiment, PHY 820 may determine the data type of the obtained data (e.g., whether the data obtained from carriage 500 is HSD or IoT data), and may provide the data to LCL 818. In other embodiments, PHY 820 may transfer the data to LCL 818, and LCL 818 may determine whether the obtained data is HSD or IoT data.

[0192] Regardless of whether the PHY 820 or the LCL 818 determines the data type of the acquired data, at operation 1110, the LCL 818 can identify the IoT device information of the data acquired from the carriage 500. In an embodiment, the LCL 818 can establish a flow based on the identified IoT device information, and the TPL 816 can generate an SPC 804 to indicate the information transmitted by the established flow. At operation 1115, the IPL 814 can be activated to identify, obtain, and implement a policy 803 for the HSD or IoT data corresponding to the IoT device 504 that generated the data acquired at operation 1105. The policy 803 for the HSD and / or IoT data can be based on the IoT device information identified at operation 1110. In an embodiment, the implementation of the policy 803 can include restricting the information from the SPC 804 generated by the TPL 816 from being pushed to a higher or lower layer.

[0193] At operation 1120, the IPL 814 can determine a destination node for the data. At operation 1125, the IPL 814 can identify the next node for transmitting the data based on the determined destination node. In an embodiment, the destination node can be indicated by the IoT device information identified at operation 1110, can be based on the policy 803, can be indicated in the packet for transmitting the data based on the data type of the acquired data (e.g., HSD or IoT data), etc.

[0194] The destination node can be a remote device (e.g., the client 560 or the server 304) or another IoT device 504 attached to the carriage 500. When the destination is the client 560, the IPL 814 can provide the data to the AL 812 for encapsulation / formatting for presentation to the user via the application interface 810 and / or the hOS 801. The data can be encapsulated / formed according to the plug-in 802 corresponding to the IoT device 504 that generated the data.

[0195] When the destination is another IoT device 504, the IPL 814 can perform a lookup operation on the RIB 735 regarding the address of the next node based on the identifier or address of the destination node (e.g., by hashing the identifier or address). Additionally, the TPL 816 can generate a message to include the obtained data (or the SPC 804 based on the obtained data), the address / identifier of the next node, and the device type of the next node, which can occur at operation 1135. At operation 1130, the LCL 818 and / or the PHY 820 can command the modem manager 734 to load an appropriate modem profile (e.g., the hub profile 777 when the next node is the cradle 500) into the modem 740 to send data over the hub network at operation 1140. In this example, operation 1135 can occur before, during, or after operation 1130.

[0196] Second example: When data is obtained from the client 560 at operation 1105, the data may have been generated by the user of the client 560 using the app and may include or indicate the configuration 736. To obtain data from the client 560, the communication circuit 705 can be configured with an appropriate modem profile (e.g., the cloud profile) to obtain data over the network associated with the cloud; or the data can be obtained by the NIC 716 using an appropriate wired communication protocol. In an embodiment, the PHY820 or the LCL 818 can determine that the data is obtained from the client 560.

[0197] At operation 1110, the LCL 818 can identify the IoT device information of the obtained data. In this case, the IoT device information can be various parameters of the configuration 736. The LCL 818 can establish a flow based on the identified IoT device information, and the TPL 816 can generate the SPC 804 to indicate the information transmitted by the established flow. At operation 1115, the IPL814 can be activated to generate the policy 803 for one or more IoT devices 504 based on the configuration 736, and then the policy 803 can be implemented by the IPL814. Additionally, the IPL 814 can generate the device-specific configuration 636 based on the configuration 736 and / or the generated policy 803.

[0198] At operation 1120, the IPL 814 can determine one or more destination nodes for the data and / or device-specific configuration 636. At operation 1125, the IPL 814 can identify the next node for delivering the data to the destination node in the same or a similar manner as previously discussed. The TPL 816 can generate a message to include the device-specific configuration 636, the address / identifier of the next node, and the device type of the next node, which can occur at operation 1135. At operation 1130, the LCL 818 and / or the PHY 820 can command the modem manager 734 to load an appropriate modem configuration file (e.g., the hub configuration file 777) into the modem 740 to send the data over the hub network at operation 1140. In this example, operation 1135 can occur before, during, or after operation 1130 is executed.

[0199] Some non-limiting examples are provided below.

[0200] Example 1 can include a device to be used as an Internet of Things (IoT) bracket, the device including: an interface abstraction layer for communicating with one or more IoT devices, the IoT bracket being communicatively attached to the one or more IoT devices via respective connections to the one or more IoT devices; a communication circuit for communicatively attaching the IoT bracket to one or more other IoT brackets and an IoT hub; and one or more collection entities for: collecting IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuit; and collecting hardware status data (HSD) from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuit.

[0201] Example 2 can include the device as described in Example 1 and / or some other examples herein, wherein the one or more collection entities include a data plane entity and a control plane entity, and wherein: the data plane entity is for collecting the IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuit; and the control plane entity is for collecting the HSD from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuit.

[0202] Example 3 may include the apparatus as described in Example 1 or 2 and / or some other examples herein, wherein each connection includes a wired connection between the one or more IoT devices and the IoT bracket, a wireless radio link between the one or more IoT devices and the IoT bracket, or a connection between the one or more IoT devices and the IoT bracket via one or more input / output (I / O) pins.

[0203] Example 4 may include the apparatus as described in Example 1 or 2 and / or some other examples herein, wherein the communication circuit is configured to communicatively attach the IoT bracket to the one or more other IoT brackets via a Mesh network and communicatively attach the IoT bracket to the IoT hub via a wireless local area network (WLAN).

[0204] Example 5 may include the apparatus as described in Example 1 or 2 and / or some other examples herein, wherein the communication circuit is configured to communicatively attach the IoT bracket to the one or more other IoT brackets in a fog computing system and communicatively attach the IoT bracket to the IoT hub via a WLAN.

[0205] Example 6 may include the apparatus as described in Example 4 or 5 and / or some other examples herein, wherein the communication circuit is configured to communicate in the Mesh network or the fog computing system using a first wireless communication protocol and communicate in the WLAN using a second wireless communication protocol, wherein the first wireless communication protocol is different from the second wireless communication protocol.

[0206] Example 7 may include the apparatus as described in Example 1 or 2 and / or some other examples herein, wherein the interface abstraction layer is configured to: detect a connection to a new IoT device connected to the IoT bracket; and obtain identification information of the new IoT device, the identification information including a device identifier (ID) of the new IoT device, a device type of the new IoT device, or a manufacturer or vendor of the new IoT device.

[0207] Example 8 may include the apparatus as described in Example 7 and / or some other examples herein, wherein the control plane entity is configured to control the communication circuit to: send a first message including the identification information to the IoT hub; and receive a second message including a data sharing permission from the IoT hub, wherein the data sharing permission includes device pairing information and user management information, wherein the device pairing information indicates one or more IoT devices permitted to obtain the IoT data generated by the new IoT device and one or more IoT devices permitted to access the hardware resources of the new IoT device, and wherein the user management information indicates one or more client devices permitted to obtain the IoT data generated by the new IoT device and one or more client devices permitted to access the hardware resources of the new IoT device.

[0208] Example 9 may include the apparatus as described in Example 2 and / or some other examples herein, further including an installation engine configured to implement an installation process to communicatively attach the IoT bracket to the IoT hub, wherein, to implement the installation process, the installation engine is configured to: initialize a pairing mode, wherein the pairing mode is initialized when the IoT bracket is powered on or in response to receiving an instruction to enter the pairing mode; broadcast a unique ID of the IoT bracket to the one or more other IoT brackets and the IoT hub; establish an end-to-end encrypted tunnel with the IoT hub in response to receiving a message from the IoT hub based on the unique ID; and control the communication circuit to send a bracket capability message indicating the platform of the IoT bracket, one or more supported communication protocols, and identification information of one or more IoT devices attached to the IoT bracket to the IoT hub through the end-to-end encrypted tunnel, wherein the identification information of each of the one or more IoT devices includes a device ID, a device type, and an IoT device manufacturer or vendor.

[0209] Example 10 may include the apparatus as described in Example 9 and / or some other examples herein, wherein the installation engine is used to control the communication circuit to: receive a routing information base (RIB) from the IoT hub through the end-to-end encryption tunnel, where the RIB indicates the routes for transmitting the IoT data and the HSD to each IoT bracket among the one or more other IoT brackets and the routes for transmitting the IoT data and the HSD to the IoT hub, wherein the data plane entity is used to provide the collected IoT data to each IoT bracket or the IoT hub via the communication circuit according to the routes indicated by the RIB, and wherein the control plane entity is used to provide the collected HSD to each IoT bracket or the IoT hub via the communication circuit according to the routes indicated by the RIB.

[0210] Example 11 may include the apparatus as described in any one of Examples 1-10 and / or some other examples herein, wherein the communication circuit includes a configurable modem circuit, and wherein the configurable modem circuit includes a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), an application specific integrated circuit (ASIC), a structured ASIC, or a programmable system on chip (PSoC).

[0211] Example 12 may include the apparatus as described in Example 11 and / or some other examples herein, wherein the apparatus further includes a modem manager for loading a first modem profile for transmitting the IoT data or the HSD through a first network and a second modem profile for transmitting the IoT data or the HSD through a second network into the configurable modem circuit, and wherein the one or more collection entities are used to command the modem manager to load the first modem profile or the second modem profile into the configurable modem circuit.

[0212] Example 13 may include the apparatus as described in Example 11 and / or some other examples herein, wherein the one or more IoT devices include one or more sensors or one or more electromechanical devices.

[0213] Example 14 may include an apparatus to be used as an Internet of Things (IoT) hub in a Mesh network or a fog computing environment. The apparatus includes: a physical layer for transmitting IoT data and / or hardware status data (HSD) to / from each IoT bracket via a first network according to the policy configuration of each IoT device, and transmitting the IoT data and / or the HSD to a client device via a second network, where each IoT bracket obtains the IoT data and the HSD from each IoT device communicatively attached thereto, and where the IoT data indicates data associated with events detected by the each IoT device, and the HSD is used to facilitate access to the hardware resources of the each IoT device; a policy layer for implementing the policy configuration of the each IoT bracket, where the policy configuration indicates the devices permitted to access the IoT data or the HSD.

[0214] Example 15 may include the apparatus as described in Example 14 and / or some other examples herein. The apparatus further includes an application interface for: hosting an application (app) that includes one or more interfaces through which the client device accesses the hardware resources of the each IoT device and one or more interfaces through which the client device defines the policy configuration to be implemented by the policy layer.

[0215] Example 16 may include the apparatus as described in Example 15 and / or some other examples herein. The apparatus further includes an application layer (AL) for: hosting respective plugins corresponding to the each IoT device, where the respective plugins indicate parameters for presenting the IoT data and the HSD to the app and parameters for providing user data to the each IoT device, and where the user data is obtained from the app via the application interface.

[0216] Example 17 may include the apparatus as described in Example 16 and / or some other examples herein. The apparatus further includes an Internet protocol layer (IPL) that includes the policy layer, where the IPL is for: encapsulating the IoT data and the HSD for delivery to the AL; and encapsulating the user data obtained from the app for delivery to the each IoT device via the each IoT bracket.

[0217] Example 18 may include the apparatus as described in Example 17 and / or some other examples herein, wherein the apparatus further includes a Transmission Protocol Layer (TPL) for: providing a flow control function for the IoT data and the HSD transmitted between the client device and the one or more IoT devices according to the policies implemented by the Policy Layer; determining the current state, current preferences, and current configurations of the respective IoT devices based on the HSD or the IoT data; generating a State, Preferences, and Configuration Set (SPC) for the respective IoT devices; and providing the generated SPC to the IPL.

[0218] Example 19 may include the apparatus as described in Example 18 and / or some other examples herein, wherein the apparatus further includes a Link Control Layer (LCL) for: establishing a flow of protocol data units (PDUs) for the HSD or the IoT data; allocating flow parameters to the established flow based on the data type of the flow, wherein the data type indicates whether the packets of the flow carry the HSD or the IoT data; and wherein the flow parameters include the flow class of the flow, the flow priority of the flow, quality of service (QoS) parameters for the HSD or IoT data, the network type to be used for transmitting the HSD or IoT data, the traffic type for the flow, and the data type of the flow.

[0219] Example 20 may include the apparatus as described in Example 19 and / or some other examples herein, wherein the Physical Layer is for: indicating physical information to the LCL, the TPL, the IPL, or the AL, wherein the physical information includes attachment information indicating how the respective IoT devices are communicatively attached to the respective IoT brackets and power information indicating how the respective IoT devices are powered.

[0220] Example 21. The apparatus as described in any one of Examples 14 - 20 and / or some other examples herein, wherein the first network includes a first communication protocol and the second network includes a second communication protocol, wherein the first communication protocol is different from the second communication protocol.

[0221] Example 22 may include the apparatus as described in Example 21 and / or some other examples herein, wherein the apparatus further includes communication circuitry for implementing the Physical Layer, wherein the communication circuitry includes: a first transceiver for transmitting the IoT data and / or the HSD through the first network according to the first communication protocol; and a second transceiver for transmitting the IoT data and / or the HSD through the second network according to the second communication protocol, and wherein the first communication protocol and the second communication protocol are different wireless communication protocols.

[0222] Example 23 may include a device as described in Example 21 and / or some other examples herein, wherein the device further includes a communication circuit and a network interface circuit (NIC) for implementing the physical layer, wherein the communication circuit includes a transceiver for transmitting the IoT data and / or the HSD via the first network according to the first communication protocol, and the NIC is for transmitting the IoT data and / or the HSD via the second network according to the second communication protocol, wherein the first communication protocol is a wireless communication protocol, and the second communication protocol is a wired communication protocol.

[0223] Example 24 may include a device as described in Example 24 and / or some other examples herein, wherein the communication circuit includes a configurable modem circuit, and the device further includes a modem manager for loading a first modem configuration file for transmitting the IoT data or the HSD via a first network and a second modem configuration file for transmitting the IoT data or the HSD via a second network into the configurable modem circuit, wherein the one or more collection entities are for commanding the modem manager to load the first modem configuration file or the second modem configuration file into the configurable modem circuit, and wherein the configurable modem circuit is a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), an application specific integrated circuit (ASIC), a structured ASIC, or a programmable system-on-chip (PSoC).

[0224] Example 25 may include a device as described in Example 24 and / or some other examples herein, wherein the one or more IoT devices include one or more sensors or one or more electromechanical devices.

[0225] Example 26 may include a method to be performed by an Internet of Things (IoT) rack, the method including: collecting, by the IoT rack via an interface abstraction layer, IoT data and / or hardware status data (HSD) from IoT devices communicatively attached to the IoT rack; sending, by the IoT rack, the collected IoT data and / or HSD to one or more other IoT racks via a first network; and sending, by the IoT rack, the collected IoT data and / or HSD to an IoT hub via a second network.

[0226] Example 27 may include the method as described in Example 26 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the one or more other IoT brackets includes: operating a data plane entity to send the collected IoT data to the one or more other IoT brackets via the first network; and operating a control plane entity to send the collected HSD to the one or more other IoT brackets via the first network.

[0227] Example 28 may include the method as described in Example 27 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the IoT hub includes: operating the data plane entity to send the collected IoT data to the IoT hub via the second network; and operating the control plane entity to send the collected HSD to the IoT hub via the second network.

[0228] Example 29 may include the method as described in Example 26 and / or some other examples herein, further including: identifying, by the IoT bracket, a policy for sending the collected IoT data and / or HSD based on a configuration associated with each IoT device; and implementing, by the IoT bracket, the policy.

[0229] Example 30 may include the method as described in Example 29 and / or some other examples herein, wherein implementing the policy includes: identifying, by the IoT device, an IoT device that is not allowed to obtain the collected IoT data or the collected HSD as indicated by the policy; and blocking the sending to an IoT bracket communicatively attached to the identified IoT device among the one or more IoT brackets.

[0230] Example 31 may include the method as described in Example 26 and / or some other examples herein, further including: determining, by the IoT bracket, a destination node for obtaining the IoT data and / or the HSD; and determining, by the IoT bracket, a next node for sending the IoT data and / or the HSD to be transmitted to the destination node.

[0231] Example 32 may include the method as described in Example 31 and / or some other examples herein, wherein determining the next node includes: performing a lookup operation on a routing information base by the IoT bracket using an identifier of the destination node.

[0232] Example 33 may include a method as described in Example 32 and / or some other examples herein, wherein determining the destination node includes: identifying, by the IoT carriage, a destination node identifier indicated by the IoT device information, wherein the IoT device information is indicated by the IoT data and / or the HSD, or the IoT device information is indicated by a configuration associated with each IoT device.

[0233] Example 34. A method as described in any one of Examples 26-28 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the one or more other IoT carriages includes: configuring, by the IoT carriage, a configurable modem circuit with a modem profile for sending data over the first network, wherein the modem profile indicates a wireless communication protocol of the first network.

[0234] Example 35 may include a method as described in Example 34 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the IoT hub includes: configuring, by the IoT carriage, the configurable modem circuit with another modem profile for sending data over the second network, wherein the another modem profile indicates a wireless communication protocol of the second network.

[0235] Example 36 may include a method to be performed by an Internet of Things (IoT) hub, the method including: receiving, by the IoT hub via a hub network, IoT data and / or hardware status data (HSD) from each IoT carriage, wherein the IoT data and the HSD are generated by each IoT device communicatively attached to each IoT carriage; sending, by the IoT hub via the hub network, the collected IoT data and / or HSD to each other IoT carriage; and sending, by the IoT hub via the hub network or a cloud network, the collected IoT data and / or HSD to a client device.

[0236] Example 37 may include a method as described in Example 36 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the each IoT carriage includes: encapsulating, by the IoT hub, the IoT data and / or the HSD based on a plugin associated with each other IoT device and a policy associated with each IoT device for consumption by each other IoT device attached to the each other IoT carriage.

[0237] Example 38 may include the method as described in Example 36 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the client device includes: encapsulating, by the IoT hub, the IoT data and / or the HSD for consumption by the client device based on a plug-in associated with each IoT device that generates the IoT data and / or the HSD and a policy associated with each IoT device.

[0238] Example 39 may include the method as described in Example 36 and / or some other examples herein, further including: identifying, by the IoT hub, a policy for sending the collected IoT data and / or HSD based on a configuration associated with each IoT device; and implementing, by the IoT hub, the policy.

[0239] Example 40 may include the method as described in Example 39 and / or some other examples herein, wherein implementing the policy includes: identifying, by the IoT hub, an IoT device that is not permitted to obtain the collected IoT data or the collected HSD as indicated by the policy; and blocking the sending to other IoT brackets communicatively attached to the identified IoT device.

[0240] Example 41 may include the method as described in Example 36 and / or some other examples herein, further including: determining, by the IoT hub, a destination node for obtaining the IoT data and / or the HSD; and determining, by the IoT hub, a next node for sending the IoT data and / or the HSD to be transmitted to the destination node.

[0241] Example 42 may include the method as described in Example 41 and / or some other examples herein, wherein determining the next node includes: performing, by the IoT hub, a lookup operation on a routing information base using an identifier of the destination node.

[0242] Example 43 may include the method as described in Example 42 and / or some other examples herein, wherein determining the destination node includes: identifying, by the IoT hub, a destination node identifier indicated by the IoT device information, wherein the IoT device information is indicated by the IoT data and / or the HSD, or the IoT device information is indicated by a configuration associated with each IoT device.

[0243] Example 44. The method as described in any one of Examples 36-37 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to each of the IoT brackets includes: configuring, by the IoT hub, a configurable modem circuit with a modem profile for sending data over the hub network, wherein the modem profile indicates the wireless communication protocol of the hub network.

[0244] Example 45 may include the method as described in Example 44 and / or some other examples herein, wherein sending the collected IoT data and / or HSD to the client device includes: configuring, by the IoT bracket, the configurable modem circuit with another modem profile for sending data over the cloud network, wherein the another modem profile indicates the wireless communication protocol of the cloud network.

[0245] Example 46 may include a method for performing a boot installation for an Internet of Things (IoT) bracket, the method including: entering, by the IoT hub, a pairing mode with the IoT bracket; determining, by the IoT hub, whether each IoT device communicatively attached to the IoT bracket needs to boot into the IoT network; and invoking, by the IoT hub, an IoT device boot process when each IoT device needs to boot into the IoT network.

[0246] Example 47 may include the method as described in Example 46 and / or some other examples herein, wherein entering the pairing mode includes: obtaining, by the IoT hub, a unique identifier of the IoT bracket; and establishing, by the IoT hub, an end-to-end encrypted tunnel with the IoT bracket.

[0247] Example 48 may include the method as described in Example 46 and / or some other examples herein, further including: determining, by the IoT hub, the bracket capabilities of the IoT bracket.

[0248] Example 49 may include the method as described in Example 48, wherein determining the bracket capabilities includes: identifying, by the IoT hub, the bracket capabilities from one or more messages exchanged during the process of entering the pairing mode.

[0249] Example 50 may include the method as described in Example 46 and / or some other examples herein, further including: determining, by the IoT hub, based on the bracket capabilities, whether the IoT bracket needs an update; obtaining, by the IoT hub, one or more updated components when it is determined that the IoT bracket needs an update; and provisioning, by the IoT hub, the one or more updated components in the IoT bracket.

[0250] Example 51 may include the method as described in Example 46 and / or some other examples herein, further comprising: determining, by the IoT hub, a route between the IoT hub and the IoT bracket; generating, by the IoT hub, a routing information base for the IoT bracket based on the determined route; and allocating, by the IoT hub, the routing information base in the IoT bracket.

[0251] Example 52 may include one or more computer-readable media including instructions that, when executed, cause an Internet of Things (IoT) hub to perform the method as described in Examples 36-45, 46-51, and / or some other examples herein.

[0252] Example 53 may include a method for performing an Internet of Things (IoT) device startup process, the method comprising: detecting, by the IoT bracket, an IoT device communicatively attached to the IoT bracket; determining, by the IoT bracket, a device pairing configuration for the IoT device; determining, by the IoT bracket, a data sharing configuration for the IoT device; starting, by the IoT bracket, a test cycle for the IoT device; and reporting, by the IoT bracket, a result of the test cycle to the IoT hub.

[0253] Example 54 may include the method as described in Example 53 and / or some other examples herein, further comprising: identifying, by the IoT bracket, IoT device information of the IoT device, wherein the IoT device information includes identification information of the IoT device, and wherein the identification information includes a device identifier of the IoT device, a device type of the IoT device, and an IoT device manufacturer or vendor of the IoT device.

[0254] Example 55 may include the method as described in Example 54 and / or some other examples herein, wherein determining the IoT device information includes: determining, by the IoT bracket, an IoT device capability of the IoT device based on the IoT device information, wherein the IoT device capability indicates a platform of the IoT device, one or more communication protocols supported by the IoT device, and currently installed software components of the IoT device.

[0255] Example 56 may include the method as described in Example 54 and / or some other examples herein, further comprising: determining, by the IoT bracket, whether a plugin associated with the IoT device is currently installed for the IoT device; and obtaining, by the IoT bracket, a plugin associated with the IoT device when the plugin is not currently installed for the IoT device.

[0256] Example 57 may include a method as described in Example 56 and / or some other examples herein, wherein determining whether a plug-in associated with the IoT device is currently installed for the IoT device includes: sending, by the IoT cradle, the IoT device information to an IoT hub; and receiving, by the IoT cradle, an indication from the IoT hub as to whether the IoT hub currently includes the plug-in.

[0257] Example 58 may include a method as described in Example 57 and / or some other examples herein, wherein when the plug-in is not currently installed for the IoT device, obtaining the plug-in associated with the IoT device: receiving, by the IoT cradle, another indication from the IoT hub that the IoT hub has obtained and installed the plug-in at the IoT hub.

[0258] Example 59 may include a method as described in Example 55 and / or some other examples herein, wherein: the device pairing configuration indicates whether the IoT device is to be paired or combined with one or more other IoT devices for operation to provide a desired function or a desired service; and the data sharing configuration indicates other devices with which the IoT device is to share IoT data and / or hardware status data (HSD).

[0259] Example 60 may include a method as described in Example 59 and / or some other examples herein, wherein the device pairing configuration and the data sharing configuration are indicated by the IoT device capabilities or by a user via an application for configuring the IoT device.

[0260] Example 61 may include one or more computer-readable media including instructions that, when executed, cause an Internet of Things (IoT) cradle to perform a method as described in Examples 26 - 35, 53 - 60, and / or some other examples herein.

[0261] Example 62 may include a device to be used as an Internet of Things (IoT) bracket, the device including: an interface module for communicating with one or more IoT devices, the IoT bracket being communicatively attached to the one or more IoT devices via respective connections with the one or more IoT devices; a communication module for communicating with one or more other IoT brackets and an IoT hub; and a collection module for: collecting IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuitry; and collecting hardware status data (HSD) from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuitry.

[0262] Example 63 may include the device as described in Example 62 and / or some other examples herein, wherein the collection module includes a data plane module and a control plane module, and wherein: the data plane module is for collecting the IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuitry; and the control plane module is for collecting the HSD from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuitry.

[0263] Example 64 may include the device as described in Example 62 or 63 and / or some other examples herein, wherein the respective connections include a wired connection between the one or more IoT devices and the IoT bracket, a wireless radio link between the one or more IoT devices and the IoT bracket, or a connection between the one or more IoT devices and the IoT bracket via one or more input / output (I / O) pins.

[0264] Example 65 may include the device as described in Example 62 or 63 and / or some other examples herein, wherein the communication module is for communicating with the one or more other IoT brackets via a Mesh network and for communicating with the IoT hub via a wireless local area network (WLAN).

[0265] Example 66 may include the device as described in Example 62 or 63 and / or some other examples herein, wherein the communication module is for communicating with the one or more other IoT brackets in a fog computing system and for communicating with the IoT hub via a WLAN.

[0266] Example 67 may include the apparatus as described in Example 65 or 66 and / or some other examples herein, wherein the communication module is configured to communicate in the Mesh network or the fog computing system using a first wireless communication protocol and communicate in the WLAN using a second wireless communication protocol, wherein the first wireless communication protocol is different from the second wireless communication protocol.

[0267] Example 68 may include the apparatus as described in Example 62 or 63 and / or some other examples herein, wherein the interface module is configured to: detect a connection to a new IoT device connected to the IoT bracket; and obtain identification information of the new IoT device, the identification information including a device identifier (ID) of the new IoT device, a device type of the new IoT device, or a manufacturer or vendor of the new IoT device.

[0268] Example 69 may include the apparatus as described in Example 68 and / or some other examples herein, wherein the communication module is configured to: send a first message including the identification information to the IoT hub; and receive a second message including a data sharing permission from the IoT hub, wherein the data sharing permission includes device pairing information and user management information, wherein the device pairing information indicates one or more IoT devices permitted to obtain IoT data generated by the new IoT device and one or more IoT devices permitted to access hardware resources of the new IoT device, and wherein the user management information indicates one or more client devices permitted to obtain the IoT data generated by the new IoT device and one or more client devices permitted to access hardware resources of the new IoT device.

[0269] Example 70 may include the apparatus as described in Example 63 and / or some other examples herein, further including an installation module configured to: initialize a pairing mode, wherein the pairing mode is initialized when the IoT bracket is powered on or in response to receiving an instruction to enter the pairing mode; broadcast a unique ID of the IoT bracket to the one or more other IoT brackets and the IoT hub; establish an end-to-end encrypted tunnel with the IoT hub in response to receiving a message from the IoT hub based on the unique ID; and control the communication module to send a bracket capability message indicating a platform of the IoT bracket, one or more supported communication protocols, and identification information of one or more IoT devices attached to the IoT bracket to the IoT hub through the end-to-end encrypted tunnel, wherein the identification information of each of the one or more IoT devices includes a device ID, a device type, and an IoT device manufacturer or vendor.

[0270] Example 71 may include a device as described in Example 70 and / or some other examples herein, wherein: the communication module is configured to: receive a routing information base (RIB) from the IoT hub through the end-to-end encrypted tunnel, wherein the RIB indicates routes for transmitting the IoT data and the HSD to each IoT bracket among the one or more other IoT brackets and routes for transmitting the IoT data and the HSD to the IoT hub; the data plane module is configured to: via the communication circuit, provide the collected IoT data to each IoT bracket or the IoT hub according to the routes indicated by the RIB; and the control plane module is configured to: via the communication circuit, provide the collected HSD to each IoT bracket or the IoT hub according to the routes indicated by the RIB.

[0271] Example 72 may include a device to be used as an Internet of Things (IoT) hub, the device including: a communication module configured to communicate IoT data and / or hardware status data (HSD) with each IoT bracket through a first network and communicate the IoT data and / or the HSD with a client device through a second network according to the policy configuration of each IoT device, wherein each IoT bracket obtains the IoT data and the HSD from each IoT device to which they are communicatively attached, and wherein the IoT data indicates data associated with events detected by the each IoT device, and the HSD is used to facilitate access to the hardware resources of the each IoT device; a policy enforcement module configured to enforce the policy configuration of each IoT bracket, wherein the policy configuration indicates devices permitted to access the IoT data or the HSD.

[0272] Example 74 may include a device as described in Example 72 and / or some other examples herein, wherein the device further includes an application interface module configured to: host an application (app) that includes one or more interfaces through which the client device accesses the hardware resources of the each IoT device, and provide one or more interfaces through which the client device defines the policy configuration to be enforced by the policy layer.

[0273] Example 75 may include a device as described in Example 74 and / or some other examples herein, wherein the device further includes an application module configured to: host each plug-in corresponding to each IoT device, wherein each plug-in indicates parameters for presenting the IoT data and the HSD to the app and parameters for providing user data to the each IoT device, wherein the user data is obtained from the app via the application interface.

[0274] Example 76 may include a device as described in Example 75 and / or some other examples herein, wherein the device further includes an Internet Protocol (IP) module including the policy enforcement module, the IP module for: encapsulating the IoT data and the HSD for delivery to the AL; and encapsulating the user data obtained from the app for delivery to the respective IoT devices via the respective IoT brackets.

[0275] Example 77 may include a device as described in Example 76 and / or some other examples herein, wherein the device further includes a transport protocol module for: providing a flow control function for the IoT data and the HSD transmitted between the client device and the one or more IoT devices according to the policies enforced by the policy layer; determining the current state, current preferences, and current configuration of each IoT device based on the HSD or the IoT data; generating a state, preference, and configuration set (SPC) for each IoT device; and providing the generated SPC to the IPL.

[0276] Example 78 may include a device as described in Example 77 and / or some other examples herein, wherein the device further includes a link control module for: establishing a flow of protocol data units (PDUs) for the HSD or the IoT data; allocating flow parameters to the established flow based on the data type of the flow, where the data type indicates whether the packets of the flow carry the HSD or the IoT data; and wherein the flow parameters include the flow class of the flow, the flow priority of the flow, quality of service (QoS) parameters for the HSD or IoT data, the network type to be used for transmitting the HSD or IoT data, the traffic type for the flow, and the data type of the flow.

[0277] Example 79 may include a device as described in Example 78 and / or some other examples herein, wherein the communication module is for: indicating physical information to the link control module, the transport protocol module, the IP module, or the application module, where the physical information includes attachment information indicating how the respective IoT devices are communicatively attached to the respective IoT brackets and power information indicating how the respective IoT devices are powered.

[0278] Example 80 may include a device as described in any of Examples 72-79 and / or some other examples herein, wherein the first network includes a first communication protocol, and the second network includes a second communication protocol, wherein the first communication protocol is different from the second communication protocol, wherein the communication module includes: a first communication module for transmitting the IoT data and / or the HSD through the first network according to the first communication protocol; and a second communication module for transmitting the IoT data and / or the HSD through the second network according to the second communication protocol, wherein the first communication protocol and the second communication protocol are different wireless communication protocols, or the first communication protocol is a wireless communication protocol and the second communication protocol is a wired communication protocol.

[0279] Example 81 may include a device to be used as an Internet of Things (IoT) bracket, the device including: a collection module for collecting IoT data and / or hardware status data (HSD) from each IoT device communicatively attached to the IoT bracket; a first communication module for sending the collected IoT data and / or HSD to one or more other IoT brackets through a first network; and a second communication module for sending the collected IoT data and / or HSD to an IoT hub through a second network.

[0280] Example 82 may include a device as described in Example 81 and / or some other examples herein, wherein the collection module includes: a data plane module for sending the collected IoT data to the one or more other IoT brackets through the first network; and a control plane module for sending the collected HSD to the one or more other IoT brackets through the first network.

[0281] Example 83 may include a device as described in Example 82 and / or some other examples herein, wherein the collection module includes: a data plane module for sending the collected IoT data to the IoT hub through the second network; and a control plane module for sending the collected HSD to the IoT hub through the second network.

[0282] Example 84 may include a device as described in Example 81 and / or some other examples herein, further including: a module for identifying a policy for sending the collected IoT data and / or HSD based on a configuration associated with each IoT device; and a module for implementing the policy.

[0283] Example 85 may include an apparatus as described in Example 84 and / or some other examples herein, wherein the module for implementation includes: a module for identifying IoT devices that are not permitted to obtain the collected IoT data or the collected HSD as indicated by the policy; and a module for blocking the transmission to the IoT brackets communicatively attached to the identified IoT devices among the one or more IoT brackets.

[0284] Example 86 may include an apparatus as described in Example 81 and / or some other examples herein, further including: a module for determining a destination node for obtaining the IoT data and / or the HSD; and a module for determining a next node for transmitting the IoT data and / or the HSD to be transmitted to the destination node.

[0285] Example 87 may include an apparatus as described in Example 86 and / or some other examples herein, wherein the module for determining the next node includes: a module for performing a lookup operation on a routing information base using an identifier of the destination node.

[0286] Example 88 may include an apparatus as described in Example 87 and / or some other examples herein, wherein the module for determining the destination node includes: a module for identifying a destination node identifier indicated by the IoT device information, wherein the IoT device information is indicated by the IoT data and / or the HSD, or the IoT device information is indicated by a configuration associated with each IoT device.

[0287] Example 89 may include an apparatus as described in any one of Examples 81-83 and / or some other examples herein, wherein the first communication module includes: a module for configuring a configurable modem circuit with a configuration file for transmitting data over the first network, wherein the configuration file indicates a wireless communication protocol of the first network.

[0288] Example 90 may include an apparatus as described in Example 89 and / or some other examples herein, wherein the second communication module includes: a module for configuring the configurable modem circuit with another configuration file for transmitting data over the second network, wherein the another configuration file indicates a wireless communication protocol of the second network.

[0289] Example 91 may include the apparatus as described in Examples 81 - 90 and / or some other examples herein, further including a device startup module for: detecting an IoT device communicatively attached to the IoT bracket; determining a device pairing configuration for the IoT device; determining a data sharing configuration for the IoT device; and initiating a test cycle for the IoT device; and reporting the results of the test cycle to an IoT hub.

[0290] Example 92 may include the apparatus as described in Example 91 and / or some other examples herein, wherein the device startup module is for: identifying IoT device information of the IoT device, where the IoT device information includes identification information of the IoT device, and the identification information includes a device identifier of the IoT device, a device type of the IoT device, and an IoT device manufacturer or supplier of the IoT device.

[0291] Example 93 may include the apparatus as described in Example 92 and / or some other examples herein, wherein in determining the IoT device information, the device startup module is for: based on the IoT device information, determining IoT device capabilities of the IoT device, where the IoT device capabilities indicate a platform of the IoT device, one or more communication protocols supported by the IoT device, and currently installed software components of the IoT device.

[0292] Example 94 may include the apparatus as described in Example 92 and / or some other examples herein, wherein the device startup module is for: determining whether a plugin associated with the IoT device is currently installed for the IoT device; and when the plugin is not currently installed for the IoT device, obtaining the plugin associated with the IoT device.

[0293] Example 95 may include the apparatus as described in Example 94 and / or some other examples herein, wherein in determining whether a plugin associated with the IoT device is currently installed for the IoT device, the device startup module is for: causing the IoT device information to be sent to an IoT hub; and causing an indication of whether the IoT hub currently includes the plugin to be received from the IoT hub.

[0294] Example 96 may include the apparatus as described in Example 95 and / or some other examples herein, wherein in obtaining the plugin associated with the IoT device when the plugin is not currently installed for the IoT device, the device startup module is for: causing another indication that the IoT hub has obtained and installed the plugin at the IoT hub to be received from the IoT hub.

[0295] Example 97 may include a device as described in Example 93 and / or some other examples herein, wherein the device pairing configuration indicates whether the IoT device is to be paired or combined with one or more other IoT devices for operation to provide a desired function or a desired service.

[0296] Example 98 may include a device as described in Example 97 and / or some other examples herein, wherein the device pairing configuration is indicated by the IoT device capabilities or by a user via an application for configuring the IoT device.

[0297] Example 99 may include a device as described in Example 93 and / or some other examples herein, wherein the data sharing configuration indicates other devices with which the IoT device is to share IoT data and / or hardware status data (HSD).

[0298] Example 100 may include a device as described in Example 99, wherein the data sharing configuration is indicated by the IoT device capabilities or by a user via an application for configuring the IoT device.

[0299] Example 101 may include a device to be used as an Internet of Things (IoT) hub, the device including: a first communication module for: receiving, by the IoT hub via a hub network, IoT data and / or hardware status data (HSD) from each IoT bracket, wherein the IoT data and the HSD are generated by respective IoT devices communicatively attached to the respective IoT brackets; and sending the collected IoT data and / or HSD to other respective IoT brackets via the hub network; and a second communication module for: sending the collected IoT data and / or HSD to a client device via the hub network or a cloud network.

[0300] Example 102 may include a device as described in Example 101 and / or some other examples herein, further including: a module for: encapsulating the IoT data and / or the HSD for consumption by other respective IoT devices attached to the other respective IoT brackets, based on plugins associated with the other respective IoT devices and policies associated with the respective IoT devices.

[0301] Example 103 may include a device as described in Example 101 and / or some other examples herein, further including: a module for: encapsulating the IoT data and / or the HSD for consumption by the client device, based on plugins associated with the respective IoT devices that generate the IoT data and / or the HSD and policies associated with the respective IoT devices.

[0302] Example 104 may include the apparatus as described in Example 101, further comprising: a module for identifying a policy for sending the collected IoT data and / or HSD based on a configuration associated with each of the IoT devices; and a module for implementing the policy.

[0303] Example 105 may include the apparatus as described in Example 104 and / or some other examples herein, wherein the module for implementing the policy is configured to: identify IoT devices that are not permitted to obtain the collected IoT data or the collected HSD as indicated by the policy; and block the transmission to the other IoT brackets communicatively attached to the identified IoT devices.

[0304] Example 106 may include the apparatus as described in Example 101 and / or some other examples herein, further comprising: a module for determining a destination node for obtaining the IoT data and / or the HSD; and a module for determining a next node for sending the IoT data and / or the HSD to be transmitted to the destination node.

[0305] Example 107 may include the apparatus as described in Example 106 and / or some other examples herein, wherein the module for determining the next node is configured to: perform a lookup operation on a routing information base using an identifier of the destination node.

[0306] Example 108 may include the apparatus as described in Example 107 and / or some other examples herein, wherein the module for determining the destination node is configured to: identify a destination node identifier indicated by the IoT device information, where the IoT device information is indicated by the IoT data and / or the HSD, or the IoT device information is indicated by a configuration associated with each of the IoT devices.

[0307] Example 109 may include the apparatus as described in any one of Examples 101-102 and / or some other examples herein, wherein the first communication module is configured to: configure a configurable modem circuit with a configuration file for sending data over the hub network, where the configuration file indicates a wireless communication protocol of the hub network.

[0308] Example 110 may include the apparatus as described in Example 109 and / or some other examples herein, wherein the second communication module is configured to: configure the configurable modem circuit with another configuration file for sending data over the cloud network, where the another configuration file indicates a wireless communication protocol of the cloud network.

[0309] Example 111 may include the apparatus as described in Examples 101 - 110 and / or some other examples herein, further including an installation module configured to: enter a pairing mode with the IoT bracket; determine whether each IoT device communicatively attached to the IoT bracket needs to be initiated into the IoT network; and invoke an IoT device initiation process when each IoT device needs to be initiated into the IoT network.

[0310] Example 112 may include the apparatus as described in Example 111 and / or some other examples herein, wherein the installation module is configured to: obtain a unique identifier of the IoT bracket; and establish an end - to - end encrypted tunnel with the IoT bracket.

[0311] Example 113 may include the apparatus as described in Example 111 and / or some other examples herein, wherein the installation module is configured to: determine the bracket capabilities of the IoT bracket.

[0312] Example 114 may include the apparatus as described in Example 113 and / or some other examples herein, wherein, in determining the bracket capabilities, the installation module is configured to: identify the bracket capabilities from one or more messages exchanged during the process of entering the pairing mode.

[0313] Example 115 may include the apparatus as described in Example 111 and / or some other examples herein, wherein the installation module is configured to: determine whether the IoT bracket needs an update based on the bracket capabilities; obtain one or more updated components when it is determined that the IoT bracket needs an update; and allocate the one or more updated components in the IoT bracket.

[0314] Example 116 may include the apparatus as described in Example 111 and / or some other examples herein, wherein the installation module is configured to: determine a route between the IoT hub and the IoT bracket; generate a routing information base for the IoT bracket based on the determined route; and allocate the routing information base in the IoT bracket.

[0315] Although specific embodiments have been shown and described for purposes of illustration herein, various alternative and / or equivalent embodiments or implementations that are considered to achieve the same purpose may replace the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any alterations or variations of the embodiments discussed herein as defined solely by the claims.

Claims

1. An apparatus for use as an Internet of Things (IoT) bracket, the apparatus comprising: An interface abstraction layer for communicating with one or more IoT devices, the IoT bracket being communicatively attached to the one or more IoT devices via respective connections to the one or more IoT devices; A communication circuit for communicatively attaching the IoT bracket to one or more other IoT brackets and an IoT hub; And One or more collection entities for: Collecting IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuit; And Collecting hardware status data (HSD) from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuit, Wherein the one or more collection entities include a data plane entity and a control plane entity, and wherein: The data plane entity is for: collecting the IoT data from the one or more IoT devices via the interface abstraction layer and providing the collected IoT data to one or more other IoT brackets or the IoT hub via the communication circuit; and The control plane entity is for: collecting the HSD from the one or more IoT devices via the interface abstraction layer and providing the collected HSD to the one or more other IoT brackets or the IoT hub via the communication circuit.

2. The device according to claim 1, wherein, The respective connections include a wired connection between the one or more IoT devices and the IoT bracket, a wireless radio link between the one or more IoT devices and the IoT bracket, or a connection between the one or more IoT devices and the IoT bracket via one or more input / output (I / O) pins.

3. The device according to claim 1, wherein, The communication circuit is for: Communicatively attaching the IoT bracket to the one or more other IoT brackets via a Mesh network and communicatively attaching the IoT bracket to the IoT hub via a wireless local area network (WLAN).

4. The apparatus according to claim 3, wherein, The communication circuit is for: Communicatively attaching the IoT bracket to the one or more other IoT brackets in a fog computing system and communicatively attaching the IoT bracket to the IoT hub via a WLAN.

5. The apparatus according to claim 4, wherein The communication circuit is for: Communicating in the Mesh network or the fog computing system using a first wireless communication protocol and communicating in the WLAN using a second wireless communication protocol, wherein the first wireless communication protocol is different from the second wireless communication protocol.

6. The device according to any one of claims 1-5, wherein, The communication circuit includes a configurable modem circuit, where the configurable modem circuit includes a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), an application specific integrated circuit (ASIC), a structured ASIC, or a programmable system on chip (PSoC).

7. The apparatus according to claim 6, wherein, The device further includes a modem manager for: loading a first modem configuration file for transmitting the IoT data or the HSD via a first network and a second modem configuration file for transmitting the IoT data or the HSD via a second network into the configurable modem circuit, where the one or more collection entities are for: commanding the modem manager to load the first modem configuration file or the second modem configuration file into the configurable modem circuit.

8. A device to be used as an Internet of Things (IoT) hub in a Mesh network or a fog computing environment, the device comprising: A physical layer for: configuring according to the policies of each IoT device, transmitting IoT data and / or hardware status data (HSD) to each IoT bracket via a first network, and transmitting the IoT data and / or the HSD to a client device via a second network, where each IoT bracket obtains the IoT data and the HSD from each IoT device to which they are communicatively attached, and where the IoT data indicates data associated with events detected by each IoT device, and the HSD is for facilitating access to the hardware resources of each IoT device; A policy layer for implementing the policy configuration of each IoT bracket, where the policy configuration indicates the devices permitted to access the IoT data or the HSD, where the IoT bracket uses the device as described in claim 1.

9. The device according to claim 8, wherein, The device further includes an application interface for: hosting an application (app), the application including one or more interfaces through which the client device accesses the hardware resources of each IoT device and one or more interfaces through which the client device defines the policy configuration to be implemented by the policy layer.

10. The device according to claim 9, wherein, The device further includes an application layer (AL), the AL for: hosting respective plugins corresponding to each IoT device, where the respective plugins indicate parameters for presenting the IoT data and the HSD to the app and parameters for providing user data to each IoT device, where the user data is obtained from the app via the application interface.

11. The device according to claim 10, wherein, The device further includes an Internet protocol layer (IPL) including the policy layer, the IPL for: encapsulating the IoT data and the HSD for delivery to the AL; and encapsulating the user data obtained from the app for delivery to each IoT device via each IoT bracket.

12. The apparatus according to claim 11, wherein The device further includes a transport protocol layer (TPL) for: Provide a flow control function for the IoT data and the HSD transmitted between the client device and the one or more IoT devices according to the policies implemented by the policy layer; Determine the current state, current preferences, and current configurations of each IoT device based on the HSD or the IoT data; Generate a set SPC of states, preferences, and configurations for each IoT device; And Provide the generated SPC to the IPL.

13. The apparatus according to claim 12, wherein, The apparatus further includes a link control layer LCL for: Establish a flow of protocol data units PDU for the HSD or the IoT data; Allocate flow parameters to the established flow based on the data type of the flow, where the data type indicates whether the packets of the flow are transporting the HSD or the IoT data; and Wherein the flow parameters include the flow class of the flow, the flow priority of the flow, quality of service QoS parameters for the HSD or IoT data, the network type to be used to transport the HSD or IoT data, the traffic type for the flow, and the data type of the flow.

14. The device according to claim 13, wherein, The physical layer is for: Indicate physical information to the LCL, the TPL, the IPL, or the AL, where the physical information includes attachment information indicating how each IoT device is communicatively attached to each IoT bracket and power information indicating how each IoT device is powered.

Images