The Internet of Things (IoT) involves connecting embedded devices such as sensors, home appliances, smart meters, health-monitoring devices, and even street lights to the Internet. With about 10 to 15 billion microcontrollers being shipped every year, each of which can potentially be connected to the Internet, a huge variety of intelligent and networked devices are becoming available to benefit many application domains. To facilitate this connection, research and industry have come up over the past decade with a number of advances in microelectronic technology, low-power radio, and networking. The objective is for embedded devices to become IP-enabled and an integral part of the services on the Internet. These connected devices are referred to as smart objects characterized by sensing, processing, and networking capabilities. They usually configure an IPv6 low-power wireless personal area network (6LoWPAN), which plays an important role in IoT, especially on account of energy consumption (low-power), ubiquitous availability (wireless), and Internet integration (IPv6).

The popularity of applications on the Web, along with its open standards and accessibility across a broad range of devices such as desktop computers, laptops, mobile phones, and gaming consoles make the Web an ideal universal platform for future IoT. Hence, when more and more smart objects are getting connected to the Internet, it is the natural evolution of the IoT to provision smart object services to the Web, similar to today's millions of conventional Web services. There is a new opportunity of truly intelligent and ubiquitous applications that can incorporate smart objects and conventional Web services using open Web standards, denoted by IoT applications on Web.

This dissertation proposes a complete solution to provision 6LoWPAN services with semantic annotation that enables the development of IoT applications on Web. We aim to bring smart object services to the Web and make them accessible by plenty of existing Web APIs in consideration of 6LoWPAN constraints such as limited resources (ROM, RAM, and CPU), low-power, and low-bitrate communication links. There are four contributions: (i) The first contribution is about the overall architecture of the semantic service provisioning for IoT application on Web consisting of three subsystems: service communication, service provisioning, and service integration. (ii) The second contribution studies the internetworking model between 6LoWPAN and regular IPv6 networks by a design, implementation, and performance evaluation of a 6LoWPAN consisting of MTM-CM5000-MSP TelosB motes with TI MSP430F1611 microprocessors and CC2420 IEEE 802.15.4 radio transceivers for smart objects, and Raspberry Pi for an edge router; (iii) The third contribution presents the detailed architecture, algorithms, and mechanisms for provisioning reliable, scalable, and secure smart object services with respect to its resource-constrained requirements; (iv) The fourth contribution is in application domain for service integration in which we apply the proposed architecture on two innovative IoT applications on Web: a building automation system (SamBAS) and a Social IoT platform (ThingsChat).

Résumé

L'Internet des objets (IoT) implique la connexion des appareils embarqués tels que les capteurs, les électroménagers, les compteurs intelligents, les appareils de surveillance de la santé, et même les lampadaires à l'Internet. Une grande variété d'appareils intelligents et en réseau sont de plus en plus à la disposition de bénéficier de nombreux domaines d'application. Pour faciliter cette connexion, la recherche et l'industrie ont mis un certain nombre d'avancées dans la technologie microélectronique, de la radio de faible puissance, et du réseautage au cours de la dernière décennie. L'objectif est de permettre aux appareils embarqués de devenir IP activé et une partie intégrante des services sur l'Internet. Ces appareils connectés sont considérés comme les objets intelligents qui sont caractérisés par des capacités de détection, de traitement, et de réseautage. Les réseaux personnels sans fil à faible consommation d'IPv6 (6LoWPANs) jouent un rôle important dans l'IoT, surtout sur la consommation d'énergie (de faible puissance), la disponibilité omniprésente (sans fil), et l'intégration d'Internet (IPv6).

La popularité des applications sur le Web, aux côtés de ses standards ouverts et de l'accessibilité à travers d'une large gamme d'appareils tels que les ordinateurs de bureau, les ordinateurs portables, les téléphones mobiles, les consoles de jeu, fait que le Web est une plateforme universelle idéale pour l'IoT à l'avenir. Par conséquent, quand de plus en plus d'objets intelligents se connectent à l'Internet, l'IoT est naturellement évolué pour la provision des services des objets intelligents sur le Web, comme des millions de services Web d'aujourd'hui. Puis vient une nouvelle opportunité pour des applications vraiment intelligentes et omniprésentes qui peuvent intégrer des objets intelligents et des services Web conventionnels en utilisant des standards Web ouverts. Nous appelons ces applications les applications IoT sur le Web.

Cette thèse propose une solution complète pour la provision de 6LoWPAN avec une annotation sémantique pour pousser le développement d'applications IoT sur le Web. Nous visons à offrir des services d'objets intelligents pour le Web et les rendre accessibles par beaucoup d'API Web qui existe en considérant des contraintes de 6LoWPAN comme les ressources limitées (ROM, RAM et CPU), la faible puissance, et la communication à faible débit.

Il y a quatre contributions: (i) La première contribution est sur l'architecture globale de la provision sémantique de services pour les applications IoT sur le Web qui comprennent trois sous-systèmes: le système de communication des services, le système de provision des services, et le système d'intégration des services. (ii) La deuxième contribution étudie un modèle d'interconnexion entre les réseaux 6LoWPAN et les réseaux IPv6 réguliers par la conception, la mise en oeuvre et l'évaluation de la performance d'un 6LoWPAN qui constitué des MTM-CM5000-MSP TelosB motes pour les objets intelligents, et le Raspberry Pi pour un routeur de bordure. (iii) La troisième contribution présente en détails de l'architecture, des algorithmes et des mécanismes pour la provision des services des objets intelligents fiables, évolutifs et sécurisés en respectant des contraintes de ressources limitées; (iv) La quatrième contribution est composée de deux applications innovantes IoT sur le Web pour l'intégration des services dans lesquels nous appliquons l'architecture proposée: un système d'automatisation de la construction (SamBAS) et une plateforme Social IoT (ThingsChat). I first would like to thank my supervisor, Prof. Noel Crespi, who gave me the opportunity to do this research and has been providing me a myriad of help, suggestions, and encouragement. Next, thanks go to Prof. Gyu Myoung Lee who was mentoring me for the first two (important) years of my Ph.D. and still offers me valuable advice. We have discussed a lot and I really appreciate as well as enjoy the time working with him.

I must thank my colleagues and friends in Service Architecture Lab for the joint cross-topic work we have done together that in its own way made a difference to this research. Many ideas in this research have their origins in countless discussions with Dina Adel. She inputted innovative scenarios for the proof-of-concept prototypes developed in this research; I owe her creativity. Imran Khan shared with me many ideas in wireless sensor network virtualization and helped to refine this work; Soochang Park fortified the networking foundation of the research; Xiao Han gave her in-sight analysis from a different perspective of the Internet of Things, data science. I am more grateful to everyone in the lab for the fun atmosphere they have created, for everyday coffee breaks that helped me to go through the endless days on campus. Thanks especially go to the lovely Valerie Mateus for her beautiful nature of helping me (and everyone) with administrative paperworks; she has made it easy for everything.

I had chance to work with excellent people in industry for several European projects. I warmly thank David Excoffier from Sogeti and Helia Pouyllau from Thales who helped me to approach practical designs presented in this research. I would like to thank Vladimir Vukadinovic and colleagues at Disney Research Zurich with whom I had a good time developing a very interesting prototype using IoT protocol stack. I learned a lot about the IoT technology and the beauty of the art twisted in it.

Thank you Tim Berners-Lee for inventing the World Wide Web, volunteers at Internet Engineering Task Force and many scientists that I cannot list all here for creating this connected world. Also, I am very much inspired by the work carried out by Distributed Systems Group at the ETH Zurich which significantly influenced this research.

Thank you my beloved wife Genie. Had it not been for her enormous love and Chapter 1

Motivation

The Internet of Things (IoT) is stimulating innovations in virtually all sectors of the economy attracting not only researchers and professionals, but also entrepreneurs, endusers, and even lawmakers. The IoT with its capacity to connect objects to the Internet, blending physical and digital worlds, is going to mark a revolution in how we communicate with other people and everything surrounding us.

Thanks to the advent of IoT technologies, several commercial smart devices improving our everyday life already existed in the market such as Koubachi plant sensor 1 , Alba light bulb 2 , and Luna mattress cover 3 to name just a few. Koubachi plant sensor can measure soil moisture, sunlight, infrared light, and ambient temperature to determine the exact needs of the plants and provide users with highly-specific care advice. Luna mattress cover is able to warm up the bed, track one's sleep, and even wake you up, if necessary. The sensors on the Alba light bulb make it the world's first responsive bulb: its internal sensors allow it to automatically maintain the proper light level, adjust the color of the light according to the time of day, and adapt to the people in the room. What's more, everything surrounding us such as chairs, windows curtains, light bulbs, office equipment, home appliances, and even baby dummies can be turned into

Introduction

Internet-connected smart objects to enhance many application domains (e.g., building automation, healthcare services, smart grids, transportation, and environmental monitoring). A smart object is defined as an item equipped with a form of sensor or actuator, a tiny microprocessor, memory, a communication module, and a power source [1]. They are electronic embedded devices characterized by sensing, processing, and networking capabilities. This can be done by extending the design of electronic appliances to these objects, which fundamentally requires a new set of microelectronic technologies and communication protocols.

To facilitate the smart object connectivity while considering its limited resources (e.g., computing capacity, power, and memory), research and industry have come up over the past decade with a number of advances in low-power microelectronic, radio communication, and corresponding Internet Protocol (IP) networking. IP for decades has effectively supported Internet applications such as email, the Web, Internet telephony, and video streaming. Internet Protocol version 6 (IPv6) is expected to accommodate a huge number of entities, enough for a inconceivably-large number of objects going to be connected to the Internet. These technologies are being engineered by standardization bodies led by Internet Engineering Task Force (IETF) to make them open and accessible to everyone. The objective is for smart objects to consume very low energy, become IP-enabled, and to be an integral part of the services on the Internet. The configuration of smart objects create a new type of networks collectively referred to as IPv6 low-power wireless personal area networks of smart objects (6LoWPANs), which can provide the IP networking infrastructure for the future IoT applications.

6LoWPAN plays an important role in IoT for its benefits of the energy consumption, ubiquitous availability, and the Internet integration of smart objects. First, energy consumption has become an critical issue for modern sustainable development, especially in the time when a huge number of smart objects staying connected to the Internet. The energy used for only maintaining the connectivity of predictably 50 billion objects [2] by current wireless technologies such as Wi-Fi and Bluetooth would account for a considerable large amount the current world energy capacity. Therefore, low-power radio hardware and software protocols are crucial for facilitating a practical IoT ecosystem.

Second, more and more wireless devices become available in today's consumer electronics market creating an ubiquitous environment surrounding us which is gradually changing our life style. Advantages to the wireless connectivity are manifold such as the convenience to users, easy deployment, and even for aesthetic aspects that no wires are required. Third, IPv6 with its huge address space is the future for smart objects to seamlessly join the Internet. 6LoWPAN is known under several names such as Lowpower Wireless Personal Area Network (LoWPAN, RFC 4944), Low-power and Lossy Network (LLN, RFC 6550), Constrained Environment (RFC 6690). In this dissertation, 6LoWPAN is used to refer to a network of IPv6, low-power, and wireless smart objects using several IETF standards from working groups including Routing Over Low-power and Lossy Networks (roll), Constrained RESTful Environments (core), and DTLS In Constrained Environments (dice), IPv6 over Networks of Resource-constrained Nodes (6lo), and IPv6 over Low-Power Wireless Personal Area Networks (6lowpan).

On the other hand, the popularity of applications on the Web, along with its open standards and accessibility across a broad range of devices such as desktop computers, laptops, mobile phones, and gaming consoles make the Web an ideal universal platform for future IoT applications. In this future environment, smart objects will be able to offer their functionality via RESTful APIs, enabling other components to interact with them dynamically. The functionality offered by these devices (e.g., temperature sensor data) is referred to as smart object service provided by embedded systems that are related directly to the physical world. Unlike traditional Web services and applications, which are mainly virtual entities, smart object services provide realtime data about the physical world. IoT applications can therefore support a more efficient decision taking process. Hence, smart objects providing their functionality as Web services can be used by other entities such as other Web services, enterprise applications, or even other smart objects. The process of preparing and providing smart object services to the Web is called service provisioning aiming to deliver smart object services to the Web, similar to today's millions of Web services are functioning.

Then comes a new opportunity for truly-intelligent and ubiquitous applications that can incorporate smart object services and conventional Web services using open Web standards. We call these applications IoT applications on Web. The arrival of IoT applications on Web also exposes a new opportunity for conventional Internet applications to shift their business model to catch up with this new ecosystem. The concept does not only refer to IoT applications running on Web browser but also to any application residing on the Internet communicating to smart objects and user agents using open Web standards via Web Application Programming Interfaces (Web APIs). The user agent can be a Web browser, a smart phone application, computer software, or even a game console firmware. Web APIs are specifications that define how to interact with software components, particularly, allow access to remote Web resources via a communication network. The benefit for developers in adopting Web APIs is an easy way to enrich functionality, simple and quick to integration, and leveraging brand strength of established partners. Even in the new platform of smartphone applications, we can already see that the use of Web APIs is prevalent. Shazam4 , for example, the application that allows users to recognize pieces of music in real-time, integrates Web APIs from many providers such as the Spotify, YouTube, Amazon, iTunes, and radio APIs. Additionally, it allows social sharing, which presumably is realized by using the Web APIs of the various social platforms.

Once smart object services reach the Web through communication networks, applications over connected smart objects will go beyond homes, offices, and public spaces to reach the truly global ubiquitous status. The Web then will also undergo the similar evolution to extend their tentacles to the new kids in the block, smart objects, integrating the physical world for more useful and intelligent applications. These applications should be developed in a relatively easy and intuitive way in which developers can use different platforms, frameworks, tools, and programming languages. It is therefore essential to provision services of smart objects in 6LoWPAN to the Web and make them accessible and workable with plenty of existing Web services or APIs. These services also need to catch up with the new trends in the Web world wherein Semantic Web technology (envisioned by Tim Berners-Lee) is predicted to bring more intelligence to the Web. Tim Berners-Lee described Semantic Web as a Web of linked data that can be processed directly by machines allowing applications to automatically infer new meaning from all the information out there [3].

This dissertation proposes a complete solution to provision smart object services in 6LoWPAN with semantic annotation in order to empower the development of IoT applications on Web. The solution complies with the constraints of smart objects: limited ROM, RAM, CPU, low-power, and low-bitrate radio.

Contributions

This dissertation has four contributions solving fundamental problems for a secure, scalable, and reliable semantic service provisioning to enable the development IoT applications on Web, as follows:

• The first contribution is about the overall service provisioning architecture for 6LoWPAN to enable the development of IoT applications on Web. The architecture covers the full development cycle taking into account object, network, and application levels. We first explain about the key requirements and the concept of IoT applications on Web, and then propose the architecture consisting of three subsystems delineated in different views: Reference Infrastructure, Multilayer Architecture, Functional Block Diagram, and Provisioning Workflow.

• The second contribution provides the networking foundation and studies the performance of the internetworking model between 6LoWPAN, regular IPv6 networks, and the Internet. It includes the design, implementation, and performance evaluation of a 6LoWPAN consisting of MTM-CM5000-MSP TelosB motes equipped with Texas Instruments MSP430F1611 microprocessors, CC2420 IEEE 802. 15.4 radio chips, and Contiki OS 3.x as smart objects, and a Raspberry Pi as the 6LoWPAN edge router.

• The third contribution is about the detailed architecture, algorithms, and mechanisms for realizing the proposed semantic service provisioning. It solves the problems of service discovery, scheduling, semantic annotation, authorization, Web Uniform resource identifier (Web URI) mapping, and Web API presentation. We also provide an in-network implementation of the proposed architecture.

• The forth contribution is in application domain in which we apply the proposed architecture in two innovative IoT applications on Web: a Social IoT platform (ThingsChat) enabling an online social network for humans and objects and a building automation system (SamBAS) using semantic technology to offer intelligence in smart environments. These applications illustrate how the architecture can be applied in various application scenarios.

Dissertation Outline

The remainder of this dissertation is structured as follows. Chapter 2 reviews the literature of service provisioning in IoT. Chapter 3 proposes the novel service provisioning architecture consisting of three subsystems (service communication, service provisioning, and service integration) presented in the following Chapter This chapter provides a literature review on the IoT protocol stack, service provisioning in IoT, and semantic annotation for smart objects. The IoT protocol stack extending TCP/IP networking model for smart object communication is playing the foundation role supporting many innovative contributions in the IoT research and development.

IoT Protocol Stack

The IoT aiming to integrate smart objects into the Internet introduces several challenges since many of the existing Internet technologies and protocols were not designed for constrained resources in smart objects. IoT, therefore, has fostered the development of many extensions and adaptations of Internet technologies for the new class of networked objects. This results in a new IP protocol stack for IoT to enable the communication between Internet-connected smart objects and other machines on the Internet.

Application Layer

Regardless of the specific link layer technology to deploy the IoT network, all the enddevices should make their data available to the Internet. This can be achieved by using several application layer technologies tailored for smart objects. On top of the IPv6 Internet, constrained smart objects are able to reap the benefits of a lightweight application protocols. The Constrained Application Protocol (CoAP) [5] is designed exclusively for smart objects to replace Hypertext Transfer Protocol (HTTP) and can be easily translated to HTTP for a transparent integration with the Web, while meeting the smart object requirements such as multicast support, very low overhead, and publish/subscribe model. The OASIS Devices Profile for Web Services (DPWS) [6] standard is a lightweight version of W3C Web Service [7] providing a secure and effective mechanism for describing, discovering, messaging, and eventing services for resourceconstrained smart objects. The Message Queue Telemetry Transport (MQTT) [8] is an asynchronous publish/subscribe protocol that runs on top of the TCP. Publish/subscribe protocols better meet the IoT requirements than request/response since clients do not have to request updates resulting in the decrease in the network bandwidth the need for using computational resources. The Extensible Messaging and Presence Protocol (XMPP, RFC 3920) was designed for chatting and message exchanging. It was standardized by the IETF over a decade ago and is a well-proven protocol that has been used widely all over the Internet. Recently, XMPP has gained attention as a suitable communication protocol for the IoT. The Advanced Message Queuing Protocol (AMQP) [9] is a protocol that arose from the financial industry. AMQP provides asynchronous publish/subscribe communication with messaging. It can utilize different transport protocols but it assumes an underlying reliable transport protocol such as TCP. Its main advantage is its store-and-forward feature that ensures reliability even after network disruptions. CoSIP [4] is a constrained version of the Session Initiation Protocol (SIP) to allow smart objects to instantiate communication sessions in a lightweight and standard fashion. Session instantiation can include a negotiation phase of some parameters which will be used for all subsequent communication.

Service Provisioning in IoT

There have been several studies on service provisioning ranging from early-stage models over Radio-Frequency Identification (RFID)and wireless sensor networks, mostly following the concept of Service-Oriented Architecture (SOA) [START_REF] Huhns | Service-oriented computing: Key concepts and principles[END_REF], to recent solutions over IP protocol stacks. This section reviews these works on general and SOA-based models of service provisioning in IoT.

General Models

Miorandi et al. [START_REF] Miorandi | Internet of things: Vision, applications and research challenges[END_REF] in their survey paper discussed that the shift from an Internet used for interconnecting end-user devices to an Internet used for interconnecting physical objects that communicate with each other and/or with humans in order to offer a given service encompasses the need to rethink anew some of the conventional approaches customarily used in networking, computing, and service provisioning/management. The arising of IoT provides a shift in service provisioning, moving from the current vision of always-on services, typically of the Web era, to always-responsive situated services, built and composed at runtime to response to a specific need and able to account for the users' context. When a user has specific needs, she will make a request and an ad hoc application, automatically composed and deployed at run-time and tailored to the specific context the user is in, will satisfy them.

The work in [START_REF] Mazhelis | Defining an internet-of-things ecosystem[END_REF] aimed to define an IoT ecosystem from the business perspective then identified service provisioning as one of the key fields to realize the vision of the IoT. The defined IoT business ecosystem is a community of interacting companies and individuals along their socio-economic environment. It is where the companies are competing and cooperating by utilizing a common share of core assets, which can be in a form of hardware and software products, platforms or standards that focus on the connected devices, on their connectivity, on application services over this connectivity, or on supporting services. The connectivity is based on common IoT protocol stack as described in the previous section. In order to realize the ecosystem, service provisioning cooperates with other modules such as Developing, Distribution, and Assurances. For example, the end user could acquire various IoT services through a home gateway that supports several technologies. Automated control of lightning, heating and security but also entertainment services could be provisioned through this gateway. With the interoperability issues diminishing, the end user could separately create contracts with network operators and the application service providers, such as a utility company or a content provider. The model here resembles the contemporary Internet service provisioning.

Prasad et al. [START_REF] Prasad | Opportunistic service provisioning in the future internet using cognitive service approximation[END_REF] presented another model called opportunistic service provisioning to deal with the variety of situations that users encounter in everyday life. The model came from the fact that in the real world, a perfectly matching service for a requirement (or tuned to a situation) may not always be available. In these situations, humans try to locate an approximate and an alternative service for the required one that is available and can solve the immediate necessity. For example, a user wants a cup of coffee from a vending machine (with a stack of paper cups), he can locate the coffee machine using his cell phone. Meantime, these coffee cups can be easily used for drinking water, tea, soup or any kind of liquid. The user may use a coffee cup as a pen stand or even as an ashtray.

Thus, the service should be able to locate the coffee cup when a pen stand is required.

The services now would be based on the non-availability of the exact solution that is not possible to serve a requirement and availability of a close alternative. This work deals with an opportunistic yet an approximate service paradigm in the Internet of the future, especially, in the light of exponential growth of Internet of Things. The authors discussed the characteristics of such a service and also provided the related structure to realize this framework by representing objects in virtual objects and virtual sensing techniques.

Mandler et al. [START_REF] Mandler | Compose -a journey from the internet of things to the internet of services[END_REF] introduced a perspective of Internet of Services within COM-POSE project1 . The objective is to benefit from the IoT technologies by seamlessly integrating the real and virtual worlds. The ecosystem can be achieved through the pro-

visioning of an open and scalable infrastructure, in which smart objects are associated with services that can be combined, managed, and integrated in a standardized way to easily build innovative applications. Specifically, this study was conducted on specifying and providing a virtual service execution. Moreover, this defined interfaces needed for appropriate services management throughout services lifecycle, creation, upgrade, reconfiguration, resolving security conflicts, rerouting, etc. An accompanying monitoring component oversees security and privacy criteria and Quality of Service guarantees are met. COMPOSE aimed to manage the lifecycle of services in the marketplace and to provide methods for on-the-fly provisioning of service components with better characteristics.

Lee and Chong [START_REF] Lee | User-centric intelligence provisioning in web-of-objects based iot service[END_REF] approached the problem of service provisioning in a user-centric manner wherein services are created efficiently according to the users' competency in their living environments. The approach involves IoT service together with semantic ontology that can support the composition of services suitable to the situation of users, and by the log records it can modify the corresponding happenings. The proposed architecture aims to handle the limitation of user-centric IoT service provision. It is designed to utilize the web based service platform structure that contains versatility and scalability which multiple users or basic environment can easily apply to be a part of the system. The environment requires interoperability, versatility, efficient communication, mobility, intelligence and active functionality to the user-centric IoT service. It is also to give advance management to the system service integration, service management, location management, context management, traffic management, security and privacy management that are all applied to control the faulty operation caused by deficient requirements. The user-centric IoT service and the gathering of information from the scattered object are done by service composition. The web service platform and distributed structure act as the core of the system to handle service provision from Web of Object2 environment. And the smart gateway manages the devices which are located in the local area of decentralized domain.

SOA-based Models

Gagnon and Cakici [START_REF] Gagnon | Integrating business services networks and the internet of things: A new framework for mobile software as a service[END_REF] proposed a framework for provisioning and integrating earlystage IoT services (using RFID) to IT infrastructure and business processes. The framework exploits the SOA in two converging technologies, Business Services Network (BSN) and the IoT. RFID tags can embed high value features essential to various industries such as detecting, classifying, and tracking mobile (sensor-less) objects in a surveillance field, monitoring the performance of electro-mechanical components, and controlling manufacturing equipment. They discussed that the integration of SOA and RFID standards was becoming a strategic research priority to leverage mobile business model such as provisioning Web services with pay-per-use, metered, or on demand business. The framework addresses various issues along a typical transaction in business models including: Supplier, Market, Adopter, and Delivery Issues.

The paper [START_REF] Guinard | Interacting with the soa-based internet of things: Discovery, query, selection, and on-demand provisioning of web services[END_REF] presented the architecture of SOA-based IoT including the on-demand service provisioning (along with dynamic network discovery, query, and selection of Web services). They defined real-world device services as functionalities offered by these devices (e.g., the provisioning of online sensor data) because these services are provided by embedded systems that are related directly to the physical world. Unlike traditional enterprise services and applications, which are mainly virtual entities, real-world services provide real-time data about the physical world. Devices providing their functionality as a Web service can be used by other entities such as enterprise applications or even other devices. Authors discussed that services on embedded devices offer rather atomic operations such as obtaining data from a temperature sensor. Thus, the services that the sensor nodes can offer share significant similarities and could be deployed on-demand per developer request. The core mechanism is that on-demand service provisioning first tries to discover service instance on the network that matches the developer's requirements.

If this fails, installation of services on suitable devices are carried out.

Li et al. [START_REF] Li | A distributed consensus algorithm for decision making in service-oriented internet of things[END_REF] proposed a three-layer service provisioning framework for service- BUGswarm [START_REF] Bugswarm | BUGswarm[END_REF] IP networked devices RESTful APIs Carriots [START_REF]Carriots[END_REF] Web-enabled devices RESTful APIs EVRYTHNG [START_REF]Evrythng[END_REF] Web-enabled devices RESTful APIs (EVRYTHNG Engine) GroveStreams [START_REF]Grovestreams[END_REF] Web-enabled devices RESTful APIs Nimbits [START_REF]Nimbits[END_REF] Sensors RESTful APIs

Open.Sen.se [35] General physical objects RESTful APIs JSON, XML Paraimpu [START_REF]Paraimpu[END_REF] Web-eanbled devices RESTful APIs

NanoService [START_REF]NanoService[END_REF] Embedded

Semantic Annotation and Provisioning

Literature in applying Semantic Web technologies to IoT is focusing on semantically annotating data from smart objects similar to what Semantic Web envisions about the Web of Linked Data. The predominant technique for representing semantics is using Resource Description Framework (RDF) [START_REF]RDF Primer[END_REF], which represents knowledge as triples (subject, predicate, object) (e.g., [TempSensor803, hasValue, 18 ] and [TempSensor803, locatedIn, Room803 ]). A set of triples forms a graph where subjects and objects are vertices and predicates are edges. The advantage of RDF and graph data model is that one can infer new knowledge from existing graph. For example, a system can use domain knowledge to understand that the temperature in Room 803 is 18 degree, which is transitive property. The domain knowledge is often expressed using Web Ontology Language (OWL) [START_REF]OWL 2 web ontology language document overview[END_REF], one of the main languages (with RDF schema) to define ontologies on the Web.

To carry out the annotation on smart objects, World Wide Web Consortium has pioneered to establish a working group to gather contributions in this field and to define the first universal ontology for semantic sensor networks (SSNs) [START_REF] Compton | The ssn ontology of the w3c semantic sensor network incubator group[END_REF]. They developed SSN ontology3 that is an OWL 2 ontology being able to describe sensors in terms of capabilities, measurement processes, observations and deployments. The SSN ontology follows a central Ontology Design Pattern (ODP) [START_REF] Gangemi | Ontology design patterns for semantic web content[END_REF] depicting the relationships between sensors, stimulus, and observations. The ontology can be seen from four main perspectives: a sensor perspective, with a focus on what senses, how it senses, and what is sensed; an observation perspective, with a focus on observation data and related metadata; a system perspective, with a focus on systems of sensors and deployments; and, a feature and property perspective, focusing on what senses a particular property or observations have been made about a property.

