Personal Area Networks: Interconnects and Performance Enhancements

Transcription

1 University of California Los Angeles Personal Area Networks: Interconnects and Performance Enhancements A dissertation submitted in partial satisfaction of the requirements for the degree Doctor of Philosophy in Computer Science by Ling-Jyh Chen 2005

2 c Copyright by Ling-Jyh Chen 2005

3 The dissertation of Ling-Jyh Chen is approved. Ying Nian Wu M. Yahya Medy Sanadidi Richard R. Muntz Leonard Kleinrock Mario Gerla, Committee Chair University of California, Los Angeles 2005 ii

4 To My Mom and Dad iii

5 Table of Contents 1 Introduction Wireless Personal Area Networks (WPAN) Background Link Layer Enhancements for WPAN Adaptive RTO for Audio Streaming over Bluetooth Implementation Experiment Results Adaptive Packet Type for TCP over Bluetooth Analytical Evaluation of Optimal Packet Type Simulation Results Conclusion Improving Bluetooth Link Throughput via Interleaved FEC Burst Error Model Proposed Approach - Interleaved FEC (I-FEC) Analysis Simulation Conclusions Seamless Mobility Support for WPAN Overview of Seamless Handoff USHA: Universal Seamless Handoff Architecture iv

6 4.2.1 USHA Experiments Choosing the Best Handoff Server Smart Decision Model Other Extensions A Case Study of Video Streaming in Vertical Handoffs VTP Overview Experiments Discussion End-to-end Capacity Estimation in Wired and Wireless Networks Related Work Internet Capacity Estimation Capacity Estimation in Wireless Networks Measuring Asymmetric Path Capacity AsymProbe Simulation Emulator based Testbed Experiments Internet Experiments Discussion Measuring End-to-end Capacity in Wireless Ad Hoc Networks AdHoc Probe Path Capacity in Wireless Networks v

7 5.3.3 Simulation Results of Fixed Rate Wireless Networks Capacity estimation with Auto Rate Modems Testbed Experiments Conclusion Service Agility in Mobile and Heterogeneous Networks Passive Capacity Estimation TFRC Probe: Passive Capacity Estimation within TFRC TCP Probe: Passive Capacity Estimation within TCP Proposed Approach - I: Implicit Handoff Notification Proposed Approach - II: Explicit Handoff Notification Evaluation Vertical handoff from LOW to HIGH Vertical handoff from HIGH to LOW Discussion and Conclusion Summary Future Work References vi

8 List of Figures 1.1 The three scenarios of PAN applications Wireless technologies for WLAN and WPAN ZigBee topology models Comparison of narrowband (NB), spread spectrum (SS), and ultra wideband (UWB) Bluetooth Testbed Bluetooth Stack Link Quality vs BER for CSR chipset RTO adaptation of the proposed approach RTP packet success rate RTP packet delay Bluetooth throughput of different ACL packet types Packet Error Rate vs Bit Error Rate of different pkt types Simulation scenario: (a) 1 hop (b) 2 hop (c) 4 hop situation TCP Newreno throughput with/without the APT link layer for (a) 1-hop (b) 2-hops (c) 4-hops TCP Newreno throughput with/without APT (bit error rate is changing every 1 second) for (a) 1-hop (b) 2-hops (c) 4-hops Measured Bit Error Rate in 10 minutes TCP NewReno throughput with/without APT for (a) 1-hop (b) 2-hops (c) 4-hops (with measured bit error rate) vii

9 3.14 Markov Model for Wireless Link The expectation of burst error length with different P bb and P gb configurations (a) original FEC coding in Bluetooth DM mode; (b) I-FEC coding Retransmission Rates of different schemes evaluated at different P gb, given P bb = Retransmission Rates of different schemes evaluated at different P bg, given P gb = The accumulative ratio of burst length under different wireless channel conditions given P gb = ; (a) P bb = 0.99 (b) P bb = (a) 1 hop (b) 2 hop (c) 4 hop situation TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections under Burst Error channel with P bb = TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections under Burst Error channel with P gb = Mobile computing scenario Horizontal and Vertical Handoff Diagram of Universal Seamless Handoff Architecture Testbed configuration of the vertical handoff experiment between Ethernet and b Instantaneous throughout results of one TCP flow during a vertical handoff from b (11Mbps) to Ethernet (100Mbps) viii

10 4.6 Sequence number of one TCP flow during a vertical handoff from b (11Mbps) to Ethernet (100Mbps) Instantaneous throughout results of one TCP flow during a vertical handoff from Ethernet (100Mbps) to b (11Mbps) Sequence number of one TCP flow during a vertical handoff from Ethernet (100Mbps) to b (11Mbps) Instantaneous throughout results of one TCP flow during a vertical handoff from 1xRTT (150Kbps) to b (5.5Mbps) Sequence number of one TCP flow during a vertical handoff from 1xRTT (150Kbps) to b (5.5Mbps) Instantaneous throughout results of one TCP flow during a vertical handoff from b (5.5Mbps) to 1xRTT (150Kbps) Sequence number of one TCP flow during a vertical handoff from b (5.5Mbps) to 1xRTT (150Kbps) Diagram of Smart Decision Model Algorithm for making Smart Decisions on HCC An coefficient function example Rate adaptation in VTP Frame Rate received at the Mobile Host Sending Rate at the Video Server Frame Rate received at the Mobile Host Video Quality sent at the Video Server Sending Rate at the Video Server Frame Rate received at the Mobile Host ix

11 4.23 Sending Rate at the Video Server Frame Rate received at the Mobile Host Video Quality sent at the Video Server Sending Rate at the Video Server (a) Under-Estimation caused by expansion (b) Over-Estimation caused by compression (c) the ideal case Interaction of probe packets in asymmetric link scenarios Last-hop ADSL scenario. The link capacities are 100Mbps for all links, except the asymmetric DSL link between D and E ( 128Kbps from D to E; 1.5Mbps from E to D) Testbed for NIST Net experiments AdHoc Probe capacity estimate using the sample with minimum OWD sum Illustration of clock skew problem in OWD sum measurements The chain topology, where the solid-line circle denotes a node s effective transmission range and the dotted-line circle denotes a node s interference range Capacity estimation results of a wireless link (with no interference from other nodes) using one-way and round-trip CapProbe Capacity estimation along a chain of nodes with different chain lengths and probing packet sizes Capacity estimation of wireless multihop connections within the same collision domain x

12 5.11 Capacity estimation of wireless multihop connections within the same collision domain Capacity estimation in a grid wireless network without cross traffic Capacity estimation in a grid wireless network with both horizontal and vertical cross traffic Scenario of fixed source/destination and mobile intermediate nodes AdHoc Probe capacity estimates (average of 200 runs and the standard deviation) in fixed source/destination and mobile intermediate nodes simulation scenario MANET Scenario, where node 25 (The Host) is moving along the dotted path with a fixed speed (1m/sec) Capacity estimation of MANET scenario (with and w/o cross traffic) Illustration of , OAR, and PAC schemes Simulation results of AdHoc Probe on an auto rate wireless link with different displacements Experiment results of AdHoc Probe on wireless multihop testbed (transmission rate is 2Mbps on each link) Experiment results of b one hop connection (auto rate) with different distance between two hosts Auto Rate b Testbed with Bluetooth interference Experiment results of b with auto rate and with Bluetooth interference from varying distance Experiment results of estimating capacity from Internet to ad hoc networks xi

13 6.1 (a) original TFRC (b) TFRC Probe (the gray ones are back-toback sampling packets) Simulation Scenario Capacity monitoring of b connection using TFRC Probe TCP Westwood Bandwidth Estimate (BE) (a) back-to-back TCP packets generate only one ACK because of DelACK; (b) inverted back-to-back TCP Probe packets are separately acknowledged TCP Probe simulation scenario I (cross traffic flows are all in forward direction) TCP Probe simulation scenario II (cross traffic flows are in both forward and reverse direction) Illustration of the ERR algorithm for TCP/TFRC Probe Simulation scenario Simulation results of TFRC Probe (original, w/ FRA, and w/ EHN) during a vertical handoff from a 150kbps link to a 5Mbps link (the vertical handoff occurred at the 600th second) Simulation results of TCP Probe (original, w/ FRA, and w/ EHN) during a vertical handoff from a 150kbps link to a 5Mbps link (the vertical handoff occurred at the 600th second) Simulation results of TFRC Probe with/without explicit handoff notifications during a vertical handoff from a 5Mbps link to a 150kbps link (the vertical handoff occurred at the 600th second) xii

14 6.13 Simulation results of TFRC Probe with/without explicit handoff notifications during a vertical handoff from a 5Mbps link to a 150kbps link (the vertical handoff occurred at the 600th second) xiii

15 List of Tables 2.1 Different Bluetooth ACL connection modes IEEE frequencies and data rates Analytically calculated thresholds at which different packet types show best performance Packet error rates evaluated against different FEC schemes, link layer packet sizes, and P bb, given that P gb = and the initial channel state is Good Comparison of one-way and round-trip based approaches Comparison of active and passive approaches Estimate asymmetric link capacity by varying packet sizes (ideal case without cross traffic and any queuing delays) Simulation results on end-to-end link capacity estimation for lasthop DSL scenarios (Unit: Kbps) NIST Net results on High/Low asymmetric links (Unit: Mbps) NIST Net results on Low/High asymmetric links (Unit: Mbps) Internet results on asymmetric link Required time resolution for accurate estimation Types of cross traffic Simulation results of TFRC Probe/CapProbe capacity estimation Capacity estimation of TFRC Probe on the wired links of different technologies (Capacity: Mbps, Time: second) xiv

16 6.4 Capacity estimation of TFRC Probe on the wireless links of different technologies (Capacity: Mbps, Time: second) TCP Probe simulation results of scenario I and II (F b2b : ratio of back-to-back packets among TCP packets; F min : ratio of good samples among back-to-back TCP packets) The required number of TCP packets (Ñ) for obtaining one good sample in TCP Probe xv

17 Acknowledgments So many people have played an important part in the process of this work. I owe a special gratitude to my advisor, Professor Mario Gerla, who provided me guidance and enthusiasm whenever I needed direction, provided me resources to pursue research, and allowed me the freedom to explore areas I found interesting. His energetic attitude was contagious, and his keen insight into difficult technical problems was always a key factor in opening up new ideas in my research. My heartfelt thanks go to the members of my thesis committee, Dr. Leonard Kleinrock, Dr. Richard Muntz, Dr. M.Y. Sanadidi, and Dr. Yingnian Wu for being on my committee and making the work more solid than it would otherwise have been. I would like to specially thank Professor M.Y. Sanadidi, who has always patiently given me very useful guidance on my research and everything. I have also been delighted to collaborate with the unbelievably talented members of our research group: Dr. Rohit Kapoor, Tony Sun, Guang Yang, Li Lao, Anders Persson, Cesar A. C. Marcondes, Yeng-Zhong Lee, for their ideas, support, and companionship. I would like to also thank my Taiwanese friends. The friendship with them was what kept me going on during the most tough times. Thank all of you, who accompanied me in the classes, on the campus, on the badminton/tennis courts, and on the Internet. This work would not have been possible without the support of our sponsors, Hewlett-Packard, Ericsson, ST Microsystems, NSF, and I am grateful to them. xvi

18 Vita Dec. 24, 1975 Born, Taipei, Taiwan B.Ed. (Information and Computer Education), National Taiwan Normal University M.S. (Computer Science), University of California, Los Angeles Ph.D. (Computer Science), University of California, Los Angeles. Publications Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, and Mario Gerla. Monitoring Access Link Capacity Using TFRC Probe. Computer Communications Journal, Special Issue on Monitoring and Measurements of IP Networks, Elsevier, Ling-Jyh Chen, Rohit Kapoor, Sewook Jung, M. Y. Sanadidi, Mario Gerla. An Adaptive ARQ Timeout Approach for Audio Streaming over Bluetooth. International Journal of Wireless and Mobile Computing, Special Issue on Mobile Multimedia Systems and Applications, Inderscience Publishers, Rohit Kapoor, Ling-Jyh Chen, Li Lao, Mario Gerla, M. Y. Sanadidi. Cap- Probe: A Simple and Accurate Capacity Estimation Technique. ACM SIGxvii

19 COMM Computer Communication Review, volume 34, issue 4, pp: 67-78, ACM Press, October, Ling-Jyh Chen, Guang Yang, Tony Sun, M. Y. Sanadidi, and Mario Gerla. Enhancing QoS Support for Vertical Handoffs Using Implicit/Explicit Handoff Notification. The Second International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks, Orlando, USA, Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, Mario Gerla. End-toend Asymmetric Link Capacity Estimation. IFIP Networking 2005, Waterloo, Ontario, Canada, Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, Mario Gerla. Ad- Hoc Probe: Path Capacity Probing in Wireless Ad Hoc Networks. The First International Conference on Wireless Internet, Budapest, Hungary, Anders Persson, Cesar A. C. Marcondes, Ling-Jyh Chen, M. Y. Sanadidi, Mario Gerla, TCP Probe: A TCP with built-in Path Capacity Estimation. The 8th IEEE Global Internet Symposium, Minmi, USA, Ling-Jyh Chen, Tony Sun, and Mario Gerla. USHA: A Practical Vertical Handoff Solution. The First International Conference on Multimedia Services Access Networks, Orlando, USA, Ling-Jyh Chen, Tony Sun, Dan Xu, M. Y. Sanadidi, and Mario Gerla. Access Link Capacity Monitoring with TFRC Probe. The Second Workshop on Endxviii

20 to-end Monitoring Techniques and Services, San Diego, USA, Ling-Jyh Chen, Tony Sun, Benny Chen, Venkatesh Rajendran, and Mario Gerla. A Smart Decision Model for Vertical Handoff. The 4th ANWIRE International Workshop on Wireless Internet and Reconfigurability, Athens, Greece, Rohit Kapoor, Ling-Jyh Chen, M. Y. Sanadidi, Mario Gerla. Accuracy of Link Capacity Estimates using Passive and Active Approaches with CapProbe. The Ninth IEEE Symposium on Computers and Communications, Alexandria, Egypt, Ling-Jyh Chen, Tony Sun, M. Y. Sanadidi, Mario Gerla. Improving Wireless Link Throughput via Interleaved FEC. The Ninth IEEE Symposium on Computers and Communications, Alexandria, Egypt, Ling-Jyh Chen, Rohit Kapoor, M. Y. Sanadidi, Mario Gerla. Enhancing Bluetooth TCP Throughput via Link Layer Packet Adaptation. The 2004 IEEE International Conference on Communications, Paris, France, Ling-Jyh Chen, Rohit Kapoor, Kevin Lee, M. Y. Sanadidi, and Mario Gerla. Audio Streaming over Bluetooth: An Adaptive ARQ Timeout Approach. The 6th International Workshop on Multimedia Network Systems and Applications, Tokyo, Japan, xix

21 Abstract of the Dissertation Personal Area Networks: Interconnects and Performance Enhancements by Ling-Jyh Chen Doctor of Philosophy in Computer Science University of California, Los Angeles, 2005 Professor Mario Gerla, Chair A Personal Area Network (PAN) is a network composed of various wireless personal devices, which may or may not be connected to the Internet. Unlike Wireless LAN (WLAN) technologies, Wireless PAN (WPAN) technologies have been characterized as shorter range, lower data throughput, lower cost, and lower power consumption. Though the distinctions, in terms of transmission range and data throughput between WLAN and WPAN are dissolving with the emerging wireless technologies, the fundamental attributes of PAN are still unique and must be considered for performance optimization of PAN applications. We observe that there are three unique characteristics with PAN applications. Firstly, most PAN devices are specialized devices, e.g. some are designed for audio/video streaming between media server and wireless headset, and some are designed for data synchronization between desktop and personal devices. Secondly, PAN devices are required to accompany mobile users and expected to provide continuous connectivity even when mobile users are roaming among different networks domains and/or technologies. Lastly, PAN applications are extremely QoS-constrained, as PAN users are very sensitive to the perceived quality and xx

22 will grow impatient at poor application performance. Targeting these three defining PAN characteristics, we investigate link layer approaches for PAN performance enhancement. Using Bluetooth technology, we develop strategies to improve user-perceived streaming quality for real-time applications, and propose adaptive schemes that improve the data throughput of best-effort applications. For mobile PAN applications, we design a framework that supports seamless connectivity for mobile user switching from one network technology to another. To complement the seamless connectivity framework, an intelligent handoff decision model is proposed allowing the mobile node to determine the best network to connect to, and automatically perform vertical handoffs when necessary. In addition, we study the classic capacity estimation problem in the emerging network environments, i.e. asymmetric links and wireless networks, and we integrate capacity estimation algorithms into data transmission protocols providing passive capacity estimation/monitoring tools. Finally, based on our proposed intelligent handoff decision model and the passive capacity estimation/monitoring tools, we investigate and successfully enhance QoS support for various mobile networking scenarios. xxi

23 CHAPTER 1 Introduction A Personal Area Network (PAN) is a network composed of various wireless personal devices, which may or may not be connected to the Internet. The personal devices are usually referred to small and lightweight devices (e.g. PDAs, smart phones, and wireless wrist watches) that can easily accompany a traveling user. Due to the nature of these small and lightweight devices, they are usually battery powered and often limited in computation capabilities. Thus, it is desirable to provide efficient PAN connections to nearby personal devices while minimizing possible power consumption. This is the contrasting difference between the definitions of PAN and wireless local area networks (WLAN), which emphasizes on delivering high data throughput over the larger communication range. Various wireless technologies have been proposed to facilitate PAN connections. For instance, Bluetooth [Blua] has been well accepted as the enabler of PAN technology [JKK01], and it has been standardized in the IEEE Wireless Personal Area Network (WPAN) standard [IEEb]. Due to the lower cost, power, and smaller size advantages of Bluetooth chips, it is both functionally ideal as an interconnecting technology between PAN devices, as well as a convenient cable replacement technology. While deployed in the personal area networks, Bluetooth is capable of connecting up to eight personal devices to form a piconet, and different piconets can be connected to each other through designated gateway devices in piconets to form a scatternet. 1

24 Several emerging wireless technologies also exhibit great PAN potential, such as ZigBee [Zig] and Ultra Wideband (UWB) [IEEa] technologies. Though the distinctions, in terms of transmission range and data throughput between WLAN and WPAN are dissolving with the emerging wireless technologies, the fundamental attributes of PAN are still unique and must be considered for performance optimization of PAN applications. We observe that there are three unique characteristics with PAN applications. Firstly, most PAN devices are specialized devices, e.g. some are designed for audio/video streaming between media server and wireless headset, and some are designed for data synchronization between desktop and personal devices. Secondly, PAN devices are required to accompany mobile users and expected to provide continuous connectivity even when mobile users are roaming among different networks domains and/or technologies. Lastly, PAN applications are extremely QoS-constrained, as PAN users are very sensitive to the perceived quality and will grow impatient at poor application performance. On the other hand, the employments of PAN can be classified into three scenarios, as illustrated in Fig In the first scenario (a), one PAN device is connected to the service provider (e.g. a desktop or a laptop) or another PAN device wirelessly to form a simple PAN, where all data communications are within the PAN. In the second scenario (b), one PAN device is connected to an Internet access point, and the data communications occurs between the PAN device and the Internet through the access point, where the access point could be a non-pan device or a PAN device equipped with both wireless technology to the PAN device and whatever networking technology to the Internet. In the last scenario (c), several PAN devices are grouped together to form an ad hoc network and an effective ad hoc routing protocol is applied in this scenario. Note that, 2

25 Figure 1.1: The three scenarios of PAN applications all data communications in this scenario are within the ad hoc network unless access points are defined and presented among these PAN devices. In this dissertation, we target the interconnection and performance enhancements for PAN applications. We study and evaluate PAN applications in mobile scenarios. We also investigate strategies, either at the link layer or at the transport layer, to improve PAN application performance. The goal of our study is to render WPAN applications more flexible and enjoyable for PAN users. More specifically, in this dissertation, we investigate PAN performance enhancements via link layer approaches (Chapter 3). Using Bluetooth technology, we develop a few strategies to improve user-perceived streaming quality for real-time applications, and we propose adaptive schemes that improve the data throughput of best-effort applications. For mobile PAN applications, we design a framework that supports seamless connectivity for mobile user switching from one network technology to another (Chapter 4). To complement the seamless connectivity framework, an intelligent handoff decision model is proposed allowing the mobile node to determine the best network to connect to and auto- 3

