Abstract
When developing IoT (Internet of Things) applications, context distribution is a key feature to support effective delivery of related contextual data obtained from things to all interested entities. With the advent of the IoT era, multiple billion devices can generate huge amounts of data that might be used in IoT applications. In this paper, we present a context distribution framework named SCondi utilizing the messaging service which supports MQTT—an OASIS standard IoT messaging protocol. SCondi provides the notion of context channel as a core feature to support efficient and reliable mechanism for distributing huge context information in the IoT environment. The context channel provides a pluggable filter mechanism that supports effective extraction, tailoring, authentication, and security of information.
1. Introduction
Context-aware computing, as a component of a ubiquitous computing [1–4], is a core technology that supports human-centric intelligent service using contextual information in real situations. As machine-centric world (M2M, machine-to-machine) [5, 6] is coming, the notion of context awareness supporting improved response ability plays an important role in the IoT since things connected to the internet have awareness/sensing ability in many cases [7–9].
The IoT which provides useful services combined with various IT technologies is considered to have the potential to change our world. The IoT is a future internet environment defined as a dynamic global network infrastructure [10]. Things with identities and intelligent interfaces can be active participants wherever they are enabled to interact and communicate. To support useful services based on the massive information related to these things, several technologies such as REST (representational state transfer) [11], MQTT (message queuing telemetry transport) [12, 13], XMPP (extensible messaging and presence protocol) [14], and CoAP (constrained application protocol) [15] are being studied for information delivery, message process, and communication protocol. Recently, the MQTT protocol has been adopted by OASIS (organization for the advancement of structured information standards) as a standard messaging protocol for the IoT.
With the advent of the IoT era, multiple billion devices can generate huge amounts of data that might be used in IoT applications. However, it is not an easy challenge to deliver these tremendous data at the right time, to the right place, and with the right quality. As one of the important components in context-aware computing, context distribution can be a key feature to support effective delivery of contextual data in the IoT environment [16]. As of now, although many research works on context distribution has been conducted, there is no standard mechanism for reliable and sophisticated context distribution in the IoT environment.
In this paper, we propose a context distribution framework named SCondi utilizing the messaging service which supports MQTT. SCondi provides the notion of context channel as a core feature to support efficient and reliable mechanism for distributing huge context information in the IoT environment. The context channel is an abstract communication channel which can reliably tailor and disseminate a collection of information to service providers. Based on the MQTT messaging service, the context channel provides a pluggable filter mechanism that supports effective extraction, tailoring, authentication, and security of information. In short, the context channel provides higher level abstract mechanism for information delivery as a transport medium of context-aware systems in the IoT environment.
2. Backgrounds
IoT is a future internet environment that focuses on machine to machine communication, referring to uniquely identifiable objects and their virtual representations. MQTT is a standard Internet of Things connectivity protocol that is designed as an extremely lightweight publish/subscribe messaging transport, considering limited computing power and poor network connectivity. The MQTT protocol is developed by IBM and chosen as standard by OASIS.
As HTTP has made a web to be an infrastructure that share information over the internet, MQTT is expected to be a key infrastructure that makes billions of embedded low price devices to go online. It is already widely used in a lot of embedded systems.
Mosquitto is an open source (BSD licensed) message broker that implements the MQTT 3.1, providing a lightweight method of carrying out messaging using a publish/subscribe model [17, 18]. Mosquitto is designed to fit messaging among machines such as low-power sensors, mobile devices, embedded computers, and microcontrollers, supporting various OS platforms such as Microsoft’s Windows, Apple’s OS X, and Linux family.
Context-aware computing is a core technology that supports human-centric intelligent service using contextual information in real situations. Context refers to a variety of information that can define the state of the real world’s entities, generally consisting of information such as entity identity, activity, status, time, and location [19]. Since many devices which can sense contextual information are getting connected to the internet, the context-aware computing plays an important role in the IoT.
3. Design of SCondi
In this section, we introduce a context distribution framework named SCondi which is based on a messaging service for the IoT, supporting smart and effective dissemination of context data. We begin by mentioning the core requirements for the context data distribution proposed by Bellavista et al. [20]. To satisfy the requirements, the context channel is provided with filter mechanism as a key facility for reliable context data distribution.
3.1. Key Requirements of Context Data Distribution
Bellavista et al. mentioned that context data distribution needs to meet following 5 requirements for providing an effective context-aware service in IoT environment.(1)Communication should be asynchronous and anonymous among context producers and consumers.(2)To support mobile heterogeneous and wireless scenarios, the context data distribution has to promptly adapt to mobility and current available resources.(3)The context data distribution must enforce visibility scopes of context data to avoid useless management overhead.(4)The context data distribution has to enforce QoC-based constraints for timeliness and reliability guarantees of data delivery.(5)The context data distribution has to handle data life cycle for self-control of the distribution process.
To satisfy the requirements, SCondi provides the following features. First, adopting MQTT as a messaging mechanism, our framework supports asynchronous and anonymous communication among message publishers and subscribers (satisfying (1)). Secondly, our framework provides effective mobility and reliable message delivery based on MQTT’s QoS (Quality of Service) in limited network environments (satisfying (2)). Thirdly, the context channel in our framework provides filter chain mechanism for the QoC constraints such as context data management, resource access control, data validation, and timeliness (satisfying (3) and (4)). Finally, it also provides common filters for general usage and customized filters through predefined interfaces (satisfying (5)).
3.2. Architecture of SCondi
SCondi has two key components: context channel and channel selector. The context channel is a transmission facility used to convey a collection of contextual data specified by the channel creator. The channel selector receives raw data from external data providers (e.g., sensors, SNS data, calendar data, email, etc.), spreading each raw context data to all the context channels that need the contextual data as their constituent, using the MQTT messaging facility as shown in Figure 1. To receive the required data, context channels should subscribe to the channel selector. When receiving the collection of the associated contextual data, the context channel delivers the collection of data to each subscribers of the channel after processing the collection of data with the filter chain through the MQTT messaging facility. In this way, the MQTT message delivery mechanism is used twice to pass the associated data to channel subscribers.
A topic with unique namespace in MQTT is allocated to each context channel. The topic manages the associated contextual data as subtopic, forming a hierarchal structure. In other words, A channel ID is assigned as a main topic while each contextual data is assigned as a subtopic separated by a “/” following the channel ID. Based on the MQTT messaging facility, SCondi provides decoupled one-to-many pub/sub through the context channel which allows any contextual data to be published once and multiple consumers to receive the collection of the needed contextual data.
In SCondi, a context is composed of a set of context primitives (CPs), where a CP is a set of related data that are used as a practical unity in applications. For instance, most elevators in the modern era have been fitted with several safety devices such as overload sensor, door sensor, fire sensor, gas sensor, cable sensor, and fault diagnosis module as shown in Figure 2. A manufacturer needs information such as equipped sensors and location of installed elevators for maintenance all together. In emergency situation, information such as floor, time, and location are required for the rescue service at the same time. As above, CP can be used effectively when information is commonly used or needed to be provided as a meaningful unit.
SCondi provides an authentication and authorization mechanism to manage access levels for context channels. To access a context channel, a subscriber should have a retrieval authority for the channel. For convenience of users, the framework supports three types of context channel according to the purpose of the application: open, access-limited, and group channel. An open channel allows everyone to access while an access-limited channel accepts the qualified subscriber who has the related access key. A group channel accepts the users authorized by the authentication module for the related group only.
To process contextual data with different characteristics depending on the purposes of context channels, we provide context channels with the filter chain mechanism. A filter chain is a collection of ordered filters. As a key feature to determine the characteristics of a context channel, the filter chain of the channel provides predefined filter interfaces to process contextual data. In addition, it allows pluggable filter adaptation which supports dynamic filter insertion/removal without interruption of service during run-time. For the effective run-time channel configuration, the framework uses the concept of ownership to context channels.
3.3. Context Filter for Quality of Context
QoC (Quality of Context) is a very important factor to be considered for the context data distribution efficiency and reliability. Traditionally QoC has focused on the quality of data only. Recently, to ensure the availability of data with the right quality, in the right place and at the right time, many related studies concentrate on complex characteristics such as data transmission time, data reliability, data accessibility, data refreshment/up-to-date, and data precision. In other words, QoC must be considered depending on the purpose of the services. To reflect these aspects, SCondi provides filter chain mechanism that allows filters to be applied for supporting QoC in context channels.
A filter changes original contextual data to qualified data according to QoC criteria. Also, as shown in Figure 3, filters can be logically combined to create more complex subscriptions patterns depending on the characteristics of context channels. In other words, filter chain mechanism helps to reduce bandwidth and to enhance scalability and to increase QoC for context distribution in the IoT environment. Our framework provides common filters that can be commonly used in context channels for QoC constraints such as value_range, time, value_changed, and average filter.(1)The value_range filter passes values only within a certain range.(2)The time filter passes values within a specific time period.(3)The value_changed filter passes values different from previous values.(4)The average filter calculates the average value with the specified condition, transmitting the calculated value.
In addition, SCondi provides predefined interfaces to create a custom filter and to manage filter chain apart from the common filters.
4. Implementation of SCondi
In this section, we explain the implementation of context distribution framework to support reliable delivery of context data. SCondi is implemented with Java program language, using Mosquitto as the MQTT message broker to support efficient and reliable messaging. The context channel provides a filter chain mechanism through the filter interface and the filter chain interface. The filter interface provides execute() to process contextual data through a specific filter as shown in Table 1. To pass the processed contextual data to the next filter in the filter chain, it provides nextFilter(). Additionally, as shown in Table 2, it provides the filter chain interface to add, delete, and replace a filter in a chain. The filter chain interface provides addFirst(), addLast(), addBefore(), and addAfter() to add filters at a specific position in a chain. It also gives delete() to remove filters and replace() to replace filter with a new one. Lastly, It provides invoke() to execute the filters of the chain in order. In this way, the context channel can be configured to have various characteristics depending on the ordering of filters. A context is defined by a set of CPs as described in Algorithm 1.
| ||||||||||||||||||||||||||
Algorithm 2 shows an example of using a filter chain. In this case, the associated context channel executes AverageFilter for calculating average value of 10 recent weights of the underlying elevator. Then, ChangedValueFilter compares the calculated value with the previous average value. If the calculated value is not equal to the previous one, the context channel delivers the calculated value to subscribed applications.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
According to the rapidly increasing number of devices in the IoT, both context channels and the channel selector can impose heavy overloads on a single MQTT message broker. Thus, SCondi uses 2 message brokers for the channel selector and context channels, respectively. A topic of the first Mosquitto message broker (for channel selection) is assigned to each source of contextual data which is provided by the external context adapter. The channel selector manages a contextual data and the associated channels through the context-channel mapping table, publishing the data to the message broker through the assigned topic. To subscribe a specific contextual data, each context channel should request a subscription of the associated topic to the message broker. After acquiring the approval from subscription authorization, the context channel can receive the interested data from the message broker by subscribing to the associated topic.
After processing the received data through its filter chain, the context channel publishes the specified set of data to the second message broker (for end user delivery). To receive the set of interested contextual data from the context channel, end user applications should subscribe to the context channel. Our framework also provides the management facility for subscription permissions on context channels. In addition, the channel provides the context-filter mapping table to manage each context data and its related filters. The channel supports 2 types of filter: global filter and local filter. Whole context data in the channel is affected by the global filter while local filter is applied only to the specific context data based on the table.
5. Performance Analysis
Since SCondi provides higher level abstract mechanism for information delivery in the IoT environment, the qualitative effectiveness of our framework is very clear. So, we focus on the effectiveness in terms of quantity of delivered messages as illustrated in Figure 4. Whereas each data should be transmitted in an original MQTT message broker, all data in a CP can be passed as a single message through our context channel with appropriate setting. To show effectiveness of our framework, we compare the quantity of delivered messages in a formal way. For this, let us begin by defining the following terms: : total number of source data; : total number of CPs; : average number of source data in a single CP.Then, in case that every CP is used once by application, the amount of source messages can be written as In general, a source data can belong to multiple CPs. So we define denoting the average source data redundancy used for CPs: Let denote the total number of applications and denote average number of CPs in a single application.
For simplicity, assume that every application receives its needed data once for a certain period of time . Then, the total number of CPs used during time interval is Since a CP is generally required by multiple applications,we definethe average CP redundancy used for applications denoted by : Now, we can calculate the amount of all messages (denoted by ) passing through the original MQTT message broker: Applying (2) and (4) to (5), we have the following: Now, we measure the amount of all messages in our SCondi. We start by new terms and that denote the total number of channels in SCondi and the average number of CPs used in a single channel, respectively. We assume that every context channel receives its needed CP once for a certain period of time . Then, the total number of CPs passed during time interval can be written as Since a CP generally belongs to multiple context channels, which is the average CP redundancy used for channels can be defined by We assume that every application receives its needed CP once from the related context channels for a certain period of time . Let denote the average number of channels required in a single application. Since a context channel can belong to multiple applications, let us define meaning the average channel redundancy used for applications by Recall that each data should be transmitted in an original MQTT message broker while all data in a CP can be passed as a single message from context channels with appropriate setting. Now, we can count the amount of all messages (denoted by ) passing through SCondi during time period : Applying (2), (8), and (9) to (10), we have the following: Since the time required to transmit messages is fairly smaller than the time interval that applications require source data, we can assume without loss of generality. Now, we discuss the condition over which the amount of all messages passing through SCondi is less than the amount of all messages passing through original MQTT message broker. Consider Note that the condition should always satisfy to hold , since is always greater than zero. Consider In case that , (14) is equivalent to Since (by (2)), we finally have the following: To capture the meaning of conditions for , using a practical data, let us calculate the amount of total delivered messages in SCondi and that of MQTT broker. We assume that , , , and . For MQTT broker case, we assume the average number of CPs in a single application is 200. In SCondi, we assume that the total number of channels is 2000, the average number of CPs in a single channel is 50 and the average number of channels in a single application is 4. Table 3 shows the calculation of the total delivered messages in both cases. As a result, is 3000000 and is 1300000 when is 3. In this case, both conditions (13) and (16) “” and “” are satisfied, resulting in .
Figure 5 depicts the total amount of messages according to the value of under the same conditions. Considering the result, even in the aspect of the amount of total messages passing through, the concept of context channel is very useful and effective when CP is composed of two or more source data.
6. Conclusion
In this paper, we introduced a context distribution framework named SCondi that supports effective dissemination of context data through context channels. SCondi is based on two major components: channel selector and context channel. The channel selector sends each raw context data to each of the context channels that requires the contextual data, using the MQTT messaging facility which has been adopted by OASIS as a standard messaging facility for the IoT. The context channel provides a filter chain mechanism that supports effective extraction, tailoring, authentication, and security of information through various types of filters. Based on the MQTT messaging facility again, when receiving the collection of the associated contextual data, the context channel delivers the collection of data to each subscriber of the channel after processing the collection of data with the filter chain. In addition, SCondi supports three types of context channel according to the purpose of the application: open, access-limited, and group channel. We also showed that SCondi is very useful and effective both in quality and quantity of delivered messages. We believe that the novel concept of context channel and the presented framework can be very useful for context distribution in the IoT environment.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (no. 2013R1A1A4A01004459).