Several studies focused on publishing semantic sensor data. Sense2Web [START_REF] Barnaghi | Publishing linked sensor data[END_REF], for example is a linked-data platform to publish sensor data and link them to existing resource on the Semantic Web. Sense2Web facilitates the publication of linked sensor data and makes this data available to other Web applications via SPARQL [START_REF]Sparql 1.1 query language[END_REF] endpoints. Pfisterer et al. [START_REF] Pfisterer | Spitfire: toward a semantic web of things[END_REF] introduced the vision of Semantic Web of Things for building semantic applications involving Internet-connected sensors as easy as building, searching, and reading a Web page today. This is done by a crawler periodically scanning the Semantic Web of Things for semantic entities and sensors, downloading metadata and prediction models using their Web APIs, converting this information into RDF triples, and storing them in the triplestore.

The work in [START_REF] Hasemann | Rdf provisioning for the internet of things[END_REF] is another approach in provisioning semantic annotation for IoT smart objects, similar to the Semantic Web of Things vision. It is about a platformindependent Wiselib RDF Provider to enable the Internet-connected smart objects to act as semantic data providers. They can describe themselves, including their services, sensors, and capabilities, by means of RDF documents. A smart object can auto-configure itself, connect to the Internet, and provide Linked Data without manual intervention.

The authors proposed to use a semantic storage for storing RDF documents from smart object data and a data provider responsible for dynamic parts of the RDF documents, such as measurements. It converts sensing data to RDF and inserts it into the semantic storage. Using the Wiselib's callback sensor concept, the data provider gets notified when the value of its associated sensor changes. Another module RDF service broker provides an interface for clients to access and modify the RDF in the storage and to manage subscription from clients.

[51] Bimschas et al. investigated unified concepts, methods, and software infrastructures that support the efficient development of applications across the Internet and the embedded world based on Semantic Web technologies. From an abstract point of view, the main task of IoT application developers is obtaining the data for a specific task.

In distributed systems, this requires (1) to identify entities holding the data and (2) to retrieve them. In this paper, authors proposed a methodology to simplify IoT application development. The approach combines technologies from the Internet of Things and the Semantic Web to provide this service efficiently. The central idea is to let entities provide self-descriptions of their type, capabilities, services, etc. in a machine-readable manner.

The paper [START_REF] De | Service modelling for the internet of things[END_REF] presented an IoT semantic service model for different components in an IoT framework over physical entities. It is also discussed how the model can be integrated into the IoT framework by using automated association mechanisms with physical entities and how the data can be discovered using semantic search and reasoning mechanisms. The entity constitutes things in the Internet of Things and could be a human, animal, car, store or logistic chain item, electronic appliance, or a closed or open environment. The relations between services and entities are modeled as associations.

These associations could be static, e.g., in case the device is embedded into the entity or dynamic, e.g., if a device from the environment is monitoring a mobile entity. The semantic modeling and OWL/RDF descriptions solve the interoperability issues within the stakeholders that have agreed and/or provided data using the models. Klaine argued in [START_REF] Kleine | Integrating the physical world with the internet -a concept evaluation[END_REF] and the resource (Data Origin). SSP contains a semantic database as the presentation of data collected from sensor nodes, which is the core of the provisioning process. Since the SSP focuses on semantic service provisioning, the cache is well fitted to semantic content, i.e., triples. This allows Data Consumers not only to retrieve cached resource states but also use SPARQL to find resources with certain properties. The SSP provides an endpoint to run queries on its cached resources via its Web URI.

Literature Analysis

We observe several problems in literature about IoT service provisioning as follows:

• Most of the studies focus on the high-level architecture and models for service provisioning without sufficient details about networking protocols at smart object level and about the integration with traditional services at application level.

Services from smart objects possess different characteristics then traditional ones as they operate in constrained environments (e.g., low capacity nodes, lossy and low-rate network). It is therefore necessary for service provisioning architecture to consider these properties.

• Current studies have not considered a full IP IoT in service provisioning, which results in the use of protocol gateways to translate non-IP to IP-based communication. Protocol gateways are complex to design, manage, and deploy; their network fragmentation leads to non-efficient networks because of the inconsistent routing, QoS, transport, and network recovery. End-to-end IP architecture is considered suitable and efficient for scalable networks of large numbers of communicating devices such as the IoT.

• Service provisioning in SOA-based IoT using W3C Web Service architecture is facing many difficulties such as the heavyweight of Simple Object Access Protocol (SOAP) messages and the complex parsing XML documents. Web APIs are providing an efficient ways of interacting between Web applications ensuring smooth and simple operation of the Web and coping with the future participation of millions of smart objects. This approach originally aim to IoT application in enterprise solutions which base on business processes of Web services.

• Semantic annotation of smart objects is incorporated within the annotation of sensor data. Whilst, the annotation of functionality (i.e., not data) is also important for these services are present in a great number of smart objects such as services to switch on/off a light bulb and to activate a watering system. The future of IoT is driven by many types of objects that carry not only data but also functionalities. Currently, there are two methods for annotating smart objects (either data or functionality): direct annotation and third-party service. The former incurs large data stored in smart objects and large exchange messages due to the use of XML-based RDF standard. The latter represents a single bottle neck by which the communication stream can be broken or interfered.

In this dissertation, we aim to overcome these problems by carrying out empirical study of 6LoWPAN performance, requirement analysis, and then propose a new semantic service provisioning to empower the IoT applications on Web. This chapter presents the key requirements of service provisioning for 6LoWPAN followed by the proposed system architecture. The architecture aims to provision smart object services in 6LoWPAN using open standards to power IoT applications on Web connecting smart objects with existing Web services in a scalable, secure, and reliable manner. We provide the architecture in different perspectives including reference infrastructure, data model, multilayer architecture, functional block diagram, and provisioning workflow. The architecture is based on all IP protocol and networking principles realized by service communication subsystem in the functional block diagram. On top of that, service provisioning uses a scheduling algorithm, OAuth 2.0 authorization framework, semantic annotation, and URI mapping schemes to generate Web APIs to be used in IoT applications on Web by mechanisms explained in the service integration subsystem.

Requirements

Smart objects and 6LoWPANs are similar to any IP-based computer network, but they carry many different characteristics that need to be taken into account. This section presents the core requirements of service provisioning in 6LoWPAN.

Open Standards and Interoperability

The Internet as we see today is based on a plenty of open and non-proprietary standards.

They are the key for a huge number of devices, services, and applications across the global to exchange data in a wide and dispersed network of networks. Some international groups are behind the development of these standards such as the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), and the World Wide Web Consortium (W3C). These organizations are all open, transparent, and rely on a consensus-based decision making process to develop standards. They are experts around the world working together to create freely-accessible specifications that available online at no charge, thus to foster the adoption of them.

Open standards lie at the core of the success of today's Internet and Internet-related technologies. While the Internet continues to grow to the next evolution with the arrival of new actors, smart objects, to create the new ecosystem of the Internet of everything or IoT, it is critical that new technologies continue to be developed based on open principles and processes. When it comes to system design such as service provisioning, using open standards does not only provide the interoperability, but also can backward promote the development of the Internet technologies.

Interoperability is the key characteristic of the Internet where the information being exchanged across a wide network of heterogeneous systems and devices. It is about the ability of a system to work with or use the functions of other systems. It has been one of the key requirements for Internet applications, which are based on the communication of different hardware and software infrastructure. In IoT, the heterogeneity of the systems and devices become even larger where smart objects, which are limited in resources, cannot operate in a full-fledged manner with other networks. Therefore, for new IoT systems to be an integral part of the Internet, they must be able to exchange data and subsequently present that data such that it can be consumed by existing systems on the Internet. Interoperability requires standards on several levels. It is necessary to have uniform mechanisms in what is being exchanged (data elements), how to structure data for exchange (record schemas and record syntaxes), and how to actually exchange it (protocol transactions and messages and profiles).

Service provisioning therefore has to provide data format, protocol messages, and data schema that can be used in other systems on the Web using open Web standards Web design principles such as Representational State Transfer (REST) [START_REF] Fielding | Principled design of the modern web architecture[END_REF] and Semantic Web [3] are the key to enable the interoperability for IoT applications on Web.

Low Energy Consumption

Energy consumption has been at the center of any discussion for the sustainable development these days, especially when the digital revolution has happened recently. Machines are driven by electronic parts, and electronics need power. This fact brings the energy issue even up to a more critical level when the IoT is happening very fast with billions of personal electronic are predicted to be available in coming years. Today, the most common power source is a battery, but there are also several other possibilities such as solar cells, piezoelectricity, radio-transmitted energy, and other forms of power scavenging. Power scavenging is a technique in which devices harvest power from the physical environment. Solar cells represent the most common form of power scavenging. They harvest their power from the ambient and direct light hitting the smart object. While static energy sources are limited, for those powered by power scavenging, energy is not always assured and difficult to be stored for extended periods of time.

For this reason, both the hardware and the software of the smart object must be designed to meet stringent power requirements. To achieve this, low-power hardware such as microprocessors and radio chips have been developed. Low-power radio hardware, which is the most critical part of consuming energy in smart objects to maintain the connectivity, however it is still not sufficient. Existing low-power radio transceivers (though optimized) use too much power to provide long lifetime on batteries. For example, the CC2420 radio transceiver, used in the MTM-CM5000-MSP TelosB and Z1 motes, use approximately 60 milliwatt of power when listening for radio traffic and a similar figure for data transmission. By that power, radio operation depletes 2 AA batteries equipped for these motes in a matter of days. Therefore in addition to hardware, software design of protocols and system architecture play an important role on improving the energy consumption of smart objects. For example, radio duty cycling mechanisms (e.g., ContikiMAC) aim to deal with this problem by keeping the radio turned off as much as possible while providing enough rendezvous points for two smart objects to communicate.

Reliability

The trade-off of low-power design for smart objects and 6LoWPAN comes with the less reliable communication link due to the use of low-power and low bitrate protocols.

There are fundamentally two factors in 6LowPAN leading to the low reliability of the network: constrained processing power in smart objects and lossy and low bitrate in the communication. To fulfill the energy requirement, smart objects are equipped with limited processing power, memory, and energy; they are also in many cases batteryoperated or energy scavenging that leads to the data processing capacity is subject to a limit. Besides, smart objects are interconnected by lossy links, typically supporting only low data rates that are usually unstable with relatively low packet delivery rates. This may result in the loss of packets. There have been efforts to handle the issue such as new routing protocol RPL considering the loss nature of the link. Even when mechanisms for dealing with high packet loss rate are applied, long delay between service requests and responses is anticipated due to the limited resource on the smart objects side. In many applications, the delay may be not tolerable for practical uses. Therefore, to effectively integrate 6LoWPAN into the Internet environment, IoT architects have to take into account this requirement as one the core values.

Security and Privacy

Security in IoT is becoming a critical issue with millions of devices getting connected to the Internet. The IoT means that everyday objects going online, being connected, and talking to each other without human being's involvement to, for example, carry out many of our tedious routines. For what we are witnessing today, the first wave of the IoT is already around with several tracking devices on the market such as activity trackers that record your movements and geographical position, baby monitors that measure breathing and skin temperature, and smart Wi-Fi light bulbs that can be programmed via a smartphone. The question is how these personal data are being handled and by whom. The autonomy of devices comes with more concern about our privacy and when more objects expose themselves to the Internet, more security issues come to our software systems where these objects are also connected. The critical problem is these smart objects are getting smarter to intervene in users' privacy. It is possible that once you bought a television, turn it on and while it serves you with new smart services taking into account of your preferences and use contents on the Internet, it could be listening to your private conversations and sharing them over the Internet.

Another issue with security and privacy for smart objects is that they have the owner-object relationship to their owners and the owners have several preferences for setting up their devices. Smart objects, different to other resources on the Web, have limited resources and a special degree of privacy because they belong to individuals with their privacy to protect and have limited resources. Therefore, the consumption of smart object services should be well-managed in a secure and stable manner. Therefore, provisioning smart objects services has to come with appropriate authorization to use.

Scalability

Today's Internet is a giant global network of networks based on IP-based protocols thanks to its inherent scalability. No other networking technology in the history has ever been deployed and tested at such an immense scale and with such a large number of devices. As smart objects will connect to the Internet in even a larger number, scalability is a primary concern and should be staying at the core of designing new system. To assure the continuous development of the Internet, smart objects and 6LoWPANs as new actors are required to work in the similar scalable manner. Service provisioning must be efficient and practical when applied to large-scale situations either in the scale of 6LoWPANs or of IoT applications on Web in addition to the assurance of system performance when the network expands. Also, at network deployment level, the installation of smart objects network in any facility (home, office, public space, etc.) is required to be fast and integral part with the existing communication infrastructure.

This requirement leads to a direct suggestion of using IP-based protocols for IP has proven itself a stable and highly scalable communication technology that supports both a wide range of applications, devices, and underlying communication technologies.

End-to-end IP architecture is considered suitable and efficient for scalable networks of large numbers of communicating devices such as the IoT. The next generation Internet protocol, IPv6, expands the address space from 32 bits to 128 bits. Such a large address space has been estimated enough for billions of smart objects going online in the near future. The adoption of IP standards can be carried out at low level of smart objects themselves to avoid using protocol translation gateways, which prevent the scalable deployment of 6LoWPAN and IoT systems.

IoT Application on Web

The Internet is a scalable global network of computers that interoperate across heterogeneous hardware and software. On top of the Internet, the Web is an outstanding example of how a set of relatively simple and open standards can be used to build very complex systems while preserving efficiency and scalability. The Web and its underlying open protocols have become a part of our everyday life -something we access at home or on the move, through our laptop computers, phones, tablet, TV, or wearable devices. It has changed the way we communicate and has been a key factor in the way the Internet has transformed the global economy and societies around the world.

Meanwhile, the IoT will allow physical objects to transmit data about themselves and their surroundings, bringing more information about the real world online and help users to better interact with their surroundings. Flowers, for example, can send you an email or a SnapChat1 photo of your flower when they need watering. Doctors can implant sensors in your body that give you real-time updates about your health updating frequently to a secure online database of your personal data. Even more, IoT data will go beyond the scope of each own service provider to go online and share with other IoT application on Web is the natural evolution of Web application when Internet is transforming to the Internet of everything to include smart objects in the loop. There can be an application to get access to your Google calendar with the note of cleaning your living room to have your mother visit in few hours. The application then asks your robot cleaner to automatically wake up and do cleaning. Robot cleaner notifies you (by sending an email or a SnapChat message) when it starts working or finishes the work. Another application can let you talk to your devices in the way you talk to your friend with the support of natural language processing engines; this is the new experience of making friendship with your devices. Yet another application can serve you in the airport to update the status of the flight, providing practical information in the airport, connecting to the boarding machine to update you for any delay of boarding time that you can spend more time doing shopping in duty free. Yet another application can synchronize your TV programs and football schedule and also your social network profile to remind you an upcoming match. These applications all require the interactions of existing Web services and new services from smart objects to create new user experience while assuring the seamless transition from developing traditional Web applications to this new type of IoT applications on Web. This is where our work comes in to solve the fundamental problem of such ecosystem, service provisioning. F i g u r e3 . 1 : T h er e f e r e n c e i n f r a s t r u c t u r e .

. S y s t em A r c h i t e c t u r e T h i s s e c t i o np r e s e n t sd e t a i l so no u rp r o p o s e d s e r v i c ep r o v i s i o n i n ga r c h i t e c t u r e i n c l u d i n g R e f e r e n c eI n f r a s t r u c t u r e , D a t a M o d e l , M u l t i l a y e r A r c h i t e c t u r e ,a n dF u n c t i o n a l B l o c k D i a g r am . W ea l s op r o v i d eab r i e f i n t r o d u c t i o no ne a c hc om p o n e n to ft h ea r c h i t e c t u r e , w h i c hw i l lb ee l a b o r a t e d i nt h e f o l l o w i n gc h a p t e r s .

. . 1 R e f e r e n c eI n f r a s t r u c t u r e F i g u r e. 1 i l l u s t r a t e s t h e r e f e r e n c ea r c h i t e c t u r e i nw h i c h sm

E dR )a n db e y o n dt ot h eI n t e r n e tt h r o u g has e r i e so fo t h e r r o u t e r sa c r o s s t h en e t w o r k .Sm a r to b j e c t sa r efi r s t m a n u f a c t u r e dw i t hp r im i t i v e s e r v i c e s i n s i d e , w h i c hc a nb er e -p r o g r amm e d . T h e s es e r v i c e sa r et h e np r o v i s i o n e dt ot h eI oT a p p l i c a t i o n so n W e bb yt h e m e t h o dp r e s e n t e d i no u rp r o p o s e da r c h i t e c t u r e . T h e s ea pp l i c a t i o n sa r eh o s t e do

u s e t h e W e bA P Ip r o v i s i o n e d f r om t h e s e sm a r to b j e c t s t op r o v i d eah a n d y t o o l f o ru s e r s t o r em o t e l yc o n t r o l t h e i rh om ew i t h t a s k s s u c ha s sw i t c ho no ro ffa l i g h tb u l b . A n o t h e r a p p l i c a t i o ni sa H om eS u r v e i l l a n c e W e ba p p l i c a t i o np r o v i d i n gs u r v e i l l a n c es e r v i c ef o r u s e r st or em o t e l yt r a c kt h e i rh om ee n v i r o nm e n ts u c ha sn o t i f y i n gu s e r st h a tt h e i rk i d s

a r ea th om e . T h e s ed a t ac r e a t ed a t a m o d e l f o ro u rp r o v i s i o n i n ga r c h i t e c t u r e .

D a t aa r eo r g a n i z e da c c o r d i n gt ot h er e f e r e n c ea r c h i t e c t u r et os t o r ed i ff e r e n t i n f o rm a t i o na b o u tt h esm a r to b j e c t s ,6 L oW P AN ,a n ds e r v i c e s . T h e r ea r et h r e ek i n d so f d a t a :o b j e c td a t a ,p r o v i s i o n i n gd a t a ,a n da p p l i c a t i o nd a t a . O b j e c td a t a , w h i c hs t o r e i n f o rm a t i o na b o u tp r im i t i v es e r v i c e sd i r e c t l yp r o v i d e df r omsm a r to b j e c t s ,c o v e rt h e p h y s i c a lr e s o u r c es t a t u sa n dc o n t e x t u a ld a t as u c ha st em p e r a t u r ea n dh um i d i t y . T h e y c a nb e im p l em e n t e d i nt h esm a r to b j e c t su s i n gr e s o u r c e -c o n s t r a i n e dp r o t o c o l ss u c ha s C oA P ,D PW S ,a n dXM P Pa n da c c e s s e dv i ap r o t o c o l m e s s a g e s . P r o v i s i o n i n gd a t a s t o r e i n f o rm a t i o na b o u ts e r v i c e sp r o v i d e db y6 L oW P ANn o d e se n r i c h e db ys em a n t i ca n n o t at i o nw i t hr e f e r e n c et ot h ed om a i no n t o l o g y . A p p l i c a t i o nc a ng e ta c c e s st ot h i sd a t ab y c a l l i n g i t s W e bA P I .A p p l i c a t i o nd a t as t o r eh i g h -l e v e l i n f o rm a t i o na b o u ts i n g l es e r v i c e s a n dc om p o s i t es e r v i c e sp r o v i d e db y6 L oW P ANt h a t m e e tt h er e q u i r em e n to fe a c ha pp l i c a t i o n . B e s i d e s ,a p p l i c a t i o n l o g i c sa r es t o r e d i nt h i sr e p o s i t o r y . B yt h i sd a t a m o d e l ,

I oTa p p l i c a t i o n so n W e bc o l l e c ta n ds t o r es em a n t i cd a t a ,c o n s u l t i n gt oo n l i n eo n t o l o g y t oh a n d l e m a n yc o n t e x t -a w a r es c e n a r i o . F i g u r e3 . 3 : M u l t i a y e ra r c h i t e c t u r e .

T h eo r g a n i z a t i o ns c h em ao fo u rd a t a m o d e l i ss h o w n i nF i g u r e3 . 2 . T h er e p o s i t o r y o nt h et o po ft h eh i e r a r c h y , i nt h e f o rmo fa p p l i c a t i o nd a t a b a s e , i s l o c a t e d i nt h e W e b s e r v e ro rc l o u d w h i c hc om b i n e ssm a r to b j e c t ss e r v i c e s w i t hc o n v e n t i o n a l W e bs e r v i c e s t oc r e a t en o v e lc om p o s i t es e r v i c e s . O n t o l o g y i s s e p a r a t e l yd e v e l o p e db y m a n yp r o v i d e r s w h oh a v ee x p e r t i s eo ne a c hd om a i n . T h ep r o v i s i o n i n gd a t ar e p o s i t o r y i sat r i p l e s t o r e l o c a t e d i nap r o v i s i o n i n gs e r v e r ,w h i c hc a nb e l o c a t e d i n l o c a ln e t w o r ko ro nt h e W e b .

O b j e c td a t ar e p o s i t o r y i s l o c a t e d i nsm a r to b j e c tw i t h i t sfi l es y s t emo rd y n am i c a l l y i n p r o g r am l o g i c .

. . M u l t i l a y e r A r c h i t e c t u r e F i g u r e. 3s h o w sah i g h -l e v e lv i ewo ft h ea r c h i t e c t u r ei nt h ef o rmo f m u l t i l a y e ra rc h i t e c t u r e . T h e r e i n ,t h eSm a r t O b j e c t L a y e ri st h el o w e s tl a y e r w h e r es e r v i c e sa r e im p l em e n t e do np h y s i c a le n t i t i e s i n c l u d i n gsm a r to b j e c t sa n dc o n v e n t i o n a lc om p u t e r s . T h i s l a y e rc o n s i s t so f6 L oW P AN sa n dr e g u l a rI Pn e t w o r k s . E a c h6 L oW P ANc o n n e c t s t oa ne d g er o u t e r6 E dRw h i c hc a r r i e so u tt h er o u t i n g f u n c t i o nb e t w e e nt h e6 L oW P AN t or e g u l a rI Pn e t w o r k sa s s u r i n gt h ec o n s i s t e n c e i nr o u t i n g , Q u a l i t yo fS e r v i c e ,t r a n sp o r t ,a n dn e t w o r kr e c o v e r yf o rt h ee n t i r es y s t em . R e g u l a rI Pn e t w o r k sa l s or e s i d e i n t h i s l a y e rp r o v i d i n gs e r v i c e st ot h e W e b i nas im i l a r w a yt o6 L oW P AN s . T h es e c o n d l a y e r i st h eS e r v i c eP r o v i s i o n i n gL a y e rr e p r e s e n t i n gt h e i n t e r f a c eb e t w e e nsm a r to b j e c t s a n da p p l i c a t i o n so nt h eI n t e r n e t . T h e r ew i l lb ea W e b A P Ia s s o c i a t e dt oe a c h6 L oW -P AN ,w h i c hc a nb eu s e d i n m u l t i p l ea p p l i c a t i o n sa n d m a s h e du pw i t ho t h e r W e bA P I s o fsm a r to b j e c t sa n dc o n v e n t i o n a l W e b A P I s . T h et h i r d l a y e r i s A p p l i c a t i o nL a y e ro f I oTa p p l i c a t i o n so n W e b . T h i s l a y e re x h i b i t st h e m e c h a n i smo fh o wa na p p l i c a t i o nu s e

F i g u r e3 . 4 :F u n c t i o n a lb l o c kd i a g r am .

6 L oW P AN W e b A P I st o i n t e r a c t w i t hsm a r to b j e c t s ,a n dh o wt h e s ea p p l i c a t i o n sc a n c a r r yo u ts em a n t i cr e a s o n i n gb yr e t r i e v i n gs em a n t i ca n n o t a t i o n f r omsm a r to b j e c ta n d q u e r y i n g f r oma v a i l a b l eo n t o l o g y i nt h ed om a i n . sm a r to b j e c t s i n c l u d e s s t e p s :r e t r i e v i n g W e bA P I f r om s e r v i c ep r o v i d e r s ,r e q u e s t i n ga ut h e n t i c a t i o nt o k e n s ,r e q u e s t i n gasm a r to b j e c ts e r v i c e ,r e c e i v i n gr e s p o n s ef r omsm a r t o b j e c t ,q u e r y i n ga n dr e a s o n i n gu s i n ga na p p r o p r i a t ed om a i no n t o l o g y ,a n d m a s h i n gu p w i t ho t h e rA P I s . System Architecture communicate with applications on the Web and interact with sensor/actuator hardware in smart objects to, for example, collect contextual information and activate a routine task of smart objects. Smart objects are also enriched by simple semantic annotation based on domain ontology previously published or available on the Web. Each service is identified by an identity, which plays a role of an endpoint address for service communication. Also this identity is reserved for security purposes. This domain enables the consistent communication between smart object networks and normal IP networks also facilitate smart object functionalities using open application standards.

. . 4 F u n c t i o n a l B l o c k D i a g r am F i g u r e. 4d e p i c t st h ep r o p o s e ds e r v i c ep r o v i s i o n i n ga r c h i t e c t u r ew i t h f u n c t i o n a lb l o c k s d i v i d e d i n t ot h r e es u b s y s t em s :s e r v i c ec omm u n i c a t i o n ,s e r v i c ep r o v i s i o n i n g ,a n ds e r v i c e i n t e g r a t i o n . T h e s ef u n c t i o n a lb l o c k sp r o v i d eg u i d e l i n e sf o rim p l em e n t i n gr e l e v a n tI P n e t w o r k i n gs t a c k s i nsm a r to b j e c t s .I Pn e t w o r k i n g f o rsm a r to b j e c t s i st h e f o u n d a t i o n f o r f a c i l i t a t i n gs e r v i c e su s i n ga p p l i c a t i o n l a y e rp r o t o c o l sd o i n gs em a n t i ca n n o t a t i o n st

. . 4 . 1 S e r v i c e C omm u n i c a t i o n S t a r t i n gw i t hS e r v i c eC omm u n i c a t i o ns y s t em ,t h e f u n c t i o n a lb l o c k ss u g g e s tt h a tsm a r t o b j e c ti sim p l em e n t e d w i t hl o w -p o w e ro p e r a t i n gs y s t em ss u p p o r t i n gc o n s t r a i n e dI

Service Provisioning

The Service Provisioning subsystem, based on the IP infrastructure in 6LoWPAN, encapsulates constrained protocols and interfaces into useful Web APIs that can be used in multiple IoT applications on the Web. One of the common characteristics of smart object services is the ability of dynamic discovery, mostly using multicasting. Service Discovery functional block is deployed to either relay the multicast messages to the applications or forward the messages in and out the local network. URIs discovered in discovery process are sent to URI Mapping to apply the mapping rules. Developers also can maintain the service cache by providing discovered data to a cache module. Provisioning Interface in the form of Web API contains descriptions of smart object services that can be consumed by IoT applications on the Web. It also provides the ability for applications to mashup smart object services with other Web services.

Each API request consisting of a HTTP verb (GET, POST, PUT, and DELETE) on an URI (retrieved from URI Mapping) and an authentication token comes to the Request Handling for preprocessing. Request Handling parses the token to get the permission of using the services and first looks into the cache for available resource to bypass the discovery step. If the resource is not found in the cache, Request Handling with send a discovery request to the target smart object to check for its availability and updated information. Thereafter, the request is put into the Scheduling queue waiting for interacting with the target smart object. This Scheduling block is to ensure that the constrained environment can reply to a maximum number of requests. When the request is process, data go through a dispatcher for communicating with the target smart object.

Service Integration

In Service Integration subsystem, each IoT application on Web can use smart object Web APIs in the same way as other Web APIs and carry out inference from semantic data. Provisioning Interface provided by the Service Provisioning subsystem to be used by IoT applications on Web in the same way that conventional Web applications use

