TCLA: A Triangular Cross-Layer Architecture for Wireless Sensor Networks

Daidi Lin College of Computer Science, Northwestern

Polytechnical University Xi’an Shaanxi 710072, China

e-mail: lindaidi@yahoo.com.cn

Shining Li College of Computer Science, Northwestern

Polytechnical University Xi’an Shaanxi 710072, China

e-mail: lishining@nwpu.edu.cn

Abstract—Many cross-layer architectures have been proposed in recent years. Most of them extend the traditional protocol stack in order to keep compatibility, which add complexity by incorporating many components. And very few are revolutionary, which break the stack structure to pursue good performance at the cost of compatibility. In this paper, we propose a network architecture with a layering and non-stack hybrid approach for wireless sensor networks (WSNs), called TCLA (Triangular CL Architecture). TCLA merges the protocol layers of OSI model into three virtual functional modules and organizes them in a non-stack way. TCLA breaks the stack structure and maintains the compatibility at the same time. TCLA aims to provide great flexibility, efficiency and scalability for WSNs. We believe that TCLA can serve as a generic architecture for the development of cross-layer design.

Keywords-cross-layer design; cross-layer architecture; non-stack; triangular cross-layer architecture; WSNs

I. INTRODUCTION The traditional protocol stack (OSI), which is designed in

accordance with the feature and demand of the wired networks, divides network protocols into several layers and only allows data exchange between adjacent layers. Such model is modular, independent, and easy to implement and maintain. However, the traditional protocol stack is perhaps not flexible enough to deal with the dynamics of the wireless environments [2][21], especially wireless sensor networks (WSNs) [3] which are highly resource-constrained and application-specific. Cross-layer (CL) design has recently emerged as a new trend for coping with the performance issues of wireless networks. In fact, recent papers on WSNs reveal that CL design and optimization results in significant improvement in terms of conserving energy and prolonging lifetime [23][26][27].

CL issues mainly focus on two aspects: the protocol design, frameworks design and implementation related issues [18]. Serving as an important container for the CL protocols and network components, the architecture would help standardize the development and maintenance of CL design. Thus, the design of CL architectures will greatly impact the performance and efficiency of the CL design.

Many proposals for CL design and their corresponding architectures have been published in the literature. All of them can be categorized as either evolutionary approach based or revolutionary approach based. These two approaches are defined in [4] as follows: The evolutionary

approach to CL design always seeks to extend the existing layered structure in order to maintain compatibility; the revolutionary approach to CL design is not bound by an existing implementation, and as such does not need to compromise to maintain compatibility.

Most existing CL architectures are evolutionary, because compatibility with existing networks and systems is very important from the software engineering perspective. And very few are revolutionary which offer great flexibility and efficiency but need completely new system-level implementation. The evolutionary approach often adds complexity by incorporating many components, which may be not suitable to the resource-limited sensor nodes. For resource-restrained and application-specific WSNs, the revolutionary approach is more attractive.

In order to get efficiency, flexibility and compatibility at the same time, we make the tradeoff between evolutionary approaches and revolutionary approaches. In this paper, we propose a CL architecture for WSNs, called TCLA, which combines layering and non-stack approaches. TCLA merges the protocol layers of OSI model into three new functional modules and organizes these functional modules in a triangular way. Besides maintaining compatibility, TCLA allows rich interactions between the protocol layers and offers great flexibility for multiple CL designs.

The rest of the paper is organized as follows: in section 2 we review the existing CL architectures and analyze their advantages, drawbacks and limitations. In section 3, we explain the details of our proposed architecture TCLA and highlight its benefits. In section 4 we discuss open challenges to refine and implement TCLA. Last, we conclude with some directions for future work in section 5.

II. RELATED WORK Recently, many CL architectures have been proposed in

the literature. However, no consensus exists on a generic CL architecture because research on CL networking is still at an early stage [2]. All of the existing CL architectures could be put into two categories according to whether they are evolutionary or revolutionary.

A. Evolutionary approach Most of existing architectures are based on evolutionary

approaches and they are the improvement of the existing protocol stack. According to the different ways of CL

2009 International Conference on Frontier of Computer Science and Technology

978-0-7695-3932-4/09 $26.00 © 2009 IEEE

