1 Overview of Paper
In this work the authors review a subset of the more important standardized IoT (Internet of Things) protocols. To begin, at the application layer CoAP and MQTT are reviewed while providing a comparison between the two. In addition, at the transport layer mDNS, DNS-SD, and uBonjour are reviewed (the authors call these service discovery protocols). Further, at the Internet/Link Layer 6LoWPAN, 802.15.4, and LoRaWAN are reviewed (the authors call these infrastructure protocols). Finally, the authors describe an application schema using some of these protocols in a smart home environment. The sheer scope of IoT associated protocols meant that many were omitted by the authors from this discussion, some of the more important being: SigFox and Cellular (Low Power Wide Area Networks), ZigBee, BLE, RFID, NFC, and Z-Wave (Short Range Network). [1] It is important to note how 6LoWPAN discussed here fits in with the other low level Internet/Link Layer protocols. This is shown in Figure 1. [1]
2 Application Layer Protocols CoAP (Constrained Application Protocol) and MQTT (Message Queue Telemetry Transport)
MQTT and CoAP, the two application layer protocols for IoT discussed here, are summarized in Table 1 illustrating their primary features and differences. The salient points to take away are the transport layer differences (TCP vs. UDP) hence the resources needed to deploy each (memory and processor resources), packet throughput speed differences due to this transport asymmetry, built-in transport security, QoS issues, and the fact that MQTT has a much larger installed base. [13][23]
With MQTT the IoT device acts as a publisher of data, which must pass through a broker, then is forwarded onto subscribers. [31] Since the broker stands between the publisher and subscriber, it authorizes both, providing a modicum of security. However, the requirement of a broker introduces additional message delay in addition to the TCP based overhead and requires yet another piece of middleware. Mosquitto is a common open source package used for MQTT brokering. [30] A Variant of MQTT, MQTT-SN, provides MQTT message services over UDP to avoid the TCP required connections. [23]
CoAP being based upon HTTP but for reduced resource IoT devices is a client server transfer protocol, utilizing a reduced set of verbs (GET, POST, PUT, DELETE). [24] With CoAP using smaller, connectionless UDP datagrams, there is less overhead without the MQTT requirement of guaranteed packet reception and handshake connections. For larger packet sizes MQTT displays less overhead, because larger packets are more apt to be fragmented and MQTT by utilizing TCP, guarantees their arrival. [1][2][3][6][7] CoAP more so than MQTT currently is undergoing change as additional features are added even with a completed standard. There is a proposal to add TCP, which may make CoAP more like MQTT without the overhead of a broker. [24]
2.1 Service and Discovery Protocols (DNS-SD, mDNS, and uBonjour)
As more IoT devices of every conceivable type become part of the Internet fabric, discovery mechanisms that suit their transient connectivity are needed. The authors discuss two here, DNS-SD (for Service Discovery) used to locate and publish network services, and mDNS (for multicast) which acts as a nameserver. These two have been combined into a service named uBonjour with an operating system environment named Contiki. [28] Since DNS-SD is used to look up names and services while mDNS locates the corresponding address, small resource IoT devices must keep name and address information cached, a negative for devices with limited memory. [16][25][26]
Ubonjour (DNS-SD component) provides name resolution and network discovery services using standard DNS protocols, whereby IoT devices can locate one another without the use of a gateway out and up into the Internet as with standard DNS. mDNS resolves hostnames using a standard DNS address record, services using a pointer record. [28]
2.2 Infrastructure Protocols (IEEE 802.15.4, 6LoWPAN, and LoRaWAN)
802.15.4 is a low data rate physical and MAC (Media Access Control) layer standard for low power applications. The MTU is small at 127 bytes; CSMA/CA and security are available MAC layer services. The radio offers a number of different frequencies (low band, high band) and channels modulated using a form of phase shift keying modulation. The available bit transmissions rates are 20-40 kbps and 250 kbps for the low and high bands respectively. IoT devices using 802.15.4 are of two types: FFD (Full Function Devices) and RFD (Reduced Function Devices). The principal difference being FFDs can communicate with all IoT devices while RFDs cannot. Mesh and star network topologies are supported as is 128-bit encryption with eight security levels. [22][27][33]
6LowPAN was created to facilitate IP connectivity when using low power 802.15.4 IoT devices. It is intermediate between the data link layer and the network layer, and it is shown in Figure 2 and Figure 3, while Figure 4 illustrates its use with MQTT and CoAP. Native IPv6 permits a 1280 byte maximum size packed which cannot be handled by IEEE 802.15.4 with a MTU of 127 bytes. In brief 6LowPAN takes care of this and other issues by using a different fragmentation schema (11-bits permitting a 2048 byte packet) along with header compression. However, large 6LowPAN packets give poor performance, using small packets results in better overall throughput. The significance of 6LowPAN when coupled together with 802.15.4 is this structure permits ready connection to IP networks. [22][29]
LoRaWAN is a long range low power technology that uses FSK (Frequency Shift Keying) at the MAC layer and a network architecture consisting of IoT nodes, servers, and gateways that route IoT node packets to the Internet. In brief it is designed for WANs. Different frequency bands at the physical layer are assigned to world geographic regions: Australia from 915-928 MHz, China from 779-787 MHz, Europe 863-870 and 433 MHz, and USA 902-928 MHz. Each has common 125 KHz uplink channels and 500 KHz downlink channels allocated differently for each region including sub-bands.
There are three classes of devices used with LoRaWAN corresponding to different types of IoT devices: class A (low energy battery sensors, bi-directional communication), class B (battery, bi-directional communication, and class C (highest energy, low latency bi-directional communication). Two layers of security are provided, both use AES-128 keys, at the network and application layer. Each LoRaWAN IoT device must join the network and be activated, a process known as OTAA (Over the Air Activation). [34][35][36]
3 INTEGRATION OF PROTOCOLS
The authors briefly discuss bridge application layer software for CoAP between MQTT: Ponte (an API converting between different data formats), Franca targeted at the automotive industry effectively serves as a hub (integrates different supplier software), and Vorto used for code generation and meta record keeping. The Eclipse (development environment) provides Ponte, Franca, and Vorto. M2M, can be used with IP and CoAP based, is used for remote IoT device management.
Finally, the authors briefly discuss how virtual networks can be applied to IoT environments (analogous to VPNs). These are provisioned at layer 2 or layer 3 as a function of IoT device resources. The takeaway here is that the logical link layer is all IoT service devices can interact with. Some of the usual rules of VPNs apply enabling sensor net partitions and aggregations.
4 SMART HOME
The author’s example of the smart IoT home is shown in Figure 5. It consists of interconnected appliances (utilizing WiFi), robots (utilizing WiFi), and low power smart sensors (utilizing 802.15.4) together with a gateway device for the smart sensors, all coupled to a home router gateway connected to the Internet. The authors claim this design facilitates easy access to devices from the cloud, yet allows the devices to “directly interact with other devices in the house” (the devices continue to communicate and interact without intervention from the outside). Standard protocols as discussed here are used throughout; sensor nodes utilize 802.15.4, CoAP, and 6LowPAN: CoAP for sensor communication, 802.15.4 for the sensor physical layer, and 6LowPAN for simple network “translating” in the router to the external Internet. [6][7][11][12]
5 FUTURE WORK
Throughout the world many people face health challenges ranging from annoying and minor to physically debilitating. Currently, health condition monitoring is typically carried out in a clinical setting using fixed, bulky, physiological measuring equipment – which within the USA is extremely expensive. Clinicians agree that for ambulatory health conditions, and some hospice based conditions, the best place for the patient is in their own home, rather than a care facility.
Here, the goal is for people to continue with their daily lives and/or permit critical patients to remain in their home while streaming clinical information to their health care providers for review, analysis, and (sometimes) action. Recent work demonstrates the market possibilities for such wearable/fabric based physiological systems with real-time telemetry. [17][18][19] In essence IoT for patient monitoring.
In this context there is a great need for real-time, streamed physiological measurement data that bridges five disparate yet intersecting disciplines: IoT (networks/protocols), materials science (wearable clothing, implantable devices), low power circuit design (long life battery operation), sensor biology, and databases (EPR – Electronic Patient Records).
One possibility discussed here, is a fabric based low power sensor network solution that may be worn as clothing or sit beneath a patient/individual that monitor vital signs together with physiological parameters. [20][21] These vital signs include, but are not limited to the following: temperature, heart rate/pulse, blood oxygen, blood pressure, body surface salinity, acceleration/de-acceleration, blood sugar, breath ions/smell, insulin pumps, preloaded pharmaceutical dispensing pumps, and voice/video records, etc. These physiological data are then streamed to a local wireless monitor using 6LowPAN connectivity, which then connects with the home or mobile phone Internet connection. This way a physician or his/her proxy can view the streamed data for charting and/or decision making as needed. If vital signs indicate a need, the patient can be called to an office/hospital and/or preloaded medication can be dispensed while the patient is at home.
Within the USA most urban/suburban homes have some type of wired Internet connectivity, typically DSL or cable modem based utilizing FTTH, FTTC, FTTB, FTTX, (Fiber To The Home/Curb/Building/X), or other wired connectivity. However, in rural areas wired Internet connectivity is much less ubiquitous but some type of mobile phone carrier based Internet service is typically available. This distinction is important, without it rural dwellers within the USA would be left out due to the concentration of Internet services within the urban/suburban areas. Here, we assume Internet connectivity to the home in some form.
As individual pieces much of the physiological measuring techniques have been demonstrated (think of a Fit Bit), the principal challenges remaining are low power sensors, integration of same within woven fabric, and robust network connectivity from the patient to a home gateway be it an Internet router or mobile phone based Internet connectivity. Figure 6 illustrates a home based IoT sensor system with Internet connectivity. In the system proposed here the sensors are woven into clothing material and/or the underlying bedding/blanket rather than individually attached except where necessary (e.g. drug infusion).
Within the home BLE, IEEE 802.15.4, and 6LowPAN are possibilities for sensor data transmission that fit the constrains for urban/rural environments. Distances are typically small, well within the 100 m specifications for BLE, 802.15.4, and 6LowPAN. However, choosing 6LowPAN facilitates simpler integration with both BLE and 802.15.4 should this need arise, as well as existing networks and meshes if needed in the future. [33] If (when) newer low power wireless physical layer protocols are developed, the use of 6LowPAN will make any transition easier due to its ease of use with existing TCP/IP networks. Network protocol interoperability is a key design choice here as the current state-of-art will surely change. In an urban environment external network connectivity would be through the in home gateway router, in the rural environment network connectivity would be through the mobile phone using BLE or 802.15.4 as a bridge to 6LowPAN, then onto the external network. [22] Once out of the home, patient vital sign data can be streamed directly to a physician’s office gateway or cached in the cloud for review and analysis. Today, CoAP and MQTT are reasonable choices for application layer transmission. In the rural setting CoAP may be a more robust choice due to its smaller packet/time footprint, though its use raises security concerns as currently implemented. [2] MQTT, having a larger packet/time footprint, needs an intermediate broker, yet does not suffer from security concerns would be better suited to a wired urban home setting. [3]
This author has begun a project exploration using MQTT with Mosquitto as the object broker using an ARM-Cortex based system (STM32L4), body sensors (blood oxygen, temperature, pressure, etc.), proximity sensor, and motion sensor. [32] This system is shown in Figure 7. Standard IEEE 802.11 WiFi, and modules for BLE (Bluetooth Low Energy) and 915 MHz LoRaWAN are included – only the standard WiFi connectivity has been tested at this time. The overall project plan is multi-phased: using standard WiFi complete the software to see all sensor information using Mosquitto (working), then migrate to the IBM Watson Cloud Based MQTT Broker. After which the 802.15.4 physical layer will be tested with 6LowPAN still using MQTT with a broker. Finally, an attempt to get CoAP and uBonjour running on the same platform will be attempted. Due to the complexity of setting up CoAP (together with Contiki) and uBonjour on an embedded platform for proof of concept, a Raspberry Pi may be substituted to save time. [30][31][32][33]
6 CONCLUSIONS
In summary, the authors have reviewed a subset of important IoT protocols with an emphasis on smart home applications. At the application layer MQTT and CoAP, TCP and UDP transport layer protocols were discussed. Currently, MQTT using a publish/subscribe model of IoT communication, offers QoS services and uses TLS for security, but requires a communication broker. Due to its use of TCP transport, MQTT typically requires more time to deliver IoT information. CoAP which utilizes UDP transport, requires less time to deliver IoT information, and is much more a work in progress. DTLS is proposed as a security mechanism, QoS service is an add on to the specification, and TCP service is planned. [2][3]
mDNS together with DNS-SD are UDP based services that act like a standard DNS service for low power low resource IoT devices. mDNS provides the address resolution and DNS-SD the names of IoT devices and services they provide.
IEEE 802.15.4, 6LowPAN, and LoRaWAN respectively are a low power physical layer, a bridge to the standard IP network layer when using low power wireless physical layers, and a MAC layer protocol design to connect IoT nodes, servers, and gateways across WAN networks.
The Smart Home schema discussed here utilizes low power IoT devices (running 802.15.4, 6lowPAN, and CoAP) interconnected using an in-home gateway which is itself interconnected with a standard WiFi router connected to the Internet. Using WiFi, in-home convenience devices (robots, computers, phones) can themselves interact with the IoT devices and/or the Internet.