Evolution of wireless sensor network design from technology centric to user centric: An architectural perspective

Abstract

Wireless sensor networks form the crux of a wide range of automated applications that are gaining popularity with every passing day. The journey of wireless sensor networks has seen simple sensory monitoring to sensing-processing-actuation based end-to-end applications to the design and deployment of highly sophisticated service-oriented use cases. This highly disruptive field has seen rapid transformations to gain insights and assess the relative merits. Demerits of competing design strategies, it very important to know the evolutionary milestones this technology has undergone in achieving the state-of-the-art in this area. In this article, a systematic review is carried out that captures the evolution of architectural designs and developments in wireless sensor network–based applications. This review delves into the relative pros and cons of various epochs in developments and delineates the future areas of research in wireless sensor network design paradigm.

Introduction

Wireless sensor networks (WSNs) comprise a large number of sensor nodes which are generally used for various applications, such as target tracking, pressure monitoring, health monitoring, fire detection, and so on. The sensor nodes consist of transducers, radio transceiver, and wireless interfaces that are used to gather data from the environment. These inexpensive, small sensors form the network with group effort to perform the tasks as per their needs. To measure the change or property of environment, various kinds of sensor nodes such as biosensors and thermal, mechanical, magnetic, optical, and chemical sensors can be connected with node. ¹ As sensor nodes consist of limited battery life, memory, processing power, and are installed at remote places (difficult to access), radio signal is used to perform the communication between the source and the base station. In general, WSN has little or no infrastructure and broadly can be categorized as structured and unstructured sensor networks. ² In structured WSN, nodes are deployed in a preplanned manner in which a few nodes may be placed at specific locations for better coverage. The network and cost maintenance of these nodes are lower than those of unstructured networks. In unstructured WSNs, nodes are densely and randomly arranged in the field. After the deployment, nodes need to be unattended to perform their tasks like monitoring, gathering, and transmitting data from the environment. In unstructured sensor networks, connectivity, failure detection, and network management are tedious task because of random deployment. ³ In unstructured WSNs, network issues and connectivity failures are the norm primarily due to random deployments. Thus, ensuring network connectivity, failure detection, and network management are non-trivial tasks. This is unlike structured WSNs. To achieve a high level of coverage and connectivity, mobile nodes may be used in unstructured network. Nowadays, sensor nodes can be deployed on the field, under field, and underwater. With respect to deployment area, sensor networks may face different constraints and challenges.

Based on the deployment technique and its application, the WSNs can also be classified into five types, namely, multimedia WSNs, mobile WSNs,^2,4 underground WSNs, terrestrial WSNs, and underwater WSNs. Multimedia WSN comprises low-cost sensors that are equipped with microphones and camera. These multimedia nodes are used to track events such as audio, video, and image. Such nodes communicate over wireless channel to gather, process, correlate, and compress the data. For guaranteed coverage, multimedia sensor nodes are arranged in a preplanned manner. Challenging issues in multimedia sensor network include energy consumption, data processing, quality of service (QoS) provision, data compression, high bandwidth requirement, cross-layer design (CLD) requirements, and so on. QoS provisioning is a challenging issue due to variable link capacity in multimedia WSNs. Mobile WSN comprises a number of mobile sensors that interact with the environment. The node has functionality to sense, compute, and communicate with other nodes. Unlike static nodes, these nodes have the ability to organize and reposition itself in the network. The collected data may be transferred within the coverage range of sensor nodes. Some issues with mobile WSNs include navigation and control, energy, deployment, maintenance, self-organization and localization, and so on. Underground WSNs comprise sensor nodes which are deployed in an underground mine or in a cave to observe underground conditions. In such networks, a few additional sink nodes may be placed on the surface (above the ground) to transmit the information from nodes to the base station. The deployment planning must be done more carefully than terrestrial networks because of loss of signal, energy, attenuation, and cost. To improve the energy level of node and network lifetime, many efficient communication protocols have been suggested for use for communication. To build the terrestrial WSNs, a number of low-cost sensor nodes, ranging from a hundred to thousand, may be deployed either in an ad hoc or predetermined manner, in the specific region. In ad hoc manner, nodes may be deployed randomly in the specific region. In a predetermined manner, nodes can be deployed with various methods such as grid deployment, two-dimensional (2D) deployment, and three-dimensional (3D) deployment. In such networks, energy consumption can be minimized by optimal routing, short-range communications, and redundant data elimination among others. Underwater WSN consists of sensor nodes and vehicles which are sparsely deployed under the water. In such networks, sensor nodes are more costly than terrestrial WSNs. Underwater vehicles are used to collect data from the deployed sensor nodes. In general, acoustic waves are used for underwater communication. In underwater environment, the primary issues faced are propagation delay, limited bandwidth, and signal fading. Some other limitations of underwater WSNs are energy, self-configurability, adaptability, and node failure due to ocean environment. In this article, we have carried out a detailed study of application-based architectural approaches. We have categorized the approaches into communication perspective, traditional layered architecture, cross-layer architecture, conventional cross-layer, complex cross-layer, unified layered architecture, middleware-based architecture, and service-oriented architecture (SOA) for WSNs. We have discussed the advantages and disadvantages of various approaches systematically. This article provides a roadmap toward architectural framework development using SOA for application. The remainder of this article is organized as follows. Section “WSN and its communication architectural frameworks” shows the various approaches for WSN architecture design, section “Evolution of architectural design and development: application perspective” presented the evolution of architectural design and development: application perspective, section “Cross-layer architecture” shows the cross-layer architectural design and systematic comparison of various approaches, section “Middleware approaches for WSN” presented middleware approaches for WSNs, section “Leveraging SOA for WSN” presented leveraging SOA for WSNs, section “Lack of common framework and reusability” shows the lack of common framework and reusability, and section “Service-oriented middleware for WSN” presented service-oriented middleware approaches for WSNs.

WSN and its communication architectural frameworks

WSN is a collection of numerous autonomous linked sensor nodes that work together to sense changes in the environment such as vibration, humidity, temperature, noise level, pressure, and so on.^5,6 WSNs can also be used for detection of mobility and location of an object like a vehicle. Basic communication architecture is depicted in Figure 1. In general, WSN has no common architecture which may be applied to all its different taxonomy categories due to different constraints and issues.^4,7 Therefore, various WSN architectures have been proposed by various designers as per the application needs. ⁸

Figure 1.

Architecture of the WSN.

Existing architectures of WSN can be classified as follows: data-centric architectures, hierarchical architectures, location-based architectures, mobility-based architectures, QoS-based architectures, network flow architectures, multipath-based architectures, and heterogeneity-based architectures.