26 matically perform vertical handoffs when necessary. In addition, we study the classic capacity estimation problem in the emerging network environments, i.e. asymmetric links and wireless networks, and we integrate capacity estimation algorithms and data transmission protocols to become passive capacity estimation/monitoring tools (Chapter 5). Finally, based on our proposed intelligent handoff decision model and the passive capacity estimation/monitoring tools, we investigate and successfully enhance QoS support for various mobile networking scenarios (Chapter 6). 4

27 CHAPTER 2 Wireless Personal Area Networks (WPAN) Background PAN devices are usually small and lightweight devices (e.g. PDAs, smart phones, and wireless wrist watches) that can easily accompany a traveling user. Due to the nature of these small and lightweight devices, they are usually battery powered and often limited in computation capabilities. Thus, it is desirable to provide efficient PAN connections to nearby personal devices while minimizing possible power consumption. This is the contrasting difference between the definitions of WPAN and wireless local area networks (WLAN), which emphasize the delivery of high data throughput over a wider geographical distance. Yet, with the fast evolution and convergence of wireless technologies, the boundary between WPAN and WLAN has been becoming imperceptible. As shown in Fig. 2.1, the transmission range of the prevalent WPAN and WLAN technologies are overlapped within the same range (i.e meters), and some WPAN technologies (e.g. UWB) are even able to achieve higher data rates than WLAN technologies (e.g a/b/g). Additionally, the applications of WPAN and WLAN devices are also converging. For instance, people, though equipped with WLAN devices, usually prefer to directly exchange data, instead of transmitting data through local area networks or Internet, due to privacy and security concerns. On the other hand, 5

28 Figure 2.1: Wireless technologies for WLAN and WPAN people, who equipped with WPAN devices, also occasionally have the needs to upload/download data to/from the Internet, while they don t want to change the ongoing wireless technologies from one to the other. As a result, the usage of WPAN and WLAN is interchangeable and becoming difficult to distinguish. Moreover, with the increasing demands of user mobility, the interaction among WPAN, WLAN, and WWAN (Wireless Wide Area Networks) is also becoming increasingly desired. For instance, one mobile user with a lightweight personal device may need to synchronize his personal data via WPAN, surf the WWW information via WLAN, and keep the Internet connectivity via WWAN while out of WLAN range. As a result, a complete PAN solution should take advantages of WPAN, WLAN, and WWAN. We present a brief overview of these technologies as follows. 1. Bluetooth Bluetooth [Blua] is a short-range radio technology operating in the un- 6

29 licensed 2.4GHz ISM (Industrial-Scientific-Medical) frequency band. Its original goal was to replace the numerous proprietary cables to provide a universal interface for devices to communicate with each other. But it soon became a good solution to interconnect devices to form so-called personal area networks [JKK01], primarily due to the low cost, low power and small size of Bluetooth chips. Bluetooth employs FHSS (Frequency Hopping Spread Spectrum) to avoid interference. There are 79 hopping frequencies (23 in some countries), each having a bandwidth of 1MHz. Frequency hopping is combined with stop and wait ARQ (Automatic Repeat Request), CRC (Cyclic Redundancy Check), and FEC (Forward Error Correction) to achieve high reliability on the wireless links. Bluetooth units can be connected to other Bluetooth units to form a piconet, which can support up to eight active units. One of the units in a piconet acts as a master and the other units act as slaves. All the data/control packet transmissions are coordinated by the master. Slave units can only send in the slave-to-master slot after being addressed in the preceding master-to-slave slot. Each slot lasts for 625 microseconds. For real-time data such as voice, Synchronous Connection Oriented (SCO) links are used, while for data transmission, Asynchronous Connectionless Link (ACL) links are used. There are several ACL packet types, differing in packet length (and consequently, data transmission rate) and whether they are FEC coded or not. For ACL links, there are two connection modes, namely DH and DM, differing in their usage of FEC coding. In DH mode, Bluetooth sends packets without FEC coding in order to maximize the achievable throughput; 7

30 Table 2.1: Different Bluetooth ACL connection modes Packet Symmetric Asymmetric Mode FEC Size Length Throughput Throughput (bytes) (slots) (Kbps) (Kbps) DM1 Yes DM3 Yes DM5 Yes DH1 No DH3 No DH5 No whereas in DM mode, it uses a (15, 10) shortened Hamming code to protect the packets from transmission errors. In DM mode, each block of 10 information bits is encoded into a 15 bit codeword, and it is capable of correcting single bit error in each block. Table 2.1 shows the different ACL packet types and their properties. Note that, in the symmetric connection mode, both master and slave nodes will occupy the same amount of Bluetooth time slots (625 microseconds in each time slot); whereas in the asymmetric connection mode, the Bluetooth link will occupy 1/3/5 time slots (for DM1/DM3/DM5 or DH1/DH3/DH5 mode) in one direction of this link and only one time slot in the opposite direction. 2. ZigBee ZigBee is a Low-Rate Wireless Personal Area Networks (LR-WPANs) standard targeted at home and building automation and controls, situational 8

31 Table 2.2: IEEE frequencies and data rates PHY (MHz) Frequency Band (MHz) Modulation Data Bit Rate BPSK 20 kbps 868/ BPSK 40 kbps O-QPSK 250 kbps awareness and precision asset location, medical and safety monitoring, and entertainment [ZL04]. The underlying physical (PHY) and medium access control (MAC) layers of ZigBee has been standardized as IEEE [IEEc], whereas the network and upper layers are specified by ZigBee Alliance [Zig]. IEEE defines two PHY layers, namely the 2.4GHz and 868/915 MHz band. While the 2.4GHz band is available worldwide, 868MHz and 915MHz bands are available in Europe and North America respectively. There are totally 27 channels specified in IEEE More specifically, there are 16 channels with 250Kbps maximum data rate in the 2.4GHz band, 1 channel with 20Kbps data rate in the 868.3MHz band, and 10 channels with 40Kbps data rate in the MHz band. The detailed frequencies and data rates of IEEE are listed in Table 2.2. The channel access employed in IEEE is carrier sense multiple access with collision avoidance (CSMA/CA). Two data transmission modes, namely beacon-enabled mode and non-beacon-enabled mode, are implemented to support slotted and unslotted CSMA/CA. Depending on the device capabilities, the IEEE device can be functioned as a network coordinator, full function device, or reduced function device. While the overall design principle of IEEE is to provide simplic- 9

32 Figure 2.2: ZigBee topology models ity, long battery life, networking capabilities, reliability, and low cost, the ZigBee Alliance specifies the interoperability (i.e. in the network and upper layers) for the devices. For instance, ZigBee network can be configured to form a star, mesh, or cluster tree topology, as shown in Fig. 2.2, and it is expected to be used in wireless sensor networks (WSN) and low-rate wireless personal area networks (LR-WPAN). 3. Ultra Wideband (UWB) Ultra-Wideband (UWB) technology has been standardized by IEEE as a [IEEa]. Instead of using conventional narrowband (NB) radio frequency and spread spectrum (SS) technologies, UWB uses an extremely wide band (i.e from 3.1GHz to 10.6GHz) to transmit data, as shown in Fig As a result, UWB devices are more scalable and adaptive than traditional NB and SS designs. Moreover, UWB devices is able to coexist with other systems well. Different to ZigBee technology, UWB is targeted at High-Rate Wireless 10

33 Figure 2.3: Comparison of narrowband (NB), spread spectrum (SS), and ultra wideband (UWB). Personal Area Networks (HR-WPANs), which are composed of several personal devices of high bandwidth demands, such as PDA, printers, digital imaging systems, speakers, displays, and etc. The technical requirements of UWB are to support 110 Mbps bit rate with 30 ft distance and 200 Mbps bit rate with 12 ft distance. The higher bit rates are also desirable when the transmit range is reduced. Moreover, the UWB device is required to operate effectively in the presence of other UWB devices or other IEEE systems (e.g a/b/g). Finally, the power consumption of the UWB system must be low enough so that UWB can be deployed on battery operated devices. 11

34 CHAPTER 3 Link Layer Enhancements for WPAN With the increasing utilization and the consumption of digital information through wireless PAN devices, maximizing the available wireless channel bandwidth becomes essential in maintaining service quality to PAN users. Since a wireless communication channel typically exhibits higher error rates due to attenuation, fading, scattering, or interference from other active sources, a challenging problem is to provide the wireless applications with the best possible data throughput in the presence of wireless channel errors. As most wireless channel errors are discovered and discarded at the link layer, link layer retransmission triggered by corrupted data decreases the effective channel bandwidth. This results in inferior performance from higher network layers such as TCP and video streaming applications. Therefore, if the number of retransmissions can be reduced with a robust link layer error controlling scheme, the performance of wireless communication would dramatically improve against channel errors. Traditionally, one of three techniques is used for error-control: 1) Retransmission which uses acknowledgements, and time-outs; 2) Redundancy, and 3) Interleaving [FW02, PH98]. Retransmitting lost packets is an obvious means by which error may be repaired, and it is typically performed with Automatic Repeat request (ARQ) at either the link layer or at the transport layer as in TCP. When data is exchanged through a relatively error-free communication 12

35 medium, retransmission is clearly a good tactic. However, retransmission is not the best strategy in an error-prone communication channel, where high latency and bandwidth overhead are believed to make retransmission a less than ideal error controlling technique. Redundancy is the means by which repair data is added along with the original data, such that corrupted packets can be repaired at the receiver without any additional transmission from the sender. A number of redundancy techniques have been developed in both the application and link layers to combat the effect of errors [RAT, KHH97]. Some popular link layer protocols, such as Bluetooth and a have implemented some variations of data redundancy techniques such as Forward Error Correction (FEC), which is well recognized for its robustness against random data losses, to enhance their throughput performance. However, redundancy comes at the cost of reduced bandwidth, since these schemes incur error correction overhead. As an error concealment scheme, Interleaving is a useful technique for reducing the effects of losses. The basic idea behind interleaving is to first re-sequence the data before transmission, so that originally adjacent units of data are separated by a predetermined distance while in flight from source to destination, and return to their original order at the receiver. Since interleaving reduces the damage from loss by dispersing the occurrence of errors in the original stream, [CZ03, TZ99, CC01] have deployed interleaving techniques to real-time video streaming applications to obtain better performance. On the other hand, even though interleaving doesn t impose any extra bandwidth overhead, it can potentially increase the processing latency, as the receiver requires that all the necessary transmitted data packets be in its buffers before it can reconstruct the original data packets. 13

36 A combined solution in the link layer will take advantages of the three traditional strategies in providing a more robust and high performance wireless channel. A cross-layer optimization with awareness of application properties can even enhance the application performance. For most of PAN devices and applications, which are wireless connected and mostly have specific purposes, such cross-layer optimization and link layer enhancements can go a long way in providing better application performance. Being the enabler of personal area network [JKK01], Bluetooth technology is selected for the study of link layer support in PAN. Three strategies are considered in this issue: retransmission, redundancy, and interleaving; where Automatic Retransmission request (ARQ) and Forward Error Correcting (FEC) coding are originally provided by Bluetooth technology for preliminary support of retransmission and redundancy strategies. Aiming at different application purposes and different channel conditions, different link layer enhancements are presented as follows. 3.1 Adaptive RTO for Audio Streaming over Bluetooth Bluetooth uses a stop-and-wait ARQ at the link layer and retransmits a packet until either the acknowledgement of a successful reception is received or the retransmission timeout is exceeded, at which point the packet is dropped [Blua]. However, in most current Bluetooth chipsets, the default value of the retransmission timeout (RTO) is infinite. An infinite timeout value makes the link layer reliable, since packets are not dropped even when the channel conditions are very bad. However, this can lead to problems for real-time/streaming media, since packets may be severely delayed when link quality is poor. 14

37 A simple approach could be to use a fixed, finite RTO value. This will result in packets being dropped at the link layer, whenever the retransmission limit is exceeded. Since a severely delayed packet may be completely useless at the client, dropping such a packet may be a good idea anyway since subsequent packets have a higher chance of being transmitted. Thus, this approach may improve audio quality if the retransmission timeout (RTO) can be selected judiciously. Therein lies the problem of using a fixed, finite RTO since it may not be easy to find a timeout value suitable for all the cases, such as different link qualities. Moreover, if such a setting is not appropriate, it may again degrade the audio quality. For example, if the fixed timeout value is too small, it will increase the drop rate; if the value is too large, it will lead to the same situation as the infinite RTO setting. To overcome such problems, we propose an adaptive ARQ RTO approach that adapts the value of the link layer RTO based on the measured properties of previous packets. Thus, if the link layer has spent too much time on the previous few packets, it should decrease the RTO setting for the next packet, since the audio client has already experienced much delay from the previous packets. In other words, it is better to risk to drop the next packet (due to the decrease in RTO) than to incur another increase in delay. On the other hand, if the link layer has sent the previous packets very efficiently with short RTTs (round trip time), it should increase the RTO value since the client has already saved time on previous packets and is capable of tolerating some delay for the next one. Thus, it pays to put some extra effort to reduce packet loss (by increasing RTO). Namely, the link layer measures the RTT of each audio packet, say RTP [SCF96] packet, which is the time for the whole RTP packet to get transmitted by the link layer (this implies the use of an application-aware link layer, as we 15

38 discuss later). Using the value of the RTT, a smoothed RTT, SRTT, is calculated (Eq. 3.1), from which the RTO is calculated. The SRTT and RTO update equations are: SRT T = (1 γ) SRT T + γ RT T (3.1) α RT O if RTT < SRTT RT O = β RT O RT O if RTT > SRTT if previous packet is dropped (3.2) where we take γ = 0.25, α = 1.1, and β = 0.9. Note that the RTO is dynamically updated using a multiplicative increase/decrease scheme following the threshold check. RTO increases when RTT decreases and vice versa. This is very different from TCP, where the RTO is increased proportionally to RTT. In addition, we also apply upper and lower bounds to the RT O value. The lower bound RT O min is taken as 2 T packet, which is the time interval between two RTP packets sent on the server side. T packet can be easily derived from the packet size of the RTP packet, and we will present the calculation in the next section. We found through our experiments that if the RTO value was set close to the T packet, too many packets were dropped at the link layer due to the RTO limit being exceeded. Thus, 2 T packet proved to be a good lower bound. The upper bound RTO is proportional to the available buffer size, as shown in the following equation. B avail = (B MAX B used )/P RT P (3.3) RT O max = T packet Max(B avail 75%, 2) (3.4) 16

39 where B avail is the available buffer size, which is the system maximum input buffer size (B MAX ) minus the used buffer size (B used ), divided by the RTP packet size (P RT P ). This equation takes into account the fact that if the RTO for an RTP packet is too large, it may cause new incoming RTP packets to be dropped from the input queue due to overflow. In fact, we found that for very large values of RTO, a number of packets were dropped because the buffer was full. Limiting the RTO to this upper bound prevented such packet drops. Note that, in Eq. 3.2, we do not update the RTO if the previous packet has been dropped due to timeout. However, because contiguous packet dropping is harmful to audio quality, we reset the RTO to RTOmax, using Eq. 3.4, if at least two of the last 5 packets have been dropped Implementation We implemented both the fixed RTO and the adaptive RTO method on our Bluetooth testbed. The testbed consists of two Linux based laptops, both equipped with a Bluetooth PCMCIA card. We installed Bluez [Blub], which is an open source Bluetooth Stack on the Linux operating system, on both laptops. We also used some other b devices to generate the interference to our Bluetooth connection during our experiments. We used DH5 packets in all our experiments. The system setup is shown in Fig The streaming protocol used in our experiments is RTSP (Real-Time Streaming Protocol) [SRL98], which is widely used on the Internet. RTSP is an applicationlevel protocol to control the delivery of real-time multimedia data for both unicast and multicast. RTSP segments the MP3 stream into many small RTP packets at the server; the client can control the delivery (move backward, move forward, play, or stop) via the RTCP (RTP Control) protocol. Each RTP packet contains 17

40 Figure 3.1: Bluetooth Testbed an RTP sequence number and may contain several MP3 packets. The audio stream used in our experiments is a 128kbps bit rate, 44.1 MHz frequency, Layer II MP3 file. The MP3 packet size of this music is 417 bytes, and each RTP packet contains 3 MP3 packets plus the header information (16 bytes). Thus, the RTP packet size is = 1267 bytes, and the T packet, the time interval between two RTP packets sent on the server side, is / msec. Since we use DH5 packets which have a maximum payload size of 339 bytes, each RTP packet will need at least 4 DH5 packets to be transmitted; therefore, the minimum transmission time for each RTP packets is (5 + 1) 4 15 msec, where msec is the Bluetooth slot time, (each DH5 packet consumes 5 time slot in one direction and 1 in the opposite direction) Implementation on Bluez Bluez is an open-source implementation of the Bluetooth stack on the Linux operating system. In the Bluetooth stack (shown in Fig. 3.2), the HCI (Host Controller Interface) layer provides a command interface to communicate, access, and control the hardware layer. The L2CAP (Logical Link Control and Adaptation Layer Protocol) layer provides connection-oriented and connectionless data 18

41 Figure 3.2: Bluetooth Stack services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation. The BNEP (Bluetooth Network Encapsulation Protocol) [BNE] layer lies on top of the L2CAP layer and provides support for IP. To make the link layer application-aware, we extract header information in the BNEP layer from the received RTP packet. The BNEP layer passes the information downward the Bluetooth stack to the L2CAP layer and then the HCI layer. Each RTP packet is split into multiple fragments by the L2CAP layer. Once the fragments of the RTP packet arrive at the HCI layer, it queues all the fragments and stores the arrival time of the first fragment. The measured RTT (Round Trip Time) is the time for all the fragments of the RTP packet to be successfully transmitted. In case one fragment of the RTP packet is dropped due to the RTO being exceeded, the remaining fragments of the RTP packet are removed from the HCI layer and the baseband by using the HCI Flush command (which is defined in the Bluetooth specs [Blua]). 19

42 Generating Interference One challenge of our testbed setup was generating reliable interference. We found that it was very difficult to control the signal strength in the testbed since environmental factors make the link quality unpredictable. We used b devices to create interference for the Bluetooth connections, because both of them operate in the 2.4 GHz frequency band. Though increasing the physical distance between the two Bluetooth devices decreased the link quality, we found that it also increased the variance of the link quality and therefore makes conditions difficult to control. We were able to control the signal strength by keeping the two Bluetooth devices very close and controlling the traffic loads on interfering b connections. To obtain the link quality from the Bluetooth chipset, we used the Get Link Quality function call. This call is defined in the Bluetooth spec [Blua] as the following manner: Get Link Quality : This command returns the value of the Link Quality. It returns a number between 0 and 255, with the higher value representing a better channel. Each Bluetooth module vendor will determine how to measure the link quality. As an example, for Bluetooth cards containing CSR (Cambridge Silicon Radio [CSR]) chipsets, the Link Quality is calculated from the Bit Error Rate in the following manner: IfBER(BitErrorRate)=0,LQ(LinkQuality)=255 IfBER<=40/40000,LQ=255 BER

43 Figure 3.3: Link Quality vs BER for CSR chipset If40/40000<BER<=4000/40000,LQ=215 ((BER/32) 40000) If4000/40000<BER<=40000/40000,LQ=105 ((BER/256) 40000) Fig. 3.3 shows the relation of the measured link quality value versus bit error rate for the CSR chipset, and we will make use of such relation to monitor and calibrate the channel and correlate to the RTO dynamics in the following experiments Experiment Results In this section, we present experiment results showing the improvement in realtime audio quality when using the proposed approach. The testbed setup and implementation are described in previous section, and the experiments are repeated under different link quality conditions. In the following experiments, we use Adapt to stand for our adaptive scheme and Fixed 160, 400, 1200 to stand for the fixed RTO method with timeout values 160, 400, and 1200 msec respectively. It should be noted here that in the default Bluetooth implementation, the ARQ timeout is infinite, i.e., the link layer never drops a packet. 21

44 Figure 3.4: RTO adaptation of the proposed approach Note that, because of the difficulty to control the link quality in the real experiments, the link quality distribution of each experiment is unique, even though the average BER might be the same. However, the average performance trend should be clearly observed Adaptive RTO In the first experiment, we show the RTO adaptation behavior of our proposed approach. In Fig. 3.4, the solid line represents the RTT, i.e., the time between the arrival of an RTP packet at the Bluetooth baseband layer and completion of its successful transmission, and the dashed line represents the adaptive RTO value. The ARQ timeout events are marked as circles in the figure. It can be seen that the adaptive RTO value increases as the RTT decreases and vice versa, in accordance with Eq

