Design and implementation of application ... - Wiley Online Library

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt (2016) Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/nem.1936

Design and implementation of application programming interface for internet of things cloud Lu Hou,1 Shaohang Zhao,1 Xing Li,1 Periklis Chatzimisios2 and Kan Zheng1,, 1

Intelligent Computing and Communication (IC2 ) Lab, Key Lab of Universal Wireless Communications, Ministry of Education, Beijing University of Posts and Telecommunications, Beijing, China 2 Department of Informatics, Alexander Technological Educational Institute of Thessaloniki (ATEITHE), Thessaloniki, Greece

SUMMARY Internet of things (IoT) technologies have developed rapidly to provide various applications and services, which benefit much on both industrial production and human lives. Meanwhile, with the deployment of cloud computing, the requirements of computing and storage capabilities of IoT can be well supported. The well-designed application programming interfaces (APIs) are needed to offer good services of IoT cloud. APIs serve as the endpoints of services and offer convenient ways for either developers to design applications or vendors/OEMs to manufacture devices. In this paper, the design and implementation of APIs for IoT cloud is presented in detail. Taking the large number of resource-constrained IoT devices into account, we propose the different kinds of APIs with different application protocols. APIs offer integrations between server-side applications and client-side applications or devices; thus, the specific implementation of APIs on these three parts are presented. Finally, a number of experiments are conducted to evaluate the performance of the designed APIs, and the result analysis is given as well. Copyright © 2016 John Wiley & Sons, Ltd. Received 30 November 2015; Revised 5 April 2016; Accepted 5 May 2016

1. INTRODUCTION In Internet of things (IoT), thousands of objects or devices can be seamlessly connected together via device-to-device or machine-to-machine communications [1,2]; thus, they can work in cooperation with each other in an intelligent way [3]. The significant increase of data that is generated by IoT devices also promotes the progress of Fifth Generation (5G) for IoT [4]. In order to reach the full potential of IoT, cloud computing technologies have to be exploited and applied [5,6]. IoT cloud allows IoT devices to be interconnected with cloud infrastructures through the Internet. With the unlimited storage, computing, and network resources, IoT cloud offers the capability to manage large-scale concurrent connections for IoT [7,8]. Moreover, cloud can provide real-times data analytics by allowing IoT devices to offload computing tasks and huge amount of data [9,10]. Therefore, diverse applications and services can be well supported by IoT cloud [11]. Generally, services of IoT cloud can be enjoyed by customers via application programming interfaces (APIs) remotely. APIs can make necessary functionalities or data easier for developers to work with, enabling IoT cloud infrastructures and resources to be utilized and controlled by developers. In

Correspondence to: Kan Zheng, Intelligent Computing and Communication (IC2 ) Lab, Key Lab of Universal Wireless Communications, Ministry of Education, Beijing University of Posts and Telecommunications, Beijing 100088, China. E-mail: [email protected]

Copyright © 2016 John Wiley & Sons, Ltd.

L. HOU ET AL.

this way, applications of IoT cloud can be easily developed and deployed. APIs define the methods and data formats for clients and servers to interact with each other. APIs are acted essentially by programs that run on servers, while programs that run on client/device side need to be able to manipulate APIs. In this way, APIs integrate the applications on server side and on client/device side. In the meantime, APIs decouple the implementations of clients from servers; thus, services that are provided by servers can be enjoyed by clients that run on different platforms. Therefore, well-designed and properly implemented APIs are significant for minimizing the deployment time of applications and enabling cloud services for IoT [12]. To address this issue, this paper provides a detailed discussion on the design and implementation of APIs for IoT cloud. Both HyperText Transfer Protocol (HTTP) and Message Queuing Telemetry Transport (MQTT) protocols are supported by IoT cloud, in consideration of different services and devices. As a consequence, two kinds of APIs are designed, corresponding to each application protocol. With these APIs, HTTP-based services and MQTT-based services can be well provided for end-users. Furthermore, implementation of APIs on threes aspects, that is, servers, clients, and IoT devices, are discussed respectively. The interactions between servers and clients/devices using the designed APIs are also presented. Finally, several experiments are conducted to evaluate the performance of both web APIs, MQTT APIs, and application servers. The rest of paper is organized as follows. The state of the art of APIs have been investigated firstly in Section 2. Then, Section 3 proposes the specific design of APIs for IoT cloud with discussions on the services that IoT cloud can provide. Furthermore, implementation details of the designed APIs are presented in Section 4. Performance evaluation and results analysis are given in Section 5. Section 6 concludes the paper.