Data-centric architecture can be described as random deployment of large sensor nodes where nodes interact with each other without global network ID. In the absence of global ID, it is difficult to select the specific node for query. Therefore, generally, data can be transferred via every node in the region which is inefficient in terms of energy consumption. In Sensor Protocols for Information via Negotiation (SPIN), routing protocol has been given to minimize the problem of redundant data and energy consumption. ⁹ Many other methods have also been proposed in for direct diffusion. The aim of this type of architecture is transmission of data by the use of the most efficient route. To achieve scalability in the sensor network, data-centric architecture is not suitable. Taking into consideration, hierarchical architecture is useful to achieve scalability in a large area network. In hierarchical architecture, the sensor node builds the group with a cluster head. To bring about communication between cluster heads and in the same cluster, cluster head form intercluster and intracluster. Cluster heads collect the data from the sensor nodes and send the data to the base station using multihop routing mechanism. Various approaches have been set to support the hierarchical architecture such as low-energy adaptive clustering hierarchy (LEACH) and so on. ¹⁰ The aim of this architecture is to maintain power consumption in a large network. In location-based architecture, the routing algorithms depend on the location of sensors to send and receive the packets. Sensors may obtain their location using different mechanisms like Global Positioning System (GPS) receivers, triangulation, or by placing the sensors at known locations. Various algorithms have been proposed to reduce the power consumption in data routing. Example algorithms include trajectory-based forwarding (TBF), ¹¹ an anchor location service (ALS), ¹² and so on. Mobility-based architecture assumes that the sensors (sink, intermediate, and source) may change their locations dynamically with respect to time. The routing and connectivity is difficult in the mobility-based architecture. To make the network connected, sensor requires more energy than static network. Therefore, with few assumptions (nodes may move in stationary network), various methods have been suggested such as source encrypted authenticated data (SEAD), ¹³ data MULEs (mobile data collector), ¹¹ and so on. The QoS architecture can be defined based on the requirements such as reliability, delay, energy, and so on. This architecture is required to send and receive the data as per predefined parameters. QoS architecture is a complex architecture due to maintenance overhead. The process of optimization across the sensor link is known as network flow-based architecture. The links may be defined based on different parameters like latency of data transfer, power consumption, and delay between two sensor nodes. The goal of this kind of architecture is to find the optimum route with predefined parameters. Examples of architecture are minimum cost forwarding, maximum lifetime routing, and maximum lifetime for data gathering and aggregation. In this architecture, sink and source node can be connected through different paths. The multipath-based architectural method is useful in the distribution of the data payload on different paths as well as for real-time data streaming where more reliability is required. Some methods have been presented in Lou. ¹⁴ The aim of such architecture is power efficiency and reliability. Heterogeneity-based architecture may be defined based on different kinds of tasks and types of sensors such as sensing, communication, battery-operated nodes and nodes with power consumption, and so on. Various architecture comes into this category such as energy efficient heterogeneous cluster (EEHC) and so on. ¹⁵ The goal of this architecture is the best use of available nodes as resource.

WSN is an application-centric network designed as per constraints and requirements of an application such as communication services, energy, routing, security, lifetime of network, QoS, and so on. Therefore, various sensor network communication architectures have been suggested.^16–18 From the application perspective, the communication architecture of WSNs is broadly categorized in to four categories, namely, (1) traditional architecture, (2) layered architecture, (3) cross-layer, and (4) unified layer. The traditional architecture has also been classified into two-tier architecture, ¹⁹ three-tier architecture, ²⁰ and multitier architecture. ²¹ The layered architecture consists of five layers and three cross-planes. Cross-layer architecture follows the concept of layered architecture but divides the layers in the form of services and interfaces. The design of service and interface follows the conventional ²² and complex approach. ²³ Unified layer is a layer-less approach to provide service in communication.^24,25 In this approach, all the service will be on the same plane and there will be proper interaction with interfaces. So, the services can be accessible as per the need without unnecessary communication between the layers.

The design and development of general architectural solution for WSNs is not trivial due to constraints such as application, energy, and network and deployment. Therefore, to design and develop the architecture for WSNs, architectural characteristics needs to be followed which also describes the challenges of it. The general characteristics of architecture are as follows:

• Scalability: Scalability supports increases in network size without affecting the network performance. Efficient architecture should be capable enough to maintain the performance level as network size increases.

• Flexibility: Flexibility is one of the important characteristics for any architecture. It can be described as coupling and decoupling of services without affecting the network. In WSNs, researchers and developers have proposed various solutions based on requirements and existing service. So coupling of those services should be allowed for any application with the performance level and also decoupling to improve performance. Therefore, architecture should be flexible enough to support different available services.

• Dynamic network organization: In the WSN, network topology changes dynamically due to reason such as interference, node mobility, device failure, and so on. The architecture should be capable enough to maintain the network with dynamicity. Traditional architectures are enriched with the static service such as bandwidth, processing power, topology, and so on, but in WSNs, these are dynamic. In general, the architecture should have capability to maintain these resources to make the network functional. In WSNs, nodes require their locations in the network with the different methods which may not be possible in architecture without application knowledge and parameters. So any architecture should support resource and service discovery in dynamic network.

• Real-world integration: Real-world integration is important to design and develop the architecture. Time and space are most important factors because WSN applications deal with real-world events. So, to maintain data consistency, the architecture should be capable to provide real-world services and their integration with the network.

• QoS: This can be described as per the perspective of researchers. In WSN perspective, QoS can be described in terms of network and application specific. Initially, application-specific (localization) QoS parameters such as node deployment, reliability, accuracy, and so on were used. Presently, the network-specific parameters like power consumption, bandwidth, and so on are more common ones. In traditional architecture, QoS parameters have been used for wired network which is not suitable for WSNs because of wireless connection limited power and topology dynamicity. Therefore, any architecture should maintain the QoS parameters to meet the application requirements.

• Application knowledge: Application knowledge provides the way to design and develop new architectural solutions for applications. In WSN perspective, detailed knowledge of sensor network applications helps to develop the architecture for the specific application. It helps service providers to map communication requirements to network. Most of the architectures are application specific, but in general, architecture should support an extensive range of applications.

• Heterogeneity: Heterogeneity support is an important characteristic of any architecture because it forms the bridge to fill technological gap. It provides the interface between different components, programming models, and hardware. Therefore, architectural solutions should support heterogeneity. In WSNs, the aim of the software framework is to make sensor network functional as per the applications. To consider the various requirements in WSNs like QoS, network requirements, performance, and deployment efficiency, software architecture is needed.^26–29

WSN applications have been increasing every day along with dynamic requirements; therefore, to adapt the changes and requirements, software architecture should be flexible to incorporate the changes. Various SOA-based software architectural solutions have been suggested to build the WSN applications.^30–33

Evolution of architectural design and development: application perspective

