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

c© Copyright by

Ling-Jyh Chen

2005

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

To My Mom and Dad

iii

Table of Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Wireless Personal Area Networks (WPAN) Background . . . . 5

3 Link Layer Enhancements for WPAN . . . . . . . . . . . . . . . . 12

3.1 Adaptive RTO for Audio Streaming over Bluetooth . . . . . . . . 14

3.1.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 Experiment Results . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Adaptive Packet Type for TCP over Bluetooth . . . . . . . . . . . 24

3.2.1 Analytical Evaluation of Optimal Packet Type . . . . . . . 25

3.2.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Improving Bluetooth Link Throughput via Interleaved FEC . . . 34

3.3.1 Burst Error Model . . . . . . . . . . . . . . . . . . . . . . 35

3.3.2 Proposed Approach - Interleaved FEC (I-FEC) . . . . . . 37

3.3.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Seamless Mobility Support for WPAN . . . . . . . . . . . . . . . 48

4.1 Overview of Seamless Handoff . . . . . . . . . . . . . . . . . . . . 50

4.2 USHA: Universal Seamless Handoff Architecture . . . . . . . . . . 52

iv

4.2.1 USHA Experiments . . . . . . . . . . . . . . . . . . . . . . 54

4.2.2 Choosing the “Best” Handoff Server . . . . . . . . . . . . . 58

4.2.3 Smart Decision Model . . . . . . . . . . . . . . . . . . . . 61

4.2.4 Other Extensions . . . . . . . . . . . . . . . . . . . . . . . 66

4.3 A Case Study of Video Streaming in Vertical Handoffs . . . . . . 67

4.3.1 VTP Overview . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.2 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 End-to-end Capacity Estimation in Wired and Wireless Net-

works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.1.1 Internet Capacity Estimation . . . . . . . . . . . . . . . . 83

5.1.2 Capacity Estimation in Wireless Networks . . . . . . . . . 85

5.2 Measuring Asymmetric Path Capacity . . . . . . . . . . . . . . . 86

5.2.1 AsymProbe . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.2.3 Emulator based Testbed Experiments . . . . . . . . . . . . 93

5.2.4 Internet Experiments . . . . . . . . . . . . . . . . . . . . . 94

5.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.3 Measuring End-to-end Capacity in Wireless Ad Hoc Networks . . 98

5.3.1 AdHoc Probe . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.3.2 Path Capacity in Wireless Networks . . . . . . . . . . . . . 104

v

5.3.3 Simulation Results of Fixed Rate Wireless Networks . . . . 107

5.3.4 Capacity estimation with Auto Rate Modems . . . . . . . 118

5.3.5 Testbed Experiments . . . . . . . . . . . . . . . . . . . . . 122

5.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6 Service Agility in Mobile and Heterogeneous Networks . . . . 130

6.1 Passive Capacity Estimation . . . . . . . . . . . . . . . . . . . . . 132

6.1.1 TFRC Probe: Passive Capacity Estimation within TFRC . 132

6.1.2 TCP Probe: Passive Capacity Estimation within TCP . . 144

6.2 Proposed Approach - I: Implicit Handoff Notification . . . . . . . 149

6.3 Proposed Approach - II: Explicit Handoff Notification . . . . . . . 152

6.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.4.1 Vertical handoff from LOW to HIGH . . . . . . . . . . . . 155

6.4.2 Vertical handoff from HIGH to LOW . . . . . . . . . . . . 156

6.5 Discussion and Conclusion . . . . . . . . . . . . . . . . . . . . . . 160

7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

vi

List of Figures

1.1 The three scenarios of PAN applications . . . . . . . . . . . . . . 3

2.1 Wireless technologies for WLAN and WPAN . . . . . . . . . . . . 6

2.2 ZigBee topology models . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Comparison of narrowband (NB), spread spectrum (SS), and ultra

wideband (UWB). . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Bluetooth Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Bluetooth Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Link Quality vs BER for CSR chipset . . . . . . . . . . . . . . . . 21

3.4 RTO adaptation of the proposed approach . . . . . . . . . . . . . 22

3.5 RTP packet success rate . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 RTP packet delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.7 Bluetooth throughput of different ACL packet types . . . . . . . . 27

3.8 Packet Error Rate vs Bit Error Rate of different pkt types . . . . 27

3.9 Simulation scenario: (a) 1 hop (b) 2 hop (c) 4 hop situation . . . 29

3.10 TCP Newreno throughput with/without the APT link layer for

(a) 1-hop (b) 2-hops (c) 4-hops . . . . . . . . . . . . . . . . . . . 30

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 . . . 31

3.12 Measured Bit Error Rate in 10 minutes . . . . . . . . . . . . . . . 32

3.13 TCP NewReno throughput with/without APT for (a) 1-hop (b)

2-hops (c) 4-hops (with measured bit error rate) . . . . . . . . . . 33

vii

3.14 Markov Model for Wireless Link . . . . . . . . . . . . . . . . . . . 36

3.15 The expectation of burst error length with different Pbb and Pgb

configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.16 (a) original FEC coding in Bluetooth DM mode; (b) I-FEC coding 39

3.17 Retransmission Rates of different schemes evaluated at different

Pgb, given Pbb = 0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.18 Retransmission Rates of different schemes evaluated at different

Pbg, given Pgb = 0.0003 . . . . . . . . . . . . . . . . . . . . . . . . 41

3.19 The accumulative ratio of burst length under different wireless

channel conditions given Pgb = 0.0003; (a) Pbb = 0.99 (b) Pbb =

0.9999. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.20 (a) 1 hop (b) 2 hop (c) 4 hop situation . . . . . . . . . . . . . . . 43

3.21 TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connec-

tions under Burst Error channel with Pbb = 0.2. . . . . . . . . . . 45

3.22 TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connec-

tions under Burst Error channel with Pgb = 0.0003. . . . . . . . . 46

4.1 Mobile computing scenario . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Horizontal and Vertical Handoff . . . . . . . . . . . . . . . . . . . 50

4.3 Diagram of Universal Seamless Handoff Architecture . . . . . . . 53

4.4 Testbed configuration of the vertical handoff experiment between

Ethernet and 802.11b. . . . . . . . . . . . . . . . . . . . . . . . . 55

4.5 Instantaneous throughout results of one TCP flow during a vertical

handoff from 802.11b (11Mbps) to Ethernet (100Mbps). . . . . . . 56

viii

4.6 Sequence number of one TCP flow during a vertical handoff from

802.11b (11Mbps) to Ethernet (100Mbps). . . . . . . . . . . . . . 56

4.7 Instantaneous throughout results of one TCP flow during a vertical

handoff from Ethernet (100Mbps) to 802.11b (11Mbps). . . . . . . 57

4.8 Sequence number of one TCP flow during a vertical handoff from

Ethernet (100Mbps) to 802.11b (11Mbps). . . . . . . . . . . . . . 57

4.9 Instantaneous throughout results of one TCP flow during a vertical

handoff from 1xRTT (150Kbps) to 802.11b (5.5Mbps). . . . . . . 59

4.10 Sequence number of one TCP flow during a vertical handoff from

1xRTT (150Kbps) to 802.11b (5.5Mbps). . . . . . . . . . . . . . . 59

4.11 Instantaneous throughout results of one TCP flow during a vertical

handoff from 802.11b (5.5Mbps) to 1xRTT (150Kbps). . . . . . . 60

4.12 Sequence number of one TCP flow during a vertical handoff from

802.11b (5.5Mbps) to 1xRTT (150Kbps). . . . . . . . . . . . . . . 60

4.13 Diagram of Smart Decision Model . . . . . . . . . . . . . . . . . . 62

4.14 Algorithm for making Smart Decisions on HCC . . . . . . . . . . 63

4.15 An coefficient function example . . . . . . . . . . . . . . . . . . . 65

4.16 Rate adaptation in VTP . . . . . . . . . . . . . . . . . . . . . . . 69

4.17 Frame Rate received at the Mobile Host . . . . . . . . . . . . . . 73

4.18 Sending Rate at the Video Server . . . . . . . . . . . . . . . . . . 73

4.19 Frame Rate received at the Mobile Host . . . . . . . . . . . . . . 75

4.20 Video Quality sent at the Video Server . . . . . . . . . . . . . . . 75

4.21 Sending Rate at the Video Server . . . . . . . . . . . . . . . . . . 75

4.22 Frame Rate received at the Mobile Host . . . . . . . . . . . . . . 77

ix

4.23 Sending Rate at the Video Server . . . . . . . . . . . . . . . . . . 77

4.24 Frame Rate received at the Mobile Host . . . . . . . . . . . . . . 79

4.25 Video Quality sent at the Video Server . . . . . . . . . . . . . . . 79

4.26 Sending Rate at the Video Server . . . . . . . . . . . . . . . . . . 79

5.1 (a) Under-Estimation caused by “expansion” (b) Over-Estimation

caused by “compression” (c) the ideal case . . . . . . . . . . . . . 84

5.2 Interaction of probe packets in asymmetric link scenarios . . . . . 87

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) . . . . . . . . . . . . . . . . . 91

5.4 Testbed for NIST Net experiments . . . . . . . . . . . . . . . . . 93

5.5 AdHoc Probe capacity estimate using the sample with minimum

OWD sum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.6 Illustration of clock skew problem in OWD sum measurements . . 104

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. . . . . . . . . . . . . . . . . . . . . . . . 106

5.8 Capacity estimation results of a wireless link (with no interference

from other nodes) using one-way and round-trip CapProbe. . . . . 108

5.9 Capacity estimation along a chain of nodes with different chain

lengths and probing packet sizes. . . . . . . . . . . . . . . . . . . 110

5.10 Capacity estimation of wireless multihop connections within the

same collision domain. . . . . . . . . . . . . . . . . . . . . . . . . 112

x

5.11 Capacity estimation of wireless multihop connections within the

same collision domain. . . . . . . . . . . . . . . . . . . . . . . . . 112

5.12 Capacity estimation in a grid wireless network without cross traffic.113

5.13 Capacity estimation in a grid wireless network with both horizontal

and vertical cross traffic . . . . . . . . . . . . . . . . . . . . . . . 113

5.14 Scenario of fixed source/destination and mobile intermediate nodes.115

5.15 AdHoc Probe capacity estimates (average of 200 runs and the stan-

dard deviation) in fixed source/destination and mobile intermedi-

ate nodes simulation scenario. . . . . . . . . . . . . . . . . . . . . 116

5.16 MANET Scenario, where node 25 (The Host) is moving along the

dotted path with a fixed speed (1m/sec). . . . . . . . . . . . . . . 117

5.17 Capacity estimation of MANET scenario (with and w/o cross traffic).118

5.18 Illustration of 802.11, OAR, and PAC schemes . . . . . . . . . . . 120

5.19 Simulation results of AdHoc Probe on an auto rate wireless link

with different displacements. . . . . . . . . . . . . . . . . . . . . . 122

5.20 Experiment results of AdHoc Probe on wireless multihop testbed

(transmission rate is 2Mbps on each link) . . . . . . . . . . . . . . 123

5.21 Experiment results of 802.11b one hop connection (auto rate) with

different distance between two hosts . . . . . . . . . . . . . . . . . 124

5.22 Auto Rate 802.11b Testbed with Bluetooth interference . . . . . . 126

5.23 Experiment results of 802.11b with auto rate and with Bluetooth

interference from varying distance . . . . . . . . . . . . . . . . . . 126

5.24 Experiment results of estimating capacity from Internet to ad hoc

networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

xi

6.1 (a) original TFRC (b) TFRC Probe (the gray ones are back-to-

back sampling packets) . . . . . . . . . . . . . . . . . . . . . . . . 135

6.2 Simulation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.3 Capacity monitoring of 802.11b connection using TFRC Probe . . 143

6.4 TCP Westwood Bandwidth Estimate (BE) . . . . . . . . . . . . . 145

6.5 (a) back-to-back TCP packets generate only one ACK because of

DelACK; (b) inverted back-to-back TCP Probe packets are sepa-

rately acknowledged. . . . . . . . . . . . . . . . . . . . . . . . . . 146

6.6 TCP Probe simulation scenario I (cross traffic flows are all in for-

ward direction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

6.7 TCP Probe simulation scenario II (cross traffic flows are in both

forward and reverse direction). . . . . . . . . . . . . . . . . . . . . 149

6.8 Illustration of the ERR algorithm for TCP/TFRC Probe . . . . . 154

6.9 Simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6.10 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). . . . . . 157

6.11 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). . . . . . . . . . . . 158

6.12 Simulation results of TFRC Probe with/without explicit hand-

off notifications during a vertical handoff from a 5Mbps link to a

150kbps link (the vertical handoff occurred at the 600th second). . 159

xii

6.13 Simulation results of TFRC Probe with/without explicit hand-

off notifications during a vertical handoff from a 5Mbps link to a

150kbps link (the vertical handoff occurred at the 600th second). . 160

xiii

List of Tables

2.1 Different Bluetooth ACL connection modes . . . . . . . . . . . . . 8

2.2 IEEE 802.15.4 frequencies and data rates . . . . . . . . . . . . . . 9

3.1 Analytically calculated thresholds at which different packet types

show best performance . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Packet error rates evaluated against different FEC schemes, link

layer packet sizes, and Pbb, given that Pgb = 0.0005 and the initial

channel state is Good . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Comparison of one-way and round-trip based approaches . . . . . 82

5.2 Comparison of active and passive approaches . . . . . . . . . . . . 82

5.3 Estimate asymmetric link capacity by varying packet sizes (ideal

case without cross traffic and any queuing delays) . . . . . . . . . 88

5.4 Simulation results on end-to-end link capacity estimation for last-

hop DSL scenarios (Unit: Kbps) . . . . . . . . . . . . . . . . . . . 92

5.5 NIST Net results on High/Low asymmetric links (Unit: Mbps) . . 94

5.6 NIST Net results on Low/High asymmetric links (Unit: Mbps) . . 94

5.7 Internet results on asymmetric link . . . . . . . . . . . . . . . . . 95

5.8 Required time resolution for accurate estimation . . . . . . . . . . 97

6.1 Types of cross traffic . . . . . . . . . . . . . . . . . . . . . . . . . 139

6.2 Simulation results of TFRC Probe/CapProbe capacity estimation 140

6.3 Capacity estimation of TFRC Probe on the wired links of different

technologies (Capacity: Mbps, Time: second) . . . . . . . . . . . . 141

xiv

6.4 Capacity estimation of TFRC Probe on the wireless links of dif-

ferent technologies (Capacity: Mbps, Time: second) . . . . . . . . 142

