Claims:We Claim:
1. A Communication method for operating an Internet of Things system, the method comprising:
(i) establishing communication between Sensor Gateway 102 and Central Controller 101;
(ii) establishing communication between Sensor Gateway 102 and Sensor Device 103;
(iii) establishing communication between Central Controller 101 and Sensor Device 103 through the Sensor Gateway 102;
wherein the Sensor Device 103 obtains its identification from the pre-configured identification tokens available with the Central Controller.

2. The Communication method as claimed in claim 1 wherein the Sensor Gateway 102 and Sensor Device 103 are paired while being in physical proximity of each other and pressing the pairing buttons simultaneously.

3. The Communication method as claimed in claim 1 wherein the Sensor Gateway 102 sends the new ID along with its own credentials and the public key to the Sensor Device to be used for encoding.

4. The Communication method as claimed in claim 1 wherein the Sensor Device 103 acknowledges identification token and public key from the Sensor Gateway 102.

5. The Communication method as claimed in claim 1 wherein the Sensor Gateway 102 notifies the Central Controller 101 regarding the addition of new Sensor Device 103.

6. The Communication method as claimed in claim 1 wherein the length of message sent by the Sensor Device 103 to the Central Controller 101 is always 80 bits.

7. The Communication method message as claimed in claim 6 wherein the message has 32 bits for Sensor Device identification, 16 bits for Sensor Gateway identification, 16 bits for sensor value and 16 bits for metadata checksum.

8. The Communication method message as claimed in claim 6 wherein the message is scrambled with a constant key of 10 bytes.

9. The Communication method as claimed in claim 1 wherein the Sensor Device identification token is returned to the pool of tokens in the Central Controller 101 when a Sensor Device 103 is unpaired from the Sensor Gateway 102.
, Description:Field of Invention and Use of Invention:

The invention relates to communications protocols and more particularly relates to a protocol for exchanging messages between the Internet of Thing (IOT) Servers, IOT Gateways and IOT sensors.

The invention is used for communication between the three layers of IOT architecture. The invention provides a robust and scalable communication method without any service disruption while adding thousands of sensors or gateways to the IOT system.

Prior Art and problem to be solved:

The Internet of Things is a network of sensors, control devices, software application and communication technology. The IoT involves three major steps: capturing of data via sensors, collection of data at a central server, analyzing the data, decision based on data and conveying the decision to actuators.

The IoT essentially comprises of three layers – the Sensor Layer, the Communication Layer and the Application Layer, all interacting with each other simultaneously. The Sensor Layer comprises of sensors to detect and capture the physical parameter to be monitored or controlled. The Communication Layer comprises of network Study of the prior art reveals that every invention has solved only a portion of the IoT problem focusing only on one or two of the three layers. Some of the prior art has tried to solve problems related to all the three layers but have failed to address the core issue of optimising all the three layers for effective performance of the system.

The Communication Layer of the IOT architecture plays a major role in the successful deployment of IOT system. In the prior art, the communication layer of IOT face the problem of scalability as large number of devices are added to the network. The communication layer suffers from logical separation of IOT devices for logically distinct sensors and gateways.

Problems with prior art:

The communication layer of the IOT system has a plethora of protocol solutions such as XigBee, ZWave for inter device communications or LoRAWAN, MQTT for cloud communication. Similarly on the software front the communication protocol and methodologies vary for different vendors and platforms. The different technologies and standards do not make for a pay as you grow scalable architecture. There are also issues related to interoperability between different vendor products and IOT central server.

None of the state of art inventions disclose the mechanism for providing information to the Central IOT server regarding the failure of the sensor or the gateway due to battery or power failure.

The present invention discloses a system based on a cloud based platform wherein the Sensor Gateway 102 communicates with subordinate end devices being actuators and Sensor Device 103 which are monitored or controlled by the user application in the mobile device and where the mobile device is communicating with the central server in the cloud over the encrypted communication network.

Objects of the invention:

The principal object of this invention is to build a robust and scalable protocol for communication between the central server which is communicating with mobile devices used for monitor and control of external parameters or conditions. Another object of the invention is to optimize the deployment of the system in low bandwidth or intermittent network areas for effective monitor and control of external parameters or conditions. Further object of the invention is to maintain coherence within the entire IOT system by the use an uniform protocol mechanism.

Summary of the invention:

The communication protocol defines the four layers of IOT network stack, which form the backbone of any IOT network platform. Any IOT network platform model may fit into this generic model, however the distributed optimal compute is defined in each of the different features supported by the communication protocol. The basic requirements of the IOT platform are defined starting from the application layer down to communication nodes communicating raw bit stream at the bottom most level.

The invention method for communicating between the different IOT sub-systems comprising of following entities: (i) Sensor Device 103s, (ii) Sensor Gateway 102s, (iii) end user devices or actuator based devices, (iv) controllers connected to sensors and end user devices, (v) Cloud Computing platform, (vi) communication network, (vii) Mobile Application.