In this section, we discuss detailed design and development of application-based architectures. The review of existing communication architectural developments for WSNs and their adaptability as per the application’s need is done. ³⁴ The architectural development for WSNs is categorized as follows: tiered architectures, layered architectures, cross-layer architectures, and SOA-based middleware architectures. ³⁵ Since WSN is an application-based network, it is convenient to describe the architectures as per the need of applications and their limitations. In this section, a brief literature survey on various perspectives of technological developments of WSNs at the architectural level is presented. ³⁶

Two-tier architecture

Two-tier WSN architecture consists of application nodes, gateway, and sensor nodes, depicted in Figure 2. ¹⁷ The application node and sensor nodes communicate with each other within the same cluster. In this architecture, sensor nodes collect data from the environment and application node sends the data to the cluster head. The cluster head communicates with other cluster heads to send the collected data to the gateway or base station. Due to the fault in the transmitter, data may not be collected from the cluster head. Therefore, communication link is required to recollect the data from other cluster heads.

Figure 2.

Two-tiered sensor network architecture.

Three-tier architecture

Two-tier architectures are not suitable to send the data when coverage area is increased. If large sensor nodes are deployed for observation, then midrange communication module will be required to connect the local sensor nodes to the central station to cover the large area. To this end, a three-tiered architecture was proposed by Han ²⁰ and shown in Figure 3. This architecture supports the long-range communication network (LRCN), midrange network (MRN), and linear wireless sensor network (LWSN). The LRCN is capable to send the data to server using the Internet. Multirobot sensor network system can transmit the data up to 16 Km. The LWSN is suitable for short-range devices (up to 100 m) and is generally used for communication from sensor nodes to the gateway.

Figure 3.

Block diagram for the three-tier WSN monitoring system.

Multitier-tier architecture

Meena et al. ²¹ have proposed the distributed multitier clustering approach for WSNs to improve the performance of network in terms of lifetime. In this approach, authors have proposed multilevel cluster heads. The higher level cluster head is responsible to transmit the data to the base station.

Communication architecture of WSNs is broadly categorized as layered architecture, cross-layer architecture, and unified layered architecture.

Layered architecture

The layered communication architecture is also known as the Open Systems Interconnection (OSI) model. Most common architecture of WSNs follows the OSI model. In layered communication architecture, both sink and source nodes transmit the data. The communication architecture consists of five layers (i.e. application layer, transport layer, network layer, data link layer, and physical layer) and three cross-planes (i.e. power management plane, mobility management plane, and task management plane).^37,38 The power management plane deals with the power consumption of the node, the mobility management plane identifies the mobility of node and maintains the information of neighboring nodes, and the task management plane is used to schedule the sensing task in the given area (Figure 4).^4,39 As per the need of sensing task, different software may be developed and employed in the application layer.

• Physical layer: The physical layer provides the interface to transmit the bit stream over the physical channel. The main task is frequency generation, detection, and selection. Pertaining to this layer, the standard of IEEE 802.15.4 is described for WSNs with low power consumption, cost, data rate, complexity, and communication range to increase the battery life. ⁴⁰ It also deals with designing of mechanical and electrical interfaces.

• Data link layer: It is responsible for the medium access, multiplexing of data stream, frame detection, and error control. This layer ensures the reliable connection among point-to-point and point-to-multipoint communications. In the context of WSNs, this layer performs some basic tasks, namely, energy efficiency, maximization of the throughput, self-organizing capability by hop-to-hop communication, and efficient sharing of communication resources between sensor nodes as per the requirement of applications. The traditional medium access control (MAC) layer is suitable for infrastructure-based networks but cannot be used for WSNs.

• Network layer: In the context of WSNs, the network layer is designed under some basic assumptions such as (1) sensors location awareness, (2) attribute-based addressing, (3) sensor network’s data-centric nature, (4) power consumption, and (5) data aggregation. To save power, this layer follows various routing mechanisms, such as minimum energy route, minimum hop route, maximum power available route, and maximum–minimum power available route. It is also responsible to connect the external network.

• Transport layer: Since WSN is application-specific network and different applications can have different needs, the transport layer should be application specific. For example, downward demands are more reliability than upward. The designing of the transport layer protocol is a challenging task because of inherent constraints like limited power and memory. ⁴¹ The storage of a large amount of data and acknowledgment in the sensor node turns out to be costly in terms of power. ⁴² Therefore, communication in the network is divided into User Datagram Protocol (UDP) and Transmission Control Protocol (TCP)/Internet Protocol (IP) for sensor networks and the Internet, respectively.

• Application layer: This layer provides the management level functionality as per the requirement of user and application. It also deals with the issues of time synchronization, task management, security, and sensor node configuration (i.e. status of node). ⁴³ Although various application level services are already developed, it remains a challenge to develop other application level services to provide higher level of services. Ramesh ⁴⁴ has proposed a protocol architecture for application-specific WSNs. However, the proposed architecture has two basic problems, namely, interoperability between the system components and lack of common framework to build new services. In WSNs, applications are custom built without standardization in communication protocols which implies that there may be no interoperability between the components developed by different research communities. Further, there is no common architecture for the developer to develop services, and hence, they are forced to develop the service from scratch. With the common framework, a developer can save the time. Various standard protocol architectures are suggested for communication in WSNs which may include the composable framework and resource awareness. The architecture includes the sensornet protocol (SP), which is the linking interface between network layer and link layer to abstract the functionalities of link layer and offer the service to network layer (Figure 5). Its major problem is adapting with the network protocols to programmer.

Figure 4.

Layered communication architecture.

Figure 5.

Adaptive communication architecture.

Jiawei et al. ⁴⁵ have presented adaptive communication architecture for WSNs which resolves the problem of communication in heterogeneous networks. The architecture adapts a wide range of communication mechanisms from the transport layer to the MAC layer without changing the protocols or applications. The adaptive communication architecture supports sensor network, MAC, and link layer protocols.

The modular network layer has been brought out by Chen et al. ⁴⁶ The main objective of the approach is to achieve code reusability and run time resource sharing. The suggested approach allows decomposition of the network layer into smaller components which may be used by other protocol at run time. It maximizes the composibilty and reusability of protocol module. As mentioned by Dunkels, ⁴⁷ full TCP/IP is not suitable for WSNs due to the dependency in the adjacent interfaces. WSN has memory constraints, but it requires too many resources (memory usage and code size). Paek et al. ⁴⁸ suggested an architecture to resolve the problem of existing programmed wireless communication system. The author suggested application-specific research due to rapid increase in hardware and software platforms in sensor networks. Zhibo Pang et al. ⁴⁹ have presented design of real-time operating system architecture for WSNs. A general purpose stack may not fulfill the need of application-specific sensor networks. The issues are (1) How many layers can there be in a protocol stack for future sensor network? (2) How the network stack will be tuned with application-specific sensor networks? And it is suggested that traditional protocol stack is not suitable for wireless ad hoc sensor network (WASN). The reasons are irrelevance of some TCP/IP services, like error control at both MAC and transport layer; flow control at the transport layer; inclusion of new services as per the application requirement; and energy optimization. These services may not be generic for every application so the stack should be application specific.

