Lightweight Mobile Web Service Provisioning for Sensor Mediation

Transcription

1 Lightweight Mobile Web Service Provisioning for Sensor Mediation Mohan Liyanage, Chii Chang, Satish N. Srirama Institute of Computer Science, University of Tartu, Estonia {liyanage, chang, Abstract Emerging sensor-embedded smartphones motivated the mobile sensing researches. With the integrated embedded hardware and software sensor components, and mobile network technologies, smartphones are capable of providing various environmental context information via embedded mobile devicehosted Web services (MWS). MWS enhance the capability of various mobile sensing applications such as mobile crowdsensing, real time mobile health monitoring, mobile social network in proximity and so on. Although recent smartphones are quite capable in terms of mobile data transmission speed and computation power, the frequent usage of high performance multi-core mobile CPU and the high speed 3G/4G mobile Internet data transmission will quickly drain the battery power of the mobile device. Numerous previous researches have tried to overcome the resource intensive issues in mobile embedded service provisioning domain. However, most of the efforts were constrained because of the underlying resource intensive technologies. This paper proposes a lightweight mobile Web service provisioning framework for mobile sensing. The framework utilises the technologies that were designed for constrained Internet of Things environment to achieve the lightweight mobile Web service provisioning. The prototype experimental results show that the proposed framework can provide higher throughput and less resource consumption than the traditional mobile Web service frameworks. Keywords-mobile Web service, CoAP, lightweight, constrained service provider. I. INTRODUCTION Emerging smartphones, which consists of numerous sensing capabilities, have motivated the mobile sensing research [1]. With the integrated embedded sensor hardware components, the software-based sensors (e.g., capability of interacting with external sensor devices in the close proximity) and mobile network technologies (i.e. Wi-Fi, Bluetooth, 3G/4G mobile Internet), smartphones are capable of providing various environmental context information by either pushing the collected sensory data to remote servers or providing the data directly via the embedded mobile Web services (MWS) [2] technology. Different to the push-based approach, MWS allow remote clients to perform on-demand requests to the smartphones without the smartphones to upload all the data they collected periodically. Additionally, MWS let the smartphones to participate in various sensing scenarios such as mobile crowdsensing [3], real time mobile health monitoring [4], mobile social network in proximity [5] and so on. Although recent smartphones are quite capable in terms of data transmission speed and computation power, when providing MWS, the resource constrained challenge still exist. The high frequent usage of high performance multi-core mobile CPU and the high speed 3G/4G mobile Internet data transmission will quickly drain the battery power of the mobile device. Therefore, in past years, several lightweight mobile Web provisioning approaches [6], [7], [8] have been proposed to address the resource intensive issues in MWS. In general, there were two trends of approaches: (1) Reducing the complexity of the messaging. e.g., utilising Representational State Transfer () based service provisioning instead of Simple Object Access Protocol (); (2) Utilising external resources to enhance the overall performance. e.g., offloading the complex computational tasks to static Cloud [5] or to the Mobile Ad Hoc Cloud [9]. The major challenge when designing a MWS framework is the constrained nature of available resources on mobile device. Although numerous frameworks [2], [6], [7], [10] have been proposed to reduce the resource consumption of mobile host, the efficiency of their approach is still limited, mainly due to the fundamental protocol stack. For example, most of the past frameworks [11], [12], [13], [14] were based on HTTP as their application protocol that is on TCP. TCP is a connection oriented protocol that has more overhead on transport layer in general, and HTTP messages are often have large header size (from 200 Bytes to 2 Kilobytes), which is not suitable for constrained environments. In this paper, we propose a lightweight mobile Web Service Provisioning framework based on integrating a number of lightweight protocols including Constrained Application Protocol (CoAP) [15], Bluetooth Low Energy (BTLE) [16] and Efficient XML Interchange (EXI) [17]. The prototype of the proposed framework has been implemented and tested on a number of mobile devices including Google/LG Nexus 5 1, Google/HTC Nexus 9 2 and Raspberry Pi 3. The experimental results, which focused on the performance comparison between the traditional MWS and the proposed lightweight MWS, have shown the efficiency of the proposed lightweight MWS framework in terms of resource consumption and service provisioning performance. The rest of the paper is organized as follows: Section

2 II provides background on applications of mobile host and comparison of related work. Section III discusses protocols related to service provisioning. Section IV presents the design details of the proposed framework followed by the description of the main components of the MWS. Section V provides implementation details of the prototype. Section VI presents case studies along with results. This paper concludes in Section VII. II. BACKGROUND This section explores the applications of the mobile host and state-of-art research on the mobile Web service provisioning. A. Applications of Mobile Host MWS has been utilized in many applications over past years. Berger et al., [10] were successful in provisioning a based retail Web application where a mobile device offers wallet services to an electronic check-out at kiosk. The kiosk station uses mobile wallet service hosted by the customer mobile devices that provides a complete payment transaction between the mobile device, the retail store system and the bank system. Two other interesting applications are a) Mobile Picture album with the location information service and b) Collaborative Journalism where mobile host involves the coordination of journalists and their organizations, are presented in the work by Srirama et al. [2], and in [18] respectively. MobiCrop [19] is an application which allows crop farmers to use their mobile devices to get information about the applying pesticides. Another interesting mobile health application provided in [11] called SOPHRA, supports healthcare professionals to access patients medical information that is hosted on their mobile device. B. Comparison of existing Mobile Host frameworks Table I illustrates a comparative overview of past MWS frameworks. It shows that earlier approaches were based on providing -based MWS architectures. However, later approaches have switched their focus on the ful services, which is more suitable for the constrained environments because of their lightweight features [6]. Although the service architecture have been switched from the to, HTTP was still being used for the application protocol. Since the HTTP uses TCP as the transport layer protocol, the overhead of the protocol combination is also relatively high. To reduce the protocol overhead, a lightweight application protocol such as CoAP is needed. However, existing MWS frameworks have not addressed such features. III. RELATED SERVICE PROVISIONING PROTOCOLS This section describes the related protocols/technologies used in our framework. It consists of four major parts of MWS: message format, data transmission, service description and service discovery mechanism. A. Message Format Reducing the payload size in data transmission phase is one of the main strategies to improve the performance and energy efficiency in MWS provisioning. Binary XML and JSON are common options in past works [30]. However, the recent W3C standard Efficient XML Interchange (EXI) is capable of outperforming Binary XML and JSON in reducing the data size. In the EXI compression, the XML document is encoded into binary format that improves encoding/decoding performance and significantly reduces bandwidth requirements [31]. Overall EXI has a high compression efficiency of 50 times when compared to other compression schemes [32]. B. Data Transmission Traditional Web service provisioning relies on over HTTP. Past MWS frameworks [24], [7], [25] tended to utilize Representational State Transfer () [33] based service provisioning in order to reduce the resource consumption of mobile host. 1) Representational State Transfer: is a communication protocol which handles the client-server communication over HTTP. A Web service designed based on is termed ful service. ful services mainly concern on the system s resources transferred over the Web. URIs (Uniform Resource Identifier) are used to access the resources over the Web server. The part of URI contains the resource which is also called Uniform Resource Name (URN) that is requested by clients. provides a simple mechanism for communication between applications over the internet. Different to the complex mechanisms such as CORBA [34], WSDL,, etc., ful applications use the basic HTTP methods (i.e. GET, POST, PUT and DELETE) to access the Web servers. Based on the experimental results [6], [13], [27], is more suitable for resource constrained mobile computing environments. 2) Constrained Application Protocol (CoAP): CoAP is a ful Web transfer protocol that is designed for constrained environments [15]. CoAP provides a more compact message format mechanism, which introduces low overhead binary encoded header and reduces the message parsing complexity. The major features of CoAP are: Request/Response (client/server) communication model. Unicast and multicast support. Four request methods including GET, POST, PUT and DELETE. Four different message types: confirmable, nonconfirmable, acknowledgement and reset. URI based resource representations for the easy resource discovery. CoAP is built on top of the User Datagram Protocol (UDP) that has significantly lower overhead with the multicast support contrast to the TCP. Recently, a work-inprogress CoAP-over-TCP solution have been introduced. However, it is still in its early stage [35]. CoAP is organized in two layers:

