The paper deals with the process of development of the universal data transfer protocol for Internet of Things projects. It describes the reasons for the mobile solution is needed. All main ways of communication for Internet of Things systems are described. It is spoken in details about different ways to transfer data on the mobile side. WIFI, Bluetooth and Bluetooth Low Energy are noted as main existed protocols. M uch attention is given to Bluetooth Low Energy as the main protocol for the universal solution to base on. The method proposed explained with the examp le of the common healthcare project's system. The main data buses are defined.
1.1
Internet of Things (IoT) is a socio-technical phenomenon with the power to disrupt our society such as the Internet before. IoT promises the (inter-) connection of myriad of things providing services to humans and machines. It is expected that by 2020 tens of billions of things will be deployed worldwide (see Fig.1). It became evident that the traditional centralized computing and analytic approach does not provide a sustainable model this new type of data. A new kind of architecture is needed as a scalable and trusted platform underpinning the expansion of IoT. The data gathered by the things will be often noisy, unstructured and real-time requiring a decentralized structure storing and analyzing the vast amount of data. Due to limited roles, energy constraints, etc., however, IoT devices may use mission-tailored or proprietary wireless protocols that smartphones do not speak natively. The number of mobile users grows every year. The number of mobile phones and wearable or connected devices grows accordingly (see Fig.2). Every new device built later 2015 implements own realization of wireless connection. This way of development makes slower the development process and restricts commu nication between different devices. That is why devices cannot be connected to big systems without pain. Universal communication protocol of the IoT devices will resolve this problem. 1.2
There are a lot of protocols and standards for the IoT system[
In maximu m coverage, there are few ways of communication in IoT system:
remote device — smartphone;
smartphone — remote device;
smartphone — server side;
server side — smartphone;
remote device— server side [
The main goal is a building a concept of protocol, suitable for IOT devices, communicated with mobile devices . Besides, it is also necessary to investigate already existed protocols, find differences between them according mobile specific. Universal data transfer protocol should be explained with the example of the common IOT system.
The universal protocol should support data transfers in both directions between remote device and smartphone and should be easily integrated with other usual protocols, used by another way of communication. The remainder of the paper is structured as follows. Section 2 presents a brief description of existed solutions and protocols to base on. The universal data protocol is shown in section 3 and an example of realization for the virtual systemis shown in section 4. Sector 5 contains conclusions and future steps of research. 2
A data transfer protocol is a standardized format for transmitting data between two
devices [
The notion of a universal protocol provides a rationale for standardization of protocols;
assuming the existence of a universal protocol, development of protocol standards
using a consensus model might be a viable way to coordinate protocol design efforts [
Bluetooth — is safer than WIFI for human health, but at the same time, the distance
between conjugated devices cannot exceed theoretical maximu m under ideal conditions
of 10 meters [
BLE (Bluetooth Low Energy) — to have permanent communication with a
smartphone and keep battery power as long as you can. This solution gives the most
productive portability [
The latest version of Bluetooth Low Energy 5.0 has a longer characteristic, but there are not enough mobile devices supported this revision on BLE.
Bluetooth mesh networking – is a protocol based upon Bluetooth Low Energy that
allows for many-to-many communication over a Bluetooth radio [
Foundation models have been defined in the core specification. Two of them are mandatory for all mesh nodes: Configuration Server (mandatory), Configuration Client , Health Server (mandatory), Health Client.
Not all IoT projects are health projects. Communication is carried in the messages that may be up to 384 bytes long. This is not suitable value for the mobile side. So the best supported by the mobile devices revision of BLE is 4.0.
Key BLE 4.0 terms and concepts: 1. Generic Attribute Profile (GATT) — The GATT profile is a general specification for sending and receiving short pieces of data known as “attributes” over a BLE link.
All current Low Energy application profiles are based on GATT. 2. Attribute Protocol (ATT) — GATT is built on top of the Attribute Protocol (ATT).
ATT is optimized to run on BLE devices. Each attribute is uniquely identified by a
Universally Unique Identifier (UUID), which is a standardized 128-bit format for a
string ID used to uniquely identify information. The attributes transported by ATT
are formatted as characteristics and services [
But the documentation of GATT protocol does not allow to have some general
characteristics for all the devices. That’s why every new IOT device has its own implemen
tation of the GATT [
The main operands of the protocol are buses and characteristics. Buses should be created by the logic meaning. Characteristics should be grouped by the belonging to each bus. Each bus should contain at least one characteristic. Each characteristic has 20 bytes for data.
Protocol consis ts of: Data buses; Data characteristics.
Analyzing the predication of the characteristics was found a different kind of
characteristics. The universal characteristic should just contain 20 bytes of the data [
Simple characteristic(Fig. 4) Time characteristic(Fig. 5) Configuration characteristic(Fig. 6) As an example, can be examined the IOT healthcare project with few buses and characteristics. System consists of simple remote device with specific sensors and phone. The ranges of measurements can be configured from the phone. Alerts are sent by remote device if measurements are out of range. Remote device has LED controlled fro m the phone (see Fig.7). remote device – bracelet or other wearable device; phone. 4.1
All data can be transferred from remote device to phone and back via data buses. Data buses can be separated by business logic: Sensordata; Alerts; Battery; Rssi; LED; Errors; Custom_config; Networks.
Sensordata data bus used to transfer specific measurements of each sensor and to set ranges of normal values. Min and max values will be set to byte array with different offsets.
Alerts data bus used to transfer alerts from the remote device to phone immediate ly . Battery data bus used to transfer battery level values with the low frequency.
Rssi bus used to get data about signal strength. Provided by Bluetooth as a default feature.
LED bus used to set some data according the led (turn on/ turn off, etc.). Error bus used to transfer errors of the remote device to the phone.
Custom_config bus used to set specific configurations (such as algorithms settings, sleep time, proximity setup, etc.)
Networks bus used to read and set network’s data from the phone to the remote device. The networks will be used by priority to connect. 4.2
Approach mentioned in section 4.3 can be build using main operands of protocol for realization main data buses. All data buses will have their own Services and Characteristics (except the rssi). Final realization of the approach results described in Table 1. Security and safety of developed protocol depends on protocol it based on. While universal data transfer protocol used BLE 4.0 as base it has the same issues and problems. This issues can be resolved with the following recommendations: Activate the communication encryption whenever possible. The use of LTK allows communication to be encrypted between the master and the slave fro m the first moment. All devices from a control network that uses Bluetooth should make use of the encryption. Do not accept connections from unknown devices. Activate the white list option in the master and require pairing with a key of at least 5 characters, thus avoiding malicious devices connecting without permission. Continuously revise the list of registered trusted devices in order to avoid malicious devices appearing. Assign a name to the devices that does not reflect extra information such as the brand, the device model, the location or service. With these measures it is difficult for possible attackers to benefit from vulnerabilities associated with specific devices and carry out targeted attacks. Maintain device configuration in invisible mode to make it difficult to detect from other devices.
Following recommendation can be implemented “as it is”, but it will decrease the speed of data transfer. 5
This paper describes process development a universal data tra nsfer protocol for IOT project. The reasons why the mobile solution is needed were examined. All main ways of communication are every IOT system were described. WIFI, Bluetooth and Bluetooth Low Energy were highlighted as main existed protocols. Much attention was given to Bluetooth Low Energy as the main protocol for the universal solution to base on. The method proposed explained with the examp le of the common healthcare project’s system. As result data transfer protocol, defined main data buses and protocols to base on, was created. Next steps of research will be defining terms of use for data transfer and implementing the universal protocol in multiple IOT systems and resolving security issue without speed lost. 6
This paper results from the Erasmus+ programme educational project ALIOT «Internet of Things: Emerging Curriculum for Industry and Human Applications» (reference number 573818-EPP-1-2016-1-UK-EPPKA2-CBHE-JP, website http://alIoT.eu.org) in which the appropriate course is developed (ITM4 - IoT for health systems) within its framework, we have developed modules related to IoT systems modelling. The authors would like to thank colleagues on this project, within the framework of which the results of this paper were discussed. The authors also would like to show their deep gratitude to colleagues from Computer systems, networks and cybersecurity, National Aerospace University «KhAI» for their patient guidance, enthusiastic encouragement and useful critiques of this paper.