DOI 10.1109/FCST.2009.50

272

interactions, they can be divided into two categories mentioned in [1] as follows.

1) Direct communication between layers: Adding new interfaces between non-adjacent layers is a commonly used method of CL design. Non-adjacent layers can interact directly through these new interfaces as shown in Fig. 1.

Figure 1. Direct communication between layers [16].

CLASS [28] allows direct signaling between non-adjacent layers. It introduces local signaling mechanism to the protocol stack and treats internal signaling and external signaling differently.

DMA-CLD [6] allows the interaction between the network layer and upper as well as lower layers. DMA-CLD is executed by network layer. Thus, the network layer ranks routes based on inter-layer feedback and information gathered from intermediate nodes.

XIAN [8] architecture lists the available MAC layer APIs to provide CL information for the network, transport and application layers, which provide bi-directional interaction between MAC and an upper layer.

The authors in [10] add a CL interface CLIF to each protocol layer. CLIF provides two interfaces for the protocols: One transfers the standard packet; the other interface is available only to CL aware protocols and is used to exchange the CL information with the CLIF.

2) Communication based on a shared database: Another commonly used evolutionary approach to CL design is to set up a shared database along with the strict layering stack. Layers can exchange information through the database as shown in Fig. 2.

Figure 2. Communication based on a shared database [16].

MobileMan [15] presents a core component, Network Status, which functions as a repository for information that network protocols throughout the stack collect. Each

protocol can access the Network Status to share its data with other protocols.

WIDENS [13] extends CL to all protocol stacks through state information and parameter mapping between adjacent layers. Non-adjacent layer interactions are controlled via the adjacent layers. In addition, WIDENS co-designs MAC and PHY layer to provide high bit rate.

OA [11] architecture uses an optimization agent to exchange and control the information between different layers. Interactions between various layers can be categorized as intra-layer or inter-layer interactions and these interactions can be either bottom-up or top-down.

CLCF [14] sets up a CL server in the local node to achieve the desired CL coordination functionality while eliminating the overhead of remote communication. CL clients are added to each protocol layer to enable the interaction with the server.

ECLAIR [7] consists of two main components: optimization subsystem and tuning layers. Optimization subsystem contains protocol optimizers that effectuate cross layer optimizations. Tuning layers provide the necessary APIs to the protocol optimizers for interacting with various layers and manipulating the protocol data structures.

The architecture proposed in [17], from vertical to horizontal, combines a low protocol stack and a cross-layer management entity. The CL management entity is used to offer a shared data structure and to take care of some sensor network specific functions.

Such architectures described above all depend on the local view of the network in decision making. However, CrossTalk [9], Hybrid View architecture [12] and XLEngine [16] still consider the importance of the global view, which may be very useful in energy management, routing and optimizing load balancing.

B. Revolutionary approach Revolutionary approaches focus on performance and

efficiency but don’t concern about compatibility. Although revolutionary architectures are attractive to WSNs, to the best of our knowledge, there have been very few revolutionary CL architectures until now.

EWI [19] is a two-layer architecture (Fig. 3) for WSNs. The two layers are the System layer and the Wireless Link layer. The bottom Wireless Link layer supplies the library of wireless transmission modules to the upper System layer. The System layer decides the organization of the wireless links. EWI removes the traditional network layer and transport layer, and some traditional functions of the two layers are merged into the top and the bottom layers.

Figure 3. EWI architecture [19].

273

With questions on whether the layering stack is still an adequate foundation for network architectures, non-stack architectures have emerged recently. Such revolutionary approach completely abandons the stack structure, which can be described schematically in Fig. 4.

Figure 4. Non-stack architectures [1].

For example, RBA, a non-stack architecture, has been proposed in [20]. Instead of using protocol layers, RBA organizes communication by using functional units which are called roles. Roles are not generally organized hierarchically, so they may be more richly interconnected than the traditional protocol layers.

C. Further analysis of existing CL architectures The evolutionary approaches, whether adding new