2. RELATED WORKS Services of IoT cloud are provided remotely that customers have to access to them through the Internet. As a consequence, applications of IoT cloud are often separated into two parts, that is, the server and client. By proper application protocols, the server and client can communicate and exchange data with each other. The server is responsible for providing APIs for client to manipulate. The client knows what resources are available and using APIs to get access to them. During this process, the server and client are integrated by APIs. Most commonly used application protocol is the HTTP, which works as a request–response protocol that client can submit HTTP requests to server, while server, which is often named as HTTP server and provides resources or exerts other functions on behalf of the client, returns response messages to the client [13]. APIs that underlie HTTP are often regarded as web APIs [14]. Using HTTP reduces the difficulties of designing and developing web applications. Besides, it has several features leading to building good APIs [15]. There are two most common structures for the design of web APIs, that is, Simple Object Access Protocol (SOAP) and REpresentational State Transfer (REST) [16]. SOAP defines a standardized structure for making requests and responses via web APIs. It neglects the semantics of the underlying protocol, which is usually served as by HTTP [17]. On the contrary, REST gives a set of constrains when designing web APIs [18]. For the feature of REST APIs, that is, simplicity, extensibility, and flexibility [19,20], it is chosen as the style of our design of web APIs. For the data that exchanged through APIs, the most common formats that are used in web APIs are JavaScript Object Notation (JSON) and Extensible Markup Language (XML) [21]. JSON is designed as an open-standard and light-weight message format that it uses a key-value pair to represent data. Different with JSON, XML uses node to structure data. Clients can choose which format is available for them by indicating the format in the HTTP request. Because of the ubiquity of HTTP, many researches focus on investigating issues of web APIs. However, in the interactions between HTTP server and client via web APIs, only clients can initiate requests to servers. A consequence of this situation is that changes are easy to send from the client Copyright © 2016 John Wiley & Sons, Ltd.

Int. J. Network Mgmt (2016) DOI: 10.1002/nem

DESIGN, IMPLEMENTATION OF API FOR IOT CLOUD

to the server but hard to do in the reverse direction. On the other hand, the computing and storage capabilities of IoT devices are usually limited, while the network bandwidth is not sufficient. Besides, they are likely to have shortage of energy. Therefore, dedicated message protocol is required for these devices in IoT cloud [22]. Constrained Application Protocol (CoAP) and MQTT protocol are qualified in this situation [23,24]. CoAP is specialized for constrained nodes and networks in IoT, while MQTT is designed as an extremely lightweight message transport protocol, which can be used to make the IoT devices interactive in constrained scenarios. MQTT has the ability to reduce sizes of the headers of messages that are transferred between connected clients and servers. It uses publish– subscribe messaging pattern to deliver information, within which a message broker is necessary to distribute messages to the interesting subscribers according to the topics that they subscribe [25]. In this regard, MQTT is used in our IoT cloud for message exchanging between IoT devices with servers/clients. Recently, several researches for enabling cloud services on IoT have been proposed. Comprehensive surveys of IoT cloud are given in [3] and [26]. Some others focus on specific applications based on IoT cloud platform [27–29]. As for the design, implementation, and usage of APIs, most of the studies focus on traditional web/mobile platforms, software, or other systems. For example, the research status of web APIs in World Wide Web is investigated in [30], while the design and implementation of REST APIs for an IP Multimedia Subsystem is proposed in [31]. In terms of APIs for IoT cloud, a few of studies have surely come up with their designs of APIs based on HTTP or CoAP. For example, a programming model for IoT cloud is proposed in [32] with applicable APIs. In [33], the designs of web APIs for their platform based on HTTP are proposed with specific performance evaluation, while authors in [34] proposed their design of APIs for an IoT cloud system based on CoAP. However, to the best of our knowledge, the detailed design and implementation of APIs based on both HTTP and MQTT protocols for IoT cloud remains a relatively empty field in the state of the art. 3. DESIGN OF API FOR IOT CLOUD The IoT cloud can offer diverse services that help software developers to design and run applications based on the IoT cloud infrastructure or vendors/Original Equipment Manufacturers (OEMs) to produce devices that can access to the IoT cloud. These services are deployed on two kinds of application servers in IoT cloud, that is, HTTP servers and MQTT servers. Each service contains several different functionalities, as depicted in Figure 1.

Figure 1. Types of services and design of APIs in IoT cloud. API, application programming interface; IoT, Internet of things; HTTP, hypertext transfer protocol; MQTT, message queuing telemetry transport Copyright © 2016 John Wiley & Sons, Ltd.


L. HOU ET AL.

3.1. Types of services and design of APIs Services that IoT cloud offers can be divided into two categories, that is, HTTP-based services and MQTT-based services, according to the different application protocols they adopted. In order to make customers able to enjoy the services, IoT cloud designs two kinds of APIs, that is, web APIs and MQTT APIs, corresponding to the types of services respectively. By making proper requests to servers, these APIs can be used by clients. 3.1.1. HTTP-based services and web APIs The HTTP-based services are provided for customers to exchange hypertexts between applications of clients and servers over the Internet. These services enable clients and devices to register, login, or logout IoT cloud by corresponding web APIs before further operations. Besides, clients have to bind devices via device binding before they can connect to them. Meanwhile, they can also release devices to free the relations with devices. As for devices, they have to use device provision to access to the MQTT servers. Moreover, over-the-air (OTA) for devices to upgrade their firmware is provided as a web API. With OTA, devices can send requests to HTTP servers for the latest firmware version. After that, servers can respond the devices with the version number and uniform resource locator (URL) on which firmware software can be downloaded; thus, devices can upgrade their firmware conveniently. The specific design of web APIs is shown in Table 1. Web APIs demand the request message to consist of four parts, that is, request, HTTP header, an empty line, and messages (optional). An example of a request via user register is shown as follows, that is,

