Abstract
As wireless sensor networks have been typically designed for monitoring of environments or habitats, all sensed data flow down toward fixed sinks. With the proliferation of Internet of Things, a variety of services require that data should be delivered not to the fixed sinks but directly to operator-specified devices, such as actuators and inside sensor fields. Then, the data will directly trigger interactive and immediate actions at the devices for the services. We call this kind of service as a device-to-device interactive Internet of Things service. However, the wireless sensor networks with fixed architecture could not support the device-to-device interactive services. The services might have the sociality based on the service-specific organic relationships between sensor and device, or between devices according to the purpose of the service. Social wireless sensor network is the architecture and mechanism to define the organic relationships of sensing data and the flow of data per service dynamically and flexibly over wireless sensor networks. In this article, we propose the social wireless sensor network architecture, functions, and challenges to provide the sociality of the services over wireless sensor networks.
Keywords
Introduction
Wireless sensor networks (WSNs) have been usually designed for various monitoring services of environments and habitats such as military, radioactivity, and fire. There have been a number of concepts, architectures, platforms, and implementations in WSNs. However, they assume that the networks have the typical and fixed architecture where all sensed data of the sensor field flow down toward preconfigured fixed sinks. Also, the sinks or a gateway in the backend analyze the overall data and provide non-interactive monitored information to remote users for the services. 1 After the remote users gather the monitored information, they might determine the next action according to the data.
As the development of Internet of Things (IoT), a variety of services are coming out recently as shown in Figure 1.2–4 For example, in the case of a smart building, as soon as a fire sensor detects a fire, it will send an event directly to several operator-specified devices such as a sprinkler, fire-alarm, and firewall. Then, the delivered event will trigger the sprinkler to spray water, fire-alarm to din, and the firewall to be pulled down immediately. Also, if movement sensors detect survivors, they will send the tracking information directly to the firefighters arrived on the scene of a fire for the fastest rescue. For another example, in usual situations, if the movement sensors detect the human existences in the room, they will send data of numbers and positions of human directly to another device, an air-conditioner of the room. Then, the air-conditioner will adjust the strength and direction of the wind according to the delivered data for the energy-saving service. Finally, for the security service, if the movement sensors detect an intruder during the security-on time, they will send an event directly to other related devices, the nearest closed-circuit television (CCTV) and security alarm devices. Then, the CCTV starts to take a photograph along with the route of the intruder, and the security alarm calls the security agency immediately.
Examples of device-to-device interactive IoT services.
Like these examples, the sensors and devices monitor the environment in real time. And they send the monitored data directly to the proper actuating devices, and then, the devices perform immediate actions based on the data according to the conditions and sequences of service-specific organic relationships specified by the operator. We call this kind of service as a device-to-device interactive IoT service. With the fixed architecture of WSNs, a significant delay would be caused since data gathering delay and human determination delay are needed. Although the determination by human or server is processed in a local domain, many problems should be solved. In the future WSNs and IoT, (1) a variety of services will be generated; (2) the configurations for servers (the number and the location) in the local domain could not be determined; and (3) according to the number and the location of servers, a significant delay will be caused and complex services could not be supported by the networks.
There are several characteristics worth mentioning about the service. Each service is provided under a sociality between sensor and device, or between devices. A fire-sensing event has a sociality with only fire devices for the disaster prevention service, and an intruder-sensing event has another sociality with security devices for the security service. However, a movement-sensing data has multiple sociality with other kinds of devices depending on the situation for multiple services. Namely, the service consists of particular sensors and devices related only for the service. The selected sensors and devices have a service-specific role within a service. They exchange the data and control internally among them according to the operator-specified relationship. The services are independent of each other even though they use same sensing data and device. For another characteristic, there might be multiple independent services in a domain at the same time. Finally, the service should be able to be designed and deployed flexibly and dynamically according to the service environments and operator’s requirements.
In order to support multiple independent device-to-device interactive IoT services, it is required to apply the sociality over WSNs dynamically and flexibly as well. WSNs should be able to configure the organic relationship of sensing data and the flow of sensed data dynamically and flexibly among specified sensors and devices according to the sociality of the services. But the traditional WSNs have been designed with the typical architecture that all sensors are included in a service, and they have a static role of a source or a sink, and data will flow only from source sensors to fixed sinks in the network. 5 These architectures are fixed, homogeneous, and non-interactive. To provide multiple kinds of the organic relationships for the services with the traditional WSNs, operators should use the gathered information at the gateway in shared WSN model as shown in Figure 2(a), which makes the service non-interactive, or deploy a dedicated WSN per service as shown in Figure 2(b).
Examples of service deployment with traditional WSN: (a) shared model and (b) dedicated model.
In this article, we propose a social wireless sensor network (SWSN) which is the architecture and mechanism to provide the sociality over WSNs. SWSN selects necessary sensors and devices, and configures a flexible role of each sensor as a source or a sink, and determines the flow of sensed data among sensors and devices dynamically according to the sociality of the service. Therefore, it could provide service own independent auto-configurable WSN for each device-to-device interactive IoT service.
The reminder of this article is organized as follows. In section “SWSN,” we propose a network architecture and system functions of SWSN. We then present several related works in section “Related work” and a use case to evaluate the feasibility and efficiency of the architecture in section “Use case.” Section “Performance evaluation” shows the performance evaluation, and section “Challenges” discusses several important challenges. Finally, section “Conclusion” concludes this article.
SWSN
In this section, we propose a network architecture and system functions of SWSN. The architecture consists of three layers of physical, social, and service. A gateway, sensors, and things perform several added functions at the layers to provide the sociality of the device-to-device interactive IoT services. Things can be active devices such as smartphone, notebook, and CCTV and can be passive objects such as temperature and fire.
Network architecture
Figure 3 shows the network architecture of SWSN. It shows three independent SWSNs for each service over a physical WSN with the architecture.
Network architecture of SWSN.
Physical layer performs the original functions of traditional WSNs in the architecture. It consists of source sensors, sink sensors to which sensed data flow down, and the gateway which manages the overall WSN. As the natural functions of traditional WSNs, all sensors self-organize the network and do fixed behavior either as a source or as a sink, and data are delivered from sources to fixed sinks in data-centric mechanism. This layer functions as the configuration network which delivers the control information to configure SWSNs dynamically for each service. Also, it provides real communications between sensors of a SWSN.
Social layer provides an independent SWSN for each service. The locations of things determine the sensors which will participate in a SWSN. The functions of things determine the role of sensors and the directions of sensed data with service goal–centric communication mechanism such as unicast, multicast, or broadcast in the SWSN. That is, the sensors do flexible behaviors either as a source or as a sink, and the data flows are configured dynamically over the related sensors depending on the sociality of active and passive things within each service. The service goal–centric communications of the SWSN are bound transparently to real communications of the physical WSN.
Service layer provides real services to users. Each service consists of service-related active and passive things. Each service is defined by the organic relationship, namely, sociality, which specifies the things, the role of things, and data delivery relationships between things for the service goal. Things perform their own business logics with the data provided by their SWSN.
System functions
A gateway, sensors, and things perform the following system functions in Figure 4 at the physical, the social, and the service layer. We are focusing on the added functions of SWSN.
System functions of SWSN.
Configuration network of SWSN
WSN over the physical layer is the traditional self-organized network that consists of all sensors with the gateway as a sink. It is used as the configuration network to exchange control information among sensors, things, and the gateway to configure SWSNs dynamically. That is, things publish information through this network for WSN to recognize the service, the locations of things, and participating sensors. Also, the gateway sends information through this network for the sensors to determine their role and the directions of data delivery for each service.
Sociality profile
Operators can provide their custom-designed services by defining a file, the sociality profile, at the gateway, which describes the organic relationships between things for each service. The sociality profile includes the service identifier, the identifiers of things that take part in the service, the role of things, and the directions of data delivery between things for immediate actions. This profile comes to determine social sensors, the role of the sensors, and the data flow among them in its SWSN. If operators want to deploy multiple kinds of concurrent services, it is sufficient for them to add a sociality profile per service.
Dynamic service subscription
Things can be subscribed to a service just by publishing the service identifier and their identifiers through the configuration network toward the gateway. That is, the dynamic service subscription of things makes WSNs detect the existence of services and things dynamically. In the case of thing wants to join multiple services, it can join them by publishing multiple service subscriptions with different service identifiers.
Active things will publish themselves and passive things will be published by the sensors that detect them. Periodic service subscriptions will reflect the changes automatically such as movement of things or faults of sensors over the SWSN.
Auto-selection of social sensors
The configuration network comes to select the sensors that will participate in a SWSN during the delivery process of the service subscription up to the gateway. In other words, the sensors on the path of the configuration network from the publishing things to the gateway are the social sensors for the SWSN. The sensors on the path keep the pair of the thing identifier and the previous sensor that delivers each service subscription. It makes WSN auto-discover the locations of things and auto-select the social sensors related to the service.
Binding social gradients
The gateway sends the sociality profile through the reverse path of the service subscription flow toward the social sensors after it receives the service subscription. Then, the social sensors create social gradients according to the delivered sociality profile as following rules. Previous source or sink sensor means the previous sensor that delivers the service subscription from source or sink thing, respectively. Social gradients make data-centric communication possible as the following rules without any broadcasted interests per service:
If the previous source sensor and the previous sink sensor are same, do not create any gradient.
If the previous source sensor and the previous sink sensor are different, create a gradient from previous source sensor to previous sink sensor on the basis of the identifier of source thing.
This process determines automatically the role of sensor and the data flow between social sensors of a SWSN.
Dynamic configuration of a SWSN
The functions of the architecture create a new SWSN when a thing joins a service, change the topology of the SWSN whenever other things join the service, change the data flow and topology whenever any things move or leave, and remove the SWSN when all things leave the service. These dynamic configurations of the SWSN are performed without any intervention of operators or modifications of hardware.
Binding social communication
Device-to-device interactive IoT services can require various communication mechanisms such as unicast, multicast, and broadcast for the service efficiency. But physical WSN usually supports one type of communication mechanism over the network. Therefore, the SWSN should bind communication transparently between social and physical WSN for each service.
Related work
Social IoT researches have shown the architecture for the device-to-device IoT services.6,7 These researches provide the services with the IoT server-centric processes of modeling, discovery, and composition of service between devices with some degree of owner interventions. Things have interaction with each other and the IoT server through legacy public networks in the global domain. They do not focus on the device-to-device and interactive service. Unlike these researches, this article intends to show that there could be some more feasible and interactive services if we restrict the service range to the local domain. With the characteristics of the local domain such as near communication range and single administrative authority, we propose another architecture that could reduce the overhead of network management and human interventions, and make the service more interactive. That is, we propose self-organizable WSN as a communication media between devices in order to remove the network overhead on devices. In addition, it can make the service more interactive with direct controllability up to sensors. Also, just the description of the organic service relationship is enough to model, discover, and compose custom-designed local domain services. It does not require any ownership control and complex relationship modeling under single authority.
Cyber physical system (CPS) has shown the typical architecture in which it collects the physical world information by the sensor network, transfers information through the legacy public network to the cyber world, and then makes a decision at the cyber world systems, and finally, controls the physical world back through the legacy public network again.4,8 There are many service cases that CPS is applied to the local area such as plants, wearable devices, home, and buildings. In those cases, the interactions through legacy public networks such as Ethernet, Wi-Fi, and cellular can cause unnecessary transmission delay if they pass through routers or gateways out of local area. The architecture of this article suggests more interactive environments for CPS services that require real-time interactive controllability between things based on the sensed data over the local domain.
There have been few researches for the multiple device-to-device interactive IoT services exactly in the traditional WSN area. Therefore, in general views, there is no way to describe the organic relationship of sensed data and data flow between devices per service over WSN. In order to support multiple independent services in traditional WSNs, all source sensors disseminate data over the network, and all sinks or actuators should select proper data for their own service. It could decrease the network efficiency and could not guarantee the service security. Therefore, we suggest the SWSN architecture to provide more efficient and secured services over WSN.
Virtual sensor concept has been introduced.9,10 The virtual sensor is a software sensor as opposed to a physical or hardware sensor. Virtual sensor provides integrated measurements of abstract conditions by combining sensed data from a group of heterogeneous physical sensor nodes. The virtual sensor can combine a variety of data to compute an abstract measurement. Via the virtual sensors, the users could precisely specify the operation according to the conditions. The big difference between the virtual sensor and SWSNs is that the virtual sensor concept focuses on the integration of sensor nodes but the SWSN emphasizes the relationship between sensors or between sensors and actuators or sink nodes. Typically, in WSNs, there are two kinds of nodes: data-generating node (sensors) and data-consuming node (actuator or sink node). The virtual sensor concept combines different types of data to compute an abstract measurement. Like our SWSNs, the virtual sensors are assumed to be heterogeneous. However, in order to support a variety of applications, the virtual sensor concept integrates the functions of a variety of sensors, but the SWSN applies the social relation between sensor nodes and between sensor nodes and actuators or sink nodes. Namely, we consider both data-generating nodes and data-consuming nodes.
Use case
In this section, we explain how to deploy two device-to-device interactive IoT services, security, and disaster prevention service in a smart building with the SWSN architecture. The used topology and routing algorithm are just an example. It could be different per domain.
Configuration network. WSN with 16 sensors is constructed at a smart building as shown in Figure 5(a). The network topology of physical WSN has the tree structure as presented in Figure 5(b), and it is used as the configuration network for SWSNs.
Sociality profile. Things for the security service are noted with purple color such as two CCTVs (C1 and C2), a door sensor (D1), a security alarm (SA), and two movement sensors (M2 and M11). Things for the disaster prevention service are noted with green color such as a firefighter (FF), a fire sensor (FS), a sprinkler (SK), a firewall (FW), a fire-alarm (FA), and a movement sensor (M2). Operator creates a file of the sociality profiles that describe the custom-designed services at the gateway in Table 1.
Use case (1/2): (a) physical WSN, (b) physical WSN topology as a configuration network, (c) service subscription and auto-selection of social sensors for security service, (d) service subscription and auto-selection of social sensors for disaster prevention service, (e) dynamic configuration of sociality profile for disaster prevention service, and (f) binding social gradients for disaster prevention service at sensor 7.
Examples of the sociality profiles.
Namely, the profile says that if M2 or D1 detects an intruder, then they send the sensed data directly to C1 to trigger taking a video, D1 also sends the data to SA to call the security agency immediately. And if M11 detects an intruder, then it sends the data to C2 to start taking a video around that area for the security service. For disaster prevention service, the profile also says that if FS detects the smoke, then it sends the event directly to all of SK, FW, FA, and FF. So, the event would make immediately SK sprinkle water, FW pulled down, FA din, and FF informed about the fire. And if M2 detects survivors, then it sends directly the data to FF for rapid rescue.
Service subscription. Each thing publishes its service identifier and thing identifier toward the gateway when it turns on. Figure 5(c) and (d) shows the process of the service subscription (SS) of the security and disaster prevention service, respectively.
Auto-selection of social sensors. All sensors on the purple and green paths of the configuration network become the social sensors automatically for each service. They save the thing identifiers and previous sensors per service as shown in Figure 5(c) and (d). The sensor 7 of Figure 5(d) comes to know that FF, FS, SK, and FW are from sensors 5, 6, 7, and 8, respectively, for the disaster prevention service. As soon as the gateway receives the service subscriptions, it sends back the sociality profile through the configuration network. The profile will be delivered to all social sensors 7, 4, 1, 2, 5, 6, and 8 using the saved previous sensor information along the reverse path of the green line as shown in Figure 5(e).
Binding social gradients. Figure 5(f) shows the process that sensor 7 binds the social gradients dynamically for the data delivery between selected social sensors according to the sociality profile of the disaster prevention service. The first relationship means that M2 forwards data to FF as soon as it detects survivors. Sensor 7 knows that FF is at the sensor 5 of its lower tree and M2 might be at the upper tree because it does not exist under its lower tree. Therefore, sensor 7 makes a gradient from parent sensor to sensor 5 for the data from M2. The second relationship means that FS forwards data to SK, FF, FW, and FA if it detects the smoke. Sensor 7 knows that FA is at the upper tree and others are at the lower sensors 5, 6, 7, and 8. Therefore, sensor 7 makes a gradient to be multicasted from sensor 6 to sensors 5, 7, and 8 and parent for the data from FS. Figure 6(a) and (b) shows the final views of the social gradients of two services.
The SWSNs. Figure 6(a) shows an SWSN for the security service that consisted of sensors 2, 3, 4, 7, 11, 14, 15, and 16, in which the social gradients created as sensors 2, 4, and 11 are sources and sensors 3, 15, and 16 are sinks. Figure 6(b) shows another SWSN for the disaster prevention service that consisted of sensors 1, 2, 4, 5, 6, 7, and 8, in which the social gradients created as sensors 2 and 6 are sources and sensors 1, 5, 7, and 8 are sinks. In this way, two independent SWSNs have been auto-configured dynamically for each service over a physical WSN as shown in Figure 6(c) and (d). They are constructed with different sensors, different roles, and data flows for each service.
Binding social communication. The physical WSN supports unicast only. A multicast from FS should be translated to four unicasts toward SK, FF, FW, and FA. So, if sensor 7 receives a data from FS, it transfers 4 data to each sensor 1, 5, 7, and 8.
Dynamic configuration. If FF moves along the fire, sensor 5 loses FF and sensor 10 senses FF. Consequently, new service subscription is performed along the path of sensors 10, 11, and 7. The gateway resends the sociality profile to all social sensors including sensors 10 and 11 along the movement of FF in order to update the social gradients. Figure 6(e) shows the dynamically updated SWSN.
Use case (2/2): (a) SWSN for security service, (b) SWSN for disaster prevention service, (c) SWSNs of two services with the SWSN architecture, (d) physical views of each SWSN, and (e) dynamic configuration with mobile things.
Performance evaluation
In this section, we evaluate the performance of the proposed architecture through simulation results.
Simulation environments
We have implemented the proposed architecture in a network simulator, Qualnet V.4.0. 11 We compare our architecture with sensor networks based on directed diffusion, 12 which is the most well-known routing protocol in WSN researches. The simulation network space consists of 400 sensor/actuator nodes uniformly deployed in a 100 × 100 m2 area. The four sink nodes are installed for gathering data via sensor nodes. Each sensor has its own sink node and its data are sent toward the sink node. The radio range of each sensor nodes is about 20 m. We randomly choose 500 pairs of sensors and actuators for the simulation. The model of sensor nodes is followed by the specification of MICA2. Each source generates a continuous bit rate (CBR) flow with interval of 0.05 s and a packet frame size is fixed to 30 bytes. IEEE 802.11 DCF standard is exploited as the media access control (MAC) protocol. The simulation time is 500 s, and the result in the figure is the average value of 100 times of our simulation.
Simulation results
Figure 7(a) shows the path length according to the end-to-end distance. In the figure, we observe that the path length of the proposed architecture is 6.92 hops when the end-to-end distance is 70 m; however, the path length of the directed diffusion is 23.40 hops. In directed diffusion, the data packets should be passed via one or two sinks since all data are forwarded toward the sinks. The fixed data flow causes the data detour and the path length becomes longer. In our architecture, although the data do not need to pass the sink nodes, the data packets are forwarded according to the social metrics and the path length could be reduced.
Simulation results: (a) path length impacted by the end-to-end distance and (b) delay impacted by the end-to-end distance.
Figure 7(b) presents the delay impacted by the end-to-end distance. In typical WSNs, the end-to-end communication delay is proportional to the path length and end-to-end distance. In order to support the interactive service, shorter delay should be required. We observe that the delay in our architecture is 207.71 ms (when the end-to-end distance is 70 m) although the delay in directed diffusion is 702.08 ms. The result shows that the proposed architecture could reduce the end-to-end delay.
Challenges
This section presents some research challenges of the SWSN architecture.
Thing identifier
The SWSN architecture requires the identifiers to distinguish each service and thing in the network. All things should have their identifiers, and all sensors should be able to detect the identifiers of things. WSN treats these identifiers as string data to distinguish services and things, not as an address. Also, well-defined rules of identifiers could make the service management easy and flexible even if lots of services are deployed dynamically in a domain.
The mitigation of fluctuation
It is possible for sensors to change the sensing state repeatedly according to the slight movement of things at the boundary or around the threshold value in WSNs. These meaningless switches can cause the fluctuation of topologies of SWSNs. That is, it can increase the traffic of service subscriptions and sociality profiles over the configuration network and increase the binding overhead of social gradients at the social sensors. Therefore, the optimization researches are needed to prevent these kinds of overhead and to guarantee dynamicity of the SWSNs along the movements of things at the same time.
Mobility supports
The service subscriptions of things will trigger the dynamic configuration of SWSNs. As the mobile-active things move, their periodic service subscriptions will make the social sensors re-selected and trigger the data flows to be updated along the movements. Eventually, the synchronization accuracy of SWSNs along movements is proportional to the period of service subscription of mobile-active things. The more frequent service subscriptions exist, the faster configuration of SWSNs will be possible. But it could increase overhead at the configuration network if mobile things move slowly or even stay at a point. Therefore, the optimization researches are required depending on the mobile pattern of things, the period of service subscriptions, and the overhead of WSN.
Optimized topology per SWSN
An SWSN is a part of overall structure of the physical WSN that connects only related sensors for a service. Therefore, data are delivered basically through the network topology and routing algorithm of the physical WSN. But there can be some services that require different kind of topologies such as linear, ring, tree, and full-mesh and specific routing algorithms such as geographic routing and optimistic routing for the service efficiency. For those services, it is needed to research their own network-structuring mechanisms and routing algorithms among social sensors for each SWSN apart from ones of the physical WSN.
Conclusion
As the proliferation of IoT, a new type of service, the device-to-device interactive IoT service, has been growing recently. The services are provided by direct inter-operations among particular sensors and devices under a sociality according to the purpose of each service. In this article, we propose the SWSN architecture to apply the sociality over traditional WSNs dynamically and flexibly. We introduce SWSN functions such as the sociality profile to define sociality, the service subscriptions to auto-select social sensors, the social gradients to determine data flows among social sensors, and the social communication binding for efficient communications. We have shown the feasibilities of the architecture and functions with a use case as well. This architecture supports flexibly multiple kinds of independent IoT services over WSNs. It also makes the custom-design of services auto-configurable according to the sociality of services. Therefore, we expect that the SWSN architecture could make contributions to the development of customer-centric IoT services despite of many remaining challenges.
Footnotes
Academic Editor: Hideyuki Takahashi
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the ICT R&D program of MSIP/IITP (B0101-16-0024, Terabit optical-circuit-packet converged switching system technology development for the next-generation optical transport network).