interfaces between layers or setting up a shared database alongside the protocol stack, are the product of reluctance to change existing implementations. Adding new interfaces between layers is a straightforward way to share information between layers. However, such approach seems less flexible than the shared database approach. By comparison, the shared database approach introduces smaller changes to the original protocols and it is easier to maintain. But the implementation of the shared database is the main challenge to this approach. When the database size increases, the cost of the management and communication of the database becomes larger. Such approach contributes to the improvement of the system performance at the cost of the added complexity. For highly resource-constrained sensor nodes, the too complex network architectures are not suitable.

The revolutionary approaches, especially the non-stack architecture RBA, completely break through the traditional organization of network protocols. This opens up a new door to design network architectures. Such new abstractions allow rich interactions between the functional units, which may offer great flexibility and extensibility both during design and at runtime. However, they do not come without cost, which require completely new system-level implementations and have the problem of compatibility.

We think there is a need for a new network architecture model for replacing the existing OSI paradigm, which can serve as the infrastructure of CL design and optimization. The new network architecture has to be simple and generic. Moreover it can offer great efficiency, flexibility and compatibility at the same time.

III. TCLA: OUR PROPOSED CL ARCHITECTURE

A. Motivation of this architecture Why another architecture? We believe that existing CL

architectures have achieved great success in certain CL design and optimization aspects of wireless networks. However, as discussed in section 2.3, they still have some drawbacks or limitations in some respects when they are used in WSNs.

The most important nature of WSNs, which are resource limited and application specific, poses challenges in the network architecture design. Besides, some adjacent layers are closely connected, between which the information interaction is frequent. All these factors should be taken into account when designing a network architecture for WSNs.

Most of the existing CL architectures add complexity by inserting new functionality to the existing layered architecture. Many complex CL architectures are too luxurious for the resource-scarce sensor nodes. WSNs prefer simple and efficient ones. Besides, the cross-layer design in WSNs suggests the necessity of revolutionary approaches, since WSNs are application specific [4].

We suppose there is a possibility to combine the advantages of both approaches discussed in section 2. The compatibility of the evolutionary architectures can be combined with the efficiency of the revolutionary architectures by using a hybrid approach. Existing architectures motivate a new network architecture with a layering and non-stack hybrid approach, which breaks the stack structure and maintains layering within the functional modules at the same time. The overview of this hybrid architecture is presented in the next section.

B. Overview of TCLA The OSI model divides network protocols into several

layers and prevents the potential benefits of joint design. Some adjacent layers are closely connected, between which the information interaction is frequent. Therefore, the approach merging two or more adjacent layers into a new virtual functional module seems an efficient way to reduce the communication overhead. The new virtual functional module can enhance the effective integration of the internal protocols and reduce the communication overhead on the basis of retaining the functional dependence of layers before merging.

The physical and data link layers take care of “close-to-the-transmission” aspects, the network and transport layers handle “networking” aspects [5]. The application layer is the interface between specific applications and networks. According to the functional proximity between protocol layers as well as the frequency of interactions between them, the OSI model can be merged into three virtual functional modules: AppM, NetM and LinkM as shown in Fig. 5. Because the functions of the session and presentation layers are relatively simple, these two layers are fully integrated in the application layer in order to reduce the overhead. AppM, actually only having one layer, is responsible for the aspects related to specific applications. NetM and LinkM, as a single functional module respectively, actually both consist of two

274

layers of OSI. NetM manages “networking” related issues, like resource allocation, routing and congestion control. LinkM handles the wireless transmission aspects, such as dealing with signals, coding, multiuser access, error control, power control, etc.

Figure 5. OSI model and Virtual function Modules.

How to organize these virtual functional modules? The stack structure is simple but insufficiently flexible. The non-stack approach is a good alternative choice here. As shown in Fig. 6, we organize these three virtual functional modules in a triangular way. This architecture uses non-stack structure, but retains layering within the functional modules. So we call this triangular CL architecture TCLA.

Figure 6. Overview of TCLA.

The internal protocol layers of one functional module can interact directly. Layers in different functional modules can interact through a communication agent which is added to each virtual functional module. The communication agent supports the standard packets as well as the shared packets (carrying CL information). This is similar to CLIF, except that CLIF is added to each protocol layer and combines signaling and function-call approaches. The main components and interactions of TCLA will be described in the next two sections.

C. Details of TCLA The details of TCLA are shown in Fig. 7. The agent is a