45 Figure 3.5: RTP packet success rate RTP Packet Success Rate Fig. 3.5 shows the RTP packet success rate on the receiver side, i.e. the percentage of packets successfully transmitted. Different BERs were generated by varying the load on interfering connections, as explained earlier. Our adaptive scheme outperforms the fixed ARQ timeout schemes, clearly showing the benefit of changing timeout based on channel conditions. The fixed 160 actually outperforms the higher ARQ timeout cases. Though this result may look counter-intuitive since a higher ARQ timeout is expected to drop fewer packets due to ARQ timeout, in reality higher ARQ timeouts also lead to a larger number of packets being dropped due to input queue overflow. This is exactly the reason why fixed 1200 shows the least RTP packet success rate. The vanilla Bluez link layer, which has an infinite ARQ timeout, performs similar to the fixed 1200 timeout RTP Packet Delay Fig. 3.6 shows the RTP average packet delay at the audio client. While the packet success rate determines how much data is successfully transmitted, the 23

46 Figure 3.6: RTP packet delay average packet delay represents how smooth the quality is. From the figure, it is obvious that the adaptive approach is able to achieve smaller average delays. Even with a BER of , the average delay is still close to the minimum value, which means acceptable audio quality. For the fixed RTO cases, the higher the ARQ RTO timeout, the higher is the average packet delay. This is obvious since a larger ARQ timeout value leads to a larger number of retransmissions. In balance, from the examination of the results in Fig. 3.5 and 3.6 one concludes that the adaptive packet scheme operate adequately with BER up to (packet loss rate less than 10% and delay less than 50 ms). The vanilla scheme, with infinite RTO will fall apart for BER <.002. This is a remarkable improvement in performance. 3.2 Adaptive Packet Type for TCP over Bluetooth Wireless links are characterized by higher bit error rates and this causes inefficiencies in the operation of TCP [BSA95]. Essentially, any perceived packet loss (occurring because of error or buffer overflow) is construed by a TCP sender as 24

47 occurring due to buffer overflow. The response of TCP to all such events is to invoke its congestion control procedures, resulting in unnecessary window reduction, which causes a drop in the TCP throughput. Note, though, that some of the packet losses occur due to corrupted packets being dropped by the link layer and invoking the congestion avoidance procedures when these events occur is not desirable. Most wireless interfaces available today monitor the characteristics of the medium and can provide such information when appropriate APIs are invoked. As explained in [Mod97], using this information, the optimal link layer packet type for the prevailing channel conditions can be adaptively selected. By optimal, we mean the link layer packet type (or link layer packet size) that maximizes the throughput at the link layer. In this section, we show the effects of adaptively selecting the optimal link layer packet type on the performance of TCP over a wireless link. Using Bluetooth [Blua] as the wireless technology, we present a simple analytical method to select the optimal link layer packet type, given the channel conditions. We perform simulations under different conditions to show that TCP throughput can be improved significantly by the use of the optimal packet type. One thing to be noted is that though we have demonstrated our results using Bluetooth, this technique could be applied to any other wireless technology, as long as it is possible to adapt the packet length or the use of Forward Error Correction according to the prevailing channel conditions Analytical Evaluation of Optimal Packet Type In this subsection, we describe a simple analysis to determine the relative performance of different packet types under different channel BERs (bit error rates). The analysis can then be used to determine the threshold values of the BER, 25

48 i.e., values at which the packet type that gives the best performance changes. Suppose the BER is b, the packet size (which is given in Table 2.1 for different packet types) is s bits and the number of Bluetooth slots occupied by a packet type is n. The packet error rate, p, for DH packets is: p = 1 (1 b) s (3.5) Recalling that DM packets are encoded with a 2/3 block FEC, i.e., in every block, 15 bits are used to encode 10 bits of data, and this block coding can correct 1 bit in every block of 15 bits. The packet error rate, p, for DM packets can be approximated as: p = 1 ((1 b) b(1 b) 14 ) s/15 (3.6) Assuming that the ARQ scheme retransmits a packet until the acknowledgement of a successful reception, the average number of attempts, N, needed to successfully transmit one packet is given by: N = k=1 k(1 p)p k 1 = 1 1 p The effective link layer throughput T is then given by: (3.7) T = s N (n + 1) 625us = s(1 p) (n + 1) (3.8) where s (packet size in bits) and n (length of packet in Bluetooth slots) for different packets as given in Table 2.1, and 625µs is the length of a Bluetooth slot. 26

49 Figure 3.7: Bluetooth throughput of different ACL packet types Figure 3.8: Packet Error Rate vs Bit Error Rate of different pkt types Using Eq. 3.8, we plot the effective throughput of Bluetooth packets versus the bit error rate in Fig Assuming UDP traffic sources, Fig. 3.8 shows the relation between bit error rate and packet error rate for different ACL packet types. The robustness of the coded DM packet types is visible in the figure. As the bit error rate increases, the packet error rate of DM packet types increases at a much smaller rate than that of the DH packet types. Using the above analysis, we added a feature to the Bluetooth link layer to enable it to select the optimal packet type, using the thresholds in Table 3.1, 27

50 Table 3.1: Analytically calculated thresholds at which different packet types show best performance Mode BER range DH5 < DM5 > , and < DM3 > , and < DM1 > dynamically based on link conditions. We implemented this functionality in our simulator. In later sections, we refer to this as the enhanced adaptive packet type (or APT) link layer Simulation Results In this subsection, we present simulation results showing the improvement in performance when using the enhanced Bluetooth link layer. The Bluetooth simulation model was developed as an extension to NS-2 (Network Simulator) [NS2]. The simulation model implements most of the features of the Bluetooth baseband layer, such as frequency hopping, time division duplexing, multi-slot packets, fragmentation and reassembly of packets. In addition, the simulator enables scatternets and inter-piconet communication by defining gateway nodes to forward packets between piconets. errors. The channel model assumes independent bit The Bluetooth topologies we used in the simulations is shown in Fig Black circles represent master nodes, and white circles represent slave (or gateway slave) nodes. Each simulation was run for 600 seconds. We varied the bit error rate to obtain performance results under different conditions. We also ran 28

51 Figure 3.9: Simulation scenario: (a) 1 hop (b) 2 hop (c) 4 hop situation connections over a different number of hops and tried different versions of TCP (Tahoe [Jac88], Reno [Ste97], and NewReno [FH99]). The TCP packet size was 500 bytes, and the buffer size of each Bluetooth node was set to 9000 bytes. Note that in the 2-hop case, the capacity of the master (black node) will be shared between the two slaves. Thus, the maximum throughput in this case is half of the maximum throughput in the 1-hop case. For the 4-hop case, the maximum throughput is the same as that of the 2-hop case Fixed bit error rate In the first set of simulations, we ran a TCP NewReno connection over 1, 2 and 4 Bluetooth hops. We also considered various values of the bit error rate on the link. Fig (a), (b) and (c) show the throughput obtained by TCP NewReno when running over the enhanced link layer and compare these results with those of a regular link layer. The enhanced link layer clearly outperforms the regular link layer. In fact, for high bit error rates, the throughput of NewReno over a regular link layer goes to zero, while that over the enhanced link layer falls only slightly. 29

52 Figure 3.10: TCP Newreno throughput with/without the APT link layer for (a) 1-hop (b) 2-hops (c) 4-hops Varying bit error rate We then considered a changing bit error rate environment, in which the bit error rate switches from to and back every 1 second. The aim was to evaluate the adaptation of the APT link layer under changing channel conditions. The TCP version used was NewReno. Fig (a), (b) and (c) show the throughput results over regular and en- 30

53 Figure 3.11: TCP Newreno throughput with/without APT (bit error rate is changing every 1 second) for (a) 1-hop (b) 2-hops (c) 4-hops hanced link layers. In these results, the TCP throughput is sampled every 10 seconds. The improvement in throughput is again very significant, in some cases almost an order of magnitude APT with real bit error rate measurement In order to simulate the APT enabled link layer with more realistic error behavior, we took traces of the channel behavior of a real Bluetooth environment over 31

54 Figure 3.12: Measured Bit Error Rate in 10 minutes a 5-minute period and plugged these into our simulator. The measurements environment consisted of two Xircom Bluetooth cards (containing the CSR chipset) at a 5-meter distance, with b devices, placed near one of the Bluetooth devices, generating interference. We used the Get Link Quality function (defined earlier) to obtain the Link Quality at every 100 msec from the Bluetooth device close to the devices and converted this into the bit error rate, using the technique explained in section Fig shows the measured bit error rate over the 10-minute period. We plugged this time varying BER trace into our simulator and ran TCP NewReno over 1, 2 and 4-hops. The results are shown in Fig Clearly, the enhanced link layer outperforms the regular link layer Conclusion In this section, we evaluated the effect of selecting the optimal packet type (size) at the link layer on the performance of TCP. We described a simple analytical model to select the optimal packet type when using Bluetooth. We presented an 32

55 Figure 3.13: TCP NewReno throughput with/without APT for (a) 1-hop (b) 2-hops (c) 4-hops (with measured bit error rate) enhanced link layer, which selects the optimal packet type based on channel conditions. Using simulation experiments, we showed that the throughput of TCP is improved significantly when the enhanced link layer is used, particularly when the bit error rate on the wireless link is high. In a sense, these results show that a well-designed and optimized link layer can make a big difference in performance in a wireless environment. 33

56 3.3 Improving Bluetooth Link Throughput via Interleaved FEC So far, we have studied TCP and audio streaming over Bluetooth in wireless scenarios with different levels of random error rates. However, unfortunately, wireless channel errors are usually bursty in occurrences. A pure retransmission strategy is too costly for the error-prone wireless communication channel. Redundancy and interleaving techniques are not enough by themselves to safeguard data transmissions from burst errors. Redundancy methods such as FEC coding are only effective in counteracting random losses, but the connection is still vulnerable to burst channel errors. Interleaving is capable of minimizing the effect of burst errors, but it can not recover from the errors introduced into the data packets. Besides, typical packet level interleaving methods, such as [CZ03, TZ99], costs extra latency to the connection. In this section, we focus on the problem of protecting link layer data against the random errors and burst errors that characterizes the wireless channel. By combining the robustness of FEC against random errors and the survivability of Interleaving against burst channel errors, we show that applying bit level interleaving to FEC coded packets is an effective method to combat wireless channel burst errors. The tactic we deployed is I-FEC, which stands for Interleaved- Forward Error Correction. We compare the data retransmission rate of I-FEC under different burst error rates against the other schemes, and compare the TCP throughput result of I-FEC to Bluetooth s built-in FEC coding scheme under different topologies and channel conditions. Without costing any additional overhead or latency, we show that I-FEC consistently and significantly outperforms FEC by achieving an 34

57 unparalleled amount of protection against heavy channel burst errors Burst Error Model In reality, wireless channel errors are usually bursty and dependent in occurrences, rather than uniformly and independently distributed. To capture such behavior in the wireless channel, a discrete time Markov Chain (DTMC) model depicted in Fig. 3.14, commonly known as the Gilbert-Elliott model [Ell63, Gil60], is used to model the true nature of wireless channel errors. The Gilbert-Elliott model consists of two states, namely the Good state and the Bad state. Events originate from these states are denoted as g and b respectively. Four transition probabilities, P gg, P gb, P bg, and P bb, are then given and they specify the state transition probabilities. For example, P gb defines the probability of transition from the good state to bad state, and P bb defines the probability of remaining in bad state, which actually reflects the degree of burst errors. The Markov chain is ergodic with stationary probabilities P g = 1 P bb 1 P bb +P gb and P b = P gb 1 P bb +P gb, and P b is the average bit error rate (BER) [ZR97]. The expectation of burst error length, L, can thus be obtained by Eq Fig depicts the relationship among P bb, P gb, and the expectation of burst error length. L = (n P g P gb Pbb n P bg ) (3.9) n=1 Given P gb = and initial channel state is Good, Table 1 shows the packet error rates under different degrees of burst error. The packet error rate was conjointly evaluated against the different packet sizes (100, 200, and 500 bytes), and different FEC coding schemes ((15,10), and (7,4) Hamming code). The (m, n) Hamming coding means n bits data are coded into a m bits codeword with the ability to correct single bit error in each codeword. 35

58 Figure 3.14: Markov Model for Wireless Link Figure 3.15: The expectation of burst error length with different P bb and P gb configurations. Table 3.2 clearly shows that data packet coded by FEC scheme outperforms data packets without FEC coding when P bb (degree of burst error) is small. However, when P bb increases, we note that FEC coding schemes cease to make a significant difference in the packet error rate. We also observe that smaller packet sizes reduce the packet error rate in the link layer, but it degrades effective bandwidth as more packets, packet overhead, and communication overhead need to be transmitted. 36

59 Table 3.2: Packet error rates evaluated against different FEC schemes, link layer packet sizes, and P bb, given that P gb = and the initial channel state is Good Packet FEC P bb Size Level (15,10) 3.25% 9.42% 15.44% 21.47% 28.61% 100bytes (7,4) 3.39% 10.24% 16.92% 23.45% 30.18% None 32.92% 32.93% 32.94% 32.98% 33.23% (15,10) 7.40% 20.48% 31.84% 42.00% 51.16% 200bytes (7,4) 6.76% 19.39% 30.79% 41.28% 50.91% None 55.09% 55.10% 55.11% 55.13% 55.29% (15,10) 16.86% 42.59% 60.57% 73.33% 82.68% 500bytes (7,4) 16.09% 41.90% 60.51% 73.76% 83.15% None 86.49% 86.49% 86.49% 86.50% 86.55% Proposed Approach - Interleaved FEC (I-FEC) FEC coding has been well studied [BA01, BFT99, Fro01], and it is the preferred error-control scheme to fight random losses, even though perfect recovery cannot be guaranteed. The main drawback of FEC technique is the overhead incurred due to the redundancy information. Although the extra overhead of FEC decreases the maximum achievable throughput, its ability to correct minor data losses makes FEC a desirable link layer coding scheme in error-prone environments, such as in the wireless medium. Bluetooth s link layer implements both DH and DM connection modes, differing in their usage of FEC coding. In DH mode, Bluetooth sends packets without 37

60 FEC coding in order to maximize the achievable throughput; whereas in DM mode, it uses a (15, 10) shortened Hamming code to protect the packets from transmission errors. In DM mode, each block of 10 information bits is encoded into a 15 bit codeword, and it is capable of correcting single bit error in each block. Analysis has shown that the deployment of FEC coding in DM mode enhances the transmission performance when the bit error rate surpasses a certain threshold [CKS04, JPH02]. However, the majority of the existing FEC implementations, including DM mode in Bluetooth, operate on a continuous block basis; thus, it only performs well when the number of errors are small, the amount of burst errors are rare, and the occurrences of errors are independent to each other. But those assumptions are not valid for the wireless environment, because once the wireless channel turns bad, the errors will happen in bursts and becomes dependent on each other, as reflected by the Gilbert-Elliott model in the previous section. Interleaving is the preferred solution to alleviate the effects of burst errors and has been popularly employed in end-to-end multimedia applications [CC01, CZ03, TZ99]. A sender interleaves the data packets before sending them out, and the receiver reconstructs the data packets after a certain amount of latency. Latency is determined by the level of interleaving, since reconstructing interleaved data packets would require the correct delivery of all packets involved in the interleaving. I-FEC joins together the strengths of both the FEC and interleaving techniques. It aims to incorporate the robustness of FEC against random errors, as well as the interleaving s ability, to alleviate the effects of burst errors. We took advantage of the built-in FEC support in Bluetooth technology, and applied I-FEC to its link layer. Since Bluetooth is a popular personal area network 38

61 Figure 3.16: (a) original FEC coding in Bluetooth DM mode; (b) I-FEC coding technology suffering from constant interferences from other radio based network equipment, I-FEC is expected to alleviate the packet loss rate of Bluetooth networks and improve effective bandwidth. In Bluetooth DM mode, a packet of size n bits is divided into several n/15 bits blocks. Each block is a FEC codeword consisting 10 data bits and 5 redundancy bits. Unsurprisingly, FEC codeword used in DM mode remains vulnerable to burst errors because consecutive bits are still continuous in a FEC codeword. Instead of using the same design approach as the Bluetooth DM mode, I-FEC divides each packet into 15 blocks with n/15 bits each. It then constructs the first 15-bit codeword by applying FEC to the first bit of each block. The second 15-bit codeword is constructed by applying FEC to the second bit of each block, and so on and so forth. Therefore, each codeword inherits the ability to correct single bit error like it was in the DM mode without having any continuous consecutive bits. The difference between I-FEC and Bluetooth DM mode is illustrated in Fig

62 3.3.3 Analysis Since I-FEC uses the same (15, 10) Hamming code for FEC coding as Bluetooth DM mode, the overhead used by I-FEC is the exact same amount used in the original DM mode, which implies that I-FEC will have the same maximum throughput as DM mode in a perfect wireless channel. Moreover, I-FEC resolves the latency problem associated with interleaving by applying bit level interleaving instead of packet level interleaving. The latency from interleaving becomes negligible since data is interleaved within a single link layer packet instead of being interleaved across different packets. As a result, I-FEC inherits both the robustness of FEC coding against random errors, and the survivability of interleaving against burst errors. For instance, suppose bit sequence number one of the data packet is corrupted in Fig. 3.15; both FEC and I-FEC coding schemes are capable of correcting that error. However, when burst error corrupts the first two bits of the data packet, the original FEC scheme will fail to recover the intended data; whereas I-FEC can successfully recover the original packet by distributing contiguous bit errors to different FEC codewords. In Fig and 3.18, we capture the retransmission rate of 1) I-FEC, 2) The original FEC scheme (DM5 mode), and 3) without any FEC support (DH5 mode) under various channel conditions. When the burst error rate is fixed at 0.2 (P bb = 0.2), Fig. 3.17shows that I-FEC consistently achieves a lower retransmission rate than FEC. It is also observed that FEC coded transmission is consistently better in retransmission rate compare to transmission without FEC coding scheme. In Fig. 3.18, with P gb fixed as , I-FEC again outperforms FEC by achieving a smaller retransmission rate. However, FEC coded transmission begin to perform as poorly as regular transmission when P bg decreases due to increasing degree of burst error 40

63 Figure 3.17: Retransmission Rates of different schemes evaluated at different P gb, given P bb = 0.2 Figure 3.18: Retransmission Rates of different schemes evaluated at different P bg, given P gb = (P bb = 1 P bg ). When P bb is greater than (P bg less than 0.001), it is observed that I-FEC results in a high retransmission rate as well. The reason behind the decrease in performance is the dramatic increase in length of burst errors when P bb increases. When P bb increases beyond 0.999, none of the available schemes can really make a difference in the retransmission rate. The relationship between 41

64 Figure 3.19: The accumulative ratio of burst length under different wireless channel conditions given P gb = ; (a) P bb = 0.99 (b) P bb = the length of burst length and P bb is depicted in Fig Simulation In this section, we present simulation results, using NS-2 [NS2] demonstrating the performance improvement by applying I-FEC to Bluetooth s link layer. The Bluetooth topologies used for the simulations are shown in Fig Black circles are the master nodes, while white circles represent the slave (or gateway slave) nodes. Each simulation ran for 600 seconds. We used 5 time-slots packet in Bluetooth link layer, which means for transmission without using a FEC scheme, 42

65 Figure 3.20: (a) 1 hop (b) 2 hop (c) 4 hop situation the DH5 packet type is chosen; whereas for the built-in FEC scheme, the DM5 mode is chosen. I-FEC is also designed as a 5 time-slots packet type, but it interleaves the FEC coded transmission from the DM5 mode. We evaluated the performance of these three schemes at different error rates, different degrees of burst error conditions, and different number of hops. Note that in the 2-hop case, the capacity of the master (black node) will be shared between the two slaves. Thus, the maximum throughput in is just half of the maximum throughput of the 1-hop case. For the 4-hop case, the maximum throughput is the same as that of the 2-hop case TCP with different P gb TCP NewReno was used for the first set of simulation, and Fig illustrates the performance of TCP NewReno evaluated under different link layer schemes, number of connections, and P gb probabilities. Size of the TCP packet was set at 500 bytes, and the buffer size on each Bluetooth node was 9000 bytes. The channel condition of every hop is configured the same for every run, P bb is always fixed as 0.2 and P gb varies from to for each series of experiment. The simulation result shows that TCP throughput decreases considerably when P gb increases for FEC coded transmission (DM mode) and regular transmission (DH mode). On the other hand, I-FEC was able to maintain a very 43