Vehicular ad hoc network is application specific, so it has different requirements for communication types, self-organizing, and management. ⁵⁰ To meet these requirements, existing structure of the protocol is not suitable to incorporate these requirements. Therefore, staircase stack suggested incorporating the requirements as per the application shown in Figure 6. This architecture is useful for data collection with collaborative nature.

Figure 6.

Staircase architecture.

In Pang et al., ⁴⁹ the proposed approach of sensor stack is used to adapt to the dynamic changes in the network. Traditional layered architecture is not feasible to add the service in between layers due to strong coupling and interface dependency. Therefore, Kumar et al. proposed an information exchange service (IES) as a service broker and its integration with sensor stack architecture (Figure 7). Sensor stack provides the functionality of sharing the data of node through the bulletin board. The sensor stack is not flexible enough to employ in the network.

Figure 7.

Sensor stack architecture.

Pros and cons of traditional communication architecture

Traditional communication architectures are generally used for networking framework in which services are implemented at each layer. Every layer has its own functionality to interact with its adjacent layers using different services and procedure calls. It minimizes the complexity by dividing the communication services in fine chunks. The layers are strictly coupled and placed adjacent to each other so communication among non-adjacent layers is not possible without any modification. With an increasing number of applications in wireless network, developers have to be ready to handle future requirements and new technologies.

Cross-layer architecture

Traditional layered communication architectures like the OSI model splits the networking task into layers and defines the services provided by each layers. The architecture prevents direct communication among the non-adjacent layers, and adjacent layers are restricted to produce calls and response. To design the communication protocol, the designer may design the protocol either with the rules or by violating the rules of traditional architecture.^51–54 By violating the rules, the designer can give solutions for direct communication between non-adjacent layers using shared variables. Such violation of traditional architecture is CLD with reference to layered architecture (Figure 8).

Figure 8.

Architectural design of crosstalk.

CLD was a new paradigm of network architecture which included functionalities of dependent layers and supported optimization. ¹³ The basic principle to design the cross-layer was crossing the defined boundaries of well-defined architecture, thus expanding opportunities beyond layer boundaries. In this research area, reliable and efficient wireless communication was the focus, and many authors have proposed design approaches of cross-layer architecture.

The authors have categorized the the CLD approach based on the criteria ¹¹ such as interaction between the physical and link layer and interaction of the physical and link layer with the upper layer (Figure 9). The CLD was initiated from the traditional layer approach and was later transformed into a layer-less approach. Such approaches are classified as follows:

• Conventional CLD approach

• Complex CLD approach

Figure 9.

Cross-layer optimization interface.

Conventional CLD approaches

In this approach, traditional layered architecture is designed and maintained for the communication between adjacent layers with well-defined interfaces. The communication can be either from upward to downward or vice versa. Upward interaction may be a feedback technique to improve the system performance. ⁵⁵ Few prioritized message can be transferred downward. These approaches had to strike only for a few message exchanges. To maintain cross-layer, the approach is classified as direct communication between layers, shared database across the layers, and new abstraction as shown in Figure 10.

• Direct communication between layers: In this approach, layers can directly share the information with each other at run time as shown in Figure 11. This approach is applicable only when the application needs to share the information at run time. Wang and Ali Abu-Rgheff ⁵⁶ have given an approach of cross-layer signaling shortcut (CLASS). The CLASS is flexible and efficient to propagate messages with standard layered architecture. This architecture has internal and external signaling scheme as depicted in Figure 11. It has some advantages such as low overhead and propagation latency and the disadvantage that at each layer, additional code blocks slow down the execution which also affects the performance.

Figure 10.

Architecture of shared database.

Figure 11.

Cross-layer signaling shortcut.

Sheikh and Mahmoud ⁵⁷ had proposed cross-layer technique to improve the performance of routing technique (Figure 12). This approach focuses on path selection, channel selection, and allocation of transmission power for smart routing in the WSN. For smart routing decision, direct signaling is used to share the information between the protocol layers with no delay. The upward communication is used to share information like the energy level, data processing, and sensing range between the physical and application layer. The MAC layer informs the application layer about the quality of link, and the network layer shares the information about the network path. The downward communication shares the information about the next hop, power, and bandwidth as per the application. This architectural technique provides the way to think the application-based routing.

• Shared database across the layers: In traditional layered architecture, there is no common database which can be shared during the run time between all the layers. More delay and energy consumption results between non-adjacent layers due to unknown processed information at specific layers. Therefore, shared database approach is required between the layers. Su and Lim ⁵⁸ have proposed a common repository to all the layers as an optimization agent (OA; Figure 13). The OA stores information such as the node energy level, ID number, hop count, link status, and so on. With the OA layers, one can access the available information from the repository. The available information is the feedback for all the layers. It is flexible enough to optimize the information sharing without redesigning the protocol, which increases the energy consumption, but increases power consumption due to the application programming interface (API).^55,59,60

Figure 12.

Cross-layer architecture.

Figure 13.

Cross-layer optimization framework.

M. Hefeida et al. ⁶¹ had proposed a CLD for WSNs known as cross-layer application-aware paradigm (CLAP) shown in Figure 10. This approach allows all the layers to share their local information among other layers. The application layer is able to change the data of the other layers. All the communication is managed by the information layer (I-layer) and does not permit the involvement of any other layer in the communication without its requirements. Merlin et al. ⁶² had proposed repository-based architecture to store the information which may be required for all the layers (Figure 14). This proposed architecture maintains the principle of traditional layered architecture to ensure that all functions will be performed at each layer for the communication. The cross-layer optimization interface (CLOI) maintains the information about incoming and outgoing packets.

• New abstraction: It is the new way to organize any protocol for the rich interaction using building blocks (BBs). It provides flexibility during the run and design time. Lou et al. ¹⁴ have proposed SOA-based WSNs (Figure 15) to enhance the lifetime of network using on/off scheduling at the MAC layer and availability of service at the application layer.

Figure 14.

Cross-layer optimization architecture.

Figure 15.

System model for conventional cross-layer design.

It comprises three layers: service sublayer, service composition query sublayer, and service composition sublayer. The service sublayer collects the information from the sensor in the overlay network, the query sublayer makes the query for the required information, and the composition sublayer finds the information from the other two layers.

Pros and cons of conventional approach

• • Pros

