As discussed above, many IoT applications required the broadcasting of only short messages, for such broadcasting it is required to broadcast a separate Eddystone UID frame every time. The broadcasting of a separate frame of 31 bytes for UID, URL, and TLM causes the wastage of bandwidth, time, and power, hence here we have proposed an extended TLM frame protocol to be used at the application layer of the communications stack. In this research, we have made the TLM frame capable to broadcast telemetry data as well as constant integer or variable sensor data up to 6 bytes. The newly designed frame defined as “Extended Eddystone-TLM Frame for Sensor Data Broadcasting in the IoT Telemetry Applications” is capable to broadcast telemetry data and constant integer or sensor data up to 6 bytes i.e., it is capable to broadcast data that to be broadcasted by two different frames. As per the design, the TLM can broadcast static or variable along with telemetry data hence broadcasting of UID frames can be avoided i.e., it can reduce communications costs by reducing the number of frames broadcasting, and computational cost (performing lightweight operations), and storage cost.
Analysis of Eddystone-TLM Frame
An existing Eddystone-TLM Frame is used to transmit its own information to the administrator to monitor device health and activities such as battery voltage, device temperature, number of advertising frames sent, time since the last reboot in tenths of a second, sensor data, or any other relevant information. This frame does not have a provision for beacon ID therefore this frame must be broadcast with an Eddystone-UID or Eddystone-URL. As shown in figure 7 the Eddystone-TLM frame is defined as 14 bytes which include 1 byte for frame type (0x20), 1 byte for version (0x00), 2 bytes for battery voltage, 2 bytes for beacon temperature, 4 bytes for advertising PDU count and 4 bytes for time since power on or reboot. In this frame, 6 bytes are not used for any data transmission.
The extended Eddystone-TML frame protocol design should be embedded into an existing Eddystone-TLM frame so that, it will be useful to broadcast the sensor data from an environment and will ensure the QoS on the very low power consumption. In order to enhance the Eddystone-TLM frame for UID broadcasting, the field of 6 bytes which is currently not used for any data transmission can be utilized. The extended TLM should be encapsulated into the existing Eddystone-TLM frame standard without affecting it. It should be lightweight, compatible with existing protocol specifications, and flexible for implementation into beacons.
Extended Eddystone-TLM Frame
The existing Eddystone-TLM frame is flexible in nature and primarily used for telemetry, monitoring, control, and positioning systems. The flexible nature of Eddystone-TLM allows its extension for the other applications that require communication between resource-constrained devices. Here, we have designed an extension for the Eddystone-TLM frame. The extension has to be according to an Eddystone-TLM field of 6 bytes which is currently not used for any data transmission i.e., protocol design should meet all the desired requirements only in the 6 bytes. The extended Eddystone-TLM specification has a provision for configuration and data frames. Figure 6 shows the Extended Eddystone-TLM frame specification.
1) Configuration Frame (3 Bytes)
The configuration frame of 3 bytes includes Mode (1 byte) to define data type (static/dynamic), Sensor Type (1 byte) to define the type of sensor, and Sensor ID (1 byte) to define sensor id.
I) Mode (1 byte): The extended Eddystone-TLM frame has to broadcast static or dynamic integer. The mode defines the type of data to be broadcasted. It has provision for the broadcasting of constant values and variable values from sensors.
Table 1. List of Modes
Binary Value
|
Hexadecimal Value
|
Mode
|
0000 0000
|
00 H
|
Static Integer (Constant Data)
|
1111 1111
|
11 H
|
Dynamic Integer (Sensor Data)
|
Any Other Value
|
Not Defined
|
If Mode Value = 0000 0000 (00H): It represents that frame is being used for the broadcasting of constant integer data. Constant integer broadcasting does not require any further declaration hence next 5 bytes are used to carry actual data.
If Mode Value = 1111 1111 (11H): It represents that frame is being used for the broadcasting of variable data from an input peripheral. The data is being received from various sensors hence sensor detail (sensor type and sensor id) has to be defined. For sensor detail next 2 bytes are used, 1 byte defines sensor type and 1 byte defines sensor id. After the configuration frame, the next 3 bytes are used to carry actual data.
II) Sensor Type (1 byte): The 1 byte (8 bits) has 256 unique values (0000 0000 to FFFF FFFF), it is capable to defined 256 types of sensors or other input peripherals. Here, we have defined 15 popular types of sensors. The remaining unique values are reserved for the future, as per the requirement for more sensor types the expansion is possible in the future up to 256.
Table 2. List of Sensor Type Specification
Binary Value
|
Hexadecimal Value
|
Sensor Type
|
0000 0000
|
00 H
|
Accelerometer Sensor
|
0000 0001
|
01 H
|
Gyroscope Sensor
|
0000 0010
|
02 H
|
Magnetometer Sensor
|
0000 0011
|
03 H
|
Global Positioning System (GPS)
|
0000 0100
|
04 H
|
Temperature Sensor
|
0000 0101
|
05 H
|
Proximity Sensor
|
0000 0110
|
06 H
|
Infrared (IR) Sensor
|
0000 0111
|
07 H
|
Pressure Sensor
|
0000 1000
|
08 H
|
Light Sensor
|
0000 1001
|
09 H
|
Ultrasonic Sensor
|
0000 1010
|
0A H
|
Alcohol Sensor
|
0000 1011
|
0B H
|
Humidity Sensor
|
0000 1100
|
0C H
|
Color Sensor
|
0000 1101
|
0D H
|
PIR Sensor
|
0000 1110
|
0E H
|
Weight Sensor
|
0000 1111 to 1111 1111
|
0F H to FF H
|
Reserved for the Future
|
III) Sensor ID (1 byte): The wireless sensor network includes various sensors and other input devices hence each one must be defined with a unique identity. For extended Eddystone-TLM we have made provision of 1 byte (8 bits) to assign unique identities to the sensors. The 8 bits can generate 256 unique values (0000 0000 to FFFF FFFF) hence the frame is capable to assign unique identities to the 256 sensors.
Data Frame (3 Bytes)
The size of the data frame is variable, depending on the type of data to be broadcasted. The constant data broadcasting frame has 5 bytes (byte 2 to 6) while the sensor data broadcasting frame has 3 bytes (byte 4 to 6). For more description of the protocol, several cases are shown in the following examples.
Examples 1: Examples for the use of Extended Eddystone TLM Frame for constant value broadcast.
Case (a) represents a configuration frame in which Mode Frame = 0000 0000 indicates that it is for the constant integer broadcast and the next 5 bytes are of original fixed data (123456789A H) that has to be broadcasted.
Case (b) represents a configuration frame in which Mode Frame = 0000 0000 indicates that it is for the constant integer broadcast and the next 5 bytes are of original fixed data (1212121212 H) that has to be broadcasted.
Examples 2: Examples for the use of Extended Eddystone TLM Frame for senor data broadcast.
Case (a) represents a configuration frame in which Mode Frame = 1111 1111 indicate that it is for variable sensor data broadcast, Sensor Type = 0000 0000 indicates that the sensor is Accelerometer and Sensor ID = 1001 0001 represents the senor id is 91H, and the last 3 bytes are for sensor input (131290 H) that has to be broadcasted.
Case (b) represents a configuration frame in which Mode Frame = 1111 1111 indicate that it is for variable sensor data broadcast, Sensor Type = 0000 0001 indicates that the sensor is Gyroscope and Sensor ID = 1001 0010 represents the senor id is 92H, and the last 3 bytes are for sensor input (070688 H) that has to be broadcasted.
Case (c) represents a configuration frame in which Mode Frame = 1111 1111 indicates that it is for variable sensor data broadcast, Sensor Type = 0000 0010) indicates that the sensor is Magnetometer and Sensor ID = 1001 0011 represents the senor id is 93H, and the last 3 bytes are for sensor input (1F0799 H) that has to be broadcasted.
Implementation of Extended Eddystone-TLM Protocol on a Beacon
The Extended Eddystone-TLM Protocol can be implemented in any beacon. In this research, we have specifically implemented the lightweight protocol in a resource-constrained beacon (Eddystone). Such a beacon broadcasts the information periodically as per the defined advertisement.
Figure 9 shows the communications architecture of a generic beacon system and an illustration of the process to insert Extended Eddystone-TLM into the scheduler of the TLM frames. Any beacon scanner (smartphone application or single board computer) with our proposed API can read both the Eddystone frame and the Extended Eddystone-TLM frame. A regular Bluetooth scanner is also capable to read a beacon that makes use of both protocols, therefore a beacon with Extended Eddystone-TLM protocol is also capable to work in a beacon broadcasting network without interference.
The Extended Eddystone-TLM protocol is added into the existing protocol not used field. As per the previous discussion, the Eddystone-TLM frame has a field of 6 bytes which is not currently used so we have designed Extended Eddystone-TLM which perfectly fits in it. This approach makes it possible to adapt the Eddystone beacon to broadcast telemetry data and sensor data together improves the efficiency of a beacon. Figure 11 indicated the field of the Eddystone-TLM frame where the Extended Eddystone-TLM protocol can be inserted. The space that hosts the proposed protocol includes two parts: configuration frame (3 bytes) and data frame (3 bytes).