66 consistent throughput regardless of the changes in P gb. The improvement on throughput becomes even more obvious whenever the error rate increases or when the hop number increases. Transmission without any coding scheme does outperform FEC and I-FEC coded transmission when the error rate is very small, this is due to the redundant error-correction code carried by FEC and I-FEC TCP with different P bb The second simulation is to compare the performance of TCP NewReno under different link layer schemes, number of connections, and varying burst error probabilities. The TCP connection and the Bluetooth configuration is the same as the previous section, except P gb is now fixed at and P bb varies from 0 to for each series of experiment. From Fig. 3.22, I-FEC clearly outperforms the FEC coded transmission and regular transmission in most of the test cases regardless of the degree of burst error P bb (P bb = 1 P bg ). The throughput performance of FEC coded transmission decreases dramatically when P bb increases. This is due to the fact the FEC coding is designed to work on consecutive bits, which is proven to be quite vulnerable to burst errors. It is also observed that regular transmission actually performs well under the 1-hop scenario when P bb is large, because the high error rate and the extra redundancy packets depreciate the FEC and I-FEC coding schemes. Nonetheless, this is a tradeoff in link later design, and it is possible to make the coding scheme adaptive to optimize the overall throughput performance Conclusions We propose Interleaved Forward Error Correction (I-FEC), a hybrid approach incorporating the robustness of FEC coding to random errors and the survivabil- 44

67 Figure 3.21: TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections under Burst Error channel with P bb = 0.2. ity of interleaving to burst errors We analyzed various link layer coding schemes under different wireless channel configurations, and observed the different level 45

68 Figure 3.22: TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections under Burst Error channel with P gb = of protection (retransmission rate) provided by each scheme. We also simulated I-FEC in Bluetooth, and evaluated its performance against the FEC scheme in 46

69 Bluetooth, and observed that I-FEC displayed significant improvement in terms of TCP throughput in the presence of random wireless burst errors, especially when the degree of burst error is high. Additionally, the bit-level interleaving approach was effective in eliminate the latency usually associated with packet level interleaving. Therefore, we have demonstrated that I-FEC has much to contribute in providing higher performance and more reliable services in the wireless environment. 47

70 CHAPTER 4 Seamless Mobility Support for WPAN As the demand of mobility increases, it has been becoming more important for mobile users to be always best connected (ABC) [Mor03] even when they are moving. For instance consider the scenario, as shown in Fig. 4.1, where a user is in the midst of monitoring her biological experiment through a multimedia streaming broadcast, on a PDA device, via an b wireless connection in her office. Concurrently, she is informed of an urgent request for her immediate presence from her collaborators 20 miles away. While she cannot afford to miss neither the streaming multimedia nor her meeting with her collaborators, an ideal mobile computing solution would allow her to leave her office with her PDA (departing from the existing b high-capacity connection, i.e. building A), take an express shuttle to her collaborator s location (during which time continuing her monitoring via a lower-capacity 1xRTT connection with the multimedia rate and quality adapted to the changed capacity, i.e. area C), and arrive at her collaborator s office (entering another b network and receiving multimedia of higher quality again, i.e. building B). It is obvious that a complete PAN solution must support mobility for end users of PAN. More specifically, the solution needs to provide continuous connectivity even when the mobile is moving. The maintained connectivity could be provided by one or more network interfaces (technologies). However, when multiple network interfaces are used, the switch of network interfaces (i.e. vertical 48

71 Figure 4.1: Mobile computing scenario handoff) must be seamless and transparent to the mobile user. By seamless, we mean the switch must be with low latency and fewer packet losses; whereas by transparent, we mean the end user must be unaware of the occurrences of such switch. In this chapter, we present the proposed seamless handoff solution, called Universal Seamless Handoff Architecture (USHA). USHA is simple and with minimal changes to the current Internet infrastructure. Therefore, it is feasible to be real deployed. Based on USHA, we study TCP and video streaming (using VTP [BGS04]) in vertical handoff scenarios. In addition, we present a Smart Decision Model for USHA to decide the best network interface at any moment. Given the Smart Decision Model, the mobile applications are able to automatically trigger a vertical handoff. Thus, the transparency of mobility support could be achieved. 49

72 4.1 Overview of Seamless Handoff Handoff occurs when the user switches between different network access points. Handoff techniques have been well studied and deployed in the domain of cellular system and are gaining a great deal of momentum in the wireless computer networks, as IP-based wireless networking increases in popularity. Differing in the number of network interfaces involved during the process, handoff can be characterized into either vertical or horizontal [SK98], as depicted in Fig A vertical handoff involves two different network interfaces, which usually represent different technologies. For example, when a mobile device moves out of an b network and into a 1xRTT network, the handoff event would be considered as vertical. A horizontal handoff occurs between two network access points that use the same technology and interface. For example, when a mobile device moves between b network domains, the handoff event would be considered as horizontal since the connection is disrupted solely by the change of b domain but not of the wireless technology. Figure 4.2: Horizontal and Vertical Handoff A seamless handoff is defined as a handoff scheme that maintains the connectivity of all applications on the mobile device when the handoff occurs. Seamless 50

73 handoffs aim to provide continuous end-to-end data service in the face of any link outages or handoff events. Low latencies and few packet losses are the two critical design goals. Low latencies require that path switches be completed almost instantaneously; service interruptions should be minimized. In case of an actual connection failure, the architecture should attempt to reconnect as soon as the service becomes available; packet losses due to the switch should also be minimized. Various seamless handoff techniques [Dom02, HZS03, JPA02, Mal01] have been proposed. These proposals can be classified into two categories: network layer approaches and upper layer approaches. Network layer approaches are typically based on IPv6 [DH98] or Mobile IPv4 [Per02] standards, requiring the deployment of several agents on the Internet for relaying and/or redirecting the data to the moving host (MH). Most upper layer approaches implement a session layer above the transport layer to make connection changes at underlying layers transparent to the application layer [GPR04, HSS99, MB98, SRB01, Sno02]. Other upper layer approaches suggest new transport layer protocols such as SCTP [SXM00] and TCP-MH [MKF03] to provide the necessary handoff support. Previous seamless handoff solutions, whether mobile IP based or mobile IPless, are often elaborate to implement and to operate. For the network layer solutions, deployment translates to upgrading every existing router without mobile IP capabilities. The cost imposed by these solutions is an existing barrier to wide deployment. For the upper layer solutions, a new session layer or transport protocol calls for an update to all existing applications and servers not supporting it, the potential cost is also discouraging. Consequently, even though many handoff solutions have managed to minimize both latency and packet loss, they are often not deployed in reality by the majority of service providers. With 51

74 the proliferation of mobile applications and mobile users, a simple and practical seamless handoff solution with minimal changes to the current Internet infrastructure remains necessary. USHA, an upper layer solution providing simple and practical handoff solution, is deployed in our experiments to handle seamless vertical handoffs. Details of USHA will be presented in next section. 4.2 USHA: Universal Seamless Handoff Architecture A Universal Seamless Handoff Architecture (USHA) was proposed in [CSC04b] to deal with both horizontal and vertical handoff scenarios with minimal changes in infrastructure (i.e. USHA only requires deployment of handoff servers on the Internet.) USHA is a mobile IP-less solution; however, instead of introducing a new session layer or a new transport protocol, it achieves seamless handoff by following the middleware design philosophy [FGC97], integrating the middleware with existing Internet services and applications. USHA is based on the fundamental assumption that handoff, either vertical or horizontal, only occurs on overlaid networks with multiple Internet access methods (e.g. soft handoff), which translates to zero waiting time in bringing up the target network interface when the handoff event occurs. If coverage from different access methods fails to overlap (e.g. hard handoff), it is possible for USHA to lose connectivity to the upper layer applications. In Fig. 4.3, a handoff server (HS) and several mobile hosts (MHs) are shown. USHA is implemented using IP tunneling techniques (IP encapsulation), with the handoff server functioning as one end of the tunnel and the mobile host as the other. An IP tunnel is maintained between every MH and the HS such that all 52

75 Figure 4.3: Diagram of Universal Seamless Handoff Architecture application layer communications are bound to the tunnel interface instead of any actual physical interfaces. All data packets communicated through this IP tunnel are encapsulated and transmitted using the connectionless UDP protocol. The IP tunnel above utilizes two pairs of virtual/fixed IP addresses, one on HS and one on MH. The fixed IP addresses are necessary for an MH to establish a physical connection to the HS. When the handoff event occurs and the physical connection from MH to HS changes, the MH is responsible for automatically switching the underlying physical connection of the virtual tunnel to the new interface, as well as notifying the HS of its change in physical connection. Upon handoff notification, the HS immediately updates its IP tunnel settings so that any subsequent data packets will be delivered to MH s new physical link. Since all data packets are encapsulated and transmitted using UDP, there is no need to reset the tunnel after the handoff. Therefore, end-to-end application sessions (e.g. TCP) that are bound to the IP tunnel are kept intact. This provides handoff transparency to upper layer applications. 53

76 4.2.1 USHA Experiments In this section, we present USHA measurements in two vertical handoff scenarios. In subsection , we first evaluate the indoor-mobility scenario, which is common for mobile users performing handoffs between 100Mbps Ethernet (e.g. his/her working cubicle) and b (e.g. conference room) network interfaces. In subsection , we evaluate USHA in the outdoor-mobility scenario, where the mobile user performs vertical handoffs between different wireless technologies (e.g b in the cafe and 1xRTT on the freeway) Vertical Handoff between Ethernet and b Fig. 4.4 illustrates the indoor-mobility scenario, where the mobile user performed a vertical handoff between Ethernet (100Mbps link capacity) and b (11Mbps mode 1 ). A FTP (TCP based) download session was initiated at the beginning of each experiment and stopped after two minutes. The vertical handoff was manually triggered after the first second. The detail configuration of the experiment scenario, including link capacity (measured by CapProbe [KCL04]) and round-trip delay (of 1500 bytes packet size), are also shown in Fig Handoff From b to Ethernet Fig. 4.5 and 4.6 shows the instantaneous FTP (TCP) throughput and packet sequence number during a vertical handoff (which is occurred at around 60th second) from b to Ethernet, i.e. from 11Mbps capacity link to 100Mbps link. The TCP throughput increased from 4Mbps (before the handoff) to around 35Mbps (after the handoff), and the packet sequence number increased without any additional latency due to the handoff. From 1 The effective capacity of 11Mbps transmission rate mode is around 5 6 Mbps. [KCL04] 54

77 Figure 4.4: Testbed configuration of the vertical handoff experiment between Ethernet and b. the results, it s clear that USHA can truly achieve seamless vertical handoffs. 2. Handoff From Ethernet to b In addition to the handoff from LOW to HIGH capacity link, we also evaluated FTP downloading during a vertical handoff from Ethernet to b link, i.e. from 100Mbps to 11Mbps capacity link. Fig. 4.7 and 4.8 show the instantaneous throughput and the corresponding packet sequence numbers. Here, there is a non-negligible latency of around 5 seconds during the vertical handoff. This is due the fact that TCP suffers multiple packet losses caused by the drastic reduction in link capacity. When multiple packets are dropped, TCP reduces its congestion window and probes the new available bandwidth with its Slow Start mechanism. As identified by [GK04], such latency could not be alleviated unless early explicit handoff notification were provided. 55

78 Figure 4.5: Instantaneous throughout results of one TCP flow during a vertical handoff from b (11Mbps) to Ethernet (100Mbps). Figure 4.6: Sequence number of one TCP flow during a vertical handoff from b (11Mbps) to Ethernet (100Mbps) Vertical Handoff between 1xRTT and b The second vertical handoff scenario is the outdoor-mobility scenario, where the mobile users perform vertical handoffs between wireless technologies that are designed to support greater user mobility. For simplicity, we decide to use two popular wireless technologies, namely 1xRTT and b in our experiments. 56

79 Figure 4.7: Instantaneous throughout results of one TCP flow during a vertical handoff from Ethernet (100Mbps) to b (11Mbps). Figure 4.8: Sequence number of one TCP flow during a vertical handoff from Ethernet (100Mbps) to b (11Mbps). While 1xRTT provides greater coverage, b is able to achieve higher data throughput. The testbed configuration is similar to Fig. 4.4, except here we replace Ethernet link with 1xRTT link, and use 5.5Mbps transmission mode for the b 57

80 link 2. The 1xRTT link is with around 150Kbps link capacity 3 and 350 ms roundtrip delay. A single FTP download session is initiated from the MH to the FTP server, and the vertical handoff is manually triggered after the first minute. 1. Handoff From 1xRTT to b Fig. 4.9 and 4.10 shows the instantaneous FTP (TCP) throughput and packet sequence number during the vertical handoff process (which occurred around 60th second) from 1xRTT to b. The TCP throughput increased from 80Kbps to around 3Mbps after the handoff, and the packet sequence number kept on increasing without additional latency. The results further proves that USHA can provide continuous connectivity for various vertical handoff scenarios 2. Handoff From b to 1xRTT Fig and 4.12 show another measurement results, where the vertical handoff is from b to 1xRTT. Similar to the results of the handoff from b to Ethernet, there is a non-negligible latency of roughly 2 seconds during the vertical handoff. Again, such latency is due to the drastic capacity reduction, because TCP needed time to recover from multiple packet losses Choosing the Best Handoff Server To deploy an USHA system in the real world, a MH requires registration with at least one HS, allowing the HS to manage an IP tunnel from itself to the MH. In the case where there are multiple HS available, it is necessary for a MH to 2 The effective capacity of 5.5Mbps transmission rate mode is around 3 4 Mbps. 3 The ISP claims 150Kbps link capacity, but CapProbe [KCL04] only measures around 90Kbps capacity. 58

81 Figure 4.9: Instantaneous throughout results of one TCP flow during a vertical handoff from 1xRTT (150Kbps) to b (5.5Mbps). Figure 4.10: Sequence number of one TCP flow during a vertical handoff from 1xRTT (150Kbps) to b (5.5Mbps). determine the best HS to register to. The decision process can be modelled as follows. First of all, the MH should collect a set of candidate HS in accordance to 59

82 Figure 4.11: Instantaneous throughout results of one TCP flow during a vertical handoff from b (5.5Mbps) to 1xRTT (150Kbps). Figure 4.12: Sequence number of one TCP flow during a vertical handoff from b (5.5Mbps) to 1xRTT (150Kbps). some pre-defined policy and cost. For instance, the MH should filter out the HSs that are not accessible to the MH s network interfaces(i.e. behind the firewall). Secondly, the MH should select the HS with tolerable delay and highest ca- 60

83 pacity, as the best HS. Specifically, suppose there are k network interfaces on the mobile host, and there are n candidate HS. D i,j and C i,j denote the round-trip delay and link capacity of the ith network interface to the jth HS. D thresh is the maximum tolerable delay for the mobile user. Suppose the rth HS is the best HS for the mobile, the following two equations should be satisfied. max D i,r D thresh (4.1) i=1...k min C i,r min C i,j ; j = 1...n (4.2) i=1...k i=1...k Smart Decision Model Though USHA provides a simple and practical seamless handoff solution, it still has difficulty in performing handoff smartly, i.e. the handoff cannot be triggered automatically so far. It turns out that a manual handoff solution is still far from becoming practical, since an appreciable solution should keep mobility transparent to the mobile users, i.e. the seamless handoff solution should be smart enough so that it is able to perform a handoff properly at the proper moment. In this section, we present the proposed Smart Decision Model to support flexible configuration in executing vertical handoffs. Fig depicts the proposed Smart Decision Model. In this figure, a Handoff Control Center (HCC) provides the connection between the network interfaces and the upper layer applications. HCC is composed of four components: Device Monitor (DM), System Monitor (SM), Smart Decision (SD), and Handoff Executor (HE). DM is responsible for monitoring and reporting the status of each network interface (i.e. the signal strength, link capacity and power consumption of each interface). SM 61

84 Figure 4.13: Diagram of Smart Decision Model monitors and reports system information (e.g. current remaining battery). SD integrates user preferences (obtained from user set default values) and all other available information provided by DM, SM to achieve a Smart Decision, to identify the best network interface to use at that moment. HE then performs the device handoff if the current network interface is different from the best network interface. A Handoff Control Center (HCC) in accordance to above has been implemented on our vertical handoff testbed to perform automatic handoffs to the best network interface. In our design, there are two phases in SD: the priority phase and the normal phase. The SD algorithm is described in Fig Priority and normal phases are necessary in SD to accommodate user-specific preferences regarding the usage of network interfaces. For instance a user may decide not use a device when the device may cause undesirable interferences to other devices (e.g b and 2.4GHz cordless phones). With priority and normal phases in place, the SD module provides flexibility in controlling the desired network interface to the user. Additionally, SD deploys a score function to calculate a score for every wireless interface; the handoff target device is the 62

85 Figure 4.14: Algorithm for making Smart Decisions on HCC network interface with the highest score. More specifically, suppose there are k factors to consider in calculating the score, the final score of interface i will be a sum of k weighted functions. The score function used is the following: S i = k k w j f j,i 0 < S i < 1, w j = 1 (4.3) j=1 j=1 In the equation, w j stands for the weight of factor k, and f j, i represents the normalized score of interface i of factor j. The best target connection interface at any given moment is then derived as the one which achieves the highest score among all candidate interfaces. We further break down the score function to three components where each accounts for usage expense (E), link capacity (C), and power consumption (P ), respectively. Therefore Eq. 4.3 becomes: 63

86 S i = w e f e,i + w c f c,i + w p f p,i (4.4) Additionally, there is a corresponding function for each term f e,i, f c,i, and f p,i, and the ranges of the functions are bounded from 0 to 1. The functions are illustrated below: f e,i = 1 e α i f c,i = eβ i e M f p,i = 1 e γ i (4.5) where α i 0, M β i 0, and γ i 0. The coefficients α i, β i, γ i can be obtained via a lookup table or a well-tuned function. In Eq. 4.5, we used the inversed exponential equation for f e,i and f p,i to bound the result to between zero and one (i.e. these functions are normalized), and properly model users preferences. For f c,i, a new term M is introduced as the denominator to normalize the function, where M is the maximum bandwidth requirement demanded by the user. Without specified by the user, the default value of M is defined as the maximum link capacity among all available interfaces. Note that, the properties of bandwidth and usage cost/power consumption are opposite (i.e. the more bandwidth the better, whereas lower cost/power consumption is preferred) Testbed Experiments A Smart Decision Model implementation is employed on the top of USHA vertical handoff testbed, and a set of experiments has been performed to evaluate this model. Our Smart Decision Model implementation worked well in all the testing scenarios. To clearly demonstrate how this model works, we show a detailed example in the followings. 64

87 Figure 4.15: An coefficient function example An example of how these coefficients in Smart Decision Model work with user defined functions is illustrated in Fig. 4.15, where x i is the usage cost (ISP charge), y i is the measured link capacity, and z i is the power consumption of the i-th wireless interface. In a sense, these functions are simply transformation from a specific domain (e.g. cents/min, kbps, and hours) to a universal unit domain, and the return values are normalized as a positive real number between 0 and 1. On top of that, the user can also decide what she values the most by giving weight w j to j-th function. The following illustrates an example of how Smart Decision is achieved. Suppose a mobile user who is currently using the 1xRTT device enters a caf. The HCC immediately discovers an b access point inside the caf and does the following comparisons: The 1xRTT cost is less than 1 cent/min because the user has already subscribed to the service using monthly unlimited plan ($80 / month), while b inside the caf costs 10 cents/min. The link capacity information is gathered from CapProbe [KCL04], a newly invented capacity estimation tool, which reports that 1xRTT has a capacity of 100Kbps and the b wireless LAN has a capacity around 5Mbps. With the current battery status, the user can either continue his 1xRTT connection for 4 hours or 2 hours with b connection. At this time, the mobile user decides that he will stay in the caf for a while, so he gives more weight to power consumption (w p =0.4), and equal weight to usage cost and bandwidth requirement (w e = 0.3, w c = 0.3). The HCC then 65

