Various kinds of smart sensors are being developed and released with the growth of sensor technology and Internet of Things (IoT) technology. IoT smart service can provide convenience in our daily lives with these smart sensors. However, the increasing number of mobile sensors and amount of data may increase latency. It may cause network congestion on a particular network. Therefore, we propose a Smart Edge Broker (SEB) to intelligently transmit data traffic generated by a smart city in this paper. SEB can prevent the traffic congestion from being transmitted or bypassed to a location where traffic is not necessary. In addition, SEB can prevent overload in a specific area between services through a location-based transfer. Plus, SEB is suitable to operate it as a fog computing model by placing it at the edge of a smart city network. We conducted a latency measurement experiment and load measurement experiment to evaluate the effectiveness of the proposed Smart Edge Broker. As a result, we found that the latency was reduced by 72%, and the CPU usage was reduced by 63% compared to when the Smart Edge Broker was not used.
To provide convenience in our daily lives, it is possible to configure a smart home using various IoT technologies [
First, latency can be prolonged. This means that it takes a long time to transmit data because the transmission distance of sensor data is too far. If the distance between smart home sensors that generate data and a service that consumes the data increases, there will be latency in transmission. This will impair the immediateness of sensor data, thereby lowering the quality of the service. Second, overload could happen. When measuring by increasing the number of sensors and widening the range, the amount of the data that needs to be processed increases, which may lead to bottlenecks due to an excessive concentration of traffic in a specific data center. If this problem happens, it will delay data processing and service provision. The third is service scalability. When new services are added to a smart home and smart city, all the related services need to be changed, increasing the cost as a result. These problems need to be solved when a smart city is configured. To that end, an intelligent distributed computing device is needed between sensors and services.
In this paper, we propose a Smart Edge Broker [
In Section
A smart home is an automation system that not only remotely controls home appliances in a house by connecting them to a network but also detects and actively controls situations using sensors [
Example of a smart home system: IoT sleep care service.
The sleep environment and biometric sleep information measured from sensors in each house are transmitted to an IoT sleep care service provided by the cloud [
A smart city is a system that provides support for efficient linkages between urban infrastructure and smart servers using ICT technologies [
OneM2M smart city blueprint.
As shown in Figure
HTTP has high reliability because it communicates synchronously through the request-response method, but it is slow and consumes a lot of resources. In contrast, MQTT is fast and light because it asynchronously communicates through the publish/subscribe method, but it has low reliability because it cannot guarantee sequential data processing.
In Figure
Examples of a smart city: (a) “Array of Things (AoT)” smart city platform; (b) “Fog Flow” smart city platform.
In Figure
In the previous two studies, the smart city platform was configured using HTTP and MQTT, respectively. However, in both studies, the edge where sensors and services are in contact was not fully utilized. The problems mentioned in Section 1, such as latency, overload, and service scalability, occur in the process of transmitting sensor data to a service through the edge. If a device located at the edge analyzes the data and automatically routes it, this will not only solve problems but also enable a smart city network to be configured more efficiently. In addition, as a smart city sensor corresponds to a smart home service gateway, it can improve the quality of smart home services. Therefore, in Section
The Smart Edge Broker is an intelligent broker, and it is located at an edge between a sensor network and service server to distribute traffic efficiently. It receives all the data from the sensors and analyzes who requested the data and how it routes to the appropriate location. Figure
Smart city platform with a Smart Edge Broker.
The boundary points between the sensor area and service area are divided by the edge. Eight smart homes are distributed in two areas in the sensor area, and the service area consists of one data center and two services. It is assumed that Svc1 and Svc2 use the sensors installed in the smart home system to provide different services and share the sensors in the area below. It is assumed that, at this time, Svc1 needs the data measured in S1, S3, S5, and S7, and Svc2 needs the data measured in S2, S4, S6, and S8. As the data center needs to collect and manage all data, it receives data from all sensors. The Smart Edge Broker mediates the exchange of data between sensors and services. It has features that reduce delays and overloads in the process.
The distance to the data center is far greater than the distance between the service and the sensor, so using sensors in multiple locations can provide efficient data exchange. Smart cities are often composed of services beyond the urban range, so the distance between services and sensors is often more than several kilometers. In this case, it naturally takes longer to send and receive data between the sensor and the service. Additionally, the response time to provide the service is long, so the quality of the service is reduced. Also, the wider the range, the more the sensors that are needed to cover the range, and the burden on the data center to collect and transmit data becomes greater. Furthermore, once a smart city has been configured, if you want to add new services or reconfigure existing services, you need to fix or modify the sensors installed around the city, which means new expenses. The Smart Edge Broker has an intelligent routing function to solve these problems.
It receives requests for desired data from each service and collects and analyzes the data from all sensors based on it. Based on the analysis results, it classifies the data requested by each service and routes it and transmits all the collected data to a data center. Figure
Scenarios for service routing in the Smart Edge Broker: (a) scenario for collecting data from sensors; (b) scenario for collecting selective data from sensors.
In the case of (1), if Svc1 receives the data of S1, S2, and S3, the smart home transmits data to the data center and the service requests data from the data center and receives it. At this time, if the Smart Edge Broker brokers the data between the smart home and service, as shown in (2), there is no need to purposely transmit the data to a remote data center. Svc2 in (2) receives data of S4, S5, and S6 in the same way as Svc1 in (1), but the Smart Edge Broker does not need to go through a data center in place of the data center. In this case, the communication distance is reduced by the distance from the data center, which in turn reduces the burden on both ends of the smart home and service. Also, as the data center does not need to collect data, there is no traffic centralization.
Figure
If this is applied to the IoT sleep care service, a smart home can correspond to a sleep care device, and a service can correspond to IoT sleep care service. It collects the sleep data measured in each smart home and transmits it to the IoT sleep care service to provide services. At this time, the Smart Edge Broker provides intelligent data routing functions at the edge between the smart home and services, thereby transmitting data more efficiently. Furthermore, the advantages of the Smart Edge Broker are highlighted when providing a wide range of IoT services.
The Smart Edge Broker functions as part of the configuration of the smart city as described above. Figure
Scenarios for service routing in the Smart Edge Broker: (a) scenario for collecting data from sensors; (b) scenario for collecting selective data from sensors; and (c) scenario for filtering unnecessary data from sensors.
First, the latency between the sensor and the service can be reduced. In general, the sensor must send data through a central data center to the service. For example, in Figure
Secondly, the Smart Edge Broker can distribute the load on the data center. For example, as shown on the right side of Figure
Finally, the scalability of the service can be further extended. Unlike Figure
The Smart Edge Broker receives data requests or receives data from services and sensors through messages. A query is a criterion to classify the data transmitted from the sensor and is a medium to select the data to receive. Therefore, a query is the most important element among the elements of the Smart Edge Broker. A topic also explains data information, so it becomes an important clue for routing data together with a query.
When processing, the query attached to a topic is stored separately. When checking receivers, the separately stored query conducts an additional search for whether it is suitable for the query in the message and filters data according to the query. At this time, it must transmit the data only if the data is suitable. If this is expanded further, it is possible to configure the data transmission process of an IoT Sleep care service, as shown in Figure
Function of the Smart Edge Broker.
As shown in Figure
There is a fixed rule in the form of a query statement in each message. According to this rule, the Smart Edge Broker analyzes the payload and processes it. At the end of the topic, “query?” is added after the identifier. For example, only the data for the user called “KIM” are wanted in the topic called “/RFID,” and the topic type is defined in the form of “/smarthome/sleep/query?user = kim.” DataPub messages are configured in the JSON form to search data. In other words, it must be in the form of {“Key”: “Value”}, but Key specifies the search target of the query so that Value has search values. To process such queries, the following specific process is needed. If an IoT sleep care service transmits data through the Smart Edge Broker, it must transmit messages in the form as shown in Tables
Smart Edge Broker message definition: QueryReq message.
Header | Byte | Description |
---|---|---|
Fixed | Byte 1 | MQTT control packet type (8) |
Byte 2 | Remaining length | |
Variable | Byte 1 | Packet identifier MSB |
Byte 2 | Packer identifier LSB | |
Byte 3 | No properties | |
Payload | Byte 1 | Payload length MSB |
Byte 2 | Payload length LSB | |
Byte | Subscription options (1) |
Smart Edge Broker message definition: DataPub message.
Header | Byte | Description |
---|---|---|
Fixed | Byte 1 | MQTT control packet type (3) |
Byte 2 | Remaining length | |
Variable | Byte 1 | Packet identifier MSB |
Byte 2 | Packer identifier LSB | |
Byte | Payload length MSB | |
Byte | Payload length LSB | |
Byte | Topic filter + query | |
Payload |
As shown in Tables
To express the process in the previous example in detail, the operating algorithms of the IoT sleep care service, the Smart Edge Broker, and smart home system can be configured, as shown in Figure
Function of the Smart Edge Broker.
First, the IoT sleep care service on the right transmits the data request message to the Smart Edge Broker through a QueryReq message. The smart home system on the left is in the home of a user who receives an IoT sleep care service and transmits the sleep environment measured by sleep sensors to the Smart Edge Broker in the middle through a DataPub message. The Smart Edge Broker analyzes the message in the middle and routes the data message to the IoT sleep care service through the DataPub message. The Smart Edge Broker consists of two modules: a query analyzer and a context-aware filter. These two modules process QueryReq and DataPub messages, as shown in Figure
Smart Edge Broker activity diagram.
The query analyzer separates the payload of a topic and query from a QueryReq message transmitted from an IoT sleep care service and stores them in a message database so that they can be used for filtering later. The context-aware filter receives a DataPub Message from the smart home system and analyzes the topic and payload data to check whether the data are suitable.
After receiving a QueryReq message, it checks whether the query is included in the topic name. If it is included, it separates the topic name into topic and query and stores them in a message database. This is to use it as a criterion for filtering when a DataPub message is received later. However, if the query is not included, it does not perform any task.
Also, when a DataPub message is received, the context-aware filter filters data by checking whether the topic name of the message is in the message database. It retrieves the query and topic stored in the message database during the filtering process. This is carried out to use the query and topic as a criterion for analyzing the payload of a received DataPub message. If the two payloads do not match, it transmits a message to QueryReq. If filtering is not necessary because the payload is not registered in the message database, it transmits a message to all those registered. If it is registered but not suitable for the query, it does not transmit a message.
For a better understanding, the operation of the Smart Edge Broker is shown in a sequence diagram in Figure
Smart Edge Broker sequence diagram.
First, the IoT Sleepcare service on the left sends a QueryReq message to the Smart Edge Broker. This message is for requesting data of the user “kim” among data with the topic “sleep.” The Smart Edge Broker receives the message and analyzes the message using a query analyzer. It analyzes the topic filter and query contained in the message and saves it in the message database. The saved topic filter and query are used to screen out data later.
After that, the smart home system sends a DataPub message to the Smart Edge Broker to send the measured data to the service. The DataPub message contains a payload along with a topic and is divided into a “User” item and “Data” item to use Query. The “User” item in the payload contains the user’s name “kim,” and the “Data” item contains the sleep information measured during the user’s sleep.
The Smart Edge Broker analyzes the received Datapub message through the context-aware filter. The context-aware filter loads topics and queries from the message database to analyze the received messages. These topics and queries are extracted from previously received QueryReq messages, and they can be mixed with topics and queries received from other services besides the IoT Sleepcare Service. The context-aware filter analyzes the Datapub message and checks whether there is a corresponding request among the services that sent the QueryReq message. If there is a QueryReq request that matches the DataPub message, the Datapub message is delivered to the service that sent the QueryReq message. In this process, the data in the message can be processed or sent as is.
This series of processes allows the IoT Sleepcare service to collect sleep data from the smart home system and provide sleep care services to users through the collected data. This can be performed in 1:
We implemented and tested the Smart Edge Broker in the next chapter to see the abovementioned effects in the smart city environment.
To check whether the Smart Edge Broker can solve the problems that may occur when it is applied to the configuration of a smart city, we configured two experiments: a latency measurement experiment and a load measurement experiment.
These experiments were conducted under two conditions in the same experimental environment. Under the first condition, the IoT sensor transmitted data to the IoT service server through the Smart Edge Broker. At this time, the data to be transmitted were randomly set so that the Smart Edge Broker could filter 30% of data. Under the second condition, the IoT sensor transmitted data to the IoT service server through the data center. In both cases, four IoT sensors simultaneously transmitted 140 bytes of data, 10 times per second, and a total of 4000 data were transmitted for 100 seconds. The measurement started when all the sensors started to transmit the data.
Experiments are proceeded in an environment as shown in Figure
Smart Edge Broker experimental testbed: (a) configuration of the testbed; (b) actual configuration of the testbed.
First, we divided the experimental environment into three areas, as shown in Figure
The experimental results are as follows. Latency measurement experience measured Round Trip Time (RTT), which is the time when each IoT sensor sends data to the IoT service server and receives responses. Graphs and representation of the measuring results are shown in Figure
Smart Edge Broker experiment results: latency time between the source sensor and destination sensor.
For latency, the time spent until each message reached the service was measured. When the Smart Edge Broker was not used (without the SEB), the average latency was 31.41 ms. In contrast, when the Smart Edge Broker (with the SEB) was used, the average latency was 8.83 ms, with a decrease of about 72%. This was mainly caused by network latency that occurred in the process of transmitting data to the IoT service server through the data center, which was 4 km away from the IoT sensor. In both experiments, the latency instantaneously increased due to the declining function of Raspberry Pi 3, which was used as an IoT sensor. As a result of analysis, it was found that performance throttling was activated during the generation and transmission of messages due to the increased temperatures of the Cortex-A53 CPU cores mounted on Raspberry Pi 3. Since this was not a network problem but a device performance problem, it did not affect the experiment’s results.
For CPU usage of the data center, the CPU usage of the server process was measured at 1-second intervals during message transmission. As seen in Figure
Smart Edge Broker experiment results: CPU load rate for the data center.
For the CPU usage of the service server, the CPU usage of the server process was measured at 1-second intervals during message transmission. As shown in Figure
Smart Edge Broker experiment results: CPU load rate for the service server.
In this paper, by proposing a Smart Edge Broker, we could solve the latency and overload problems that may occur during the process of using an IoT service through a smart home system and smart city platform. This is a method of analyzing and filtering the data using topic and query and routing it to the proper location.
To find out whether the proposed Smart Edge Broker could control network traffic by analyzing the payload of data, we conducted experiments to compare two cases: when the Smart Edge Broker was used and when it was not used. In the latency measurement experiment, the latency was reduced by 72% when the Smart Edge Broker was used compared to when it was not used, and the CPU load rate was reduced by 63% in the load measurement experiment. It was also found that sensors or services could be conveniently added to the existing system using the characteristics of the Smart Edge Broker, even if a sensor or a service was added to an existing system, which indicates service scalability. In addition, the Smart Edge Broker works on the application layer, so that engineers can easily handle it.
However, further studies on security are needed. When searching for items corresponding to the Smart Edge Broker according to the 10 recommendations for security specified by the OWASP [
The data used to support the findings of this study are available at
The authors declare that there are no conflicts of interest regarding the publication of this paper.
This work was supported by the Technology development Program funded by the Ministry of SMEs and Startups (MSS, Korea) (Grant no. S2798371). This work was supported by the Gachon University Research Fund of 2019 (GCU-20190787).