The Sensor Device 103s form the lowest layer of the system. The Sensor Device 103s are connected to a Sensor Gateway 102. The Sensor Gateway 102 collects and converges all the sensor data. The Sensor Gateway 102 performs data massaging and then forwards the data to the central server in the cloud for near real time data analysis. The central server performs data analysis using pre-configured rules or using Artificial Intelligence. The central server based on the rules, carries out subsequent automatic action on the actuator devices or forwards the information to mobile device for manual intervention.

The communication protocol ties the hardware characteristics of all the sub elements all the way to the software front end in order to get the goodness of every edge node optimally.

The Sensor Gateway 102 and the Sensor Device 103 communicate with each other using the Communication Protocol. The process for building the IOT network starts by pairing the Sensor Device 103 to the Sensor Gateway 102. The Communication Protocol is invoked by pressing button on the Sensor Gateway 102 and Sensor Device 103 simultaneously. This method provides with any new Sensor Gateway 102 to be connected to the IOT network in a simple elegant manner, ensuring first level of physical security protocol.

The Communication Protocol defines the identification addresses for Sensor Gateway 102 and Sensor Device 103. The Sensor Device 103 obtains its identification number during pairing with the Sensor Gateway. The unique identification number is provided by the Central Server to the Sensor Gateway 102, which in turn provides the ID to the Sensor Device 103. The Central Server maintains a free list of Identification tokens. The tokens are freed upon removal of the SAT by any user. This helps in establishing a coherent view of the Sensor Devices 103 across all the users connected to the same Sensor Gateway 102.

The bitstream used in Communication Protocol contains the information necessary to identify the family of the bitstream(preamble), the accuracy and correctness (CRC), the actual message (datagram) and any other metadata that is needed along with the actual data packet. Parts of the bit stream are encrypted using a native simple scheme, which helps with scrambling of the bits sufficiently to guard under trivial snoop attacks. The message is always 10 Byte long (80 bits): (32 Bit Sensor Gateway ID + 16 bit Sensor Device ID + 16 bit Sensor Value + 16 bit metadata/checksum)

This minimalistic data of 10 bytes ensures reliable communication without loss of bits across Radio Frequencies, ensuring a longer range supported by the Sensor Devices 103 for the same applications as compared to any other prior art.

The message is scrambled using a constant 10 bytes key. Scrambling with a constant key ensures the inability to decipher bits directly from any trivial snoop attacks. The Communication Protocol operates on a 250 Kbps baud rate, which helps in increased reliability across concrete walls and objects and thereby increasing the range of the Sensor Devices 103.

Brief Description of Drawings:

Fig 1 illustrates the layers of the system – Sensor Layer, Sensor Gateway 102 Layer and Central Controller 101 Layer along with Mobile app layer;

Fig 2 is the flow diagram of Sensor Device 103 communicating with Sensor Gateway 102 according to an embodiment of the present invention;

Fig 3 illustrates the complete flow diagram of Sensor Device 103 communication with the Central Controller 101 via the Sensor Gateway 102;

Fig 4 is the flow diagram of Sensor Gateway 102 registration with Central Controller 101;

Fig 5 is the flow diagram of the mobile app or the desktop application registration and communication with the Central Controller 101;

Fig 6 is a model layout of the mobile app and the desktop application

Detailed Description:

The detailed description of the invention will be described in detail below with reference to the drawings. FIGS. 1 through 6, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the invention may be implemented in any type of suitably arranged system.

Fig 1. Illustrates the three layers of the IOT System.

The entire ecosystem is built up by first deploying the Central Controller 101 101. The Central Controller 101 is the heart and brain of the entire system. The Central Controller 101 is pre-configured with software and applications to register and communicate with the Sensor Gateway 102 and Sensor Device 103. It must be pointed out that condition to requirements, the Central Controller 101 may be a single Server implementation or a redundant Server implementation with load balancing and high availability. The actual physical and logical implementation of the Central Controller 101 may vary as per the requirements. The Central Controller 101 comprises of at least one storage device connected to it.

The second step in creation of the ecosystem is the deployment of Sensor Gateways 102. The Sensor Gateway 102 form the second layer in the three tier-system and are deployed as required to places where the external conditions have to be monitored. The Central Controller 101 communicates with Sensor Gateway 102 via the Communication Protocol 104.

The Sensor Gateway 102 connects the Sensor Device 103 to the Central Controller 101. The Sensor Gateway 102 is used to converge all the data coming from the Sensor Device 103. The Sensor Gateway 102 comprises of a two way communication i.e. a) with the Central Controller 101 and Sensor Device 103 via Communication Protocol 104.

The Sensor Gateway 102 is configured to gather updates from the Sensor Devices 103 regarding their health status – power status, battery status, type of sensor i.e. whether a current or a voltage sensor, or a digital or an analog sensor.