88 computes the score according to Eq. 4.4 and Eq. 4.5 using coefficient functions illustrated in Fig Eq. 4.6 and 4.7 show the calculation of the score results of both 1xRTT and b interfaces, where S 1xRT T = 0.83 and S b = Since S 1xRT T > S b, the HCC therefore decides to continue using 1xRTT interface instead of switching to the faster b interface. S 1xRT T = e α e β γ = e o e100kbps/2mbps e 2/ (4.6) S 1xRT T = e α e β γ = e /20 emin(2,5)mbps/2mbps 0.44 e 2/2 (4.7) Note that, though the example shown in this section uses the coefficient functions defined in Fig. 4.15, these coefficients are changeable upon users needs and preferences. These coefficients can be obtained via a lookup table or a well-tuned function; however, they need to be normalized so that the score function (Eq. 4.3) can reasonably decide the score for each network interface from different factors Other Extensions In addition the support of continuous connectivity, USHA could be easily extended by inserting additional plug-ins. For instance, the HS can be extended by incorporating the transcoding functionalities. More specifically, when the avail- 66

89 able bandwidth 4 of the access link (i.e. from HS to MH) is lower than the required bit rate required by applications (e.g. video streaming application), it would be of great help if HS could transcode application data to a lower bit rate. Resulting in better utilization of available network resources to provide best possible services. Additionally, since data packets are all encapsulated and transmitted via UDP between HS and MH, one can enhance the connection security by encrypting the encapsulated UDP packets (e.g. using IPsec [IPs]) and improve the end-to-end data goodput by compressing all UDP packets through the IP tunnel in real-time (e.g. using LZO algorithm [LZO]). A more detailed account management and access control schemes are also possible with USHA, since both functionalities can be easily handled and deployed on the HS. 4.3 A Case Study of Video Streaming in Vertical Handoffs Video streaming has become a popular form of transferring video over the Internet. With the emergence of mobile computing needs, a successful video streaming solution demands 1) uninterrupted services even with the presence of mobility and 2) adaptive video delivery according to current link properties. In this section, we study the need and evaluate the performance of adaptive video streaming in vertical handoff scenarios. We created a simple handoff environment with Universal Seamless Handoff Architecture (USHA), and used Video Transfer Protocol (VTP) [BGS04] to adapt video streaming rates according to the Eligible Rate Estimates. Using testbed measurements experiments, we verify the importance of service adaptation, as well as show the improvement of user-perceived video 4 For instance, Spruce [SKK03] can be employed to quickly estimate the available bandwidth of a given path. 67

90 quality, via adapting video streaming in the vertical handoffs VTP Overview Bandwidth Estimation VTP is a video streaming protocol aiming to adapt its rate and quality according to network conditions. The core of VTP is its bandwidth estimation technique. It estimates the Eligible Rate Estimate (ERE) by applying an Exponentially Weighted Moving Average (EWMA) to the achieved rate, which is in turn calculated as the number of bytes delivered to the client during a certain time interval, divided by the length of the interval. Assume we use packet trains of length k to measure the achieved rate. Denote d i as the number of bytes in packet i, t i as the time when packet i arrives at the client. The sample of achieved rate measured when packet j is received, denoted as b j, is b j = k 1 l=0 d j l t j t j (k 1) (4.8) The EWMA is needed to smooth achieved rate samples and eliminate random noise. Denote B i as the available bandwidth estimate after getting sample b j, then B j = α B j 1 (1 α)( b j + b j 1 ) (4.9) 2 The reason of using both b j and b j 1 is to further reduce the impact of randomness in the achieved rate samples. 68

91 Rate Adaptation Current VTP implementation works with pre-stored streams but can be extended to live video. Multiple streams of the same content are encoded discretely at different rates. Compression algorithms such as MPEG-4 [MPE] can adjust parameters, such as the Quantization Parameter (QP), to achieve different encoding rates. For example, a movie trailer may be encoded at 56Kbps, 150Kbps and 500Kbps, targeting users with different access capacities. VTP chooses from multiple encoding levels of the same content the best rate according to ERE. Figure 4.16 illustrates with a finite state machine how rate adaptation is performed in VTP. Three video encoding levels, namely Q0, Q1 and Q2 with ascending rates, are shown. IR0 through IR2 are the increasing rate states while DR is the decreasing rate state. Figure 4.16: Rate adaptation in VTP VTP starts from state Q0. Upon receiving an ACK from the client, VTP server compares its current sending rate with the recently updated bandwidth estimate B. If the sending rate is less than or equal to B, VTP regards it as an indication of good network condition and makes a transition to IR0, where VTP linearly increases its sending rate to probe the available bandwidth. The amount 69

92 of rate increase is limited to 1 packet/rtt, same as in TCP. On exiting IR0, VTP may move to state Q1 when the rate is high enough to support the level 1 stream, i.e. quality upgrade; or return to Q0 otherwise. Thus Q0 only implies the server is sending the level 0 stream; it says nothing about the actual sending rate. This process repeats itself, with possible quality upgrades, until the bandwidth estimate drops below current sending rate. Rate decrease happens immediately when the measured bandwidth estimate drops below the sending rate. A transition from the current encoding level, say Q2, to DR is made. In DR, sending rate is decreased to the bandwidth estimate. If this rate is no longer able to support the current encoding level (level 2 in this example), one or more level decreases, i.e. quality downgrade, will occur until the level that the new sending rate can support. If the sending rate is below Q0, the lowest level, the streaming service will either be stopped or send at this lowest level, depending on administration policies Transmission Scheduling for VBR Video Constant Bit Rate (CBR) video continuously adjusts QPs to maintain the target bit rate of the stream. This simplifies transmission scheduling, but results in varying video quality from frame to frame, which is unpleasant to the viewer. On the other hand, Variable Bit Rate (VBR) video produces streams with varying bit rates; and with more consistent quality. Due to space limit we will not cover VTP transmission scheduling in detail in this paper. Briefly speaking, VTP divides a video clip into a number of segments. For each segment, VTP computes a target rate, at which neither buffer overrun or underrun should occur. Since video streams are pre-stored, instantaneous sending rates are available beforehand, and so are the target rates of the segments. VTP 70

93 then applies these target rates to the finite state machine in Figure 4.16 for rate adaptation. In the next section we will evaluate the performance of adaptive video streaming in seamless handoff scenarios of our integrated USHA + VTP testbed Experiments In this section, we present measurement results of adaptive video streaming in vertical handoff scenarios using a 2-minute movie trailer encoded in MPEG-4 at three discrete levels. We denote them as levels 0, 1 and 2, corresponding to the encoding rates (VBR) of below 100, , and above 250 Kbps, respectively. The VTP server is implemented on a stationary Linux desktop; the client is on a mobile Linux laptop. The USHA system is also set up in Linux, with custom configured NAT and IP tunneling. Both the VTP server and client are connected to the handoff server, the former via 100 Mbps Ethernet; the later via b and 1xRTT provided by Verizon Wireless. The b is set at the 11 Mbps mode; the bandwidth of 1xRTT varies with cross traffic, the typical value is around tens of Kbps. We have tested two handoff scenarios, from 1xRTT to b (low capacity to high) and vice versa. In all experiments, one-time handoff occurs at 60 sec after the start of the experiment. In each scenario, we have tested both non-adaptive and adaptive video streams. In the non-adaptive case, video of fixed quality is sent throughout the experiment regardless of ERE, while in the adaptive case the video quality adapts accordingly. 71

94 Handoff from 1xRTT to b In the first set of experiments, we evaluate the performance of video streaming when the mobile host performs handoff from the lower-capacity interface of 1xRTT to the higher-capacity interface of b. 1. Non-adaptive Video Streaming First, we run non-adaptive experiments one for each encoding level. Since the coding rates of levels 1 and 2 are both above the capacity of 1xRTT, the corresponding experiments died shortly after started simply because of the inability of 1xRTT to handle such high rates. Results are not reported. Only video of level 0 made it through as the results show below. More specifically, Fig shows the frame rate received by the mobile client, and Fig shows the sending rate at the VTP server. In Fig. 4.18, Reference Rate means the source rate of the video stream (note that the source rate is variable, even within a given encoding scheme), whereas the Sending Rate means the instantaneous transmission rate of the data, which depends on the link capacity and thus may exceed the source rate. In Fig. 4.17, the video frame rate is stable and consistently between a visually pleasing range of 20 and 25 frames/sec (fps) shortly after it is started. Even in the presence of a handoff from LOW to HIGH at 60 sec, the frame rate remains unaffected. This proves our USHA to be transparent to applications. The video quality is overall very good in terms of smoothness. However, Fig reveals more insightful information. In this non-adaptive experiment, the reference rate and video quality remain low after the handoff at 60 sec, where they could increase to take the advantage of the increased sending rate and bandwidth. This justifies the 72

95 Figure 4.17: Frame Rate received at the Mobile Host Figure 4.18: Sending Rate at the Video Server 73

96 exploration of adaptation in video streaming applications. Note that after the handoff, the actual sending rate is much higher than the reference rate, so the server finishes sending quickly (before 80 sec). 2. Adaptive Video Streaming The setup of adaptive streaming experiment is similar to the non-adaptive one described above except that now the video quality level adapts to the network conditions. In Fig. 4.19, we show the frame rate received by the mobile client. Still it is stable and consistently in a range that gives good perceived quality. No dips in frame rate are found when the handoff event occurs. Fig shows the quality level of the video sent by the VTP server (averaged over 1-sec intervals). Level 2 is highest and 0 is lowest. Prior to the handoff at 60 sec, most frames are sent at the lowest quality level (i.e. 0); after handoff the average quality jumps to about 1.5. This is consistent with our experiment setup where the available bandwidth increases drastically when moving from 1xRTT to b. Fig shows the reference and sending rates on the VTP server. Prior to the handoff at 60 sec, Figure 8 looks very similar to Fig The difference emerges after the handoff. The reference rate jumps up and strives to match the sending rate ( 300 Kbps), indicating that high quality video is now being transmitted across the b channel. In other words, VTP successfully detects (within fractions of a second) the change in available bandwidth and adapts its video encoding level to maximize the perceived quality of the mobile user. 74

97 Figure 4.19: Frame Rate received at the Mobile Host Figure 4.20: Video Quality sent at the Video Server Figure 4.21: Sending Rate at the Video Server 75

98 Handoff from b to 1xRTT In the second set of experiments, we evaluate the performance of video streaming when the mobile host performs handoff from the high-capacity interface of b to the low-capacity interface of 1xRTT. To make results comparable to the previous experiments, the one-time handoff is also generated 60 sec after the experiment is started. 1. Non-adaptive Video Streaming Similar to the experiments that we have done in the case where handoff occurs from 1xRTT to b, we have also tested non-adaptive streaming at all three quality levels, respectively. Unlike the previous experiments, this time handoff occurs from the high-capacity interface to the low-capacity one, thus all three levels are feasible initially and can be tested. As expected, after the handoff, experiments with levels 1 and 2 virtually died. We show the experiment results with level 2, i.e. the highest quality in Fig (video frame rate received by the mobile client) and Fig (sending rate on the VTP server). Before the handoff, the frame rate received by the client is high and stable, and the reference and sending rates at the server are both high and close to each other, an obvious sign of high quality video. These metrics drop sharply at 60 sec when the handoff occurs, the reason being that 1xRTT is not able to handle the video of highest quality as we have explained. The frame rate drops to an unacceptable level of 10 fps; the sending rate becomes less than half of the reference rate. In the experiment we have found that the video virtually froze after the handoff. This experiment confirms the claim that adaptive multilevel video codes are a must in heterogeneous roaming. 76

99 Figure 4.22: Frame Rate received at the Mobile Host Figure 4.23: Sending Rate at the Video Server 77

100 2. Adaptive Video Streaming Moving on to the adaptive video experiments, Fig shows the video frame rate received at the mobile client - high and stable as we have seen in Fig Note that there exists a small dip in the frame rate shortly after the handoff event at 60 sec, but the recovery is within a couple of seconds. This again proves the effectiveness of seamless handoff and rate adaptation of our proposed solution. Fig and Fig show the video quality level and the reference and sending rates at the VTP server. Prior to the handoff at 60 sec when the system is running over the b connection, video quality is high (i.e. 2), so is the reference rate, matching the sending rate. Exactly at 60 sec the system is able to detect the handoff event and to adapt the video quality to the reduced bandwidth. Throughout the experiment the sending rate is always ahead of the reference rate so that there is no backlog build up at the sender Discussion In a handoff-enabled environment, drastic changes in the link capacity are often associated with vertical handoff events. For instance, handoff from 1xRTT to b can easily witness a 100-fold increase in the link capacity (from 100 Kbps to 11 Mbps). Some traditional approaches (e.g. TFRC) incorporate the well-known slowly-responsive congestion control (SlowCC ) [BBF01] and thus can smoothly adjust the sending rate. However, SlowCC cannot take aggressive advantage of the rapid change of resources in emerging vertical handoff scenarios [GK04]. In order to utilize the bandwidth resources well, and maximize the user-perceived quality, a well-designed adaptive streaming scheme must take into 78

101 Figure 4.24: Frame Rate received at the Mobile Host Figure 4.25: Video Quality sent at the Video Server Figure 4.26: Sending Rate at the Video Server 79

102 account the effect of drastic capacity changes in both up and down directions. From the experiment results presented in sections and , it is evident that VTP is one such scheme. Using the eligible rate estimate, VTP can properly and rapidly adapt its sending rate and video quality to available bandwidth, and hence is successful in handling vertical handoffs. This is not small feat. In fact, in most AIMD-based streaming protocols inspired to TCP, the adaptation process adjusts slowly to capacity changes. For example, when handoff occurs from LOW to HIGH (i.e. 1xRTT to b), no congestion loss is detected. A TCP based scheme will remain in congestion avoidance and linearly increase its congestion window (and rate) to probe the available bandwidth. In the opposite direction, where handoff occurs from high (e.g b) to low capacity (e.g. 1xRTT), there is immediate packet loss at the moment of the handoff, so AIMD protocols will react promptly to such loss. In fact, they tend to overreact causing oscillatory behavior and slower convergence to the new (lower) encoding rate. In general, application performance would benefit if the server could predict the imminent handoff (e.g. MAC layer feedback from fading signals of one connection and strengthening signals of the other) and thus slow down its sending rate just before the handoff. We plan to address this issue in our future work. 80

103 CHAPTER 5 End-to-end Capacity Estimation in Wired and Wireless Networks Knowledge of fundamental network properties is important for network plan, design, manage, optimization and pricing, especially for emerging network technologies and applications, such as overlay, peer-to-peer (P2P), grid and mobile networks. Knowing link capacity is particularly desirable for numerous applications. For instance, capacity information can benefit P2P clients to avoid downloading files from poor peers (i.e. with poor link capacities). Moreover, knowing the link capacity can help overlay networks to efficiently structure overlay trees. The ideal capacity estimation tool must be end-to-end (i.e. without support from the intermediate hosts) and non-intrusive (i.e. low overhead to the networks). The algorithm of such tool had better be simple and fast, and the estimation results must be accurate. To fulfill these requirements, we study capacity estimation in wired and wireless networks based on CapProbe [KCL04], which is a simple, fast, accurate, end-to-end, and less intrusive technique. Moreover, we extend the CapProbe technique to function well in different network dynamics, such as asymmetric links and wireless networks. The design of network measurement tools could be one-way or round-trip. One-way techniques are able to measure network properties of asymmetric links, but they need to be installed and run on the two end hosts. Round-trip techniques 81

104 Table 5.1: Comparison of one-way and round-trip based approaches One-way approach Round-trip approach Pros Can be used to estimate forward/reverse No clock skew problem link Cons Need cooperation from the receiver Clock skew problem Usually cannot handle asymmetric links Pros Cons Table 5.2: Comparison of active and passive approaches Active approach Passive approach Usually faster and more accurate Much less intrusive No need to worry firewalls Estimate whenever you want Firewall may be a problem Cannot estimate unless foreground Intrusive traffic starts Hard to design do not have time synchronization problems, but they usually can not measure asymmetric links properly (one exception is AsymProbe [CSY05], which is able to measure link capacities of both directions in a round-trip manner). Table 5.1 details the pros and cons of one-way and round-trip designs. Additionally, the measurement tools could operate either actively or passively. In general, active methods are more controllable and thus result in better performance (in terms of speed and accuracy). However, active methods are usually intrusive and more likely to be blocked by the increasingly deployed firewalls. The pros and cons of active and passive approaches are described in Table

105 In this chapter, we focus on active measurements and target on scenarios of asymmetric links and wireless networks. We will move on passive measurements and applications in the next chapter. 5.1 Related Work Internet Capacity Estimation Previous research on capacity estimation relied on either delay variations among probe packets as illustrated in pathchar [Jac], or dispersion among probe packets as described in Nettimer [LB99] and Pathrate [DRM01]. Conceptually, Dovrolis analysis in [DRM01] clearly revealed that the dispersions distribution can indeed be multi-modal without multi-channels, and that the strongest mode in the multimodal distribution of the dispersion may correspond to either (1) the capacity of the path, or (2) a compressed dispersion, resulting in capacity over-estimation, or (3) the Average Dispersion Rate (ADR), which is lower than the capacity. Other tools such as pchar and clink [Dow99] use variations of the same idea as pathchar. Pchar employs regression techniques to determine the slope of the minimum RTT versus the probing packet size. However, Pathchar like tools have limitations with respect to the speed of estimation process as shown in [KCL04]. On the other hand, active probing techniques such as Pathrate induce out-of band traffic and are often considered as an intrusive technique particularly if many users simultaneously apply them. CapProbe [KCL04] is a recently proposed capacity estimation technique shown to be both fast and accurate over a large range of scenarios. Conceptually speaking, when a back-to-back packet pair is launched into a network, they are always dispersed at the bottleneck link according to the bottleneck capacity. If such 83

106 dispersion would arrive at a destination unperturbed, it will be ideal for identifying the bottleneck capacity (as shown in Fig. 5.1-c). The dispersion of those distorted samples might be either expanded or compressed, where expansion of dispersion leads to under-estimation and compression of dispersion leads to over-estimation of the capacity as shown in Fig. 5.1-a,b. Figure 5.1: (a) Under-Estimation caused by expansion (b) Over-Estimation caused by compression (c) the ideal case CapProbe combines the use of dispersion measurements and end-to-end delay measurements to filter out packet pair samples distorted by cross traffic. This means that whenever an incorrect value of capacity is estimated, the sum of the delays of the packet pair packets, called the delay sum, includes cross-traffic induced queuing delay. A delay sum, which does not include any cross-traffic queuing delay, is referred to as the minimum delay sum. The dispersion of such a packet pair sample is not distorted by cross-traffic and will reflect the correct capacity. This sample can easily be identified since its delay sum will be the minimum among delay sums of all packet pair samples. The capacity can be estimated by the equation: 84

107 C = P T (5.1) where P is the sampling packet size, and T is the dispersion of the sample packet pair of the minimum delay sum Capacity Estimation in Wireless Networks As presented above, the path capacity estimation problem has been extensively studied in the Internet. Various tools have been proposed to accurately estimate bottleneck link capacity in the wired and/or last-hop wireless networks [Dow99, DRM01, Jac, KCL04, LB99]. However, the complexity and convergence time required for these schemes are not well suited for ad hoc wireless networks. Moreover, the bidirectional set up of some of the above techniques proves to detrimental in ad hoc networks as discussed later. Several techniques exist for adhoc path capacity estimation, which are supported by specific routing algorithms. For example, on demand routing algorithms (e.g. AODV [BP03]) as well as proactive algorithms (e.g. LANMAR and Fisheye Routing [XHG02]) have been successfully extended to yield path capacity. These estimations however are dependent on specific routing schemes - they require feedback from the network layer. Li et al directly addressed the end to end estimation of path capacity of a static multihop network based on b. Their approach was to send a brute force UDP packet stream and measure the maximum achievable data throughput [LBC01]. This scheme is very realistic in that it reflects the currently available capacity if a UDP stream is injected. However, as discussed later it is not very practical due to impact on ongoing traffic. Moreover, the capacity measurement is 85