. . 5 P r o v i s i o n i n g W o r k fl ow

c t f u n c t i o n a l i t y i n t h e f o rmo f s e r v i c e s ,a u t h e n t i c a t i o n s c h em e s ,a n d s em a n t i ca n n ot a t i o n s . T h efi n a l s t e p i n v o l v e s s e r v i c ep r o v i d e r t op r o v i s i o n sm a r to b j e c t s e r v i c e s t o t h e

a p p l i c a t i o n so n t h e W e b . D e v e l o p e r sc a ns t a r t t ou s eas e to fsm a r to b j e c tb ya c q u i r i n g t h e i rA P I ,a u t h e n t i c a t i o nt o k e n st og e ta c c e s st ot h eA P I ,a n dd om a i no n t o l o g yt ou s e r e a s o n i n g w i t hs em a n t i cd a t ar e t r i e v e df r omsm a r to b j e c t ,d e p i c t e d i nt h en e x ts t e p .

T h e r e a f t e r ,a p p l i c a t i o n sc a nc omm u n i c a t ew i t hsm a r to b j e c t sv i aHTT P m e t h o d so v e r W e bA P I , m a s h u pw i t ho t h e r W e bA P I sa n dd o i n gr e a s o n i n gb a s e do ns em a n t i ct o o l s .

. 4 S umm a r y T h i s c h a p t e rh a sg i v e n t h eo v e r a l la r c h i t e c t u r e f o r s em a n t i c s e r v i c ep r o v i s i o n i n go f6 L oW -P AN .I nt h en e x tc h a p t e r s , w e w i l l i n t r o d u c et h ed e t a i l so fe a c hs u b s y s t emt or e a l i z e t h i sa r c h i t e c t u r e .S t a r t i n gw i t hC h a p t e r4 ,w ep r e s e n tt h ed e s i g n , im p l em e n t a t i o n ,a n d e v a l u a t i o no f6 L oW P ANw i t hw h i c h ,t h er e s u l t sa c ta st h e f o u n d a t i o nt ob u i l du pt h e p r o v i s i o n i n ga r c h i t e c t u r ed e s c r i b e di nt h en e x t C h a p t e r5 . C h a p t e r6d e s c r i b e st w o i n n o v a t i v ea p p l i c a t i o n sa p p l y i n gt h ep r o p o s e da r c h i t e c t u r e .

Chapter 4

Design and Performance Study of 6LoWPAN

W h i l e t h e s e t e c h n o l o g i e sa r eg a i n i n g s t a b l e s t a t u s ,h o w t h e ya ff e c t t h ed e s i g no fm a n y

p o t e n t i a li n t e l l i g e n ta n du b i q u i t o u sI oTa p p l i c a t i o n si ss t i l lr a t h e ra ni s l a n df o rn ew

6LoWPAN Edge Router

In order to connect 6LoWPAN networks to other IP networks, we use 6LoWPAN Edge Routers (6EdRs). These edge routers are located at the border of the 6LoWPAN performing two essential tasks: adaptation between 6LoWPAN and regular IPv6 networks and routing the IP traffic in and out of the 6LoWPAN. This transformation is transparent, efficient and stateless in both directions.

6LoWPAN Implementation

Hardware

We use CM5000 motes equipped with three LEDs, a temperature sensor, a humidity sensor, two light sensors, and button sensor as generic smart objects to set up a 6LoW-PAN. With several sensors and LEDs, CM5000 can represent many home and building appliances such as a light sensor, a light bulb, a thermostat, a switch, and even a motion sensor. We use a RPi for the edge router with the built-in Ethernet as an IPv6 interface and a CM5000 mote connecting to RPi USB port as a 6LoWPAN interface (IEEE 802.15.4). Some laptop computers are used to deploy a regular IPv6 networks with Ethernet interfaces connecting to the same router with the edge router. packet is forwarded to the IPv6 network, edge router removes its 6LoWPAN adaptation layer, uncompresses its header, and ensures that global IPv6 source address is used for the outgoing packets. For incoming packets to the 6LoWPAN, edge router adds 6LoWPAN specific adaptation layer and possibly 6LoWPAN IPv6 header compression mechanism and then forwards them to the 6LoWPAN.

Performance Evaluation

We carry out the experiments on the communication between a 6LoWPAN and a regular IPv6 network to observe the quality of the link in several aspects under a real-life deployment. The deployment takes place in an L-shape office building floor. We deploy the 6LoWPAN with a 6EdR and a number of nodes and a simple IPv6 network with one host. The 6EdR is deployed in one office along with a laptop computer (as a regular IPv6 host), both connected to the same local network via a home and building router. Three nodes are put in 1-hop, 2-hop, 3-hop positions to the edge router as shown in Figure We carry out the fourth experiment on message overhead and latency of service communication between a Web application and smart objects using CoAP, DPWS, and HTTP protocols (via CoAP/HTTP proxy). We use Java, CoAP Californium library [START_REF] Kovatsch | Californium: Scalable cloud services for the internet of things with coap[END_REF], and WS4D-JMEDS [START_REF]Web Service for Devices Initiative[END_REF] to implement the Web application.

Discussion and Lessons Learned

Energy Consumption

Based on the average capacity of an AA battery is 2500 mAh and nominal voltage is 1.5 V, we can estimate the battery life for smart objects to maintain the connectivity (using duty cycling) as following Formula 4.3

2500mAh × 1.5V × 2 0.37mW × 24h × 365days = 2.304years (4.3)
where 0.37mW is the average power of smart objects in host mode when idle.

Current IPv4 Infrastructure

Even though IPv6 is an ideal addressing space for future Internet but the shift to IPv6

is still happening at a slow pace accounting for only 5 percent of the worldwide Internet traffic, according to Cisco 6lab shows that it can be implemented on top of IP protocol stack to (even) highly resourceconstrained smart object such as sensor nodes (thanks to uDPWS 16 and Contiki OS).

Web Services

The request and response messages are relatively large compared to HTTP or CoAP but still well operate on very limited node. Besides, in smart objects with higher computing power and memory such as home appliances and office equipments, DPWS can perform in its best to enable secure translations between smart objects and applications.

Deployment

From the experiment results, we look into some deployment issues such as how large 6LoWPAN coverage can be in typical premises and how difficult the deployment can be when it comes to mass production.

IEEE 802.15.4 Radio Range

Since the radio signal is considerably strong at 15 m in reality, the range of the network is considered sufficient to several homes and buildings. 1-hop 6LoWPANs which only

Installation

IoT application thus far is frequently considered high cost and difficulty to deployment.

However, with the presented design, the deployment of 6LoWPAN such as for home and building networks appears to be easy and intuitive, in the same way to conventional IP networks. The edge router hardware and software can be developed very fast and at low-cost using current advances in micro-electronics and radios (equivalent to a single computer board plus a 802.15.4 radio module). Besides, services of smart objects can seamlessly reside on the Web by implementing application protocols such as CoAP, DPWS, and protocol proxy for HTTP. By that, the development model from developers' point of view virtually remains the same, which will stimulate more the adoption of IoT applications. Furthermore, the installation of smart objects in 6LoWPAN is zeroconfiguration, which doesn't require any additional commissioning device (e.g., a laptop computer). In other words, a smart object can obtain an address and join the 6LoWPAN on its own, without human intervention.

Summary

We have presented our design of 6LoWPANs using open standards with a real-life implementation for home and building networks. The present study on networking performance of 6LoWPANs exhibits several positive results on the deployment and on the perspective of using IP protocols for smart objects for end-to-end communication with services/applications on the Internet. This study is the fundamental for us to develop service provisioning mechanisms presented in the next chapter to power the IoT applications on Web. They also provide essential data to set up simulation environments in Contiki OS Cooja and our own DPWSim simulators.

We in the previous Chapter 4 have successfully designed and implemented 6LoW-PANs for smart objects. Experiment results show that even highly-constrained objects can communicate effectively (energy, round-trip time, messages, etc). with IP protocols. 6EdR routers provide a transparent traffic between smart objects and regular IPv6 nodes, and to the Internet. The 6LoWPAN eliminates the protocol translation that is complex to design, manage, and deploy and its network fragmentation leads to non-efficient networks because of the inconsistent routing, QoS, transport, and network recovery. End-to-end IP architecture is considered suitable and efficient for scalable networks of large numbers of communicating devices such as the IoT. The deployment of 6LoWPANs is relatively intuitive and easy to carry out and virtually in the same way as installing regular IP networks. Besides, application protocols such as DPWS and

CoAP enable the use of smart objects services in IoT applications. However, for IoT applications on Web to use these services in practical and scalable scenarios, there still exist several problems that need to be addressed, as presented in following Section 5.1.

Provisioning Issues

Service Discovery

Simultaneous Requests

The 6LoWPAN design enables smart objects to be accessed directly from Internet using native IP protocols without any protocol translation support. However, smart objects only support a very small number of simultaneous requests due to their resourceconstrained nature (memory, processing power, and communication bandwidth) and this issue is also related to the implementation of the networking stacks. Although the use of constrained operating systems with a full IoT protocol stack (e.g., Contiki OS) can manage these requests, it can cause the long delay in service response. The delay increases significantly when more requests come to smart objects as can be seen in Figure 5.1. A single service request delays at very short time of 50 ms; two or more requests take the smart object several seconds to response; 5 requests create 5 seconds delay and the figure soars to 35 seconds in case of 20 simultaneous requests.

Service Authorization

When making smart objects available for services on the Internet, beside assuring an interoperable deployment model (i.e., using IP protocols and Web APIs), security measures have to be taken into account that smart objects cannot be hijacked or hacked, making sure access to the smart object is still under controlled by the physical owners.

The challenge with service provisioning of smart objects for IoT applications on Web is that the owner of smart objects must give out the access to the applications meanwhile maintaining the secure control of smart objects. If a service provisioning server provides a smart object API to the public or just only to a set of registered third-party developers, it might be possible for developers to misuse the smart objects.

F i g u r e5 . 2 :S em a n t i cs e r v i c ep r o v i s i o n i n ga r c h i t e c t u r e . T h i sc h a p t e rp r e s e n t st h eS e r v i c eP r o v i s i o n i n gs u b s y s t emo ft h ep r o p o s e da r c h i t e ct u r e( s e eF i g u r e3 . 4 )t oa d d r e s sa f o r em e n t i o n e dp r o b l em s w h i l e m e e t i n gr e q u i r em e n t s o f s e r v i c ep r o v i s i o n i n g f o r6 L oW P AN ( o p e n s t a n d a r d s , i n t e r o p e r a b i l i t y , l o we n e r g yc o ns um p t i o n ,a n dr e l i a b i l i t y ) .I na d d i t i o n ,w ep r o p o s en ews c h em e so no t h e r i s s u e sr e l a t e d t op r o v i s i o n i n g i n c l u d i n gS em a n t i cA n n o t a t i o n ,UR I M a p p i n g ,a n dA P IR e p r e s e n t a t i o n . T h e f o l l o w i n g s e c t i o n e l a b o r a t e f u n c t i o n a lb l o c k sa n d r e l a t e da l g o r i t hm sa n dm e c h a n i sm

. 2 S e r v i c e P r o v i s i o n i n g F i g u r e. 2s h o w sn i n e f u n c t i o n a lb l o c k s i no u rp r o p o s e ds e r v i c ep r o v i s i o n i n gs y s t emt o h a n d l efi v e m a i n i s s u e s :s e r v i c ed i s c o v e r y ,s em a n t i ca n n o t a t i o n ,s im u l t a n e o u sr e q u e s t s , a u t h o r i z a t i o n ,a n d W e b A P Ig e n e r a t i o n .I n w h i c h , R e s o u r c e M a n a g em e n tp r o v i d e sa

u s e r i n t e r f a c e f o r r e s o u r c e s ( 6 L oW P ANa n d sm a r to b j e c t s ) m a n a g em e n t i np r o v i s i o n i n g n e t w o r ka sw e l la sg r a n t i n ga u t h o r i z a t i o n f o r I oTa p p l i c a t i o n so n W e bv i aA u t h o r i z a t i o n b l o c k .S c h e d u l i n gc o o p e r a t e sw i t hR e q u e s tH a n d l i n gt oc o o r d i n a t e m u l t i p l es im u l t a n eo u s r e q u e s t s t oe n s u r e t h eq u a l i t yo f s e r v i c e .

S e r v i c eD i s c o v e r yh a n d l e sn a t i v ed i s c o v e r y p r o t o c o l s i n6 L oW P ANa n d f e e d t h em t oS em a n t i cA n n o t a t i o na n d t o t h e W e bA P IG e ne r a t i o n ,w h i c h i n t u r nc a l lUR I M a p p i n gp r o c e s s t og e n e r a t eA P Ie n d p o i n t s . T r i p l e s t o r e p r o v i d e st h es em a n t i cs t o r a g e f o rp r o v i s i o n i n gs e r v i c e s .

. 2 . 1 S e r v i c e D i s c o v e r y T h i sf u n c t i o nb l o c kr e s i d e sa tt h el o w e s tl e v e lo fp r o v i s i o n i n gf u n c t i o n a l i t yo nl o c a l n e t w o r k s i d e t od i r e c t l y i n t e r a c tw i t hd e v i c e s .I t i s r e q u i r e d t od i s c o v e ra v a i l a b l e s e r v i c e s t oc a r r yo u t t h ep r o v i s i o n i n g . W e b s e r v i c e sa r eu s u a l l yd i s c o v e r e db yq u e r y i n g r e g i s t r i e s u s i n g i n t e r f a c e s s u c ha sU n i v e r s a lD e s c r i p t i o nD i s c o v e r ya n d I n t e g r a t i o n (UDD I ) . W h i l e

i tc a nb eac o n v e n i e n tw a yt od i s c o v e rs e r v i c e s , i t sc e n t r a l i z e dn a t u r ec a n l e a dt o m a n y issues such as fault tolerance, performance, and scalability. In DPWS, multicastingbased WS-Discovery does not require any central service registry. When an application tries to locate a device in a network, it sends a UDP multicast message (using the SOAP-over-UDP binding) carrying a SOAP envelope containing a WS-Discovery Probe message with the search criteria, e.g., the name of the device. All the devices in the network (local subnet) that match the search criteria will respond with a unicast WS-Discovery Probe Match message (also using the SOAP-over-UDP binding). To achieve resource discovery, CoAP servers provide a resource description available via a wellknown URI /.well-known/core (RFC 5785). This description is then accessed with a GET request on the URI. </ s t a t u s /temp> t i t l e ="Temperature " ; r t =" s t a t u s " Listing 5.1: CoRE Link Format. The Service Discovery provides the same interface to query services regardless of the protocol (e.g., CoAP, DPWS, or XMPP) used in the 6LoWPAN. It is in the form of plugin, when we need to incorporate new protocol we can add in to. This function also plays a role as handling several service discovery functionalities happening at multicasting support provisioning network and making some functionalities possible in global scenario such as dynamic service discovery with DPWS. The approach is to apply URI mapping and API representation directly on underlying discovery mechanism PROCESS RequestHandler BEGIN I n i t i a t e r e q u e st Q u e u e Keep t r a c k o f l a s t R e q e s t T i m e I f ( r e q u e s t Ti m e i s w i t h i n l a s t R e q u e s t T i m e bound ) Begin

Add new r e q u e s t t o r e q u e s t Q u e ue A c t i v a t e t h e S c h e d u l i n g p r o c e s s i f i t i s not a c t i v e

End END PROCESS S c h e d u l e r BEGIN Every quantumTime Begin I f r e q u e s t Q u e u e i s empty

Stop E l s e

Remove r e q u e s t from r e q ue s t Qu e ue

Add r e q u e s t t o sentQueue

Send r e q u e s t Notation3 (N3) format [START_REF] Berners-Lee | Notation3 (N3): A readable rdf syntax[END_REF], a textual syntax alternative to RDF, the size of data is still rather large (see Listing 5.5). The reason is that the semantic annotation for smart object involves a great deal of linking information such as namespace and RDF schema.

The size of the semantic data in more complex situation may increase and surpass the maximum buffer size that is provided for resource responses, which must be respected due to the limited IP buffer such as the maximum buffer size for CoAP blocks is typically 1024 bytes.

Literature approaches use third-party semantic services/servers to capture and republish these data. This can solve the problem of limited size for semantic annotation but results in many tradeoffs that prevent the adoption of this method. For example, third-party server means the communication stream is broken and can be interfered or the communication is slowed down and semantic server becomes a bottleneck in the communication between applications and smart objects. The ideal way is to have smart objects express semantically expressive based on IP protocols. Our approach is very close to this ideal method in which we unburden most of semantic annotation information from smart objects to the provisioning layer, keeping only core data for transmitting while provisioned services still can be fully annotated. We use following scheme:

1. Service providers provide a domain ontology for each set of smart objects. Ontology for each domain is developed independently by a reliable and consensus decision making process, e.g., Semantic Sensor Network Ontology1 .

2. Each service in smart object is represented in N3 format without default namespaces, ontolgy, and application URIs.

3. Ontology and application URI are added accordingly in service provisioning layer based on the information from the service provider for ontology and provisioning server for application URI.

The above temperature sensing data can then be provided by smart object by the format provided in Listing 5.6 while the actual semantic annotation data can be reached from applications are still the same as shown in Listing 5.5. The Internet media type passing to Web API calls is denoted as text/n3. These semantic data queried from smart objects are store in a Triplestore. A triplestore is the storage for semantic data, in this case, referring to the annotation of smart object data and functionalities. A triple is a data entity composed of [subject, predicate, object], there are three triples in the above data and one more triple about the time stamp is added as shown in following Listing 5.7.