The Sensor Device 103 also comprises of applications running to gather the external environmental conditions and performs operations, which help with clustering, filtering, smoothening and analysing the sensor data for accuracy and validation. An individual Sensor Device 103 is configured to send trigger to the Sensor Gateway 102 based on an external event. The event may be a change in temperature, weight or flow of fluid or even a movement. Along with the external events, the Sensor Devices 103 are configured to update their power status, the health status in form of dead or alive messages. The Sensor Devices 103 may also be attached to an actuator to perform the commands as instructed by the Central Controller 101. The actuator may be a mechanical, electro-mechanical or a software-controlled device.

Fig 2 is an illustration of the communication between the Sensor Gateway 102 and Central Controller 101. The communication between Sensor Gateway 102 and Central Controller 101 is carried over an encrypted and secured northbound Communication Protocol 104.

Sensor Gateway 102 when powered up gets connected to the network, and sends a Registration Request 201 to the Central Controller 101. The Central Controller 101 is pre-configured with the details of Sensor Gateway 102 as per client requirements. The Central Controller 101 carries the authentication and verification of the Sensor Gateway 102. The Central Controller 101 carries out authentication for every Sensor Gateway 102 powered up and connected to the communication network. The Central Controller 101 either on successful authentication or otherwise, replies with either a positive acknowledgment or a Nack. On positive authentication, the Central Controller 101 sends the required Meta Data to the Sensor Gateway 102.

The pairing of the Sensor Device 103 with Sensor Gateway 102 is initiated by pressing of the respective buttons on the Sensor Device and Sensor Gateway. The Sensor Device requests the Sensor Gateway for an ID and at the same time gives its credentials to the Sensor Gateway along with the encrypted keys.

The Sensor Gateway 102 validates the Sensor Device credentials and obtains an ID from the Central Controller 101. The Sensor Gateway sends the new ID along with its own credentials and the public key to the Sensor Device to be used for encoding.

Sensor Device acknowledges the new ID and public key to the Sensor Gateway, which in turn notifies the Central Controller regarding the addition of new Sensor Device.

The Sensor Gateway 102 forwards the updates from the Sensor Device 103, which is shown in Fig 2 as messages 203 Sensor Updates.

The Sensor Device 103 sends a Sensor Gateway 102 to Controller sync request 205, which is replied via a Ack/Nack/Meta Data 206. In an event, where the Central Controller 101 has lost communication with the Sensor Gateway 102 due to any reason such as power failure at the Sensor Gateway 102 site or loss of communication link, the Central Controller 101 sends a sync request to the Sensor Gateway 102. This mechanism helps to ensure that the Central Controller 101 knows the state of the Sensor Gateway 102 at any given instance of time.

Based on the Sensor Update, the Central Controller 101 sends an Action Request 209 to the Sensor Gateway 102. The Action Request is meant for the Sensor Device 103 or the actuator device to carry out certain actions.

Fig 3 illustrates the communication flow between the Sensor Device 103 and the Sensor Gateway 102.

One or more Sensor Device 103 may be connected to the Sensor Gateway 102. A Sensor Device 103 may be connected wirelessly or via a wired interface. The Sensor Device 103 to Sensor Gateway 102 communication is in three phases. First is the Registration Phase. During Registration, the pairing of a Sensor Device 103 with the Sensor Gateway 102 is carried out in close proximity. The pairing buttons on the Sensor Device 103 and the Sensor Gateway 102 pressed simultaneously.

In the normal operation phase, on the occurrence of an event, the Sensor Device 103 sends the event update to the Sensor Gateway 102. The Sensor Gateway 102 upon receipt of information from the Central Controller 101 informs the Sensor Device 103 regarding sensor actuation or update via the message 306.

The third phase of the Sensor Device 103 and Sensor Gateway 102 is the Dead/Alive or last gasp communication. The innovative feature allows for the Sensor Device 103 to send a last gasp before its battery is discharged to the Sensor Gateway 102 via message 308. The feature allows for conservation of energy at the Sensor Gateway 102 and reduction in polling cycles from the Sensor Gateway 102 to the Sensor Device 103.

Fig 4 illustrates the flow diagram of communication between the Sensor Device 103, Sensor Gateway 102 and Central Controller 101. The communication between Sensor Device 103 and Sensor Gateway 102 is similar to that of Fig 3. Fig 4 shows that in the normal operation phase, the Sensor Gateway 102 carries out the Analysis and massaging via message 405. During the Last gasp operation, the Sensor Gateway 102 forwards the Sensor Device 103 information to the Central Controller 101. Thus the Central Controller 101 is always aware of the state of every Sensor Device 103 in the system.

Fig 5 illustrates communication flow diagram between the App (Mobile or web based) and the Central Controller 101. The App sends a message 501 for registration and credential check. The Central Controller 101 validates and authenticates the App and replies with Ack/Nack/Meta Data. The communication between the Central Controller 101 and App is event triggered so as to save on bandwidth. Although, in some of the embodiments, an App may keep requesting the Central Controller 101 with a constant request for updates. The App sends a request 413 for Data Refresh from the Central Controller 101. The App has notification pushed by the Central Controller 101 and may request an action with a request 509.

Fig 6 illustrates the layout of the App on a mobile device as well as on a web page.

While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.