• It gives the complete view of traditional layered communication architecture for wireless and wired medium.

• It gives the flexibility to add the new interface in traditional architecture.

• In this approach, information can be shared by either direct or indirect signaling mechanism.

• All the information about the layers can be shared by the common repository.

• It minimizes the communication overhead among the layers if there is no role of adjacent layer in the communication.

• • Cons

• Cross-layer feedback would be difficult to update.

• Additional code block reduces the throughput of the layers.

• It needs special mechanism to avoid the failure of common repository.

• It is difficult to ensure the correctness of algorithm due to multiple layer optimizations. ¹¹

Complex CLD approaches

The basic principle in the conventional CLD approach is to integrate and merge the functionality of two or more layers. Energy requirements for sensor network applications may vary as per data aggregation and computation power capabilities. Therefore, to increase the lifetime of network, energy-efficient hybrid algorithm has been suggested by Kaur and Mahajan. ⁶³ Li et al. ²³ have proposed a framework to minimize the energy consumption with the QoS requirements shown in Figure 16. The data link layer, physical layer, and requirements of the application layer are combined into a single framework. It is implemented over the clustered network in which the level of transmission and modulation can be changed. In the cluster, the cluster head and node adopt the modulation scheme adaptive code positioning module (ACPM) and binary phase shift keying, respectively. With experimental QoS parameters, power consumption, end-to-end delay, and packet loss have been analyzed.

Figure 16.

System architecture complex cross-layer design.

Lin and Li ⁶⁴ have proposed triangulation cross-layer architecture for WSNs. In this architecture, the author presents ways to merge and minimize the layers as per the functionality shown in Figure 17.

Figure 17.

Triangular cross-layer architecture.

In triangular cross-layer architecture (TCLA), three layers, that is, application, session, and presentation, are merged into application module (AppM). Network module (NetM) comprises transport and network layers and linking module (LinkM) combines the physical and data link layer. AppM deals with application-related aspects; NetM is responsible for congestion control, routing, and resource allocation; and LinkM handles the transmission-related aspects. Each module has its own agent to exchange information.

Song and Hatinakos ⁶⁵ have proposed a target tracking protocol for the densely deployed WSN. In this approach, the MAC and application layer perform direct communication as shown in low energy self-organizing protocol design (Figure 18). CLD can be achieved by the elimination of the transport and network layer. It also deals with QoS parameters like error and energy consumption in target tracking application (Figure 19).

Figure 18.

Low energy self-organizing protocol design.

Figure 19.

Architectural component of TinyCubus.

Pros and cons of complex design approach

• • Pros

• This approach increases the life span of the network and fulfills the requirements of QoS.

• It provides flexibility and adaptability for the heterogeneous hardware and applications.

• It reduces the overhead of information exchange across the layers.

• It shows the way to merge two or more layers and also allows the unidirectional or bidirectional communication in non-adjacent layers.

• • Cons

• The architectures are application specific and not general.

• Improper merging of layers reduces maintainability and might interfere with communication at other layers.

• In this approach, debugging is difficult.

• This approach is more error prone.

• No standard rules to merge two or more layers.

Comparison between traditional and cross-layer approach

Unified layered architecture

WSNs are application-specific networks which may be applied in the industrial or civilian field as per the requirement, for example, pervasive computing. ⁶⁶ In a sensor network, nodes can be deployed for different purposes like pressure monitoring, object tracking, temperature monitoring, data collection, and so on. For the communication, traditional and cross-layer architectural approaches have been given by different research communities (Table 1). Traditional and wireless (IEEE 802) architectural approaches are not suitable for WSNs due to the specific characteristic that differentiates them from wired and wireless networks ⁶⁷ (Figure 20).

Table 1.

Traditional versus cross-layer approach.

S. No.	Traditional layer approach	Cross-layer approach
1	It prevents the interoperability between homogeneous systems and restricts the functionality to specific layers.	In this approach, optimization can be achieved at every layer to improve the performance of network and network lifetime.
2	In this approach, optimization may not be achieved due to the strict coupling between the layers.	Existing interlayer dependencies motivate cross-layer.
3	This approach is technology specific and not application specific.	Cross-layer approach is application and technology specific.
4	Modification in the layered architecture is difficult, change in one layer leads to change in consecutive layers.	Interface can be added between the layers as per the application requirements.
5	In this approach, layers have no provision to make the decision jointly with the direct communication among non-adjacent layers.	Cross-layer approach helps to do self-configuration of the nodes.

Figure 20.

Chip-level augmentation of IEEE 802.15.4 PHY.

WSN has constraints such as network lifetime, energy, transmission range, and so on. By taking into consideration the constraints, the authors have proposed unified layered architectures for WSNs. ²⁶ Unified layered approach is a layer-less technique as shown in Figure 21. The benefit of unified architecture is that it allows the integration of different services which are developed for different tasks in different environments by different research communities. The unified layered architecture is useful from the perspective of technology development in WSNs. Various researchers have given the approaches for different applications using the unified layer.

Figure 21.

Unified layered architecture.

Unified layered approaches for WSNs

In the unified layered approach, users can communicate and manage the network using the application layer. ²⁶ It provides ways for the developers to develop the application without knowing the underlying characteristic of WSNs. Vuran and Akyildiz ⁶⁸ have developed a cross-layer protocol for WSNs. The entire traditional layers have been replaced by a single layer, and all the functionalities of traditional layers are included in it. This architecture ensures reliable communication with minimum energy consumption. Chen Hsiang Feng et al. ²⁴ have presented unified protocol stack for WSNs for the integration of different protocols in one stack. The block diagram is depicted in Figure 22. This architecture includes the group of interfaces, which makes seamless communication between the same and different layers. Jinman Jung et al. ⁶⁹ have developed a unified framework for protocol simulation on the sensor operating system. It can be used for end-user device and local sensor network. The user can monitor and collect the data from the sensor node using the interface.

Figure 22.

Packet flow diagram for the UPS framework.

Middleware approaches for WSNs

With advancement of technology (in microelectronics and wireless communication), WSN offers a wide range of applications. The application development and integration with real-world environment is not an easy task. Therefore, middleware is required for the development of large-scale distributed applications. The advantages of the middleware include (1) simplification of complex application development; (2) it provides the interface for the abstraction, reusability, communication between components, and integration; (3) it hides the implementation details of the underlying heterogeneous platform, communication details, and distribution. ⁷⁰ The development of middleware is not an easy task due to various constraints like integration with real world, hardware, heterogeneity, scalability, network optimization, application knowledge, and so on. ⁷¹ Various designs and approaches have been suggested as a middleware for WSNs. Some middleware approaches shall be be presented in this section. In Coronato, ⁷² a service-oriented middleware architecture Uranus has been suggested as a platform to integrate biomedical sensors for health monitoring application. The application correctness and recovery is tested at run time with a case study.

