Common Service Discovery Scheme in IoT Environments

Transcription

1 , pp Common Service Discovery Scheme in IoT Environments Joosang Youn 1 * and TaeJin Lee 2 1 Dept. of Industrial ICT Engineering, Dong-Eui University 176, Eomgwangno, Busan jin-gu, Busan, 47340, South Korea 2 Broadwave Corp., #1009, R&D Tower, 396, World Cup buk-ro, Mapo-gu, Seoul, Republic of Korea Abstract. Recently, many IoT applications are developed in heterogeneous IoT environment, in which there are various IoT devices with various kinds of network interfaces. They use different service discovery protocols. Thus, the interoperability between IoT devices using different service discovery schemes is supported in heterogeneous IoT environment. In this paper, the common service discovery scheme (CSDS) is proposed to provide general service management and the interoperability of service discovery at application-level in heterogeneous IoT environments. Through the simulation, we show that the proposed CSDS has lower overhead than DNS based scheme and can support the interoperability between different service discovery. Keywords: Service Discovery, heterogeneous IoT. 1 Introduction Recently, many IoT applications are developed in heterogeneous IoT environment which consists of various kinds of network interface enabled IoT devices. Thus, IoT gateway is used for interconnection between difference network interface enabled IoT devices. For example, in the case of home automation application IoT gateway is used to provide interaction and interconnection between IoT devices with various kind of wireless access technology. Also, home automation application environment consists of IoT devices with various kinds of offered service. These may have different service discovery protocol. Thus, IoT gateway should have the capability of service discovery between IoT devices which have different service discovery mechanism. Thus, in this paper, we propose the common service discovery scheme which can support the interoperability of divers service discovery protocols. The remainder of the paper is structured as follows. The research motivation and problem statement are presented in the next Section. In Section 3 we define the proposed common service discovery scheme (CSDS) at application-level. Finally, a performance evaluation is provided in Section 4, whereas conclusive remarks are drawn in Section 5. * Corresponding author ISSN: ASTL Copyright 2018 SERSC

2 2 Research Background and Problem Statement 2.1 Existing service discovery scheme Up to now, there are existing many service discovery. In particular, existing many service discovery protocols can be classified according to IP-based or Non-IP based transport mechanism. In IP-based discovery protocols there are CoAP RD [1], DNS- SD [2] and CoAP Discovery [3]. On the other hand, in Non-IP based discovery protocols, there are Zigbee [4] and SDP (BlueTooth) [5]. According to the topology which uses service and device directory or not, CoAP RD, DNS-SD, SSDP based UPnP and SLP are in a centralized approach. CoAP Discovery and SDP (BlueTooth) are in a distributed approach. Finally, SLP, Zigbee and SLP are in a Hybrid approach. 2.2 Problem statement related on the interoperability between any service discovery protocols Figure 1 shows the simple usecase which describes the need of interoperability of divers service discovery protocols in heterogeneous IoT service environment where there is IoT gateway for multiple interfaces support and protocol conversion at device layer. Bluetooth enable IoT device (speaker) is non IP enabled device and Wi-Fi enabled IoT device (sound player) is IP enabled device. In the usecase, service discovery protocol used in both devices is different. In addition, both devices can be connected with IoT gateway and estimate communication link between two devices through IoT gateway. Thus, in the situation, Bluetooth enable IoT device and Wi-Fi enabled IoT device does not know the offered service of each other. Because the service discovery protocol enabled in each other differs. Fig. 1. The simple usecase for describing the need of interoperability of different service discovery protocols in heterogeneous IoT environment Copyright 2018 SERSC 29