3 Year Author Description Protocols 2003 Berger, S. et al. [10] 2004 Srirama et al. [2], [20], [21] 2005 Gehlen and Pham [22] 2006 Srirama [23], Srirama et al. [13] 2008 Ou et al. [14] 2009 Kim and Lee [12] Custom Web service for local network Lightweight MH with Personal Java P2P Web services on Java enable mobiles MH in P2P network on JXTA technology Layered P2P architecture for Converged Cellular and Ad Hoc Networks Migration of services between devices and management of context and service directory 2011 Chang [24] Context-aware cache prefetching strategy 2012 Paniagua MH with and OSGi and Srirama frameworks. [25] [26] Mohamed and Wijesekera [7] 2013 Charl van der [27] Verma and Srivastava [28] Moritz et al. [29] A lightweight framework fully conforms to the Context-aware services, a hybrid model of both Mobile P2P and JmDNS. Maintain a service directory using the XMPP Devices Profile for Web Services (DPWS) used as an application layer protocol in WSNs App. Trans. Local Discovery Global Discoverscription Service De- Message Layer Layer Format HTTP TCP DHCP, centralized No WSIL local UDDI registry HTTP TCP Global UDDI WSDL registry HTTP TCP Local Service Registry (Service Broker) HTTP TCP JXMA (JXTA) modules HTTP TCP Local directory manager for publish and discovery JXMA (JXTA) modules HTTP TCP Local service repository Vertical tunneling model WSDL JXTA advertisements WSDL WSDL HTTP TCP Zeroconf WSDL HTTP TCP JXTA for P2P discovery. ZeroConf /Multicast DNS for Adhoc-Network HTTP TCP Manual IP address of the MH Wide-Area DNS-SD Manual IP address of the MH HTTP TCP Mobile P2P/ JmDNS Mobile P2P/JmDNS OWL- S/WSDL JSON JSON HTTP TCP XMPP XMPP Info/Query stanza of XMPP CoAP UDP DPWS UDP-IP multicasting Our lightweight MHS framework CoAP UDP BTLE Global DNS CoAP /.wellknown/core TABLE I COMPARISION OF RELATED WORKS OF MOBILE WEB SERVICE PROVISIONING /EXI /EXI 1) Transaction layer, which handles message exchange between end-points; 2) Request/response layer, which is responsible for the transmission of requests and responses. Message exchange on the transaction layer has four types: confirmable (requires an acknowledgment), non-confirmable (does not necessarily to acknowledge), acknowledgment (use to acknowledge the confirmable message) and reset (a confirmable message when the recipient of a message encounters an error). The request/response layer is based on the architecture. CoAP provides the reliability with this dual layered approach even without using TCP. Generally, CoAP end-points use the Constrained ful Environments (CoRE) [36] Link Format for the service discovery. There are two approaches, which can be applied for the service discovery process: 1) CoAP resource discovery, which is a basic distributed approach that allows a client device to perform a direct query to another device for discovering the hosted services. 2) CoAP Resource Directory (RD), which is similar to a regular directory-based discovery mechanism in which the RD stores descriptions of resources hosted on the CoAP servers, and allow clients to perform queries on those resources. In order to use the RD, clients and servers should know how to reach the RD. Therefore RD should be a well-known device like a gateway or a Domain Name System (DNS) server. C. Local Service Discovery Local service discovery in peer-to-peer (P2P) manner is one of the major features of MWS provisioning in many scenarios [13], [5]. Different to the global service discovery, which can be achieved by utilizing central service repository/registry, local P2P-based MWS discovery requires P2P communication protocols that are commonly available in existing mobile devices. In a classic design, the mobile host might utilize Wi-