Alshinina and Elleithy ⁷³ presented a middleware virtual machine, namely Mate, for the communication for WSNs that can be applied in the reprogrammable networks. Reprogramming for WSNs needs more energy than the deployment in the unmanned area. Mate is an interface that executes complex programs in short which reduces the energy cost to transmit the program. This approach gives the new paradigm to upload the program with parameter correction of the program as per need. Mate is developed on TinyOS which is designed for WSNs to execute the operations at the middleware level. To build the WSN functions, after deployment, it uses the byte code which is divided into 24 instructional capsules. Sending and receiving capsules are useful to deploy ad hoc routing and data aggregation. The application of this approach is to break large programs into many capsules, and these capsules can be executed in the network. Virtual machines consist of logger, scheduler, network, and hardware. To communicate, a synchronous model is used because it enables developers to develop the application-level programs in a simple way. The goal of Mate is to handle sensor networks which have a dynamic nature. This is an architecture and code which is required to develop applications. Marcello Cinque et al. ⁷⁴ have discussed the need of resiliency in WSN applications for the adoption of protocols and platforms. The authors presented the simulation, assessments, and critical analysis in various categories. Alessandro Testa et al. ⁷⁵ have proposed an approach to analyze the effect of undesired events over reliability constraint. Effect of this type of event must be identified before the development and deployment of applications. In this approach, a heuristic method is used to do the analysis using event calculus, and also, it is useful for the system designer to check the reliability level of applications. As a case study, a static methodology had been suggested for checking the correctness of the designed model. ⁷⁶

Internet of Things (IoT) applications are increasing rapidly to solve the real-life problems such as monitoring of health, traffic, surveillance, and so on. To collect the data from various sources, IoT networks use sensor devices. Therefore, various issues are also involved in IoT network such as energy constraint, lifetime of network, security, resource management, and so on. IoT network consists of heterogeneous type of devices to collect the data from the sources. Energy and heterogeneity are major issues in the IoT-enabled network. Various solutions have been suggested to deal with heterogeneity and energy efficient issues, but all are technology centric.^35,77,78 So user-centric middleware technique has been suggested to solve the issue of heterogeneity using three modules, that is, data collection, interface, and heterogeneous network. In previous studies,^79–81 resource management has been investigated with TinyOS, FreeRTOS, and Contiki which are popular operating system for various parameters like memory, process, energy, and communication management. In Tanganelli and Curado, ⁸² security method is suggested for the IoT data, and DC-Net is implemented over the real-time sensor nodes to achieve the high-level confidentiality. In this approach, a reliable data collection and propagation method has been suggested using a cloud- and fog-based identification system. In addition to this, DC-NET is implemented over the constrained devices. And for securing the IoT devices, various private communication methods have been discussed. Recently, context-aware computing for IoT management has been gaining popularity. ⁸³

Leveraging SOA for WSNs

There has been a lot of developments in service-oriented computing paradigm using services as the central element of the design. One of the major goals of any technology is to provide services to the users, and such approach was proposed by Kim et al. ⁸⁴ and Alshinina and Elleithy, ⁸⁵ known as SOA; SOA has evolved in the last decades with specific details with many successful implementations. SOA is defined as an architectural framework having three fundamental roles, namely, service providers, service consumers, and service broker (Figure 23). Some researchers^86,87 have detailed the architectural concepts, design, and technologies of SOA.

Figure 23.

Service-oriented architecture.

In SOA, resources are packaged as self-defined, self-contained modules termed as services to provide standard business functionalities. Various researchers have contributed to provide some specific characteristics of services which are described in a standard service description language (SDL). The services have a published interface and can communicate with each other. In further developments, the services have been described as the combination of one or more BBs. These BBs associated with a workflow that can serve the particular purpose in the given application domain.

Initially, SOA was designed, developed, and implemented for the web services to facilitate web developers with defined standards in terms of language, protocol, and common repository. However, SOA in general has services which can be web services but services can also be other than web services. Papazoglou ⁸⁸ presented an SOA with a more general connotation, with many versions and manifestations of integrating enterprise business processes with extended SOA. The extended SOA added more functionality to the existing SOA, namely, service composition to make service with a combination of different modules and service management to ensure the correctness of services, levels of service agreement, and service orchestration.

In 2008, Bernd Reuther and Dirk Henrici ⁸⁹ have introduced an SOA-based communication model as a solution for adaptability of improved protocol in applications without modifications. The communication model is composed of the service user, service broker, service provider, API, and an adapter. SOA-based communication models hide functionality of framework from the users and incorporate local requirements at run time for service selection. The goal of the model is to provide available network services from the stack with the help of service broker and service providers.

SOA-based design

The SOA-based design methodology is based on the SOA that follows the agile development standard for WSNs. ⁹⁰ This methodology is specifically suitable for designing and implementing automated complex WSNs. SOA consists of software components which are used to perform the tasks or services. Various SOA-based architectures have been presented in previous studies.^90–92 SOA is the platform for development of IoT applications as well. IoT application fulfills the requirements by the composed services. In the composition process, various energy-constrained devices may be involved to provide the complete service. In Du et al., ⁹³ an energy optimization solution has been suggested to fulfill the multirequirements. SOA has characteristics, namely, loosely coupled, location transparency, and technology neutral which is required to build flexible architecture.

Design issues of WSN communication architecture

WSN consists of various components, such as low-cost sensors, software, hardware platforms, operating systems, and so on that build the WSN functionalities as per applications. These components are developed by different developers and research communities with different assumptions and application requirements. All the components may not be compatible for communication due to some issues. Some of them are discussed as follows:

• Heterogeneity: In early days, the WSN consisted of homogeneous sensor which performed the same functions of computation, communication, and energy dissipation. But at present, it has changed to application-specific networks due to its applicability in different areas. Therefore, a network can consist of different kinds of nodes as per the requirements of the application. For example, some networks may be a combination of various kinds of nodes that can perform different tasks like pressure and temperature monitoring, motion detection, and image capturing. To execute such tasks, nodes require services, interfaces, and programming APIâ™s to create compatibility between communication protocols, hardware, and operating systems, which is a tedious and time-consuming task.

• Adoption of new protocols: In WSNs, the application requirements has been increasing in the form of service to improve the performance of the networks, and accordingly, communication services have also been increasing. In recent scenarios, researchers and developers have been focusing on the area of communication protocols to improve the performance of network. Existing communication architectures are not flexible enough to couple with new applications. Therefore, flexibility is needed to support the advancement of communication services. Adoption of new protocols is an issue with the existing communication architecture.