component which is added to each virtual functional module to facilitate the communication between two functional modules. Each agent consists of two interfaces namely: Standard interface and Shared interface. The standard interface is responsible for the transmission of the standard packet, which offers compatibility with the existing networks and protocols. So protocols that don’t support the CL design

can still function well in this architecture. The shared interface is used to exchange shared information between two layers in different function modules. In this way, arbitrary two protocol layers can interact directly.

Figure 7. Details of TCLA.

An agent has two functions as follows: • To tag the sending packet and recognize the received

packet. There are many ways to distinguish the standard packet and the shared packet, for example, an unused bit in the protocol headers [10] can be used to distinguish the two kinds of packets.

• To converse the received information from other layers into the form that the destination protocol can recognize.

Since the functionality for manipulating protocol data structures is built into the agent, no modification is required to the existing protocol layers. This facilitates incorporation of new CL optimizing algorithms with minimum intrusion.

D. Interactions in TCLA Interactions in TCLA can be categorized as intra-module

(between layers in one functional module) or inter-module interactions (between layers of different functional modules) and these interactions are all bi-directional data flow. Layers in one functional module, for example, the transport layer and the network layer in NetM, can interact directly without the interference of the agent. Layers in different functional modules, for example, the physical layer in LinkM and the application layer in AppM, can also directly communicate with each other but need the help of the communication agent.

The following is the complete procedure of sending and receiving a packet through the agent:

When a protocol wants to send a standard packet, the agent of its module directly sends this packet to the next module through the standard interface, because the standard packet flow direction is definite. When a protocol wants to send some shared information to another target protocol, the agent of its module tags the packet, and then sends this shared packet to the target module (where the target protocol resides) through the shared interface.

275

When a functional module receives a packet from other modules, its agent firstly checks the packet mark, and determines whether this is a standard packet or a shared packet. If it is a standard packet, the agent won’t have to handle the packet and just forwards the packet through its standard interface. Therefore, concerning the processing of standard packets, TCLA is equivalent to the traditional protocol stack. If it is a shared packet, the shared interface will abstract the shared information, converse the shared information into the format that the target protocol can recognize, and then forward the packet to the target protocol.

The following are two examples. One is the flow of a standard packet from the physical layer to application layer. As shown in Fig. 8, the packet is transferred through the standard interface of each module and flows through the data link layer, network layer and transport layer. This is similar to traditional protocol stack. Therefore, the existing protocols can run on this model without modification.

Figure 8. An example of the standard packet flow.

The other example is shown in Fig. 9. The physical layer wants to send the status information of the wireless channel to the application layer, so that the application could adjust its sending rate. First, the physical layer packages the status information of the wireless channel. Then the agent of LinkM tags the packet and sends it to AppM through its shared interface. When AppM receives this packet, its agent checks the packet mark and finds out this is a shared packet. The shared interface abstracts the information and converses it into the format that the application layer can recognize, and then forwards it to application layer. This packet flow from the physical layer to application layer doesn’t flow through the data link layer, network layer and transport layer. Similarly, the application layer can also transfers the QoS requirement and energy control parameters to the physical layer directly through the shared interface in the opposite direction.

Figure 9. An example of the shared packet flow.

E. Salient features Our work differs from previous work in several aspects.

First, most of the existing CL architectures are evolutionary, which are based on the stack structure. Our work breaks the bound of the stack structure. Second, to our knowledge, existing revolutionary CL architectures pursue performance at the cost of abandoning compatibility. Our architecture combines the layering and non-stack approaches so that we can obtain performance and compatibility at the same time.

We present the salient features of TCLA as follows. 1) Modularity and Simplicity: TCLA preserves the

modularity of traditional protocol stack and each abstract module has high independence. Thus, it is easy to implement and maintain.

2) Scalability and flexibility: WSNs are networks for specific applications, so the network architecture for WSNs requires high scalability and flexibility. TCLA adopts modular design and triangular organization, so that it is easy to add new modules to TCLA or remove modules from TCLA without affecting the normal functions of other modules.

3) Compatibility: Successful integration of existing and emerging wireless systems is a demanding task [22]. Compatibility and interconnection may be an answer to this issue. TCLA provides great compatibility with the existing implementations.