4 Fi or Bluetooth to support the P2P-based service discovery mechanism. However, classic Wi-Fi and Bluetooth protocols are still considered as heavyweight comparing to the recent released Bluetooth Low Energy (BTLE) [16] protocol. BTLE was designed for applications which require low power consumption and low radio duty cycle. It operates in the 2.4 GHz ISM band and uses adaptive frequency hopping to avoid interferences. In BTLE communication, it divides the frequency spectrum into 40 channels with center frequencies 2402 MHz to 2480 MHz with the 2 MHz guard band for each channel. There are 37 data channels, 3 advertising channels that consist of 40 communication channels. With the data rate of 1 Mb/s, BTLE uses Gaussian Frequency Shift Keying (GFSK) as the modulation scheme [37], [38]. BTLE uses lightweight attribute protocol and attribute profiles where maximum payload is limited to 27 octets that is more than enough to represent sensor data such as temperature, heart rate, humidity etc. To achieve low energy feature, five methods supported by BTLE clients and servers are PUSH, PULL, SET, BROADCAST and GET. Clients use PULL method to retrieve attributes form the server when needed while servers use PUSH to send data to clients. The BROADCAST methods can be used to send data to every listing client in the vicinity in order to minimize the bandwidth and power consumption. D. Service Description Service description metadata plays an important role in dynamic service composition systems. By providing standard service description metadata such as Web Service Description Language (WSDL) 4, software clients can automatically identify the operations provided by the service. In following sections, we discuss three main service description approaches that are suitable for MWS provisioning. 1) Web Service Description language: Original WSDL was designed to describe -based Web services. However, WSDL 2.0 is capable of describing ful services. Following is a portion of WSDL 2.0 document that was used to describe a ful operation provided by the mobile host. <operation ref="" whttp:method="get"/> <service name="locationservice" interface=" <!-- skip --><endpoint address = "coap://serv.org:5683/locationservice"/> An alternative Web service description beside WSDL is Web Application Description Language (WADL) 5 which was introduced specifically to describe ful services. Although WADL was not accepted as a W3C standard, it has been broadly used in practice. For example, Jetty 6 Web service container supports WADL as the service description metadata. 2) Sensor Model Language (SensorML): SensorML 7 is a metadata-based resource description language. It provides Intro XML encodings for illustrating sensors, actuators, and processes. The schema and namespace information defines under the header of the SensorML document. All the elements defined in the document mainly depend on the services and resources associated with the sensors. But there are some required elements such as: gml:identifier contains a unique ID (universally unique identifier (UUID), URN, URL, etc.) which can be used to identify any service or the sensor. sml:outputs defines what is measured (ex. Room temperature) sml:position defines the location of the sensor device. e.g., <gml:coordinates> </gml:coordinates>. SensorML is suitable for describing MWS when the mobile host is mainly provisioning sensory data. Additionally, SensorML supports semantic description, which is not provided by WSDL 2.0 by default. 3) CoAP Service Description: CoAP service discovery can be achieved by performing a GET on "/.well-known/core" of the server. It returns links of available resources in the CoRE Link Format [36]. The resource link includes following attributes: Interface Type(if): It describes the generic interfaces of particular resource(s). An interface type can be the URI of a service description metadata (e.g., WADL). Resource Type (rt): It is an application-specific semantic type to a resource. For example, a temperature resource might have its resource type as "room-temperature" or a URI such as that refers to a semantic type in an Web resource ontology. Content Type (ct): It describes the data format of the resource payloads that was defined in the CoAP Content- Formats Registry. A numeric identifier is defined in combination with the content coding. For example, ct=0 represents the Internet media type text/plain. Following is an example of the response form the GET /.well-known/ core request: <building1/tempsen1> if = " rt = " ct = "0" </building1/tempsen1> A. Overview of Architecture IV. SYSTEM DESIGN Fig. 1 illustrates the architecture of the proposed MWS provisioning. In this environment, mobile host represents the Web service provider that is capable of providing various data to its clients. For example, the mobile host can collect sensory data from its surrounding sensor devices SN1 and SN2 and interpret the data to the useful information, then provide the interpreted data via its Web service mechanism.

