ABSTRACT
The Internet of Things (IoT) opens up tremendous opportunities to provide location-based applications. However, despite the services around a user being physically adjacent, common IoT platforms use a centralized structure, like a cloud-computing architecture, which transfers large amounts of data to a central server. This raises problems, such as traffic concentration, long service latency, and high communication cost. In this paper, we propose a physical distance-based asynchronous messaging platform that specializes in processing personalized data and location-based messages. The proposed system disperses traffic using a location-based message-delivery protocol, and has high stability.
RELATED WORK
Real-world location-based applications aim to detect the location of targets in various service domains, such as medical personnel or equipment in a hospital, smart home management system or stored inventories in a warehouse. There has been research on IoT devices such as Bluetooth low Energy (BLE) sensor module and power consumption issues on IoT device.
EZ is a gateway that supports an efficient asynchronous protocol in IoT. EZ enables the creation of gateways with either C or Java platforms without requiring developers to have any substantial understanding of either relevant protocols or low-level network programming. These research works well-define the characteristics of location-based services (LBS) and IoT. However, they have the aforementioned problems of centralized architecture.
PROPOSED SYSTEM CONCEPT
Figure 1. Scenario for Location-based IoT service
Figure 1 is a representation of a location-based IoT service scenario in a hospital environment. A hospital has numerous mobile assets, such as wheelchairs, chemicals, medicine, and hazardous waste materials. The administrator will request typical IoT services, such as (a) monitoring the location and status of equipment; and (b) checking the path of hazardous materials to confirm their safety (shown as green line).
In addition, a nurse can request location-based services, such as (c) finding or reserving an available wheelchair near her current position; (d) broadcasting only to the position of the patient who called rather than broadcasting to the entire hospital; or (e) checking the proper medicine by proximity-based direct Device to Device (D2D) communication with a patient’s wearable device. Lastly, (f) a user uses the private data such as daily activity or vital signal stored in personal storage.
Figure 2. Concept diagram of asynchronous messaging platform
Figure 2 shows the proposed system’s asynchronous-messaging structure. The proposed platform is composed of mobile devices, protocol gateway, and Self-Organized Software platform (SoSp) middleware. Mobile devices are connected to SoSp middleware using various protocols; a mobile device using TCP/IP directly connects to the messaging middleware, and the other protocol devices can communicate to the messaging middleware through the protocol gateway.
WIRELESS COMMUNICATION PROXY
Figure 3. Component diagram of frontend module and RFProxy agent
Figure 3 shows the elements of the frontend module and the RFProxy agent. The FE supports a variety of wireless-communication protocols using a communication manager. The address book converts an address from a communication address (like a MAC address) to an identification address (like a unique user ID), or reversely. It helps that we can communicate with a mobile device using a unique ID without concerns about the real communication protocol. The network manager and connection manager manage the specific protocol depending on the characteristics of the communication protocol.
Figure 4. Messaging sequence from SLIM Hub (SH) to target mobile node
Figure 4 shows how the frontend module sends a message to the mobile node. If the FE receives a message request (1,2), it switches the Bluetooth mode to a central mode, which can create a connection. When it is connected to the mobile node (3), the FE transmits the message and saves the results (4,5). Next, the FE forwards the result to RFProxy (7,8). If the transmission fails because the mobile node has moved, the message is re-transmitted by a location-based protocol, so the message is transferred regardless of the mobile node’s movement.
E POST-IT MIDDLEWARE
Figure 7. Features of the ePost-it concept
To implement asynchronous messaging among various devices and services, we propose the ePost-it concept to provide location-based asynchronous messaging. This concept comes from Post-it in the real world, which can be easily separated or attached to the target. Following are the features of the ePost-it concept, as shown in Figure 7:
- It has a complete message-block type containing a string, encoded binary data, etc.‚
- It will last as long as the survival time configured in the message.‚
- It can be sent to all of the users in the region by targeting the area as the destination.‚
- It can easily be temporarily stored and moved anywhere along the target.
Figure 9. Software structure of ePost-it middleware
Figure 9 shows the structure of the ePost-it middleware. All SoSp middleware service messages are delivered in ePost-it format through RFProxy or WiFi, and processed by the ePost-it agent. The ePost-it agent analyzes the destination described in the XML document, searches the destination SH to find where the message should be delivered using the location-based search algorithm and transfers the message to the messaging agent of the target SH.
Figure 11. Messaging flow from messaging agent to target agents or devices
ePost-it middleware use four types of push methods to deliver a message to a mobile node using various communication protocols. Figure 11 illustrates the process of transmitting an ePost-it to mobile nodes of various kinds. The messaging agent forwards the message to the destinations, depending on the destination type. A message targeted to a service agent is transmitted directly. A message targeted to a mobile node is passed to a push agent, and the push agent transfers the message according to the mobile node’s communication type.
IMPLEMENTATION AND EVALUATION
Figure 12. Hardware module used to evaluate the proposed platform
Figure 12 shows the hardware used to evaluate the proposed platform. The SLIM Hub acts as a gateway and provides the location-based services (LBS). It includes speakers, LCD, and ethernet access, and is connected to adjacent SHs using TCP/IP. The frontend module is a protocol gateway connected to an SH to abstract the communication with mobile nodes, such as BLE and ZigBee. The mobile tag is a type of mobile node.
Figure 13. Total transmission time according to the number of mobile nodes
To evaluate the FE, we tested the traffic performance. Figure 13 shows the average total transmission time while increasing the number of mobile nodes, each of which sends only one message to the FE. First, a mobile node sends a variable size message to the FE. For a given number of mobile nodes, we measured a total transmission time until all queued requests are processed and calculated an average of 30 runs.
Figure 15. Response time of ePost-it according to the number of mobile nodes
Figure 15 shows the response time from user’s entrance to receiving the message, according to the number of mobile nodes. As shown in the figure, the response time increases slowly as the number of mobile nodes increases. We determined that an SH responds within a few seconds, in spite of numerous mobile nodes.
CONCLUSIONS
In this paper, we introduced the LIoT service and investigated a proximity-based asynchronous messaging platform specialized in processing personalized data and location-based message. To address traffic congestion and privacy issues, the problems of centralized architectures, the proposed system disperses traffic using a location-based message-delivery protocol, and stores collected personal data to the individual’s storage, not the central server. To implement the asynchronous mechanism in IoT, we designed the following components. The direct communication buffer in a FE abstracted the communication protocol and provided a loosely coupled connection between a mobile node and IoT services.
The temporary storage held personal data until the data was transferred by the asynchronous-messaging mechanism. The ePost-it middleware supported location-based messaging services. We experimentally evaluated the performance. The results showed that the FE could sequentially process numerous requests, spending a few hundred milliseconds in a connection, and the SH could rapidly provide location-based messaging. In future work, we will focus on extending the messaging platform to support continuous data streaming, regardless of the device movement; e.g., healthcare applications for a vital-signal streaming system, which requires the transmission and sharing of large waveform data.
Source: Kyungpook National University
Authors: Hyeong gon Jo | Tae Yong Son | Seol Young Jeong | Soon Ju Kang
>> 200+ IoT Led Projects for Engineering Students
>> IoT Software Projects for Students