6.5 TCP Probe simulation results of scenario I and II (Fb2b: ratio of

back-to-back packets among TCP packets; Fmin: ratio of good

samples among back-to-back TCP packets) . . . . . . . . . . . . . 150

6.6 The required number of TCP packets (N) for obtaining one good

sample in TCP Probe. . . . . . . . . . . . . . . . . . . . . . . . . 150

xv

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 mem-

bers 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, sup-

port, 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

Vita

Dec. 24, 1975 Born, Taipei, Taiwan.

1998 B.Ed. (Information and Computer Education),

National Taiwan Normal University.

2002 M.S. (Computer Science),

University of California, Los Angeles.

2005 Ph.D. (Computer Science),

University of California, Los Angeles.

Publications

Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, and Mario Gerla. “Mon-

itoring Access Link Capacity Using TFRC Probe.” Computer Communications

Journal, Special Issue on Monitoring and Measurements of IP Networks, Elsevier,

2005.

Ling-Jyh Chen, Rohit Kapoor, Sewook Jung, M. Y. Sanadidi, Mario Gerla. “An

Adaptive ARQ Timeout Approach for Audio Streaming over Bluetooth.” In-

ternational Journal of Wireless and Mobile Computing, Special Issue on Mobile

Multimedia Systems and Applications, Inderscience Publishers, 2004.

Rohit Kapoor, Ling-Jyh Chen, Li Lao, Mario Gerla, M. Y. Sanadidi. “Cap-

Probe: A Simple and Accurate Capacity Estimation Technique.” ACM SIG-

xvii

COMM Computer Communication Review, volume 34, issue 4, pp: 67-78, ACM

Press, October, 2004.

Ling-Jyh Chen, Guang Yang, Tony Sun, M. Y. Sanadidi, and Mario Gerla. “En-

hancing QoS Support for Vertical Handoffs Using Implicit/Explicit Handoff No-

tification.” The Second International Conference on Quality of Service in Het-

erogeneous Wired/Wireless Networks, Orlando, USA, 2005.

Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, Mario Gerla. “End-to-

end Asymmetric Link Capacity Estimation.” IFIP Networking 2005, Waterloo,

Ontario, Canada, 2005.

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, 2005.

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, 2005.

Ling-Jyh Chen, Tony Sun, and Mario Gerla. “USHA: A Practical Vertical Hand-

off Solution.” The First International Conference on Multimedia Services Access

Networks, Orlando, USA, 2005.

Ling-Jyh Chen, Tony Sun, Dan Xu, M. Y. Sanadidi, and Mario Gerla. “Access

Link Capacity Monitoring with TFRC Probe.” The Second Workshop on End-

xviii

to-End Monitoring Techniques and Services, San Diego, USA, 2004.

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, 2004.

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,

2004.

Ling-Jyh Chen, Tony Sun, M. Y. Sanadidi, Mario Gerla. “Improving Wireless

Link Throughput via Interleaved FEC.” The Ninth IEEE Symposium on Com-

puters and Communications, Alexandria, Egypt, 2004.

Ling-Jyh Chen, Rohit Kapoor, M. Y. Sanadidi, Mario Gerla. “Enhancing Blue-

tooth TCP Throughput via Link Layer Packet Adaptation.” The 2004 IEEE

International Conference on Communications, Paris, France, 2004.

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, 2004.

xix

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 au-

dio/video streaming between media server and wireless headset, and some are

designed for data synchronization between desktop and personal devices. Sec-

ondly, PAN devices are required to accompany mobile users and expected to pro-

vide 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

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 ap-

plications, 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 de-

termine 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 es-

timation/monitoring tools, we investigate and successfully enhance QoS support

for various mobile networking scenarios.

xxi

CHAPTER 1

Introduction

A Personal Area Network (PAN) is a network composed of various wireless per-

sonal 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 defi-

nitions 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 connec-

tions. For instance, Bluetooth [Blua] has been well accepted as the “enabler”

of PAN technology [JKK01], and it has been standardized in the IEEE 802.15.1

Wireless Personal Area Network (WPAN) standard [IEEb]. Due to the lower

cost, power, and smaller size advantages of Bluetooth chips, it is both function-

ally 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

Several emerging wireless technologies also exhibit great PAN potential, such

as ZigBee [Zig] and Ultra Wideband (UWB) [IEEa] technologies. Though the dis-

tinctions, in terms of transmission range and data throughput between WLAN

and WPAN are dissolving with the emerging wireless technologies, the fundamen-

tal 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 au-

dio/video streaming between media server and wireless headset, and some are

designed for data synchronization between desktop and personal devices. Sec-

ondly, PAN devices are required to accompany mobile users and expected to pro-

vide 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. 1.1. 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

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 enhance-

ments for PAN applications. We study and evaluate PAN applications in mobile

scenarios. We also investigate strategies, either at the link layer or at the trans-

port 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 en-

hancements via link layer approaches (Chapter 3). Using Bluetooth technol-

ogy, 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 allow-

ing the mobile node to determine the “best” network to connect to and auto-

3

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 estima-

tion/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

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. 0 ∼ 100 meters), and

some WPAN technologies (e.g. UWB) are even able to achieve higher data rates

than WLAN technologies (e.g. 802.11a/b/g).

Additionally, the applications of WPAN and WLAN devices are also converg-

ing. For instance, people, though equipped with WLAN devices, usually prefer

to directly exchange data, instead of transmitting data through local area net-

works or Internet, due to privacy and security concerns. On the other hand,

5

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

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 pi-

conet, 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, dif-

fering in their usage of FEC coding. In DH mode, Bluetooth sends pack-

ets without FEC coding in order to maximize the achievable throughput;

7

Table 2.1: Different Bluetooth ACL connection modes

Packet Symmetric Asymmetric

Mode FEC Size Length Throughput Throughput

(bytes) (slots) (Kbps) (Kbps)

DM1 Yes 17 1 108.8 108.8 108.8

DM3 Yes 121 3 258.1 387.2 54.4

DM5 Yes 227 5 286.7 477.8 36.3

DH1 No 27 1 172.8 172.8 172.8

DH3 No 183 3 390.4 585.6 86.4

DH5 No 339 5 433.9 723.2 57.6

whereas in DM mode, it uses a (15, 10) shortened Hamming code to pro-

tect 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) stan-

dard targeted at home and building automation and controls, situational

8

Table 2.2: IEEE 802.15.4 frequencies and data rates

PHY (MHz) Frequency Band (MHz) Modulation Data Bit Rate

868/915868 - 868.6 BPSK 20 kbps

902 - 928 BPSK 40 kbps

2450 2400 - 2483.5 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 802.15.4

[IEEc], whereas the network and upper layers are specified by ZigBee Al-

liance [Zig].

IEEE 802.15.4 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 802.15.4. 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 902-928MHz band. The detailed

frequencies and data rates of IEEE 802.15.4 are listed in Table 2.2.

The channel access employed in IEEE 802.15.4 is carrier sense multiple ac-

cess with collision avoidance (CSMA/CA). Two data transmission modes,

namely beacon-enabled mode and non-beacon-enabled mode, are imple-

mented to support slotted and unslotted CSMA/CA. Depending on the

device capabilities, the IEEE 802.15.4 device can be functioned as a net-

work coordinator, full function device, or reduced function device.

While the overall design principle of IEEE 802.15.4 is to provide simplic-

9

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 up-

per 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

802.15.3a [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. 2.3. 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

Figure 2.3: Comparison of narrowband (NB), spread spectrum (SS), and ultra

wideband (UWB).

Personal Area Networks (HR-WPANs), which are composed of several per-

sonal 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 oper-

ate effectively in the presence of other UWB devices or other IEEE systems

(e.g. 802.11a/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

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 be-

comes 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 prob-

lem 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 chan-

nel bandwidth. This results in inferior performance from higher network layers

such as TCP and video streaming applications. Therefore, if the number of re-

transmissions 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) Retrans-

mission 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

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

802.11a 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

A combined solution in the link layer will take advantages of the three tradi-

tional strategies in providing a more robust and high performance wireless chan-

nel. 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 consid-

ered 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 retrans-

mission 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 re-

transmission timeout is exceeded, at which point the packet is dropped [Blua].

However, in most current Bluetooth chipsets, the default value of the retransmis-

sion 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

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

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:

SRTT ′ = (1− γ)× SRTT + γ ×RTT (3.1)

RTO′ =

α×RTO if RTT < SRTT

β ×RTO if RTT > SRTT

RTO 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 RTO value. The

lower bound RTOmin is taken as 2 × Tpacket, which is the time interval between

two RTP packets sent on the server side. Tpacket 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 Tpacket, too many packets were dropped at the link layer due to the RTO

limit being exceeded. Thus, 2× Tpacket proved to be a good lower bound.

The upper bound RTO is proportional to the available buffer size, as shown

in the following equation.

Bavail = (BMAX −Bused)/PRTP (3.3)

RTOmax = Tpacket ×Max(Bavail × 75%, 2) (3.4)

16

where Bavail is the available buffer size, which is the system maximum input

buffer size (BMAX) minus the used buffer size (Bused), divided by the RTP packet

size (PRTP ). 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.

3.1.1 Implementation

We implemented both the fixed RTO and the adaptive RTO method on our Blue-

tooth 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 802.11b 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. 3.1.

The streaming protocol used in our experiments is RTSP (Real-Time Stream-

ing Protocol) [SRL98], which is widely used on the Internet. RTSP is an application-

level 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

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 417× 3+16 = 1267 bytes, and the Tpacket, the time

interval between two RTP packets sent on the server side, is 1267×8/128000 ' 80

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 0.625× (5 + 1)× 4 ' 15

msec, where 0.625 msec is the Bluetooth slot time, (each DH5 packet consumes

5 time slot in one direction and 1 in the opposite direction).

3.1.1.1 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 Adapta-

tion Layer Protocol) layer provides connection-oriented and connectionless data

18

Figure 3.2: Bluetooth Stack

services to upper layer protocols with protocol multiplexing capability, segmen-

tation 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

3.1.1.2 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 envi-

ronmental factors make the link quality unpredictable. We used 802.11b devices

to create interference for the Bluetooth connections, because both of them op-

erate 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

802.11b 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∗40000

20

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.

3.1.2 Experiment Results

In this section, we present experiment results showing the improvement in real-

time audio quality when using the proposed approach. The testbed setup and

implementation are described in previous section, and the experiments are re-

peated 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 re-

spectively. 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

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.

3.1.2.1 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. 3.2.

22

Figure 3.5: RTP packet success rate

3.1.2.2 RTP Packet Success Rate

Fig. 3.5 shows the RTP packet success rate on the receiver side, i.e. the per-

centage of packets successfully transmitted. Different BERs were generated by

varying the load on interfering 802.11 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.

3.1.2.3 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

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 0.0045, 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 con-

cludes that the adaptive packet scheme operate adequately with BER up to 0.004

(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 improve-

ment in performance.

3.2 Adaptive Packet Type for TCP over Bluetooth

Wireless links are characterized by higher bit error rates and this causes ineffi-

ciencies 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

occurring due to buffer overflow. The response of TCP to all such events is to

invoke its congestion control procedures, resulting in unnecessary window reduc-

tion, 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.

3.2.1 Analytical Evaluation of Optimal Packet Type

In this subsection, we describe a simple analysis to determine the relative perfor-

mance 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

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)15 + 15b(1− b)14)s/15 (3.6)

Assuming that the ARQ scheme retransmits a packet until the acknowledge-

ment 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)pk−1 =1

1− p(3.7)

The effective link layer throughput T is then given by:

T =s

N × (n + 1)× 625us=

s(1− p)