[ Triplestore can be realized by serialization (i.e., using file system) or by third-party solutions such as OpenLink Virtuoso2 , 3Store3 , and Apache Jena4 . All the data in triplestore are associated with a domain ontology indicated by the service provider of the smart objects. The ontology is either available on the Web or newly developed by the service provider depending on the field of the applications. The applications have limited accesses to the smart objects according to the scope of the authorization granted (e.g. read only or update) whilst they still can communicate to the smart objects once having been authorized. We therefore adopt OAuth 2.0 as the core of authentication and authorization framework for our proposed provisioning architecture.

Authorization with OAuth 2.0

Authorization functional block in our proposed service provisioning architecture refers to an OAuth 2.0 authorization provider functionality, which authenticates the identity of the user, in this case locally within the provisioning network to strengthen the security. It issues access tokens to the interested applications following the confirmation from the user. Any IoT application that wants to access the smart object services must be authorized by the user, and the authorization must be validated by the appropriate Web API endpoints. There are three authorization endpoints in the our proposed service provisioning architecture for this process: Authorization URI (/authorize) is the URI on which users grant the authorization to the interested application; Token URI (/token) is the URI called by client applications when they want to exchange a code for an access token, or a refresh token for a new access token. API URI (/api) is the base URI on which provisioned Web API endpoints are mounted. These Web API endpoints enable a secure communication between IoT applications on Web and 6LoWPAN smart objects. This is done in the three-step mechanism illustrated in the Figure 5.3.

1.

Step 1: User or the owner of the smart objects gets access to the Resource Management and then goes to the Applications section and looks for the appropriate application to authorize. The user selects the application and click the authorize button to grant the application with Client ID and Redirect URI provided by the application. The Authorization then redirects to the Redirect URI with the authorization code in the URI fragment to transfer it to the application.

2.

Step 2: The application requests an access token from the API, by passing the authorization code along with authentication details, including the client secret, to the API token endpoint. If the authorization is valid, the API will send a response containing the access token (and optionally, a refresh token) to the application.

3.

Step 3: Now the application is authorized! It may use the token to carry out transactions with real services from provisioning server via the service API, limited to the scope of the access, until the token is expired or revoked.

URI Mapping

We propose two schemes for mapping service URIs to provisioning URIs, which are integral parts of the Web API endpoints. The first scheme is based on the resolved hostnames of smart objects in the network and the second scheme uses IP addresses of smart With DPWS, we propose a design constraint on the DPWS implementation for smart objects. It is based on the fact that most smart object services provide relatively simple operations compared to normal Web services with complex input/output data structure.

Our proposed constraint follows a simplified CRUD model ("create", "read", "update", "delete") to map between these services and HTTP methods: DPWS Operation Prefix -CRUD Action -HTTP Method. Specifically, four CRUD actions are applied to map DPWS operations to HTTP methods as in Table 5.5

. 3 I n -n e tw o r kIm p l em e n t a t i o n w i t h DP W S T h i ss e c t i o n i n t r o d u c e sa n i n -n e t w o r k im p l em e n t a t i o no ft h ep r o p o s e da r c h i t e c t u r e f o r D PW Sp r o t o c o l . T h e im p l em e n t a t i o n i s i nt h ef o rmo fa R E STp r o x yt oe x t e n dt h e D PW S s t a n d a r d t ob e t t e r i n t e g r a t e i t i n t o t h e I oTa p p l i c a t i o n so n W e bw h i l e m a i n t a i n -

i n g i t sa d v a n t a g e so fd y n am i cd i s c o v e r ya n de v e n t i n g m e c h a n i sm s .

Devices Profile for Web Services

DPWS is based on Web Service Description Language (WSDL) and SOAP to describe and communicate device services, but it does not require any central service registry such as Universal Description, Discovery and Integration (UDDI) for service discovery.

Instead, it relies on SOAP-over-UDP binding and UDP multicast to dynamically discover device services. DPWS offers a publish/subscribe eventing mechanism, WS-Eventing , for clients to subscribe for device events, e.g., a device switch is on/off or sensing when temperature reaches a predefined threshold. When an event occurs, notifications are delivered to subscribers via separate TCP connections. The following use case illustrates a common situation in several IoT applications when a new smart object joins the network.

Use case

Rosalie would like to make a module for controlling a newly-purchased DPWS heater.

The heater is equipped with a temperature sensor, a switch, memory, a processor, and networking media, and is implemented with a hosted Heater service. Heater service consists of eight operations: (1) check the heater status (GetStatus), ( 2) switch the heater on/off (SetStatus), (3) get room temperature (GetTemperature), ( 4) adjust the heater temperature (SetTemperature), ( 5) add (AddRule), ( 6) remove (RemoveRule), and ( 7) get (GetRules) available policy rules for defining automatic operation of the heater, and ( 8) over-heating event eventOverHeat(). She connects the heater to the network and tries to control it from her IoT application.

Global Dynamic Discovery

When an application tries to locate a smart object in a network, it sends a UDP multicast message (using the SOAP-over-UDP binding) carrying a SOAP envelope that contains a WS-Discovery Probe message with search criteria, e.g., the name of the smart object.

All the smart objects in the network (local subnet) that match the search criteria will respond with a unicast WS-Discovery Probe Match message (also using the SOAPover-UDP binding). In our use case, the heater sends Probe Match message containing network information. At this point, Rosalie realizes that it is impossible for her IoT application to dynamically discover the heater because of the network range limit to local subnet of multicast messages. If a proxy is applied, it allows the application to suppress multicast discovery messages and instead send a unicast request to the proxy.

Then, the proxy can representatively send Probe and receive Probe Match messages to and from the network while the behavior of smart objects remains unmodified; they still answer to Probe message arriving via multicast. In networks with many Probe messages, the proxy can significantly unburden the Internet traffic. The proxy provides two RESTful Web APIs to handle the discovery as shown in Table 5.7

We also propose a repository in the proxy to maintain the list of active smart objects.

The repository is updated when smart objects join and leave the network. In addition, the proxy performs a routine to periodically check the consistency of the repository, says every 30 minutes. For a proxy with 100 smart objects, the size of the repository is about the supported operations and the data structures used in the smart object service. Some DPWS implementations (such as WS4D JMEDS) provide a cache repository to store the WSDL document at runtime. After the application retrieves the WSDL file for the first time, the file can be cached for local usage in the subsequent occurrences within the life cycle of the DPWS framework (start/stop). This kind of caching mechanism would significantly reduce both the latency and the message overhead. Our DPWS proxy can provide WSDL caching not only at runtime but also permanently in a local database.

The cache is updated along with the routine to maintain the smart object repository in proxy described in the dynamic discovery section.

Figure 5.5 shows the network topology in two cases of our proposed design and the the original direct DPWS communication. Figure 5.5 shows the network topology in two cases of our proposed design and the the original direct DPWS communication.

Performance Evaluation

We carry out the experiments with 6LoWPAN set up on Cooja simulator [START_REF] Osterlind | Cross-level sensor network simulation with cooja[END_REF]. Experiment results from Chapter 4 allow us to set up 6LoWPAN network on network simulator with respect to real-life performance. This approach doesn't lose important properties of smart objects and especially effective to focus on the service integration issues. Cooja can accurately simulate all the constraints in smart objects and 6LoWPAN such as ROM/RAM size, microprocessor instruction set, and IEEE 802.15.4 radio environment. s e r v i c er e q u e s td e l a yr em a i n ss t a b l ye q u a l i nb o t hc a s e s , m e a n i n gt h a to u ra l g o r i t hm d o e s n ' ta ff e c tn o n -s im u l t a n e o u s r e q u e s t sw h i l e im p r o v i n g t h ep e r f o rm a n c ew h e nm u l t i p l e s im u l t a n e o u sr e q u e s t sc om et oas e r v i c e .

6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 4 t t l= 6 2 t im e= 3 5 2 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 5 t t l= 6 2 t im e= 3 5 5 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 6 t t l= 6 2 t im e= 3 6 9 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 7 t t l= 6 2 t im e= 3 4 7 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 8 t t l= 6 2 t im e= 3 3 4 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 2 9 t t l= 6 2 t im e= 3 3 6 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 3 0 t t l= 6 2 t im e= 3 5 3 m s 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 3 1 t t l= 6 2 t im e= 3 7 2 m s 1 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 3 2 t t l= 6 2 t im e= 3 4 3 m s 1 6 4 b y t e s f r om a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 : i cm p s e q= 3 3 t t l= 6 2 t im e= 3 5 4 m s 1 ˆC 1 ---a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 p i n g s ta t i s t i c s ---1 3 3 p a c k e t s t r a n sm i t t e d , 2 6 r e c e i v ed, 2 1% p a c k e t l o s s, t im e 3 2 0 6 0m s 1 r t t m i n / a v g /m a x /m d e v = 3 0 8 . 0 0 8 / 3 5 0 . 7 2 7 / 4 1 1 . 3 8 9 / 2 1 . 0 4 2 m s 1 u s e r@ i n s t a n t-c on t i k i :

Scheduling: Simultaneous Requests Handling

We carry out an experiment to test the situation when multiple requests come to the same smart object service. To recap, two requests are considered simultaneous if they happen within a small interval of time, for example as we observe with CM5000 motes, the value is about 100 ms. As seen from Figure 5.8, the scheduling algorithm significantly improves the delay of service request in all cases with the number of requests ascending from 1 to 20. Especially when more simultaneous requests sent to the same service, scheduling can be considered to virtually eliminate the bottleneck in the network. Delay with scheduling algorithm also shows the stability with respect to the capacity of smart objects, that would not adversely affect user experience on application side.

Scheduling: Energy Consumption

We observe the duty cycle and energy consumption of the smart object hosting the requested service over the period of 100 seconds when the smart object handling 20 simultaneous requests in the previous experiment. Figure 5.9 shows the duty cycling pattern in two cases. As we notice, by applying scheduling, the smart sensor keeps radio on during a shorter time about 20 seconds compare to 45 seconds when there is no scheduling. Although, radio duty cycle peaks at nearly 6 percent in case of using scheduling but overall energy consumption of the smart object with support of scheduling is slightly lower than without scheduling (see Figure 5.10).

Semantic Annotation

Our approach in annotating semantics to smart object service is to break down the RDF data into two parts, the core data are stored in smart object service and the additional linking data are added in service provisioning phrase. The annotation in smart object is represented in N3 format, delivered in media type request of text/n3. With the richness of semantic annotation for smart service data, our proposed mechanism significantly reduces the size of the messages compared to straightforward annotation and eliminate of using a third-party service for re-describing the services. We consider a typical data representation from a smart object service with the annotated information of type, source, and value. Figure 5.11 shows the data sizes in difference cases: no semantic annotation, annotation in RDF format, annotation in N3 format, and the proposed method. Our proposed method ensures that the semantic annotation remains at reasonable bytes that can fit in constrained IP stacks such as uIP and CoAP.

REST Proxy Message Overhead and Latency

We set up an experiment to evaluate latency and overhead in two different scenarios: the first one uses our proposed proxy (Figure 5.5a), and the second one uses the direct DPWS communication (Figure 5.5b). In both cases, an IoT application communicates with a DPWS smart object (a heater) to invoke its hosted service (heater functionalities). To replicate a realistic deployment of the IoT application, we deployed it on a server running Tomcat5 that used a public Internet connection and was located about 30 km away from the smart objects. We implemented the heater with a hosted service SmartHeater providing eight operations, as in Table 5.9. We implemented a REST proxy in Java using the Jersey library on Tomcat6 to generate heater Web API. The IoT application either uses the API provided by the REST proxy or directly communicates with the heater (using the WS4D JMEDS library) to carry out the DPWS heater's four functionalities:

checking heater status, setting heater status, adding a new rule, and deleting a rule.

GET / proxy / h e a t e r HTTP/ 1 . 1 User-Agent : Java / 1 . 7 . 0 Host : 1 5 7 . Listing 5.9: Request and response messages for obtaining the status of the heater using the proxy Web API expose relatively simple in HTTP format.

Figure 5.12 shows the message sizes of the request and response messages and the mean round-trip time (RTT) in the communication between the application and the SmartHeater. We use two methods: the RESTful Web API from the proxy and the original DPWS operations. The latency when using proxy is 25 percent lower than when using DPWS. In many pervasive IoT scenarios requiring high responsiveness, reasonable delay would improve system performance and the user experience. Message overhead improves significantly when we apply the proxy. For real deployments of applications and smart objects in original DPWS communication, nearly full-mesh connectivity (Figure 5.5b) is unavoidable compared to the linear increments of HTTP traffic in the proxy scenario (Figure 5.5a). Listings 5.9 and 5.10 show the details of request and response messages for an operation using the proxy and DPWS. Listing 5.10: Request and response messages for obtaining the status of the heater using DPWS expose the complex XML-based messages in SOAP format.

Summary

This chapter has presented the functional blocks along with several algorithms and mechanisms for realizing the proposed service provisioning architecture for IoT applications on Web. The main goal is to solve several problems associated with provisioning smart object services to the Web such as service discovery, multiple simultaneous requests, and service authorization in order to generate a friendly interface for developers to effectively and smoothly integrate smart objects into IoT applications on Web.

Chapter 6

Case Studies: IoT Applications on Web This chapter presents the Service Integration process in our proposed architecture with two case studies of developing IoT applications using service provisioning and open Web standards. These are innovative IoT applications in the domains of Social Internet of Things (SIoT) and Building Automation System (BAS). The first application is ThingsChat, a SIoT platform facilitating the social relationship between human and smart objects in the similar way with between human and human in traditional social networks. To do that, we extend our proposed semantic service provisioning by adding a Device Socializing module, creating a Socialized Web API to automate the communication between human and devices over the Social IoT platform. The second application, SamBAS, focuses on exploiting the potential of semantic data model for developing a novel building automation system with the adoption of IoT technologies for the device communication. Both the applications use DPWSim [START_REF] Han | Dpwsim: A devices profile for web services (dpws) simulator[END_REF] (see Appendix A), a DPWS simulator developed within this research, to simulate home and office environments hosting several smart objects using IoT protocol stack. We call smart objects as devices in these contexts to align with end-user's point of view since a device or appliance is more popular than a smart object. stacks and toolkits for DPWS. In addition, many studies have been recently carried out to complete the technology. Experiment results show that DPWS is able to be implemented into (even) highly resource-constrained devices such as sensor nodes with reasonable ROM footprints [START_REF] Lerche | Implementing powerful web services for highly resource-constrained devices[END_REF]. Other technical issues of DPWS have also been explored such as encoding and compression [START_REF] Moritz | Encoding and compression for the devices profile for web services[END_REF], the integration with IPv6 infrastructure and 6LoWPAN [START_REF] Moritz | Beyond 6lowpan: Web services in wireless sensor networks[END_REF][START_REF] Samaras | A modified DPWS protocol stack for 6lowpan-based wireless sensor networks[END_REF], the scalability of service deployment [START_REF] Yang | Dynamic deployment of embedded services for DPWS-enabled devices[END_REF], and the security in the latest release of WS4D DPWS stacks.

Devices Profile for Web Services

DPWS thus far has been widely used in automation industry, home entertainment, and automotive systems [START_REF] Cucinotta | A real-time service-oriented architecture for industrial automation[END_REF] and also applicable for enterprise integrations [START_REF] Spiess | SOA-based integration of the internet of things in enterprise services[END_REF]. It satisfies many requirements for IoT applications such as resource-constrained, eventdriven, and dynamic discovery; In the meantime, it can maintain the integration with the Internet and enterprises infrastructures. In addition, the strong support from the community is another reason to make it a promising technology for the future IoT. WS4D has been developing several DPWS standard implementations in different languages and platforms as summarized in the Table 6

ThingsChat: A Social Internet of Things Platform

Online Social Network (OSN) has emerged as an inter-connectivity forum encouraging people to establish and expand their network of friends/acquaintances for social interacting and sharing ideas as well as various resources in textual and other multimedia formats. The OSNs aggregates users' interests, preferences, groups of friends, and activities to form rich user profiles. The concept of content mashup has emerged to encourage and support users' customization of their own OSN by adding services to expand the functionalities already provided or adding feeds from other OSN. These values of OSN has been changing social interaction over the Internet, from enhancing the way we reach information to enhancing the way we reach for each other. In the meantime, the IoT is gradually penetrating into our daily life with dozens of appealing products are filling up the shelves. These devices, thanks to the efforts from research activities, can now be facilitated with inexpensive sensors, low-power wireless communication protocols to sense and transmit the status of physical world to Internet. A new generation of applications on this connected ecosystem is being developed excitingly, not only to interact with single device or service but also to use the concept of mashup and composition with other Web services to create new experiences. However, the best story has yet to come when the idea keeps flying higher and further by offering these smart and connected devices a new attribute of being social to benefit OSNs over Internet-connected and socialized devices. This new paradigm is called Social Internet of Things (SIoT). Industry and academia since then have been following up this trend and come up with some models and prototypes of SIoT [START_REF] Atzori | The social internet of things (SIoT) -when social networks meet the internet of things: Concept, architecture and network characterization[END_REF] but mainly in the conceptual level and preliminary data models for the device-to-device social relationship.

Our vision is to further enhance the social interaction by bringing connected devices to a new level of being able to have social relationship with other devices and with people.

To achieve that objective, we extend our proposed service provisioning architecture to facilitate the devices with social ability in the form of Web APIs that can be used by OSNs to interact with devices. Furthermore, we add to the core OSN functionalities new capabilities of profiles, intelligence, recommendation, and Natural Language Processing (NLP) to inherit all the features of OSN and IoT. This design results in a universal OSN of everything, people and devices, called ThingsChat.

System Architecture

ThingsChat system architecture aims to minimize the discrepancy between device and human profiles in the social network structure. In other words, ThingsChat treats devices alike human in a way that devices can make decision and communicate with human users. The architecture covers a network of people and devices with a Service

Provisioning subsystem magnified by a Device Socialization module to connect devices to the social networking platform in a similar way that human users connect to it.

There are two main subsystems communicating via the Socialized Web API: Service

Provisioning and Social Network. The former extends our proposed service provisioning architecture not only to bring device services to the Web but also socialize these services by adding abilities (API) such as talking and making friend to human users. The latter is based on the social networking core (e.g., Elgg3 , phpBB Social Network4 , and Oxwall to provide a tokenization function for natural language text. All the machines/servers DPWSim, ThingsGate, ThingsChat, and NLP Service are deployed in the same local network for testing purpose.

To illustrate the application, we explain two use cases of Coffee Maker in office and Robot Cleaner at home (see Figure 6.4). Nadia is living in an apartment (Virtual Home)

with several DPWS appliances such as a TV, lamps, coffee makers, and heater. She can easily install these devices in the home network from her mobile phone by using the Resource Management module. ThingsGate allows Nadia to detect available devices and then socialize them by simple touches on the WUI. She can do the same procedure in her office to install new devices, probably with the help of a network administrator.

When she finishes setting up things, she can talk with her devices anywhere through ThingsChat in a natural way. In the morning, when Nadia is on the way to office, Coffee Maker based on her profile offers a coffee at 09:00, but Nadia has an early meeting at that time so she asks the Coffee Maker to make it few minutes earlier at the same time she is talking with her friend on ThingsChat. Coffee Maker receives her request and update to status that her favorite coffee has set to be ready at 08:55, it also knows how to reply when Nadia say thanks. In another use case, it has been three days that W ea im t oe v a l u a t e t h ep e r f o rm a n c eo f t h eS o c i a l i z e d W e bA P I i np r o v i s i o n i n g s e r v e r (T h i n g sG a t e )a n dD e v i c eA p d a p t e r W e bA P I i nS I oT s e r v e r (T h i n g sC h a t ) . T h ee x p e r im e n t e x h i b i t sa t y p i c a l i n t e r a c t i o nfl o wb e t w e e nu s e r sa n dd e v i c e s :u s e ra s k sd e v i c e t od o s om e j o b s ,d e v i c ec a r r i e so u t t h e r e q u e s t e d j o b sa n d r e p l i e sb a c k t ou s e r . T h i sc o n v e r s a -tion involves two API endpoints, one from ThingsGate (POST [thingsgate]/social/chatto-device) 8 and the other from ThingsChat (POST [thingschat]/socialnet/chat-to-user.php) 9 . There are also other modules used in the conversation such as natural language processing, machine tokens conversion, semantic data processing, and recommendation, however we focus on evaluating APIs and these modules in minimal workload. We break down the job on ThingsGate into two parts: Service Execution for invoking the requested device service and API Processing for server to process the API request. second for processing and transmitting data back and forth between ThingsGate and ThingsChat. It is because that ThingsChat API mainly deals with querying the database system for handling user and device profiles.

SamBAS: A Building Automation System

The idea of smart house or smart building has been around for many years receiving much expectation. A building automation system, residing at the heart of such smart environments, interacts with its components including hardware, software, and the communication among them. It involves in several disciplines such as electronics, informatics, automation, or control engineering. BAS, since its debut, has been developed and promoted by a community of developers, technologists, and scientists with plenty of impressive prototypes and products. These products bring in comforts and conveniences to daily life, freeing people from tedious house-works or office-works. Use cases vary from very simple ones, e.g., automatically turn on/off the lights to complex and critical situations, e.g., security surveillance. Furthermore, BAS also provides value-added services by offering intelligent services such as customer tracking in shopping malls or elderly people healthcare services. All of those make it a very promising business attracting attention of the community to target not only organization customers but also individual end-users. Industry and academia have been developing many new technologies for building automation such as communication protocols, data management, data bus systems, software components, and/or new hardware devices which can be integrated in the new systems. Thanks to all those efforts, building automation has advanced over the last decades with several communication protocols and a variety of BAS products from many 8 [thingsgate]: ThingsGate server address 9 [thingschat]: ThingsChat server address different vendors. A comprehensive overview of communication protocols in building automation can be found in [START_REF] Dietrich | Communication and computation in buildings: A short introduction and overview[END_REF] with different BAS products. Traditionally, equipments in BASs are interconnected by proprietary communication protocols such as LonWorks [START_REF]Open Data Communication in Building Automation, Controls and Building Management -Control Network Protocol[END_REF], Building Automation and Control Network (BACnet) [START_REF]Building automation and control systems -Part 5: Data communication protocol[END_REF], or KNX [START_REF]Information technology -Home electronic system (HES) architecture -Part 4-1: Communication layers -Application layer for network enhanced control devices of HES Class 1. International Organization for Standardization[END_REF]. These protocols have been used to cover all the features of building automation, including Heating, Ventilating and Air Conditioning (HVAC), lighting, and alarming. There are also many other standards for BAS. HomeConnex (Peracom Networks), for example, is a home entertainment network which unites PCs, TVs, audio/video components and set-top devices into an integrated system. X-10 (X10 Inc.) is another industry standard using power line and radio for communication among electronic devices used for home automation. Other proprietary standards include Easy-Radio (Low Power Radio Solution Inc.), No New Wires (Intellon Corp.), Sharewave (Sharewave Inc.), SoapBox (VTT Electronics), and Z-wave (Zensys).

Even though, the BAS market is very active with plenty of appealing BAS solutions but consumers are well aware of the value of such smart systems. However, it is not difficult to recognize the reluctance among customers in adopting available BAS products on the market. The main reasons are identified as the cost and the scalability of these proprietary systems. This normally leads to the suspension or partially deployment of several on-the-table building renovation projects. the first one is to enable the system to quickly adapt to the dynamic changes in user and environment context; the second one is to coordinate devices in order to serve the diverse and complex user's needs involving not only one but several services at the same time.

To solve these problems, first, we semantically model the user and environment context using RDF and from DPWS communication. Then, we apply service composition over semantic data from device services and predefined semantic policy rules to select, bind, and execute appropriate services. The proposed solution, SamBAS is to use composite service plans to describe users' requirements using the proposed Composition Plan Description Language (CPDL). We design a Building Ontology containing the description of concepts and relationships in building environment for the reference schema of storing graph data in the triplestore database. Context information is modeled, processed and passed to service composition engine to coordinate appropriate devices/services based on predefined policy rules and five-step composition process. F i g u r e6 . 6 :S y s t emc o n fi g u r a t i o n .

. 3 . 1 S y s t em A r c h i t e c t u r e

S y s t em c o n fi g u r a t i o n s h o w n i nF i g u r e6 . 6d e p i c t sa t y p i c a l s e t u po fd e v i c e s i n s i d ea r o om o fab u i l d i n g . T h e r ea r e D PW Sd e v i c e sc o n s i s t i n go fa w i d er a n g eo fb u i l d i n ge q u i pm e n t( e . g . , TV ,p r i n t e r ,a n dl i g h tb u l b s )a n dc o n t e x tc o l l e c t o r s( e . c omm u n i t ya s i tc r e a t e so n eo f t h eb a s i cb u i l d i n gb l o c k s f o r f o rm i n g t h e W e bo f s em a n t i c d a t a . Ag r a p hc o n s i s t so fr e s o u r c e sr e l a t e dt oo t h e rr e s o u r c e s , w i t hn os i n g l er e s o u r c e h a v i n ga n yp a r t i c u l a r i n t r i n s i c im p o r t a n c eo v e ra n o t h e r . RD Fd a t a b a s e i n c l u d e so fRD F s t a t em e n t s ,o rs om e t im e sc a l l e da nRD F t r i p l e s . T h e t e rm t r i p l e i su s e d t od e s c r i b e t h e c om p o n e n t so fas t a t em e n tw i t ht h r e ec o n s t i t u e n tp a r t s :s u b j e c t ,p r e d i c a t e ,a n do b j e c t o ft h es t a t em e n t .

T h ep r im a r yp u r p o s eo ft h i so n t o l o g y i st oc l a s s i f yt h i n g s i nt e rm so fs em a n t i c s ,o r m e a n i n ga n de s p e c i a l l y f o rd e s c r i b i n gp o l i c i e su s e d i nc om p o s i t i o np r o c e s s . Ac l a s s i n OW L [ 4 4 ] i sac l a s s i fi c a t i o no f i n d i v i d u a l s i n t og r o u p sw h i c hs h a r ec omm o nc h a r a c t e ri s t i c s .I fa n i n d i v i d u a l i sa m em b e ro fac l a s s , i tt e l l sa m a c h i n et h a t i t f a l l su n d e rt h e s em a n t i cc l a s s i fi c a t i o ng i v e nb yt h e OW Lc l a s s . T h i sp r o v i d e st h e m e a n i n go ft h ed a t a t h a th e l p s r e a s o n i n ge n g i n e t od r a w i n f e r r e d i n f o rm a t i o n f r om t h ed a t a b a s e .L i s t i n g6 . 2 s h o w sap a r to fB u i l d i n gO n t o l o g yd o c um e n t i nOW Lb yP r o t é g é -OW Le d i t o r 1 0 .I tc o ns i s t so fd o c um e n th e a d e ra n dt h ed e c l a r a t i o no ft h ec l a s sP o l i c y w i t ht w op r o p e r t i e so f a p p l y F o ra n dh a sC o n d i t i o n . T h e s ep r o p e r t i e sa l s or e fl e x t h er e l a t i o n s h i po fc l a s s P o l i c y all the properties of User.

Context-Awareness

Context-awareness plays an important role in the pervasive computing architectures to enable the automatic modification of the system behavior according to the current situation with minimal human intervention. Since appeared in [START_REF] Schilit | Context-aware computing applications[END_REF], context has become a powerful and longstanding concept in human-machine interaction. As human beings, we can more efficiently interact with each other by fully understanding the context in which the interactions take place. It is difficult to enable a machine to understand and use the context of human beings. Therefore the concept of context-awareness becomes critical and is generally defined by those working in ubiquitous/pervasive computing, where it is a key to the effort of bringing computation into daily lives. One major task in context-aware computing is to acquire and utilize information about the context of participating entities of a system in order to provide the most adequate services. The service should be appropriate to the particular person, place, time, event, etc. where it is required. In the scope of this building automation, user, device, and environment context are considered in order to bring more efficient service composition. These context data are sent to the system by using DPWS events implemented in context collectors and devices.

Implementation Remarks

The success of these applications shows that the proposed architecture is highly flexible and applicable in different application scenarios proving again that end-to-end IP architecture is an ideal choice for IoT. According to the developers of these applications, the software development experience is very positive and the integration of smart object services into traditional Web applications is easy and transparent. For example, ThingsChat is based on an existing online social network (phpBB Social Network) using PHP programming language, which is one of the most common server-side languages for Web applications. In order to build a new social network (SIoT), developers are required to master PHP language. In the meantime, they are not expected to have knowledge on IoT protocol stack. However, software developers encounter no problem with working on these interface even without any knowledge on the underlying IoT protocols and the architecture only provides the interface (Web API) using open standards.

Chapter 7

Conclusion and Future Work

Future Work

The proposed architecture with its profound impact on both academia and industry is a starting point for several future directions for IoT research. In this section, we look at some of the future work directly extending the results from this dissertation.

Service Composition

The question in IoT is not only how to make smart objects be able to communicate over the Internet through provisioning, but also how smart objects services can be used in multiple application in serendipitous ways to create new and creative applications. To answer this, we can be use service composition, one of the core principles of the Service-Oriented Architecture. Advanced functionalities can then be created by combining a set of atomic services in the form of composite services. These composite services can be used in different scenarios to meet various user requirements. The true value of the IoT and new opportunities to create a smarter world will become apparent when data and events from an increasing number of smart objects can be easily and dynamically composed to create novel applications. Service composition has been extensively studied in the context of Web services and business processes [START_REF] Dustdar | A survey on web services composition[END_REF]. A number of standards have been developed and are being used in real-world deployments to support the service composition. However, the characteristics of IoT systems, such as resource-constraints and data/event-driven devices render some of the techniques devised for traditional Web service composition inadequate. Therefore, new composition models with respect to new requirements of IoT systems are expected. We continue with the the future full-IP IoT to apply the service composition to further expand the proposed service provisioning architecture to give more innovation on the IoT domain.

Operations

Each device contains a list of operations carrying out device functionalities such as switching on and off based on commands received from clients. These operations are described in WSDL descriptions and can be retrieved via service endpoint addresses.

Each output of an operation is represented by a graphical status, for example, the light bulb in Figure A.1 will be changed to off status when the corresponding operation is successfully invoked by a client.

Events

An event, similar to an operation, is used for a device functionality related to changes in

New Space/Stand-alone Device

There are two options for creating a virtual environment: stand-alone device and space.

These functions can be accessed through File menu or keyboard shortcuts. A space is a i t ssm a r t p h o n ei n t e r f a c et oi n v o k ea no p e r a t i o no fal i g h tb u l bd e v i c eK i t c h e n L i g h t.

U s e r sc a nsw i t c ht h el i g h tb u l bo no ro fff r omt h e W e bi n t e r f a c eb yc l i c k i n go nt

Contents 1 . 1 1 1. 2 4 1. 3

 111243 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

  that a key indicator for sustainable application development is the reusability of components and data provisioning. The provisioning of sensor readings as CoAP Web services is a straightforward way to integrate the sensors (the physical things) into the Internet and thus makes them part of the IoT. He proposed to divide the data model into three separate parts with Data Provider stay in between Data Origin and Data Consumer. The central component of the Data Provider is the Smart Service Proxy (SSP) which acts as the intermediate device between the client (Data Consumer)

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Open Standards and Interoperability . . . . . . . . . . . . . . . . . . . 19 3.1.2 Low Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.4 Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 IoT Application on Web . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 Reference Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.3 Multilayer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.4 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.4.1 Service Communication . . . . . . . . . . . . . . . . . . . . . 27 3.3.4.2 Service Provisioning . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.4.3 Service Integration . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.5 Provisioning Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

  applications and users. We coin the term IoT Application on Web to refer to any Web application interacting with smart objects through communication networks using open Web standards. They are IoT applications and they are Web applications identified by: • Reside on the Web (on Web server/cloud) • Use open Web standards • Interact with smart objects • Be accessed via Web agents.

  a r to b j e c t sa r e i t em s e q u i p p e d w i t hs e n s o r so ra c t u a t o r s ,t i n y m i c r o p r o c e s s o r s , m em o r y , l o w -p o w e rc omm u n i c a t i o nd ev i c e s ,a n dp o w e rs o u r c e s .Sm a r to b j e c t se x i s t i ns e v e r a lr e a l -l i f e f a c i l i t i e ss u c ha sb u i l di n g s ,h o u s e s ,a n dp u b l i cs p a c e s . M o s to ft h ema r ec o n s t r a i n e dd e v i c e s w i t he v e nf ew h u n d r e dk i l o b y t e m em o r ya n d i sb a t t e r y -p o w e r e d . T h e yr u n l o w -p o w e ro p e r a t i n gs y st em im p l em e n t e dw i t hI P -b a s e dp r o t o c o l sa n ds t a c k s . T h e s esm a r to b j e c t sc o n fi g u r ea 6 L oW P ANb a s e do n l o w -p o w e rp h y s i c a l l a y e rp r o t o c o l ss u c ha sI E E E8 0 2 . 1 5 . 4 , B L E , a n d D ECT U l t r aL o wE n e r g y . T h e6 L oW P ANc o n n e c t st or e g u l a rI Pn e t w o r k sv i aa 6 L oW P ANE d g e R o u t e r( 6

  nt h e W e bs e r v e r so rc l o u da n dc a nb ea c c e s s e dv i au s e rd e v i c e s s u c ha s l a p t o pc om p u t e r s ,sm a r tp h o n e s ,a n dt a b l e t s . T h i sr e f e r e n c ea r c h i t e c t u r ec a nb er e a l i z e d i nh om en e t w o r k s . F o re x am p l e ,ah om e h o s t s s e v e r a l sm a r to b j e c t s i n c l u d i n gaw i r e l e s sc am e r a ,aw i r e l e s sL ED sm a r tb u l b ,a n d a na l a rm . T h e s eo b j e c t s j o i nt h eh om en e t w o r kv i aE t h e r n e tc o a x i a lc a b l e s( a l a rm )o r w i r e l e s s l yb yB l u e t o o t hL o wE n e r g y( c am e r a ,sm a r tb u l b ) . T h en e t w o r kc o n n e c t i n gt o a6 E dRa c t sa sa na c c e s sp o i n t f o rh om e I n t e r n e tc o n n e c t i o n ,a n da l s oc o n n e c t s t oo t h e r d e v i c e su s i n g f u l lI Pc a p a c i t ys u c ha s l a p t o pa n d TV . Asm a r tp h o n ea p p l i c a t i o nc a n F i g u r e3 . 2 : D a t a m o d e l i nt h eh i e r a r c h i c a ls c h em e .

3 . 3

 3 . 2 D a t a M o d e l E v e r ysm a r to b j e c ti nt h e6 L oW P ANi sp r o v i s i o n e d w i t hd a t ai n w h i c hi n f o rm a t i o n a b o u tl o wl e v e lr e s o u r c e s( s e n s o r s ,a c t u a t o r s , m em o r y ,e n e r g y ,e t c . ) a n dh i g hl e v e l r e s o u r c e s( s em a n t i cs e r v i c e sa n dc o n t e x t u a ls e r v i c e s )a r es t o r e d i nd i ff e r e n t l o c a t i o n s .

  o t h e s es e r v i c e s .I tr e l i e so no p e na n ds t a n d a r d i z e dp r o t o c o l s m a i n l yf r omI ET F w o r ki n gg r o u p s . S e r v i c ep r o v i s i o n i n g m e t h o df o rs e c u r e ,s c a l a b l e ,a n dr e l i a b l es e r v i c e so f 6 L oW P AN i n c l u d e s :s e r v i c ed i s c o v e r y ,s c h e d u l i n g ,UR I m a p p i n g ,r e q u e s th a n d l i n g ,a ut h e n t i c a t i o n ,a n d W e bA P I r e p r e s e n t a t i o n . Am e t h o d f o ru s i n gp r o v i s i o n e d s e r v i c e s f r om

  P s t a c k ss u c ha sC o n t i k i O S 2 ,T i n yO S 3 ,a n dR IOT O S 4 .C omm o nI oTp r o t o c o l s ,e . g . , 6 L oW P AN A d a p t a t i o n ,I P v 6 , R P L , TC P ,a n d UD Pc a nb eu s e dt op r o v i d et h en e tw o r k i n g f u n c t i o n a l i t yo fsm a r to b j e c t s . O nt o po ft h a t ,s e r v i c e sa r e im p l em e n t e du s i n g a na p p l i c a t i o nl a y e rp r o t o c o ls u c ha s C oA P , D PW S ,a n d XM P P . T h e s es e r v i c e sc a n 2 h t t p : / /www . c o n t i k i -o s . o r g / 3 h t t p : / /www . t i n y o s . n e t /

F

  i g u r e3 . 5 : P r o v i s i o n i n gw o r k fl o w . W e b A P I ss u c ha s G o o g l e A P I ,Tw i t t e r A P I ,a n d Y a h o o A P I .S em a n t i cd a t ar e c e i v e d f r omsm a r to b j e c ts e r v i c e sc a nb ea s s o c i a t e d w i t ht h ed om a i no n t o l o g yt oc a r r yo u t i n f e r e n c eo r i n t e l l i g e n c e f o r t h ea p p l i c a t i o n . A l lo f t h e s e f u n c t i o n a lb l o c k sc a nb eu s e d i n s t a n d a r dp r o g r amm i n g l a n g u a g ea n dt o o l sp r o v i d e db ys e v e r a ld e v e l o pm e n tp l a t f o rm s .

F

  i g u r e3 . 5 i l l u s t r a t e sa no v e r a l lw o r k fl o wo fp r o v i s i o n i n g sm a r to b j e c t s e r v i c e s i n c l u d i n g t h r e e s u b s y s t emo f t h ea r c h i t e c t u r e . A t t h efi r s t s t e p ,s e r v i c ep r o v i d e r s s u c ha sb u i l d i n g o w n e r sa n d t h i r d -p a r t y s e r v i c ec om p a n i e sp r o v i d e sm a r to b j e c t sw i t hp r e -m a n u f a c t u r e d o p e r a t i n gs y s t em ss u p p o r t i n gI Ps t a c k sf o rd e v e l o p e r so rt h i r d -p a r t yI oTt e c h n o l o g y fi rm st o im p l em e n tI Ps t a c k s . N e x t ,s e r v i c ep r o v i d e r sd e s c r i b ea n d im p l em e n tsm a r t o b j e

Contents 4 .

 4 1 6LoWPAN Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Internetworking Architecture . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 6LoWPAN Edge Router . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 6LoWPAN Implementation . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Duty Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3.1 Radio Signal Strength . . . . . . . . . . . . . . . . . . . . . . 4.3.3.2 Packet Delivery Ratio . . . . . . . . . . . . . . . . . . . . . . 4.3.3.3 End-to-End Delay . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3.4 Data Transfer Rate . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Service Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Discussion and Lessons Learned . . . . . . . . . . . . . . . . . . . . . 4.4.1 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Contiki OS 3.x and Network Performance . . . . . . . . . . . . . . . . 4.4.3 Current IPv4 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F

  i g u r e4 . 1 : I Pa n d6 L oW P ANp r o t o c o ls t a c ki nr e f e r e n c et ol a y e r so ft h e TC P / I P n e t w o r k i n g m o d e l .S i n c e I P v 6 -e n a b l e d l o w -p o w e rw i r e l e s sp e r s o n a la r e an e t w o r k so f sm a r to b j e c t s ( 6 L oW -P AN s )p l a ya n im p o r t a n tp a r t i nt h eI oT ,e s p e c i a l l yo na c c o u n to ft h eI n t e r n e t i n t eg r a t i o n( I P v 6 ) ,e n e r g yc o n s um p t i o n( l o w -p o w e r ) ,a n du b i q u i t o u sa v a i l a b i l i t y(w i r e l e s s ) ,t h i sc h a p t e rp r e s e n t st h ed e s i g na n das t u d yo n6 L oW P AN sp r o v i d i n gt h en e t w o r ki n gf o u n d a t i o nf o rt h ep r o p o s e dp r o v i s i o n i n ga r c h i t e c t u r e . T h ed e s i g nr e a l i z e sSm a r t O b j e c tl a y e ri nt h e m u l t i l a y e ra r c h i t e c t u r ea n dS e r v i c e C omm u n i c a t i o ns u b s y s t emi nt h eb l o c kd i a g r amp r e s e n t e di n C h a p t e r3 . T h ep e r f o rm a n c es t u d yc o n t a i n sac omp r e h e n s i v ea n a l y s i so ns e v e r a l i n t e r n e t w o r k i n gc h a r a c t e r i s t i c sb e t w e e n6 L oW P AN sa n d r e g u l a rI P v 6n e t w o r k s i n c l u d i n ge n e r g yc o n s um p t i o no nn o d e s ,n e t w o r kp e r f o rm a n c e , a n ds e r v i c ec omm u n i c a t i o n .

F

  i g u r e4 . 1s h o w sac om p a r i s o nb e t w e e nt y p i c a ln e t w o r k i n gs t a c k so fr e g u l a r I Pn e tw o r k sa n d6 L oW P ANf o l l o w i n g4 -l a y e r TC P / I P m o d e l(R F C1 1 2 2 ) : L i n k ,I n t e r n e t , T r a n s p o r t ,a n d A p p l i c a t i o n s . T h ek e yd i ff e r e n c el i e sa t6 L oW P ANa d a p t a t i o nl a y e r , w h i c ha d d sas p e c i fi c l a y e ra n dI P v 6h e a d e rc om p r e s s i o nb e f o r e f o rw a r d i n gt or e g u l a r I P v 6d e s t i n a t i o n . T h i st e c h n o l o g yg i v e st h eeffi c i e n te x t e n s i o no fI P v 6 i n t ot h e6 L oW -P ANd om a i n ,t h u se n a b l i n ge n d -t o -e n dI Pn e t w o r k i n g f e a t u r e s f o raw i d er a n g eo fI oT a p p l i c a t i o n s .

  d i s c o v e r i e s .I nt h i sc h a p t e r , w ep r e s e n to u rd e s i g n , im p l em e n t a t i o n ,a n dp e r f o rm a n c e e v a l u a t i o no f6 L oW P ANb a s e do no p e nI oTs t a n d a r d sp r o v i d e db yI ET Fi n C oR E , RO L L ,a n d6 L oW P AN w o r k i n gg r o u p s . W eim p l em e n tt h ed e s i g no nas e t MTM -CM 5 0 0 0 -M S P T e l o sB m o t e s(CM 5 0 0 0 ) 1 f o rsm a r to b j e c t sa n da R a s p b e r r yP i(R P i ) 2 f o ra ne d g er o u t e r ,s om el a p t o pc om p u t e r sf o rh o s t si nr e g u l a rI P v 6n e t w o r k . A l l 1 h t t p : / /www . a d v a n t i c s y s . c om / s h o p /m tm cm 5 0 0 0m s p -p -1 4 . h tm l 2 h t t p s : / /www . r a s p b e r r y p i . o r g / F i g u r e4 . 2 :6 L oW P AN I n t e r n e t w o r k i n gA r c h i t e c t u r e . a r ec o n n e c t e dt ot h eb a c k b o n en e t w o r ko ft h eb u i l d i n g . T h ep e r f o rm a n c ee v a l u a t i o n e x h i b i t sh o wt h e s en ewn e t w o r k i n gt e c h n o l o g i e so p e r a t ei nr e a l -l i f ed e p l o ym e n t sa n d w h e r et oa d a p tt h emt od i ff e r e n ts c e n a r i o s . 4 . 1 6 L o WPAN D e s i g n 4 . 1 . 1 I n t e r n e tw o r k i n g A r c h i t e c t u r e T h e6 L oW P AN i n t e r n e t w o r k i n ga r c h i t e c t u r e i s m a d eu po f6 L oW P AN s ,r e g u l a r I Pn e tw o r k s( I P v 4 ,I P v 6 ) ,a n dr o u t e r s . T h eo v e r a l la r c h i t e c t u r e i sp r e s e n t e d i nF i g u r e4 . 2 i n w h i c h6 L oW P AN i sa n I P v 6 s u b n e to f sm a r to b j e c t s s h a r i n ga c omm o n I P v 6a d d r e s sp r efi x ( t h efi r s t6 4b i t so fa n I P v 6a d d r e s s ) . T h e s e sm a r to b j e c t sc a np l a y t h e r o l eo fah o s t o rar o u t e rt oc r e a t ea m e s hn e t w o r k .6 L oW P AN i sc o n n e c t e dt or e g u l a rI Pn e t w o r k s t h r o u g ha ne d g e r o u t e r . T h ee d g e r o u t e r f o rw a r d sd a t ap a c k e t sb e t w e e n t h e6 L oW P AN a n db a c k b o n e I P v 6 ,w h i l eh a n d l i n g I P v 6c om p r e s s i o na n dn e i g h b o rd i s c o v e r y .C omm u n i c a t i o nb e t w e e n6 L oW P ANsm a r to b j e c t sa n dI Ph o s t s i no t h e rn e t w o r k s h a p p e n s i na ne n d -t o -e n d m a n n e r , j u s t l i k eb e t w e e na n y r e g u l a r I Pn o d e s . E a c h6 L oW -P ANsm a r to b j e c t i s i d e n t i fi e db yau n i q u e I P v 6a d d r e s s ,a n d i sc a p a b l eo fs e n d i n ga n d r e c e i v i n gI P v 6p a c k e t s .I nF i g u r e4 . 2 ,t h e6 L oW P ANsm a r to b j e c t sc a nc omm u n i c a t e w i t he i t h e ro f t h e r e g u l a r I P v 6h o s t s ,s e r v e r so n t h e I n t e r n e t ,o rp e r s o n a lu s e r s 'd e v i c e s . Sm a r to b j e c t ss u p p o r tICM P v 6t r affi c( p i n g ) ,a n du s et h e UD Pa sat r a n s p o r t . S i n c e t h ep a y l o a da n dp r o c e s s i n gc a p a b i l i t i e so fsm a r to b j e c t sa r ee x t r em e l y l im i t e dt os a v e e n e r g y ,a p p l i c a t i o np r o t o c o l sa r ed e s i g n e d t ou s ea s im p l eb i n a r y f o rm a to v e rUD P s u c h a sD PW Sa n dC oA P .

Figure 4 .

 4 Figure 4.3 presents our 6EdR architecture consisting of several layers: Network Interfaces (regular IPv6, e.g., Ethernet and low-power, e.g., IEEE 802.15.4), 6LoWPAN Adaptation, Neighbor Discovery, IPv6, IPv6 Routing, Network Management, and Proxy. 6LoWPAN Adaptation Layer is for decompressing frames received from the low-power link (RFC 4944) using known information about the network and compressing regular IPv6 frames from the regular network interface. This step could be performed in the wireless interface or the edge router driver. Neighbor Discovery is responsible for several configuration tasks such as auto-configuration of nodes, discovery of other nodes on the link, and maintaining reachability information about the paths to other active neighbor nodes. It includes both IPv6 Neighbor Discovery Protocol (NDP, RFC 4861) and 6LoWPAN Neighbor Discovery (6LoWPAN-ND, RFC 6775). The interface or driver should take care of configuring the stack or adapting relevant neighbor discovery messages between 6LoWPAN-ND and NDP. IPv6 Routing maintains route entries between its interfaces belonging to two different routing domains where most traffic flows are coming from the Internet towards one or more 6LoWPAN nodes, or from LoWPAN nodes towards the Internet. Network Management is one of the core features of any network deployment for managing smart objects on 6LoWPAN. It may use Simple Network Management Protocol (SNMP, RFC 6353). Proxy further adds application layer translation models for transferring request in and out 6LoWPAN.

F

  i g u r e4 . 3 :6 E dRD e s i g n . 4 . 2 . 2 S o f tw a r e W eu s et h e l a t e s tu p d a t eo fC o n t i k i O S3 . x 3 ( b yt h et im eo fw r i t i n gt h i s m a n u s c r i p t ) w i t hµ I Pp r o t o c o l s t a c k t o im p l em e n t I P v 6n e t w o r k i n g f u n c t i o n a l i t i e s f o r t h e6 L oW P AN n o d e s . T I M S P 4 3 0t o o l c h a i no n U b u n t u i su s e dt oc om p i l et h ep r o g r am s f o rCM 5 0 0 0 m o t e s . T h e s ep r o g r am sa l lc o n fi g u r e t h e sm a r to b j e c t s t ou s e r a d i oc h a n n e l2 6 ,C o n t i k i -MA C [ 5 4 ] f o rd u t yc y c l i n g m e c h a n i sm , r o u t e r m o d et oc r e a t ea m e s hn e t w o r k ,a n d MA C a d d r e s s e st oa u t og e n e r a t et h e i r I P v 6a d d r e s s e s( e . g . , MA C0 0 : 1 2 : 7 4 : 0 0 : 1 3 :c b : 2 d : a 6 f o r I P v 6a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c b : 2 d a 6a d d r e s s ) . O nt o po ft h a t ,s e v e r a l m o d u l e sa r ed e v e l o p e d t op r o v i d ed i ff e r e n t f u n c t i o n a l i t i e st ot h esm a r to b j e c t ss u c ha se n e r g yp r o fi l i n g( u s i n g E n e r g e s tp o w e rp r o fi l e [ 5 5 ] ) ,UD P s e r v e r ,C oA P s e r v e r ( E r b i um l i b r a r y [ 5 6 ] ) ,a n dD PW S s e r v e r ( uD PW S l i b r a r y 4) .F i g u r e4 . 4 s h o w s t h e r e a lh a r dw a r ec o n fi g u r a t i o no f t h ee d g e r o u t e rw i t ht w o i n t e r f a c e s :I E E E8 0 2 . 1 5 . 4a n dE t h e r n e t .R a s p b i a nO S ,aD e b i a n -b a s e dO S i sp r o v i d e da s t h ep l a t f o rm f o r t h ee d g e r o u t e r .I t s I E E E8 0 2 . 1 5 . 4 i n t e r f a c ec omm u n i c a t e sw i t ht h ee d g er o u t e rv i a U SBp o r tu s i n gS e r i a l L i n eI n t e r n e tP r o t o c o l( S L I P ) . W ec r e a t ean e t w o r k TUN n e l(TUN )v i r t u a l i n t e r f a c e t os im u l a t ean e t w o r kd e v i c eo p e r a t i n go nI n t e r n e tl a y e r . T h i sTUNi n t e r f a c e w o r k s w i t hS I Pt oa p p l y6 L oW P ANa d a p t a t i o n . W ea l s oc o n fi g u r et h e R a s p b i a n O Sa sa n I P v 6r o u t e rb e t w e e nt w on e t w o r k i n t e r f a c e sE t h e r n e ta n d TUN . B yt h a t ,t r affi c f r om 6 L oW P ANc om e st ot h ee d g er o u t e r w i t hI E E E8 0 2 . 1 5 . 4f r am e sa d d i n gc om p r e s s i o n a n d6 L oW P ANa d a p t a t i o n i nt h es o f t w a r e ,p a s s e dt o TUN i n t e r f a c ea n dt h e nr o u t e d t oE t h e r n e t i n t e r f a c et or e a c hr e g u l a rI P v 6n e t w o r k . F o re x am p l e , w h e na6 L oW P AN 3 h t t p : / /www . c o n t i k i -o s . o r g / ,v e r s i o n2 0 1 5 / 0 2 / 1 6 4 h t t p : / /www .w s 4 d . o r g /

Figure 4 . 4 :

 44 Figure 4.4: 6EdR hardware: Raspberry Pi with an Ethernet interface and a CM5000 mote as an IEEE 802.15.4 interface.

4. 5 .

 5 There estimates about 10 Wi-Fi devices operating at the time of the experiment. A screen capture from a Wi-Fi analyzer indicates which channels wireless networks are on and how strong they are. We notice that only eduroam and eduspot are busy on channel 1, other in mild status which would not affect much on the experiment nodes operating on IEEE 802.15.4 radio channel 26. Network configuration is as follows: Building Router Linksys E1200, IPv6-enabled 6LoWPAN aaaa::/64 6EdR (Raspberry Pi and CM5000) -Ethernet: fde5:d6db:6ff6::1 (connected to E1200) -IEEE 802.15.4: aaaa::212:7400:13cb:44 -Virtual TUN: aaaa::1

F

  i g u r e4 . 5 :6 L oW P ANh om en e t w o r ks e t t i n g . Sm a r to b j e c t s -1 -h o pn o d e :a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c b : 4 4 b b -2 -h o pn o d e :a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c b : 1 0 1 a -3 -h o pn o d e :a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c b : 1 e 4 1 IP v 6h o s t -E t h e r n e t :f d e 5 : d 6 d b : 6 ff 6 : : 1 0 0( c o n n e c t e dt oE 1 2 0 0 ) 4 . 3 . 1 E n e r g y C o n s um p t i o n T h efi r s te x p e r im e n t i sa b o u te n e r g yc o n s um p t i o n . W ee x am i n eh o we a c hn o d e i nt h e n e t w o r kc o n s um e se n e r g y i nt w o m o d e s( h o s ta n dr o u t e r )w i t hfi v ed i ff e r e n td a t ar a t e s ( 1t o5p a c k e t / s ) . Asm a r to b j e c t i sc o n s i d e r e dt ob e i nr o u t e r m o d ei f i t f o rw a r d st h e tr affi cb e t w e e no t h e rn o d e s . T h e h o s t m o d ei sw h e n t h e sm a r to b j e c to n l yc omm u n i c a t e s w i t ho t h e ro b j e c t so rt h ee d g er o u t e rw i t h o u td o i n ga n yt r affi c f o rw a r d i n g . W eu s et h e p o w e rp r o fi l eE n e r g e s t [ 5 5 ] i nC o n t i k i O St or e c o r dt h ee n e r g yc o n s um p t i o n i nat a r g e to b j e c t . E n e r g e s tu s e sp o w e r s t a t e t r a c k i n g t oe s t im a t e s y s t emp o w e rc o n s um p t i o na n da s t r u c t u r ec a l l e de n e r g yc a p s u l e st oa t t r i b u t ee n e r g yc o n s um p t i o nt oa c t i v i t i e s i n c l u d i n g C PUi na c t i v e m o d e(C PU ) , C PUi ns t a n d b y m o d el o w -p o w e r m o d e( L PM ) ,p a c k e t t r a n sm i s s i o n s(TX ) ,a n dr e c e p t i o n s(RX ) .T h ep o w e r f o re a c ha c t i v i t y i sc a l c u l a t e db y f o l l o w i n gF o rm u l a4 . 1 :E n e r g e s tVa l u e×C u r r e n t×Vo l t a g e R T IMER SECOND×R u n t im e ( 4 . 1 )

Figure 4 . 6 :

 46 Figure 4.6: Energy consumption in host mode.

Figure 4 . 7 :

 47 Figure 4.7: Energy consumption in router mode

Figure 4 . 8 :. 2 )Figure 4 . 8 and

 48248 Figure 4.8: Duty cycle in host mode

Figure 4 . 9 :

 49 Figure 4.9: Duty cycle in router mode4.3.3 Network PerformanceIn the third experiment, we send 100 Internet Control Message Protocol version 6 (ICMPv6, RFC4443) packets from a regular IPv6 host to different smart objects in the 6LoWPAN and wait for the echo responses to record some network parameters such as packet loss, round-trip time, and time-to-live to calculate packet delivery ratio (PDR), end-to-end delay, and data transfer rate. The experiment is to send three sets of packets to three types of 6LoWPAN nodes: 1-hop, 2-hop, and 3-hop. Each set is carried out in 5 different data rates from 1 to 5 packet/s.

Figure 4 .

 4 [START_REF] Huhns | Service-oriented computing: Key concepts and principles[END_REF] shows the experiment results indicating RSSI in a good condition within the range of 21 m and LQI remains stable at 108.4.3.3.2 Packet Delivery RatioAs illustrated in Figure4.11, PDR gets very high rate of 98 percent for 1-hop nodes and slightly drops to 86 percent when data rate reaches the highest rate among the tests of 5 packet/s. For 2-hop and 3-hop nodes, PDR is lower through out the experiment fluctuating from 45 to 80 percent.

Figure 4 . 10 :

 410 Figure 4.10: Radio RSSI and LQI.

Figure 4 . 11 :

 411 Figure 4.11: Packet Delivery Ratio.

Figure 4 .

 4 Figure 4.12 shows the end-to-end delay slightly increases when more packets come back and forth between nodes, it however remains very low and not much diverse between different types of nodes (1-hop, 2-hop, and 3-hop), ranging from 30 to 60 ms. These figures are considered transparent to the communication.

Figure 4 .

 4 Figure 4.12: End-to-end Delay.

Figure 4 . 13 :

 413 Figure 4.13: Transfer rate.

4. 3 . 4

 34 Service CommunicationWhen it comes to the development of IoT applications, apart from the IP networking infrastructure, provisioning smart object services is an essential issue. Developers expect APIs that they can integrate new features and create new functionalities to their applications. Notably, CoAP is designed exclusively for smart objects to replace HTTP and can be easily translated to HTTP for a transparent integration with the Web while meeting the smart object requirements such as multicast support, very low overhead, and publish/subscribe model. Since CoAP is not native to the Web protocols, a CoAP/HTTP proxy is a common approach to provide HTTP-based APIs for CoAP services. DPWS is another application protocol for smart objects. It brings W3C Web services technology into the IoT by defining specifications that provide a secure and effective mechanism for describing, discovering, messaging, and eventing services for resourceconstrained devices. DPWS uses WSDL to describe a device, Web Services Metadata Exchange 5 to define metadata about the device, and WS-Transfer 6 to retrieve the service description and metadata information. The messaging exchange occurs via SOAP, WS-Addressing 7 , and the Message Transmission Optimization Mechanism/XML-Binary Optimized Packaging 8 with SOAP-over-HTTP and SOAP-over-UDP bindings. It uses WS-Discovery 9 for discovering a device (hosting service) and its services (hosted services) and the Web Services Policy 10 to define a policy assertion and indicate the device compliance with DPWS. Secure Web services, dynamic discovery, and eventing features are the main advantages of DPWS for event-driven IoT applications.

Figure 4 .

 4 14 presents the request/response message sizes and latency of CoAP, DPWS, and HTTP transactions. CoAP messages apparently smaller than HTTP messages due to the the use of simplified headers compared to HTTP headers though the difference is at hundred kb. DPWS, meanwhile, shows a significant overhead compared to the other two protocols. The round-trip time of CoAP and HTTP communications are not much different and considered to be transparent to user's experience. DPWS round-trip time is still low but much greater than CoAP and around twice more than of HTTP.

Figure 5 . 1 :

 51 Figure 5.1: Comparison of service delay when multiple simultaneous requests are sent to one smart object.

  s f o ra s e c u r e , s c a l a b l e ,a n d r e l i a b l e s e r v i c ep r o v i s i o n i n g t op o w e r I oTa p p l i c a t i o n so n W e b .

2 . 0 5

 5 Content </. w e l l -known/ c o r e >; c t =40 , </ c o n t r o l / l e d > t i t l e ="LED Red , PUT mode=on | o f f " ; r t =" c o n t r o l "

<Listing 5 . 2 :

 52 ?xml v e r s i o n ="1.0" e n c o d i n g="UTF-8"?> <s 1 2 : Envelope xmlns : s 1 2="h t t p : / /www. w3 . o r g /2003/05/ soap-e n v e l o p e " xmlns : wsa="h t t p : / /www . w3 . o r g /2005/08/ a d d r e s s i n g " xmlns : wsd="h t t p : / / d o c s . o a s i s -open . o r g /ws-dd/ ns / d i s c o v e r y /2009/01" > <s 1 2 : Header> <wsa : Action>h t t p : / / d o c s . o a s i s -open . o r g /ws-dd/ ns / d i s c o v e r y /2009/01/ Probe </wsa : Action> <wsa : MessageID>urn : uuid : 3 a c 5 f 8 2 0 -d47d -11e3 -80c0 -358 d7a9bbe90 </wsa : MessageID> <wsa : To>urn : docs-o a s i s -open-o r g : ws-dd : ns : d i s c o v e r y :2009:01 </ wsa : To> WS-Discovery Probe message.

  <ns0 : ty pe r d f : r e s o u r c e ="h t t p : / / pur1 . o c 1 c . o r g /NET/ s s n x / s s n#S e n s o r "/> <ns1 : o b s e r v e d P r o p e r t y >Temperature </ns1 : o b s e r v e d P r o p e r t y > <ns1 : hasValue >19.2</ ns1 : hasValue> </ r d f : D e s c r i p t i o n > </ r d f :RDF> Listing 5.4: Temperature sensor smart object RDF/XML format.Tim Berners-Lee coined the term Semantic Web as an extension of the current Web[3] in which data are consumable and understandable to machines. It brings a new concept of representing data in the meaningful graph database model to improve the communication between human and machine. That means Semantic Web can achieve a certain level of automation on Web[START_REF] Chen | Semantic web meets computational intelligence: State of the art and perspectives [review article[END_REF]. When the IoT paradigm arrives and it is now changing the Web, the Semantic Web concept even fits more to its architecture since smart objects need intelligence and automation in different level to fulfill their tasks. However, similar to other extensions of Internet and Web protocols originally designed for computers to smart objects such as CoAP to HTTP or DPWS to SOAP, straightforward adoption of semantic annotation to smart objects is impractical. It is because of the complexity of the Semantic Web model with the involvement of ontology, triple, and data presentation following specific requirements. @ p r e f i x : <h t t p : / /www. i t -s u d p a r i s . eu / s e n s o r#> . @ p r e f i x r d f : <h t t p : / /www. w3 . o r g /1999/02/22 -r d f -syntax-ns#> . @ p r e f i x ns0 : <h t t p : / /www. w3 . o r g /2000/01/ r d f -schema#> . @ p r e f i x ns1 : <h t t p : / / pur1 . o c 1 c . o r g /NET/ s s n x / s s n#> . <h t t p : / /www. i t -s u d p a r i s . eu / s e n s o r#Temp5> ns0 : ty pe ns1 : S e n s o r ; ns1 : hasValue " 1 9 . 2 " ; ns1 : o b s e r v e d P r o p e r t y " Temperature " . Listing 5.5: Temperature sensor smart object N3 format. Listing 5.4, for example, shows an example of RDF representation of temperature data from a sensor of a smart object. It uses 506 bytes to semantically represent the data from the smart object with temperature sensing value is 19.2 degree. Even with

  b s e r v e d P r o p e r t y " Temperature " . Listing 5.6: Temperature sensor smart object N3 format.

OAuth 2 .

 2 0 (RFC 6749) is an authorization framework that enables applications to obtain limited access to resources on the Web on behalf of the resource owner. It has been widely used in many services such as Google, Facebook, and GitHub. It works by delegating user authentication to the service that hosts the user account, and authorizing thirdparty applications to access the user account. OAuth 2.0 provides authorization flows for Web and desktop applications and mobile devices.OAuth 2.0 fits the security model of the IoT applications on Web where the resource (smart object) owner can authorize an application to access their smart object functions without having full access on handling the smart object such as terminating its operation.

F i g u

  r e5 . 3 :3 -s t e pa u t h o r i z a t i o np r o c e s s f o r I oTa p p l i c a t i o n so n W e b . T h efi r s t m e t h o di ss t r a i g h t f o rw a r ds i n c e i td o e s n ' tr e q u i r ea n yc h e c kf o ra d d r e s s d u p l i c a t i o n f o r t h e I Pa d d r e s s i sa l r e a d yu n i q u e i n t h en e t w o r k s o i t i sag o o dc a n d i d a t e f o rsm a r to b j e c t i d e n t i t y . T h es e c o n d m e t h o dr e q u i r e st h ep r o v i s i o n i n gs e r v e rt oc h e c k t h eh o s t n am ed u p l i c a t i o n .I tc a nb es u i t a b l e f o rsm a l lh om e so roffi c e s . D PW Su s e s W S -A d d r e s s i n gt oa s s i g nau n i q u e i d e n t i fi c a t i o n f o re a c hsm a r to b j e c t ( e n d p o i n ta d d r e s s ) , i n d e p e n d e n t f r omt r a n s p o r ts p e c i fi ca d d r e s s . T h i su n i q u e i d e n t i fic a t i o n i su s e dw i t has e r i e so f m e s s a g ee x c h a n g e sP r o b e / P r o b eM a t c h , R e s o l v e /R e s o l v e -M a t c h t og e ta t r a n s p o r ta d d r e s sa n d t h e na n o t h e r s e r i e so f m e s s a g e sa r e s e n tb a c ka n d f o r t h t o i n v o k ea no p e r a t i o n . W ed e fi n ea m a p p i n gb e t w e e nap a i ro fD PW Se n d p o i n t /t r a n s p o r ta d d r e s s e sa n das i n g l e UR I ,a n dt h e n w eu s et h ec o r r e s p o n d i n go p e r a t i o n n am ef o re a c hs e rv i c ea st h ee x t e n s i o no ft h e UR I .F o re x am p l e ,t h ea f o r em e n t i o n e d t h e rm o s t a th a sag e tT em p ( )o p e r a t i o nim p l em e n t e di n D PW S w i t ht h ep a i ro fe n dp o i n ta n dt r a n s p o r ta d d r e s s e so fu r n : u u i d : 4 t h e rm o s t a t . T a b l e5 . 4s h o w s t h e m a p p i n go f t h e s e t w o a d d r e s s e sa l o n gw i t h t h eo p e r a t i o nn am e ( t em p ) t oa s i n g l eUR I .T h e m a p p i n g i sun i q u e f o re a c hsm a r to b j e c ts e r v i c e ,a n dd a t aa r es t o r e d i nt h esm a r to b j e c tr e p o s i t o r yo ft h e p r o x y . T h er e p o s i t o r y i sa l s ou p d a t e d w h e nt h e r e i sac h a n g e i nsm a r to b j e c ts t a t u s a n d / o rp e r i o d i c a l l yw h e n t h ep r o x y r u n s i t s r o u t i n e t oc h e c ka l l t h ea c t i v e sm a r to b j e c t s . T a b l e5 . 3 : UR I m a p p i n gw i t hC oA P S e r v i c e UR I c o a p : / / [ a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c c : 3 6 9 3 ] : 5 6 8 3 / t em p P r o v i s i o n i n gs e r v e r 1 5 7 . 1 5 9 . 1 0 3 . 5 0 S c h em e1 UR I h t t p : / / 1 5 7 . 1 5 9 . 1 0 3 . 5 0 / t h e rm o s t a t / t em p S c h em e2 UR I h t t p : / / 1 5 7 . 1 5 9 . 1 0 3 . 5 0 / [ a a a a : : 2 1 2 : 7 4 0 0 : 1 3 c c : 3 6 9 3 ] / t em p

F i g u r e5 . 4 :

 4 R e s o u r c e M a n a g em e n t W e b U I i nT h i n g sG a t e . M a n a g e D e v i c e f u n c t i o n /m e n us h o w sa l i s to fd i s c o v e r e dd e v i c e s i nt h e6 L oW P ANo fh om en e t w o r k . U s e rc a n q u e r yd e t a i l e di n f o rm a t i o no ra d ds o c i a ld a t at oe a c hd e v i c eb yI n f oo rS o c i a l i z eh yp e r l i n k sa s s o c i a t e dt oe a c hsm a r to b j e c t . A p p l i c a t i o n sf u n c t i o n /m e n uh e l pu s e r st o a u t h o r i z e I oTa p p l i c a t i o n so n W e bt ou s er e s o u r c e s i nt h e6 L oW P AN . 5 . 2 . 7 R e s o u r c e M a n a g em e n t R e s o u r c e M a n a g em e n tf u n c t i o n a lb l o c ki si nc h a r g eo f m o n i t o r i n ga n d m a n a g i n gt h e 6 L oW P ANa n d i t s sm a r to b j e c t s .I tp r o v i d e s i n f o rm a t i o na b o u t t h en e t w o r k s t a t u s s u c h a st h en um b e ro fn o d e s ,n e t w o r kt o p o l o g y ,a n dr o u t i n g i n f o rm a t i o n .I ta l s op r o v i d e s a ni n t e r f a c ef o rg r a n t i n ga u t h o r i z a t i o nt oI oTa p p l i c a t i o n so n W e bt og e ta c c e s st o t h ep r o v i s i o n e d W e b A P I . R e s o u r c e M a n a g em e n ta u t h e n t i c a t e su s e r sb yc r e d e n t i a l s ( u s e r n am e / p a s sw o r d )v i aa W e bU s e r I n t e r f a c e (W e bU I ) .F i g u r e5 . 4 s h o w s t h e W e bU I o ft h e R e s o u r c e M a n a g em e n tim p l em e n t e d w i t h i n T h i n g sG a t ep r o v i s i o n i n gs e r v e rf o r t h eS o c i a l I oTa p p l i c a t i o np r e s e n t e d i nC h a p t e r6 .

Figure 5 .

 5 Figure 5.6 shows the 6LoWPAN with 10 random nodes. The longest distance to the 6EdR (node 1) is 3-hop (nodes 1-2-3-4). TX/RX success ratio is set at 98 percent as suggested in Packet Delivery Ratio test in Chapter 4. Each node is implemented with a CoAP service enriched with the proposed semantic annotation. We aim to test

F i g u r e5 . 5 :

 5 N e t w o r k t o p o l o g y i n t w oc a s e s :( a )O u rp r o p o s e dd e s i g nc o n fi g u r e sap r o x yb a s e d t o p o l o g yw i t h l o c a lHTT P / SOA Pb i n d i n g ,( b )T h eo r i g i n a lsm a r to b j e c t sP r o fi l e f o r W e bS e r v i c e s(D PW S )c omm u n i c a t i o nc o n fi g u r e sg l o b a l m e s h -l i k ec o n n e c t i v i t y f o r HTT P / SOA Pb i n d i n g . C o n s e q u e n t l y , t h eo r i g i n a lD PW S i n t r o d u c e sh i g h e r l a t e n c ya n d o v e r h e a d . t h ep e r f o rm a n c eo fs e r v i c ep r o v i s i o n i n gs e r v e rt os e eh o wt h ep r o p o s e da l g o r i t hm sa n d m e c h a n i sm sp e r f o rm i nt e rmo ft r a n s p a r e n c ya n deffi c i e n c y .T h ep r o v i s i o n i n gs e r v i c e i sd e p l o y e d i nt h es im u l a t o rh o s t m a c h i n e ,w h i c hc r e a t e sa l o c a ln e t w o r kw i t h6 E dR i n i t sE t h e r n e t i n t e r f a c e . A W e ba p p l i c a t i o n i sd e v e l o p e d i na W e bs e r v i c eo ft h es am e l o c a ln e t w o r kw i t h t h ep r o v i s i o n i n g s e r v e r ( t h ed e p l o ym e n to f t h e s am ea p p l i c a t i o no na s e r v e ro n W e bd o e s n ' tc h a n g e t h en a t u r eo f t h e I Pc omm u n i c a t i o nw i t h t h e i n v o l v em e n to fan um b e ro fr o u t e r s ) .5 . 4 . 1 T r a n s p a r e n c y F i r s to fa l l ,t h ec o n s i s t e n tu s eo f I Ps t a c k s i nsm a r to b j e c t sa sw e l la s i np r o v i s i o n i n g i s a l i g n e dw i t hc omm o nn e t w o r k i n f r a s t r u c t u r e ,w h i c he n s u r e sa t r a n s p a r e n c yo fc omm u n ic a t i o n i n t h en e t w o r k .6 E dR i sa n im p o r t a n tn o d e i n t h e I Pn e t w o r k i n g m o d e l t oa s s u r e t h esm o o t hc omm u n i c a t i o n . T h i sca nfi r s tv e r i fi e db yp i n g 6c omm a n d f r omar e g u l a r I Pn o d et oa6 L oW P ANn o d e( s e eL i s t i n g5 . 8 ) . W e f u r t h e re x am i n et h et r a n s p a r e n c y o ft h es e r v i c ep r o v i s i o n i n ga g a i n s tt h e im p l em e n t a t i o no fo u rp r o p o s e da l g o r i t hm s ,e sp e c i a l l y f o rt h es c h e d u l i n g . W ec a r r yo u tas i n g l er e q u e s tt oas e r v i c eo fn o d e2 f r om o u rI oTa p p l i c a t i o n w i t ha n d w i t h o u ts c h e d u l i n g m o d u l e . F i g u r e5 . 7s h o w st h a tt h e F i g u r e5 . 6 : A6 L oW P AN i nC o o j aw i t h1 0n o d e sa n d3 -h o pd i s t a n c e f r om t h e e d g e r o u t e r ( n o d e1 ) . A l ln o d e sa r e im p l em e n t e dw i t hC o n t i k ia n du I P s t a c k s . T h e s c r e e n s h o t s h o w s t h en e t w o r k i fs e l f -c o n fi g u r i n gw i t ht r affi ce x c h a n g e db e t w e e nn o d e s .

  ˜$ L i s t i n g5 . 8 : P i n gc omm a n df r omar e g u l a rI Pn o d et o2 -h o pn o d e3i n6 L oW P A PN ( a a a a : : 2 1 2 : 7 4 0 3 : 3 : 3 0 3 ) .

Figure 5 . 7 :

 57 Figure 5.7: Scheduling algorithm is transparent as it does not affect a single request. Its purpose is to improve the delay when there are multiple simultaneous requests coming to one smart object.

Figure 5 . 8 :

 58 Figure 5.8: Comparison of service delay when multiple simultaneous requests are sent to one smart object service.

Figure 5 . 9 :

 59 Figure 5.9: Comparison of radio duty cycle when multiple simultaneous requests are sent to one smart object.

Figure 5 . 10 :Figure 5 . 11 :

 510511 Figure 5.10: Comparison of energy consumption when multiple simultaneous requests are sent to one smart object.

Figure 5 . 12 :

 512 Figure 5.12: CoAP, DPWS, and HTTP message overhead and latency.

  e x t / html Connection : keep-a l i v e HTTP/ 1 . 1 200 OK S e r v e r : Apache-Coyote / 1 . 1 Content-Type : t e x t / html T r a n s f e r -Encoding : chunked Date : Fri , 26 J u l 2013 2 1

  2 1 2 : 7 4 0 0 : 1 3 c c : 3 6 9 3 ] : 4 5 6 7 / Heater </wsa : To> </s 1 2 : Header> <s 1 2 : Body/> </s 1 2 : Envelope> <?xml v e r s i o n ="1.0" e n c o d i n g="UTF-8"?> <s 1 2 : Envelope xmlns : s 1 2="h t t p : / /www. w3 . o r g /2003/05/ soap-e n v e l o p e " xmlns : wsa ="h t t p : / /www. w3 . o r g /2005/08/ a d d r e s s i n g "> <s 1 2 : Header> <wsa : Action>h t t p : / / telecom -s u d p a r i s . eu / o p e r a t i o n s / g e t s t a t u s R e s p o n s e </ wsa : Action> <wsa : RelatesTo>urn : uuid :46932240 -d504 -11e3-bf6a -6eabe38b6788 </wsa : RelatesTo> </s 1 2 : Header> <s 1 2 : Body> <i 5 3 : r e p l y xmlns : i 5 3 ="h t t p : / / telecom -s u d p a r i s . eu">ON</ i 5 3 : r e p l y > </s 1 2 : Body> </s 1 2 : Envelope>

  DPWS defines a set of implementation constraints to provide secure and effective mechanisms for service describing, discovering, messaging, and eventing for resource-constrained devices. Since its debut in 2004 by a consortium led by Microsoft, DPWS has become part of Microsoft's Windows Vista and Windows Rally (a set of technologies from Microsoft intended to simplify the setup and maintenance of wired and wireless networked devices), and has been developed in several research and development projects under the European Information Technology for European Advancement (ITEA) and Framework Programme (FP): SIRENA (02014 ITEA2), SODA (05022 ITEA2), SOCRATES (FP6), and on-going IMC-AESOP (FP7) and WOO (10028 ITEA2). Many technology giants such as ABB, SAP, Schneider Electric, Siemens, and Thales have been participating in these projects. As they have large market shares in electronics, power, automation technologies as well as enterprise solutions, their promotion of the DPWS technology promise a wide range of the future DPWS/IoT products. Schneider Electric and Odonata pioneered the implementation of DPWS leading to the early and open-source release of software stacks implementing DPWS in C and Java available at Service-Oriented Architecture for Device Website 1 . Web Services for Devices initiative 2 reinforces the implementation by providing and maintaining a repository to host several open-source

5 )

 5 which features a full-fledged OSN with a Web-based User Interface (WUI). A Device Profiles database is added to store the device profiles inheriting all the properties of user profiles but containing some additional information to interact with the socialized devices such as endpoint address referring to the base URI of Web API related to the corresponding device. In addition, Device Adapter module acts as the interface for the communication between the social network platform and socialized devices. The other modules Recommender, Semantic Reasoner, and NLP Interface are in charge of realizing the human-like intelligence and recommendation functionalities for devices.

F i g u r e6 . 1 :

 1 T h i n g sC h a ta r c h i t e c t u r e . 6 . 2 . 2 S o c i a l i z e d W e b AP I W ee x t e n do u rp r o p o s e ds e r v i c ep r o v i s i o n i n gt o i n c l u d et h es o c i a lc h a r a c t e r i s t i c s( e . g . , c omm u n i c a t i o na n dd e c i s i o n -m a k i n g )b ya d d i n gt h eD e v i c eS o c i a l i z a t i o n m o d u l et oe xi s t i n gs e r v i c ep r o v i s i o n i n gf r am ew o r k . T h i sc r e a t e san ewS o c i a l i z e d W e b A P It of ac i l i t a t en o to n l yt h ec omm u n i c a t i o nb e t w e e nd e v i c e sa n dt h eS I oTp l a t f o rmb u ta l s o b e t w e e nd e v i c e sa n dh um a nu s e r s . T h es e r v i c ep r o v i s i o n i n gs e r v e r i s im p l em e n t e d i nt h e f o rmo fah om eg a t ew a yT h i n g sG a t e ,w h i c he x t e n d s t h e i n -n e t w o r k im p l em e n t a t i o n o fo u rp r o p o s e da r c h i t e c t u r ep r e s e n t e d i nS e c t i o n5 . 3t od i s c o v e r ,s t o r e ,a n dt r a n sm i t d e v i c es e r v i c e st oT h i n g sC h a t .I tp r o v i d e sa n i n t e r a c t i v eT h i n g sG a t e WU I i nR e s o u r c e M a n a g em e n t ( a s e r v i c ep r o v i s i o n i n g f u n c t i o n a lb l o c k ,d e t a i l sa t5 . 2 . 7 ) f o ru s e r s t og r a n t a u t h o r i z a t i o nt oT h i n g sC h a ta n d i n i t i a l i z ed e v i c e sw i t hs o c i a l i z e d f u n c t i o n a l i t i e s ,t u r ni n gt h em i n t os o c i a le n t i t i e s . T a b l e6 . 2s h o w st h e m a i ne n d p o i n t so ft h eS o c i a l i z e d W e b A P I f r omT h i n g sG a t e .I nt h i sa p p l i c a t i o n , T h i n g sG a t ea l s op l a y sa n o t h e rr o l ea st h e m e d i a t o r f o ra n imp o r t a n ts t e pc a l l e ds o c i a l i z i n gd e v i c e .I t i n v o l v e su s e ro rd e v i c eo w n e r i nt h e l o o pt o a u t h o r i z ea n dc u s t om i z e t h ed e v i c e t ofi t i n t h eS I oTp l a t f o rm .F i g u r e6 . 2 i l l u s t r a t e s t h es t e po f s o c i a l i z i n ga r o b o tc l e a n e rv i aR e s o u r c e M a n a g em e n t WU I .T h i n g sG a t ed i s c o v e r s a D PW Sd e v i c ew i t ha n IDR o b o tC l e a n e rD e v i c e ( ar o b o tc l e a n e rw i t hd e t a i l ss h o w n i n F i g u r e6 . 3 ) i nt h en e t w o r ka n da u t om a t i c a l l yg e n e r a t e s W e b A P Ie n d p o i n t s f o rp r o v i -T a b l e6 . 2 : T h i n g sG a t eS o c i a l i z e d W e bA P I . W e b A P IE n d p o i n t A r g um e n t s D e s c r i p t i o n G ET/ s o c i a l / d e v i c e -l i s t N /A L i s ts o c i a l i z e dd e v i c e s PO ST/ s o c i a l / r e g i s t e r d e v i c e -n am e R e g i s t e ras o c i a ld e v i c ep r o fi l e d e v i c e -u s e r n am e p a s sw o r d PO ST/ s o c i a l / c h a t -t o -d e v i c e d e v i c e -i d S e n dn ewp o s tt oau s e r p o s t -i d c o n t e n t PO ST/ s o c i a l / f r i e n d -r e q u e s t d e v i c e -i d S e n dn ewp o s tt oau s e r u s e r -i d G ET/ s o c i a l / n l p c o n t e n t G e td e v i c ec o d et r a n s l a t e d t on a t u r a l l a n g u a g e F i g u r e6 . 2 : T h i n g sG a t eR e s o u r c e M a n a g em e n t :S o c i a l i z i n gad e v i c e . s i o n i n g i t ss e r v i c e .I nt h i ss t e p ,t h ed e v i c e i sa l r e a d ya v a i l a b l ef o rc omm u n i c a t i n gt o I oTa p p l i c a t i o n so n W e bb u tn o ty e t r e a d y f o r i n t e r a c t i n gw i t hu s e r so nS I oTp l a t f o rm .A nu s e r l o g s i nt ot h es y s t emv i aT h i n g sG a t e WU It os e et h e l i s to fd i s c o v e r e d / p r o v is i o n e dd e v i c e sa n ds e l e c tR o b o tC l e a n e rD e v i c e t os o c i a l i z e i t . T h i n g sG a t et h a nr e d i r e c t s t h eu s e rt oar e g i s t r a t i o n i n t e r f a c et h a ts h ec a nc u s t om i z et h ed e v i c ew i t hs om es o c i a l c h a r a c t e r i s t i c ss u c ha su s e rn am ea n da v a t a r . T h eu s e rc l i c k sR e g i s t e rb u t t o nt ofi n i s h t h e r e g i s t r a t i o n ,a n d i fT h i n g sG a t e s u c c e s s f u l l y r e g i s t e r s t h ed e v i c e i n t h eS I oTp l a t f o rmU s e rP r o fi l e s , i tw i l lg e n e r a t ed e v i c e ' sS o c i a l i z e d W e bA P Ie n d p o i n t sa n da d d t h ed e v i c e i n t ot h es o c i a l i z e d l i s t ,w h i c hc a nb es e e n l a t e rb yu s e r( s e eF i g u r e6 . 3 ) F i g u r e6 . 3 : T h i n g sG a t eR e s o u r c e M a n a g em e n t :L i s to fs o c i a l i z e dd e v i c e s .6 . 2 . 3 T h i n g sC h a t P l a t f o rmI na d d i t i o nt ot h ec o r e f u n c t i o n a l i t i e so fa n O SN ,T h i n g sC h a th a st h e D e v i c e A d a p t e r m o d u l et o i n t e r a c tw i t ht h eS o c i a l i z e d W e bA P I s . T h i s m o d u l eh a s i t so w ns e to fA P I e n d p o i n t s( s e eT a b l e6 . 3 )t h a tc a nc o o p e r a t ew i t ht h eS o c i a l i z e d W e bA P It o f u l fi l lt h e d u p l e xc omm u n i c a t i o nb e t w e e nu s e r sa n dd e v i c e s . F o re x am p l e ,ad e v i c es e r v i c ec a n c a l la n A P Ie n d p o i n ti nt h er e q u e s ts h o w ni nL i s t i n g6 . 1t ot a l kt ou s e r N a d i ai na p r e v i o u s l y -e s t a b l i s h e dc o n v e r s a t i o nw i t hp o s t -i d=3 7 5 . D e v i c eA d a p t e r i s s u p p o r t e db y D e v i c eP r o fi l e sd a t a b a s e t h a t s t o r e sd e v i c ep r o fi l e s ,a n de x t e n s i o no fU s e rP r o fi l e s i n t h e c o r es o c i a ln e t w o r k i n gd a t a b a s e . T h ee x t e n s i o n i n c l u d e sA P Ie n d p o i n t sa n do w n e r s h i p o ft h ed e v i c e sb yw h i c hT h i n g sC h a tc a nn o t i f yd e v i c e s i nt h es am ew a yt h a t i tn o t i fi e s h um a nu s e r s( v i an o t i fi c a t i o n m e s s a g e s ) . N L PI n t e r f a c ep r e -p r o c e s sn a t u r a l l a n g u a g e m e s s a g e s f r omh um a nu s e r s i n t oa l i s to f m a c h i n e r e a d a b l ec omm a n d s ( t o k e n s )a n dv i c e v e r s a .S em a n t i cE n g i n e i s i nc h a r g eo fp r o c e s s i n g s em a n t i cd a t a r e c e i v e d f r omd e v i c e s i n N 3 f o rm a t .I tc r e a t e sad a t a m o d e lo u to ft h et r i p l e sr e c e i v e d f r omd e v i c e sa n dc a r r i e s o u t r e a s o n i n g t oe x t r a c tm o r e i n f o rm a t i o n t h a tc a nb eu s e d i n t h eR e c omm e n d e rm o d u l e t o m a k er e c omm e n d a t i o nt oh um a nu s e r so ro t h e rd e v i c e s . PO S T / s o c i a ln e t/ c h a t-t o -u s e r .p h p H T T P / 1 . 1 H o s t : th in g s ch a t . c om A c c e p t : t e x t / n 3 d e v i c e-i d=R o b o t C l e a n e r p o s t -i d= 3 7 5L i s t i n g6 . 1 : A P Ic a l l f r omd e v i c es i d et ot a l kt ou s e rN a d i a .

  n g s C h a t S e r v i c e E x e c u t i o n S e r v e r P r o c e s s i n g T h i n g s G a t e R u n n i n g T im e (m s ) F i g u r e6 . 4 : C o ff e e M a k e r i noffi c ea n d R o b o t C l e a n e ra t V i r t u a l H om er e c omm e n dt o N a d i aa c c o r d i n gt oh e rp r o fi l ea n dc a nu n d e r s t a n dh e rr e q u e s t s .

F i g u r e6 . 5 :

 5 P e r f o rm a n c eo ft h eS o c i a l i z e d W e bA P Io fT h i n g sG a t ea n dD e v i c eA d a p t e r W e bA P Io fT h i n g sC h a t . R o b o t C l e a n e rh a s n ' tc l e a n e dt h eh o u s e . R o b o t C l e a n e r ,b a s e do n N a d i a ' sp r o fi l ef o r h e r ep r e f e r e n c eo fc l e a n i n g f r e q u e n c y ,r em i n d sh e rt oh a v et h eh o u s ec l e a n e da n ds h e i s g l a dt ok n o wt h a ta n da s k st h eR o b o tC l e a n e rt od o i t .

  Figure 6.5 shows the running time for each task in the above conversation: request to [thingschat]/socialnet/chat-to-user.php, ThingsGate request takes average of 404 ms to complete consisting 199 ms for service execution and 205 ms for API processing, that is reasonably low for a service provisioning server in a local network deployment. ThingsChat request, however, takes just over 1

  The arrival of the IoT paradigm has opened up new approaches in the building automation domain with the availability of new devices and communication protocols which are open, light-weight, low-cost, and interoperable. IoT open standards, both in software and hardware have brought building automation in a new perspective that is never more realistic and affordable. This case study, therefore, aims to provide a new solution for BASs using open Web standards and IoT communication technologies such as 6LoWPAN and DPWS. We focus to solve the two fundamental problems of BASs:

  g . ,s e n s o r s , R F ID , N F Cr e a d e r s ) . T h e s ed e v i c e sa r ec o n n e c t e dt ot h eb u i l d i n gn e t w o r kv i a w i r e l e s so r w i r e dc o n n e c t i o n s w i t hI Ps t a c ka n d l o wp o w e r w i r e l e s sp r o t o c o l s . S e n s o r sa r e im p l em e n t e db yuD PW So v e r t h eC o n t i k iO S .E q u i pm e n tw i t h l a r g e r m em o r ya n dp r o c e s s i n g p o w e rr u no nEm b e d d e dL i n u xo rA n d o i d O S ,t h e i r f u n c t i o n a l i t i e sa r ed e v e l o p e du s i n g D PW S -g SOA P ,s om ec a nb ec o n n e c t e dd i r e c t l yt ot h er e g u l a rI Pn e t w o r k ,s om ej o i n t h en e t w o r kv i ah om ea c c e s sp o i n to r6 E dR .S e n s o r s w i t ht h e i rs e n s i n gc a p a c i t yc a n m o n i t o r t h ee n v i r o nm e n tR F ID r e a d e r s ,N F C r e a d e r s ,o rc am e r ac a n i d e n t i f yu s e r s . A l l h a r dw a r ec om p o n e n t sg e tc o n n e c t e dt ot h eB u i l d i n g A p p l i c a t i o nS e r v e rt h a th o s t st h e c o r e f u n c t i o n a l i t i e so ft h es y s t em . S y s t ema r c h i t e c t u r es h o w n i nF i g u r e6 . 7c o n s i s t so faS e r v i c eP r o v i s i o n i n g m o d u l e b a s e do no u rp r o p o s e ds e r v i c ep r o v i s i o n i n ga n ds e v e r a lo t h e rf u n c t i o n a lb l o c k st ou s eD PW Ss e r v i c e s i nb u i l d i n ga u t om a t i o n .I nw h i c h , COM PO S IT IONs u b s y s t emr e s i d e s a tt h ec e n t e ro ft h ea r c h i t e c t u r ew i t h i t sfi v e -s t e pc om p o s i t i o np r o c e s sh e l p st or e a l i z e a n dd e l i v e ra p p r o p r i a t ec om p o s i t es e r v i c e st ou s e rb a s e do nt h eu s e ra n de n v i r o nm e n t c o n t e x t . T h es u b s y s t emc a nb ef u n c t i o n a l l yd i v i d e di n t os e l e c t i n gse r v i c e s ,b i n d i n g s e r v i c e sa n de x e c u t i n gs e r v i c e sw h i c ha r er e fl e c t e d i nt h r e ec om p o n e n t s :S e r v i c eS e l e ct o r ,S e r v i c eB i n d e r ,a n dS e r v i c eE x e c u t o rr e s p e c t i v e l y .I na d d i t i o n , C om p o s i t i o nP l a n C r e a t o rh a sa c c e s st oC om p o s i t i o nP l a nd a t a b a s ea n dp r o v i d e s f u n c t i o n a l i t i e s f o ru s e r s t oc r e a t e , m o d i f y ,a n dd e l e t ec om p o s i t i o np l a n s . C om p o s i t i o nB r o k e rd e c i d e sw h e t h e r t oc a l lt h eCOM PO S IT IONo rn o tv i aad e c i s i o n -m a k i n gp r o c e s sb a s e do nt h er e c e i v e d c o n t e x t i n f o rm a t i o n . C o n t e x tP r o c e s s o r r e c e i v e sa n dp r o c e s s s em a n t i c c o n t e x td a t a f r om

F

  i g u r e6 . 7 :S y s t ema r c h i t e c t u r ec o n s i s t so f f o u r m a i ns u b s y s t em s DA T ABA S E ,COM -MUN ICA T ION ,D I SCOV ER Ya n dCOM PO S IT IONa n d f o u ro t h e r m o d u l e sC om p o s it i o nP l a nC r e a t o r ,S em a n t i cR e a s o n e r ,C om p o s i t i o nB r o k e ra n dC o n t e x tP r o c e s s o r . c o n t e x tc o l l e c t o r s ,a n dt h e ns e n d st h emt ot h eC om p o s i t i o nB r o k e r .6 . 3 . 2 B u i l d i n g O n t o l o g ya n d G r a p h D a t a b a s e B u i l d i n gO n t o l o g yd e fi n e sc o n c e p t sa n dr e l a t i o n s h i p sb e t w e e ne n t i t i e sw i t h i nt h eb u i l d -i n ge n v i r o nm e n t .I tp r o v i d e sas c h em at ob u i l du ps em a n t i cd a t a b a s e i nt h ef o rmo f g r a p hd a t a . T h i s i san ewc o n c e p to fd a t a b a s e f o rS em a n t i c W e bw h i c hc o n s um e sRD F t op r e s e n tt h ed om a i nk n o w l e d g e . RD F i sac omm o na c r o n ymw i t h i nt h es em a n t i cw e b

Listing 6 . 2 :

 62 eu / b a s o n t#P o l i c y --> <owl : C l a s s r d f : about = ' ' h t t p : / /www. i t -s u d p a r i s . eu / bas P o l i c y ' ' > <r d f s : subClassOf > <owl : R e s t r i c t i o n > <owl : on Pr operty r d f : r e s o u r c e = ' ' applyFor ' '/ > <owl : someValuesFrom r d f : r e s o u r c e = ' ' B u i l d i n g ' '/ > </owl : R e s t r i c t i o n > </ r d f s : subClassOf > <r d f s : subClassOf > <owl : R e s t r i c t i o n > <owl : on Pr operty r d f : r e s o u r c e = ' ' applyFor ' '/ > <owl : someValuesFrom r d f : r e s o u r c e = ' ' User ' '/ > </owl : R e s t r i c t i o n > </ r d f s : subClassOf > <r d f s : subClassOf > <owl : R e s t r i c t i o n > <owl : on Pr operty r d f : r e s o u r c e = ' ' h a s C o n d i t i o n ' '/ > <owl : someValuesFrom r d f : r e s o u r c e = ' ' Co ndit ion ' '/ > </owl : R e s t r i c t i o n > </ r d f s : subClassOf > </owl : C l a s s > . . . Building Ontology Document. with other classes including Building, User and Condition. Figure 6.8 shows the classes of Building Ontology and their hierarchical relationship. An example of the hierarchy between classes of User and Director can be seen in the figure with the arrow starting from User pointing to Director which means Director is a subclass of User and inherits

Figure 6 . 8 :

 68 Figure 6.8: Building Ontology graph. The highlighted blocks in the graph show the hierarchy among class Service and its subclasses. The dotted line with a label presents a property called locatedIn which takes class Room as object meaning a service is located in a room.

  g . ,A p a c h eJ e n a 1 1 n a t i v e l y -s u p p o r t e d r e a s o n e r . A n i n f e r e n c e m o d e l i sc r e a t e dw h i c h t a k e s t h e r e a s o n e r , B u i l d i n g O n t o l o g ya n dt h e G r a p h D a t a b a s ea s i n p u tp a r am e t e r s . D a t a i nt h e f o rmo f r e s o u r c e sa n dp r o p e r t i e sa r et h e nc r e a t e df r omd a t a b a s e . As im p l ec o d el i n ec a nb e u s e dt og e n e r a t ea ne n t a i l e dr e l a t i o n s h i p .S p e c i fi c a l l y ,u s e rJ e n n i f e rw h o i sa n i n s t a n c e o fD i r e c t o r (B u i l d i n g O n t o l o g yc l a s s ,s u b c l a s so fc l a s sU s e r)w o u l db e im p o s e db yt h e U n i v e r s a lH e a t i n g P o l i c y r u l ea sw e l l . T h i s r e a s o n i n g m o d e lh e l p s t o r e d u c e t h ed a t a b a s e s i z ea n dq u i c k l yc o l l e c ta l lr e l a t e dd a t ao fa ne v e n to ru s e rw h i c ha r ea l ln e c e s s a r y f o r t h es e r v i c ec om p o s i t i o np r o c e s s . 6 . 3 . 3 S em a n t i c C o n t e x t -aw a r eS e r v i c e C om p o s i t i o n R e s i d i n ga t t h eh e a r to f t h ep r o p o s e dBA S , t h eCOM PO S IT ION s u b s y s t em i s i nc h a r g e o fa n sw e r i n gc om p o s i t i o nr e q u e s t sf r om C om p o s i t i o n B r o k e r w i t hr e g a r dt oc o l l e c t e d c o n t e x t i n f o rm a t i o n .I tt h e ng e t sa c c e s st oa l lr e l a t e dr e s o u r c e st oc o o r d i n a t ea p p r op r i a t ed e v i c e s / s e r v i c e st os e r v et h er e q u e s t . P r e v i o u s l y ,B u i l d i n g O n t o l o g ya n d G r a p h D a t a b a s eh a v eb e e nd i s c u s s e dt op r o v i d et h es em a n t i cd a t a b a s e . A l s o ,c o n t e x t i n f o rm a t i o np r o c e s s e db yt h eC o n t e x tP r o c e s s o r i sp a s s e dt ot h ec om p o s i t i o np r o c e s sa st h e i n p u td a t a .I na d d i t i o n ,ad e s c r i p t i o n l a n g u a g e i sd e s i g n e dt od e s c r i b et h ec om p o s i t i o n p l a n sa n dafi v e -s t e pc om p o s i t i o np r o c e s s i sp r o p o s e d t oeffi c i e n t l ya n da c c u r a t e l yc a r r y o u ts e r v i c ec om p o s i t i o n . 1 1 h t t p : / / j e n a . a p a c h e . o r g / 6.3.3.1 Composition Plan Description Language (CPDL) A language called Composition Plan Description Language (CPDL) has been designed to describe composition plans associating with each context. An example of a CPDL document is shown in the Listing 6.5. This document describes a composition plan related to user Jennifer with the context of when she comes in her office (room 803) in the morning. It defines the composite service in that context consisting of four component services Window, Light, CoffeeMaker, and Heater. The actual execution of this plan depends on the context, user, localtion, and policies.<?xml v e r s i o n = ' ' 1 . 0 ' ' e n c o d i n g = ' 'UTF-8 ' ' ?> <CSDL xmlns : x s i = ' ' h t t p : / / i t -s u d p a r i s . eu / bas ' ' > <p l a n u s e r=" J e n n i f e r " l o c a t i o n ="Room803" c o n t e x t="MorningCheckin"> < s e r v i c e s t a t u s ="on">Window</ s e r v i c e > < s e r v i c e s t a t u s ="on">Light </ s e r v i c e > < s e r v i c e s t a t u s ="on">CoffeMaker </ s e r v i c e > < s e r v i c e s t a t u s ="on">Heater </ s e r v i c e > </plan> </CSDL> <xml> Listing 6.5: Composition Plan Description Language (CPDL).6.3.3.2 Service Compositionfive-step service composition process is shown in Figure6.10 which visually depicts six phases of the composition as follows:• Step 1: Collect and process context information • Step 2: Query related policies, make decision to call COMPOSITION • Step 3: Query related services, select services • Step 4: Bind services to their operations • Step 5: Execute operations of services The process starts with an event notified from context collectors when they detect changes in context and send that information in to the Context Processor. This information can be one of the three types of context: User, Device, and Environment. ContextProcessor processes and represents this information in semantic data which are sent to the Composition Broker to decide whether to move on by calling the COMPOSITION or not. In case no action needs to be carried out, the system switch to the sleep mode, otherwise the COMPOSITION is called. Then, resources are collected in the database to support the composition process. Service Selector uses provided context information, F i g u r e6 . 1 0 :F i v e -s t e pc om p o s i t i o np r o c e s s .C PD Ld a t ao f t h eu s e ra t t h a tc o n t e x ta n d i n f e r r e dp o l i c i e s f r om t h eS em a n t i cR e a s o n e r t o s e l e c ta p p r o p r i a t e s e r v i c e sa n dc r e a t eac o n c r e t ed e s c r i p t i o no f t h e r e q u i r e dc om p o s i t e s e r v i c e . S e r v i c eB i n d e r f o l l o w su pb yb i n d i n g w i t ho p e r a t i o n so fs e l e c t e ds e r v i c e sa n d S e r v i c eE x e c u t o rg e t sa c c e s st oS e r v i c eC a c h et oe x e c u t et h a to p e r a t i o n s . 6 . 3 . 4 P r o t o t y p ea n d E x p e r im e n t s W ed e v e l o pS amBA Sp r o t o t y p et o i l l u s t r a t et h eo p e r a t i o no ft h ep r o p o s e ds y s t ema n d t ot e s tt h ef e a s i b i l i t ya n ds c a l a b i l i t yo ft h es y s t em . T h ep r o t o t y p eu s e s D PW S imf o r s im u l a t i n g D PW Sd e v i c e s i na noffi c eb u i l d i n g . A G r a p h i c a l U s e rI n t e r f a c eo nt o po f t h ed e v i c e sr e p r e s e n t i n ga noffi c ep l a na l o n g w i t hi t sa c t o r s : offi c ee q u i pm e n ta n da u s e r w h oc a n m o v ea r o u n dt h eoffi c es p a c et oc h a n g eh e rc o n t e x ta ss h o w n i nF i g u r e 6 . 1 1 . C o n t e x tc h a n g e s i ne n v i r o nm e n ta n dd e v i c e sa r ea c t i v a t e db yu s e rb yfi r i n gd e v i c e e v e n t sp r o v i d e d i nD PW S im . T h eS amBA S c o n s i s t sa l l t h e s y s t em c om p o n e n t sd i s c u s s e d p r e v i o u s l y . B u i l d i n g O n t o l o g y i sd e v e l o p e du s i n gP r o t é g é -OW Le d i t o r ,g r a p hd a t a b a s e i sr e p r e s e n t e d i n N 3 f o rm a t ,a n dt h e COM PO S IT ION m o d u l e sa r ed e v e l o p e d i nJ a v a p r o g r amm i n g l a n g u a g eo na nB u i l d i n gA p p l i c a t i o nS e r v e rw i t h I n t e lp r o c e s s o r2 . 6GH z , 6 GB RAM .I tu s e sJ e n a l i b r a r yf o rs em a n t i cd a t a m a n i p u l a t i o na n dJ e n a i n t e g r a t e d r e a s o n e r f o r i n f e r e n c e f u n c t i o n a l i t i e s .

F i g u r e6 . 1 1 Figure 6 . 12 :

 1612 Figure 6.12: Service selection. Composition time of service selection process as the number of devices increases from 500 to 5000.

Contents

7. 1

 1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.1 Conclusion This dissertation has proposed a new architecture of semantic service provisioning for 6LoWPAN including a design of 6LoWPAN internetworking model with regular IPv6 network, a study on networking performance of 6LoWPAN, algorithms and mechanisms for service provisioning, and two innovative proof-of-concept IoT applications on Web illustrating the integration of the proposed architecture in different application domains. The design and study on networking performance of the 6LoWPAN has shown that end-to-end IP communication is possible for real-life deployment of smart objects. The results suggest that the IP-based IoT protocol stack can be used for even with highly resource-constrained such as sensor nodes with a few Kb of memory. Operating systems such as Contiki OS are providing effective platforms to enable the communication of smart objects. The proposed service provisioning architecture presents a secure, scalable, and reliable method to power IoT applications on Web. The architecture was verified by two IoT applications of ThingsChat and SamBAS on Social IoT and Building Automation domains. For each domain, we evaluated the implementation empirically by means of several prototypes and applications and on different environments: the IoT testbed consisting of MTM-CM5000-MSP TelosB sensor nodes, the Contiki Cooja simulator, and DPthWSim -the open-source DPWS simulator developed within this research. Overall, the results demonstrate that the proposed semantic service provisioning architecture can cope with several challenges and enhance the experience for the development of IoT applications on Web.The work has profound impact on two large-scale European projects: ITEA2 Web of Objects (WoO) 1 and ITEA2 Social Internet of Things -Applications by and for the Crowd (SiTAC)2 . The WoO project addressed specific issues relating to the increasing integration of Internet-connected devices in existing business applications, proposing a modular solution kit to enable the development of industrial and consumer applications with smart objects as actors, across multiple layers from objects to Web-based user applications. The SiTAC project exploits the social networking paradigm in order to facilitate and unify interactions both between people and devices and between devices.It provides a distributed framework for enabling the Web-based service representation of smart spaces and the objects they include.

F i g u r e A . 1 :

 1 Ah om es p a c ec o n t a i n st h r e ed e v i c e s : ag e n e r i c D PW S imd e v i c e( b l u e b u t t o n ) ,a l i g h tb u l b ,a n dac o ff e e m a k e r . As t a n d -a l o n ed e v i c e( s p a c e w i t ho n l yo n e d e v i c e ) i sa l i g h tb u l b . a n dc omm u n i c a t i o nd a t a( e . g . ,s e r v i c e i n v o c a t i o nc omm a n d ss e n t f r omc l i e n t s ) . W eu s e an um b e ro fh a r dw a r ei n c l u d i n gIBM PC s , R a s p b e r r y P i ,a n d T e l o s Bs e n s o rn o d e s t ob u i l dr e a l -l i f ed e v i c e ss u c ha st h e rm o s t a t s , m o t i o nd e t e c t o r s ,a n dTV st or e c o r dh o w t h e s ed e v i c e sw o r k i n s e v e r a l s c e n a r i o s i no r d e r t om im i c t h e i rb e h a v i o r s i n t h e s im u l a t o r . D PW S imb u i l d s s im u l a t e dd e v i c e s r e g a r d i n ga l l l a y e r so f t h eTC P / I Pn e t w o r k i n g m o d e l [ 8 0 ] . A tt h en e t w o r ki n t e r f a c el a y e r ,t h er e l i a b l e E t h e r n e tl i n ko ft h eh o s t m a c h i n e i sc o n s i d e r e dt of o c u so nt h e D PW Sp r o t o c o l m e s s a g e sa n d m e c h a n i sm sr a t h e rt h a n p h y s i c a l i s s u e s( e . g . ,r a d i o i n t e r f e r e n c e ) . A ta p p l i c a t i o n l a y e r ,e a c h D PW S imd e v i c e i s m o d e l e da sa l i s to fs e r v i c e s( e v e n t sa n do p e r a t i o n s )b i n d i n gt oa n I Pa d d r e s s( i n t e r n e t l a y e r )o v e rUD P( t r a n s p o r t l a y e r ) .E v e n t sh a p p e np e r i o d i c a l l ya f t e ra n i n t e r v a lo ft im e o r m a n u a l l yv i au s e r i n t e r a c t i o n ;o p e r a t i o n sa r es o f t w a r ec om p o n e n t sr e c e i v i n g i n p u t , p r o c e s s i n g i t ,a n dp r o d u c i n go u t p u t(w i t h i t ss t a t u su p d a t e da n ds e n tt ot h e i n v o k e r ) .O nt o po ft h a t ,d e v i c es t a t u sa n do u t p u t so fe v e n t s / o p e r a t i o n sa r e m o d e l e da sg r a p hi c a lr e p r e s e n t a t i o n s . W h e n i tc om e st o m o d e l i n ga n ds im u l a t i n gr e a l D PW Ss y s t em s , D PW S imc a ns u p p o r ts t e p s i n v o l v i n g m o d e l i n g ,d e s i g n i n ge x p e r im e n t ,a n dp e r f o rm i n g a n a l y s i so ft h ed i s c r e t e -e v e n ts im u l a t i o n [ 8 1 ] . D PW S imh a s f o u rb a s i c c om p o n e n t sn am e l yS p a c e s ,D e v i c e s ,O p e r a t i o n s ,a n dE v e n t s .As p a c ec o n t a i n ss e v e r a ld e v i c e s ;e a c hd e v i c eh a sa l i s to fo p e r a t i o n sa n de v e n t s .S p a c e sAs p a c ei sav i r t u a le n v i r o nm e n tr e p r e s e n t i n gar e a l -l i f es e t t i n gi n w h i c h D PW S im d e v i c e sr e s i d e i n .I tc a nb eah om e ,a noffi c e ,at r a i ns t a t i o n ,ap u b l i cs p a c e ,o rs im p l y as t a n d -a l o n ed e v i c e . F i g u r eA . 1 i l l u s t r a t e sah om es p a c ec o n t a i n i n gt h r e ed e v i c e sa n d as t a n d -a l o n ed e v i c e .

DevicesA

  device refers to both DPWS hosting service and hosted service. Since these two kinds of services, in reality, share similar characteristics, they are used interchangeably in DPWSim for simulation purpose. It contains two different endpoint addresses used for each type of services. For example, when taking part in the discovery, it uses the device endpoint address; when invoking an operation, it uses the service endpoint address.

  device state. When the device state changes (or an event happens), it notifies subscribed clients by sending notification messages. An event can happen periodically (i.e., it happens frequently after an interval of time such as sensing CO2 level every 15 minutes) or manually (i.e., it is invoked by users). This property can be set in the Device Control Panel as shown in Figure A.2. A.2 DPWSim Components A.3 DPWSim Core Functionalities DPWSim provides simulation tools to help researchers and developers to build IoT applications consuming DPWS services. DPWSim can support users to create virtual environments from a simple to a complex one, even a graphically-rich interface like in the Figure A.5 with the aid of external computer graphics software and design skills. DPWSim acts as a dynamic mediator to generate different types of simulation meanwhile maintaining the DPWS functionalities.

F i g u

  r eA . 2 : D PW S imGU Ic om p o n e n t s :ad i a l o gw i n d o w ( L i n u xO S ) ,a m e n ub a r (M a c O S ) ,a n dac o n t e x t m e n u(W i n d o w s O S ) .c om p o s i t ee n v i r o nm e n t t oh o s ts e v e r a ld e v i c e s .I t i sc r e a t e db yu s i n gap l a n im a g es u c h a soffi c e ,h om e ,a n da i r p o r t . As t a n d -a l o n ed e v i c e i ss im p l ya D PW S imd e v i c ew i t ha h o s t e ds e r v i c ec o n t a i n i n go p e r a t i o n sa n de v e n t s . T h i sk i n do fv i r t u a le n v i r o nm e n tc a n b es t o r e d i nfi l ea n dr e -u s e d i no t h e rv i r t u a le n v i r o nm e n t s .N ew D e v i c e D e v i c e sc a nb ec r e a t e db y s e v e r a lw a y s ,e a c h i sa s s o c i a t e dw i t ha s u bm e n uo f t h eDe v i c e m e n ui n D PW S im : A d d N ew( n ewu s e r -c u s t om i z e dd e v i c e s ) , A d d P r e d e fi n e d( p r ec o n fi g u r e dd e v i c e sb y D PW S im ) , A d dF r omF i l e( im p o r t i n gd e v i c e f r oms a v e dd e v i c e d e s c r i p t i o n ) ,a n d G e n e r e a t ef r om P h y s i c a l D e v i c e( c r e a t i n gn ewd e v i c eb y m a p p i n g f u n c t i o n a l i t i e sf r omar e a ld e v i c et oas im u l a t e do ne ) . U s e r sc a nf u r t h e rc u s t om i z e p h y s i c a ld e v i c ep r o p e r t i e st ofi tan ewd e v i c e . T h i sc a p a b i l i t y i se s p e c i a l l yu s e f u lw h e n d e v e l o p e r s w a n tt of o c u so nd e s i g n i n gt h eb u s i n e s s l o g i co fa nI oTa p p l i c a t i o nr a t h e r t h a nt h ep h y s i c a lpe r f o rm a n c eo fd e v i c e s . D e v i c e M a n a g em e n t O n c ead e v i c eh a sb e e nc r e a t e dw i t h i nav i r t u a le n v i r o nm e n to ra sa s t a n d -a l o n ed e v i c e , i tc a nb eq u e r i e d f o r D PW S i n f o rm a t i o n ,r e -l o c a t e d ,d e l e t e d ,o rs a v e d f o r f u t u r eu s e s . S im i l a r l y ,av i r t u a le n v i r o nm e n t i n c l u d i n g i t sd e v i c e sc a nb es a v e d i nt h efi l es y s t em f o r b e i n gs h a r e dam o n gc o -w o r k e r s . D e v i c es e r v i c e sc a nb ec h a n g e do n c ec r e a t e dt h r o u g h t h e D e v i c e C o n t r o l P a n e la s s o c i a t e dt oe a c hd e v i c ea ss h o w ni nt h e F i g u r e A . 2 . I t p r o v i d e sa n im p o r t a n ta p p r o a c h f o rd e v e l o p e r st oc h a n g ed e v i c e f u n c t i o n a l i t i e sd u r i n g t h ed e v e l o pm e n tp r o c e s sw i t h o u tr e -c r e a t i n gt h ed e v i c e .

F i g u r e A . 3 :

 3 D PW SE x p l o r e rd i s c o v e r sa D PW S imd e v i c eT e r r a c e L i g h t c o n t a i n i n ga n e v e n tM o t i o nD e t e c t i o n a n da no p e r a t i o nS w i t c h . T h eg r e e n i c o nn e x t t o t h e M o t i o nD et e c t i o ne v e n t i n d i c a t e st h a tD PW SE x p l o r e r i ss u b s c r i b i n gt ot h ee v e n t ;o n c et h ee v e n t o c c u r s ,D PW SE x p l o r e rw i l lr e c e i v et h en o t i fi c a t i o n ,e . g . ,O b j e c td e t e c t e d .

F i g u r e A . 4 :

 4 Au s e rc a nt u r no nt h e l i g h tb u l b K i t c h e n L i g h tb y i n v o k i n g i t sSw i t c hO n o p e r a t i o nv i at h esm a r t p h on e W e b i n t e r f a c eo fD PW S im W e b . DP W S E x p l o r e r D PW SE x p l o r e r i sa na n a l y z i n gt o o lf o r D PW Sc om p l i a n ts e r v i c e s .I tv i s u a l i z e sv a ri o u sa s p e c t so fb o t hh o s t i n ga n dh o s t e ds e r v i c e sl i k e m e t a d a t ao r m e s s a g ee x c h a n g e a n dp r o v i d e sc a p a b i l i t i e st oc a l lo rs u b s c r i b et od e v i c es e r v i c e sa n de v e n t s .I t i su s e d t op r e v i ew D PW Ss e r v i c e sd u r i n gt h ed e v e l o pm e n tp r o c e s s . D PW S imd e v i c e sc a nb e d i s c o v e r e d ,t h e i ro p e r a t i o n sc a nb e i n v o k e d ,a n dt h e i re v e n t sc a nb es u b s c r i b e df r om D PW SE x p l o r e r . F i g u r e A . 3s h o w sh o w D PW SE x p l o r e rr e t r i e v e sd a t aa n d i n t e r a c t s w i t haD PW S imd e v i c e .DP W S im W e b D PW S im W e b i sa sm a l l W e ba p p l i c a t i o n i n c l u d e d i n t h e r e l e a s eo fD PW S im t o i l l u s t r a t e a nu s ec a s ew h e na W e ba p p l i c a t i o n i n t e r a c t sw i t h D PW S imd e v i c e s .I t i saJ a v a W e b a p p l i c a t i o nr u n n i n go n A p a c h e T om c a ta p p l i c a t i o n .I tc a nd i s c o v e ra v a i l a b l e D PW Sd e v i c e so nt h en e t w o r ka n dr e t r i e v et h e i r m e t a d a t a . F o l l o w i n gt h e s ed a t a ,u s e r sc a n i n v o k ed e v i c eo p e r a t i o n st oc a r r yo u tt h e i rt a s k s . F i g u r eA . 4s h o w s D PW S im W e bv i a F i g u r e A . 5 : Av i r t u a lh om eh o s t i n gs e v e r a l D PW Sd e v i c e s i sd e s i g n e du s i n g D PW S im w i t ht h eh e l po fa3Da r t i s t( S aH o a n g f r om É c o l eN a t i o n a l eS u p é r i e u r ed 'A r c h i t e c t u r e d eP a r i sL aV i l l e t t e -EN SA P L V ) .

  h e b u t t o n s . R e s e a r c h P r o j e c t s D PW S imh a sb e e nu s e dw i t h i nIT EA 2 W e bo f O b j e c t s(W oO )p r o j e c tt os u p p o r tt h e d e v e l o pm e n to fa n i n c i d e n tm a n a g em e n t s c e n a r i o f o r t e s t i n g t h e c o n t e x t u a lo b j e c t c o l l a bo r a t i o n . D PW S imh a sb e e nu s e dt h r o u g h o u tt h ed e v e l o pm e n tt od e s c r i b et h ec omm o n i n t e r f a c e f o r t h ec o o p e r a t i o nb e t w e e nd e v i c e su p o n t h ea s s i g n e d r i g h t sa n d s p e c i fi c r u l e s im p o s e di nt h e w h o l es y s t em . A ne x am p l eo ft h eh om ee n v i r o nm e n tc r e a t e df o rt h e p r o j e c t i ss h o w n i nF i g u r e A . 5 . T h eh om ec o n s i s t so fs e v e r a l D PW Sd e v i c e ss u c ha sa TV , l am p s ,a n dac o ff e e m a k e r . W i t ht h eh e l po fa3Da r t i s t ,i tp r o v i d e sa ne l e g a n t s im u l a t i o nu s i n gD PW Sp r o t o c o l s . B e s i d e s ,D PW S imh a sb e e n t h u s f a ru s e d i n s e v e r a l I oT s t u d i e s s u c ha s t h e s em a n t i c b u i l d i n ga u t om a t i o ns y s t em[ 8 2 ] ,s o c i a ld e v i c en e t w o r k i n g[ 8 3 ] ,a n d R E STp r o x yf o r D PW S [ 8 4 ] . D PW S im i sh o s t e db y W oOp r o j e c ta n d i t ss o u r c ec o d e i s m a i n t a i n e do n a G i tH u br e p o s i t o r y( h t t p : / / g i t h u b . c om / s o n h a n / d p w s im . )

  4, Chapter 5, and Chapter

	Chapter 2
	Literature Review

Contents 2.1 IoT Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Link and Adaptation Layers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Internet Layer: Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.4 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Service Provisioning in IoT . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 General Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 SOA-based Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 RESTful Service Provisioning . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Semantic Annotation and Provisioning . . . . . . . . . . . . . . . . 14 2.4 Literature Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

  The IoT protocol stack is contributed not only by research results from academia but also from standardization bodies such as Internet Engineering Task Force (IETF), Institute of Electrical and Electronics Engineers (IEEE), and European Telecommunications Standards Institute (ETSI).The IoT protocol stack extends four layers of the TCP/IP model (RFC 1122: Link, Internet, Transport, and Application) with the new Adaptation layer, which is required for smart objects to adapt the small frame size of the low-power link layer to the much larger size of IPv6 packets. Adaptation layer defines mechanisms and protocols for header compression/decompression to enable the use of IPv6 on low-power links of smart objects. Table2.1 summaries common protocols for each of the five layers which are elaborated more in the following sub sections.

Table 2 .

 2 1: IoT Networking Protocol Stack .15.4 MAC Protocol Data Unit (MPDU), the use of a 40-byte IPv6 header would be too excessive. The IETF 6lowpan WG, therefore was formed to work on the IPv6 protocol extensions required for such networks where hosts are interconnected

	Layer	Protocols
	Application HTTP, CoAP, DPWS, XMPP, MQTT, AMQP, CoSIP
	Transport	TCP, UDP, SCTP, ICMP, DTLS
	Internet	IPv6, RPL
	Adaptation 6LoWPAN, 6TiSCH, IPv6-over-foo
	Link	IEEE 802.15.

4

, BLE, PLC, DECT, Low-power Wi-Fi, ITU-T G.9959

2.1.1 Link and Adaptation Layers

IPv6 resides at the center of the IoT protocol stack for the interconnection between smart objects and existing services on the Internet. IPv6 with its inconceivably-large address space is foreseen to be available on a wide variety of different Link layer technologies meeting a wide variety of communication requirements such as wired or wireless, short or long range, and high or low data throughput. Almost all types of communication links can support IP-based communication, therefore potentially operable for smart objects where the low-power requirement is the key for designing the networking models. There are several link layer technologies that are being developed for smart objects such as IEEE 802.15.4, Bluetooth Low Energy (BLE), Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy, and ITU-T G.9959. Each of these link protocol has its corresponding adaptation layer technology, for example IPv6 over The IPv6 protocol has a high overhead and restrictions that make it unsuitable for low-power or constrained networks such as IEEE 802.15.4 networks. For example, considering the limited space available for the Medium Access Control (MAC) payload in an 802The IEEE 802.15.4e Timeslotted Channel Hopping (TSCH) is a recent amendment to the MAC portion of the IEEE 802.15.4 standard. As a result the 802.15.4e timeslotted channel hopping MAC differs fundamentally from the Carrier Sense Multiple Access (CSMA) MAC found in standard 802.15.4. In short, TSCH allows for more controlled and deterministic network access as opposed to CSMA, while also offering increased resiliency to interference via channel hopping. TSCH MAC protocols are therefore commonly used in industrial applications.

2.1.2 Internet Layer: Routing Due to the distinctive characteristics of 6LoWPAN (e.g., low energy availability, throughput, reliability, availability, and processing capabilities), it has specific routing requirements (RFC 5867, RFC 5826, RFC 5673, and RFC 5548) that differ from those found in traditional IP networks. The IETF roll WG focuses on building routing solutions for 6LoWPANs as the result of the evaluation of existing routing protocols like Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Ad hoc On-Demand Distance Vector (AODV), and Optimized Link State Routing (OLSR) indicating that they do not satisfy all of the specific routing requirements (draft-ietfroll-protocols-survey). The working group focuses on an IPv6 routing architectural framework while also taking into account high reliability in presence of time varying loss characteristics and connectivity with low-power operated smart objects with limited memory and CPU in large scale networks. The main realization of this working group is the design of Routing Protocol for Low-Power and Lossy Networks (RPL) which provides a mechanism to support multipoint-to-point traffic from smart objects inside 6LoWPAN towards a central control point as well as point-to-multipoint traffic from the central control point to the smart objects inside the 6LoWPAN. Within the constrained parts of the network, the RPL offers a uniform and efficient method for realizing multihop networks.

  oriented IoT deployments, which is able to represent, discover, detect, and compose services at edge nodes. The purpose is to develop an effective architecture for service Many other studies[START_REF] Zhiquan | Data mashup in the internet of things[END_REF],[START_REF] Avilés-López | Mashing up the internet of things: a framework for smart environments[END_REF],[START_REF] Kenda | Mashups for the web of things[END_REF] also find their ways to explore this trend over sensor nodes and embedded devices.

	Besides, many IoT platforms have been developed to support the development of
	IoT applications tend to approach RESTful service provisioning of smart objects. As
	can be seen in the Table 2.2, these platforms mainly aim at integrating smart objects of
	different types into the Web through RESTful APIs. These platforms provide mid-point
	services to encapsulate underlying heterogeneous smart objects into Web interfaces that
	can further integrate into modern Web infrastructures such as cloud and platform-as-
	a-service (PaaS). These approaches expose some difficulties to scale IoT systems since
	each platform has to handle routing discrepancy and protocol translation.
		Table 2.2: IoT Platforms
	Platform	Smart Objects	Service Abstraction

operations in the IoT by extending existing architectures over smart things that are connected to the Internet via heterogeneous access networks and technologies (such as sensor networks, mobile networks, and RFID). The framework has three layers: application layer is connected with a business process modeling component for IoT business process; network layer contains several components to provide the functionalities required by services for processing information and for notifying application software and services about events related to the resources and corresponding virtual entities; sensing layer involves the sensing devices such as RID tags and smart sensors which can record, monitor, and process observations and measurements. The network layer can communicate to the sensing layer with device-level APIs.

2.2.3 RESTful Service Provisioning

Web resources identified by Universal Resource Identifiers (URIs) are considered as the core of modern Web architecture. They are accessed by clients in a synchronous request/response fashion using Hypertext Transfer Protocol (HTTP) methods such as GET, PUT, POST, and DELETE. Resource state is kept only by the server, which allows caching, proxying, and redirection of requests and responses. Web resources may contain links to other resources creating a distributed Web between Internet endpoints, resulting in a highly scalable and flexible architecture. These are the fundamental concepts of the Web, i.e., Representational State Transfer (REST)

[START_REF] Fielding | Principled design of the modern web architecture[END_REF]

. REST has emerged as a predominant Web design model with more than ten thousand RESTful APIs (services) at the time of this article

[START_REF]Programmableweb[END_REF]

.

The RESTful service abstraction advocated by many researchers and professionals is an essential step to provision services in IoT systems. Guinard et al. in several studies

[START_REF] Guinard | Towards physical mashups in the web of things[END_REF][START_REF] Guinard | Towards the web of things: Web mashups for embedded devices[END_REF][START_REF] Guinard | Mashing up your web-enabled home[END_REF][START_REF] Guinard | Giving rfid a rest: building a web-enabled epcis[END_REF][START_REF] Guinard | Cloud computing, rest and mashups to simplify rfid application development and deployment[END_REF][START_REF] Guinard | Restifying real-world systems: A practical case study in rfid[END_REF]

present a continuous effort to integrate smart objects of different forms ranging from RFID, to WSNs, to embedded systems, to the Web by representing their data and events using RESTful APIs via device gateways. Based on that, authors develop two approaches for mashup: Physical-Virtual and Physical-Physical in a number of applications.

Table 4 .

 4 1: Battery powered smart object lifetime for IP connectivity.ware for the sake of energy consumption. Many IoT devices such as home appliances and sensor nodes only transfer control data with few bytes then this rate is adequate for most IoT applications containing relatively simple service communication. When considering new application ideas, system designers are expected to take into account the transfer rate to make a right choice for the network deployment.The operation of uIP networking stacks in Contiki OS 3.x appears reliable in our intensive experiment with packets sending for a period of 24 hours. Compared to previous releases, our experience with Contiki OS 3.x indicates that IP performance has been improved considerably. Besides, there are several useful libraries with Contiki OS such as Erbium CoAP, Web server, file system, and Shell. Contiki OS programming experience is very effective with protothreads for multi-threading and event-driven applications. Our experience suggests Contiki OS is very robust and can be the universal operating system for smart objects.

	5 www.w3.org/TR/ws-metadata-exchange/
	6 www.w3.org/Submission/WS-Transfer/

7

www.w3.org/Submission/ws-addressing/ 8 www.w3.org/TR/soap12-mtom/ 9 http://schemas.xmlsoap.org/ws/2005/04/discovery/ 10 www.w3.org/Submission/WS-Policy/ 2.3 years can be considered to be the very long for just only two AA batteries to maintain the connectivity. Similarly, Table

4

.1 illustrates the estimated battery life of smart objects in some cases: idle (duty cycling) and continuously sending packets with the data rate from 1 to 5 packet/s in two modes (host and router ). With the average duty cycle remains lower than 0.5 percent when objects are idle, the connectivity of 6LoWPANs is still maintained meanwhile energy consumption is kept minimal. Even in case of continuously sending data with very high data rate of 5 packet/s, two AA batteries can provide enough power for about 2.5 months. obvious trend of much lower PDR. This is identified as the result of the RPL routing protocol. More investigation is expected to figure out the cause of the packet loss. The data transfer rate at around 25 kbit/s is considered low-rate due to the sacrifice of hard-

  There are several candidate protocol for application layer in IoT including HTTP, CoAP, DPWS, XMPP, MQTT, and AMQP. Among which, DPWS and CoAP are mostly close to common Web architecture aiming to bring functionalities of smart objects (data and events) to the Web in the form of services. By following Web design principles (REST, SOA), these services can acquire open Web standards to enable them to understand the Web languages and protocols, denoted as smart object services.CoAP follows REST architectural style, compromising a minimal subset of REST along with mechanisms of resource discovery, subscription/notification, and security measures for smart objects. It is similar to HTTP and can be easily translated to HTTP for a transparent integration with the Web, while having very low overhead.It also supports multicast and publish/subscribe model. The CoAP protocol provides a technique for discovering and advertising resource descriptions via CoAP endpoints using CoRE Link Format (RFC 6690) of discoverable resources. As standardized by IETF, CoAP is showing suitable for smart objects as well as getting attention from the community. There are many CoAP implementations available not only for smart objects (e.g., Erbium 12 for Contiki OS, libcoap for TinyOS, and SMCP 13 for embedded systems) but also for powerful servers (e.g., Java Californium 14 ), Web browser (e.g.,

Copper

15

), and mobile platform (e.g., nCoAP). The Erbium implementation, according to our experiments, exposes very low overhead and supports well multicast as well as publish/subscribe model. This protocol is showing an excellent choice to meet eventdriven requirements from IoT application. A secure mechanism for CoAP transaction is expected to explored more to make it widely usable in real-life applications. DPWS, on the other hand, is the lightweight version of W3C Web Service

[7]

in addition to new features such dynamic discovery and event notification. Even though DPWS use XML-based SOAP envelopes (something considered bulky), our experiment

Table 4 .

 4 consist of smart objects in the radio range of the edge router can cover the area of 707 m2 in good radio signal. That area can comfortably cover typical 2-storey houses. Table4.2 shows more details about the estimated ranges in different facilities that 6LoWPAN can give healthy radio coverages. In most cases of average houses and offices, IEEE 802.15.4 can comfortably maintain a stable connectivity. 2: IEEE 802.15.4 Radio Range.

	Node Type Range Area Typical facilities
		(m)	(m2)
	1-hop	15	707	large, two-storey houses
	2-hop	30	2827	medium building floors
	3-hop	45	6362	large building floors

12

http://people.inf.ethz.ch/mkovatsc/erbium.php 13 https://github.com/darconeous/smcp/ 14 http://people.inf.ethz.ch/mkovatsc/californium.php 15 http://people.inf.ethz.ch/mkovatsc/copper.php 16 http://ws4d.org/udpws/

  When the Scheduling process starts, it checks the request queue again, removes the head request (first in the queue), adds this request to another queue called sent queue, and sends the request accordingly to the target smart object. The QuantumAssertion keeps track of the sent queue to see if a request has waited for too long to adjust the quantum time. The ResponseObserver process forwards the received response messages from smart objects to clients and updates the sent queue.

	5.2.3 Semantic Annotation
	<r d f :RDF
	xmlns : r d f ="h t t p : / /www. w3 . o r g /1999/02/22 -r d f -syntax-ns#"
	xmlns="h t t p : / /www. i t -s u d p a r i s . eu / s e n s o r#"
	End
	END
	PROCESS QuantumAssertion
	BEGIN
	I f sentQueue i s not empty and top o f queue i s o v e r t i m e
	Adjust quantumTime
	E l s e
	R e s e t quantumTime
	END
	PROCESS R es po nse Ob se rv e r
	BEGIN
	I f t h e r e i s a r e s p o n s e
	Remove from sentQueue
	Get c l i e n t i d
	Forward t o c l i e n t
	END
	Listing 5.3: Scheduling algorithm.
	The RequestHandling process receives coming HTTP requests via the provisioned
	Web API and check if each request arrives in a reasonable interval. If a request arrives

too fast (less than a quantum time after the nearest recored request), it will be added to a request queue (based on a queue data structure

[START_REF] Cormen | Introduction to Algorithms[END_REF]

). The Scheduling process keeps track of the request queue and it is activated when there are waiting requests in the queue. xmlns : ns0="h t t p : / /www. w3 . o r g /2000/01/ r d f -schema#" > xmlns : ns1="h t t p : / / pur1 . o c 1 c . o r g /NET/ s s n x / s s n#" <r d f : D e s c r i p t i o n r d f : about="h t t p : / /www. i t -s u d p a r i s . eu / s e n s o r#Temp5">

Table 5 .

 5 4: Base URI mapping with DPWS

	Endpoint address	urn:uuid:46932240-d504-11e3-bf6a-6eabe38b6788
	Transport address	http://[aaaa::212:7400:13cc:3693]:4567/thermostat
	Service	getTemp()
	Provisioning server 157.159.103.50
	Scheme 1 URI	http://157.159.103.50/thermostat/temp
	Scheme 2 URI	http://157.159.103.50/[aaaa::212:7400:13cc:3693]/temp
	5.2.6 Web API Generation

Web API Generator is in charge of generating a set of Web API associated to each smart object service. The process is based on above URI mapping scheme. The API consists of endpoints for discovery, subscription, and service calls in Representational State Transfer (REST) architectural style

[START_REF] Fielding | Principled design of the modern web architecture[END_REF]

. To generate these RESTful Web APIs, we can extract directly from CoAP URI as CoAP and HTTP basically use the same REST concept.

Table 5 .

 5

	5: CRUD operation mapping scheme
	Prefix	CRUD Action HTTP Verb
	Get-	READ	GET
	Set-	UPDATE	PUT
	Add-	CREATE	POST
	Remove-DELETE	DELETE
	Web APIs are the core of the development of applications on Web these days pro-
	viding interfaces for developers to develop applications on Web. Web APIs are specifi-
	cations that define how to interact with software components, particularly, allow access
	to remote Web resources via a communication network. The benefits for developers
	in adopting Web APIs are: easy to enrich functionality, simple and quick to integra-
	tion, and leverage brand strength of established partners. Even in the new platform of

smartphone applications, we can already see that the use of Web APIs is prevalent. Our provisioning Web API consists of API endpoints represented in the following format (see

Table 5.6)

, which is used consistently in this dissertation:

  These features, secure Web services, dynamic discovery, and eventing, are the main advantages of DPWS for event-driven IoT applications. Nevertheless, in fact, developers would face several problems when applying DPWS for IoT applications on Web. The main concern is about the dynamic discovery in which the network range of UDP mul-We will follow an IoT engineer Rosalie's development process to understand what challenges she could encounter when developing, deploying, and interacting the smart object from her IoT application and how the proxy helps her to solve these problems.

	To solve these problems, we design a service provisioning mechanism for DPWS
	using a REST proxy by providing the following features: (1) global dynamic discovery
	using WS-Discovery in local networks; (2) proxy-based topology for publish/subscribe
	eventing mechanism; (3) dynamic addressing for DPWS smart objects; (4) RESTful
	Web APIs; and (5) WSDL caching. The proxy unburdens Internet traffic by processing
	the main load in local networks. Also, the proxy can extend the dynamic discovery

ticast messages is limited to the local subnet. Therefore, it is impossible to carry out this mechanism in a large network such as the Internet. With WS-Eventing, the establishment of separate TCP connections in case of delivering the same event notification to many different subscribers will generate a global mesh-like connectivity between all devices and subscribers (see

Figure 5.5)

. This requires high memory, processing power, and network traffic and thus consumes a considerable amount of energy in devices. Another issue is the overhead due to the data representation in XML format and multiple bidirectional message exchanges. It is not a problem when most DPWS devices currently communicate locally, but in a mass deployment of devices, these messages would generate heavy Internet traffic and increase the latency in device/application communication. Furthermore, W3C Web services use WSDL for service description and SOAP for service communication; the former, despite the fact that it is a W3C standard, requires much effort from developers to process poorly-structured XML data; the latter is mostly common in stateful enterprise applications, whereas recent Web applications are moving toward the core Web concepts expressed in REST architectural style by offering stateless and unified interfaces of RESTful Web APIs. from locally to globally through RESTful Web APIs. Developers do not have to parse complex WSDL documents to get access to service descriptions; they can use RESTful Web APIs to control smart objects.

Table 5 .

 5 9: RESTful Web API for the heater

	RESTful Web API	DPWS operations Argument Discription
	GET /discovery PUT /discovery	Discovery	search	List smart objects Search for smart objects
	POST /heater/overheat eventOverHeat()		Subscribe to an event
	GET /heater	GetStatus()		Get heater status
	PUT /heater	SetStatus(String)	status	Set heater status
	GET /heater/temp	GetTemp()		Get room temperature
	PUT /heater/temp	SetTemp()	temp	Adjust heater temperature
	POST /heater/rules	AddRule	rule	Add new rule
	GET /heater.rules	GetRules()		List of rules
	DELETE	RemoveRule()	ruleID	Delete a rule
	/heater/rules/[ruleID]

  Composition Plan Description Language (CPDL) . . . . . . 89 6.3.3.2 Service Composition . . . . . . . . . . . . . . . . . . . . . . . 89 6.3.4 Prototype and Experiments . . . . . . . . . . . . . . . . . . . . . . . . 90 6.4 Implementation Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 92

Contents 6.1 Devices Profile for Web Services . . . . . . . . . . . . . . . . . . . . 73 6.2 ThingsChat: A Social Internet of Things Platform . . . . . . . . . 74 6.2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.2.2 Socialized Web API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.2.3 ThingsChat Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.2.4 Prototype and Experiment . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3 SamBAS: A Building Automation System . . . . . . . . . . . . . . 81 6.3.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.3.2 Building Ontology and Graph Database . . . . . . . . . . . . . . . . . 84 6.3.2.1 Context-Awareness . . . . . . . . . . . . . . . . . . . . . . . 85 6.3.2.2 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.3.2.3 Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.3.3 Semantic Context-aware Service Composition . . . . . . . . . . . . . . 88 6.3.3.1

Table 6 .

 6 .1. DPWS-gSOAP provides C/C++ toolkits for deploying Web services consumers and providers. It is multi-platform implementation supporting Windows-native, Windows-cygwin, Linux, and Embedded Linux. DPWS-uDPWS is DPWS implementation in C language designed for Embedded Linux, Contiki and especially for highly resource-constrained devices such as sensor nodes. DPWS-JMEDS is Java framework for DPWS supporting different Java editions. The latest release of DPWS-JMEDS hosts the feature of Android OS which paves the way for implementing services on Android devices. 1: DPWS Implementation.

	Version	Language Operating System
	DPWS-gSOAP	C	Linux, Windows, Embedded Linux
	DPWS-uDPWS C	Embedded Linux, Contiki
	DPWS-JMEDS Java	Java Virtual Machine
	DPWS-Android Java	Android

Table 6 .

 6 3: ThingsChat Device Adapter Web API Virtual Home is created by DPWSim to precisely generate DPWS protocol messages for each devices. DPWSim also helps creating rich graphical user interfaces for the simulation environments (see Figure 6.4 for an example of such interface with the help of an 3D artist). DPWS devices can be discovered and communicated by DPWS clients following DPWS standards. ThingsGate is a Java Web application running on an Apache Tomcat server 6 . ThingsChat is based on phpBB Social Network Engine providing all basic features of an OSN such as profiles, friends, and sharing. It also has a WUI to allow people and devices to talk. An NLP Service uses Apache OpenNLP 7

	Web API Endpoint	Arguments Description
	POST /socialnet/chat-to-user.php	device-id	Send message to a user
		post-id
	POST /socialnet/confirm-friend.php device-id	Confirm making-friend request
		user-id
	GET /socialnet/nlp.php	content	Get natural language translated
			to device code
	6.2.4 Prototype and Experiment
	ThingsChat application consists of four components: Virtual Home (powered by DP-
	WSim), provisioning server ThignsGate, SIoT platform ThingsChat, and an external
	NLP Service.

  <r d f :RDF xmlns = ' ' h t t p : / /www. i t -s u d p a r i s . eu / b a s o n t # ' ' xml : b a s e = ' ' h t t p : / /www. i t -s u d p a r i s . eu / b a s o n t ' ' xmlns : r d f s = ' ' h t t p : / /www. w3 . o r g /2000/01/ r d f -schema # ' '

	xmlns : owl = ' ' h t t p : / /www. w3 . o r g /2002/07/ owl # ' '
	xmlns : xsd = ' ' h t t p : / /www. w3 . o r g /2001/XMLSchema# ' '
	xmlns : r d f = ' ' h t t p : / /www. w3 . o r g /1999/02/22 -r d f -syntax-ns # ' '
	xmlns : xml = ' ' h t t p : / /www. w3 . o r g /XML/1998/ namespace ' ' >
	<owl : Ontology r d f : about = ' ' h t t p : / /www. i t -s u d p a r i s . eu / bas ' '/ >
	. . .
	<!--h t t p : / /www. i t -s u d p a r i s .
	1 0 h t t p : / / p r o t e g e . s t a n f o r d . e d u /

  Device Context, and Environment Context. The context data then are sent to Composition Broker which plays the role as a composition decision maker. It decides whether to call the COMPOSITION or not based on data defined in policy. For example, if the context information of room temperature is over 10 degree Celsius, no composition will be carried out otherwise Composition Broker checks the temperature with current status of the system to launch the COMPOSITION in case the situation is labeled as

	a bdg : D e v i c e C o n t e xt ;
	bdg : happenIn : Room803 ;
	bdg : h a s A c t o r : CoffeeMaker803 ;
	bdg : time " 2 0 1 5 : 0 4 : 2 6 1 5 : 4 9 " .
		Listing 6.3: Context Data.
	Listing 6.3 illustrates three pieces of context data for each type of context: User
	Context, context change.	F i g u r e6 . 9 : R e a s o n i n ge x am p l e .
	6.3.2.2 Policy
	: U n i v e r s a l H e a t i n g P o l i c y
	a bdg : O p e r a t i o n P o l i c y ;
	: Context1430042727831 bdg : applyFor bdg : User ;
	a bdg : UserContext ; bdg : h a s C o n d i t i o n : H e a t i n g C o n d i t i o n .
	bdg : happenIn : Room803 ; : H e a t i n g C o n d i t i o n
	bdg : h as A c t o r : J e n n i f e r ; a bdg : C o n d i t i o n ;
	bdg : time " 2 0 1 5 : 0 4 : 2 6 1 2 : 0 5 " . bdg : c o n d i t i o n T y p e ' ' Heating ' ' ;
	bdg : c o n d i t i o n V a l u e 10 .
	: Context1430043339256	Listing 6.4: HeatingCondition Rule Data.
	a bdg : EnvironmentContext ;
	bdg : happenIn : Room803 ;
	bdg : h as A c t o r : TempSensor803 ; 6.3.2.3 Reasoning
	bdg : time " 2 0 1 5 : 0 4 : 2 6 1 2 : 1 5 " .
	Graph database built around the Building Ontology enables Semantic Reasoner to infer
	: Context1430056199063 additional information from existed data and relationship. We exlain a simple example of

@ p r e f i x : <h t t p : / /www. i t -s u d p a r i s . eu / b a s d a t a#> . @ p r e f i x bdg : <h t t p : / /www. i t -s u d p a r i s . eu / b a s o n t#> .

A policy is represented by Policy class in Building Ontology, which applies to a user, device, or location and contains a condition (Condition class) for representing the policy.

There are three types of policies: Operation Policy, Universal Policy, and Personal Policy. Listing 6.4 illustrates a piece of data containing a policy called UniversalHeatingPolicy which is an instance of OperationPolicy (Building Ontology class). It applies for all users, instances of User (Building Ontology class) and has condition HeatingCondition (data). HeatingCondition is later on described as an instance of Condition (Building Ontology class) with "Heating" type and taking the value 10. Previously, two name spaces were defined at the header, one for the data and the other for the ontology. @ p r e f i x : <h t t p : / /www. i t -s u d p a r i s . eu / b a s d a t a#> . @ p r e f i x bdg : <h t t p : / /www. i t -s u d p a r i s . eu / b a s o n t#> .

t h e r e a s o n i n g f r om t h ed a t a s h o w n i n t h eL i s t i n g6 . 4 t o i n f e r t h a t U n i v e r s a lH e a t i n g P o l i c y a p p l i e s f o ru s e rJ e n n i f e r . T h er e a s o n i n gp r o c e s s i sd e p e c i t e d i nF i g u r e6 . 9 i n w h i c ha f a c t i s s t a t e da s t h e U n i v e r s a lH e a t i n g P o l i c y r u l ea p p l y i n g f o r i n s t a n c e so f U s e r c l a s s . A r e a s o n e rw i t hb a s i cc a p a c i t yc a nb eu s e d t od em o n s t r a t e t h eu s ec a s e ,e .

http://www.shazam.com/

http://www.compose-project.eu/

http://www.web-of-objects.com/

http://purl.oclc.org/NET/ssnx/ssn

https://www.snapchat.com/

h t t p : / /www . r i o t -o s . o r g /

http://purl.oclc.org/NET/ssnx/ssn

https://github.com/openlink/virtuoso-opensource

http://threestore.sourceforge.net

http://openjena.org

http://tomcat.apache.org

http://jersey.java.net

http://soa4d.org/

http://ws4d.org/

http://elgg.org/

http://phpbbsocialnetwork.com/

http://www.oxwall.org/

http://tomcat.apache.org/

http://opennlp.apache.org/

http://www.web-of-objects.com/,

-2015 2 http://sitac.wp.tem-tsp.eu/, 2012 -2015

http://ws4d.org/dpws-explorer/

Acknowledgments

of each protocol. In addition, we use a repository to maintain the list of active devices by carrying out the discovery process periodically or when the traffic is detected low in the 6LoWPAN. For example, a smart object has a temperature sensor and an LED indicator to display the status of room temperature. A client can discover these services by sending a request GET /.well-known/core to the smart object, which responses with the content shown in Listing 5.1. This task can be done with the service provisioning service by using the Web API presented in Table 5.1. Similarly, instead of using complex WS-Discovery Probe message in Listing 5.2 for DPWS services, we can discover services of the smart object by the same provisioning APIs. From the content of the response message, two services are discovered and provisioned in two Web APIs (see Table 5.2).

Scheduling

Limited resources in smart objects result in a problem of supporting simultaneous requests from multiple IoT applications on Web. Multiple requests can happen frequently for it is a typical case in the interaction between applications and smart objects when they get connected and become an integral part of the Internet. Many smart objects such as sensor nodes only support a very small number of simultaneous connections resulting in an ineffective operation of several real-time applications. We solve this problem by using a scheduling algorithm shown in Listing5.3). The algorithm consists of four processes: RequestHandler, Scheduler, QuantumAssertion, and ResponseObserver. Two requests are considered to be simultaneous if they come one after another in very short time (less than a threshold denoted by quantum time).

Publish/subscribe Eventing

To receive event notifications, Rosalie can subscribe her application directly to the heater by sending a SOAP envelope containing a WS-Eventing Subscribe message (using the SOAP-over-HTTP binding). The heater responds by sending a WS-Eventing SubscribeResponse message via the HTTP response channel. When an event occurs, the heater establishes a new TCP connection and sends an event notification to the subscriber. Therefore, in scenarios with many subscribers, it generates high level of traffic, requiring high resources, and causing smart objects to consume more energy. However, this publish/subscribe mechanism can be done through REST proxy to reduce the overhead of SOAP message exchanges and resource consumption, replacing global mesh-like connectivity by proxy-based topology (see Figure 5.5). One RESTful Web API is dedicated for event subscription; instead of sending a WS-Eventing Subscribe message, the application sends an HTTP POST request to the subscription resource (See Table 5.8). 5.9 shows a list of RESTful Web APIs provided by the proxy for the heater smart object mapping with DPWS operations.

WSDL Caching

When an application knows a smart object hosted service (representing smart object functionalities) endpoint address, it can ask that service for its interface description by sending a GetMetadata Service message. The service may respond with a GetMetadata Service Response message including a WSDL document. The WSDL document describes

IoT Protocol Stack

The IEEE 802.15.4 has been proven to be an excellent standard for low-power smart objects to carry out end-to-end IP communication. It goes with a set of supported standards such as 6LoWPAN adaptation and uIPv6 implementation.

Smart Grid

The proposed architecture also one of the core communication technology of the new European project in the domain of smart energy management: Future Unified System for Energy and Information Technology 3 (FUSE-IT). The project has just started by the time of this manuscript. We are planing to to extend the proposed architecture to the smart grid applications with a large-scale testbed in Barcelona city. The aim of the project is to develop a smart secured building system, incorporating secure shared sensors, actuators and devices strongly interconnected through not only information networks but trusted energy networks, including a core building data processing & analysis module, a smart unified building management interface, and a full security dashboard. Besides, it also simulates environments where DPWSim devices reside in. DPWSim provides many simulation tools for users to create, manage, store, and load simulations with high flexibility. DPWSim GUI that is based on Java Swing [START_REF] Elliott | Java Swing[END_REF] is quite intuitive and easy to use. DPWSim helps developers to prototype, develop, and test DPWS functionalities. The following sub-sections describe the simulation model, core components, functionalities, usage scenarios, and GUI of the simulator.

Appendix A

DPWSim: A DPWS Simulator

A.1 Simulation Model

DPWSim simulates the DPWS devices by modeling them as services that operate according to the input of sensing data (e.g., environmental temperature provided by users) 1 ws4d.org/jmeds/

A.4 Usage Scenarios

DPWSim can be used in different phases in the development process of DPWS products and systems. In general, it can be used in three scenarios

Scenario one -Product Integrating

Device manufacturers can pre-provide the DPWSim-compatible *.dpws file that describes functionalities of upcoming devices to developers. It enables them to test these devices in their real IoT applications before the official release of these products.

Scenario two -Product Protyping

Developers can prototype new devices and new functionalities based on their application requirements without going through the complex manufacturing process. The final design then can be transferred to the manufacturer to work on it.

Scenario three -Resources Sharing

This scenario describes the situation when several teams, at the same time, develop different modules over the same devices. To solve the problem and speed up the development process, a new set of simulated devices is generated by DPWSim to share among developers. The simulation can also be used for demonstration purpose without the loss of the accuracy.

A.5 Graphical User Interface

DPWSim GUI is built on lightweight Java Swing with a high level of flexibility and the inherent ability to override native host operating system (OS) UI controls. Swing components do not have corresponding native OS GUI components, and every component is free to render itself in any way possible within the underlying graphics GUIs. DPWSim GUI is intuitive to users with the dialog/menu/context menu system.