«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
Congestion detection and congestion mitigation mechanisms in STCP are similar to CODA mechanisms (see section 8.2.1). However, congestion notification is carried out differently. In STCP, when the load is greater than a lower threshold (but smaller than a higher threshold), then a congestion notification bit is activated in some randomly chosen packets. If the load becomes greater than the higher threshold, then all packets are transmitted with the congestion notification bit set. When the sink node receives a packet with the congestion bit set, it activates a congestion bit in the acknowledgment. Upon receipt of such acknowledgment, the sensor node may route data through a different path or may reduce the transmission rate.
The Event-to-Sink Reliable Transport (ESRT) protocol  was designed to achieve reliable event detection in a WSN, while aiming at conserving energy. ESRT is suitable for WSN applications that require a certain event to be detected, instead of end-to-end packet reliability. Most of the ESRT func
tionality runs on the sink node. ESRT assumes that sensor nodes periodically report the data they collect at a reporting frequency, f, and the sink node is in charge of processing the reports transmitted by the sensor nodes for detecting an event In ESRT, the sink node compares the observed event reliability, r, defined as the number of received packets during a certain interval, with the desired event reliability, R, defined as the required number of received packets during that interval for reliable event detection.
ESRT aims at achieving the desired reliability while at the same time avoiding network congestion. Sensor nodes monitor local buffer levels in order to detect congestion. If a sensor node detects congestion, it signals this fact in the next data packet it transmits to the sink node. If the sink node measures event reliability almost equal to the desired one, and no congestion notification takes place, then the WSN is operating optimally.
Otherwise, the sink node computes a new reporting frequency, f, for the next interval, which is broadcast to the source nodes. The new reporting frequency may be greater, equal to or smaller than the previous one, depending on the particular network state determined by the sink node according to its measurements.
Table 8.3 shows the different network states defined in ESRT and the corresponding actions taken by the sink node in each case.
The process is repeated until the measurements made by the sink node indicate that the WSN is operating optimally. The sink node detects congestion on the basis of local buffer occupancy measurements.
Summary of ESRT actions (adapted from ) 8.4.3. Summary Both transport protocols discussed in previous Sections 8.4.1 and 8.4.2 are generic end-to-end upstream protocols. The main differences are that while ESRT offers event reliability by means of an end-to-end source reporting frequency adjustment, STCP implements a controlled variable reliability utilizing the diversity in applications (continuous flows and event-driven flows). Table 8.4 summarises the key characteristics of these two transport protocols.
8.5. Transport mechanisms in ZigBee ZigBee offers support for reliable data transport between two end devices. Because ZigBee does not define a transport layer, reliability is achieved at the application layer as follows: application layer data units in ZigBee include an acknowledgment request bit. The recipient of such a data unit
must send an ACK back to the source. If the ACK is not received by the source, then the data unit is retransmitted. ZigBee does not provide congestion control mechanisms.
REFERENCES A. Dunkels, J. Alonso, T. Voigt, “Making TCP/IP Viable for Wireless Sensor Networks”, in proceedings of the 1st European Workshop on Wireless Sensor Networks (EWSN’04), Berlin, Germany, June 2004.
 A. Dunkels, “Full TCP/IP for 8-bit architectures”, in proceedings of Mobisys’03, San Francisco, USA, May 2003.
 L. Casals, J. Paradells, “Internet en las Cosas”; in proceedings of XV Jornadas Telecom I+D, 2005. (in Spanish)  Z. Shelby, “NanoIP: The Zen of Embedded Networking”, in proceedings of the IEEE International Conference on Communications, Anchorage, USA, May 2003.
 picnic – bringing pic and nic together (Ethernet). http://picnic.sourceforge.net.
 A. Dunkels, J.P. Vasseur, “IP for Smart Objects”, Internet Protocol for Smart Objects (IPSO) Alliance White Paper #1, September 2008.
 C. Wang et al., “A Survey of Transport Protocols for Wireless Sensor Networks”, IEEE Network, pp. 34-40, May/June 2006.
 Y. G. Iyer, S. Gandham, and S. Venkatesan, “STCP: A Generic Transport Layer Protocol for Wireless Sensor Networks,” Proc. IEEE ICCCN 2005, San Diego, CA, Oct. 17–19, 2005.
 B. Hull, K. Jamieson, and H. Balakrishnan, “Mitigating Congestion in Wireless Sensor Networks,” Proc. ACM Sensys ’04, Baltimore, MD, Nov.
 C.-Y. Wan, S. B. Eisenman, and A. T. Campbell, “CODA: Congestion Detection and Avoidance in Sensor Networks,” Proc. ACM Sensys ’03, Los Angeles, CA, Nov. 5–7, 2003.
 S.-J. Park et al., “A Scalable Approach for Reliable Downstream Data Deliveryin Wireless Sensor Networks,” Proc. ACM MobiHoc ’04, Roppongi, Japan, May 24–26, 2004.
 C. Wang et al., “Priority-Based Congestion Control in Wireless Sensor Networks”, IEEE Int’l. Conf. Sensor Networks, Ubiquitous, and Trustworthy Comp., Taichung, Taiwan, June 5–7, 2006.
 Y. Sankarasubramaniam, O. B. Akan, and I. F. Akyildiz, “ESRT: Event-toSink Reliable Transport in Wireless Sensor Networks,” Proc. ACM Mobihoc ’03, Annapolis, MD, June 1–3, 2003.
 F. Stann and J. Heidemann, “RMST: Reliable Data Transport in Sensor Networks,” Proc. IEEE SNPA ’03, Anchorage, AK, May 11, 2003.
 H. Zhang et al., “Reliable Bursty Convergecast in Wireless Sensor Networks,” Proc. ACM Mobihoc ’05, Urbana-Champain, IL, May 25–28, 2005.
 C.-T. Ee and R. Bajcsy, “Congestion Control and Fairness for Many-toOne Routing in Sensor Networks”; Proc. ACM Sensys ’04, Baltimore, MD, Nov. 3–5, 2004.
 C.-Y. Wan and A. T. Campbell, “PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks,” Proc. ACM WSNA ’02, Atlanta, GA, Sept. 28, 2002.
 C.-Y. Wan, A. T. Campbell, S. B. Eisenmann, J. Crowcroft, “Siphon:
Overload Traffic Management using MultiRadio Virtual Sinks in Sensor Networks”, in proceedings of ACM SenSys’05, San Diego, November 2005.
 C. Intanagonwiwat, R. Govindan, and D. Estrin. “Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks”.
In Proceedings of ACM/IEEE International Conference on Mobile Computing and Networking, pp. 56-67, Boston, MA, USA, August 2000.
 D. Estrin, R. Govindan, J. Heidemann, and S. Kumar, “Next century challenges: scalable coordination in sensor networks”. In MobiCom ’99: Proceedings of the 5th annual ACM/IEEE international confe
Chapter 8. Transport
rence on Mobile computing and networking, pp. 263–270, New York, USA, 1999.
 C. Bormann, D. Sturek, Z. Shelby, “6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols”, Internet Draft, (Work in progress) July 2009.
 W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”, RFC 2001, January 1997.
 B. Deb, S. Bhatnagar, B. Nath, “ReInForM: Reliable Information Forwarding Using Multiple Paths in Sensor Networks”, in proceedings of IEEE LCN, Bonn, Germany, October 2003.
 C. Gomez, M. Catalan, D. Viamonte, J. Paradells, A. Calveras, "Web browsing optimization over 2.5G and 3G: End-to-end mechanisms vs. usage of performance enhancing proxies", Wireless Communications & Mobile Computing Journal 2008.
 H. Balakrishnan et al. “Improving TCP/IP Performance Over Wireless Networks”, in proceedings of Mobicom’95, Berkeley, California, USA, November 1995.
 A. Dunkels et al. “Distributed TCP Caching for Wireless Sensor Networks”, in proceedings of the Third Annual Mediterranean Ad Hoc Networking Workshop, Turkey, June 2004.