5 (e.g., ZigBee), or LTE-A (LTE Direct) for local service interaction. Instead of using connection oriented transport protocols such as TCP, the proposed mobile host utilizes UDP, which has a simple header (20 Bytes) and it doesn t maintain connected sessions over the time. CoAP works on the UDP layer and it has 4 bytes as its header size that provides simple, lightweight message exchange in between mobile host and clients over constrained network. The proposed mobile host also utilizes EXI to compress the size of the message payload. C. Components of Mobile Host Fig. 1. Mobile Web service provisioning framework The communication protocol of the mobile host is mainly based on CoAP, and the message payload is in EXI format. The mobile host supports two types of service discovery: global service discovery and local service discovery. The global service discovery is realized by publishing its service description metadata (e.g., WSDL, WADL or SensorML) to a global service registry (e.g., DNS-SD). A remote client that knows the location of the service registry can discover the mobile host by requesting the service registry. Afterwards, the remote client can perform the regular service request to the mobile host by sending the CoAP service requests. The local service discovery is based on BTLE. As the Fig. 1 shows, a client can discover the mobile host in proximal range via BTLE. The mobile host will provide certain information via BTLE to help the client to identify the communication requirement. If the client moves out of the BTLE range with the mobile host, it can still communicate with the mobile host via mobile Internet connection. The mobile host has been assigned a public static IP address from the mobile Internet service provider (e.g. Estonian TELE2 [39] and EMT [40] both provide this service). Alternatively, if the public IP address allocation is not available, the mobile host can utilize proxy services [8], or hole-punching/relaying [41]. B. Basic protocol stack Fig. 2 illustrates the conceptual design of the protocol stack used in the proposed mobile host. The proposed framework is mainly based on lightweight protocols to make the process simple. In the lower layer of the protocol stack, the mobile host can utilize numerous common protocols such 3G/ 4G BT EXI CoAP UDP IP Wi-Fi IEEE LTE-A Fig. 2. Protocol stack of the mobile Web server as 3G/4G mobile Internet (for global service interaction), Wi-Fi/Wi-Fi Direct, Bluetooth (BT)/BTLE, IEEE Fig. 3. Main components of mobile host Web server Fig. 3 illustrates the component architecture of the proposed mobile host. It consists of following main components. 1) Request/Response Listener: It is the first contact point for the clients to the mobile host. Once the mobile host is started, it listens on port 5683 which is reserved for the CoAP services. 2) Service Engine: This is the core module of the mobile host. It analyzes requests from the clients, process and executes relevant methods to get data from the particular resource, and then sends data back to the clients with the response messages. It maintains a resource pool corresponding to the services it offers. In summary, the service engine mainly has two sub components: URI Mapper it analyzes the URI and maps to the corresponding resource to fetch data. Resource pool it is a collection of resources that has context data about particular Web services. In case of real time composite service provisioning that involves interacting with external resource providers, when mobile host receives a request from client, the service engine will fetch data from the relevant resource providers via Data Collector. For example, if the client requested the current location of the server, the URI Mapper executed the method associated with the particular resource (LocationServiceResource) which contacts the Data Collector to get the current GPS coordination from the GPS Sensor. Then the Data Collector contacts the Sensor Manager of the mobile OS to fetch the

