Integrating the sensing capabilities of wireless sensor network (WSN) into the traditional telecom network is an important stageto realize future ubiquitous intelligence in the Internet of Things. Driven by the vision of service oriented architecture (SOA), thispaper proposed a carrier class Internet ofThings (IoT) service architecture named as MUSE. MUSE integratesWSNwith IMS OSEframework to enable the WSN services to be operable and manageable. Also sensor web enablement (SWE) framework is adoptedto shield the heterogeneity of different WSNs. MUSE consists of two key entities—MUSE Enabler and MUSE Gateway. On theone hand, the architecture promotes the node manageability and enriches the diversity of high level task planning flexibility. Onthe other hand, the architecture extends the telecom context-aware service and realizes service operability and network scalability.Moreover, the key components of the architecture and the detailed service procedure were introduced in the paper. Besides, anintelligent building prototype with 20 nodes was illustrated and the feasibility and performance of MUSE were verified at last.
1. Introduction
With the ongoing development towards future internet ofthings (IoT), we are standing at the beginning of the ageof 50 to 100 billion intelligent devices to be connected[1]. As the information acquisition engine and perceptionextension of IoT, the core value of wireless sensor network(WSN) is to collect massive information in a multiangleand multiparameter way, which has been applied in manyfields, such as environment, transportation, industry, healthcare, and intelligent building [2]. With the huge numberof things/objects and sensors/actuators connected to theInternet, how to access these heterogeneous and globallydistributed sensor networks in a unified way and how tooperate and manage these different kinds of sensors andactuators efficiently are urgent to be solved. In this paper,from the view of telecom operators, we argue that integrationof WSN and IP multimedia subsystem (IMS) is a feasible andcost-efficient way to address these challenges.
Driven by the vision of service oriented architecture,information-oriented service, rather than connection-orient-ed service, is gradually becoming the intrinsic feature of
ubiquitous information society.The carriers emphasizemuchon providing information service instead of simple networkaccess. From the view of carriers, the operability of ubiquitousinformation-oriented service of WSN/IoT should be incar-nated as follows.
Service Operability. Current sensing capability is applicationspecific, localized, and isolated rather than service-oriented.For carriers, they just treat sensing capability as a part ofinformation acquisition approach but not as basic serviceability, for example, SMS, MMS, or voice. In order to catalyzenovel context-aware applications in the future telecom field,it is essential for carriers to bring the variety of sensingcapabilities of WSN into the traditional service. Correspond-ingly, the carriers’ existing operation capabilities, such asauthentication, authorization, accounting (AAA), quality ofservice (QoS), and service level agreement (SLA)mechanism,would enable ubiquitous perception services to be operableand manageable. However, in the current carrier operationplatform, there is lack of unified information models andservice procedures designed for WSN/IoT context-awareservices.
Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2014, Article ID 930472, 11 pageshttp://dx.doi.org/10.1155/2014/930472
2 International Journal of Distributed Sensor Networks
Network Scalability. In the traditional vertical design model,WSN is highly customized and coupled with specific applica-tions. Once the WSN has been deployed, it is hard to makeflexible expansion and it may even need to be redeployedunder some circumstances. Whereas future IoT needs toenable public and uncertain users’ participatory informationacquisition, local knowledge share, and data mining, thiswill help to generate a consolidated view of the physicalworld. Connected by the carriers’ existing infrastructure,decentralized and disrupted sensor networks could cooperatevia the heterogeneous access network. Decoupling the serviceand infrastructure is a feasible approach to break informationsilo and greatly improve the scalability of WSN.
Node Manageability.The future IoT service should reflect thesemantic service into sensors/actuators operations.The carri-ers need to provide the unified and centralized managementfor sensors/actuators registration, update, and cancellation.Thus a variety of sensors, from simple thermometer, humid-ity, noise, and complex camera to triaxial accelerometer,could be discovered, accessed, and utilized on a global level.
Task Plan Flexibility. From the view of carriers’ service, WSNcould be considered as a black box and the sensing process isexecuted by the task parameters transferred to it. To enableflexible IoT service, task planning and adjustment mech-anism are needed. Ubiquitous perception service shouldsupport the parameterized and metadata-based WSN taskassets.The function ofWSN can be subjected to a feasible taskupdating.
The four features mentioned above comprise the pre-requisites of the future carrier class IoT service. In thispaper, we propose a service-oriented IoT architecture namedas MUSE. Referring to unified nodes definition and datamodel of sensor web enablement (SWE) [3],MUSE promotesthe node manageability and enriches the diversity of highlevel task plan flexibility. Moreover, MUSE integrates WSNwith IMS OSE framework, which extends the traditionaltelecom service and realizes service operability and networkscalability with IMS. Besides, there are two key componentsthat are illustrated.The first one is a newly introduced serviceenabler called MUSE Enabler, which decouples services andthe infrastructure in service ability layer. The second one isMUSE Gateway, which serves as a medium between the IMSenabler and the WSN.
The significance of MUSE is that, on the one hand, itachieves effective transmission of WSN information withthe wide coverage of IMS and makes the service of WSNoperational and scalable with the third-party management ofIMS. On the other hand, it enables carriers to provide richerservices for end users by utilizing the sensing capability andcontext-aware information.
The rest of the paper is organized as follows: in Section 2,we introduce the related works of representative standard-ization organizations, research institutions, and academia.Section 3 proposes the MUSE architecture and analyses twokey components and supporting technologies in detail. Thefour specific procedures of carrier’s operation are discussedin Section 4. In Section 5, the feasibility of our framework is
illustrated by a conceptual application. The prototype provesthat the architecture is appropriate for the future carrier classIoT service provision and the network load could be reducedeffectively.
2. Related Work
To understand and deploy the ubiquitous service of IoT is achallenge and an unsolved problem.Many existing researchesof standardization organizations, carriers, and academia areintroduced as follows.
SWE, proposed by Open Geospatial Consortium (OGC),is a relative comprehensive framework aiming at achieving acollaborative, coherent, consistent, and consolidated sensordata collection, fusion, and distribution system. SWE makessensors discoverable and accessible and realizes the object ofaccessing heterogeneous WSN and sharing WSN resources.Moreover, it provides task planning for sensors to acquireobservations of interest for flexible WSN services [4]. Yet forall, from carriers’ vision, SWE needs to be integrated intoa telecom framework to operate the perception informationservice.
IMS, proposed by 3rd Generation Partnership Project(3GPP), is the de facto standard of the 3G/4G core networks,offering the mechanism of multimedia service provision andthe flexible session management [5]. IMS is intended todeliver next generation interactive and interoperable services,cost effectively, over an architecture providing the flexibilityof the Internet. It is done by having a horizontal control layerthat isolates the access network from the service layer. Exceptfor the original services in the service layer, Open MobileAlliance (OMA) defines the open service environment (OSE)and the standardized mobile service enabler specificationslike Presence and XDMS, which support the creation ofinteroperable end-to-end mobile services. IMS functionswell with the basic multimedia services based on streamingmedia, but for the fragmented and redundant sensing dataservices like WSN, related standards and mechanisms arebeing challenged.
E-SENSE is an IoT research project proposed in EuropeanFP7 [6].The goal of E-SENSE is to make ambient intelligenceavailable in 3G/4G networks. To fulfill the requirements ofdifferent scenarios, this project proposes an architecture thatintegratesWSN into the IMS service platform and introducesthe design of its gateway and network protocol stack. E-SENSE makes WSN manageable and controllable to somedegree, whereas the WSN service is limited to providing thedata observation service and without task planning. For thefuture ubiquitous perception service, we should introduce amore complete service procedure.
European ISP Telefonica proposes an experimental plat-form named as ubiquitous sensor networks (USN) [7, 8].Theproject composes and expands the present service enablerssuch as Presence, XDM, and Billing in OMA-defined OSEenvironment. It also decouples services from WSN by intro-ducing the SWE information model. USN makes it possiblefor applications to be developed and deployed independently.Whereas this project concentrating on the USN Enabler, for
International Journal of Distributed Sensor Networks 3
Perceptionextension layer
Telecomoperationframework
AAA
BSS
OSS
Security GW GWGW GW
App App
Application layer
Service ability layer
Signalingcontrol layer
Maps IM PoCWSN enabler
WSN enabler
triggerIMS (HSS, CSCFs)
Storage
SWE servicesCatalogue
Service logic
SIP interface
SIP extensionGateway
IMS interfaceSensorML
O&MStorage
SWE client
WSN interface
Service logicNetwork
access layer
IMS/third-partyenabler
Service trigger
Figure 1: MUSE Architecture.
future IoT, description of service procedures, for example,gateway registration, services capabilities publishing, andnetwork remote management, needs to be emphasized fur-ther.
Researchers fromConcordiaUniversity propose an archi-tecture for the integration of the sensing capabilities ofWSN in IMS to provide perception information services toend users [9, 10]. Based on the IMS Presence service, thesystem adopts the publish/subscribe mode to realize WSNdata access. In the architecture, sensor data are stored inthe message body of SIP message in the form of extendedPIDF [11]. It contributes to realizing the publish/subscribemechanism by presence of service enabler which has littleinfluence on current architecture.We prefer to design a newlyenabler instead of modifying Presence enabler in that thefuture IoT service needs a more flexible service provisionmechanism to transmit massive and redundant data ofWSN.
The above studies promote the current sensing capabilityto service-oriented pattern to some extent, respectively. How-ever, these studies have not yet proposed a systematic solutionthat satisfied the four carriers’ features and requirementsmentioned in Section 1. This paper proposes a standardizedubiquitous IoT service architecture in IMS-switched networkwhich accords with the standard service specifications ofcarriers.
3. Architecture Description
MUSE satisfies the intrinsic requirements of the ubiquitousIoT service, and the key feature lies in supporting thedecentralized and heterogeneous WSN accessing telecomnetwork in unified and flexible approaches. In this section, wefirst propose the architecture of the IMS/WSN convergencesystem which follows the technical deployment specificationin IMS. Further, we design two core network components:MUSE Enabler and MUSE Gateway. The MUSE Enablerrealizes the functions of sensor networks tracking, data
acquisition, and task planning by referring to services inthe SWE framework and the catalogue service in OGC. TheMUSEGatewaymanipulates adaptation of protocols betweenWSN and telecom networks and format conversion of dataincludingmetadata and observation data. Finally, we describeseveral core technologies in this architecture.
3.1. Overall Structure. Based on the typical layered IoTframework, Mari Carmen Domingo tried to introduce IMSinto the framework, which makes a beneficial tentative forthe future IoT ubiquitous services [12]. In this paper, MUSEis also based on the typical layered framework shown inFigure 1, from bottom to top as follows: perception extensionlayer, network access layer, signaling control layer, serviceability layer, and application layer.
The functions of the five layers are defined as follows.(1) Perception extension layer. It realizes the effective
information acquisition and transmission of the phys-ical world.
(2) Network access layer. It is responsible for interactingwith the IMS network, as well as both data collectionand network management of WSN.
(3) Signaling control layer. It consists of IMS entities,for example, HSS and CSCF. And it realizes thefunctions of signaling route, access authentication,session control, service trigger, and so forth.
(4) Service ability layer. It is responsible for integratingand managing the WSN resources functions such asservice discovery and data acquisition.
(5) Application layer. It supplies perceptive applicationsto the end users by utilizing the I/O interface providedby the service ability layer.
For the mobile communication network operators, thislayered architecture makes the WSN seamlessly embed-ded into the telecommunication networks operation and
4 International Journal of Distributed Sensor Networks
management frameworks, and the value is added to theinformation by using context awareness which comes fromdetecting, storing, processing, and integrating situational andenvironmental information gathered by sensor nodes.
In the MUSE architecture, we also introduce the infor-mation model and the service procedure borrowing fromSWE framework and make modifications to accord withthe service specifications of carriers. The main technologicalimprovements of this architecture are as follows.
(1) Data format standardization. We utilize the Sen-sorML as the standard model and use XML Schemato describe sensors systems and processes. What ismore, O&M is used for encoding observations andmeasurements from a sensor [13, 14].
(2) Service trigger. In order to realize the service triggerin IMS, we propose the rule of service point trigger(SPT) for WSN services.
(3) Protocol extension. SIP messages are extended bymodifying the header and the message body toaccommodate the control signaling.
(4) Catalogue service. Catalogue service from OGC isintroduced to discover the WSN and services.
Specifically, the two key components designed in thearchitecture are as follows. (1)TheMUSE Enabler is a central-ized service engine. All requests from the upper applicationsare handled by it and all the metadata and observation datapublished by the WSN gateway are managed in it. (2) TheMUSE Gateway is proposed in the network access layer,which connects different types of WSN with the mobilecommunication networks. To introduce the two componentsinto this architecture, several core technologies such as theservice triggering rules, the extension of SIP messages, andthe catalogue service are proposed.
The advantage of this architecture is that it enables WSNas a unified, flexible, and manageable service in a standardway.
3.2. Network Entity
3.2.1. MUSE Enabler. MUSE Enabler is the most crucialentity in the IMS-switched architecture we proposed. MUSEEnabler in the service ability layer is designed according tothe OMA OSE standard. It interacts with entities such asPresence, PoC, and XDM through a standardized way. XDMenabler specifies user-specific service-related informationde-fined in well-structured XML documents. In this paper, weadopt the XCAP protocol as the communication protocolbetween the WSN enabler and the XDM server. The goal ofMUSEEnabler is to introduce the IoT service into the telecomoperation platform, integrate WSN resources, and provideubiquitous perception services to end users. MUSE Enablerinvolves three functions that are (1) registration and trackingof WSN that realize the management of WSN resources, (2)decomposition of the access request, data acquirement fromrelated WSN, and fusion data pushing, and (3) WSN taskplanning that provides functions of WSN management andsensor observation according to the service request.
Informationrepository
SWE services
SOS SPS
WNSSAS
Catalogueservice
Observationdata
Userprofile
Service logic function
Publisher Register Notifier Subscriber
SIP interface
WSN info
Figure 2: MUSE Enabler.
Shown in Figure 2, the reference structure of MUSEEnabler consists of two layers.The lower layer is SIP interfaceand the upper layer includes three modules which areinformation repository, service logic, and SWE functions.
(1) SIP interface module. SIP interface module providesstandardized SIP interface through which other enti-ties could interact with the enabler. It receives andresolves SIPmessages fromother network entities andforwards the message body according to the messagetype.
(2) Service logic module. Service logic module takescharge of service logic such as the data query of upperlayer’s applications and the verification of sensor taskfeasibility. This module is also responsible for theservice logic of MUSE Gateway registration and datapublishing. The workflow of the module is as follows:resolve the SIP message of SIP interface module,generate a standardized description interfaced toSWE function module, and invoke the SWE functionmodule to execute specific operations of the WSN.
(3) SWE functions module. Referring to the standardSWE service model, SWE functions module realizesWSN services of data observation, task planning,alerting, and notification [15]. It executes specificsensor query or operating parameter configurationaccording to the parameters that transmitted from theservice logic module. In this module, the cataloguefunction executes registration and service discoveryof WSN according to the OGC catalogue servicestandard.
(4) Information repository module. Information reposi-tory module takes charge of storing WSN metadata,observation data, user profile, and subscription rules.Through the data access interface, SWE function
International Journal of Distributed Sensor Networks 5
module is capable of retrieving and updating data inthe module.
MUSE Enabler is designed according to IMS speci-fications, which achieves the seamless migration amongdifferent carriers. MUSE Enabler integrates sensor networksthat with distributed, heterogeneous characteristics into aunified enabler and all the manipulations of the upper layerare gathered and processed by MUSE Enabler. That shieldsthe differences of the underlying networks. Meanwhile, theenabler supplies an encapsulation interface for the upperlayer, which provides convenience for third-party applicationdevelopers and hides the internal network of carriers. More-over, it manages user profile and billing information withinthe hierarchical architecture in IMS, avoids the functionduplication in the traditional vertical network structure,provides perfect QoS and security mechanism, and realizesthe operability of ubiquitous perception services.
3.2.2. MUSE Gateway. As a bridge that associates WSN withIMS, MUSE Gateway plays an important role in the IoTservice architecture [16]. The goal of Gateway is to enableWSN to access the telecom network and respond to theservice request of MUSE Enabler. Gateway contains threefunctions: (1) communication protocol adaptation. As a mul-timode device, gateway could communicate with WSN thatadopts short-range wireless communication protocols suchas ZigBee and 6LoWPAN [17] and access the IP-based IMSsystem via xDSL, GPRS, and so forth. (2) Format conversionof metadata and observation data: gateway adopts SensorMLas the unified description for sensors and O&M as the sensordata information model, which shields the heterogeneity ofunderlying networks. (3) Support of SWE: gateway initiatesthe progress of WSN registration and responds to the upperlayer request, making the service progress accord with thestandard service procedure that SWE defines.
As shown in Figure 3, MUSE Gateway could be dividedinto three layers. As the interface to WSN, the lower layertakes charge of the WSN management and WSN data collec-tion. The upper layer that interacts with IMS is responsiblefor receiving and sending SIP messages. The middle layer,including the information repository module, the servicelogic module, and the SWE client module, is responsible forstoring and processing sensory data.
(1) Information repository module. This module con-tains three repositories. The sensor data repositorystores observation data that WSN collects. The infor-mationmodel repository contains the sensor descrip-tion model named SensorML and the observationdata model named O&M. The subscription rulesrepository contains the data publishing trigger thatMUSE Enabler defines.
(2) Service logic module. This module carries out theservice logic of WSN registration and observationdata publishing. It also responds to the request of dataquerying and sensor task planning that the MUSEEnabler sends. This module generating and resolving
SIP interface
Service logic function
Register Publisher Subscribe Notifier
SWE clientWNSclientclient
client client
SAS
SOS SPS
Info.acquisition
WSNmanagement
WSN interface
Subscriberules
Info. model
Information repository
Observationdata
Figure 3: MUSE Gateway.
the SIP message in the service procedure mainlyserves for the SWE client module.
(3) SWE client module. This module realizes sensorobservation and sensor task planning and notifica-tion services according to the standard SWE servicemodel. It interacts with the information repositorymodule and generates perceptual information to sendto MUSE Enabler. It also calls the WSN interface andrealizes the WSN task planning function of serviceplatform.
Modules cooperating with each other in Gateway stan-dardize the metadata and observation data of WSN andsend them to MUSE Enabler through the SIP message,which eliminates the heterogeneity of WSN. Moreover, itstrengthens theWSNmanagement of the service platform byintroducing the WSN registration and task planning.
3.3. Supporting Method. Several key challenges exist in theMUSE architecture as follows: (1) how the IMS service isdeployed, (2) how to use a standardized communication pro-tocol and data description protocol to complete the serviceprocess, and (3) how to implement the WSN registrationand discovery. In this section, we design a set of supportingtechnologies to solve the challenges.
3.3.1. Service Trigger. Service trigger is the basis of deployingWSN services in IMS.The IMS service trigger can be summedup as service requests forwarding among the network elemententities according to service rules [18]. In order that theWSN service process can be carried out smoothly, the initialfiltering rule is defined to correctly route the SIP message inthe service process of WSN network registration and sensinginformation publishing.
6 International Journal of Distributed Sensor Networks
When a subscriber signs a service contract with theinternet service provider (ISP), the ISP establishes the IMSuser configuration information and stores it in HSS. Then S-CSCF will generate a third-party REGISTER request to theMUSE Enabler. Thus MUSE Enabler knows the existence ofthe gateway and the WSN attached to it.
SPT for theWSN gateway registration in this architectureis shown in Algorithm 1. This SPT means that SIP message,whose method is REGISTER and header is WSN INFO, willbe forwarded to wsn [email protected] server.
By utilizing the service trigger mechanism, SIP messagesin the service process can be forwarded to theMUSE Enablercorrectly.
3.3.2. SIP Extension. SIP message is the control protocol ofthe IMS network service, which is used to create, modify, andrelease sessions of one ormore participants. In order to realizethe basic function of network registration, data publishing,and data query, at the same time, is compatible with theexisting IMS signaling system, the original SIP message isextended in this scheme.
The REGISTER message is responsible for registrationand status update of gateway in this scheme. The REGISTERmessage carries SensorML describingWSN network throughextending its message body [13], so as to satisfy the require-ments of WSN gateway registration. Specifically, SensorMLis an Extensible Markup Language based on XML encodingin the SWE framework, which provides the standard sensormodel and observation process.
The PUBLISH message in the IMS domain is mainlyresponsible for event status update. Because the sensormessage publishing in WSN is similar to the original eventstatus update in IMS, theWSN gateway utilizes the PUBLISHmessage to publish data. Gateway needs to construct the doc-ument of SensorML and O&M in the body of the PUBLISHmessage to complete the publishing of the WSN metadataand observation data. Specifically, O&M describes sensingobservation data in a unified standard utilizing XML formatin the SWE framework [14] and thus shields the differenceof sensing observation data derived from the heterogeneousWSN.
SIMPLE protocol in IMS is an event notification frame-work, which is based on the SIP message and is extendedfor IM and Presence services, and it mainly consists of theSUBSCRIBE message and the NOTIFY message [19, 20].In this architecture, the upper layer application utilizes theSUBSCRIBE message in which filtering rules of the sensornetwork are carried out to complete the subscription andquery of observation data.When sensing datameets the user’ssubscription conditions, MUSE Enabler uses the NOTIFYmessages to notify the upper layer application that it carriesthe relevant data description.
The above extension of SIP messages makes differentnetwork elements communicate with each other in a stan-dardized message format, meets the functional requirementsof MUSE Enabler, realizes information fusion among hetero-geneous sensor networks, and provides a unified interface toupper layer applications.
3.3.3. Catalogue Service. Catalogue service is a featuredservice prototype in MUSE. The integration of WSN andIMS system is optimized by the SWE standardized model.Furthermore, the scalable catalogue service is designed topromote the interoperability of the sensing systems andmakeeffective integration of spatial information resources. Theintegration of catalogue service and the basic SWE servicecan be used to store and manage information such as servicemetadata, sensor metadata, and sensing observation data.What is more, the catalogue service is used as the entranceservice for external calls. The records of catalogue service aremainly composed of service capability document, SensorMLdescribing perception description, task template, and a partof the O&M describing observation data.
For the data request and response operations, the orig-inal perception information services interact directly witha related database. These operations’ procedures are slightlyadjusted after the integration of catalogue service to ensurethat the metadata database is consolidated and managed bythe catalogue service and thus are transparent to the SWEservices and users. Some adjusted operations are shown inTable 1.
Catalogue service provides a uniform management formetadata and a more effective WSN resources integrationmechanism, which is expected to be one of the vital factorsin MUSE.
4. Service Procedure
We define a set of service procedures following the corre-sponding SWE service model to standardize the servicesand support the operation of MUSE. The procedures pro-vide functions of discovering, accessing, and utilizing WSNresources aiming at fulfilling the requirements of serviceoperations. Specifically, the main interactive procedures areWSN gateway register, service discovery, observation datamanagement, and sensor task planning.
International Journal of Distributed Sensor Networks 7
Table 1: Catalogue operations.
Operation Operation procedure
GetCapabilities
Function: the operation provides service metadata to the user.Description: service metadata is stored in the metadata repository, which is managed by the catalogue service.Thus the user needs to send requests to the catalogue service rather than the SWE service instance to acquireservice metadata.
DescribeSensorFunction: users acquire sensor metadata through this operation.Description: the sensor metadata is also stored in the metadata repository and the user can only interact withthe catalogue service rather than SOS itself.
RegisterSensor Function: the operation enables WSN to register itself into a SOS instance.Description: the sensor metadata should be forwarded to the catalogue service for further processing.
4.1. Gateway Register Procedure. The gateway register proce-dure allows MUSE Gateway to register in the correspondingservice instance. Based on the basic IMS third-party registermechanism, the register message is transferred to the MUSEEnabler; then the WSN gateway can be registered to thecorresponding SWE service instance and it will activate anupdate in the catalogue service. The register request carriesbasic identification information of gateway in its messagehead and a SensorML as its message body to describe thesensing capability of the WSN. When the S-CSCF receivesthe message, it generates a third-party REGISTER requestto the MUSE Enabler due to the trigger point downloadedfrom the HSS. Then the MUSE Enabler triggers a SOSoperation called RegisterSensor and meanwhile requests thecatalogue service to update the service ability and otherrelated information. So far MUSE Enabler discovers theexistence of gateway and attaches it. When the status of thegateway is changed, an update procedure is performed torefresh the state information in the metadata repository.
By providing the gateway register procedure, MUSE thenhas the ability tomanage itsWSNandnodes effectively, whichis the premise of WSN resource integration.
4.2. Service Discovery Procedure. In MUSE, the service dis-covery procedure provides standardized service capabilitiesquery and acquisition mechanism.
The user first sends the GetRecords request to the cata-logue service in MUSE Enabler, and then a record list wouldbe obtained as a feedback in case the request is valid. Differentfrom the original work flow of SWE services, this proceduredoes not need to post requests to the specific service instance,in that the service metadata requested by users is managedthrough the catalogue service uniformly.The user’s request isactually encapsulated within a SUBSCRIBE message in SIP;the SIP message will then be sent to the catalogue service.For the catalogue service, it queries the metadata repositoryusing the given conditions and will return a service metadatadocument if the query is valid.
By providing the service discovery procedure, MUSE canmanage its services in a more standardized and effective way,which would support basic operations in the architecture andprovide a unified service interface for third-party applica-tions.
4.3. Sensor Observation Procedure. The sensor observationprocedure in MUSE is designed to enable sensor dataconsumers, such as terminal users, applications, and otherservice instances, to acquire sensor observation data. Theprocedure is based on the SOS specification and redefinedto adapt the uniform management through the catalogueservice.
There are two typical situations of the sensor observationprocedure. The first one is the observation data acquire-ment of data consumers. A SUBSCRIBE message with thedescription of the interested perception information is sentto MUSE Enabler from the data consumer. This messagecarries semantic requests for perception information andthe message body should fit the rules of GetObservationoperation defined in SOS. The message is then forwardedto the corresponding service instance. The instance queriesthe data repository to get the requested observation dataand returns an O&M document encapsulated in a NOTIFYmessage. For the second situation, MUSE Gateway, namely,data producer, publishes observation data actively. To makethe procedure more flexible, two mechanisms are proposedas follows.
(1) Regular uploading. The sampling parameters suchas upload intervals and data types are predefined inthe capability document of the corresponding SOSinstance. The only way to change these samplingparameters is to adopt sensor task planning oper-ations. Due to its more efficient transmission, thismechanism is the main approach in MUSE.
(2) Initiative uploading. Similar to the InsertObservationoperation defined in SOS, the mechanism enablesMUSE Gateway to publish observation data initia-tively and thus makes the sensor data observationflexible.
The sensor observation procedures standardize the pro-cess of requests and publishing, which supplies the datafoundation to upper-layer perception information services.
4.4. Sensor Planning Procedure. The sensor planning proce-dure in MUSE is used for WSN task scheduling. We referto the SPS standard task description encapsulated in SWEcommon data model, which enhances the task descriptionthrough parameterization.
8 International Journal of Distributed Sensor Networks
Table 2: Suboperations of sensor planning procedure.
Update Update task parameters when in reserving orexecution state
Submit Notify the service instance that the task is to beexecuted
Task scheduled Update
Submit
Submit
Complete
ReserveReserved Reserve expired
Cancelled
Failed
Execution
Figure 4: Task state transition diagram.
Every sensor planning request must verify its feasibilityby invoking the GetFeasibility operation [21]. The sensorplanning procedure is a transaction operation. To ensure theWSN resources are managed effectively, we propose somesuboperations which are shown in Table 2.
Based on our definition, a state transition diagram isshown in Figure 4. In the diagram, a Reserved task shall notchange to the state of Execution unless the client confirmsit. If the client does not confirm a Reserved task in time, thetask will expire. Meanwhile an Execution task can be updatedbefore the task is executed successfully and transited intothe final state, whereas, in some exceptional situations, forexample, when the client cancels the scheduled task or theserver fails to complete the planned task, the task will reachthe final state.
The transaction operation guarantees the instantaneityand the accuracy of sensor planning, which improves theutilizing efficiency of scheduled resources in certain degree.
The sensor planning procedure enables the MUSE tosupport the integrated task scheduling service, which fulfillsthe requirements of the sensor observation planning and theWSNmanagement planning for the service platform and thusbrings benefits to the service diversity and service efficiencyof MUSE.
5. Prototype Implementation and Proof ofConcept Application
In order to verify MUSE’s feasibility and to evaluate itsperformance, we deployed an intelligent building prototypewith 20 Micaz WSN nodes. Furthermore, a MUSE Gatewaybased onMB510 is deployed. In the scenario, end users obtain
GatewayGas monitor Sensor nodes
Air conditioner
LightHumidifier
Figure 5: Intelligent building scenario.
the perception information from WSN through the IMS. Bythe comparison of the sensor observation procedure betweenthe traditional mode and the MUSE mode, the MUSE canreduce the network load effectively.
5.1. Conceptual Application Scenario. A typical indoor struc-ture is shown in Figure 5. Many sensors are deployed in thehouse, which fulfills different functions including the housesecurity monitoring, the family comfortable adjustment, andthe smart home energy management. All types of interestedobservation data include the temperature, humidity, smoke,and light. In the security monitoring function, the tempera-ture and smoke are used to detect the fire emergency; in thefamily comfortable adjustment function, the temperature andhumidity are used to control the conditioner and humidifier;and in the home energy management function, the temper-ature, humidity, and light are used to control the lights andconditioners in the room.
In traditional WSN applications, these sensing data areindependent, though the sensor observation data type issimilar. In the MUSE mode, all observation data of WSNcould be gathered by MUSE Gateway and then convergedto the MUSE Enabler. Moreover, the task requests fromupper layer applications could be adjusted flexibly throughthe MUSE Enabler.
5.2. Prototype Architecture and SIP Process. As shown inFigure 6, 20 Micaz sensor nodes are scattered in the buildingand a MB510 sink node is connected to a laptop runningthe UCT IMS Client. The sink node and the laptop performMUSE Gateway’s functions such as data collection and WSNregistration altogether. The IMS core entity, including HSSandCSCFs, is implemented based on the open IMS core. Andthen a monitoring and surveillance client is implementedin an Android phone with an IMS soft terminal called IMSDroid.
The gateway supports the multimode access such as Wi-Fi, IEEE 802.15.4, and Bluetooth. It also supports the plugand play feature and adopts basic SIP to adapt differentcarriers. Because of the lack of multimode devices, we adopta tradeoff method that utilizes a MIB 510 sink node and alaptop running IMS client to carry out the function of MUSE
International Journal of Distributed Sensor Networks 9
Gateway. The MB510 node is responsible for the sensing datacollection, and the laptop realizes the data process functionand the data publish function.
The full signaling process of the service procedure isshown in Figure 7. To simplify the signaling process, wereplace all CSCF entities in IMS with xCSCF in the figure.Gateway register: a WSN is registered at first and the cata-logue service updates the corresponding service information.InsertObservation: the registered WSN publishes its obser-vation data. GetRecords and GetCapabilities: consumersquery records and get interested service instance capabilities.DescribeSensor: the users choose to get sensor descriptions.GetObservation: consumers request for sensor observationdata and expected to get a return encoded by O&M.
In the signaling process as shown in Figure 7, MUSEEnablermaintains the observation data which is published byMUSE Gateway periodically and end users get the data fromMUSE Enabler when needed. This kind of proxy mode canreduce the number of SIP messages when end users requestthe data, which improves the efficiency of data access. Onthe other hand, as the WSN catalogue service is added tothe scheme, end users have to access catalogue service toget the information of WSN and sensors before they requestdata. This may increase the network load for theWSN whosestructure is always changed.
5.3. Network Load Evaluation. In the prototype, we deployfive perception applications to analyze the performance ofnetwork load. The five applications gather temperature andhumidity data inside the room.Undoubtedly each applicationhas its own data sampling requirements like sampling timeand data type for needs of each application.
In traditional mode, every sensor network provides thetemperature and humidity observation, and every node hasa data package including sampling time, node identity, andsampling value, whose total size is about 40 bytes. Asshown in Table 3, for the intelligent humidifier application,
the sampling time is 2 minutes and there are 800-bytetemperature and humidity data totally published at one time.So the WSN publishes 24KB data per hour in the intelligenthumidifier application and 216KB data per hour for all thefive applications totally.
In MUSE mode, we set the sampling time to the mini-mum value (30 seconds), and the original data size publishedonce is 800 bytes. Since the data are encapsulated into O&Mformat, with about 400-byte description data added, the totalpackage size is expected to increase to 1.2 KB. As the fiveapplications can share sensor data produced by the WSN inthis area, the network load decreases to 144KB per hour. TheMUSE architecture successfully reduces the overall data sizeby reusing observation data, though single time data size isincreased from 0.8 KB to 1.2 KB.
As shown in Figure 8, in the traditional mode, the datasize increases as the increasing of application number and theamplification is related to the requirements of the new addedapplication. In the MUSE mode, the data size is related tothe integral requirements, which has no significant changeafter it increases to a certain extent. When the numberof applications is 1 or 2, MUSE mode shows no obviousadvantage in network load, due to that the observation dataof MUSE involves extra data descriptions, whereas, as thenumber of applications increases to some degree, such as 3,4, or 5, MUSE mode reduces the data size obviously by datamultiplexing. This mechanism is adaptive in comprehensiveapplications to reduce their data loads, especially for carriersto operate widely deployed application scenarios.
6. Conclusion
In this paper, we proposed an ubiquitous IoT service archi-tecture named as MUSE aiming to integrate WSN over IMStelecom framework in a flexible and unified way. MUSEtakes advantage of the SWE framework to standardize theperception information model and the WSN service pro-cedure, which shields the heterogeneity of different WSNs.By utilizing the OGC catalogue service, MUSE realizes theunified management of WSN and services. To realize theintegration of WSN and IMS, we defined the service triggerrule of WSN services and extended the SIP protocol. Andthen the reference model of two main components in MUSEarchitecture is given. At last we illustrated four basic serviceprocedures which provide the service reference mode forcarriers.
The advantages of integrating WSN over IMS telecomframework remain as follows. On the one hand, the carrier’sstrong operability enables ubiquitous perception servicesto be operable and manageable. On the other hand, theservices which carriers provide can be flexibly expanded anddeployed.
The standardized integration of regional deployed WSNand wide area deployed mobile communication networks isan evolution stage to realize future ubiquitous intelligencein the internet of things. In the future we will continue theresearch and try to solve the key questions in the MUSEarchitecture, such as themore grained sensor data acquisition
10 International Journal of Distributed Sensor Networks
MUSE enabler
Catalogue service WSN servicesxCSCFConsumerGateway
Gatewayregister
Insert
GetRecords
GetCapabilities
DescribeSensor
GetObservation
observation
capabilities
(2) Register
(5) Publish (O&M)(4) OK (ID)
(3) OK (ID)
(1) Register
(6) Publish (O&M)
(11) Notify
(8) OK(7) OK
(10) Subscribe(9) Subscribe
(12) Notify
(14) Subscribe(13) Subscribe
(15) Query(16) Service
(22) Notify
(21) Notify
(18) Notify(17) Notify
(23) Subscribe(24) Subscribe
(19) Subscribe(20) Subscribe
(25) Notify(26) Notify
Figure 7: Signaling process of the service procedure.
Table 3: Network load under different model.
Mode Application Sampling data type Sampling period (s) Data size single time(KB)
Data size per hour(KB/h)
Original mode
Self-adaptive humidifier T and H 120 0.8 24Patch board overtemperaturealarm T 60 0.4 24
Indoor temperatureconditioner T and H 60 0.8 48
Fire alarm T and H 30 0.8 96Plant nurseries T 60 0.4 24Total — — — 216
MUSE mode Synthetic of the 5applications T and H 30 1.2 144
International Journal of Distributed Sensor Networks 11
24
72
120
216 216
36
6072
144 144
1 2 3 4 5
Number of applications
250
200
150
100
50
0
Net
wor
k lo
ad (K
B/h)
Traditional modeMUSE mode
Figure 8: Network load changing curve in different mode.
and task planning services, security, and privacy in catalogueservice, mobility support for sensors and devices, and thehighly effective stream data transmission. Moreover, we willattempt to carry the standardization works of future IoTservice based on our work mentioned before.
Conflict of Interests
The authors declare that there is no conflict of interestsregarding the publication of this paper.
Acknowledgments
This research is supported by National Natural ScienceFoundation of China (no. 61271185 and no. 61300183) and theFundamental Research Funds for the Central Universities.
References
[1] M. Zorzi, A. Gluhak, S. Lange, and A. Bassi, “From today’sINTRAnet of things to a future INTERnet of things: a wireless-and mobility-related view,” IEEEWireless Communications, vol.17, no. 6, pp. 44–51, 2010.
[2] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci,“Wireless sensor networks: a survey,” Computer Networks, vol.38, no. 4, pp. 393–422, 2002.
[3] “OGC sensor web enablement: overview and high level archi-tecture,” OGC 07-165, Open Geospatial Consortium, 2006.
[4] Z. Chen, N. Chen, L. Di, and J. Gong, “A flexible data and sensorplanning service for virtual sensors based on web service,” IEEESensors Journal, vol. 11, no. 6, pp. 1429–1439, 2011.
[5] IP Multimedia Subsystem (IMS), Stage 2, 3GPP TS 23.228.[6] A. Gluhak, M. Presser, D. Babb, L. Herault, and R. Tafazolli,
“e-SENSE reference model for sensor network in B3G mobilecommunications systems,” in Proceedings of the 15th IST Mobile& Wireless Communications Summit, Myconos, Greece, June2006.
[7] M. Strohbach, J. Vercher, and M. Bauer, “A case for IMS,” IEEEVehicular Technology Magazine, vol. 4, no. 1, pp. 57–64, 2009.
[8] J. Bernat, “Ubiquitous sensor networks in IMS: an ambientintelligence telco platformintelligence telco platform,” in Pro-ceedings of the ICT-MobileSummit 2008 Conference, Estocolmo,Sweden, 2008.
[9] M. El Barachi, A. Kadiwal, R. Glitho, F. Khendek, and R.Dssouli, “A presence-based architecture for the integration ofthe sensing capabilities of wireless sensor networks in the IPmultimedia subsystem,” in Proceedings of the IEEE WirelessCommunications and Networking Conference (WCNC ’08), pp.3116–3121, Las Vegas, Nev, USA, March 2008.
[10] H. Ru Cheng, F. Belqasmi, R. H. Glitho, and F. Khendek, “Thedesign and implementation of architectural components forthe integration of the IP multimedia subsystem and wirelessactuator networks,” IEEE Communications Magazine, vol. 49,no. 12, pp. 138–146, 2011.
[11] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, andJ. Peterson, “Presence information data format (PIDF),” RFC3863, 2004.
[12] M. Domingo, “A context-aware service architecture for theintegration of body sensor networks and social networksthrough the IP multimedia subsystem,” IEEE CommunicationsMagazine, vol. 49, no. 1, pp. 102–108, 2011.
[13] M. Botts and A. Robin, “OpenGIS sensor model language(sensorML) implementation specification,” OGC DocumentOGC 07-000, Open Geospatial Consortium (OGC), Wayland,Mass, USA, 2007.
[14] S. Cox, “Observations and measurements—part1—observationschema,” OGC Document OGC 07-022r1, Open GeospatialConsortium (OGC), Wayland, Mass, USA, 2007.
[15] X. Chu, T. Kobialka, B. Durnota, and R. Buyya, “Open sensorweb architecture: core services,” in Proceedings of the 4thInternational Conference on Intelligent Sensing and InformationProcessing (ICISIP ’06), pp. 98–103, IEEE, Bangalore, India,December 2006.
[16] M. El Barachi, A. Kadiwal, R. Glitho, F. Khendek, and R.Dssouli, “The design and implementation of a gateway for IPmultimedia subsystem/wireless sensor networks interworking,”in Proceedings of the 69th IEEE Vehicular Technology Conference(VTC ’09), pp. 1–5, Barcelona, Spain, April 2009.
[17] “IETF 6lowpan Working Group Homepage,” http://www.ietf.org/html.charters/6lowpan-charter.html.
[18] A. Gouya and N. Crespi, “Service orchestration in IMS,” in IMSHandbook, pp. 329–344, CRC Press.
[19] SIMPLE WG, “SIP for instant messaging and presence lever-aging extensions,” 2006, http://www.ietf.org/html.charters/simple-charter.html.
[20] J. Rosenberg, H. Schulzrinne, B. Campbell, C. Huitema, and D.Gurle, “Session initiation protocol (SIP) extension for instantmessaging,” RFC 3428, IETF, 2002.
[21] I. Simonis and P. Dibner, “OpenGIS sensor planning serviceimplementation specification,” OGCDocument OGC 07-014r3,Open Geospatial Consortium (OGC), Wayland, Mass, USA,2007.