108 affected by current cross traffic conditions. In the experimental results presented in [LBC01], this approach was only able to obtain a substantially lower utilization of 1/7 of effective capacity. 5.2 Measuring Asymmetric Path Capacity Existing round-trip capacity estimation tools, including the ones discussed above, estimate the narrowest capacity of any link. These existing techniques encounter severe constraints when measuring the respective link capacities of the increasingly popular asymmetric links (e.g. DSL, cable modem, and satellite links, where the forward link capacity is different than the backward link capacity). In this subsection, we present AsymProbe to measure asymmetric link capacities in the round trip fashion. The details of this approach will be presented in the following sections, and evaluation of AsymProbe will be discussed in the simulation and experiments sections AsymProbe In this section, we present AsymProbe, a novel capacity measuring technique that allows to measures the capacity of either the forward or backward narrow link on the path. The basic idea of AsymProbe stems from the observation that the measured dispersion in the original CapProbe can be introduced either in the forward or backward direction of an asymmetric link. When probing and acknowledgement packets are of same size, the measured dispersion is good for estimating the round-trip bottleneck capacity, since the narrowest link along the round-trip path gives the largest dispersion to the (probing or acknowledgement) packet pairs. One can then easily estimate this capacity by applying Eq

109 Figure 5.2: Interaction of probe packets in asymmetric link scenarios Fig. 5.2 depicts the packet pair interactions in an asymmetric link scenario, with link capacity C 1 on the forward direction link and capacity C 2 on the backward direction link. The probe packets are sent back-to-back with packet size P 1 on the forward direction link (from A to B); the acknowledgement packets are sent immediately upon receipt of probe packets with packet size P 2 on the backward direction link (from B to A). Suppose T 1 and T 2 represent the respective dispersions of probe packets and acknowledgement packets when they are sent back-to-back on the link; from the definition of Eq. 5.1, T 1 and T 2 can then be derived as T 1 = P 1 C 1 and T 2 = P 2 C 2. The dispersion measured at the end host A, denoted as T, is the dispersion between back-to-back acknowledgement packets. Suppose T 1 > T 2, this means that measured dispersion T equates to T 1. We assume that host B immediately acknowledges the probe packets without incurring additional queuing delay, else the min sum condition would be violated and the pair discarded. On the other hand, suppose T 1 < T 2, then T reflects T 2 instead, i.e. the dispersion generated on the backward direction link prevails. Therefore, T = max(t 1, T 2 ) (5.2) 87

110 Table 5.3: Estimate asymmetric link capacity by varying packet sizes (ideal case without cross traffic and any queuing delays) Probe (P 1 ) and ACK (P 2 ) Packet Size Measured Dispersion T Capacity Estimation C 1 and C 2 P 2 C 2 > P 1 C 1 T T 2 C 1 < C 1; C 2 = C 2 P 2 C 2 < P 1 C 1 T T 1 C 1 = C 1; C 2 < C 2 P 2 C 2 = P 1 C 1 T T 1 = T 2 C 1 = C 1; C 2 = C 2 P 2 = P 1 T max(t 1, T 2 ) C 1 = C 2 = min(c 1, C 2 ) By varying the packet size ratio between the probe and the ACK packets, and observing the forward link capacity estimate (C 1, which is P 1 T ) and the backward link capacity estimation (C 2, which is P 2 T ), the source node can obtain the correct capacity estimations for both directions of the path. For instance, suppose C 1 > C 2 and the initial packet size P 1 = P 2, it can be concluded that T 2 > T 1 because P 2 C 2 > P 1 C 1. From the discussion above, the end-to-end dispersion T measured equates to T 2. Therefore, C 2 = P 2 = C T 2 and C 1 = P 1 T = C 2 < C 1. The estimated capacity is the round-trip bottleneck link capacity on the asymmetric link (the minimum value of C 1 and C 2 ), which is exactly is what CapProbe estimates as presented in [KCL04]. However, by increasing P 1 gradually, C 2 remains equivalent to C 2, but C 1 increases and approaches C 1 gradually. When P 1 increased to P 2 C 1 C 2, C 1 converges to C 1 and C 2 converges to C 2. Conversely, after P 1 increased to larger than P 2 C 1 C 2 (i.e. T 1 > T 2, since P 1 C 1 > P 2 C 2 ), T will reflect T 1. As a result, C 1 = P 1 T = C 1 and C 2 = P 2 T < C 2. This simple relationship between the estimated capacity (C 1, C 2) and the varying packet size can be harvested for the accurate estimation of asymmetric link capacities. Table 5.3 below details this relationship. 88

111 Based on the relationship presented in the table, the AsymProbe algorithm consists of four phases, of which the first three phases are Probing phases, and the last is the Decision phase. Two packet sizes are used in the probing phases: P max and P min, which are chosen carefully by taking network and system issues into account. In the first probing phase P 1 and P 2 are both set to P max. Thus we estimate the bottleneck capacity of the round trip path. In phase 2 and 3, (P 1,P 2 ) are set first to (P max,p min ) and then to (P min,p max ) in order to estimate the forward and backward link capacities respectively. We use C[i][1] and C[i][2] to denote the estimation results of C 1 and C 2 in the i-th phase, respectively. In the fourth phase, namely the Decision phase, a decision algorithm is performed to determine the estimation results of both direction links from all C[i][1] and C[i][2]. However, it should also be mentioned that the capability of Asym- Probe in determining the larger capacity is mathematically bounded by the maximum ratio of packet sizes between probe and acknowledgement packets, i.e. the max of P 1 P 2 and P 2 P 1. Specifically, if both capacity estimates of the narrower direction in Phases 2 and 3 are equal, it indicates that the packet size ratio is not sufficient large to provide accurate capacity estimation of the asymmetric link. In this case, AsymProbe is unable to estimate the actual capacity in the direction with higher speed, but will indicate that such condition as occurred, and report a lower-bound of the capacity instead. Other one-way capacity estimation tools (e.g. Pathrate) can then be applied to further measure the capacity in this direction. The Decision phase algorithm is described in Alg Simulation In this section, we present simulation results that evaluate the accuracy of capacity estimation of AsymProbe on paths with asymmetric links. AsymProbe 89

112 Algorithm 1 AsymProbe Algorithm (The Decision Phase) if C[1][1] == C[2][1] then C 1 = C[2][1] if C[1][1] > C[3][1] then else C 2 = C[3][2] C 2 is larger than Max(C[2][2], C[3][2]) end if else if C[1][1] == C[3][1] then C 1 = C[3][1] if C[1][1] > C[2][1] then else C 2 = C[2][2] C 2 is larger than Max(C[2][2], C[3][2]) end if else if C[1][2] == C[2][2] then C 2 = C[2][2] if C[1][2] > C[3][2] then else C 1 = C[3][1] C 1 is larger than Max(C[2][1], C[3][1]) end if else if C[1][2] == C[3][2] then C 2 = C[3][2] if C[1][2] > C[2][2] then else C 1 = C[2][1] C 1 is larger than Max(C[2][1], C[3][1]) end if end if 90

113 Figure 5.3: Last-hop ADSL scenario. The link capacities are 100Mbps for all links, except the asymmetric DSL link between D and E ( 128Kbps from D to E; 1.5Mbps from E to D) is implemented in the NS-2 simulator [NS2]. Fig. 5.3 depicts the simulation topology that represents a commonly seen scenario nowadays with an asymmetric DSL link. All links are symmetric 100Mbps Ethernet links except the one between node D and E, which is an asymmetric DSL link with 1.5Mbps downlink capacity (from E to D) and 128Kbps uplink capacity (from D to E). Nodes to the left of node D (namely A and C) belong to a home networks, while nodes to the right of node E are on the Internet. The AsymProbe estimation is performed on the path between node A and B. In addition to the AsymProbe flow, various types of cross traffic were generated on the DSL link to test AsymProbe robustness. The cross traffic types used were FTP and Poisson based UDP traffic of different rates. For the Internet segment, long range dependent (LRD) traffic is created between node E and F in both directions. The LRD traffic is composed of 16 Pareto flows with alpha = 1.9 [TWS97], and the overall rate of LRD traffic is 60Mbps in each direction. The maximum and minimum AsymProbe packet sizes, P max and P min, are set to 1500 bytes and 100 bytes respectively. For the various cross traffic configura- 91

114 Table 5.4: Simulation results on end-to-end link capacity estimation for last-hop DSL scenarios (Unit: Kbps) Cross Traffic AsymProbe from A AsymProbe from B CapProbe A B B A B A A B A B none FTP (B C) FTP (C B) Poisson (B C, rate=300kbps) Poisson (B C, rate=750kbps) Poisson (B C, rate=1500kbps) Poisson (C B, rate=25.6kbps) Poisson (C B, rate=64kbps) Poisson (C B, rate=128kbps) tions described in Table. 5.4, AsymProbe is independently initiated from both A and B; results obtained from AsymProbe are then compared against CapProbe as summarized in Table 5.4. From the results shown in Table 5.4, AsymProbe is able to estimate the correct link capacity in both directions for all test cases; whereas CapProbe can only estimate the bottleneck link capacity of the round-trip path. Moreover, simulation results also show that AsymProbe works when placed on either the end-client (node A) or the Internet server (node B). The results are consistent in both cases. It is also worth mentioning that since the link capacity ratio of the simulated scenario is 1.5Mbps/128Kbps, it is smaller than the packet size ratio P max P min, 92

115 Figure 5.4: Testbed for NIST Net experiments AsymProbe is thus able to measure the correct link capacities. However, if we decrease the packet size ratio (e.g. increasing P min in order to avoid the fine time resolution problem as described in [KCS04]) and obtain a packet size ratio that is larger than the link capacity ratio, AsymProbe will only estimate the correct capacity of the narrower link and output the other direction link as a lower bound estimation, defined as P max P min estimation tools can be launched. C NarrowLink. In such case, one-way link capacity Emulator based Testbed Experiments The testbed experiments are performed in the configuration shown in Fig The NISTNet emulator [NIS] is used to set up the asymmetric bottleneck link of various capacities. A backlogged file transfer session is generated from the FTP server to the client as cross traffic. This FTP connection shares the bottleneck link with an AsymProbe connection that traverses from host A to B. For reasons we will discuss shortly, we choose 1500 bytes and 500 bytes as the maximum and minimum packet sizes in this set of experiments, respectively. Thus we have P max P min = = 3. We present the experiment results in Table 5.5 and Table 5.6, in which we may see that when the forward/backward (Table 5.5) or backward/forward (Table 5.6) capacity ratio is below 3, AsymProbe measures both forward and backward capacities very accurately. When the ratio increases 93

116 beyond 3, only a lower bound can be obtained in the direction with the larger capacity. Table 5.5: NIST Net results on Table 5.6: NIST Net results on High/Low asymmetric links (Unit: Low/High asymmetric links (Unit: Mbps) Mbps) Link AsymProbe CapProbe Link AsymProbe CapProbe Capacity Estimation Estima- Capacity Estimation Estima- tion tion F B F B F B F B F: Forward Link; B: Backward Link F: Forward Link; B: Backward Link Internet Experiments In addition to the controlled testbed experiments, we also perform a set of Internet measurements to evaluate AsymProbe in a more diverse and realistic scenario. In 94

117 Table 5.7: Internet results on asymmetric link Link Claimed Capacity Estimated Capacity Down Up # Down Up Kbps 132 Kbps DSL Mbps 128 Kbps Kbps 132 Kbps Kbps 132 Kbps Mbps 565 Kbps DSL 2 3 Mbps 512 Kbps Mbps 567 Kbps Mbps 558 Kbps Kbps 247 Kbps Cable Modem 3 Mbps 256 Kbps Kbps 255 Kbps Kbps 248 Kbps this set of experiments, again we have P max P min = = 3. However, the asymmetric links we have found, provided by DSL 1 and Cable 2 companies, all have a higher down-link/up-link capacity ratio than 3. As presented in Table 5.7, AsymProbe captures the up-link capacities accurately, while only obtaining lower bounds for the down-links Discussion From the simulation and experiment results above, AsymProbe is capable of estimating asymmetric link capacities, as long as the capacity ratio of the forward and backward links is within the range of the packet size ratio of the employed probe and acknowledgement packets. In order to increase the estimation range 1 DSL 1 is provided by Verizon: DSL 2 is provided by Hinet: 2 Cable Modem is provided by Comcast: 95

118 of AsymProbe, the packet size ratio should be as large as possible. However, this ratio is bound by implementation. Specifically, the maximum size of the employed packets must be bounded by the Maximum Transmission Unit (MTU), which is the largest size of an IP datagram allowed to transmit on the path without fragmentation. The size of MTU may vary greatly in different system configurations. However, practically it is set to 1500 bytes in most networks. Packets larger than MTU will be segmented into smaller fragments for transmission and then reassembled on the receiving host. Therefore, using packets larger than MTU is not appropriate for CapProbebased capacity estimation techniques, since the dispersion measurement no longer reflects the bottleneck capacity. On the other hand, the minimum size of AsymProbe packets is also bounded in accordance with the supported time resolution on the estimating host. This is due to the fact that a packet pair with a smaller packet size will result in a smaller inter-packet dispersion, which in turn requires a finer time resolution to be measured accurately. Assume the capacity of the narrow link is C and the probing packet size is P, the dispersion time (and also the clock granularity needed for accurate estimation) that needs to be measured is T = P/C. Table 5.8 shows the required clock granularities that are needed for different probing packet sizes and narrow link capacities. It is clear that the time resolution of an end host relies on the hardware speed and the operating system. A system with fast processors and I/O interfaces can provide a finer time resolution. Additionally, [KCS04] also shows that the accuracy of CapProbe-based capacity estimation is tightly related to the runtime execution mode. With kernel mode implementations, the capacity estimation is faster and more accurate than with user mode implementations. Kernel mode 96

119 Table 5.8: Required time resolution for accurate estimation Packet Size Narrow Link Capacity 1 Gbps 100 Mbps 10 Mbps 1 Mbps 100 bytes ms ms 0.08 ms 0.8 ms 500 bytes ms 0.04 ms 0.4 ms 4 ms 1000 bytes ms 0.08 ms 0.8 ms 8 ms 1500 bytes ms 0.12 ms 1.2 ms 12 ms implementations also provide better time resolutions. Therefore, kernel mode implementations can use smaller packets for capacity estimation than the user mode implementations. In the presented testbed experiments, the employed packet sizes are bounded with 1500 bytes as the maximum and 500 bytes as the minimum. The value of 1500 bytes is determined by the MTU on the path, whereas the value of 500 bytes is the minimum packet size which can measure the dispersion accurately with the provided machine time resolution. Thus it is only capable of estimating an asymmetric link with capacity ratio up to 1500 : 500, namely 3 : 1. For those links with even higher asymmetric ratios (e.g. 1.5Mbps/128Kbps DSL links or 400Kbps/64Kbps satellite links), it is necessary to increase the packet size ratio by either increasing the maximum packet size or decreasing the minimum packet size. Since the maximum packet size is determined by the MTU, which is fixed, the only feasible solution is to decrease the minimum packet size. In such cases, using a faster machine or switching from user mode to kernel mode can help. 97

120 5.3 Measuring End-to-end Capacity in Wireless Ad Hoc Networks With the increasing deployment of wireless devices (e.g. laptops, PDAs, cellphones, etc), ad hoc networking is becoming an increasingly important class of infrastructure less technology for connecting a group of wireless devices. Ad hoc wireless protocols have been extensively investigated at all layers from physical to applications. However, a systematic development of ad hoc wireless network tools is still lacking. In particular, as a difference from the Internet, there are no efficient end to end tools to evaluate ad hoc network resources (eg, path capacity, available bandwidth, etc). Yet, the end to end knowledge of resources such as path capacity is important for network utilization and management. For instance, in a video conference application supported by an overlay that spans wired and wireless ad hoc users, the knowledge of path capacity to different destinations helps the sources and proxies adapt the audio/video streaming rates to match user capacities and provide better quality of services. A simple and accurate end-to-end path capacity estimation tool is needed. The estimation must be fast so that it can reflect the path capacity in a timely even when the actual capacity is varying (for example, because the user is moving from one media to another, or the environment interference is changing). The estimation must be independent of cross traffic (as in this case we are interested in evaluating the equivalent of the bottleneck capacity in the Internet, as opposed to available bandwidth). The estimation tool must be applicable to mixed wired and wireless paths, since several applications (especially the commercial applications) will include ad hoc wireless extensions as opportunistic extensions of the Internet. Finally, the estimation must be non-intrusive so that it will not disturb the ongoing applications traffic in the network. 98

121 End-to-end path capacity estimation in ad hoc wireless networks is a much more challenging problem than in wired nets. The estimation results need to be consistent with/without cross traffic, since the path capacity is a property that is invariant to the presence of cross traffic. At the same time, the estimate depends not only on the rate of the narrow link along the path (as in a wired net), but also on topology, path layout, interferences between nodes along the path and on several other environmental parameters. Moreover, the estimation technique must be applicable to both fixed rate and auto rate wireless networks (where rate can be adjusted to propagation characteristics and energy requirements). In other words, the estimate must account for rate adaptation and reflect it in a transparent way, with no feedback or side information from the network. Motivated by the above goals, in this study we propose AdHoc Probe, a packet-pair based end to end technique that estimates path capacity in ad hoc wireless networks. We evaluated AdHoc Probe in static and mobile networks, with fixed and auto rate modems using simulation and testbed experiments. In all cases we show that AdHoc Probe can estimate path capacity timely and correctly AdHoc Probe AdHoc Probe is based on CapProbe, a well-proved bottleneck link capacity estimation tool for wired and last-hop wireless networks [KCL04]. However, AdHoc Probe differs from CapProbe in many significant ways. First, AdHoc Probe is a one-way (instead of round-trip) estimation technique. Secondly, AdHoc probe measures the maximum rate achievable on an unloaded path (i.e. no other users present) when intermittent environmental problems (e.g. short range mo- 99

122 bility, random errors, etc) are factored out. It turns out that the achievable rate is generally considerably less than the min link capacity (while the two values are identical on a wired path). Thirdly, AdHoc Probe is designed to work under conditions not present in a typical Internet path, for instance when the wireless network is mobile, multihopped, interfered, and subject to rapid changes in link data rates AdHoc Probe Algorithms Similar to CapProbe, AdHoc Probe relies on the packet-pair technique to provide capacity estimation in wireless networks. However, while CapProbe is designed to estimate the bottleneck link capacity in a round-trip fashion, AdHoc Probe intends to estimate the end-to-end path rate based on one-way measurements. The end-to-end path rate is the maximum achievable rate over the wireless path in the absence of any competing traffic. Such metric can be used in end to end applications with QoS requirements, overlay designs, network traffic management, etc. The maximum achievable rate (in the absence of competing traffic) is typically lower than the nominal channel transmission rate due to a variety of reasons including multihopping, unique features of wireless networks (e.g. RTS/CTS mechanism), link rate adaptation techniques, etc. AdHoc Probe is able to accurately measure such achievable rate. The basic AdHoc Probe algorithm can be obtained by modifying the roundtrip CapProbe into a one-way mechanism. Probing packet pairs of fixed size are sent back-to-back from the sender to the receiver. The sending time is stamped on every packet by the sender, the one way delay (OWD) is calculated at the receiver, and the path capacity (i.e. rate) estimation is performed at the receiver and communicated to the sender. 100

123 Figure 5.5: AdHoc Probe capacity estimate using the sample with minimum OWD sum. The receiver measures the OWD of each packet as the difference between time received (clocked at the receiver) and time sent (stamped in the packet header) The OWD sum is then computed. The good packet-pair samples (i.e. the packet pairs encountering no cross traffic) are those with minimum OWD sum (as shown in Fig. 5.5), and the corresponding capacity is given by C = P/T, where P is the packet size and T is the dispersion of the packet pair. AdHoc Probe does not implement the convergence test (as CapProbe does), in order to make the algorithm simple, fast, and timely to the highly varying characteristics of wireless networks. Instead, AdHoc Probe simply reports the capacity estimation after receiving a number of samples, say N. Similar to Cap- Probe, the accuracy of capacity estimation increases as N grows. However, a large N value is not suitable for mobile wireless networks as it will lead to high latency in estimation and may not allow us to capture the dynamic properties of the wireless network. 101