6 location data and pass it to EXI Parser for binary encoding. The encoded data will be passed to the CoAP engine for the delivery. 3) Data Collector: Data collector is responsible for collecting data from available resource providers. Such providers can be the inbuilt sensor components of the mobile host, external environmental sensory service providers or spatial data from mobile social network in proximity. 4) Message Processer: It processes the payload of the messages used in the communications. The proposed mobile host framework utilizes EXI formatted binary scheme. EXI Parser gets data from the service engine, compresses it, and forwards to the request/response listener for delivery. 5) Sensor Manager (SM): It is responsible to communicate with the inbuilt sensors. When a request is related to sensory information, the SM activates the sensor components, fetch the data and deactivate the sensor. SM only activates the sensor components when it is necessary and helps to minimize the energy consumption of the mobile host. 6) Local Service Discovery Component: When the client device locates itself in close proximity to the mobile host, it can receive the BTLE advertisement broadcasted by the mobile host. After the BTLE connection established, the client can explore the basic services [42] that are provided by the mobile host. Among other services, the Bluetooth Service Discovery Protocol (SDP) [43] allows the client to retrieve the IP configuration of the mobile host that supports the future communication need. For example, if the client moves away from the BTLE service range, it can still interact with the mobile host over mobile IP networks. 7) Global Service Discovery Component: To enable the Web services across other networks, mobile host registers its service description with the global DNS server. In full architecture, all Web services publish with associated URIs that can be discovered by clients. For example, by performing GET along with the URI coap://myserver.com:5683/.well-known/core, mobile host will send the details of all available services on the server. Alternatively, if the global service registry supports the service description repository mechanism, the mobile host can publish its service description metadata (e.g., WSDL, WADL or SensorML) to the service registry server. Hence, the client does not need to directly communicate with the mobile host for identifying the resources provided by the mobile host. V. IMPLEMENTATION This section describes the prototype implementation of the proposed framework. A. Mobile Host The mobile host was implemented on Google/LG Nexus 5 running Android version The implementation is basically adopted from the JCoAP 8 that provides Java API for the 8 CoAP. The mobile host has also been tested on Raspberry Pi and Nexus 9 tablet. To start an instance of the Web server, the mobile host needs to instantiate a new CoAP local end-point. The class LocalEndpoint describes the functionality of a local endpoint, including a set of resources and methods to add or remove resources. First of all, the resources to be provided and the method to be performed must be defined. In our implementation, we defined four types of resources: 1) TmpResource provides the current room temperature. 2) LocationResource provides current GPS details of the mobile host. 3) AltitudeResource provides current altitude information of the mobile host. 4) LightResource provides the ambient light of the environment. The server initializes the instances for each resource type and registers them to the end-point for providing services. B. EXI Data Process To minimize the size of the CoAP response message, we used EXI, the binary compression on the CoAP payload. We used ExiProcessor 9, the open source Java-based library that encodes text XML files into binary EXI and decodes EXI files back to XML. Current prototype uses pre-compressed EXI files because current Android OS SDK does not support a number of required API libraries for ExiProcessor. For the testing, we managed to implement ExiProcessor on the Raspberry Pi with the 3G dongle for the mobile Internet connectivity. C. Local Service Discovery BTLE have been implemented for local service discovery. Initially the mobile host advertises its name as Mobile-Host with its current IP address assigned to it. Client within the proximity can discover mobile host from the IP described by the BTLE advertisement without establishing Bluetooth pairing connection with the mobile host. After that, clients are able to access the MWS over the IP network. If the client moved from the proximity, it can use the recorded IP address of the mobile host to connect through the IP network and access the MWS. The other types of local discovery mechanisms were not included in our prototype because we have not yet discovered a more energy efficient local service discovery mechanism than BTLE. We consider it as a future research direction. D. Global Service Discovery The remote clients can request the DNS server, which is hosted on the public network for the resource and service discovery. In the prototype, the DNS server was simulated in a regular laptop computer. 9