• Interoperability: In the recent scenarios, different service providers and vendors provide solutions in WSNs as a service, like software, hardware, and operating systems. The developments of these services are developed to fulfill the need of applications and users in different language platforms. Therefore, interaction among the services is difficult because of interoperability. Interoperability is an issue to make all the service functional with all modules.

• Integration with other network: The integration with other networks (e.g. Internet) is required to monitor and collect data of the environment. It is a difficult and time-consuming task due to availability of different services in different networks. Therefore, common well-defined interface and services (TCP/IP in Internet and UDP in WSN) are needed to make the network compatible and functional.

• Security: The security module improves the confidentiality, integrity, and authentication in WSNs during data transmission, gathering, and accessing. The WSN consists of nodes having low computation power, storage, and energy. Implementing encryption methods on nodes requires extra processing power, transfer of extra bit, and also increased delay in the network. As a technological solution, the traditional architecture is enriched with security module at all the layers for all applications. The security mechanism in all the layers leads to performance degradation and also increases the burden on some applications and users where security is not required. It is a challenge for researchers and developers to rethink from the user perspective. The security and its use may be an optional solution in communication architecture for the applications.

• Adoption of new services: In view of technology-centric development, the innovation and development technology oriented to provide services for different domains such as WSNs, ubiquitous computing, and so on. The goal of the development is to facilitate the users as per their needs and feedback. Therefore, the developers and researchers focus or in future may give the solution to fulfill the need. ⁹⁴ Hence, the design of communication architecture should be flexible enough to couple the existing and future coming services.

• Reliability: In WSNs, reliability is an important parameter for some applications that can be considered as network reliability, protocol reliability, and data reliability. Few works have been done in designing of reliable delivery protocols, and most of the work is application specific where traditional WSN applications suffer from data losses. However, for a range of applications, reliability is needed, where data losses makes the data ineffective. So, reliable communication architecture is required for application (emergency event) where the status of node and data is important.

Lack of common framework and reusability

Numerous applications have been developed using WSNs for geographical monitoring, motion detection, and radiation detection. Development of application-specific WSNs increases the development of protocols. These developments have created a new challenge, that is, a lack of common framework where a developer can develop new services. Almost all the applications are customized protocols for communication without standardization as per the requirements and proficiency of researchers. ⁴⁴ In WSNs, no common architectural framework exists on which the developers can develop the required services and are forced to develop service from the scratch for applications. The network setup in WSNs does not need an infrastructure. It is applicable in unmanned area or where human cannot reach and manage the activity of the environment. The cost of implementation is low. The WSN provides reliable and low-power nodes that work for long time to monitor the event. However, the speed of data transmission is slower than that of the wired network. Such an architecture is less secure due to accessibility of all the information by intruders at any point of time. The structure of WSNs is more complex compared to wired networks. It may be affected by various parameters of surrounding environments, such as signal attenuation, walls, distance, and so on.

Service-oriented computing paradigm for WSNs

The WSN executes tasks in dynamic and distributed environment as per application requirement. Therefore, with the requirements heterogeneity of network like hardware and software components, devices and protocols are also increasing to fulfill the requirements. ⁹⁵ To consider this heterogeneity, the application development is a challenging task for the network engineer without knowing the network details. For the sensor network application development, some parameters need to be considered, that is, reusability, scalability, reliability, security, integration, QoS, and so on. The middleware layer has been suggested as a solution to incorporate the current and future requirements needed to develop new generation WSN application. Various approaches have been given on middleware to develop and execute the applications as per needs. Moreover, all the middleware approaches provide functionality to configure the software and data aggregation. For some instance, middleware needs more functionality, like interoperability mechanism on different levels and adaptability of dynamic network. Future WSN is envisioned as a combination of services such as sensing, communication, and so on, which will be provided by different providers to different applications. ⁷³ In the emerging scenario, the new architectural approaches are needed to incorporate the requirements, logics on different planes, and acceptability of dynamic behavior of the network as per need of application. The new architectural design consists of loose coupling, interfaces, and level of abstraction which builds WSNs independent from application. The service-oriented computing paradigm is the most prominent approach to develop the WSN for current and future applications. The service-oriented approach has some basic characteristics such as loose coupling, flexibility, interoperability, and availability which provides the easy development environment for providers. ⁷³ The combination of WSNs and service-oriented approach provides a method of unified services with WSN components for users and flexible model of programming to develop the scalable WSN applications.

Motivation for employing SOA-based WSNs

WSN has appeared as a new paradigm for the information collection with the collaborative efforts from sensor nodes. Nowadays, the applicability of this network has been increased due to requirement of less infrastructure and readability in an unmanned area. Therefore, a number of users and requirements are also increasing in the area of WSNs. These requirements are fulfilled with developed architectural solutions with the technology-centric approach. Based on this approach, many solutions have been given to the users as per the requirements of applications. These architectural solutions are forcing and putting the overhead to the users and applications due to a lack of flexibility. In the present scenario, the user and application demand flexibility in terms of service development, reusability of codes, service selection, and composition from the pool as per the application requirements due to dynamic requirements and customization. As a case, the user has to select the best service from the service planes as per the application and network requirements for the deployment and location identification of sensor nodes. Existing technology-centric approaches do not support this kind of activity. Therefore, it motivates us to think about the solution of WSN communication architecture that should be based on the user perspectives for ease of modification or enhancement, flexible enough to incorporate the current and future requirements, interoperability between service (developed from different organizations of research communities), reusability of codes, automatic service selection, and composition. For the development of user-centric communication architecture of WSNs, we have followed the service-oriented paradigm.

Service-oriented middleware for WSNs

In WSNs, researchers are using the SOA for different aspects, like application development, design of sensor network, and so on.^96,97 The WSN is applicable for various kinds of applications such as habitat monitoring, environmental monitoring, structural monitoring, and so on. Different kinds of applications compel the developer to develop device software as per the requirements (energy, memory, and resources). One of the key requirements is power, which may not be the same for all the applications. Therefore, the developer has to come with a design methodology to fulfill the need of applications. For example, IoT-based applications have various requirements, such as data accuracy, data security, resource constraints, and so on. In Siris et al., ⁹⁸ different implementation test beds are used to measure the humidity, ozone, and temperature using the federated interoperable semantic IoT (FIESTA-IoT/cloud testbeds and applications) platform. The deviation in accuracy and energy cost and privacy method has been discussed. Kandris et al. ⁹⁹ have given agile development software methodology for the software development. In WSNs, the design of application and network protocol stack fulfills the need of users, but however designed solutions are not acceptable as per the need, then a new solution should be developed using the SOA.