4) Efficiency: For the energy and processing resource limited WSNs, efficiency is very important. Our abstract modules integrate the internal layers and remove the redundant overhead. Moreover, our proposed architecture allows rich interactions between different layers in order to enable the efficient implementation of information feedback.

5) Generality: TCLA is a general model which can serve as an infrastructure for WSNs CL design.

276

Furthermore, TCLA is not only applicable to WSNs, but also applicable to other wireless networks.

IV. OPEN CHALLENGES TO REFINE AND IMPLEMENT TCLA

There are still some research challenges to refine and implement TCLA.

Firstly, the internal layers in some abstract modules are closely connected and integrating them will greatly reduce overhead. For example, some of the latest standardization issues [24] and works [13][25] suggest the co-design and integration of the physical and data link layers. We have to analyze the interactions between these layers in detail, so that we can further optimize communication.

Secondly, Unbridled CL interactions can cause conflicts or loops, since a small modification in one layer may lead to a series of changing affecting other layers. We need to examine the dependencies between the interaction protocol parameter to avoid conflicts and loops.

Thirdly, the agent component is responsible for the packet transmission, recognition and format conversion. We have to analyze what types of data structure should be maintained by an agent. More importantly, we have to refine and implement the communication between existing protocols and their agents.

Finally, because the sensor nodes are energy and processing resource limited, TCLA has to support optimizations. The optimizing algorithms can reside in the agent in order to introduce minimum intrusion to existing protocols. The design and implementation of the optimizing modules needs further study.

V. CONCLUSION AND FUTURE WORK In this paper, we have reviewed existing CL architectures

and analyzed their advantages, limitations and drawbacks. Most of existing architectures are evolutionary, which add complexity by incorporating many components, and very few break the stack structure completely, which are regarded as revolutionary approaches. We proposed a CL architecture with a layering and non-stack hybrid approach, called TCLA, which not only breaks the stack structure but also obtains compatibility. Finally, we highlighted the benefits of TCLA and discussed the open challenges to refine and implement TCLA. TCLA is still in the design stage. Our future research will focus on the validating and refining of TCLA. We are currently simulating TCLA in a software simulator, after that, we will implement a prototype of TCLA to test it in real operational scenarios.

REFERENCES [1] V. Srivastava and M. Motani, “Cross-layer design: A survey and the

road ahead,” IEEE Communications Magazine, vol. 43, no. 12, pp. 112–119, Dec 2005.

[2] M. A. Razzaque, P. Dobson, and P. Nixon, “Cross-Layer Architectures for Autonomic Communications,” Journal of Network and Systems Management, Mar 2007.

[3] T. Melodia, M. C. Vuran, and D. Pompili, “The State of the Art in Cross-layer Design for Wireless Sensor Networks,” to appear in Springer Lecture Notes in Computer Science (LNCS), 2006.

[4] F. Aune, Cross-Layer Design Tutorial, Published under Creative Commons License, 2004.

[5] G. Karlsson, S. Lindfors, M. Skoglund, and G. Oien, “Cross-Layer Optimization in Short-Range Wireless Sensor Networks (CROPS),” www.ee.kth.se/commth/projects/ CROPS/docs/Technical.pdf.

[6] 0A. M. Safwat, “A novel framework for cross-layer design in wireless ad-hoc and sensor networks,” IEEE GlobeCom Workshops, Dec 2004.

[7] V. T. Raisinghani and Sridhar Iyer, “ECLAIR: An Efficient Cross Layer Architecture for Wireless Protocol Stacks,” WWC2004.

[8] H. Aiache, V. Conan, J. Leguay, and M. Levy, “XIAN: Cross-layer interface for wireless ad hoc networks,” in Mediterranean Ad Hoc Networking Workshop, 2006.

[9] R. Winter, J. Schiller, N. Nikaein, and C. Bonnet, “CrossTalk: cross-layer decision support based on global knowledge,” IEEE Communications, vol. 44, no. 1, Jan 2006.

[10] [10] Z. Chang, G. Gaydadjiev, “A Hybrid Cross Layer Architecture For Wireless Protocol Stacks,” IWCMC 2008.