7 Success rate CPU % VI. CASE STUDY We designed a case study to investigate the performance of the proposed Web service framework. The aim is to compare the traditional MWS with the proposed MWS in terms of throughput, CPU load and the energy consumption. A. Setting The mobile host was implemented in Google/LG Nexus 5 running Android version with the TELE2 3G mobile Internet connection. Additionally, TELE2 provides a public IP address for the mobile host. The clients were simulated on a laptop computer connected to the University Wi-Fi network. Clients requested the altitude of the mobile host that replies the CoAP response message with the payload of 23 Bytes. We simulate different number of concurrent client requests from 10 to 300 per second. Then we measured the average throughput using request/response ratio in each occasion. We repeated the same test case with the mobile host that used traditional Web service framework (HTTP/) to contrast the lightweight in our mobile Web service framework. We also performed the same test case in the University Wi-Fi network to evaluate the performance of the framework further. B. Results 1) Throughput Comparison: Fig. 4 illustrates the throughput comparison between the traditional HTTP-based MWS framework and the proposed lightweight MWS framework. The proposed framework can maintain the 100% success rate up to 140 concurrent requests per second and at least maintains 95% success rate up 160 concurrent requests per second in the Wi-Fi network. The performance was improved in the 3G network because of the inconsistent packet delay in the 3G network than the Wi-Fi network. On the other hand, the traditional mobile Web server showed that it can only handle up to 70 concurrent requests per second in the Wi-Fi network and 130 concurrent requests per second in the 3G network with the throughput of 95%. Also we can see that the throughput of the traditional MWS dropped drastically after reached its maximum capacity. 110% 100% 90% 80% 70% 60% 50% Throughput CoAP-MH(Wi-Fi) HTTP-MH(Wi-Fi) CoAP-MH(3G) HTTP-MH(3G) Fig. 4. Concurrent requests per second Throughput of MWS 2) CPU Usage Comparison: In order to record the CPU usage while the mobile host operating MWS, we used Android Device Monitor that displays the CPU Load for the top applications running on the mobile device. Fig. 5 illustrates the CPU usage comparison based on our record. As the figure shows, the average CPU load is below 5% in CoAPmobile host. On the other hand, in HTTP-mobile host, it is around 11.75% for 100 concurrent client requests per second. When the numbers of client requests are increased (around 110/Sec) HTTP-based mobile host application crashed as it is CPU intensive. On the other hand, CoAP-based mobile host can accommodate even a higher load from clients. Another interesting factor we observed is that the kernel CPU loads of both applications. As shown in the Fig. 5, in the HTTP-based mobile host, kernel CPU load is at a very high level while comparing with the CoAP-mobile host, which is as little as about 1%. CoAP-MH (Application CPU) CoAP-MH (Kernel CPU) 12.00% 10.00% 8.00% 6.00% 4.00% 2.00% Server CPU HTTP-MH (Application CPU) HTTP-MH (Kernel CPU) 0.00% Concurrent requests per second Fig. 5. CPU load of MWS 3) Energy Consumption Comparison: To measure the energy consumption, Battery level drop (1hr) we monitored the battery CoAP-MH HTTP-MH level drop when the mobile host was serving 80 clients 25% 20% request per second. The 15% testing was repeatedly 10% running for one hour. Fig. 6 5% illustrates the comparison 0% based on the battery usage 80 Concurrent requests per second records. As Fig. 6 shows, there is 21% dropped in Fig. 6. Battery level drop for an hour traditional HTTP-mobile host while 11% in lightweight CoAP-mobile host. The result indicates that the proposed lightweight mobile host consumes much less energy than the traditional mobile host. VII. CONCLUSION In this paper, we have presented a lightweight mobile Web service provisioning framework for resource constrained environment. During our implementation and testing, we used design architecture and lightweight protocols in order