Due to diverse applications of sensor networks, this is a tedious task to build applications of WSNs and actuators. ⁶⁷ So to make the development easier for the developer, a new framework, high level of abstraction, or middleware is required. In 2011, Eduardo Cañete et al. ¹⁰⁰ have introduced a Service-oriented Framework for Wireless Sensor and Actor Networks (USEME) as a framework to develop the real-time applications which follows the principle of service-oriented and component paradigm. The framework has three basic elements—sensor node, port, and services. For the development of service, high-level languages are suggested because low-level language is difficult, time consuming, and is not reusable. The sensor nodes make the complex service to do the task, for example, AC actor needs humidity and temperature. The ports are designed with three elements—synchronous command, asynchronous command, and event to execute the program. The service term is defined with the help of required port and provided port to form the service and interact with the service. The approach gives the way to add, extend, and reuse the system. As per the application requirements, developers may develop and integrate the components in framework. In 2102, Abangar et al. ¹⁰¹ had suggested middleware perspective to build the smart infrastructure using the WSN. They also claimed that service-oriented framework is not enough to make smart infrastructure, but with the middleware technology, development of new sensor-based service can be easier.

In heterogeneous WSNs, heterogeneous of nodes may be deployed to collect data from environment. The communications among the heterogeneous nodes are difficult due to interoperability. To solve the problem of interoperability, SOA-based interface as a middleware architecture has been proposed by Abangar et al. ¹⁰¹ Middleware facilitates the users to perform query, storage, to or from the sensors. Smart mechanisms are used to decide whether data are required from the storage or sensor. The architecture uses few features of SOA such as interoperability and reusability, and in addition to this, it removes the overhead of XML data format using binary encoding. Additional advantages are minimum energy consumption and efficient data delivery and query processing. Alkazemi and colleagues ¹⁰² have also addressed the issue of heterogeneous sensor network in terms of data format and its structure that may affect the network capability. To develop middleware, it follows the principle of SOA and business model management. The middleware comprises the layer-independent modules, which makes possible to achieve high degree of scalability and flexibility for the architecture. ⁷¹ The layers are service bus, interface repository, synthesizer service, binding service, data exchange service, encryption routing service, and business process service. The middleware is flexible and scalable for WSN applications but are not tested for business process applications. To deal with the heterogeneous data, Levent Gürgen et al. ¹⁰³ have given the service-oriented-based stremware architecture for the management of data. The architecture is used to define the different data in a generic way using the schema. The architecture deployed between the senor and application as a mediator adopter ¹⁶ to collect the data from the sensors using query service. The deployment follows the hierarchical SOA ¹⁰⁴ to collect the heterogeneous data from distributed sensors. The approach is useful for kind of application where heterogeneous sensor nodes like camera, pressure, and temperature sensors are required to collect the data.

Amundson and colleagues ⁹¹ have proposed an object-centric, ambient-aware service-oriented sensornet programming framework (OASiS) which follows the principle of SOA (Figure 24). The framework provides services in terms of discovery, binding, and composition as per the constraints of the network to develop the application for dynamic environment. In the framework, the developer has no need to program for each domain; he has to only use the library which is developed by the domain expert. It comprises a node manager, configuration manger, and service discovery manager as the service to support the application. In addition to this, the framework also addresses the designing issue of networked sensors. The issues are application specific and QoS requirements, that is, constraint management, mapping of application design in real world, service discovery, configuration, and data aggregation.

Figure 24.

OASiS programming framework.

Mohammad Al-Rousan and Kullab ¹⁹ have developed service-oriented-based solution $(\mathrm{SI}{)}^2$ to provide standardized device access mechanism for the applications. The middleware architecture has been developed based on dependent and independent layers. The message handler and service manager are the two components of the platform-dependent layer. The function of the message handler is to transform the events from platform dependent to independent form and converts the services from platform dependent to independent format which are on smart devices. The independent layer consists of the three modules, namely, requester, service mapper, and service repository. ¹⁰⁵ These modules are responsible for specific functions such as processing the request, mapping the service required by a smart item, and storage of the item, respectively. In context-aware computing, service-oriented approach is already adopted in the service awareness sphere using rule-based reasoning for awareness and conventional context awareness scheme may not work generally due to heterogeneity of the device. ¹⁰⁶ Therefore, Bai Y et al. ¹⁰⁷ have proposed service-oriented middleware to solve the problem of heterogeneity (hardware device) and to encourage the application development based on the context in smart environments. The middleware works as the bridge between the application layer requirement as per the context and hardware layers. For context-aware reasoning, it enables interaction between many factors.

Moungla Caporuscio et al. ¹⁰⁸ have proposed middleware architecture for ubiquitous computing. The aim of the architecture is to connect devices and deploy web services on a range of devices. The middleware architecture consists of two layers, namely, web service–oriented layer and multiradio networking layer. The web service layer performs peer-to-peer connection and includes the Simple Object Access Protocol (SOAP) messages for routing in the multiradio network. The multiradio layer manages the addressing scheme of the multiradio network. It gives a way to use the SOAP API in pervasive computing like WSNs. Edgardo Avils-Lpez and J. Antonio Garca-Macas ⁹² have proposed TinySOA for accessing the WSN using SOA-based interface by the programmer’s preferred language. With this approach, the developer can collect data without knowing the technical detail of hardware devices. This middleware can also be used to connect to the Internet with sensor network to collect data. Chein Liang-Fok et al. ¹⁰⁹ have proposed middleware architecture, Servilla, to improve the flexibility and energy efficiency using adaptive service mechanism. It is difficult to use and program the WSN due to the limitation of energy and high connectivity, but traditionally, it is done with the energy level information of the service provider. In addition to this, it is also platform independent to support the heterogeneous network. By optimizing the energy dissipation, the architecture also increases the availability of services without forcing developers and application services.

Conclusion

In this article, a detailed review has been carried out on architectural design and development aspects of WSNs. Application-oriented design of WSNs fails to cater to the complexity of advanced WSN-based use cases that demand automated and agile development. Cross-layer architectural design paradigm with its various archetypes for catering to different requirements has been delineated, and finally, middleware-based WSN design strategies have been deliberated. For handling increasingly complex middleware designs in WSNs, different facets of SOA-based designs and their salient features have been presented herein. The article also points to a few areas of SOA-based WSN design that can be studied as continuation of research in this area.

Thus far, various developments in middleware-based WSN applications have been disscussed in detail with SOA in vogue. The introduction of SOA has provided great flexibilities in the design and development of sophisticated WSN applications. With proliferation and ease of services development, myriad services have been developed and made available for public pooled usages. Such a scenario, though very apt for next-generation software development markets, poses serious impediments for practitioners to select best services from the available pool. Besides, due to prohibitively large number of alternatives available for a particular service, appropriate service selection has been a very pertinent problem. This may be looked upon in future by employing evolutionary and other stochastic optimization techniques.