An HTTP method, URL, and version number form the request field of a request message. Among all the request methods that are defined in HTTP [13], only GET, POST, and DELETE are used in IoT cloud because these three methods can meet most of the requirements of operations. GET method allows clients to acquire information or data from servers, while POST enables clients to send data to servers. DELETE method can delete the resource that clients specified. URL helps clients to locate the resource as it shows the location of the resource. To be RESTful, each resource or data shall have a unique URL over the Internet. A URL consists of domain name and the endpoint of API. Designing proper URLs is one of the main part of the design of APIs, because it can reflect the hierarchy structure of data that APIs can offer. The HTTP header includes some parameters that shows the used data format and connection type. Some other parameters can be added in this field; for example, clients can indicate servers which data format is available for response message. The optional messages field includes information that is needed to be delivered to servers. They are usually padded in the end of the request.




POST POST GET POST DELETE POST GET GET

Device registration

User login

Device listing

Device binding

Device release

Timer setting

Device provision

OTA

dev/ota/version/update _and_check/uid

DID

timer

unbind

list_device /?uid=xx bind

user_login

dev/devices

user_register

Endpoint of URL

MQTT server address and port UID and passcode

Time and repeated date

DID

UID and DID

UID

Product key, MAC address, and passcode Username and password

Username and password

Parameters

201/400, . . .

5000/5001, 5002, . . . 8000/8001, 8002, . . . 6000/6001, 6002, . . . 7000/7001, 7002, . . . 9000/9001, 9002, . . . 201/400, . . .

1000/1001, 1002, . . . 201/ 400, . . .

Status code

Version, downloading url

—

—

—

—

Device list

—

DID

UID token

Return values

Clients register to IoT cloud Devices register to IoT cloud Clients login to IoT cloud List all devices that are bound by the given UID Clients bind devices with specific DID Clients release bound devices Clients set timer to control switches of devices Devices obtain addresses and ports of MQTT servers Devices update firmware

Role

MQTT, message queuing telemetry transport; API, application programming interface; IoT, Internet of things; OTA, over-the-air; DID, device ID; UID, user identification; MAC, media access control.

POST

HTTP method

User registration

API name

Table 1. Examples of web APIs designed for IoT cloud



L. HOU ET AL.

The HTTP servers need to send back a response to clients for each request. A response message includes a status code and data (optional). With the status code, clients can be informed of the status of the request. Optional data can be attached to the response on condition that clients require for it. An example response message is shown as follows, that is, Different web APIs are assigned different status codes; some of which are predefined in HTTP [13]; others are specially designed for IoT cloud. These codes can help clients to analyze the responses in an easy way. Whether the requests are successful or failed is reflected by the last number of status code. The number ‘0’ stands for success, while other numbers stand for failure. If the request fails, clients can be able to identify the type of errors via the last number; for example, ‘1001’ means that the necessary information of the requests are incomplete, while ‘1002’ represents that something is wrong in HTTP servers. The predefined status codes are typically put to use for devices for extensibility. Code 200 means the requests are handled successfully, while code 201 means new device is created. Furthermore, code 400 means that the requests from devices are incomprehensible for servers. 3.1.2. MQTT-based services and MQTT APIs In support of resource-constrained IoT devices, MQTT-based services are offered typically for the communications with these devices via MQTT protocol. MQTT servers enable end-users to send commands to the resource-constrained devices, while these devices can report their status to the servers. APIs that perform the functionalities of MQTT-based services are referred as MQTT APIs. Different with web APIs, MQTT APIs are invoked via sending and receiving control packets between MQTT servers and clients/devices [24]. Several control packets are defined in MQTT protocol, such as CONNECT, CONNACK, or SUBSCRIBE. MQTT APIs re-encapsulate control packets and offer more friendly interfaces for consumers. The design of MQTT APIs are shown in Table 2, as well as the corresponding relations with control packets. Clients or devices can establish connections to MQTT servers via connect, which is in essence sending CONNECT packets to MQTT server. After receiving the CONNECT packets, MQTT servers can send back CONNACK packets to inform clients or devices that the connections are setup. Because that subscribe–publish pattern is adopted in MQTT servers, clients or devices need to subscribe topics that they are interested in before receiving messages. Similarly, MQTT servers send SUBACK packets back to them as the acknowledgement of successfully subscribing. Clients or devices can also publish messages on certain topics; thus, others who have subscribed these topics can receive the messages. OTA are also included in MQTT APIs, which allows IoT devices to make flexible choices, either by HTTP server or MQTT server, when upgrading. On the other hand, MQTT servers need to keep long connections with clients and devices; thus, they need to monitor the states of the connections periodically. This process is regarded as heartbeat detection. A typical MQTT API is designed for heartbeat detection, that is, ping. With ping, clients and devices can report the current states of the connections to MQTT servers. By receiving the PINGREQ message, MQTT servers can be aware that the connections are alive.

