Abstract
Integrating the sensing capabilities of wireless sensor network (WSN) into the traditional telecom network is an important stage to realize future ubiquitous intelligence in the Internet of Things. Driven by the vision of service oriented architecture (SOA), this paper proposed a carrier class Internet of Things (IoT) service architecture named as MUSE. MUSE integrates WSN with IMS OSE framework to enable the WSN services to be operable and manageable. Also sensor web enablement (SWE) framework is adopted to shield the heterogeneity of different WSNs. MUSE consists of two key entities—MUSE Enabler and MUSE Gateway. On the one hand, the architecture promotes the node manageability and enriches the diversity of high level task planning flexibility. On the 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, an intelligent 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 of things (IoT), we are standing at the beginning of the age of 50 to 100 billion intelligent devices to be connected [1]. As the information acquisition engine and perception extension of IoT, the core value of wireless sensor network (WSN) is to collect massive information in a multiangle and multiparameter way, which has been applied in many fields, such as environment, transportation, industry, health care, and intelligent building [2]. With the huge number of things/objects and sensors/actuators connected to the Internet, how to access these heterogeneous and globally distributed sensor networks in a unified way and how to operate and manage these different kinds of sensors and actuators efficiently are urgent to be solved. In this paper, from the view of telecom operators, we argue that integration of WSN and IP multimedia subsystem (IMS) is a feasible and cost-efficient way to address these challenges.
Driven by the vision of service oriented architecture, information-oriented service, rather than connection-oriented service, is gradually becoming the intrinsic feature of ubiquitous information society. The carriers emphasize much on providing information service instead of simple network access. From the view of carriers, the operability of ubiquitous information-oriented service of WSN/IoT should be incarnated as follows.
Service Operability. Current sensing capability is application specific, localized, and isolated rather than service-oriented. For carriers, they just treat sensing capability as a part of information acquisition approach but not as basic service ability, for example, SMS, MMS, or voice. In order to catalyze novel context-aware applications in the future telecom field, it is essential for carriers to bring the variety of sensing capabilities of WSN into the traditional service. Correspondingly, the carriers' existing operation capabilities, such as authentication, authorization, accounting (AAA), quality of service (QoS), and service level agreement (SLA) mechanism, would enable ubiquitous perception services to be operable and manageable. However, in the current carrier operation platform, there is lack of unified information models and service procedures designed for WSN/IoT context-aware services.
Network Scalability. In the traditional vertical design model, WSN is highly customized and coupled with specific applications. Once the WSN has been deployed, it is hard to make flexible expansion and it may even need to be redeployed under some circumstances. Whereas future IoT needs to enable public and uncertain users' participatory information acquisition, local knowledge share, and data mining, this will help to generate a consolidated view of the physical world. Connected by the carriers' existing infrastructure, decentralized and disrupted sensor networks could cooperate via the heterogeneous access network. Decoupling the service and infrastructure is a feasible approach to break information silo and greatly improve the scalability of WSN.
Node Manageability. The future IoT service should reflect the semantic service into sensors/actuators operations. The carriers need to provide the unified and centralized management for sensors/actuators registration, update, and cancellation. Thus a variety of sensors, from simple thermometer, humidity, 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, WSN could be considered as a black box and the sensing process is executed by the task parameters transferred to it. To enable flexible IoT service, task planning and adjustment mechanism are needed. Ubiquitous perception service should support the parameterized and metadata-based WSN task assets. The function of WSN can be subjected to a feasible task updating.
The four features mentioned above comprise the prerequisites of the future carrier class IoT service. In this paper, we propose a service-oriented IoT architecture named as MUSE. Referring to unified nodes definition and data model of sensor web enablement (SWE) [3], MUSE promotes the node manageability and enriches the diversity of high level task plan flexibility. Moreover, MUSE integrates WSN with IMS OSE framework, which extends the traditional telecom service and realizes service operability and network scalability with IMS. Besides, there are two key components that are illustrated. The first one is a newly introduced service enabler called MUSE Enabler, which decouples services and the infrastructure in service ability layer. The second one is MUSE Gateway, which serves as a medium between the IMS enabler and the WSN.
The significance of MUSE is that, on the one hand, it achieves effective transmission of WSN information with the wide coverage of IMS and makes the service of WSN operational and scalable with the third-party management of IMS. On the other hand, it enables carriers to provide richer services for end users by utilizing the sensing capability and context-aware information.
The rest of the paper is organized as follows: in Section 2, we introduce the related works of representative standardization organizations, research institutions, and academia. Section 3 proposes the MUSE architecture and analyses two key components and supporting technologies in detail. The four specific procedures of carrier's operation are discussed in Section 4. In Section 5, the feasibility of our framework is illustrated by a conceptual application. The prototype proves that the architecture is appropriate for the future carrier class IoT service provision and the network load could be reduced effectively.
2. Related Work
To understand and deploy the ubiquitous service of IoT is a challenge and an unsolved problem. Many existing researches of standardization organizations, carriers, and academia are introduced as follows.
SWE, proposed by Open Geospatial Consortium (OGC), is a relative comprehensive framework aiming at achieving a collaborative, coherent, consistent, and consolidated sensor data collection, fusion, and distribution system. SWE makes sensors discoverable and accessible and realizes the object of accessing heterogeneous WSN and sharing WSN resources. Moreover, it provides task planning for sensors to acquire observations of interest for flexible WSN services [4]. Yet for all, from carriers' vision, SWE needs to be integrated into a telecom framework to operate the perception information service.
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 and the flexible session management [5]. IMS is intended to deliver next generation interactive and interoperable services, cost effectively, over an architecture providing the flexibility of the Internet. It is done by having a horizontal control layer that isolates the access network from the service layer. Except for the original services in the service layer, Open Mobile Alliance (OMA) defines the open service environment (OSE) and the standardized mobile service enabler specifications like Presence and XDMS, which support the creation of interoperable end-to-end mobile services. IMS functions well with the basic multimedia services based on streaming media, but for the fragmented and redundant sensing data services like WSN, related standards and mechanisms are being challenged.
E-SENSE is an IoT research project proposed in European FP7 [6]. The goal of E-SENSE is to make ambient intelligence available in 3G/4G networks. To fulfill the requirements of different scenarios, this project proposes an architecture that integrates WSN into the IMS service platform and introduces the design of its gateway and network protocol stack. E-SENSE makes WSN manageable and controllable to some degree, whereas the WSN service is limited to providing the data observation service and without task planning. For the future ubiquitous perception service, we should introduce a more complete service procedure.
European ISP Telefonica proposes an experimental platform named as ubiquitous sensor networks (USN) [7, 8]. The project composes and expands the present service enablers such as Presence, XDM, and Billing in OMA-defined OSE environment. It also decouples services from WSN by introducing the SWE information model. USN makes it possible for applications to be developed and deployed independently. Whereas this project concentrating on the USN Enabler, for future IoT, description of service procedures, for example, gateway registration, services capabilities publishing, and network remote management, needs to be emphasized further.
Researchers from Concordia University propose an architecture for the integration of the sensing capabilities of WSN in IMS to provide perception information services to end users [9, 10]. Based on the IMS Presence service, the system adopts the publish/subscribe mode to realize WSN data access. In the architecture, sensor data are stored in the message body of SIP message in the form of extended PIDF [11]. It contributes to realizing the publish/subscribe mechanism by presence of service enabler which has little influence on current architecture. We prefer to design a newly enabler instead of modifying Presence enabler in that the future IoT service needs a more flexible service provision mechanism to transmit massive and redundant data of WSN.
The above studies promote the current sensing capability to service-oriented pattern to some extent, respectively. However, these studies have not yet proposed a systematic solution that satisfied the four carriers' features and requirements mentioned in Section 1. This paper proposes a standardized ubiquitous IoT service architecture in IMS-switched network which accords with the standard service specifications of carriers.
3. Architecture Description
MUSE satisfies the intrinsic requirements of the ubiquitous IoT service, and the key feature lies in supporting the decentralized and heterogeneous WSN accessing telecom network in unified and flexible approaches. In this section, we first propose the architecture of the IMS/WSN convergence system which follows the technical deployment specification in IMS. Further, we design two core network components: MUSE Enabler and MUSE Gateway. The MUSE Enabler realizes the functions of sensor networks tracking, data acquisition, and task planning by referring to services in the SWE framework and the catalogue service in OGC. The MUSE Gateway manipulates adaptation of protocols between WSN and telecom networks and format conversion of data including metadata and observation data. Finally, we describe several core technologies in this architecture.
3.1. Overall Structure
Based on the typical layered IoT framework, Mari Carmen Domingo tried to introduce IMS into the framework, which makes a beneficial tentative for the future IoT ubiquitous services [12]. In this paper, MUSE is also based on the typical layered framework shown in Figure 1, from bottom to top as follows: perception extension layer, network access layer, signaling control layer, service ability layer, and application layer.
MUSE Architecture.
The functions of the five layers are defined as follows.
Perception extension layer. It realizes the effective information acquisition and transmission of the physical world. Network access layer. It is responsible for interacting with the IMS network, as well as both data collection and network management of WSN. Signaling control layer. It consists of IMS entities, for example, HSS and CSCF. And it realizes the functions of signaling route, access authentication, session control, service trigger, and so forth. Service ability layer. It is responsible for integrating and managing the WSN resources functions such as service discovery and data acquisition. Application layer. It supplies perceptive applications to the end users by utilizing the I/O interface provided by the service ability layer.
For the mobile communication network operators, this layered architecture makes the WSN seamlessly embedded into the telecommunication networks operation and management frameworks, and the value is added to the information by using context awareness which comes from detecting, storing, processing, and integrating situational and environmental information gathered by sensor nodes.
In the MUSE architecture, we also introduce the information model and the service procedure borrowing from SWE framework and make modifications to accord with the service specifications of carriers. The main technological improvements of this architecture are as follows.
Data format standardization. We utilize the SensorML as the standard model and use XML Schema to describe sensors systems and processes. What is more, O&M is used for encoding observations and measurements from a sensor [13, 14]. Service trigger. In order to realize the service trigger in IMS, we propose the rule of service point trigger (SPT) for WSN services. Protocol extension. SIP messages are extended by modifying the header and the message body to accommodate the control signaling. Catalogue service. Catalogue service from OGC is introduced to discover the WSN and services.
Specifically, the two key components designed in the architecture are as follows. (1) The MUSE Enabler is a centralized service engine. All requests from the upper applications are handled by it and all the metadata and observation data published by the WSN gateway are managed in it. (2) The MUSE Gateway is proposed in the network access layer, which connects different types of WSN with the mobile communication networks. To introduce the two components into this architecture, several core technologies such as the service triggering rules, the extension of SIP messages, and the catalogue service are proposed.
The advantage of this architecture is that it enables WSN as a unified, flexible, and manageable service in a standard way.
3.2. Network Entity
3.2.1. MUSE Enabler
MUSE Enabler is the most crucial entity in the IMS-switched architecture we proposed. MUSE Enabler in the service ability layer is designed according to the OMA OSE standard. It interacts with entities such as Presence, PoC, and XDM through a standardized way. XDM enabler specifies user-specific service-related informationdefined in well-structured XML documents. In this paper, we adopt the XCAP protocol as the communication protocol between the WSN enabler and the XDM server. The goal of MUSE Enabler is to introduce the IoT service into the telecom operation platform, integrate WSN resources, and provide ubiquitous perception services to end users. MUSE Enabler involves three functions that are (1) registration and tracking of WSN that realize the management of WSN resources, (2) decomposition of the access request, data acquirement from related WSN, and fusion data pushing, and (3) WSN task planning that provides functions of WSN management and sensor observation according to the service request.
Shown in Figure 2, the reference structure of MUSE Enabler consists of two layers. The lower layer is SIP interface and the upper layer includes three modules which are information repository, service logic, and SWE functions.
MUSE Enabler.
SIP interface module. SIP interface module provides standardized SIP interface through which other entities could interact with the enabler. It receives and resolves SIP messages from other network entities and forwards the message body according to the message type.
Service logic module. Service logic module takes charge of service logic such as the data query of upper layer's applications and the verification of sensor task feasibility. This module is also responsible for the service logic of MUSE Gateway registration and data publishing. The workflow of the module is as follows: resolve the SIP message of SIP interface module, generate a standardized description interfaced to SWE function module, and invoke the SWE function module to execute specific operations of the WSN.
SWE functions module. Referring to the standard SWE service model, SWE functions module realizes WSN services of data observation, task planning, alerting, and notification [15]. It executes specific sensor query or operating parameter configuration according to the parameters that transmitted from the service logic module. In this module, the catalogue function executes registration and service discovery of WSN according to the OGC catalogue service standard.
Information repository module. Information repository module takes charge of storing WSN metadata, observation data, user profile, and subscription rules. Through the data access interface, SWE function module is capable of retrieving and updating data in the module.
MUSE Enabler is designed according to IMS specifications, which achieves the seamless migration among different carriers. MUSE Enabler integrates sensor networks that with distributed, heterogeneous characteristics into a unified enabler and all the manipulations of the upper layer are gathered and processed by MUSE Enabler. That shields the differences of the underlying networks. Meanwhile, the enabler supplies an encapsulation interface for the upper layer, which provides convenience for third-party application developers and hides the internal network of carriers. Moreover, it manages user profile and billing information within the hierarchical architecture in IMS, avoids the function duplication in the traditional vertical network structure, provides perfect QoS and security mechanism, and realizes the operability of ubiquitous perception services.
3.2.2. MUSE Gateway
As a bridge that associates WSN with IMS, MUSE Gateway plays an important role in the IoT service architecture [16]. The goal of Gateway is to enable WSN to access the telecom network and respond to the service request of MUSE Enabler. Gateway contains three functions: (1) communication protocol adaptation. As a multimode device, gateway could communicate with WSN that adopts short-range wireless communication protocols such as ZigBee and 6LoWPAN [17] and access the IP-based IMS system via xDSL, GPRS, and so forth. (2) Format conversion of metadata and observation data: gateway adopts SensorML as the unified description for sensors and O&M as the sensor data information model, which shields the heterogeneity of underlying networks. (3) Support of SWE: gateway initiates the progress of WSN registration and responds to the upper layer request, making the service progress accord with the standard service procedure that SWE defines.
As shown in Figure 3, MUSE Gateway could be divided into three layers. As the interface to WSN, the lower layer takes charge of the WSN management and WSN data collection. The upper layer that interacts with IMS is responsible for receiving and sending SIP messages. The middle layer, including the information repository module, the service logic module, and the SWE client module, is responsible for storing and processing sensory data.
MUSE Gateway.
Information repository module. This module contains three repositories. The sensor data repository stores observation data that WSN collects. The information model repository contains the sensor description model named SensorML and the observation data model named O&M. The subscription rules repository contains the data publishing trigger that MUSE Enabler defines.
Service logic module. This module carries out the service logic of WSN registration and observation data publishing. It also responds to the request of data querying and sensor task planning that the MUSE Enabler sends. This module generating and resolving the SIP message in the service procedure mainly serves for the SWE client module.
SWE client module. This module realizes sensor observation and sensor task planning and notification services according to the standard SWE service model. It interacts with the information repository module and generates perceptual information to send to MUSE Enabler. It also calls the WSN interface and realizes the WSN task planning function of service platform.
Modules cooperating with each other in Gateway standardize the metadata and observation data of WSN and send them to MUSE Enabler through the SIP message, which eliminates the heterogeneity of WSN. Moreover, it strengthens the WSN management of the service platform by introducing the WSN registration and task planning.
3.3. Supporting Method
Several key challenges exist in the MUSE architecture as follows: (1) how the IMS service is deployed, (2) how to use a standardized communication protocol and data description protocol to complete the service process, and (3) how to implement the WSN registration and discovery. In this section, we design a set of supporting technologies to solve the challenges.
3.3.1. Service Trigger
Service trigger is the basis of deploying WSN services in IMS. The IMS service trigger can be summed up as service requests forwarding among the network element entities according to service rules [18]. In order that the WSN service process can be carried out smoothly, the initial filtering rule is defined to correctly route the SIP message in the service process of WSN network registration and sensing information publishing.
When a subscriber signs a service contract with the internet service provider (ISP), the ISP establishes the IMS user configuration information and stores it in HSS. Then S-CSCF will generate a third-party REGISTER request to the MUSE Enabler. Thus MUSE Enabler knows the existence of the gateway and the WSN attached to it.
SPT for the WSN gateway registration in this architecture is shown in Algorithm 1. This SPT means that SIP message, whose method is REGISTER and header is WSN_INFO, will be forwarded to
<InitialFilterCriteria> <TriggerPoint> <SPT> <Method>REGISTER</Method> <SIPHeader> <header>WSN_INFO</header> <content>*</content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:wsn_enabler@open-ims.com </ServerName> </ApplicationServer> </InitialFilterCriteria>
By utilizing the service trigger mechanism, SIP messages in the service process can be forwarded to the MUSE Enabler correctly.
3.3.2. SIP Extension
SIP message is the control protocol of the IMS network service, which is used to create, modify, and release sessions of one or more participants. In order to realize the basic function of network registration, data publishing, and data query, at the same time, is compatible with the existing IMS signaling system, the original SIP message is extended in this scheme.
The REGISTER message is responsible for registration and status update of gateway in this scheme. The REGISTER message carries SensorML describing WSN network through extending its message body [13], so as to satisfy the requirements of WSN gateway registration. Specifically, SensorML is an Extensible Markup Language based on XML encoding in the SWE framework, which provides the standard sensor model and observation process.
The PUBLISH message in the IMS domain is mainly responsible for event status update. Because the sensor message publishing in WSN is similar to the original event status update in IMS, the WSN gateway utilizes the PUBLISH message to publish data. Gateway needs to construct the document of SensorML and O&M in the body of the PUBLISH message to complete the publishing of the WSN metadata and observation data. Specifically, O&M describes sensing observation data in a unified standard utilizing XML format in the SWE framework [14] and thus shields the difference of sensing observation data derived from the heterogeneous WSN.
SIMPLE protocol in IMS is an event notification framework, which is based on the SIP message and is extended for IM and Presence services, and it mainly consists of the SUBSCRIBE message and the NOTIFY message [19, 20]. In this architecture, the upper layer application utilizes the SUBSCRIBE message in which filtering rules of the sensor network are carried out to complete the subscription and query of observation data. When sensing data meets the user's subscription conditions, MUSE Enabler uses the NOTIFY messages to notify the upper layer application that it carries the relevant data description.
The above extension of SIP messages makes different network elements communicate with each other in a standardized message format, meets the functional requirements of MUSE Enabler, realizes information fusion among heterogeneous sensor networks, and provides a unified interface to upper layer applications.
3.3.3. Catalogue Service
Catalogue service is a featured service prototype in MUSE. The integration of WSN and IMS system is optimized by the SWE standardized model. Furthermore, the scalable catalogue service is designed to promote the interoperability of the sensing systems and make effective integration of spatial information resources. The integration of catalogue service and the basic SWE service can be used to store and manage information such as service metadata, sensor metadata, and sensing observation data. What is more, the catalogue service is used as the entrance service for external calls. The records of catalogue service are mainly composed of service capability document, SensorML describing perception description, task template, and a part of the O&M describing observation data.
For the data request and response operations, the original perception information services interact directly with a related database. These operations' procedures are slightly adjusted after the integration of catalogue service to ensure that the metadata database is consolidated and managed by the catalogue service and thus are transparent to the SWE services and users. Some adjusted operations are shown in Table 1.
Catalogue operations.
Catalogue service provides a uniform management for metadata and a more effective WSN resources integration mechanism, which is expected to be one of the vital factors in MUSE.
4. Service Procedure
We define a set of service procedures following the corresponding SWE service model to standardize the services and support the operation of MUSE. The procedures provide functions of discovering, accessing, and utilizing WSN resources aiming at fulfilling the requirements of service operations. Specifically, the main interactive procedures are WSN gateway register, service discovery, observation data management, and sensor task planning.
4.1. Gateway Register Procedure
The gateway register procedure allows MUSE Gateway to register in the corresponding service instance. Based on the basic IMS third-party register mechanism, the register message is transferred to the MUSE Enabler; then the WSN gateway can be registered to the corresponding SWE service instance and it will activate an update in the catalogue service. The register request carries basic identification information of gateway in its message head and a SensorML as its message body to describe the sensing capability of the WSN. When the S-CSCF receives the message, it generates a third-party REGISTER request to the MUSE Enabler due to the trigger point downloaded from the HSS. Then the MUSE Enabler triggers a SOS operation called RegisterSensor and meanwhile requests the catalogue service to update the service ability and other related information. So far MUSE Enabler discovers the existence of gateway and attaches it. When the status of the gateway is changed, an update procedure is performed to refresh the state information in the metadata repository.
By providing the gateway register procedure, MUSE then has the ability to manage its WSN and nodes effectively, which is the premise of WSN resource integration.
4.2. Service Discovery Procedure
In MUSE, the service discovery procedure provides standardized service capabilities query and acquisition mechanism.
The user first sends the GetRecords request to the catalogue service in MUSE Enabler, and then a record list would be obtained as a feedback in case the request is valid. Different from the original work flow of SWE services, this procedure does not need to post requests to the specific service instance, in that the service metadata requested by users is managed through the catalogue service uniformly. The user's request is actually 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 repository using the given conditions and will return a service metadata document if the query is valid.
By providing the service discovery procedure, MUSE can manage its services in a more standardized and effective way, which would support basic operations in the architecture and provide a unified service interface for third-party applications.
4.3. Sensor Observation Procedure
The sensor observation procedure in MUSE is designed to enable sensor data consumers, such as terminal users, applications, and other service instances, to acquire sensor observation data. The procedure is based on the SOS specification and redefined to adapt the uniform management through the catalogue service.
There are two typical situations of the sensor observation procedure. The first one is the observation data acquirement of data consumers. A SUBSCRIBE message with the description of the interested perception information is sent to MUSE Enabler from the data consumer. This message carries semantic requests for perception information and the message body should fit the rules of GetObservation operation defined in SOS. The message is then forwarded to the corresponding service instance. The instance queries the data repository to get the requested observation data and returns an O&M document encapsulated in a NOTIFY message. For the second situation, MUSE Gateway, namely, data producer, publishes observation data actively. To make the procedure more flexible, two mechanisms are proposed as follows.
Regular uploading. The sampling parameters such as upload intervals and data types are predefined in the capability document of the corresponding SOS instance. The only way to change these sampling parameters is to adopt sensor task planning operations. Due to its more efficient transmission, this mechanism is the main approach in MUSE. Initiative uploading. Similar to the InsertObservation operation defined in SOS, the mechanism enables MUSE Gateway to publish observation data initiatively and thus makes the sensor data observation flexible.
The sensor observation procedures standardize the process of requests and publishing, which supplies the data foundation to upper-layer perception information services.
4.4. Sensor Planning Procedure
The sensor planning procedure in MUSE is used for WSN task scheduling. We refer to the SPS standard task description encapsulated in SWE common data model, which enhances the task description through parameterization.
Every sensor planning request must verify its feasibility by invoking the GetFeasibility operation [21]. The sensor planning procedure is a transaction operation. To ensure the WSN resources are managed effectively, we propose some suboperations which are shown in Table 2.
Suboperations of sensor planning procedure.
Based on our definition, a state transition diagram is shown in Figure 4. In the diagram, a Reserved task shall not change to the state of Execution unless the client confirms it. If the client does not confirm a Reserved task in time, the task will expire. Meanwhile an Execution task can be updated before the task is executed successfully and transited into the final state, whereas, in some exceptional situations, for example, when the client cancels the scheduled task or the server fails to complete the planned task, the task will reach the final state.
Task state transition diagram.
The transaction operation guarantees the instantaneity and the accuracy of sensor planning, which improves the utilizing efficiency of scheduled resources in certain degree.
The sensor planning procedure enables the MUSE to support the integrated task scheduling service, which fulfills the requirements of the sensor observation planning and the WSN management planning for the service platform and thus brings benefits to the service diversity and service efficiency of MUSE.
5. Prototype Implementation and Proof of Concept Application
In order to verify MUSE's feasibility and to evaluate its performance, we deployed an intelligent building prototype with 20 Micaz WSN nodes. Furthermore, a MUSE Gateway based on MB510 is deployed. In the scenario, end users obtain the perception information from WSN through the IMS. By the comparison of the sensor observation procedure between the traditional mode and the MUSE mode, the MUSE can reduce the network load effectively.
5.1. Conceptual Application Scenario
A typical indoor structure is shown in Figure 5. Many sensors are deployed in the house, which fulfills different functions including the house security monitoring, the family comfortable adjustment, and the smart home energy management. All types of interested observation data include the temperature, humidity, smoke, and light. In the security monitoring function, the temperature and smoke are used to detect the fire emergency; in the family comfortable adjustment function, the temperature and humidity are used to control the conditioner and humidifier; and in the home energy management function, the temperature, humidity, and light are used to control the lights and conditioners in the room.
Intelligent building scenario.
In traditional WSN applications, these sensing data are independent, though the sensor observation data type is similar. In the MUSE mode, all observation data of WSN could be gathered by MUSE Gateway and then converged to the MUSE Enabler. Moreover, the task requests from upper layer applications could be adjusted flexibly through the MUSE Enabler.
5.2. Prototype Architecture and SIP Process
As shown in Figure 6, 20 Micaz sensor nodes are scattered in the building and a MB510 sink node is connected to a laptop running the UCT IMS Client. The sink node and the laptop perform MUSE Gateway's functions such as data collection and WSN registration altogether. The IMS core entity, including HSS and CSCFs, is implemented based on the open IMS core. And then a monitoring and surveillance client is implemented in an Android phone with an IMS soft terminal called IMS Droid.
Prototype architecture.
The gateway supports the multimode access such as Wi-Fi, IEEE 802.15.4, and Bluetooth. It also supports the plug and play feature and adopts basic SIP to adapt different carriers. Because of the lack of multimode devices, we adopt a tradeoff method that utilizes a MIB 510 sink node and a laptop running IMS client to carry out the function of MUSE Gateway. The MB510 node is responsible for the sensing data collection, and the laptop realizes the data process function and the data publish function.
The full signaling process of the service procedure is shown in Figure 7. To simplify the signaling process, we replace all CSCF entities in IMS with xCSCF in the figure. Gateway register: a WSN is registered at first and the catalogue service updates the corresponding service information. InsertObservation: the registered WSN publishes its observation data. GetRecords and GetCapabilities: consumers query records and get interested service instance capabilities. DescribeSensor: the users choose to get sensor descriptions. GetObservation: consumers request for sensor observation data and expected to get a return encoded by O&M.
Signaling process of the service procedure.
In the signaling process as shown in Figure 7, MUSE Enabler maintains the observation data which is published by MUSE Gateway periodically and end users get the data from MUSE Enabler when needed. This kind of proxy mode can reduce the number of SIP messages when end users request the data, which improves the efficiency of data access. On the other hand, as the WSN catalogue service is added to the scheme, end users have to access catalogue service to get the information of WSN and sensors before they request data. This may increase the network load for the WSN whose structure is always changed.
5.3. Network Load Evaluation
In the prototype, we deploy five perception applications to analyze the performance of network load. The five applications gather temperature and humidity data inside the room. Undoubtedly each application has its own data sampling requirements like sampling time and data type for needs of each application.
In traditional mode, every sensor network provides the temperature and humidity observation, and every node has a data package including sampling time, node identity, and sampling value, whose total size is about 40 bytes. As shown in Table 3, for the intelligent humidifier application, the sampling time is 2 minutes and there are 800-byte temperature and humidity data totally published at one time. So the WSN publishes 24 KB data per hour in the intelligent humidifier application and 216 KB data per hour for all the five applications totally.
Network load under different model.
In MUSE mode, we set the sampling time to the minimum value (30 seconds), and the original data size published once is 800 bytes. Since the data are encapsulated into O&M format, with about 400-byte description data added, the total package size is expected to increase to 1.2 KB. As the five applications can share sensor data produced by the WSN in this area, the network load decreases to 144 KB per hour. The MUSE architecture successfully reduces the overall data size by reusing observation data, though single time data size is increased from 0.8 KB to 1.2 KB.
As shown in Figure 8, in the traditional mode, the data size increases as the increasing of application number and the amplification is related to the requirements of the new added application. In the MUSE mode, the data size is related to the integral requirements, which has no significant change after it increases to a certain extent. When the number of applications is 1 or 2, MUSE mode shows no obvious advantage in network load, due to that the observation data of MUSE involves extra data descriptions, whereas, as the number of applications increases to some degree, such as 3, 4, or 5, MUSE mode reduces the data size obviously by data multiplexing. This mechanism is adaptive in comprehensive applications to reduce their data loads, especially for carriers to operate widely deployed application scenarios.
Network load changing curve in different mode.
6. Conclusion
In this paper, we proposed an ubiquitous IoT service architecture named as MUSE aiming to integrate WSN over IMS telecom framework in a flexible and unified way. MUSE takes advantage of the SWE framework to standardize the perception information model and the WSN service procedure, which shields the heterogeneity of different WSNs. By utilizing the OGC catalogue service, MUSE realizes the unified management of WSN and services. To realize the integration of WSN and IMS, we defined the service trigger rule of WSN services and extended the SIP protocol. And then the reference model of two main components in MUSE architecture is given. At last we illustrated four basic service procedures which provide the service reference mode for carriers.
The advantages of integrating WSN over IMS telecom framework remain as follows. On the one hand, the carrier's strong operability enables ubiquitous perception services to be operable and manageable. On the other hand, the services which carriers provide can be flexibly expanded and deployed.
The standardized integration of regional deployed WSN and wide area deployed mobile communication networks is an evolution stage to realize future ubiquitous intelligence in the internet of things. In the future we will continue the research and try to solve the key questions in the MUSE architecture, such as the more grained sensor data acquisition and task planning services, security, and privacy in catalogue service, mobility support for sensors and devices, and the highly effective stream data transmission. Moreover, we will attempt to carry the standardization works of future IoT service based on our work mentioned before.
Footnotes
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This research is supported by National Natural Science Foundation of China (no. 61271185 and no. 61300183) and the Fundamental Research Funds for the Central Universities.