3 3 Common Service Discovery Scheme (CSDS) In the paper, the network model is assumed as shown in Figure 1. As shown in Figure 2, in the network area covered by the IoT gateway, IoT devices have different network interfaces and different service discovery protocols. In addition, because IoT gateway does not have common function about service management to collect the offered service of IoT device and propagate the collected information to IoT devices. Thus, each IoT device does not detects service-type enabled in each other. In this paper, we propose the common service discovery scheme (CSDS) to support general service management at application-level. The proposed CSDS includes both the service advertisement function and the service discovery function, which is to support the service discovery between IP based service discovery protocols enabled IoT device and non-ip based service discovery protocols enabled IoT device inside IoT gateway, through IoT gateway. The CSDS is implemented with basic CoAP protocol. CoAP mechanisms are currently being considered by the application protocol in IoT environments. And CoAP has resource discovery mechanism using resource directory (RD). In this paper, we propose the CSDS using service directory (SD) modified with CoAP based RD. In the CSDS, with CoAP, a service is defined by the four-information {protocol, host, port, service-type}, that is, a service-type represents a pre-defined service of IoT device. In addition, the service-type can be identified by a URI. For example, service-type may be expressed as coap://[2001::11]:5683/sensor/video. And the statue of service-type is acted upon with CoAP methods. The service offered by IoT device in SD is defined by the tuple {service-type, type (protocol)}, e.g., {video, wifi} The name of service-type is usually defined with the service-name using by service discovery protocol. Once a service in an IoT device is enabled, IoT device has to register its service within the service entity of the SD. In the CSDS, IoT device can create SD entity within IoT gateway to register its service-type. Thus, with the CSDS, all services offered by all IoT devices within service area covered IoT gateway can be registered automatically in SD entity of IoT gateway. In order to use the SD either for registration or for performing a lookup, the IoT device must first know how to reach the SD, i.e.. First at all, IoT device registers the service-type within the service entity of the SD by performing a POST request message (i.e., /sd) to IoT gateway by a URI. If the registration is successful, the SD returns the path to the end-point where its Fig. 2. Service Registration Process Fig. 3. SD lookup Process 30 Copyright 2018 SERSC

4 service-type are located (i.e., /sd/service-type). The SD may also proactively discover the service of the different servers using CoAP method. When a client wants to perform a lookup of a service in the SD to find out which servers implement a certain service, it has to use GET request of CoAP to the SD. For this, the client utilizes a specific query to only obtain those results that match the client s interest. As an example, in Figure 3, a IoT device queries the SD to return those registered service-type (i.e., lookup servicetype). In order to issue the query, the location of the directory should be known and obtained following the process as described in Figure 2. Because a query to the SD directly returns a CoAP service. Finally, with the help of CoAP SD, the CoAP services (end-points) or domains can also be discovered with the lookup types dt (device type) or d (domain) respectively (note that this is only defined for the directory based lookups and not available for the distributed resource discovery). 4 Performance Evaluation In this section, to evaluate the performance of the CSDS, a key metric of interest, including control message overhead is used. In addition, we show the performance of the proposed scheme compared with both previously proposed DNS based scheme modified with resource discovery scheme in DNS via extensive simulations in NS (Network Simulator)-3. For these experiments, we utilized the simple scenario shown in Figure 1. In addition, the results include only the overhead introduced by CoAP and DNS protocols, not considering UDP and IPv6 headers. As shown in figure 4, the simulation result demonstrates that the proposed CSDS has lower overhead than DNS based scheme and can support the interoperability between different service discovery protocols. Fig. 4. The overhead of the CSDS and DNS based schemes Copyright 2018 SERSC 31

5 5 Conclusion In this paper, the common service discovery scheme (CSDS) is proposed to support general service management at application-level in heterogeneous IoT environments. As explained up, although various kind of service discovery schemes exist for existing networks, they cannot support the interoperability between different service discovery schemes and thus be suitable for heterogeneous environments. Furthermore, some existing discovery protocols specifically designed for low power networks have limited interoperability. And they are just designed to be not worked at the gateway level. By comparison, the proposed SCDS provides higher efficiency for service discovery in terms of lower overhead. On the other hand, DNS has the advantage of compatibility for traditional networks. The simulation result demonstrates that the proposed SCDS has lower overhead than DNS based scheme and can support the interoperability between different service discovery protocols. Acknowledgments. This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (No. R ). References 1. Z. Shelby and S. Krco. CoRE Resource Directory. (IETF I-D work in progress), [Expires December 2013]. 2. S. Cheshire and M. Krochmal. DNS-Based Service Discovery. RFC ISSN: , Internet Engineering Task Force, February IETF CoRE Working Group. 4. Zigbee Specification. ZigBee Document r17, January Bluetooth Service Discovery Application Profile (SDAP) HowTechnologyWorks/ProfilesAnd.Protocols/SDAP.htm [Last accessed October 2013]. 32 Copyright 2018 SERSC