[11] W. Su and T. L. Lim, “Cross-Layer Design and Optimization for Wireless Sensor Networks,” in Prof. of Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2006. SNPD 2006.

[12] M. A. Razzaque, S. Dobson, and P. Nixon, “A Cross-Layer Architecture for Autonomic Communications,” IFIP 2006, vol. 4195, pp. 25–35, 2006.

[13] R. Knopp, N. Nikaein, C. Bonnet, H. Aiache, V.Conan, S. Masson, G. Guibe, and C. L. Martret, “Overview of the WIDENS Architecture: A Wireless Ad Hoc Network for Public Safety,” IEEE SECON 2004, Oct 2004.

[14] K. M. El Defrawy, M. S. El Zarki, and M. M. Khairy, “Proposal for a Cross-Layer Coordination Framework for Next Generation Wireless Systems,” Proceedings of the 2006 international conference on Wireless communications and mobile computing, pp. 141-146, Jul 2006.

[15] E. Borgia, M. Conti, and F. Delmastro, “MobileMAN: Design, Integration, and Experimentation of Cross-Layer Mobile Multihop Ad Hoc Networks,” IEEE Communications Magazine, July 2006.

[16] W. Berrayana, H. Youssef, S. Lohier, and G. PujolleDec, “Proposition of a cross-layer architecture model for the support of QoS in ad-hoc networks,” Proceedings of the 2006 ACM CoNEXT Conference, Dec 2006.

[17] Ismo Hakala and Merja Tikkakoski, “From vertical to horizontal architecture---a cross-layer implementation in a sensor network node,” Proceedings of the first international conference on Integrated internet ad hoc and sensor networks, 2006.

[18] N. Zhao, L. Sun, “Research on cross-Layer Frameworks Design in Wireless Sensor Networks,” Proceedings of the Third International Conference on Wireless and Mobile Communications, Mar 2007.

[19] L. Song and D. Hatzinakos, “A cross-layer architecture of wireless sensor networks for target tracking,” IEEE/ACM Transactions on Networking, vol. 15, pp. 145-158, Feb 2007.

[20] R. Braden, T. Faber, and M. Handley, “From Protocol Stack to Protocol Heap: Role-Based Architecture,” Proc. Hot Topics in Net., Princeton, NJ, Mar 2002.

[21] V. T. Raisinghani, S. Iyer, “Cross Layer Feedback Architecture for Mobile Device Protocol Stacks,” IEEE Communications Magazine, vol. 44, pp. 85-92, Jan 2006.

[22] S. Shakkottai, T. S. Rappaport and P. C. Karlsson, “Cross-layer Design for Wireless Networks,” IEEE Communications Magazine, vol. 41, pp. 74- 80, Oct 2003.

[23] L. van Hoesel, T. Nieberg, J. Wu, and P. J. M. Havinga, “Prolonging the lifetime of wireless sensor networks by cross-layer interaction,” IEEE Wireless Communications,vol. 11, no. 6, pp. 78 - 86, Dec 2004.

[24] A. Doufexi, S. Armour, P. Karlsson, M. Butler, A. Nix, D. Bull, and J. McGeehan, “A comparison of the HIPER-LAN/2 and IEEE

277

802.11a wireless LAN standards,” IEEE Communications Magazine, vol. 40, pp. 172–180, May 2002.

[25] Z. Chang and G. Gaydadjiev, “Cross-Layer Designs Architecture for LEO Satellite Ad Hoc Network,” WWIC 2008, LNCS 5031, pp. 164–176, 2008.

[26] H. Kwon, T. H. Kim, S. Choi, and B. G. Lee, “Lifetime maximization under reliability constraint via cross-layer strategy in wireless sensor

networks,” in IEEE Wireless Communications and Networking Conference, 2005, pp. 1891–1896.

[27] M. L. Sichitiu, “Cross-layer scheduling for power ef ciency in wireless sensor networks,” in INFOCOM, 2004, pp. 1740–1750.

[28] Qi Wang and M. A. Abu-Rgheff, “Cross-layer Signalling for Next-Generation Wireless Systems,” In Wireless Communications and Networking (WCNC), vol. 2, pp. 1084–1089, Mar 2003.

278