Personal Area Networks: Interconnects and Performance Enhancements
Transcript of Personal Area Networks: Interconnects and Performance Enhancements
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