124 Apart from the number of samples, N, the latency of the estimate also depends on the probing packets sending rate (i.e. the probing rate). For simplicity, AdHoc Probe simply sends probing packets (with the packet size of P bytes) using a CBR rate (i.e. R packet-pair/second, or equivalently 2 P R bytes/second). As a result, the expected duration of one estimation is approximately N/R seconds. Clearly, the larger R is, the less time a capacity estimation process takes. However, R should be upper-bounded since a large R may disturb the ongoing foreground traffic in the network or even congest the network. As a result, the capacity estimate may become inaccurate (hard to get one good sample) or extremely slow (packets are lost due to congestion). The probing parameters N and R need to be carefully tuned in accordance with the underlying network properties and by trading off precision for speed. This tradeoff clearly depends on the application. In this paper, we simply set N = 200, P = 1500, and R = 4 sample pairs/sec for all simulations and testbed experiments System Time Synchronization Issue The OWD measurement in AdHoc Probe is problematic on a real testbed. Unlike the perfect time synchronization provided by the simulator, the system clocks of the two end hosts are usually not synchronized. As a result, the measured OWD will not be identical to the actual OWD. Though some software packages and service protocols (e.g. NTP [Mil92]) have been proposed to enable time synchronization of network hosts, one can not guarantee the two end hosts are always synchronized before the estimation. Thus, a successful capacity estimation technique should not rely on any assumptions of a perfectly time-synchronized system. We now provide simple analysis on the AdHoc Probe algorithm and 102

125 show that AdHoc Probe works well even when the system time is not perfectly synchronized. Suppose δ is the constant time offset between the AdHoc Probe sender and receiver. For the i-th packet pair sample, the sending time is stamped T send,i, and the receiving times (on the receiver) are T recv1,i for the first packet and T recv2,i for the second packet, respectively. Therefore, the measured OWD sum (S ) and the actual OWD sum (S) of the i-th packet pair sample are: S i = (T recv1,i T send,i ) + (T recv2,i T send,i ) (5.3) S i = (T recv1,i T send,i δ) + (T recv2,i T send,i δ) = S i 2δ (5.4) Thus the difference between S i and S i is a constant 2δ for all packet pairs. If S k = min i=1...n S i for k [1...n], then S k = min i=1...n S i, and vice versa. By filtering out those samples of non-minimum S, it is easy to identify the good sample that has the minimum S and S, and the capacity estimation is computed by using the interval between this packet pair sample. Clearly, the interval is not affected by the time offset. Therefore, AdHoc Probe is able to absorb the constant time offset δ between the sender and the receiver and produce an accurate capacity estimate Clock Skew Issue In addition to the time synchronization issue, the deployment of one-way AdHoc Probe may also suffer from the clock skew problem, i.e. the clock drift is not identical on different machines. Fig. 5.6 shows an example of actual OWD measurements, when we send UDP packets (4 packets per second) from one laptop 103

126 Figure 5.6: Illustration of clock skew problem in OWD sum measurements to the other using b. The relative OWD (i.e. OW D i OW D 1 for the i-th measurement) is skewed by almost 1 ms after only 80 packets (i.e. 20 seconds)! This is a very big error relative to the typical delay sum, in the order of tens of ms (as seen in Fig. 5.6). As a result, AdHoc Probe tends to select early (late) sample as the good sample when the OWD measurements are affected by an increasing (decreasing) skew. Fortunately, the skewed clock drift problem has been efficiently solved in [ZLX02] by calibrating the skew, and we have implemented the correction in our code accordingly Path Capacity in Wireless Networks A major difference between CapProbe and AdHoc Probe is the interpretation of the result. While in a wired network the path rate is equal to the bottleneck capacity, the path rate of a wireless multihop path is related to, but not necessarily identical, to the minimum of the link rates along the path. In the sequel we first review existing models that predict the effective rate and then show that AdHoc 104

127 Probe indeed estimates such rate. We recall that the effective end-to-end rate is defined as the maximum achievable data rate in the absence of any cross traffic connection. As mentioned earlier, this is smaller than the raw data rate at the physical layer. The difference is due to packet O/H and channel access coordination to handle multiple, pipelined packets on the path. We derive specific models below. More specifically, in the b standard, since a RTS packet is 40 bytes, CTS and ACK packets are 39 bytes, and the MAC header of a data packet is 47 bytes, the effective capacity of a one-hop wireless link can be calculated by using the following equation 3 : C = S S C P (5.5) where S is size of the network layer packet (including IP header), and C P is the link capacity of the physical layer. For instance, when the data packet size is 1500 bytes and the data rate of the wireless link is 2Mbps, the effective capacity 1500 is at most Mbps However, due to the collision avoidance mechanism provided by RTS/CTS exchanges, the effective capacity of the wireless link decreases when there is more than one node within the same collision domain. This is clearly our case where the two packets are attempting transmissions within the same connection and path. It will be true also when a UDP stream will be maintained on the path. Suppose for instance that on the path in question there are N 1 active nodes within node A s transmission range, all engaged in forwarding packets on the same path. The maximum effective rate for that path is C/N since only one 3 We assume physical layer overhead, such as preamble, header and idle time (IFS), are negligible 105

128 Figure 5.7: The chain topology, where the solid-line circle denotes a node s effective transmission range and the dotted-line circle denotes a node s interference range. of the N nodes can transmit a packet at a time. Naturally, it is unusual to have an ad hoc network path that hops several times within the same collision domain. However, this would clearly cause a reduction in effective rate. Such rate reduction must be captured by AdHoc Probe. Much more common is the reduction in capacity incurred when the path is multihop. We consider a simple chain topology as shown in Fig For simplicity, we suppose the nodes are placed on a line with 200 meters to its immediate neighbor node, and the effective transmission range of each node is 250 meters. When the radio interfering range is the same as the transmission range, previous study by Li et al [LBC01] has shown that the effective capacity of a chain topology becomes just 1/3 of the effective capacity of a single cell connection. Moreover, as identified in [XGB02], the radio interfering range is usually much larger than the transmission range. Therefore, the effective end-to-end capacity of a chain configuration will further decrease. For instance, in Fig. 5.7, if the 106

129 interference range (marked by a dotted-line circle) is 550 meters, a packet transmission from node 4 will interfere with a packet transmission from node 1 to 2. In other words, simultaneous data transmission is not possible among nodes 1, 2, 3, and 4. It turns out that the effective end-to-end capacity of the chain topology in Fig. 5.7 will be at most 1/4 of the effective capacity of a single cell topology. Another issue in a multihop path is that data rates may be different hop by hop due to different environment conditions. Thus, the link rate is no longer uniform along the path. In this case, the effective rate can still be computed with the above models, using the minimum rate link along the path. From the above we can conclude that the effective rate in an ad hoc wireless path is more complex to model than in the wired network counterpart. One important feature of AdHoc Probe is that it does measure the correct path rate no matter how complex the underlying channel model (a physical system) is. In the following sections, we will validate AdHoc Probe by comparing the path capacity estimation with the analytical results using simulation and testbed experiments. We will also study the path capacity of wireless networks in more diversified scenarios, e.g. where a link can change its rate according to the network conditions Simulation Results of Fixed Rate Wireless Networks This section presents simulation results illustrating the used of AdHoc Probe in estimating the end-to-end path capacities in a number of fixed rate wireless network configurations. Modeled after Li s simulation configurations in [LBC01], we use the ns-2 [NS2] simulator with CMU wireless extensions. The wireless channel is tuned to imitate the Lucent WaveLan card at 2Mbps, with the effective transmission range 107

130 Figure 5.8: Capacity estimation results of a wireless link (with no interference from other nodes) using one-way and round-trip CapProbe. set at 250 meters and the interference range at 550 meters. Nodes remain stationary during the simulations, and all simulated data packets are preceded by an RTS/CTS exchange, in accordance with the standards. Adhoc probe is implemented in ns-2 and used to estimate the end-to-end path capacity in various wireless network configurations Distinguishing One-way and Round-trip Techniques We first wish to show the difference of one-way AdHoc Probe and round-trip CapProbe techniques by evaluating them on a simple one-hop wireless link (source and destination separated by 200 meters with no external interference). Capacity estimation results from both one-way and round-trip techniques are shown in Fig The results are as expected. As earlier explained in our throughput model, the round-trip estimates are always about half of the one-way estimates in the onehop wireless link scenario. Wireless contention and backoff resulting from packet 108

131 collisions (between the second packet of the packet pair and the acknowledgement of the first packet) is the main reason why round-trip CapProbe consistently measures a lower end-to-end capacity. One intuitive way to see this is that the path capacity is shared by the two directions of the probing flow, and thus it is halved. Since in our applications we are interested in the one direction capacity, we will restrict ourselves to AdHoc Probe in the remainder of the paper Path Capacity on Chain Topologies This subsection studies the capacity on single chain topologies, where packets originate from the first node and are forwarded to the last node on the chain. Forwarding nodes are expected to contend and interfere with their neighbors, meaning that the effective path capacity will be adversely affected. Here, we use the same scenario as shown in Fig The transmission range (marked by solid-line circle) of an node is 250 meters, the interference range (marked by a dotted-line circle) is 550 meters, and the nodes are placed on a straight line with 200 meters in between. We have run a set of AdHoc Probe simulations on chain topologies of various packet sizes and path lengths; the results are shown in Fig As expected, the estimate value increases as the packet size increases, consistent with the analytical results from Eq Moreover, the effective end-to-end capacity decreases as the chain grows longer, demonstrating an inverse relationship between the two variables. When the chain length exceeds four, at the packet size of 1500 bytes, the estimated end-to-end capacity converges to Kbps. It is approximately 1/4 of the single cell capacity, close to the analytical results of discussed earlier. 450kbps as With the same wireless network configuration as specified in [LBC01], AdHoc 109

132 Figure 5.9: Capacity estimation along a chain of nodes with different chain lengths and probing packet sizes. Probe was able to achieve end-to-end capacity estimation that closely matches the analytical prediction (1/4 of single hop capacity). A previous empirical method for evaluating wireless end to end capacity [LBC01] converged to a lower estimate of single cell capacity ( 250 Kbps) using the same channel and packet size assumptions employed in our simulation. That method measured the path rate by pushing a UDP stream and evaluating the achieved throughput. AdHoc Probe attains a path capacity estimate that is more consistent with analytical results as compared with [LBC01], with considerably less intrusion. In general, a stream or flow based testing strategy like the one reported in [LBC01] can be more appealing as it gives a measure of real achieved throughput (i.e. what you measure is what you will actually get this instant with a UDP stream). However, the technique can be too disruptive for some applications. Moreover, the estimate is more limited as it depends on the type of stream used (e.g. the UDP experiment cannot be directly used to predict TCP throughput). If there is other traffic in the network, the probing 110

133 stream will interact with it in a way that is very difficult to analyze; it will be difficult then to extract the idle path rate estimate that we are set out to discover. AdHoc Probe in contrast is much less intrusive. It only needs one good sample to correctly estimate the path capacity no matter what the cross load and interference is. Consequently, the path capacity so estimated is of more general use as it can be employed to model and predict the throughput of different types of streams (e.g. UDP, TCP, etc) in different loading conditions Path capacity within the same interfering domain Next, we evaluate the capacity of a highly interfered wireless path. More precisely, we wish to validate the C/N relationship derived from the model in section To this end, we have designed a simulation experiment where the hops of the multihop path are all in the same collision domain. The topology and configurations used here are the same as previous subsection, except that the distance between a node and its next-hop neighbor is reduced to 10 meters here. We have run AdHoc Probe using the packet size of 1500 bytes with various numbers of hops. Fig shows the average estimation results of 20 runs, as well as maximum and minimum estimates, at each number of hops. As predicted by the model, the end-to-end capacity estimate decreases as the inverse of the number of interfering nodes (or equivalently, the number of hops in the same collision domain) Path Capacity Estimation on Grid Topologies Since grid topologies are more representative of ad hoc configurations than chain topologies, we now consider the n n regular grid shown in Fig Nodes are placed 200 meters away from their horizontal and vertical neighbors. Radio 111

134 Figure 5.10: Capacity estimation of wireless multihop connections within the same collision domain. Figure 5.11: Capacity estimation of wireless multihop connections within the same collision domain. transmission range is set to 250 meters, and the radio interfering range is set to 550 meters. We consider two types of traffic patterns: horizontal flows only (Fig. 5.11a), and horizontal plus vertical flows (Fig. 5.11b). Path capacity is measured for the mid horizontal row via AdHoc Probe; other paths carry flows with Poisson distribution at an average rate that varies up to 100Kbps. Fig and Fig show the respective path capacity estimates. 112

135 Figure 5.12: Capacity estimation in a grid wireless network without cross traffic. Figure 5.13: Capacity estimation in a grid wireless network with both horizontal and vertical cross traffic As shown in Fig and Fig. 5.13, AdHoc Probe gives the correct estimate for all configurations. For example, in a 4 4 regular grid topology, the path length is 4 and (as shown in Fig. 5.9) capacity is 520Kbps. For the 7 7 grid, path length is 7 and capacity is 400Kbps. The estimates become incorrect (by defect) when the grid becomes totally saturated with cross traffic. For example, 113

136 consider the 4x4 grid with both horizontal and vertical cross traffic. Because of the transmit and interfere ranges, only one packet at a time, vertical or horizontal can go through the grid with perfect scheduling. For 1,500B packet size, this translates into an upperbound on the maximum 4x4 grid capacity of 60 Kbps per flow. Fig shows that below saturation the 4x4 capacity estimate is accurate. Around saturation, at 60Kbps, the estimate is not correct by a small defect. In this situation, the grid never offers an idle window through which AdHoc Probe pairs can sneak through and provide min sum estimates. All pairs tend to be separated by an extra amount due to intervening traffic. This leads to underestimates, as clearly shown. This experiment essentially reconfirms for the ad hoc network case the property that we already discovered in wired networks. Namely, CapProbe (and now AdHoc Probe) can estimate the capacity correctly up to the point where the path becomes saturated! This is not very intuitive in multihop ad hoc networks where the packets in the pair travel separated by 4 hops. Any cross traffic transmitted by 2-hop neighbors during this 4 hop window will interfere with the pair and invalidate the min sum requirement. Thus, for the same network loading, the risk of interference with the packet pair appears to be much higher in ad hoc nets than in wired nets. Yet, AdHoc Probe can still estimate the correct capacity! AdHoc Probe with mobile nodes/hosts After evaluating AdHoc Probe in stationary wireless scenarios, we now apply AdHoc Probe to carefully engineered mobile scenarios where we can control the path breakage rate. We want to study AdHoc Probe robustness to path breakage and path reestablishment. Fig depicts the scenario where the AdHoc Probe sender and receiver are fixed, and the intermediate forwarding hosts are 114

137 Figure 5.14: Scenario of fixed source/destination and mobile intermediate nodes. mobile. For each wireless node, radio transmission range is set to 250 meters, and the radio interfering range is set to 550 meters. Node 2, 3, 4, and 5 are moving as a group and clockwise along the dotted square path with a fixed speed (which is varying from 10 m/sec to 100 m/sec). Naturally, similar performance is observed when the intermediate nodes move randomly. But, our scenario permits us to control the path breakage rate. In the scenario, Dynamic Source Routing (DSR) is used so that the AdHoc Probe has a path (3 hops) to destination (but the route continuously breaks and must be reconstructed due to mobility). The capacity estimation is performed with 20 separate runs for each configuration (each run with 200 packet pair samples). The average capacity estimates and standard deviations are shown in Fig The results clearly show that AdHoc Probe is able to accurately estimate path capacity. In other words, enough min sum samples are collected while the path is up to allow the correct rate estimation. AdHoc Probe measured around 530 Kbps capacities, which confirmed the estimation results we obtained from the simulation of the chain topology of 3 hops length. 115

138 Figure 5.15: AdHoc Probe capacity estimates (average of 200 runs and the standard deviation) in fixed source/destination and mobile intermediate nodes simulation scenario Monitoring path capacity in Ad Hoc Networks w/ Mobile End Hosts After the mobile intermediate nodes scenario, we now examine another mobile scenario, where one of the AdHoc Probe hosts is mobile and the intermediate hosts are fixed. Fig depicts the mobile Host scenario, consisting of 25 stationary nodes (numbered from 0 to 24) and one mobile Host (node 25). Stationary nodes are arranged as a 5 5 grid, spaced 200 meters apart from their horizontal and vertical neighbors. The mobile node travels along the indicated path at a fixed speed of 1 meter/second. For the purpose of reducing the number of variables, every node is configured to transmit at a fixed rate of 2Mbps, with a transmission range of 250 meters and an interfering range of 550 meters. DSR routing protocol is used. 116

139 Figure 5.16: MANET Scenario, where node 25 (The Host) is moving along the dotted path with a fixed speed (1m/sec). AdHoc Probe is deployed to measure the capacity of the connection from a fixed source node (node 0) to the mobile Host (node 25). In this simulation, AdHoc Probe uses packet size = 1500 bytes and probing frequency = 4 samples per second, resulting in a rate equal to = 96 Kbps. The path capacity is then estimated with and without cross traffic. In the cross traffic experiment, five Poisson UDP flows, each at an average rate of 5k bps, are set up from nodes 0, 5, 10, 15, 20 to nodes 4, 9, 14, 19, 24, respectively. Results are collected and depicted as points in Fig In Fig. 5.17, we report the capacity estimation. Note that the capacity will vary as the node moves since the path length in hops changes. AdHoc Probe correctly estimates the capacity as a function of hop distance regardless of cross traffic. The results in Fig match the results of the chain topology in zero load reported in Fig When node 25 moves away from its initial position (100,100) towards its first 117

140 Figure 5.17: Capacity estimation of MANET scenario (with and w/o cross traffic). destination (700,700), the estimated end-to-end capacity decreases sharply from the original 1600kps to 780kbps, and then to 500kbps. This is because the hop count increases from one to four during the same period Capacity estimation with Auto Rate Modems Overview of Auto Rate techniques Auto Rate functionality is important for multi-rate wireless devices to maximize the utilization of network resources. For instance, by simply adjusting the transmission data rate, one can achieve higher data throughput with the higher data rate mode, or increase the transmission range and robustness against interference by using a lower data rate mode. Additionally, even within the same data rate mode, the overall data throughput can be improved by opportunistically taking advantage of the channel coherence time (duration for which the wireless node has better-than-average channel conditions). Finally, data rate can be changed 118

141 to save energy [QCJ03]. Several auto rate schemes have been proposed to exploit the multi-rate capability. They can be categorized into two types: Adaptive Rate schemes (e.g. ARF [KM97], RBAR [HVB01], and AARF [LMT04]) and Opportunistic Scheduling schemes (e.g. OAR [SKS02] and MAD [JYZ04]). Adaptive Rate schemes could be either sender based or receiver based. Auto Rate Fallback (ARF) [KM97] is the first published and implemented sender based rate adaptation algorithm. The basic idea of ARF is to start the transmission using highest rate and switch to lower rate when 1 or 2 consecutive failures occur. ARF also starts a timer upon rate dropping. When either the timer expires or 10 successfully received acknowledgements are counted, the transmission rate is upgraded to a higher rate and the timer is reset. The drawbacks of ARF are: (a) the heuristic based ARF cannot adapt effectively in a rapidly varying wireless channel, and (b) ARF data rate tends to suffer from high oscillation even when the wireless channel is not rapidly changing. In [LMT04], Mathieu et al propose Adaptive ARF (AARF) to adapt the threshold settings of ARF in accordance to the channel conditions. As a result, the frequent rate oscillations in ARF are mitigated. Receiver Based Auto Rate (RBAR) [HVB01] is, as the name implies, a receiver based algorithm aiming at optimizing the application throughput. In RBAR, the sender embeds the ongoing transmission rate information in the RTS packet. Upon receiving the RTS packet, the receiver calculates the transmission rate to be used based on SNR and an a priori wireless channel model. The calculated rate is sent back to the sender in the CTS packet. The sender then transmits its DATA frames using the specified rate. Since the RTS/CTS exchange occurs just before the transmission of the DATA packet, RBAR is able to adequately adjust 119