Table 2. Design of MQTT APIs for IoT cloud Types of MQTT APIs connect subscribe unsubscribe publish OTA ping disconnect

Parameters

Request control packet

UID/DID, CONNECT password/passcode Topic SUBSCRIBE Topic Topic, message DID — —

Response control packet CONNACK SUBACK

UNSUBSCRIBE UNSUBACK PUBLISH PUBACK — — PINGREQ PINRESP DISCONNECT —

Role Clients or devices create connection to MQTT servers Clients or devices subscribe topics Users or devices unsubscribe topics Clients or devices publish messages Devices update firmware Heartbeat detection Disconnect with MQTT servers

MQTT, message queuing telemetry transport; API, application programming interface; IoT, Internet of things; OTA, over-the-air; DID, device ID; UID, user identification. Copyright © 2016 John Wiley & Sons, Ltd.



4. IMPLEMENTATION OF APPLICATION PROGRAMMING INTERFACES One of the main functions of APIs is to integrate servers and clients/devices. Thus, two kinds of programs in servers and clients are needed together to implement APIs separately. APIs are actually provided by programs at server side. They await the clients to ask it for data. On the other hand, programs at client side can manipulate APIs and acquire data through it. 4.1. Implementation of application programming interfaces for servers For the purpose of high concurrency and real-time performance, Node.js is used to build both HTTP servers, MQTT servers, and server-side applications that are running on them. Node.js uses a nonblocking input/output model to ensure high-performance for application servers [20,35]; thus, millions of clients or devices can be connected to a single machine in IoT cloud. In both HTTP and MQTT servers, each API has a listener that can monitor the states of invocations of the API. The URL or type of MQTT packet leads the coming request to the proper API, triggering the listening event of the listener. After that, the process of the request is inserted in an event queue at the subsequent position that the event handler would handle the event next to the current event. The processing approach of each API is defined as a callback function, which can be executed by the event handler when the event is triggered. For example, when the user registration is called, the callback function of this API is executed that HTTP server stores the username and password in database and responds with a user identification (UID) to the clients. However, the underlying process of parsing data packets are different between web APIs and MQTT APIs. In HTTP servers, data packets from the transmission control protocol (TCP) layer are parsed as HTTP packets, where HTTP headers are recognized. Nevertheless, MQTT servers can support MQTT connections as well as WebSocket connections, as illustrated in Figure 2(b). MQTT connection is used for ordinary clients or devices, while WebSocket connection is provided for web browsers or some third-party platforms. Three tiers of headers of data packets by WebSocket need to be parsed, that is, HTTP header, WebSocket header, and MQTT header, before acquiring the payload. 4.2. Implementation of clients In order to obtain the needed data, clients have to make proper requests to application servers. There exist three kinds of clients in IoT cloud, that is, web applications, mobile applications, and third-party platforms. These clients run on different platforms but use the same APIs to enable end-users to enjoy services of IoT cloud. 4.2.1. Web applications Web applications run typically in web browsers, which are most widely used for end-users to surf the Internet. Web applications are generally deployed as web pages. These web pages are created by hypertext markup language, cascading style sheets, and JavaScript. Hypertext markup language and cascading style sheets are used to build static web pages, while JavaScript defines the actions towards end-users’ behaviors. For example, when end-users click the hyperlink that query the information of bound devices, JavaScript programs can generate requests whose formats and contents are defined by device listing and send these requests to HTTP servers. This process is realized by Asynchronous JavaScript and XML (Ajax), which is designed to enable clients to exchange data with servers asynchronously. Ajax is invoked by using a popular library of JavaScript, which is known as jQuery. By using Ajax, the requests can be sent to servers without interrupting the existing pages. HTTP servers usually respond to the web browsers with the web pages that can be parsed and displayed to the end-users or developers. In this way, end-users and developers can acquire the information they need. The IoT cloud mainly offers management functions for end-users to manage devices that are bound to their mobile apps and for developers to debug application programs by web applications. A web API, that is, device listing, is designed in IoT cloud for these functions. With device listing, endusers can view the detailed information of the bound devices, such as running statuses. On the other Copyright © 2016 John Wiley & Sons, Ltd.


L. HOU ET AL.