0.000625(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

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. 3.7. 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

Table 3.1: Analytically calculated thresholds at which different packet types show

best performance

Mode BER range

DH5 < 0.0001529

DM5 > 0.0001529, and < 0.0060795

DM3 > 0.0060695, and < 0.0157813

DM1 > 0.0157813

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.

3.2.2 Simulation Results

In this subsection, we present simulation results showing the improvement in

performance when using the enhanced Bluetooth link layer. The Bluetooth sim-

ulation model was developed as an extension to NS-2 (Network Simulator) [NS2].

The simulation model implements most of the features of the Bluetooth base-

band layer, such as frequency hopping, time division duplexing, multi-slot pack-

ets, fragmentation and reassembly of packets. In addition, the simulator enables

scatternets and inter-piconet communication by defining gateway nodes to for-

ward packets between piconets. The channel model assumes independent bit

errors.

The Bluetooth topologies we used in the simulations is shown in Fig. 3.9.

Black circles represent master nodes, and white circles represent slave (or gate-

way 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

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.

3.2.2.1 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. 3.10 (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

Figure 3.10: TCP Newreno throughput with/without the APT link layer for (a)

1-hop (b) 2-hops (c) 4-hops

3.2.2.2 Varying bit error rate

We then considered a changing bit error rate environment, in which the bit error

rate switches from 0.0001 to 0.0005 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. 3.11 (a), (b) and (c) show the throughput results over regular and en-

30

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.

3.2.2.3 APT with real bit error rate measurement

In order to simulate the APT enabled link layer with more realistic error behav-

ior, we took traces of the channel behavior of a real Bluetooth environment over

31

Figure 3.12: Measured Bit Error Rate in 10 minutes

a 5-minute period and plugged these into our simulator. The measurements envi-

ronment consisted of two Xircom Bluetooth cards (containing the CSR chipset)

at a 5-meter distance, with 802.11b 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 802.11 devices

and converted this into the bit error rate, using the technique explained in section

3.1.1.2. Fig. 3.12 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. 3.13. Clearly, the

enhanced link layer outperforms the regular link layer.

3.2.3 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

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

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. Re-

dundancy 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 vul-

nerable 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 inter-

leaving 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 er-

ror 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

unparalleled amount of protection against heavy channel burst errors.

3.3.1 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, Pgg, Pgb, Pbg, and Pbb, are then given and they specify the state

transition probabilities. For example, Pgb defines the probability of transition

from the good state to bad state, and Pbb defines the probability of remaining in

bad state, which actually reflects the degree of burst errors. The Markov chain

is ergodic with stationary probabilities Pg = 1−Pbb

1−Pbb+Pgband Pb =

Pgb

1−Pbb+Pgb, and

Pb is the average bit error rate (BER) [ZR97]. The expectation of burst error

length, L, can thus be obtained by Eq. 3.9. Fig. 3.15 depicts the relationship

among Pbb, Pgb, and the expectation of burst error length.

L =∞∑

n=1

(n× Pg × Pgb × P nbb × Pbg) (3.9)

Given Pgb = 0.0005 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

Figure 3.14: Markov Model for Wireless Link

Figure 3.15: The expectation of burst error length with different Pbb and Pgb

configurations.

Table 3.2 clearly shows that data packet coded by FEC scheme outperforms

data packets without FEC coding when Pbb (degree of burst error) is small. How-

ever, when Pbb increases, we note that FEC coding schemes cease to make a sig-

nificant 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 band-

width as more packets, packet overhead, and communication overhead need to

be transmitted.

36

Table 3.2: Packet error rates evaluated against different FEC schemes, link layer

packet sizes, and Pbb, given that Pgb = 0.0005 and the initial channel state is

Good

Packet FEC Pbb

Size Level 0.1 0.3 0.5 0.7 0.9

(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%

3.3.2 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 de-

creases the maximum achievable throughput, its ability to correct minor data

losses makes FEC a desirable link layer coding scheme in error-prone environ-

ments, such as in the wireless medium.

Bluetooth’s link layer implements both DH and DM connection modes, differ-

ing in their usage of FEC coding. In DH mode, Bluetooth sends packets without

37

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 en-

hances 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 tech-

niques. 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 ap-

plied I-FEC to its link layer. Since Bluetooth is a popular personal area network

38

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 net-

works 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.

3.16.

39

3.3.3 Analysis

Since I-FEC uses the same (15, 10) Hamming code for FEC coding as Blue-

tooth 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 interleav-

ing 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 ran-

dom errors, and the survivability of interleaving against burst errors. For in-

stance, 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. 3.17 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 (Pbb = 0.2), Fig. 3.17shows that

I-FEC consistently achieves a lower retransmission rate than FEC. It is also ob-

served that FEC coded transmission is consistently better in retransmission rate

compare to transmission without FEC coding scheme. In Fig. 3.18, with Pgb

fixed as 0.0003, I-FEC again outperforms FEC by achieving a smaller retrans-

mission rate. However, FEC coded transmission begin to perform as poorly as

regular transmission when Pbg decreases due to increasing degree of burst error

40

Figure 3.17: Retransmission Rates of different schemes evaluated at different Pgb,

given Pbb = 0.2

Figure 3.18: Retransmission Rates of different schemes evaluated at different Pbg,

given Pgb = 0.0003

(Pbb = 1−Pbg). When Pbb is greater than 0.999 (Pbg 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

Pbb increases. When Pbb increases beyond 0.999, none of the available schemes

can really make a difference in the retransmission rate. The relationship between

41

Figure 3.19: The accumulative ratio of burst length under different wireless chan-

nel conditions given Pgb = 0.0003; (a) Pbb = 0.99 (b) Pbb = 0.9999.

the length of burst length and Pbb is depicted in Fig. 3.15.

3.3.4 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. 3.20. 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

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.

3.3.4.1 TCP with different Pgb

TCP NewReno was used for the first set of simulation, and Fig. 3.21 illustrates

the performance of TCP NewReno evaluated under different link layer schemes,

number of connections, and Pgb 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, Pbb is always

fixed as 0.2 and Pgbvaries from 0.0001 to 0.001 for each series of experiment.

The simulation result shows that TCP throughput decreases considerably

when Pgb increases for FEC coded transmission (DM mode) and regular trans-

mission (DH mode). On the other hand, I-FEC was able to maintain a very

43

consistent throughput regardless of the changes in Pgb. 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 out-

perform 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.

3.3.4.2 TCP with different Pbb

The second simulation is to compare the performance of TCP NewReno under

different link layer schemes, number of connections, and varying burst error prob-

abilities. The TCP connection and the Bluetooth configuration is the same as

the previous section, except Pgb is now fixed at 0.0003 and Pbb varies from 0 to

0.9999 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 Pbb (Pbb = 1−Pbg). The throughput performance of FEC coded transmission

decreases dramatically when Pbb 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 Pbb 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.

3.3.5 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

Figure 3.21: TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections

under Burst Error channel with Pbb = 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

Figure 3.22: TCP Performance on Bluetooth 1-hop, 2-hop, and 4-hop connections

under Burst Error channel with Pgb = 0.0003.

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

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 ap-

proach was effective in eliminate the latency usually associated with packet level

interleaving. Therefore, we have demonstrated that I-FEC has much to con-

tribute in providing higher performance and more reliable services in the wireless

environment.

47

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 802.11b wireless connection in

her office. Concurrently, she is informed of an urgent request for her immedi-

ate 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 802.11b high-capacity connection, i.e. building A),

take an express shuttle to her collaborator’s location (during which time contin-

uing 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 802.11b 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 connec-

tivity even when the mobile is moving. The maintained connectivity could be

provided by one or more network interfaces (technologies). However, when mul-

tiple network interfaces are used, the “switch” of network interfaces (i.e. vertical

48

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 Uni-

versal 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 Deci-

sion Model” for USHA to decide the “best” network interface at any moment.

Given the Smart Decision Model, the mobile applications are able to automati-

cally trigger a vertical handoff. Thus, the transparency of mobility support could

be achieved.

49

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 cellu-

lar 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. 4.2. A vertical handoff involves two different network interfaces, which

usually represent different technologies. For example, when a mobile device moves

out of an 802.11b 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 802.11b network domains, the handoff event would be

considered as horizontal since the connection is disrupted solely by the change of

802.11b 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 connec-

tivity of all applications on the mobile device when the handoff occurs. Seamless

50

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 al-

most 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 typ-

ically 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 lay-

ers 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 IP-

less, are often elaborate to implement and to operate. For the network layer

solutions, deployment translates to upgrading every existing router without mo-

bile 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 support-

ing 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

the proliferation of mobile applications and mobile users, a “simple” and “prac-

tical” seamless handoff solution with minimal changes to the current Internet

infrastructure remains necessary.

USHA, an upper layer solution providing simple and practical handoff solu-

tion, 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

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

4.2.1 USHA Experiments

In this section, we present USHA measurements in two vertical handoff sce-

narios. In subsection 4.2.1.1, we first evaluate the “indoor-mobility” scenario,

which is common for mobile users performing handoffs between 100Mbps Ether-

net (e.g. his/her working cubicle) and 802.11b (e.g. conference room) network

interfaces. In subsection 4.2.1.2, we evaluate USHA in the “outdoor-mobility”

scenario, where the mobile user performs vertical handoffs between different wire-

less technologies (e.g. 802.11b in the cafe and 1xRTT on the freeway).

4.2.1.1 Vertical Handoff between Ethernet and 802.11b

Fig. 4.4 illustrates the “indoor-mobility” scenario, where the mobile user per-

formed a vertical handoff between Ethernet (100Mbps link capacity) and 802.11b

(11Mbps mode1). A FTP (TCP based) download session was initiated at the

beginning of each experiment and stopped after two minutes. The vertical hand-

off 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. 4.4.

1. Handoff From 802.11b 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 802.11b 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

1The effective capacity of 11Mbps transmission rate mode is around 5∼6 Mbps. [KCL04]

54

Figure 4.4: Testbed configuration of the vertical handoff experiment between

Ethernet and 802.11b.

the results, it’s clear that USHA can truly achieve seamless vertical hand-

offs.

2. Handoff From Ethernet to 802.11b

In addition to the handoff from LOW to HIGH capacity link, we also evalu-

ated FTP downloading during a vertical handoff from Ethernet to 802.11b

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 ver-

tical 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

Figure 4.5: Instantaneous throughout results of one TCP flow during a vertical

handoff from 802.11b (11Mbps) to Ethernet (100Mbps).

Figure 4.6: Sequence number of one TCP flow during a vertical handoff from

802.11b (11Mbps) to Ethernet (100Mbps).

4.2.1.2 Vertical Handoff between 1xRTT and 802.11b

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 802.11b in our experiments.

56

Figure 4.7: Instantaneous throughout results of one TCP flow during a vertical

handoff from Ethernet (100Mbps) to 802.11b (11Mbps).

Figure 4.8: Sequence number of one TCP flow during a vertical handoff from

Ethernet (100Mbps) to 802.11b (11Mbps).

While 1xRTT provides greater coverage, 802.11b is able to achieve higher data

throughput.

The testbed configuration is similar to Fig. 4.4, except here we replace Eth-

ernet link with 1xRTT link, and use 5.5Mbps transmission mode for the 802.11b

57

link2. The 1xRTT link is with around 150Kbps link capacity3 and 350 ms round-

trip 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 802.11b

Fig. 4.9 and 4.10 shows the instantaneous FTP (TCP) throughput and

packet sequence number during the vertical handoff process (which oc-

curred around 60th second) from 1xRTT to 802.11b. 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 802.11b to 1xRTT

Fig. 4.11 and 4.12 show another measurement results, where the vertical

handoff is from 802.11b to 1xRTT. Similar to the results of the handoff

from 802.11b 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.

4.2.2 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

2The effective capacity of 5.5Mbps transmission rate mode is around 3∼4 Mbps.3The ISP claims 150Kbps link capacity, but CapProbe [KCL04] only measures around

90Kbps capacity.

58

Figure 4.9: Instantaneous throughout results of one TCP flow during a vertical

handoff from 1xRTT (150Kbps) to 802.11b (5.5Mbps).

Figure 4.10: Sequence number of one TCP flow during a vertical handoff from

1xRTT (150Kbps) to 802.11b (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

Figure 4.11: Instantaneous throughout results of one TCP flow during a vertical

handoff from 802.11b (5.5Mbps) to 1xRTT (150Kbps).

Figure 4.12: Sequence number of one TCP flow during a vertical handoff from

802.11b (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

pacity, as the “best” HS. Specifically, suppose there are k network interfaces on

the mobile host, and there are n candidate HS. Di,j and Ci,j denote the round-trip

delay and link capacity of the ith network interface to the jth HS. Dthresh 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.

maxi=1...k

Di,r ≤ Dthresh (4.1)

mini=1...k

Ci,r ≥ mini=1...k

Ci,j ; j = 1...n (4.2)

4.2.3 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 transpar-

ent 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. 4.13 depicts the pro-

posed Smart Decision Model. In this figure, a Handoff Control Center (HCC)

provides the connection between the network interfaces and the upper layer ap-

plications. HCC is composed of four components: Device Monitor (DM), System

Monitor (SM), Smart Decision (SD), and Handoff Executor (HE). DM is respon-

sible 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

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 imple-

mented 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. 4.14.

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. 802.11b 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

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:

Si =k∑

j=1

wjfj,i 0 < Si < 1,k∑

j=1

wj = 1 (4.3)

In the equation, wj stands for the weight of factor k, and fj, 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

Si = wefe,i + wcfc,i + wpfp,i (4.4)

Additionally, there is a corresponding function for each term fe,i, fc,i, and

fp,i, and the ranges of the functions are bounded from 0 to 1. The functions are

illustrated below:

fe,i =1

eαifc,i =

eβi

eMfp,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 fe,i and fp,i to

bound the result to between zero and one (i.e. these functions are normalized),

and properly model users preferences. For fc,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 inter-

faces. Note that, the properties of bandwidth and usage cost/power consumption

are opposite (i.e. the more bandwidth the better, whereas lower cost/power con-

sumption is preferred).

4.2.3.1 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

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 xi is the usage cost (ISP

charge), yi is the measured link capacity, and zi 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 wj to j-th function.

The following illustrates an example of how Smart Decision is achieved. Sup-

pose a mobile user who is currently using the 1xRTT device enters a caf. The

HCC immediately discovers an 802.11b 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 802.11b 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 802.11b 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 802.11b

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 (wp=0.4), and equal weight

to usage cost and bandwidth requirement (we = 0.3, wc = 0.3). The HCC then

65

computes the score according to Eq. 4.4 and Eq. 4.5 using coefficient functions

illustrated in Fig. 4.15. Eq. 4.6 and 4.7 show the calculation of the score results

of both 1xRTT and 802.11b interfaces, where S1xRTT = 0.83 and S802.11b = 0.44.

Since S1xRTT > S802.11b, the HCC therefore decides to continue using 1xRTT

interface instead of switching to the faster 802.11b interface.

S1xRTT = 0.3× 1

eα+ 0.3× 1

eβ+ 0.4× 1

γ

= 0.3× 1

eo+ 0.3× 1

e100kbps/2Mbps+ 0.4× 1

e2/4

≈ 0.83

(4.6)

S1xRTT = 0.3× 1

eα+ 0.3× 1

eβ+ 0.4× 1

γ

= 0.3× 1

e10/20+ 0.3× 1

eMin(2,5)Mbps/2Mbps+ 0.4× 1

e2/2

≈ 0.44

(4.7)

Note that, though the example shown in this section uses the coefficient func-

tions 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.

4.2.4 Other Extensions

In addition the support of continuous connectivity, USHA could be easily ex-

tended by inserting additional ‘plug-ins’. For instance, the HS can be extended by

incorporating the transcoding functionalities. More specifically, when the avail-

66

able bandwidth4 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. Result-

ing 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 Inter-

net. 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 Uni-

versal 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

4For instance, Spruce [SKK03] can be employed to quickly estimate the available bandwidthof a given path.

67

quality, via adapting video streaming in the vertical handoffs.

4.3.1 VTP Overview

4.3.1.1 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 calcu-

lated 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 di as the number of bytes in packet i, ti as the

time when packet i arrives at the client. The sample of achieved rate measured

when packet j is received, denoted as bj, is

bj =

∑k−1l=0 dj−l

tj − tj−(k−1)

(4.8)

The EWMA is needed to smooth achieved rate samples and eliminate random

noise. Denote Bi as the available bandwidth estimate after getting sample bj, then

Bj = α ·Bj−1 − (1− α)(bj + bj−1

2) (4.9)

The reason of using both bj and bj−1 is to further reduce the impact of ran-

domness in the achieved rate samples.

68

4.3.1.2 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 dif-

ferent rates. Compression algorithms such as MPEG-4 [MPE] can adjust para-

meters, 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 mul-

tiple 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

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.

4.3.1.3 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

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 stream-

ing in seamless handoff scenarios of our integrated USHA + VTP testbed.

4.3.2 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, 100∼250, 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 802.11b and

1xRTT provided by Verizon Wireless. The 802.11b 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 802.11b (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

4.3.2.1 Handoff from 1xRTT to 802.11b

In the first set of experiments, we evaluate the performance of video stream-

ing when the mobile host performs handoff from the lower-capacity interface of

1xRTT to the higher-capacity interface of 802.11b.

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. 4.17 shows the frame rate received by the mobile client,

and Fig. 4.18 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 trans-

parent to applications. The video quality is overall very good in terms of

smoothness. However, Fig. 4.18 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 ad-

vantage of the increased ”sending rate” and bandwidth. This justifies the

72

Figure 4.17: Frame Rate received at the Mobile Host

Figure 4.18: Sending Rate at the Video Server

73

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. 4.20 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 802.11b.

Fig. 4.21 shows the reference and sending rates on the VTP server. Prior to

the handoff at 60 sec, Figure 8 looks very similar to Fig. 4.18. 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 802.11b 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

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

4.3.2.2 Handoff from 802.11b to 1xRTT

In the second set of experiments, we evaluate the performance of video stream-

ing when the mobile host performs handoff from the high-capacity interface of

802.11b 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 802.11b, 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.

4.22 (video frame rate received by the mobile client) and Fig. 4.23 (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

Figure 4.22: Frame Rate received at the Mobile Host

Figure 4.23: Sending Rate at the Video Server

77

2. Adaptive Video Streaming

Moving on to the adaptive video experiments, Fig. 4.24 shows the video

frame rate received at the mobile client - high and stable as we have seen in

Fig. 4.19. 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. 4.25 and Fig. 4.26 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 802.11b 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.

4.3.3 Discussion

In a handoff-enabled environment, drastic changes in the link capacity are of-

ten associated with vertical handoff events. For instance, handoff from 1xRTT

to 802.11b 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 ad-

vantage 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

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

account the effect of drastic capacity changes in both up and down directions.

From the experiment results presented in sections 4.3.2.1 and 4.3.2.2, 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 802.11b), 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. 802.11b) 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 con-

nection 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

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 tech-

nologies and applications, such as overlay, peer-to-peer (P2P), grid and mobile

networks. Knowing link capacity is particularly desirable for numerous applica-

tions. For instance, capacity information can benefit P2P clients to avoid down-

loading 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 sup-

port 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 ca-

pacity estimation in wired and wireless networks based on CapProbe [KCL04],

which is a simple, fast, accurate, end-to-end, and less intrusive technique. More-

over, 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

Table 5.1: Comparison of one-way and round-trip based approaches

One-way approach Round-trip approach

Pros ¦ Can be used to estimate for-

ward/reverse link

¦ No clock skew problem

Cons ¦ Need cooperation from the re-

ceiver

¦ Clock skew problem

¦ Usually cannot handle asym-

metric links

Table 5.2: Comparison of active and passive approaches

Active approach Passive approach

Pros ¦ Usually faster and more accu-

rate

¦ Estimate whenever you want

¦ Much less intrusive

¦ No need to worry firewalls

Cons ¦ Firewall may be a problem

¦ Intrusive

¦ Cannot estimate unless fore-

ground 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 per-

formance (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 5.2.

82

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

5.1.1 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 mul-

timodal 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 speak-

ing, 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

dispersion would arrive at a destination unperturbed, it will be ideal for identi-

fying 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

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.

5.1.2 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 esti-

mate 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 sup-

ported by specific routing algorithms. For example, on demand routing algo-

rithms (e.g. AODV [BP03]) as well as proactive algorithms (e.g. LANMAR and

Fisheye Routing [XHG02]) have been successfully extended to yield path capac-

ity. 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 802.11b. 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

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 increas-

ingly 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.

5.2.1 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. 5.1.

86

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 C1 on the forward direction link and capacity C2 on the back-

ward direction link. The probe packets are sent back-to-back with packet size P1

on the forward direction link (from A to B); the acknowledgement packets are

sent immediately upon receipt of probe packets with packet size P2 on the back-

ward direction link (from B to A). Suppose T1 and T2 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, T1 and T2 can then be

derived as T1 = P1

C1and T2 = P2

C2.

The dispersion measured at the end host A, denoted as T ′, is the dispersion

between back-to-back acknowledgement packets. Suppose T1 > T2, this means

that measured dispersion T ′ equates to T1. 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 T1 < T2, then T ′ reflects T2 instead, i.e. the dispersion generated

on the backward direction link prevails. Therefore,

T ′ = max(T1, T2) (5.2)

87

Table 5.3: Estimate asymmetric link capacity by varying packet sizes (ideal case

without cross traffic and any queuing delays)

Probe (P1) and ACK (P2)

Packet Size

Measured

Dispersion T ′Capacity Estimation

C′1 and C′2

P2C2

> P1C1

T ′ → T2 C′1 < C1; C′2 = C2

P2C2

< P1C1

T ′ → T1 C′1 = C1; C′2 < C2

P2C2

= P1C1

T ′ → T1 = T2 C′1 = C1; C′2 = C2

P2 = P1 T ′ → max(T1, T2) C′1 = C′2 = min(C1, C2)

By varying the packet size ratio between the probe and the ACK packets, and

observing the forward link capacity estimate (C ′1, which is P1

T ′ ) and the backward

link capacity estimation (C ′2, which is P2

T ′ ), the source node can obtain the correct

capacity estimations for both directions of the path. For instance, suppose C1 >

C2 and the initial packet size P1 = P2 , it can be concluded that T2 > T1 because

P2

C2> P1

C1. From the discussion above, the end-to-end dispersion T ′ measured

equates to T2. Therefore, C ′2 = P2

T ′ = C2 and C ′1 = P1

T ′ = C2 < C1. The estimated

capacity is the round-trip bottleneck link capacity on the asymmetric link (the

minimum value of C1 and C2), which is exactly is what CapProbe estimates as

presented in [KCL04].

However, by increasing P1 gradually, C ′2 remains equivalent to C2, but C ′

1

increases and approaches C1 gradually. When P1 increased to P2×C1

C2, C ′

1 converges

to C1 and C ′2 converges to C2. Conversely, after P1 increased to larger than P2×C1

C2

(i.e. T1 > T2, since P1

C1> P2

C2), T ′ will reflect T1. As a result, C ′

1 = P1

T ′ = C1 and

C ′2 = P2

T ′ < C2. 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

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:

Pmax and Pmin, which are chosen carefully by taking network and system issues

into account. In the first probing phase P1 and P2 are both set to Pmax. Thus

we estimate the bottleneck capacity of the round trip path. In phase 2 and 3,

(P1,P2) are set first to (Pmax,Pmin) and then to (Pmin,Pmax) 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 per-

formed 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 max-

imum ratio of packet sizes between probe and acknowledgement packets, i.e. the

max of P1

P2and P2

P1. Specifically, if both capacity estimates of the narrower direc-

tion 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 direc-

tion with higher speed, but will indicate that such condition as occurred, and

report a “lower-bound” of the capacity instead. Other one-way capacity estima-

tion tools (e.g. Pathrate) can then be applied to further measure the capacity in

this direction. The Decision phase algorithm is described in Alg. 1.

5.2.2 Simulation

In this section, we present simulation results that evaluate the accuracy of ca-

pacity estimation of AsymProbe on paths with asymmetric links. AsymProbe

89

Algorithm 1 AsymProbe Algorithm (The Decision Phase)

if C[1][1] == C[2][1] then

C1 = C[2][1]

if C[1][1] > C[3][1] then

C2 = C[3][2]

else

C2 is larger than Max(C[2][2], C[3][2])

end if

else if C[1][1] == C[3][1] then

C1 = C[3][1]

if C[1][1] > C[2][1] then

C2 = C[2][2]

else

C2 is larger than Max(C[2][2], C[3][2])

end if

else if C[1][2] == C[2][2] then

C2 = C[2][2]

if C[1][2] > C[3][2] then

C1 = C[3][1]

else

C1 is larger than Max(C[2][1], C[3][1])

end if

else if C[1][2] == C[3][2] then

C2 = C[3][2]

if C[1][2] > C[2][2] then

C1 = C[2][1]

else

C1 is larger than Max(C[2][1], C[3][1])

end if

end if 90

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 asymmet-

ric 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 down-

link 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, Pmax and Pmin, are set

to 1500 bytes and 100 bytes respectively. For the various cross traffic configura-

91

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 128 1500 1500 128 128

FTP (B → C) 128 1500 1505 128.057 128

FTP (C → B) 128.062 1500 1500 128 128

Poisson (B → C, rate=300Kbps) 128 1500 1500 128 128

Poisson (B → C, rate=750Kbps) 128 1500 1500 128 128

Poisson (B → C, rate=1500Kbps) 128 1500 1500 128 128

Poisson (C → B, rate=25.6Kbps) 128 1500 1500 128 128

Poisson (C → B, rate=64Kbps) 128.006 1500 1500 127.936 128

Poisson (C → B, rate=128Kbps) 127.988 1500 1483.143 128.039 128

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 simu-

lated scenario is 1.5Mbps/128Kbps, it is smaller than the packet size ratio Pmax

Pmin,

92

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 Pmin 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 Pmax

Pmin× CNarrowLink. In such case, one-way link capacity

estimation tools can be launched.

5.2.3 Emulator based Testbed Experiments

The testbed experiments are performed in the configuration shown in Fig. 5.4.

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 Pmax

Pmin= 1500

500= 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

beyond 3, only a lower bound can be obtained in the direction with the larger

capacity.

Table 5.5: NIST Net results on

High/Low asymmetric links (Unit:

Mbps)

Link

Capacity

AsymProbe

Estimation

CapProbe

Estima-

tion

F B F B

1 1

1.063 1.064 0.981

1.064 1.065 0.981

1.063 1.063 0.985

2 1

2.010 1.063 0.979

2.015 1.062 0.979

2.010 1.064 0.979

3 1

2.997 1.065 0.985

3.012 1.065 0.983

3.015 1.055 0.981

4 1

≥3.611 1.064 0.979

≥3.609 1.061 0.981

≥3.611 1.062 0.979

F: Forward Link; B: Backward Link

Table 5.6: NIST Net results on

Low/High asymmetric links (Unit:

Mbps)

Link

Capacity

AsymProbe

Estimation

CapProbe

Estima-

tion

F B F B

1 1

1.063 1.065 0.981

1.065 1.064 0.981

1.065 1.065 0.979

1 2

1.064 2.015 0.979

1.062 2.010 0.975

1.006 1.989 0.981

1 3

1.062 2.997 0.983

1.063 3.018 0.985

1.056 2.997 0.981

1 4

1.059 ≥3.610 0.981

1.065 ≥3.610 0.979

1.065 ≥3.611 0.979

F: Forward Link; B: Backward Link

5.2.4 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

Table 5.7: Internet results on asymmetric link

Link

Claimed Capacity Estimated Capacity

Down Up # Down Up

DSL 1 1.5 Mbps 128 Kbps

1 ≥ 379 Kbps 132 Kbps

2 ≥ 382 Kbps 132 Kbps

3 ≥ 380 Kbps 132 Kbps

DSL 2 3 Mbps 512 Kbps

1 ≥ 1.49 Mbps 565 Kbps

2 ≥ 1.53 Mbps 567 Kbps

3 ≥ 1.51 Mbps 558 Kbps

Cable Modem 3 Mbps 256 Kbps

1 ≥ 721 Kbps 247 Kbps

2 ≥ 730 Kbps 255 Kbps

3 ≥ 723 Kbps 248 Kbps

this set of experiments, again we have Pmax

Pmin= 1500

500= 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.

5.2.5 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

1DSL 1 is provided by Verizon: http://www.verizon.com; DSL 2 is provided by Hinet:http://www.hinet.net

2Cable Modem is provided by Comcast: http://www.comcast.com

95

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 CapProbe-

based 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

Table 5.8: Required time resolution for accurate estimation

Packet Size

Narrow Link Capacity

1 Gbps 100 Mbps 10 Mbps 1 Mbps

100 bytes 0.0008 ms 0.008 ms 0.08 ms 0.8 ms

500 bytes 0.004 ms 0.04 ms 0.4 ms 4 ms

1000 bytes 0.008 ms 0.08 ms 0.8 ms 8 ms

1500 bytes 0.012 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

5.3 Measuring End-to-end Capacity in Wireless Ad Hoc

Networks

With the increasing deployment of wireless devices (e.g. laptops, PDAs, cell-

phones, 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 ca-

pacity, 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 des-

tinations helps the sources and proxies adapt the audio/video streaming rates to

match user capacities and provide better quality of services. A simple and ac-

curate 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 “avail-

able” 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 In-

ternet. Finally, the estimation must be non-intrusive so that it will not disturb

the ongoing applications traffic in the network.

98

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 “nar-

row” 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 ac-

count 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.

5.3.1 AdHoc Probe

AdHoc Probe is based on CapProbe, a well-proved bottleneck link capacity esti-

mation 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

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.

5.3.1.1 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 in-

tends 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 applica-

tions 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 in-

cluding multihopping, unique features of wireless networks (e.g. RTS/CTS mech-

anism), 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 round-

trip 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

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

Apart from the number of samples, N , the latency of the estimate also de-

pends 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 sec-

onds. 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 ongo-

ing 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.

5.3.1.2 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

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 Tsend,i, and

the receiving times (on the receiver) are Trecv1,i for the first packet and Trecv2,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 = (Trecv1,i − Tsend,i) + (Trecv2,i − Tsend,i) (5.3)

Si = (Trecv1,i − Tsend,i − δ) + (Trecv2,i − Tsend,i − δ) = S ′i − 2δ (5.4)

Thus the difference between Si and S ′i is a constant 2δ for all packet pairs.

If Sk = mini=1...n Si for k ∈ [1...n], then S ′k = mini=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 com-

puted 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.

5.3.1.3 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

Figure 5.6: Illustration of clock skew problem in OWD sum measurements

to the other using 802.11b. The relative OWD (i.e. OWDi−OWD1 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.

5.3.2 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 ca-

pacity, 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

Probe indeed estimates such rate.

We recall that the effective end-to-end rate is defined as the maximum achiev-

able 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 802.11b 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 equation3:

C =S

S + 40 + 39 + 47× CP (5.5)

where S is size of the network layer packet (including IP header), and CP 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

is at most 15001500+40+39+47

× 2 ≈ 1.8 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

3We assume physical layer overhead, such as preamble, header and idle time (IFS), arenegligible

105

Figure 5.7: The chain topology, where the solid-line circle denotes a node’s effec-

tive 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. 5.7. 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

interference range (marked by a dotted-line circle) is 550 meters, a packet trans-

mission 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.

5.3.3 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 imi-

tate the Lucent WaveLan card at 2Mbps, with the effective transmission range

107

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 sta-

tionary during the simulations, and all simulated data packets are preceded by

an RTS/CTS exchange, in accordance with the 802.11 standards. Adhoc probe is

implemented in ns-2 and used to estimate the end-to-end path capacity in various

wireless network configurations.

5.3.3.1 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.

5.8.

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 one-

hop wireless link scenario. Wireless contention and backoff resulting from packet

108

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.

5.3.3.2 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. 5.7. The transmission range

(marked by solid-line circle) of an 802.11 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. 5.9. As expected, the estimate value increases as

the packet size increases, consistent with the analytical results from Eq. 5.5.

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 400∼500 Kbps. It is approximately 1/4 of the single cell

capacity, close to the analytical results of 15001500+40+39+47

× 2 × 14≈ 450kbps as

discussed earlier.

With the same wireless network configuration as specified in [LBC01], AdHoc

109

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 esti-

mate 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 evalu-

ating 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

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 dis-

cover. 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.

5.3.3.3 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

5.3.2. 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. 5.10 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).

5.3.3.4 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. 5.11. Nodes

are placed 200 meters away from their horizontal and vertical neighbors. Radio

111

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. 5.12

and Fig. 5.13 show the respective path capacity estimates.

112

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. 5.12 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

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. 5.13 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 prop-

erty 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!

5.3.3.5 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 break-

age and path reestablishment. Fig. 5.14 depicts the scenario where the AdHoc

Probe sender and receiver are fixed, and the intermediate forwarding hosts are

114

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. 5.15.

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

Figure 5.15: AdHoc Probe capacity estimates (average of 200 runs and the stan-

dard deviation) in fixed source/destination and mobile intermediate nodes simu-

lation scenario.

5.3.3.6 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. 5.16 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

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 1500 × 8 × 2 × 4 = 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. 5.17.

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. 5.17 match the results of the chain topology in zero

load reported in Fig. 5.9.

When node 25 moves away from its initial position (100,100) towards its first

117

Figure 5.17: Capacity estimation of MANET scenario (with and w/o cross traf-

fic).

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.

5.3.4 Capacity estimation with Auto Rate Modems

5.3.4.1 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 trans-

mission 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

to save energy [QCJ03].

Several auto rate schemes have been proposed to exploit the multi-rate ca-

pability. They can be categorized into two types: Adaptive Rate schemes (e.g.

ARF [KM97], RBAR [HVB01], and AARF [LMT04]) and Opportunistic Schedul-

ing 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

Figure 5.18: Illustration of 802.11, 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 802.11 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 effec-

tive 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 Con-

catenation (PAC) scheme to further eliminate the ACK packets among multiple

data packets in OAR. Fig. 5.18 illustrates the MAC layer interactions of the

original 802.11 scheme, OAR scheme, and the PAC scheme. Again, since OAR

and PAC need to modify 802.11 RTS/CTS and DATA/ACK exchanges, they are

not compatible with the existing 802.11 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

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

802.11b MAC is adapted among 2, 5.5 and 11Mbps.

5.3.4.2 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. 5.19 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

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 de-

vices. We defer the discussion on interference-triggered rate adaptation to the

testbed experiment section.

5.3.5 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 802.11b links to Bluetooth interference. The experiment results

are presented below.

122

Figure 5.20: Experiment results of AdHoc Probe on wireless multihop testbed

(transmission rate is 2Mbps on each link)

5.3.5.1 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 802.11b laptops about 70 ∼ 80 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. 5.20.

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

Figure 5.21: Experiment results of 802.11b one hop connection (auto rate) with

different distance between two hosts

5.3.5.2 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.

5.21.

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

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 ef-

fective capacity of ∼1Mbps, which again, corresponds to 1Mbps modem rate. The

experimental results thus confirm the relationship between source-destination dis-

tance and path capacity as discussed in section 5.3.4.2.

5.3.5.3 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 802.11b path interfered

by Bluetooth. Fig. 5.22 illustrates the testbed configuration. Two 802.11b

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 802.11 receiver. The Bluetooth pair is placed at a

varying distance from the 802.11 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 802.11b use the same radio frequency band

(i.e. 2.4GHz), they interfere with each other, and the link quality of the 802.11b

connection degrades. As a result, the 802.11b 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

Figure 5.22: Auto Rate 802.11b Testbed with Bluetooth interference

Figure 5.23: Experiment results of 802.11b with auto rate and with Bluetooth

interference from varying distance

and standard deviation of the capacity estimates are presented below in Fig. 5.23.

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

5.3.5.4 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 5.3.5.1, 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. 5.24 shows the

experiment results.

From the results, AdHoc Probe measures 98Mbps capacity on the wired seg-

ment (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 bot-

tleneck shifts to the ad hoc network and AdHoc Probe measures path capacity

consistent with the results in subsection 5.3.5.1. 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

Figure 5.24: Experiment results of estimating capacity from Internet to ad hoc

networks

5.3.6 Conclusion

In this study, we have reviewed the definition of “path capacity” in ad hoc wire-

less 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 spe-

cific 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

The results showed that AdHoc Probe is able to accurately measure path capac-

ity 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

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. Ad-

ditive 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 ac-

cording to a TCP Reno-based equation [PFT98] to mimic the behavior of TCP

congestion control.

130

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 802.11b 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, Aggrega-

tion, 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 net-

work 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

6.1 Passive Capacity Estimation

6.1.1 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 proto-

col [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 transfer-

ring operations involving asymmetric links. Since information traffic on asym-

metric links such ADSL are usually ten times more intensive on forward direc-

tion link (download) as oppose to reverse direction link (upload) (e.g. video

streaming and file downloading), the ability to appropriately establish the upper-

bound 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.

6.1.1.1 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

of sending rate [FHP00]:

T =s

R√

2p3

+ tRTO

(3√

3p8

)p (1 + 32p2)

(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 tRTO.

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 tRTO. The sender

is also responsible for adjusting its sending rate Tactual 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

6.1.1.2 Proposed Approach: TFRC Probe

TFRC probe is a passive capacity monitoring technique realized through embed-

ding 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 origi-

nal 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 esti-

mation 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

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 CapProbe-

based 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-to-

back sampling packets are time-stamped with the sending time (T0) of the

135

corresponding packet pair. Upon receiving the sampling packets, TFRC

Probe receiver measures the one-way delay of each packet in the packet

pair (T1 and T2) by subtracting T0 from its respective receiving time. The

dispersion (T2 - T1) and delay sum (T2 + T1) 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 (T1 and T2) may not exactly repre-

sent 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 sam-

pling 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 capac-

ity monitoring tool should promptly ”capture” each capacity change event

when it occurs (e.g. adaptation of transmission modes on the 802.11b 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

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 specifi-

cally, suppose Rsend 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).

Rsend × t = n× S × P × 8 (6.2)

=⇒ P =Rsend × 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 Rsend 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 Rsend 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

Figure 6.2: Simulation Scenario

6.1.1.3 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 exam-

ine 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

Table 6.1: Types of cross traffic

Cross Traffic Description

Type I 4 FTP flows (from node 7 to 10, 8 to 9, 11 to 14, and 12

to 13); 1500 bytes/packet

Type II 4 CBR flows (from node 7 to 10, 8 to 9, 11 to 14, and 12

to 13); 500 bytes/packet; 80% load on the bottleneck

Type III 16 Pareto flows with alpha = 1.9 (4 flows from node 7

to 10, 4 flows from 8 to 9, 4 flows from 11 to 14, and 4

flows from 12 to 13); 1000 bytes/packet; 80% load on the

bottleneck

summarized the results in Table 6.2 below.

From the results, TFRC Probe shows high accuracy in all the test cases,

regardless of different types of cross traffic. It is also evident that accurate esti-

mation can be achieved with merely 20 packet samples for all of the scenarios.

While CapProbe measures the round-trip capacity of a link, TFRC probe is spe-

cialized to measure the forward link capacity. Again, it should be emphasized

that capacity information conveyed by the forward link is critical for most data

transferring protocols (e.g. video streaming and file downloading) in setting the

appropriate upper-bound for their sending rates. This is especially true for proto-

col operating on asymmetric links such as ADSL. The simulation results indicate

that the proposed TFRC Probe approach is beneficial for such purposes.

6.1.1.4 Experiments w/o Packet Size Adaptation

The first set of experiment evaluates the accuracy of TFRC probe on wired links of

different connecting technology, which is followed by a set experiment on wireless

139

Table 6.2: Simulation results of TFRC Probe/CapProbe capacity estimation

TFRC Probe / CapProbe

no cross 20 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

traffic 50 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

cross traffic 20 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

type I 50 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

cross traffic 20 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

type II 50 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

cross traffic 20 samples 100K / 100K 500K / 100K 1M / 100K 5M / 100K

type III 50 samples 100K /100K 500K / 100K 1M / 100K 5M / 100K

bottleneck capacity of the

backward direction link

100Kbps 100Kbps 100Kbps 100Kbps

bottleneck capacity of the

forward direction link

100Kbps 500Kbps 1Mbps 5Mbps

scenarios. For these experiments, the adaptive packet size feature is temporarily

disabled to allow validation of TFRC probe functionality. The link connections

tested were: 100Mbps Ethernet, 2M/128Kbps DSL, 802.11b (11, 5.5, 2, and 1

Mbps transmission modes), and 1xRTT (150Kbps). The DSL DownLink is esti-

mated by hosting the TFRC Probe sender on the Internet and the receiver behind

the DSL link; whereas the DSL UpLink is estimated by hosting the TFRC Probe

sender behind the DSL link and the receiver on the Internet. The probing packet

size is fixed at 1000 bytes for each experiment, which is repeated five times for

each link. Table 6.3 and Table 6.4 shows the experiment results (estimated ca-

pacity and required time for completion) after collecting 20, 50, and 100 samples.

From the results, TFRC Probe were able to estimates the capacity accurately

and rapidly (in terms of number of samples). Specifically, TFRC Probe is able to

140

Table 6.3: Capacity estimation of TFRC Probe on the wired links of different

technologies (Capacity: Mbps, Time: second)

Run 1 Run 2 Run 3 Run 4 Run 5

CapacityTimeCapacityTimeCapacityTimeCapacityTimeCapacityTime

Ethernet (100Mbps)

20 samples 92.18 5.5 94.92 5.5 94.25 5.6 107.99 5.5 94.07 5.6

50 samples 98.17 5.8 104.31 5.7 94.25 5.9 94.02 5.7 94.07 5.8

100 samples 98.17 6.1 104.31 6.0 94.25 6.2 94.02 6.1 94.07 6.2

DSL DownLink (2Mbps)

20 samples 1.982 7.0 1.807 8.6 1.710 8.8 1.782 6.7 1.835 6.7

50 samples 1.982 12.7 1.865 12.4 1.835 12.6 2.145 12.6 1.652 10.5

100 samples 1.982 20.9 1.865 18.9 1.835 18.9 2.145 19.0 1.652 16.9

DSL UpLink (128Kbps)

20 samples 0.114 70.9 0.122 69.5 0.115 72.7 0.110 81.5 0.119 71.4

50 samples 0.114 145.0 0.122 137.6 0.115 146.0 0.115 147.5 0.112 142.3

100 samples 0.115 265.6 0.122 258.5 0.119 258.6 0.115 266.0 0.112 257.5

measure the bottleneck capacity within 20 samples and within 10% of the actual

values in almost all experiments. Note that the effective capacity of 802.11b is

usually smaller than the physical channel capacity due to the MAC layer over-

head (e.g. RTS/CTS packets and CSMA/CA mechanisms). Compared with the

CapProbe results reported in [KCL04], TFRC Probe measures the capacity of the

forward direction link; whereas CapProbe always measures the UpLink capacity

of the DSL link since it relies on the ”round-trip” based estimation.

The results also show that the speed of capacity estimation is highly related

to the link capacity. For instance, while estimating capacity of the 100Mbps

Ethernet link, it takes only 5.5 seconds to obtain 20 samples in the experiments;

whereas, while it took 70 seconds to estimate the 128Kbps DSL UpLink. It

is obviously desirable to speed up the estimation process in order to perform

141

Table 6.4: Capacity estimation of TFRC Probe on the wireless links of different

technologies (Capacity: Mbps, Time: second)

Run 1 Run 2 Run 3 Run 4 Run 5

CapacityTimeCapacityTimeCapacityTimeCapacityTimeCapacityTime

1xRTT (150Kbps)

20 samples 0.186 115.9 0.187 87.1 0.186 68.3 0.140 116.0 0.186 61.6

50 samples 0.140 156.4 0.140 122.3 0.187 113.2 0.140 188.5 0.140 113.1

100 samples 0.140 230.0 0.140 182.9 0.140 187.0 0.140 286.8 0.140 212.3

802.11b (1Mbps)

20 samples 0.65 17.0 0.91 17.8 0.85 18.7 0.94 17.7 0.92 17.9

50 samples 0.93 25.6 0.93 27.8 0.91 28.2 0.94 26.3 0.93 27.8

100 samples 0.91 39.6 0.93 41.6 0.91 42.6 0.92 41.2 0.93 42.3

802.11b (2Mbps)

20 samples 1.48 16.7 1.80 16.8 1.81 16.9 1.77 17.9 1.80 18.0

50 samples 1.48 21.8 1.74 21.2 1.68 21.6 1.09 23.9 1.69 23.5

100 samples 1.49 29.1 1.47 29.6 1.80 29.8 1.72 32.3 1.73 32.5

802.11b (5.5Mbps)

20 samples 3.73 14.8 3.86 15.3 4.36 14.9 3.83 15.1 4.45 14.6

50 samples 4.18 18.4 3.86 19.7 3.80 19.5 4.06 19.3 3.87 18.6

100 samples 4.18 23.2 3.92 24.4 3.80 24.0 4.06 24.0 3.87 22.8

802.11b (11Mbps)

20 samples 8.09 7.6 7.60 7.5 7.91 7.5 7.00 7.6 6.26 7.9

50 samples 8.09 9.0 7.60 10.1 6.23 9.6 7.00 10.2 6.26 10.2

100 samples 7.84 12.7 7.60 11.8 6.23 11.6 6.60 12.0 6.26 11.9

efficient ”monitoring” task and to provide ”up-to-date” information. The packet

size adaptation feature is thus necessary, and its effect will be evaluated in the

next subsection.

142

Figure 6.3: Capacity monitoring of 802.11b connection using TFRC Probe

6.1.1.5 Experiments w/ Packet Size Adaptation

Figure 6.3 depicts the experiment results of 802.11b capacity monitoring. The

experiment testbed is created on a Linux based system, and the 802.11b transmis-

sion mode is manually changed with ’iwconfig ’ command. During the experiment

the transmission mode is set to 2, 5.5, 11, 5.5, and 2 Mbps mode at times 50,

100, 150, 200, 250second. The packet size adaptation feature of TFRC Probe is

enabled in the experiments; thus, the packet size is now a function of the TFRC

Probe sending rate, number of data packets between two samples (n, which is

set to 20), number of samples for each estimation (S, which is set to 20), and

expected time for each estimation (t, which is set to 5 second) according to Eq.

(6.3).

The estimated capacities illustrated by Fig. 6.3 are very consistent and closely

matches the effective 802.11b capacities for most of the reported values. There

are some inaccurate results reported from the experiment, several over estimation

143

of capacity were reported at around 250th second, and under estimation of capac-

ity were reported around 205th second. These estimation inaccuracies are likely

influenced by the dynamic nature of the wireless channel. The estimation accu-

racy can be improved by simply increase the number of required samples for each

estimation (S); however, it might decrease the estimation speed in accordance to

Eq. (6.2).

Figure 6.3 also shows the adaptation of TFRC Probe packet size, as expressed

in Eq. (6.3). It is evident that the packet size of TFRC probe increases when

the sending rate increases and decreases when the sending rate decreases. While

operating at 5.5 and 11 Mbps modes, the packet size remained stalled due to the

maximum packet size setting (1500 bytes) in our implementation.

6.1.2 TCP Probe: Passive Capacity Estimation within TCP

TCP is the most prevalent transport protocol on the Internet. Some TCP vari-

ants (e.g. TCP Westwood [GNS04]) have attempted to approximately estimate

the link capacity in order to enhance congestion control. For instance, TCP

Westwood approximates the link capacity by measuring and averaging the rate,

called BE, of returning ACKs, as shown in Fig. 6.4. However, as we will show

later on, BE is not accurate in many cases. As a result, an accurate, passive

capacity estimation within TCP is still not available.

6.1.2.1 TCP Probe

We propose TCP Probe as a passive capacity estimation extension embedded

within TCP and based on the recently introduced CapProbe technique [KCL04].

The key design principle of such an extension is simplicity, i.e. changes to the

existing TCP protocol must be minimal and preferably sender-side only. More-

144

Figure 6.4: TCP Westwood Bandwidth Estimate (BE)

over, the extension needs to be applicable to any existing TCP variant. We call

this extension TCP Probe hereafter.

The basic principle of CapProbe is to send a pair of packets back to back from

the source to destination. The pair is then immediately returned to the source.

The source measures the delay of each packet as well as the inter-packet interval

(often referred to as “dispersion”). This experiment is run for many packet pair

samples. The source monitors the sum of the packet pair delays. When the

sum is minimum (over a sufficiently large number of samples), the corresponding

pair yields the path capacity C estimate. Namely C = packet size/delay interval

[KCL04].

In order to mimic CapProbe, TCP Probe must send a portion of the data

packets back-to-back as packet pair samples. Fortunately TCP automatically

does send some back-to-back data packets, mostly in Slow Start and also some-

times in Congestion Avoidance, upon receipt of an ACK packet. These instances

are often sufficient to produce an adequate number of back to back samples. If

more frequent samples are required, a duplicate packet can be injected by the

source after a data packet at the expense of extra traffic. The packets in the

pair are ACKed separately. Once the two ACKs of the packet pair are received

145

Figure 6.5: (a) back-to-back TCP packets generate only one ACK because of

DelACK; (b) inverted back-to-back TCP Probe packets are separately acknowl-

edged.

by the TCP sender, the dispersion information can be used to estimate the path

capacity using the previously mentioned CapProbe approach.

However, in order to confine the modifications required in TCP Probe to

the sender-side only, and require no change at the TCP receiver, two problems

must be solved. One of them is the widely deployed “Delayed ACK” (DelACK)

[Bra89], and the other is different sizes of TCP data packets and ACKs.

DelACK has been popularly deployed on most of the Internet hosts. A TCP

receiver with DelACK installed will acknowledge the received data on every other

data packet. Therefore if two TCP data packets i and i+1 are sent back-to-back

from the sender, either packet i or i + 1 will be acknowledged, as shown in Fig.

6.5-a.

The problem caused by DelACK can be solved by the “inverted packet-pair”

technique. More specifically, when TCP needs to send back-to-back data packets

with sequence numbers i and i + 1, it swaps the sending order, i.e., packet ‘i + 1’

is sent before packet ‘i’. This swapped sending order will generate back-to-back

146

ACKs on sequence numbers i−1 and i+1. The DelACK receiver is, thus, forced

to send an individual ACK for each data packet, as shown in Fig. 6.5-b. Note

that this enhancement is applicable to all TCP variants.

The second problem stems from the fact that data and ACK packet sizes are

different. Clearly, the TCP receiver cannot enlarge the ACK packet size to make

it equal to data packet size. Thus, the difference of TCP data and ACK packet

sizes does not comply with the original CapProbe algorithm assumption, where

the packet pair sizes in the forward and backward direction are equal. As a result,

the CapProbe equation C = P/T may not hold in our case.

A related problem has been addressed in [CSY05], where we have extended

CapProbe to estimate asymmetric link capacity by varying the probing packet

sizes on the two directions of the path. Specifically, suppose the bottleneck link

capacities of the forward and backward direction links are C1 and C2, and the

probing packet sizes on the forward and backward links are P1 and P2, AsymProbe

is capable to measure the forward link capacity (C1) when P1

P2> C1

C2and measure

the backward link capacity when P1

P2< C1

C2.

Since the size of TCP data and ACK packets are fixed (namely 1500 bytes

and 40 bytes, including IP header, respectively), TCP Probe thus measures the

forward link capacity when C1

C2< 1500

40= 37.5 or the backward link capacity when

C1

C2> 37.5. To the best of our knowledge, most of current Internet links are

either symmetric or moderately asymmetric with a link capacity ratio smaller

than 37.5 (e.g. the down/up link capacities are 1.5Mbps/512Kbps for DSL and

3Mbps/1Mbps for Cable1) Therefore, TCP Probe is able to correctly estimate

forward link capacity on most Internet connections.

1The Down/Up link capacities vary by ISPs and areas.

147

6.1.2.2 Simulation

In this section, we present simulation results that evaluate the accuracy and

speed of TCP Probe capacity estimation using NS-2 simulator [NS2]. Fig. 6.6

and 6.7 depict the simulation scenarios, where one TCP Probe flow (i.e. FTP

downloadind) is initiated from node s to e, and 16 cross traffic flows are generated

to share the bottleneck link (between node 2 and 3) of 4Mbps capacity. In scenario

I (as shown in Fig. 6.6), the 16 cross traffic flows are all in the forward direction

(i.e. 4 flows are from node 5 to 8, 4 flows are from node 6 to 7, 4 flows are from

node 9 to 12, and the other flows are from node 10 to 11); whereas in scenario II

(as shown in Fig. 6.7), 8 of them are in the reverse direction (i.e. 4 flows are from

node 12 to 9, and 4 flows are from node 11 to 10). The 16 cross traffic flows are

Pareto flows with different loads. The α parameter of each Pareto flow is set to

1.9 to simulate the long range dependent (LRD) traffic [TWS97]. The simulation

results are shown in Table 6.5.

From the simulation results, it is clear that TCP Probe correctly estimated the

link capacity (i.e. 4Mbps) with traffic load from 50% to 100% in both scenarios.

To evaluate the speed of TCP Probe estimation, we observe the ratio of TCP

Probe samples (i.e. back-to-back TCP packets, denoted as Fb2b) and the ratio

of good samples among all samples (denoted as Fmin). The results show that

Fb2b is always within 20% ∼ 40% range, and Fmin decreases as the load increases.

In other words, regardless of cross traffic loads, around 1/3 of TCP packets are

always sent back-to-back and could be used as probing samples for TCP Probe.

However, the probability of getting good samples decreases as the cross traffic

loads increase. We denote N as the expected number of samples for obtaining

one good sample in TCP Probe, thus N is given by Eq. 6.4. Table 6.6 show

expected N of scenario I and II with different cross traffic loads.

148

Figure 6.6: TCP Probe simulation scenario I (cross traffic flows are all in forward

direction).

Figure 6.7: TCP Probe simulation scenario II (cross traffic flows are in both

forward and reverse direction).

N =1

Fb2bFmin

(6.4)

6.2 Proposed Approach - I: Implicit Handoff Notification

The primary goal of the AIMD algorithm is to maintain stability, inter-protocol

friendliness, and intra-protocol fairness when adjusting the effective sending rate.

As a result, AIMD schemes often probe conservatively for additional available

bandwidth and are suitable only when bandwidth changes are slight. When the

bandwidth change is drastic (e.g. caused by vertical handoffs to faster link tech-

149

Table 6.5: TCP Probe simulation results of scenario I and II (Fb2b: ratio of

back-to-back packets among TCP packets; Fmin: ratio of good samples among

back-to-back TCP packets)

Capacity Fb2b Fmin

I II I II I II

50% load 4Mbps 4Mbps 35.85% 28.41% 16.09% 13.74%

60% load 4Mbps 4Mbps 40.98% 27.41% 12.42% 9.58%

70% load 4Mbps 4Mbps 40.77% 29.35% 9.04% 7.47%

80% load 4Mbps 4Mbps 35.55% 33.06% 6.40% 4.52%

90% load 4Mbps 4Mbps 28.99% 35.59% 3.72% 3.23%

100% load 4Mbps 4Mbps 20.96% 39.19% 3.37% 3.47%

Table 6.6: The required number of TCP packets (N) for obtaining one good

sample in TCP Probe.

Scenario I Scenario II

50% load 18 26

60% load 20 39

70% load 28 46

80% load 44 67

90% load 93 88

100% load 142 74

nology), AIMD does not adapt fast enough to match the suddenly materialized

bandwidth. Recent studies have indicated that a highly agile system may not be

150

possible unless handoff notification is implemented [GK04].

Fortunately, with the passive capacity monitoring techniques (i.e. TFRC

Probe and TCP Probe), implicit handoff notifications (IHN) can be carried out

by continuously estimating the link capacity. Suppose the most recent capacity

estimate is C ′ and its previous estimate is C, a vertical handoff is identified when

either C ′ > αC (LOW-to-HIGH handoff) or C ′ < βC (HIGH-to-LOW), where α

and β are two positive constants of threshold. For simplicity, we set α = 5 and

β = 0.2 throughout this study.

Once a drastic capacity change is observed, an IHN can be triggered to notify

the ongoing applications to perform appropriate service adaptations. If the ver-

tical handoff is LOW-to-HIGH, we propose the “Fast Rate Adaptation” (FRA)

algorithm to aggressively take advantage of the dramatic capacity increase. More

specifically, FRA forces TCP/TFRC Probe to enter the slow start2 phase and

probe the new link exponentially, rather than staying in congestion avoidance3

with linear probing. FRA is able to help TCP/TFRC Probe achieve a higher

throughput and better network utilization, especially when the capacity increase

is large.

Additionally, when multiple data copies (e.g. video of different bit rates)

are available on the server, the FRA algorithm should switch the ongoing data

delivery to the higher quality data when it is possible. For instance, if two versions

of stream video (say, 192kbps and 512kbps bit rates) are available on the video

server, the FRA algorithm should switch the delivering data from the 192kbps

version to the 512kbps version when the sending rate is increased larger than

2In TFRC [FHP00], there is a slow start phase, during which the TFRC sender doubles thesending rate every RTT (i.e. exponentially) until the first packet loss occurs. After the firstpacket loss, TFRC sets its sending rate to half of the current rate and thereafter adjusts itsrate based on the TCP response function.

3By congestion avoidance, in TFRC, we mean the TFRC sender adapts the rate based onthe TCP response function.

151

512kbps. Therefore, the user-perceived stream quality can be greatly improved.

However, when the vertical handoff is HIGH-to-LOW, and assuming it re-

sults in a significant reduction in path capacity, most of the outstanding packets

(transmitted but not yet received) will be lost. Ideally, in this case, a handoff

notification is sent slightly before the handoff actually occurs, which IHN is not

capable of doing. We will present a solution for this scenario in the next section.

6.3 Proposed Approach - II: Explicit Handoff Notification

For mobile systems incorporating an intelligent handoff manager, we propose

Explicit Handoff Notification (EHN) to provide agile accommodations to vertical

handoffs. With an intelligent handoff manager, such as the Smart Decision Model

presented in [CSC04a], the decision on which network interface to use can be

made in advance by considering user preferences as well as network parameters

(e.g. link capacity, power consumption, remaining battery power, etc [CSC04a,

WKG99]). The intelligent handoff manager automatically monitors the various

physical link qualities, and triggers handoff event when appropriate. EHN gives

advance handoff notifications to ongoing upper layer applications, allowing them

to adjust faster to drastic changes in link capacity.

If EHN is deployed in a mobile system, it can be used in fact in both High-to-

Low and Low-to-High handoffs. In case of Low-to-High handoff, upon receiving

an EHN, the sender launches the FRA algorithm, enabling TCP/TFRC Probe

to promptly utilize the newly materialized capacity. Since EHN is an explicit

notification of a handoff event, FRA algorithm can be launched almost immedi-

ately after the EHN is received. IHN, on the other hand, depends on the speed

of capacity estimation to determine when handoff events have occurred, possibly

152

causing some delay in launching the FRA algorithm. EHN can be expected to

achieve a higher data throughput due to its faster reaction to vertical handoffs.

For HIGH-to-LOW vertical handoff events, we propose the Early Rate Reduc-

tion (ERR) algorithm to appropriately slow down the TFRC/TCP Probe sending

rate before the actual vertical handoff event. More specifically, ERR slows down

the TFRC/TCP Probe sending rate one OWD (one-way delay) before the handoff

event takes place, reducing the amount of outstanding data packets that would be

lost in the wireless portion of the path. To illustrate this concept, suppose a verti-

cal handoff changes the capacity from C1 to C2 (where C1 > C2). Let the original

TFRC Probe sending rate be R, and suppose the EHN is triggered one OWD be-

fore the actual handoff. The ERR algorithm first reduces the TFRC/TCP Probe

sending rate from R to RC2/C1 (one OWD before the actual handoff), allowing

the delivery of the outstanding packets before switching to a slower network in-

terface. By the time the vertical handoff event actually occurs, the mobile host

will already be sending at an adjusted rate RC2/C1, therefore avoiding potential

bulk packet losses. Fig. 6.8 illustrates the ERR algorithm, the shaded region

depicts the amount of outstanding data that is salvaged by employing the ERR

algorithm.

Note that, for real-time streaming applications, the ERR algorithm should

also reduce the data bit rate (e.g. switch to the lower bit-rate video or perform

real-time transcoding) so that the user-perceived stream quality can be largely

preserved (i.e. reducing the delay of real-time streaming). It should also be

mentioned that the EHN scheme applies exclusively to mobile hosts equipped with

the intelligent handoff manager. Moreover, EHN is designed for the wireless last-

hop scenarios. Therefore, EHN is not directly applicable to multi-hop networks

that conduct vertical handoffs on intermediate nodes.

153

Figure 6.8: Illustration of the ERR algorithm for TCP/TFRC Probe

6.4 Evaluation

In this section, we present simulation results to evaluate the performance of

service agility using TCP/TFRC Probe. Both IHN and EHN were implemented

in the NS-2 simulator [NS2]. IHN is triggered once a drastic capacity increase was

observed from passive capacity monitoring; while EHN was explicitly triggered

prior to a handoff event (i.e. assuming the intelligent handoff manager is given,

and the EHN is sent directly to TCP/TFRC applications). Moreover, the FRA

algorithm was implemented to utilize the increased capacity more aggressively

after a LOW-to-HIGH vertical handoff, and the ERR algorithm was launched

when an EHN of drastic capacity reduction was received for an imminent HIGH-

to-LOW handoff.

Fig. 6.9 illustrates the simulation setup. All links except the one between

node 5 and node 6 belonged to the wired Internet segment and had a capacity

of 100 Mbps each. Node 5 and node 6 were connected via a wireless link, with

a capacity of either 150 Kbps (1xRTT) or 5 Mbps (802.11b). One application

flow (TCP or TFRC) was initiated from node 1 to node 6, such that the wireless

link became the last hop. 16 Pareto distributed flows (with the parameter alpha

154

Figure 6.9: Simulation scenario

= 1.9, and the total rate of 25Mbps) were created from node 7 to node 10 (4

flows), from node 8 to node 9 (4 flows), from node 11 to node 14 (4 flows), and

from node 12 to node 13 (4 flows). These Pareto flows represented the long range

dependent (LRD) traffic observed on the Internet [TWS97].

During the 1200-second simulation, a vertical handoff event was generated at

the 600th second on the last hop (i.e. the link between node 5 and node 6). We

now present the simulation results of the LOW-to-HIGH handoff in subsection

6.4.1 and those of the HIGH-to-LOW handoff in subsection 6.4.2.

6.4.1 Vertical handoff from LOW to HIGH

6.4.1.1 TFRC Probe

We first study the performance of FRA and IHN/EHN in the context of TFRC

Probe when the handoff is LOW-to-HIGH. Three TFRC Probe variants, namely

the original TFRC Probe, TFRC Probe with IHN+FRA and TFRC Probe with

EHN+FRA, are compared in Fig. 6.10. Note that there existed a lag of approx-

imately 15 seconds between the moment of handoff and its detection by IHN in

TFRC Probe, after which TFRC Probe with IHN+FRA was able to enter slow

155

start and increase its sending rate faster than the original TFRC Probe (see Fig.

6.10-a). On the other hand, EHN was able to foresee the handoff right before it

actually occurred (at the 600th second), so TFRC Probe with EHN+FRA entered

slow start and increased the rate 15 seconds earlier. Both advanced TFRC Probe

variants managed to utilize the increased capacity after handoff more efficiently,

in terms of the sending rate (Fig. 6.10-a) and throughput (Fig. 6.10-b), than the

original TFRC Probe. At the same time they exited the slow start phase quickly

and continued in congestion avoidance without incurring any congestion.

6.4.1.2 TCP Probe

We then look at how FRA and IHN/EHN perform in TCP Probe. The simu-

lation results, shown in Fig. 6.11, are similar to those with TFRC Probe. The

two advanced TCP Probe variants, equipped with FRA+IHN and FRA+EHN

respectively, were able to enter slow start and increase the window exponentially

when the handoff was detected (IHN lagged behind EHN by 5 seconds in this

case). In contrast, the original TCP Probe stayed in congestion avoidance and

increased its window slowly (Fig. 6.11-a). Fig. 6.11-b shows that the throughput

of TCP Probe with FRA+IHN or FRA+EHN was significantly higher than the

original scheme lacking awareness of the vertical handoff.

6.4.2 Vertical handoff from HIGH to LOW

We have discussed earlier in this paper that when the vertical handoff is HIGH-to-

LOW, IHN cannot detect it in a timely manner; a significant amount of packets

will get lost before the sender reduces its sending rate. Therefore, we did not

simulate IHN in this scenario. Instead we focused on EHN and assessed the

efficacy of ERR in reducing the number of lost packets during the handoff.

156

(a) TFRC sending rate

(b) TFRC packet sequence number

Figure 6.10: 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).

Fig. 6.12 presents the comparison of three TFRC Probe variants. In addition

to the original TFRC Probe with no handoff notification, there were two advanced

variants of TFRC Probe with EHN: EHN(a): EHN was generated when the

handoff occurred, i.e. without ERR; and EHN(b): EHN was generated one OWD

157

(a) TCP congestion window size

(b) TCP packet sequence number

Figure 6.11: 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).

before the handoff, i.e. with ERR.

As Fig. 6.12-a shows, TFRC Probe with EHN(a) and EHN(b) both reduced

the sending rate more drastically than the original TFRC Probe when the handoff

occurred. They also experienced a second rate cut as the original TFRC Probe

158

(a) TFRC sending rate

(b) TFRC packet sequence number

Figure 6.12: 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).

did, but the time between rate cuts was accordingly prolonged. Finally all TFRC

Probe variants had their sending rate converged to the new last-hop capacity (150

kbps) and entered congestion avoidance.

Fig. 6.12-b seemingly indicates that all TFRC Probe variants had practically

159

Figure 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).

the same throughput in our aforementioned simulation. This is true considering

solely the number of received packets at node 6. However, Fig. 6.13 reveals more

insight into the issue of QoS. TFRC Probe with EHN(b), namely ERR-equipped,

had approximately 200 packets lost during the handoff. Without ERR, TFRC

Probe with EHN (a) lost about 400 packets, twice as many as TFRC Probe with

EHN(a). The original TFRC Probe suffered the most packet losses with a number

of 650. It is clear that both EHN and ERR are effective algorithms that reduce

the number of packets during a HIGH-to-LOW vertical handoff.

6.5 Discussion and Conclusion

In this study, we studied design issues and proposed corresponding solutions for

enhancing quality of service for mobile hosts in various vertical handoff scenarios.

Using TCP and TFRC as examples, we proposed Implicit Handoff Notification

160

(IHN), an algorithm to detect the occurrences of vertical handoffs by passively

monitoring and estimating the link capacity with embedded end-to-end estima-

tion tools (e.g. TCP Probe and TFRC Probe). End-to-end protocols such as

TCP Probe or TFRC Probe are suggested to identify the nature of the hand-

off event estimate the amount of change in link capacity. For mobile systems

equipped with an intelligent handoff manager, we purposed the Explicit Handoff

Notification (EHN) scheme. The handoff manager automatically monitors the

physical link qualities, and triggers handoff events when appropriate. EHN ex-

plicitly notifies the ongoing applications when/what handoff event is about to

be generated by the manager, enabling the upper layer application to adapt its

sending rates accordingly.

Complementing the IHN and EHN schemes, we proposed a Fast Rate Adap-

tation (FRA) algorithm when the handoff is LOW-to-HIGH to promptly utilize

the newly materialized capacity. When the handoff is HIGH-to-LOW, another

algorithm called Early Rate Reduction (ERR) is launched to prevent bulk out-

standing packet losses. IHN, EHN, FRA, and ERR enable service agility during

both High-to-Low and Low-to-High vertical handoffs. Using simulation experi-

ments, we have evaluated the integration of IHN, RHN, FRA, and ERR in various

scenarios, and showed that the proposed algorithms are able to provide better

QoS support during vertical handoffs.

161

CHAPTER 7

Summary

In this dissertation, we have presented our studies on cross-layer integration for

wireless personal area networks, seamless handoff solution for mobile networking,

capacity estimation in wired and wireless networks, and QoS enhancements for

mobile and heterogeneous networks. We summarize our studies as follows.

1. Link Layer Enhancements for WPAN

With the increasing utilization and the consumption of digital information

through WPAN devices, maximizing the available wireless channel band-

width becomes essential in maintaining quality of services 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.

Traditionally, one of three techniques is used for error-control: 1) Retrans-

mission which uses acknowledgements and time-outs; 2) Redundancy, and

3) Interleaving. In this work, we propose a combined solution in the link

layer by taking advantages of the three traditional strategies in providing a

more robust and high performance wireless channel. Since most of WPAN

162

devices and applications are functioned with specific purposes, such cross-

layer optimization with awareness of application properties is able to greatly

enhance the application performance.

Aiming at different WPAN applications, we have proposed Adaptive ARQ

Retransmit TimeOut (ARTO) for audio streaming and Adaptive Packet

Type (APT) for TCP file transfer over Bluetooth links. Moreover, through

analysis and simulation, we have investigated an optimization scheme for

Bluetooth scatternet formation and proposed Interleaved FEC coding (I-

FEC) to further enhance the robustness of wireless connections against

burst errors.

2. Mobile Computing

In view of the proliferation of mobile computing scenarios, an “always-best-

connected” (ABC) environment is becoming increasingly important. In

order to maintain the connectivity even when the end users are mobile, a

seamless handoff solution across wireless domains/technologies is necessary.

A seamless handoff solution with both low latency and low packet loss is

mandatory for mobile users who wish to receive continuous, uninterrupted

Internet service while frequently switching from one network connection

to another. Additionally, the handoff solution should be network-layer-

transparent and infrastructure-modification-free so that existing Internet

server and client applications can painlessly survive the rapid pace of wire-

less technology evolution.

We have proposed Universal Seamless Handoff Architecture (USHA) as

163

a practical seamless handoff solution. Based on USHA, we have investi-

gated adaptive video streaming in vertical handoffs and designed a Smart

Decision Model to intelligently and automatically trigger a vertical hand-

off. Using testbed experiments, we have validated our solutions via a set of

experiments composed of Ethernet, 1xRTT, and 802.11b technologies.

3. Network Measurements

The deployment of wired and wireless networks has been growing rapidly

in the last decade. Research of network protocol design and performance

enhancement has been extensively investigated. Yet, a thorough and sys-

tematic study on the fundamental properties of the deployed network is still

lacking. Knowledge of such properties is becoming increasingly important

for network design, management and utilization. For instance, one would

benefit the peer selection for P2P networks and the tree structuring for

overlay networks, while the properties of link capacity and available band-

width are considered.

We have investigated a simple, fast, accurate, and less-intrusive tool, called

CapProbe, for capacity estimation. In addition, we have designed Asym-

Probe for the emerging asymmetric Internet access links, and AdHoc Probe

for wireless ad hoc networks. Using analysis, simulation, and testbed exper-

iments, we have evaluated our approaches in a variety of network scenarios.

4. QoS for Vertical Handoffs

Network applications, with QoS support enabled, are able to better uti-

lize the network resources (e.g. best-effort data transfer), and optimize the

164

user-perceived service qualities (e.g. real-time streaming). To achieve this

goal, the system is required to detect and adequately respond (or adapting)

to the network resource changes. Adaptation systems have been extensively

studied, and various solutions, which are mostly AIMD based, have been

proposed to provide effective and adequate service adaptation when the

network resource changes are due to congestion and/or random loss.

However, with the emerging mobile and heterogeneous network scenarios,

vertical handoffs, which usually result in drastic network resource changes,

such as link capacity, available bandwidth, and delay, are frequently oc-

curred. As a result, traditional AIMD based systems react slowly and

inadequately in such scenarios.

In order to provide better QoS support in vertical handoff scenarios, we

propose two algorithms (i.e. IHN and EHN) to identify occurrences of ver-

tical handoffs, and two algorithms (i.e. FRA and ERR) to perform agile

service adaptation when a vertical handoff is detected. Specifically, EHN

is provided by the intelligent handoff manager, and IHN is implemented

by utilizing the proposed passive capacity monitoring tools, namely TCP

Probe and TFRC Probe. The FRA algorithm is launched when the ver-

tical handoff is detected as from LOW to HIGH, and the ERR algorithm

is performed when the handoff is from HIGH to LOW. Using simulation,

we verified that our approaches are able to significantly improve applica-

tion performance, in terms of throughput and loss rate, in vertical handoff

scenarios.

165

7.1 Future Work

There are three general areas of future work suggested by our research. Firstly, it

is increasingly important to study the coexistence issue among existing wireless

technologies. More specifically, since IEEE 802.11b/g, IEEE 802.15.1, and IEEE

802.15.4 all use the same frequency band (i.e. 2.4GHz ISM frequency band),

interfere is eminent with each other when their network coverage ranges overlaps.

In order to provide better QoS for applications, it is necessary to further our

studies on the coexistence issue and design appropriate algorithms to provide

more reliable and acceptable application performance for PAN.

Secondly, it is desirable to extend our vertical handoff solution (i.e. USHA)

to more distributed and dynamic network scenarios. In this dissertation, we have

proposed a practical seamless vertical handoff solution, called USHA, for mobile

users to keep seamless connectivity even when they are moving and performing

vertical handoffs from one network interface to another. However, USHA is able

to handle the scenarios where the vertical handoff is occurred on the mobile end

host. When vertical handoffs are occurred on the Internet servers or on the inter-

mediate hosts, USHA can not work. Therefore, with emerging mobile scenarios, a

new universal vertical handoff solution, with the capabilities of handling vertical

handoffs on any hosts along a connection path, is still desired.

Finally, in addition to various link capacity estimation techniques in wired

and wireless networks, estimation of other fundamental network properties (i.e.

available bandwidth, buffer sizes, topologies, error rate, etc) remains a challenging

problem that requires additional development in tools and techniques to decipher.

The desired tools must be fast, accurate, and less-intrusive, and they must func-

tion well in both wired and wireless networks. Moreover, besides using analysis

and simulation to evaluate the designed tools, it is also necessary to perform large

166

scale experiments on the Internet and design more efficient tools to facilitate such

large scale experiments. This and two other issues mentioned above are all areas

remained to be addressed in the years to come.

167

References

[BA01] Chadi Barakat and Eitan Altman. “Bandwidth tradeoff between TCPand link-level FEC.” In IEEE ICN, July 2001.

[BBF01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker.“Dynamic Behavior of Slowly Responsive Control Algorithms.” InACM SIGCOMM, 2001.

[BFT99] Jean-Chrysostome Bolot, Sacha Fosse-Parisis, and Don Towsley.“Adaptive FEC-based error control for Internet Telephony.” In IEEEInfocom, 1999.

[BGS04] A. Balk, M. Gerla, M. Sanadidi, and D. Maggiorini. “Adaptive VideoStreaming: Pre-encoded MPEG-4 with Bandwidth Scaling.” ElsevierComputer Networks, 44:415–439, March 2004.

[Blua] “Bluetooth Specifications v1.1.” http://www.bluetooth.com.

[Blub] “Bluez - Official Linux Bluetooth protocol stack.”http://bluez.sourceforge.net.

[BNE] “Bluetooth Network Encapsulation Protocol Profile ver. 1.0.”http://www.bluetooth.com.

[BP03] E. M. Belding-Royer and C. E. Perkins. “Evolution and Future Direc-tions of the Ad hoc On-Demand Distance Vector Routing Protocol.”Ad Hoc Networks Journal, 1:125–150, July 2003.

[Bra89] R. Braden. “Requirements for internet hosts communication layers.”Technical report, IETF RFC 1122, October 1989.

[BSA95] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, and Randy H. Katz.“Improving TCP/IP Performance over Wireless Networks.” In ACMConf. on Mobile Computing and Networking, November 1995.

[CC01] Jianfei Cai and Chang Wen Chen. “FEC-based video streaming overpacket loss networks with pre-interleaving.” In International Confer-ence on Information Technology: Coding and Computing, 2001.

[CKS04] Ling-Jyh Chen, Rohit Kapoor, M. Y. Sanadidi, and Mario Gerla. “En-hancing Bluetooth TCP Throughput via Link Layer Packet Adapta-tion.” In IEEE ICC, 2004.

168

[CNY04] Ling-Jyh Chen, Alok Nandan, Guang Yang, M.Y. Sanadidi, and MarioGerla. “A Study of Passive Capacity Estimation based on CapProbe.”Technical report, UCLA CSD TR040021, 2004.

[CSC04a] Ling-Jyh Chen, Tony Sun, Benny Chen, and Mario Gerla. “A SmartDecision Model for Vertical Handoff.” In The 4th ANWIRE Interna-tional Workshop on Wireless Internet and Reconfigurability, 2004.

[CSC04b] Ling-Jyh Chen, Tony Sun, B. Cheung, D. Nguyen, and Mario Gerla.“Universal Seamless Handoff Architecture in Wireless Overlay Net-works.” Technical report, UCLA CSD TR040012, 2004.

[CSR] “Cambridge Silicon Radio.” http://www.csr.com.

[CSY05] Ling-Jyh Chen, Tony Sun, Guang Yang, M. Y. Sanadidi, and MarioGerla. “End-to-end Asymmetric Link Capacity Estimation.” In IFIPNetworking, 2005.

[CZ03] Mark Claypool and Yali Zhu. “Using Interleaving to Ameliorate theEffects of Packet Loss in a Video Stream.” In International Workshopon Multimedia Network Systems and Applications, 2003.

[DH98] S. Deering and R. Hinden. “Internet Protocol, Version 6 (IPv6) Spec-ification.” Technical report, IETF RFC 2460, December 1998.

[Dom02] G. Dommety. “Fast Handovers for Mobile IPv6.” Technical report,draft-ietf-mobileip-fast-mipv6-04.txt, IETF Internet draft, March2002.

[Dow99] Allen Downey. “Using Pathchar to Estimate Internet Link Character-istics.” In ACM SIGCOMM, 1999.

[DRM01] Constantinos Dovrolis, Parameswaran Ramanathan, and DavidMoore. “What do packet dispersion techniques measure?” In IEEEInfocom, 2001.

[Ell63] E. O. Elliott. “Estimates of error rates for codes on burst-error chan-nels.” Bell Syst. Tech. Journal, 42, September 1963.

[FGC97] Armando Fox, Steven D. Gribble, Yatin Chawathe, Eric A. Brewer,and Paul Gauthier. “Cluster-based Scalable Network Services.” InACM Symposium on Operating Systems Principles (SOSP), 1997.

[FH99] S. Floyd and T. Henderson. “The NewReno Modification to TCPsFast Recovery Algorithm.” Technical report, IETF RFC 2582, April1999.

169

[FHP00] Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer.“Equation-Based Congestion Control for Unicast Applications.” InACM SIGCOMM, 2000.

[Fro01] Pascal Frossard. “FEC Performance in Multimedia Streaming.” IEEECommunication Letters, 5:122–124, 2001.

[FW02] G. Fairhurst and L. Wood. “Advice to link designers on link Auto-matic Repeat reQuest (ARQ).” Technical report, IETF RFC 3366,August 2002.

[Gil60] E.N. Gilbert. “Capacity of a burst-noise channel.” Bell Syst. Tech.Journal, 39:1253–1266, September 1960.

[GK04] Andrei Gurtov and Jouni Korhonen. “Measurement and Analysis ofTCP-Friendly Rate Control for Vertical Handovers.” ACM MCCR,2004.

[GNS04] Mario Gerla, Bryan Kwok Fai Ng, M.Y. Sanadidi, Massimo Valla,and Ren Wang. “TCP westwood with adaptive bandwidth estimationto improve efficiency/friendliness tradeoffs.” Computer Communica-tions, 27(1):41–58, 2004.

[GPR04] V. Ghini, G. Pau, M. Roccetti, and P. Salomoni M. Gerla. “SmartDownload on the Go: A Wireless Internet Application for Music Dis-tribution over Heterogeneous Networks.” In IEEE ICC, 2004.

[HSS99] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg. “SIP: Ses-sion Initiation Protocol.” Technical report, IETF RFC 2543, March1999.

[HVB01] Gavin Holland, Nitin Vaidya, and Paramvir Bahl. “A rate-adaptiveMAC protocol for multi-hop wireless networks.” In ACM MobiCom,2001.

[HZS03] Robert Hsieh, Zhe Guang Zhou, and Aruna Seneviratne. “S-MIP: aseamless handoff architecture for mobile IP.” In IEEE Infocom, 2003.

[IEEa] “IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a(TG3a).” http://www.ieee802.org/15/pub/TG3a.html.

[IEEb] “IEEE 802.15 WPAN Task Group 1 (TG1).”http://www.ieee802.org/15/pub/TG1.html.

170

[IEEc] “IEEE 802.15.4 WPAN-LR Task Group.”http://www.ieee802.org/15/pub/TG4.html.

[IPs] “IP Security Protocol (ipsec) Charter.”http://www.ietf.org/html.charters/ipsec-charter.html.

[Jac] Van Jacobson. “Pathchar: A tool to infer characteristics of Internetpaths.” ftp://ftp.ee.lbl.gov/pathchar/.

[Jac88] Van Jacobson. “Congestion Avoidance and Control.” In ACM SIG-COMM, August 1988.

[JKK01] Per Johansson, Rohit Kapoor, Manthos Kazantzidis, and Mario Gerla.“Bluetooth: An Enabler for Personal Area Networking.” IEEE Net-work Magazine, Sept/Oct 2001.

[JPA02] D. B. Johnson, C. Perkins, and J. Arkko. “Mobility Support in IPv6.”Technical report, draft-ietf-mobileip-ipv6-17.txt, IETF Internet draft,May 2002.

[JPH02] M.C. Ju, C.H. Park, D.K. Hong, K.J. Youn, and J.W. Cho. “Packetselection scheme based on a channel quality esti-mation for Bluetoothsystems.” In The 5th International Symposium on Wireless PersonalMultimedia Communications, 2002.

[JYZ04] Zhengrong Ji, Yi Yang, Junlan Zhou, Mineo Takai, and Rajive Bagro-dia. “Exploiting Medium Access Diversity in Rate Adaptive WirelessLANs.” In ACM MobiCom, 2004.

[KCL04] Rohit Kapoor, Ling-Jyh Chen, Li Lao, Mario Gerla, and M. Y. Sana-didi. “CapProbe: A Simple and Accurate Capacity Estimation Tech-nique.” In ACM SIGCOMM, 2004.

[KCS04] Rohit Kapoor, Ling-Jyh Chen, M. Y. Sanadidi, and Mario Gerla.“Accuracy of Link Capacity Estimates using Passive and Active Ap-proaches with CapProbe.” In IEEE ISCC, 2004.

[KHH97] Isidor Kouvelas, Orion Hodson, Vicky Hardman, and Jon Crowcroft.“Redundancy Control in Real-Time Internet Audio Conferencing.” InInternational Workshop on Audio-Visual Services over Packet Net-works (AVSPN97), September 1997.

[KM97] A. Kamerman and L. Monteban. “WaveLAN II: A high-performancewireless LAN for the unlicensed band.” Bell Lab Technical Journal,Summer:118–133, 1997.

171

[LB99] Kevin Lai and Mary Baker. “Measuring Bandwidth.” In IEEE Info-com, pp. 235–245, 1999.

[LBC01] J. Li, C. Blake, D. Couto, H. I. Lee, and R. Morris. “Capacity of AdHoc Wireless Networks.” In ACM MobiCom, 2001.

[LMT04] Mathieu Lacage, Mohammad Hossein Manshaei, and Thierry Turletti.“IEEE 802.11 Rate Adaptation: A Practical Approach.” In ACMMSWiM, 2004.

[LZO] “LZO real-time data compression library.”http://www.oberhumer.com/opensource/lzo/.

[Mal01] Karim El Malki. “Low Latency Handoffs in Mobile IPv4.” Technicalreport, draft-ietf-monileip-lowlatency-handoffs-v4-03.txt, IETF Inter-net draft, November 2001.

[MB98] David A. Maltz and Pravin Bhagwat. “MSOCKS: An architecture fortransport layer mobility.” In IEEE Infocom, pp. 1037–1045, March1998.

[Mil92] D. L. Mills. “Network Time Protocol Specification, Implementationand Analysis.” Technical report, IETF RFC 1305, March 1992.

[MKF03] Arifumi Matsumoto, Masahiro Kozuka, Kenji Fujikawa, and YasuoOkabe. “TCP Multi-Home Options.” Technical report, draft-arifumi-tcp-mh-00.txt, IETF Internet draft, October 2003.

[Mod97] Eytan Modiano. “A Simple Algorithm for Optimizing the Packet SizeUsed in ARQ Protocols Based on Retransmission History.” In TheThirty-First Conference on Information Science and Systems, March1997.

[Mor03] Giacomo Morabito. “Always Best Connected.” In International AN-WIRE Workshop, April 2003.

[MPE] “MPEG-4 Industry Forum.” http://www.m4if.org.

[NIS] “NISTNet: network emulation package.”http://www.antd.nist.gov/itg/nistnet/.

[NS2] “Network Simulator (NS-2).” http://www.mash.cs.berkeley.edu/ns/.

172

[NSN97] Brian D. Noble, M. Satyanarayanan, Dushyanth Narayanan,James Eric Tilton, Jason Flinn, and Kevin R. Walker. “AgileApplication-Aware Adaptation for Mobility.” In ACM Symposium onOperating Systems Principles, pp. 276–287, 1997.

[OAR] “OAR.” http://ww.ece.rice.edu/networks/software/OAR/OAR.html.

[Per02] C. Perkins. “IP Mobility Support for IPv4.” Technical report, IETFRFC 3344, August 2002.

[PFT98] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. “Modeling TCPThroughput: A Simple Model and its Empirical Validation.” In ACMSIGCOMM, 1998.

[PH98] C. Perkins and O. Hodson. “Options for Repair of Streaming Media.”Technical report, IETF RFC 2354, June 1998.

[Pos81] Jon Postel. “Transmission Control Protocol.” Technical report, IETFRFC 793, September 1981.

[QCJ03] Daji Qiao, Sunghyun Choi, Amit Jain, and Kang G. Shin. “MiSer:An Optimal Low-Energy Transmission Strategy for IEEE 802.11a/h.”In ACM MobiCom, 2003.

[RAT] “Robust Audio Tool.” http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/download.html.

[SCF96] H. Schulzrinne, S. Casnet, R. Frederick, and V. Jacobson. “RTP: ATransport Protocol for Real-Time Applications.” Technical report,IETF RFC 1889, January 1996.

[SK98] Mark Stemm and Randy H. Katz. “Vertical Handoffs in WirelessOverlay Networks.” ACM Mobile Networking (MONET), 1998.

[SKK03] J. Strauss, D. Katabi, and F. Kaashoek. “A measurement study ofavailable bandwidth estimation tools.” In ACM IMC, 2003.

[SKS02] B. Sadeghi, V. Kanodia, A. Sabharwal, and E. Knightly. “Opportunis-tic Media Access for Multirate Ad Hoc Networks.” In ACM MobiCom,2002.

[Sno02] Alex Snoeren. A Session-Based Approach to Internet Mobility. PhDthesis, Massachusetts Institute of Technology, December 2002.

173

[SRB01] M. Schlager, B. Rathke, S. Bodenstein, and A. Wolisz. “Advocating aRemote Socket Architecture for Internet Access using Wireless LANs.”Journal of Mobile Networks and Applications, 6:23–42, 2001.

[SRL98] H. Schulzrinne, A. Rao, and R. Lanphier. “Real Time StreamingProtocol (RTSP).” Technical report, IETF RFC 2326, April 1998.

[Ste97] W. Stevens. “TCP Slow Start, Congestion Avoidance, Fast Retrans-mit, and Fast Recovery Algorithms.” Technical report, IETF RFC2001, January 1997.

[SXM00] R. Stewart, Q. Xie, K. Morneault, H. Schwarzbauer, T. Taylor, I. Ry-tina, M. Kalla, L. Zhang, and V. Paxson. “Stream Control Transmis-sion Protocol.” Technical report, IETF RFC 2960, October 2000.

[TWS97] Murad S. Taqqu, Walter Willinger, and Robert Sherman. “Proof of afundamental result in self-similar traffic modeling.” ACM SIGCOMMComputer Communications Review, 27:5–23, 1997.

[TZ99] Wai-Tian Tan and Avideh Zakhor. “Error Control for Video Multicastusing Hierarchical FEC.” In ICIP, October 1999.

[WKG99] H.J. Wang, R. H. Katz, and J. Giese. “Policy-Enabled Handoffs acrossHeterogeneous Wireless Networks.” In ACM WMCSA, 1999.

[WOM00] T. Warabino, S. Ota, D. Morikawa, M. Ohashi, H. Nakamura,H. Lwashita, and F. Watanane. “Video transcoding proxy for 3G wire-less mobile internet access.” IEEE Communication Magazine, 38:66–71, 2000.

[XGB02] K. Xu, M. Gerla, and S. Bae. “How effective is the IEEE 802.11RTS/CTS handshake in ad hoc networks?” In IEEE Globecom, 2002.

[XHG02] K. Xu, X. Hong, and M. Gerla. “An Ad Hoc Network with MobileBackbones.” In IEEE ICC, 2002.

[Zig] “Zigbee Alliance.” http://www.zigbee.org/.

[ZL04] Jianliang Zheng and Myung J. Lee. “Will IEEE 802.15.4 Make Ubiq-uitous Networking a Reality? A Discussion on a Potential Low Power,Low Bit Rate Standard.” IEEE Communications Magazine, pp. 140–146, June 2004.

[ZLX02] L. Zhang, Z. Liu, and C. H. Xia. “Clock Synchronization Algorithmsfor Network Measurements.” In IEEE Infocom, 2002.

174

[ZR97] Michele Zorzi and Ramesh R. Rao. “Error Control and Energy Con-sumption in Communications for Nomadic Computing.” IEEE Trans.Computers, 46:279–289, 1997.

175