142 Figure 5.18: Illustration of , OAR, and PAC schemes the data rate to the varying channel conditions, and it is generally accepted as the rate adaptation scheme of choice. However, since RBAR modifies the standard RTS/CTS packets, it is difficult to deploy it in existing networks. Besides adapting the transmission data rate, Opportunistic Scheduling schemes transmit multiple data frames without RTS/CTS exchanges when the wireless channel is in good condition. Since the MAC layer overhead is reduced, the effective capacity is increased. Opportunistic Auto Rate (OAR) [SKS02] is the first opportunistic scheduling scheme, which transmits multiple packets (by treating them as fragments) when channel condition allows a higher data rate. Later, Ji et al proposed a Medium Access Diversity (MAD) framework to actively exploit time and space channel dynamics at the MAC layer [JYZ04]. Not only can OAR be incorporated into the MAD framework, it can also work with the Packet Concatenation (PAC) scheme to further eliminate the ACK packets among multiple data packets in OAR. Fig illustrates the MAC layer interactions of the original scheme, OAR scheme, and the PAC scheme. Again, since OAR and PAC need to modify RTS/CTS and DATA/ACK exchanges, they are not compatible with the existing standard. AdHoc Probe will work with any of the above schemes and will provide a stable path rate estimate if the adaptation scheme reaches equilibrium. In the next subsection, we evaluate AdHoc Probe in Auto Rate wireless networks using 120

143 NS-2 simulator with the auto rate extension described in [OAR]. The simulator supports both RBAR and OAR. In the simulation, the transmission data rate of b MAC is adapted among 2, 5.5 and 11Mbps Tracking Capacity Changes in Auto Rate Environment To force RBAR and OAR to adjust the rate, we set up a simulation experiment with a two node network where destination B moves away from source A at the speed of 1 meter/sec. Four AdHoc Probe samples are injected per second, and a capacity estimate is computed every 200 packet pair samples. The same simulation scenario is applied to both RBAR and OAR schemes. The results depicted in Fig show the relationship between the estimated A, B link capacity (with RBAR and OAR respectively) and the distance from the source to the destination. After 700 seconds, when the destination B is 150 meters away from source A, the estimated capacity under RBAR and OAR drops to 4Mbps and 5Mbps, respectively. When the destination is 350 meters away from the source during time 1500 to 2200 seconds, the estimated capacity of RBAR and OAR schemes dropped to around 1.5Mbps. Let us reemphasize the fact that RBAR and OAR adapt the sending rate to the wireless channel S/N ratio. Finally, the distance between A and B decreases again during the interval 2200 to 4000 seconds. RBAR and OAR raise the sending rate since the channel conditions have now improved. OAR achieves a higher capacity than RBAR for the same distance because OAR sends multiple data frames without additional RTS/CTS exchanges. It is remarkable that AdHoc Probe can capture this difference and correctly report the improvement introduced by OAR. The simulation results in this section have amply confirmed the relationship 121

144 Figure 5.19: Simulation results of AdHoc Probe on an auto rate wireless link with different displacements. between the source-destination distance and the path capacity on multi-rate devices. We defer the discussion on interference-triggered rate adaptation to the testbed experiment section Testbed Experiments Here, we perform testbed experiments to measure path capacities of wireless ad hoc networks using AdHoc Probe. We address implementation issues such as time synchronization and clock skew. We experiment with AdHoc Probe in both fixed rate and auto rate actual wireless configurations in the lab. We induce auto rate adjustments by varying the physical distances between nodes and by subjecting the b links to Bluetooth interference. The experiment results are presented below. 122

145 Figure 5.20: Experiment results of AdHoc Probe on wireless multihop testbed (transmission rate is 2Mbps on each link) Experimental results in fixed rate wireless networks The testbed was first set to validate the path capacity on multi-hop fixed rate wireless networks. We placed several b laptops about meters apart in a chain topology. The wireless rate was fixed at 2Mbps. 20 capacity estimates were collected for each path length (i.e. each number of hops). Each run included 200 packet pair samples, and 4 samples were injected every second. The experiment is conducted without cross traffic, and the average and standard deviation of the capacity estimates is presented below in Fig From the results, it is obvious that the effective capacity of a chain topology decreases as the hop length increases, and the estimate remains constant after the number of hops becomes larger than 4. The results confirm what we learned in our simulations. 123

146 Figure 5.21: Experiment results of b one hop connection (auto rate) with different distance between two hosts Experimental results of auto rate wireless networks triggered by displacements To experimentally validate the relationship between source-destination distance and path capacity, we measured the path capacity between auto rate capable nodes when the distance varies by 20 meter increments. The data transmission rate can adapt in the range {11Mbps, 5.5Mbps, 2 Mbps, 1 Mbps}. Four AdHoc Probe samples were collected every second and each run consists of 200 samples. The experiment was conducted without cross traffic. 20 capacity estimates were collected, and their average and standard deviation are presented below in Fig From the results, the estimated capacity remains basically unchanged when the source-destination pair is within 0 60 meters (the average effective one-way capacity is approximately 4.4Mbps, which corresponding to the 11Mbps modem rate when the various O/H components are factored out). When the distance between the source and the destination node increases beyond 60 meters, we ob- 124

147 served a decrease in the measured capacity. In particularly, when the distance between the source-destination reaches 80 meters, AdHoc Probe measures an average effective capacity of 3Mbps, corresponding to 5.5 Mbps modem rate. When the distance between source-destination reaches 100 meters, the average effective capacity of 1Mbps, which again, corresponds to 1Mbps modem rate. The experimental results thus confirm the relationship between source-destination distance and path capacity as discussed in section Experiment results with Bluetooth interference Rate adaptation can be triggered not only by a change in distance but also by wireless interference. In fact, interference has the same effect as reducing the signal to noise ratio as distance does. To investigate the influence of wireless interference on effective capacity of a wireless link, we set up an experiment with a single hop b path interfered by Bluetooth. Fig illustrates the testbed configuration. Two b laptops (i.e. AdHoc Probe sender and receiver) are placed 10 meters apart, and two Bluetooth laptops (the interference generators) communicate with each other creating interference to the receiver. The Bluetooth pair is placed at a varying distance from the receiver (from 0 to 9m). The Bluetooth source sends a CBR traffic to the Bluetooth receiver at 240kbps (1500 bytes/packet; 20 packets/second). Since Bluetooth and b use the same radio frequency band (i.e. 2.4GHz), they interfere with each other, and the link quality of the b connection degrades. As a result, the b sender adjusts its rate using ARF in an attempt to adapt to the changing channel conditions. For each data point 20 AdHoc Probe tests were made, each test consisting of 200 packet pair samples. Probing rate is 5 packet-pairs per second. The average 125

148 Figure 5.22: Auto Rate b Testbed with Bluetooth interference Figure 5.23: Experiment results of b with auto rate and with Bluetooth interference from varying distance and standard deviation of the capacity estimates are presented below in Fig From the results, the average capacity estimate is consistently in the 4Mbps range, which is what we expect for a single hop 11Mbps channel. The estimate is very sharp for Bluetooth beyond 3m. For zero distance, the estimate oscillates as the Auto Rate controller tries to keep up with the changes. It is remarkable that the average estimate at zero Bluetooth distance is quite close to the actual rate. 126

149 Remote estimation of ad hoc network capacity from the wired Internet In the last experiment, we estimate the capacity of a path that starts from the wired Internet and terminates in the ad hoc network. This type of measurement is important in opportunistic ad hoc network applications where for example a server must deliver a multimedia file to a mobile user currently roaming in an ad hoc network connected to the Internet (e.g. an urban vehicular network). The testbed configuration employed in this experiment is the same as in the fixed rate multihop experiment as shown in , except that here the probing packets are sent from the Internet host (i.e. on a wired path), to the access point (which is a laptop with both wired and wireless interfaces), and from the access point via the wireless multihop path to the destination. Note that the procedure is still end to end, the packet pair interval is measured by the destination and the path capacity estimate is returned to the Internet source. Fig shows the experiment results. From the results, AdHoc Probe measures 98Mbps capacity on the wired segment (i.e. when the end point is the access point), which is consistent with 100Mbps fast Ethernet bottleneck. When the end point is wireless, the bottleneck shifts to the ad hoc network and AdHoc Probe measures path capacity consistent with the results in subsection As expected, AdHoc Probe functions well on both wired and wireless paths and combinations thereoff. It is thus an appropriate tool for remotely estimating path capacity of wireless ad hoc extensions of the Internet. 127

150 Figure 5.24: Experiment results of estimating capacity from Internet to ad hoc networks Conclusion In this study, we have reviewed the definition of path capacity in ad hoc wireless networks and have proposed a technique - AdHoc Probe - that can efficiently measure such capacity. The technique is a packet-pair based technique inspired to CapProbe, the equivalent tool used in the Internet. AdHoc Probe measures the wireless path capacity that the user would achieve in absence of competing traffic. The procedure is totally end to end and is thus independent of the specific protocols implemented in the ad hoc network. We have presented analysis, simulation, and experimental testbed results. We have validated AdHoc Probe in fixed rate wireless networks with varying path lengths (in hops). We have also showed that AdHoc Probe works well in a loaded network until the network itself becomes completely congested. We evaluated AdHoc Probe in auto rate wireless networks by varying the displacements and as well as the wireless interference. 128

151 The results showed that AdHoc Probe is able to accurately measure path capacity in all cases of fixed rate networks. Moreover, AdHoc Probe is able to track the rate adaptation of an auto rate wireless link timely and correctly. Finally, AdHoc probe was applied across the Internet to measure the path capacity to a remote wireless network. In summary, AdHoc Probe has provided accurate measurements in all possible environments. It is simple, timely, accurate, and much less intrusive than some previously proposed techniques based on sending entire test streams. 129

152 CHAPTER 6 Service Agility in Mobile and Heterogeneous Networks With the emerging mobile computing scenarios, where the network resources usually change rapidly and dramatically, service agility is becoming increasingly important. Agility is a key property of an adaptive system such that the system can properly detect and respond to changes in network resource availabilities [NSN97]. Though a less agile system may suffice in a more stable environment (e.g. leased lines or enterprise intranets), only a highly agile system can function effectively in the environments of large and erratic resource changes (e.g. mobile systems or wireless networks). Service agility can be implemented either end-to-end or via middlewares. Additive Increase Multiplicative Decrease (AIMD) is the most popular mechanism of end-to-end agility techniques. Based on AIMD, numerous data transmission protocols have been designed and deployed on the Internet. For instance, TCP [Pos81], the dominant transport protocol on the Internet, adapts its congestion window to maximize the data throughput while maintaining fairness with other TCP flows and friendliness with other non-tcp flows. TFRC [FHP00], another best-effort unicast multimedia streaming protocol, adapts its sending rate according to a TCP Reno-based equation [PFT98] to mimic the behavior of TCP congestion control. 130

153 However, these AIMD based systems function effectively only when the changes of network resources are caused by network congestion or slight random losses. When a dramatic change of network resource occurs (e.g. a vertical handoff from 1xRTT technology to b technology which results in the link capacity change from 150Kbps to around 5Mbps), these AIMD based techniques react very slowly [BBF01] and thus perform poorly [GK04]. Alternatively, service agility can be implemented using middleware approaches. Specifically, as proposed by Armando et al [FGC97], scalable network services can be fulfilled by deploying middlewares of TACC (i.e. Transformation, Aggregation, Caching, and Customization) functionalities. For instance, transcoding is one sort of transformation techniques, and it converts a data object (or stream) from one presentation format into another one in real-time. There are three types of transcoding: 1) Format conversion, 2) Data size reduction, and 3) Tailoring [WOM00]. To function agilely, the transcoding middleware must keep tracking the quality of the incoming application data, as well as the network resources (e.g. available bandwidth, link capacity, loss rate, and delay) of the outgoing links (i.e. from the middleware to the end user), and transcode the application data into the proper format accordingly. However, transcoding based solutions tend to result in large latency and huge computation overhead. In this chapter, we propose a service agility solution based on end-to-end network measurements and monitoring. Two passive capacity estimation techniques, namely TFRC Probe and TCP Probe, are proposed to continuously monitor the end-to-end capacity of the connection path. A fast rate adaptation algorithm is proposed to fast react to the case of the drastic capacity change from LOW to HIGH. The detailed approaches and testbed evaluations are presented in the followings. 131

154 6.1 Passive Capacity Estimation TFRC Probe: Passive Capacity Estimation within TFRC We propose TFRC Probe, an on-line capacity monitoring technique achieved through embedding the CapProbe algorithm [KCL04] within the TFRC protocol [FHP00]. Different from the round-trip nature of CapProbe algorithm, we specifically designed TFRC Probe to monitor the link capacity of the forward direction link only. This is based on the realization that capacity information on the forward direction link conveys critical information for any data transferring operations involving asymmetric links. Since information traffic on asymmetric links such ADSL are usually ten times more intensive on forward direction link (download) as oppose to reverse direction link (upload) (e.g. video streaming and file downloading), the ability to appropriately establish the upperbound of servers sending rate can provide much assistance in regulating the quality/speed/smoothness of data delivery services. For instance, a previous study has shown that TFRC is slow in responding to a drastic capacity increase [GK04], and has indicated that a fast rate adaptation algorithm can significantly improve multimedia delivery (for example, by adjusting source rate, content and format) [CNY04]. In this study, TFRC Probe is validated with both simulations and testbed experiments, and has been proven to be quite an effective tool in providing accurate capacity estimation and monitoring TFRC Overview TCP-Friendly Rate Control (TFRC) is an equation based unicast multimedia streaming protocol proposed in [FHP00]. TFRC mimics the TCP long-term throughput by utilizing the response function below to control the upper bound 132

155 of sending rate [FHP00]: T = s ( ) 2p R + t 3p 3 RT O 3 p (1 + 32p 8 2 ) (6.1) T represents the upper bound of the sending rate, which is determined by packet size s, round trip time R, loss event rate p, and the TCP retransmission timeout value t RT O. TFRC is designed to facilitate flow controlled TCP friendly transport of data streams without strict error controls. It is designed to increase the sending rate gradually over time. For example, the maximum increase of TFRC sending rate is capped at just 0.14 packets per RTT, or 0.22 packets per RTT with history discounting as described in [FHP00]. Furthermore, TFRC is also designed to respond smoothly to data loss events, instead of cutting down the sending rate drastically upon every single loss event. In order to achieve smoother data transmission in TFRC, the sender and the receiver are required to cooperate with each other. The sender is responsible for computing the smoothed round-trip time R using an exponentially weighted moving average, and determining the retransmit timeout value t RT O. The sender is also responsible for adjusting its sending rate T actual to be close to T, which is derived from the equation. On the other end, the receiver is responsible for calculating the loss event rate p and sending the information back to the sender once per round-trip time. The loss event rate is obtained by maintaining an array of the last eight loss intervals. This loss interval array is continuously updated and a weighted average of the loss intervals is computed. The reported loss event rate p is defined as the inverse of the weighted average. 133

156 Proposed Approach: TFRC Probe TFRC probe is a passive capacity monitoring technique realized through embedding the CapProbe algorithm within the original TFRC protocol. TFRC Probe is designed to meet the following objectives: a) accurate capacity estimation, b) fast estimation process c) minimal traffic overhead and modification to the original TFRC protocol. Like CapProbe, TFRC Probe estimates link capacity, since such information is important for the streaming server to adjust its sending rate and media quality. However, as a difference from CapProbe, which estimates the round-trip capacity of the path, TFRC Probe is designed to estimate the one-way link capacity on the forward direction link. The one-way estimation is important when the link is asymmetric. In the following we will describe how TFRC can accomplish those objectives. 1. Accurate Capacity Estimation Capacity estimation in the one-way fashion has attracted increasing amount of research interest of late. This is due to the fact that most bandwidth consumption (e.g. data streaming services, file download, etc) occurs on the forward direction link. As a result, capacity information on the forward direction link is helpful for the data servers to properly adjust its sending rate or data quality, whereas the traditional round-trip estimation may not be adequately representative on asymmetric links (e.g. ADSL and satellite links). Following the fundamental concepts of CapProbe, passive capacity estimation capability can be added to TFRC by simply sending a portion of data packets back-to-back and estimating the link capacity based on the measured dispersion and end-to-end delay of these back to back packets 134

157 Figure 6.1: (a) original TFRC (b) TFRC Probe (the gray ones are back-to-back sampling packets) [KCL04]. Fig. 6.1 compares the difference between TFRC and TFRC Probe. In the original TFRC, as illustrated in Fig. 6.1-a, transmission of data packets is paced and evenly distributed, based on the computed sending rate. This is beneficial to multimedia streaming applications which require a smooth and stable sending rate. For the purpose of CapProbebased capacity estimation, however, paced transmission lacks the packet pairs that are crucial to the scheme. In order to perform passive capacity estimation following the CapProbe algorithm, a modification is made in TFRC Probe such that after every nth data packet is sent out, the TFRC Probe sender immediately transmits the next data packet without waiting for the pacing interval. In other words, TFRC Probe creates a back-to-back sampling packet pair for every n packet. The default value of n is set to 20 in our experiments. Fig. 6.1-b highlights the differences between the two schemes. Additionally, in order to achieve one-way capacity estimation, the back-toback sampling packets are time-stamped with the sending time (T 0 ) of the 135

158 corresponding packet pair. Upon receiving the sampling packets, TFRC Probe receiver measures the one-way delay of each packet in the packet pair (T 1 and T 2 ) by subtracting T 0 from its respective receiving time. The dispersion (T 2 - T 1 ) and delay sum (T 2 + T 1 ) are then calculated, and the capacity estimation is made by following the CapProbe algorithm [KCL04]. The capacity estimation results can be reported to the TFRC Probe sender using either the original ACK packets or out-of-band reporting packets. In our implementation, the capacity estimation results are carried by the regular ACK packets; therefore, no additional traffic overhead is introduced. Note that, the measured one-way delay (T 1 and T 2 ) may not exactly represent the experienced transmission time of each sampling packet, since the sender and the receiver hosts may not be correctly synchronized in advance. However, the dispersion measurement and the process of finding the sampling packet pair with the minimum delay sum are still effective in TFRC Probe, as long as the frequency of the time ticks are the same on the two end hosts. Since the CapProbe algorithm only relies on the dispersion of the sampling packet pair which has the minimal delay sum, the capacity estimation can be thus accurate even when the two end systems are not properly synchronized. 2. Fast Link Capacity Estimation Besides providing accurate capacity estimation, a successful link capacity monitoring tool should promptly capture each capacity change event when it occurs (e.g. adaptation of transmission modes on the b link, or a vertical handoff between two different connecting technologies). It turns out that the capacity estimation process needs to be fast and the estimate needs to be updated frequently. The speed of capacity estima- 136

159 tion is determined by two factors, namely the convergence speed and the sampling rate. Though TFRC Probe inherits the outstanding convergence speed from CapProbe algorithm, the speed of capacity estimation in TFRC Probe still relies on the sending rate of the probing packets. More specifically, suppose R send is the sending rate of data packets, S is the number of samples needed to get a reliable capacity estimation, P is the data packet size, t is the expected time to get one capacity estimation, the relation of these properties can be represented in eq. (6.2) and eq. (6.3). R send t = n S P 8 (6.2) = P = R send t 8 n S (6.3) In our implementation, the default setting of n is 20 (the probing packets are sent every 20 data packet), and S is set to 20 (the capacity estimation results are reported every 20 samples). Since R send is maintained by TFRC rate control algorithm, the optimal data packet size P is then obtained by Eq. 3 given the expected time for each capacity estimation update, t, which is set to 5 seconds by default. By iteratively update P according to the sending rate R send for every S samples, TFRC Probe is able to monitor the link capacity with resolution of t seconds. Wisely tuning the resolution factor t, TFRC Probe is able to be notified the capacity changes while monitoring the network links. 137

160 Figure 6.2: Simulation Scenario Simulation In this section, the monitoring ability of TFRC Probe is verified by a variety of configurations in NS-2 simulator [NS2]. A set of simulations are performed to evaluate the accuracy and speed of the capacity estimation, and different types of cross traffic are used to simulate different network dynamics. The topology we used in the simulation is depicted in Fig. 6.2, where bottleneck link (between node 3 and 4) is shared by all the data flows and configured as an asymmetric link with various capacities in the forward direction and fixed capacity (100Kbps) in the backward direction. TFRC Probe and CapProbe are independently performed on the path from node 1 to node 6, and the cross traffic (if it exists) is generated from node 7 to 10, 8 to 9, 11 to 14, and 12 to 13 respectively. Three different types of cross traffic, detailed in Table 6.1, were used to examine the speed and the accuracy of our probing techniques under various network conditions. Cross traffic type I and II are simple FTP/CBR connections between multiple senders and receivers. For cross traffic type III, multiple Pareto flows were used to model after web traffic [TWS97]. Different capacity values are assigned on the link from node 3 to node 4 to create the bottleneck link. In each experiment, we also collect the estimated capacity after 20 packet samples and again using 50 packet samples to evaluate the speed of the estimation. We 138