Figure 2. Implementation of APIs. API, application programming interface; MQTT, message queuing telemetry transport; URL, uniform resource locator; HTTP, hypertext transfer protocol hand, developers can examine the information of both the end-users that are using the applications and the devices that are controlled by the applications. Besides, developers can query the binding relationships between these end-users and devices, which can help developers to modify programs in a proper way. 4.2.2. Software development kits and mobile apps For the convenience of developing mobile applications, client libraries that contain the implementation codes of client side of APIs are provided for developers. These libraries are bundled in the software development kits (SDKs) or just individually available. Generally, two kinds of SDKs over two of the most popular mobile operating systems (OSs), that is, Android and iOS, are offered. Android SDK is implemented via Java, while iOS SDK uses Objective-C and Swift that are designed by Apple Inc. With these SDKs, a lot of time can be saved for developers because they have no need to generate raw requests or messages but calling the existing and user-friendly interfaces in SDKs. The example interactions between mobile applications and application servers using the APIs are shown in Figure 3. End-users who are using mobile applications on their smartphones can register to IoT cloud by user registration. Similar with the process in web browser, username, and password are needed for registration. After that, end-users can login to IoT cloud. By receiving the requests, HTTP servers can assign unique UIDs and tokens for apps as the identifiers. With the UIDs and tokens, mobile apps can connect to MQTT servers. On the other hand, mobile applications can use web APIs to bind devices, after which data exchanging with these devices can be realized. Moreover, end-users can set timers via timer setting to make devices finish tasks at specific time. For example, by setting certain time and repeated period, switches of devices can be triggered automatically and repeatedly. Copyright © 2016 John Wiley & Sons, Ltd.



Figure 3. An example of interactions between mobile applications with application servers. MQTT, message queuing telemetry transport; HTTP, hypertext transfer protocol; UID, user identification 4.2.3. Third-party platforms Some third-party platforms become more and more popular, such as WeChat or Facebook. They usually have a large number of users. In order to enable these users to enjoy services of IoT cloud, thirdparty platforms can also invoke APIs of IoT cloud; thus, they can integrate services of IoT cloud into their platforms conveniently. Therefore, people can enjoy services over these platforms without using the dedicated applications of IoT cloud. Take WeChat as an example, by using web APIs and MQTT APIs, clients of WeChat can access to the IoT cloud and do the same things that the mobile applications can do. However, the connections between clients of WeChat and servers are established based on WebSocket protocol, aiming at enabling two-way communications between clients and servers [36]. As a result, WebSocket becomes indispensable in IoT cloud to work as the application protocol for clients of WeChat to interact with IoT cloud. 4.3. Implementation of Internet of things devices Vendors can design and produce devices that can access to the specifically designed APIs. Because of the ubiquity and large number of devices, IoT cloud needs to distinguish them easily. Generally, IoT devices are equipped with Wi-Fi modules, which enable devices to access to IoT cloud through the Internet. The main component of one Wi-Fi module, that is, Wi-Fi network interface controller, has a unique media access control (MAC) address, which is designed to identify the location of the device in the networks. Because of the uniqueness of MAC address, it can be used to differentiate device from others. On the other hand, vendors/OEMs use one product key to identify one kind of device. Moreover, a series of passcodes are embedded in devices, which are used for IoT cloud to verify identifications of devices that have registered to the cloud. With MAC address, product key, and passcode, IoT cloud can generate a unique device ID (DID) to identify devices accurately. Devices can obtain their DIDs from HTTP servers via registration process. The interactions between IoT devices with application servers are shown in Figure 4. In order to access IoT cloud, new devices need to register to HTTP servers via device registration at first. MAC Copyright © 2016 John Wiley & Sons, Ltd.


L. HOU ET AL.