9. Security The broadcast nature of wireless communications opens the door to a wide range of security attacks, and WSNs are no exception. In fact, some WSN applications may be very sensitive to security attacks. For instance, the introduction of erroneous messages in an industrial WSN, or even sometimes in a residential environment, may cause serious problems.
Security mechanisms such as encryption, authentication or communication integrity are based on cryptographic methods. These mechanisms are processing-hungry and contribute significantly to implementation code size. Hence, there is a trade-off between security functionality and hardware capabilities.
This chapter is organized as follows. Section 9.1 presents a set of security functions which may be required in WSNs. Section 9.2 focuses on how those functions are implemented in the IEEE 802.15.4 standard. Section 9.3 presents the architecture and functional description of the security services provided by ZigBee. Section 9.4 concludes the chapter with a brief overview of the current status of security mechanisms of other WSN solutions.
9.1. Security services The main security services that may be required in any network comprise
the following ones:
• Confidentiality: this service has the goal of keeping information in a secret way so that only authorized entities share this information. It is
typically achieved by using cryptographic mechanisms, like ciphering, which ideally should prevent an adversary to obtain even partial information.
• Authentication: the goal of this service is to make sure that a data source is the one who claims to be. In many contexts this may correspond to verifying the identity of a data source.
• Integrity: this service aims at detecting when an adversary modifies an in-transit message and hence preventing information from being changed. To achieve this goal, a Message Authentication Code (MAC) is used in each message, which constitutes a cryptographically secure checksum. Because the MAC is “signed” with a secret key that is owned only by the parties involved in the communication, the MAC provides authentication at the same time.
• Non-repudiation: this service assures that an entity involved in a communication cannot deny having taken part in that communication (as the receiver or as the sender).
9.2. Security of IEEE 802.15.4 This section is divided into two subsections. Subsection 9.2.1 presents security suites of IEEE 802.15.4-2003, while subsection 9.2.2 shows the relevant elements with regard to security introduced by IEEE 802.15.4-2006.
9.2.1. Security suites of IEEE 802.15.4 IEEE 802.15.
422 specifies eight security suites, which are summarized in Table 9.1. Such suites may be classified into four groups, depending on their characteristics: no security, cipher only, authentication only and cipher plus authentication. All security suites employ the Advanced Encryption Standard (AES)  as the basis for the related cryptographic operation. The In this chapter, unless explicitly mentioned, the term IEEE 802.15.4 refers to the original version of the specification (published in 2003).
More details on the several security suites are shown below:
• No security. This suite constitutes the identity function and does not provide security services.
• AES-CTR. This suite provides confidentiality using the AES block cipher algorithm. The sender breaks the clear-text into 16-byte blocks and computes the ci = pi ⊕ Ek (xi) operation, pi being a clear text block, ci the corresponding ciphered text and xi the value of a counter used for i-th block.
• AES-CBC-MAC. This kind of suite provides authentication and integrity by means of the CBC-MAC algorithm. The sender may compute a 4-, 8- or 16-byte MAC. This MAC may be calculated by entities sharing a symmetric key. The sender appends the MAC to the clear text. The receiver verifies this code by calculating it from the received frame and comparing it with the value included in that frame.
• AES-CCM. This kind of security suite uses CCM mode for confidentiality (cipher), authentication and integrity. Roughly, integrity protection is first applied using CBC-MAC, and after that data are ciphered together with the 4-, 8- or 16-byte MAC, using AES-CTR mode.
A relevant fact about IEEE 802.15.4 security is that it does not specify key management mechanisms. Hence, higher layer functionality must carry out key management tasks. For instance, ZigBee defines key management functionality on top of an IEEE 802.15.4 network .
9.2.2. Security of IEEE 802.15.4-2006
The IEEE 802.15.4-2006  specification uses AES-CCM*, a minor modification of the AES-CCM mode used in the original IEEE 802.15.4 specification. AES-CCM* includes all the features of AES-CCM and includes also the cipher only and integrity only. These extra functionalities simplify the security operations. ZigBee uses IEEE 802.15.4-2006 security at MAC layer.
9.3. Security services of ZigBee ZigBee offers various security services that comprise key establishment, key transport, frame protection and device management . Subsection 9.3.1 presents the architecture of the security services offered by ZigBee.
Subsections 9.3.2 to 9.3.4 present security mechanisms at ZigBee MAC, NWK and APL layers, respectively. Subsection 9.3.5 offers a functional description of security services in a ZigBee network.