8 to maintain the less complexity and energy efficiency of the framework. The evaluation results have shown that the proposed lightweight MWS framework can provide a more cost-efficient MWS provisioning solution than the past traditional MWS frameworks. As for the future research directions, we would like to improve the efficient service discovery features which are most important in the machine to machine communication. ACKNOWLEDGMENT This research is supported by the European Regional Development Fund through the EXCS and Estonian Science Foundation grant PUT360. Special thanks to Jakob Mass for his contribution on implementation and evaluation of the traditional Web server. REFERENCES [1] N. D. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, and A. T. Campbell, A survey of mobile phone sensing, Communications Magazine, IEEE, vol. 48, no. 9, pp , [2] S. N. Srirama, M. Jarke, and W. Prinz, Mobile web service provisioning, in Telecommunications, AICT-ICIW 06. International Conference on Internet and Web Applications and Services/Advanced International Conference on. IEEE, 2006, p [3] L. Wang, D. Zhang, and H. Xiong, effsense: energy-efficient and costeffective data uploading in mobile crowdsensing, in Proceedings of the 2013 ACM conference on Pervasive and ubiquitous computing adjunct publication. ACM, 2013, pp [4] I. K. Kim and J. H. Song, Mobile Health reference architectures, in Information Society (i-society), 2013 International Conference on. IEEE, 2013, pp [5] C. Chang, S. N. Srirama, and S. Ling, An adaptive mediation framework for mobile P2P social content sharing, in Service-Oriented Computing. Springer, 2012, pp [6] K. AlShahwan, Feda & Moessner, Providing soap web services and restful web services from mobile hosts, in Internet & Web Applications and Services (ICIW), th Inte.Conf.on. IEEE, 2010, pp [7] K. Mohamed and D. Wijesekera, A lightweight framework for web services implementations on mobile devices, in Mobile Services (MS), 2012 IEEE First International Conference on. IEEE, 2012, pp [8] M. Jansen, O. Hordt, and J. Milatovic, About the development of scenarios for mobile Web Service provisioning, in Computer and Information Technology (WCCIT), 2013 World Congress on. IEEE, 2013, pp [9] F. AlShahwan and M. Faisal, Mobile cloud computing for providing complex mobile web services, in Mobile Cloud Computing, Services, and Engineering (MobileCloud), nd IEEE International Conference on. IEEE, 2014, pp [10] S. Berger, S. McFaddin, C. Narayanaswami, and M. Raghunath, Web services on mobile devices-implementation and experience, in Mobile Computing Systems and Applications, Proceedings. Fifth IEEE Workshop on. IEEE, 2003, pp [11] R. K. Lomotey, S. Jamal, and R. Deters, SOPHRA: a mobile web services hosting infrastructure in mhealth, in Mobile Services (MS), 2012 IEEE First International Conference on. IEEE, 2012, pp [12] Y.-S. Kim and K.-H. Lee, A lightweight framework for mobile web services, Computer Science-Research and Development, vol. 24, no. 4, pp , [13] S. N. Srirama, M. Jarke, H. Zhu, and W. Prinz, Scalable mobile web service discovery in peer to peer networks, in Internet and Web Applications and Services, ICIW 08. Third International Conference on. IEEE, 2008, pp [14] Z. Ou, M. Song, H. Chen, and J. Song, Layered peer-to-peer architecture for mobile web services via converged cellular & ad hoc networks, in Grid & Pervasive Computing Workshops, GPC Workshops 08. The 3rd International Conference on. IEEE, pp [15] Z. Shelby, B. Frank, and D. Sturek, Constrained Application Protocol (CoAP) draft-shelby-core-coap-00, Online at ietf. org/html/draft-shelby-core-coap-01, [16] Bluetooth specification version 4.0, Bluetooth SIG, [17] Efficient xml interchange (exi) format 1.0 (second edition). [Online]. Available: [18] S. N. Srirama and M. Jarke, Mobile hosts in enterprise service integration, International Journal of Web Engineering and Technology, vol. 5, no. 2, pp , [19] R. K. Lomotey, Y. Chai, K. A. Ahmed, and R. Deters, Web Services Mobile Application for Geographically Dispersed Crop Farmers, in Computational Science and Engineering (CSE), 2013 IEEE 16th International Conference on. IEEE, 2013, pp [20] S. N. Srirama, M. Jarke, and W. Prinz, Mobile Host: A Feasibility Analysis of Mobile Web Service Provisioning. in UMICS, [21] S. Srirama and W. Prinz, Concept, implementation and performance testing of a mobile Web Service provider for smart phones, Master thesis, RWTH Aachen, Germany., [22] G. Gehlen and L. Pham, Mobile web services for peer-to-peer applications, in Consumer Communications and Networking Conference, CCNC Second IEEE. IEEE, 2005, pp [23] S. N. Srirama, Publishing and discovery of mobile web services in peer to peer networks, arxiv preprint arxiv: , [24] C. Chang, S. Ling, and S. Krishnaswamy, Promws: Proactive mobile web service provision using context-awareness, in Pervasive Computing and Communications Workshops (PERCOM Workshops), 2011 IEEE International Conference on. IEEE, 2011, pp [25] C. Paniagua, Discovery and push notification mechanisms for mobile cloud services, Masters thesis, University of Tartu, [26] S. N. Srirama and C. Paniagua, Mobile web service provisioning and discovery in android days, in Proceedings of the 2013 IEEE Second International Conference on Mobile Services. IEEE Computer Society, 2013, pp [27] C. van der Westhuizen and M. Coetzee, A framework for provisioning restful services on mobile devices, in Adaptive Science and Technology (ICAST), 2013 International Conference on. IEEE, 2013, pp [28] R. Verma and A. Srivastava, A Novel Web Service Directory Framework for Mobile Environments, in Web Services (ICWS), 2014 IEEE International Conference on. IEEE, 2014, pp [29] G. Moritz, F. Golatowski, C. Lerche, and D. Timmermann, Beyond 6LoWPAN: Web services in wireless sensor networks, Industrial Informatics, IEEE Transactions on, vol. 9, no. 4, pp , [30] S. N. Srirama, MWSMF: A mediation framework for mobile hosts and enterprise on cloud, International Journal of Pervasive Computing and Communications, vol. 7, no. 4, pp , [31] A. P. Castellani, M. Gheda, N. Bui, M. Rossi, and M. Zorzi, Web Services for the Internet of Things through CoAP and EXI, in Communications Workshops (ICC), 2011 IEEE International Conference on. IEEE, 2011, pp [32] Z. Shelby, Embedded web services, IEEE Wireless Communications, vol. 17, no. 6, p. 52, [33] R. T. Fielding, Architectural styles and the design of network-based software architectures, Ph.D. dissertation, University of California, Irvine, [34] R. Elfwing, U. Paulsson, and L. Lundberg, Performance of soap in web service environment compared to corba, in Software Engineering Conference, Ninth Asia-Pacific. IEEE, 2002, pp [35] A TCP and TLS Transport for the Constrained Application Protocol (CoAP). [Online]. Available: draft-tschofenig-core-coap-tcp-tls/ [36] Z. Shelby, Constrained ful Environments (CoRE) Link Format, [37] C. Gomez, J. Oller, and J. Paradells, Overview and evaluation of bluetooth low energy: An emerging low-power wireless technology, Sensors, vol. 12, no. 9, pp , [38] R. Jain, Bluetooth and Bluetooth Smart, [39] TELE2. [Online]. Available: [40] EMT. [Online]. Available: [41] S. N. Srirama and M. Liyanage, Tcp hole punching approach to address devices in mobile networks, in nd International Conference on Future Internet of Things and Cloud (FiCloud). IEEE, 2014, pp [42] Bluetooth GATT Specifications - Services. [Online]. Available: [43] The Bluetooth Service Discovery Protocol. [Online]. Available: service-discovery