Figure 4. An example of interactions between IoT devices with application servers. IoT, Internet of things; MQTT, message queuing telemetry transport; HTTP, hypertext transfer protocol; DID, device ID; OTA, over-the-air addresses, product keys, and passcodes are all needed to be sent to HTTP servers in this process. HTTP servers then generate the DIDs for the devices and send them back as the responses. After that, devices have to connect to MQTT servers before they can communicate with users. Therefore, they have to send requests for provision via device provision to obtain the addresses and ports of MQTT servers, which is stored in HTTP servers. Then, devices can create connections to MQTT servers with their DIDs and passcodes. These connections need to be persistent; thus, devices can exchange messages with end-users via subscribe and publish continuously. Two main topics, that is, ‘client2dev’ and ‘ota’, need to be subscribed by IoT devices when they connect to MQTT servers. Each device has a unique ‘client2dev’ topic that is typically used for applications to publish messages to the device. When end-users bind a device, they also have to subscribe the same ‘client2dev’ topic, with which they can communicate with the device. The ‘ota’ is typically used to upgrade the firmware of the devices via OTA technology by MQTT servers. When devices subscribe ‘ota’ topic, the MQTT servers can publish firmware information on it. In this way, devices can receive the latest version number and download the link. 5. PERFORMANCE EVALUATION AND ANALYSIS In order to evaluate the performance of our IoT cloud system, especially the designed APIs, several experiments are carried out on a testing IoT cloud system under various conditions. 5.1. Configurations The application servers of the testing IoT cloud consist of one HTTP server and one MQTT server, respectively. Besides, a Redis server is deployed to serve as the database. The detailed information of these servers are shown in Table 3, as well as the objective APIs that are tested. Locust (http://locust.io/) is used to test the performance of web APIs. It can simulate the workloads of HTTP server over different number of users. It creates a lot of virtual users firstly on a machine. Each virtual user sends a random request via a certain web API every random time, which can simulate the real situation that the web APIs are used. In this process, average response time can be counted by Locust, as well as the exceptions. Copyright © 2016 John Wiley & Sons, Ltd.



Table 3. Configuration details of servers in IoT cloud Type of server

Number of server

Number of CPU

CPU model

Clock frequency (GHz)

Memory (GB)

APIs

HTTP server

1

1

Intel Xeon E5-2680

2.7

16

MQTT server

1

1

2.7

32

Redis server

1

1

Intel Xeon E5-2680 Intel Xeon E5-2680

Device binding, device release, user login, device provision, and user registration Publish

2.7

32

—

IoT, Internet of things; API, application programming interface; HTTP, hypertext transfer protocol; MQTT, message queuing telemetry transport.

Figure 5. Average response time on different number of users and web application programming interfaces Another test is carried out to evaluate the main MQTT API, that is, publish. In this test, the number of users that are publishing messages varies among 50 000, 100 000, 150 000, and 200 000. These users publish random messages on a topic every 2 min, which conforms to the actual conditions. Meanwhile, one user sends messages to itself every 1 s, during which, delays between sending and receiving messages are recorded. These delays can reflect the performance of publish. Besides, the running statuses, especially memory occupations, of MQTT server on different number of users are tracked and compared with the Redis server. 5.2. Results Figure 5 shows that the average response time of different web APIs are rising with the increase of number of users, because with more users sending requests to the HTTP server, the workloads of server become huger. Therefore, the average response time becomes longer. On the other hand, the average response time of device binding remains highest, which is mainly because the binding process requires large amount of data to be stored, such as UIDs and DIDs. However, there are actually not much differences on average response time between web APIs. Copyright © 2016 John Wiley & Sons, Ltd.


L. HOU ET AL.

The changing processes of the average response time are illustrated in Figure 6. The average response time is increasing with the augment of running time. Among them, the average response time stays closely to zero when the number of users remains under 2000. However, the average response time becomes extremely high when the number of users reaches around 5000. Because of the limitation of the testing machines, the average response time continues to grow as the time goes. The performance of publish in MQTT servers is depicted in Figure 7. The number of users has a huge impact on the performance of publish as it can be seen. The more users that publish messages in server, the longer the delays become. When the number of users reaches 200 000, the average delays become two times over the other conditions. This means that the performance of publish reaches its limitation at the situation that the number of users extends to around 200 000. On the other hand, due to that the MQTT server becomes more and more stable as it works, the average transmission delay reduces gradually.

Figure 6. Average response time on different number of users and running time

Figure 7. Average transmission delay of publish in message queuing telemetry transport (MQTT) servers on different number of users Copyright © 2016 John Wiley & Sons, Ltd.



Figure 8. Memory occupation of message queuing telemetry transport (MQTT) server and Redis server on different time and client number The occupation statuses of memory in MQTT server and Redis server are shown in Figure 8. With the increase of the number of users in MQTT server, the memory occupation is rising in the same rate.However, the descent of the MQTT curve at the last means that the MQTT server has reached to its limitations that no more users can be connected by it. This shows that the publish in a single MQTT server can be used by at most 230 000 users concurrently. 6. CONCLUSIONS In the last few years, IoT technologies have developed rapidly. By deploying IoT technologies on cloud computing platforms, IoT cloud can provide enhanced services for end-users and effective utilization of resources. In this paper, we mainly discuss the design and implementation of both web APIs and MQTT APIs for IoT cloud. Furthermore, the specific implementations of the APIs, both in servers, clients, and devices, are discussed, as well as the interactions between application servers with clients and devices. Finally, several experiments are carried out to evaluate the performance of designed APIs over different conditions. ACKNOWLEDGEMENTS This work was funded in part by the National High-Tech R&D Program (863 Program) under grant 2015AA01A705, the China Natural Science Funding (NSF) under grant 61271183, National Key Technology R&D Program of China under grant 2015ZX03002009-004 and Fundamental Research Funds for the Central Universities (no. 2014ZD03-02).

REFERENCES 1. Lei L, Kuang Y, Cheng N, Shen X, Zhong Z, Lin C. Delay-optimal dynamic mode selection and resource allocation in device-to-device communications—part 2: practical algorithm. IEEE Transactions on Vehicular Technology 2016; 65(5): 3491–3505. 2. Zheng K, Hu F, Wang W, Xiang W, Dohler M. Radio resource allocation in LTE-advanced cellular networks with M2M communications. IEEE Communications Magazine 2012; 50(7): 184–192. 3. Al-Fuqaha A, Guizani M, Mohammadi M, Aledhari M, Ayyash M. Internet of things: a survey on enabling technologies, protocols and applications. IEEE Communications Surveys & Tutorials 2015; 17(4): 2347–2376. 4. Chen S, Zhao J. The requirements, challenges, and technologies for 5G of terrestrial mobile telecommunication. IEEE Communications Magazine 2014; 52(5): 36–43. 5. Lei L, Zhong Z, Zheng K, Chen J, Meng H. Challenges on wireless heterogeneous networks for mobile cloud computing. IEEE Wireless Communications 2013; 20(3): 34–44.



L. HOU ET AL.

6. Su Z, Xu Q, Zhu H, Wang Y. A novel design for content delivery over software defined mobile social networks. IEEE Network 2015; 29(4): 62–67. 7. Zheng K, Meng H, Chatzimisios P, Lei L, Shen X. An SMDP-based resource allocation in vehicular cloud computing systems. IEEE Transactions on Industrial Electronics 2015; 62(12): 7920–7928. 8. Chen J, Yu Q, Chai B, Sun Y, Fan Y, Shen X. Dynamic channel assignment for wireless sensor networks: a regret matching based approach. IEEE Transactions on Parallel and Distributed Systems 2015; 26(1): 95–106. 9. Zheng K, Yang Z, Zhang K, Chatzimisios P, Yang K, Xiang W. Big data-driven optimization for mobile networks toward 5G. IEEE Network 2016; 30(1): 44–51. 10. Su Z, Qichao Xu, Qi Q. Big data in mobile social networks: a QoE oriented framework. IEEE Network 2016; 30(1): 52–57. 11. Yuan D, Jin J, Grundy J, Yang Y. A framework for convergence of cloud services and Internet of things. In Proceedings of the 2015 IEEE 19th International Conference on Computer Supported Cooperative Work in Design (CSCWD): Calabria, Italia, 2015; 349–354. 12. Zhang H, Cheng P, Shi L, Chen J. Optimal DoS attack scheduling in wireless networked control system. IEEE Transactions on Control Systems Technology 2016; 24(3): 843–852. 13. Fielding R, Gettys J, Frystyk H, Masinter L, Leach P, Berners-Lee T. Hypertext transfer protocol—HTTP/1.1. Internet Engineering Task Force (IETF). RFC 2616, 1999. 14. Panziera L, Comerio M, Palmonari M, Paoli F, Batini C. Quality-driven extraction, fusion and matchmaking of semantic web API descriptions. Journal of Web Engineering 2012; 11(3): 247–268. 15. Li J, Xiong Y, Liu X, Zhang L. How does web service API evolution affect clients? In IEEE International Conference on Web Services: Santa Clara, USA, 2013; 300–307. 16. Aihkisalo T, Paaso T. Latencies of service invocation and processing of the REST and SOAP web service interfaces. In IEEE Eighth World Congress on Services: Honolulu, USA, 2012; 100–107. 17. Lee J, Lee S-J, Wang P-F. A framework for composing SOAP, non-SOAP and non-web services. IEEE Transactions on Services Computing 2014; 8(2): 240–250. 18. Fielding R, Taylor R. Principled design of the modern web architecture. ACM Transactions on Internet Technology 2002; 2(2): 115–150. 19. Cholia S, Skinner D, Boverhof J. NEWT: a RESTful service for building high performance computing web applications. In Gateway Computing Environments Workshop (GCE): New Orleans, 2010; 1–11. 20. Karagoez MF, Turgut C. Design and implementation of RESTful wireless sensor network gateways using Node.js framework. In European Wireless Conference: Barcelona, 2014; 1–6. 21. Lin B, Chen Y, Chen X, Yu Y. Comparison between JSON and XML in applications based on AJAX. In International Conference on Computer Science & Service System (CSSS): Nanjing, China, 2012; 1174–1177. 22. Abeele FV, Hoebeke J, Moerman I, Demeester P. Integration of heterogeneous devices and communication models via the cloud in the constrained Internet of things. International Journal of Distributed Sensor Networks 2015; 2015: 1–16. 23. Shelby Z, Hartke K, Bormann C. The Constrained Application Protocol. Internet Engineering Task Force (IETF) RFC 7252, 2014. 24. Banks A, Gupta R. MQTT version 3.1.1. Organization for the Advancement of Structured Information Standards (OASIS), 2014. 25. Collina M, Corazza GE, Vanelli-Coralli A. Introducing the QEST broker: scaling the IoT by bridging MQTT and REST. In IEEE 23rd International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC): Sydney, 2012; 36–41. 26. Kim J, Lee J, Kim J, Yun J. M2M service platforms: survey, issues, and enabling technologies. IEEE Communications Surveys & Tutorials 2013; 16(1): 61–76. 27. Li F, Vogler M, Claebens M, Dustdar S. Efficient and scalable IoT service delivery on cloud. In IEEE International Conference on Cloud Computing (CLOUD), 2013; 740–747. 28. Kryftis Y, Mastorakis G, Mavromoustakis CX, Batalla JM, Pallis E, Kormentzas G. Efficient entertainment services provision over a novel network architecture. IEEE Wireless Communications 2016; 23(1): 14–21. 29. Skourletopoulos G, Mavromoustakis CX, Mastorakis G, Rodrigues J, Chatzimisios P, Batalla JM. A fluctuation-based modeling approach to quantification of the technical debt on mobile cloud-based service level. In IEEE Globecom Workshops: San Diego, 2015; 1–6. 30. Maleshkova M, Pedrinaci C, Domingue J. Investigating web APIs on the World Wide Web. In IEEE European Conference on Web Services (ECOWS): Ayia Napa, 2010; 107–114. 31. Rissanen HM, Mecklin T, Opsenica M. Design and implementation of a RESTful IMS API. In International Conference on Wireless and Mobile Communications (ICWMC): Valencia, 2010; 86–91. 32. Nastic S, Sehic S, Vogler M, Truong HL, Dustdar S. PatRICIA—a novel programming model for IoT applications on cloud platforms. In IEEE International Conference on Service-Oriented Computing and Applications (SOCA): Koloa, 2013; 53–60. 33. Perez JZ, Carrera D. Performance characterization of the servIoTicy API: an IoT-as-a-Service data management platform. In IEEE First Internation Conference on Big Data Computing Service and Applications: Redwood City, Canada, 2015; 62–71. 34. Giang NK, Ha M, Kim D. SCoAP: an integration of CoAP protocol with web-based application. In IEEE Global Communications Conference (GLOBECOM): Atlanta, 2013; 2648–2653.




35. Tilkov S, Vinoski S. Node.js: using JavaScript to build high-performance network programs. IEEE Internet Computing 2010; 14(6): 80–83. 36. Fette I, Melnikov A. The WebSocket protocol. IETF. RFC 6455, 2011.

AUTHORS’ BIOGRAPHIES Lu Hou received his BS degree from the School of Information and Communication Engineering, Beijing University of Posts and Telecommunications (BUPT), China, in 2014. He is now a candidate for PhD in the Intelligent Computing and Communication (IC2 ) lab, Key Lab of Universal Wireless Communications, Ministry of Education, BUPT. Nowadays, he mainly focuses on resource allocation and security in mobile cloud computing.

Shaohang Zhao received his BS degree from Beijing University of Posts and Telecommunications (BUPT), China, in 2014. He is now studying for a Master’s Degree in the Intelligent Computing and Communication (IC2 ) lab. His research mainly concentrates on the Internet of Things networks.

Xing Li received his BS degree from the School of Information and Communication Engineering, Beijing University of Posts and Telecommunications (BUPT), China, in 2014. He is now studying for a Master’s Degree in the Intelligent Computing and Communication (IC2 ) lab. His research interests include massive MIMO and Internet of Things.

Peris Chatzimisios (S’02-M’05-SM’12) is currently an Associate Professor with the Computing Systems, Security and Networks (CSSN) Research Lab of the Department of Informatics at the Alexander Technological Educational Institute of Thessaloniki. He currently participates in several European and National Research Projects (such as COST Actions, Arximidis III). More specifically, he serves as Deputy Leader for Working Group WP5 ‘Standardization and dissemination’, as Training School Coordinator as well as a Member in the Management Committees of COST Action IC1003 (European Network on Quality of Experience in Multimedia Systems and Services (QUALINET)) and of COST Action IC0905 (Techno-Economic Regulatory Framework for Radio Spectrum Access for Cognitive Radio/Software Defined Radio (TERRA)). Moreover, he is a Substitute Member in the Management Committees of COST Action IC0703 (Data Traffic Monitoring and Analysis: theory, techniques, tools and applications for the future networks) and of COST Action 298 (Participation in the Broadband Society).

Kan Zheng (SM’09) is currently a full professor at Beijing University of Posts and Telecommunications (BUPT), China. He received the BS, MS, and PhD degrees from BUPT, China, in 1996, 2000, and 2005, respectively. He has extensive experience in the research and standardization of the new emerging technologies. He is the author of more than 200 journal articles and conference papers in the field of wireless networks, M2M networks, VANET, and so on. He holds editorial board positions for several journals. He has organized several special issues in famous journals including IEEE Communications Surveys and Tutorials, IEEE Communication Magazine, and IEEE System Journal.

