Presentation of Bluetooth Activities of Aalborg
University at BLIP Systems
Slide 1 of 21
BLIP Meeting - Agenda
• Agenda:
– Preliminary Results of TCP Performance over
Bluetooth
(Dennis Dungs, ca. 30 min)
– Location Information in Bluetooth
(Joao Figueiras, ca. 30 min)
– Scatternet Formation
(Istvan Kovacs, ca. 30 min)
– Set-up of experimental Bluetooth network at Aalborg
University
(who??, 10 min)
– Bluetooth simulation tools
(who??, 10 min)
Slide 2 of 21
Implementation and Evaluation of a
Performance Enhancing Proxy for Wireless
TCP
Master Thesis Project (Sep 03 – April 04)
Dennis Dungs
Technical University Munich, Germany
Aalborg University, Denmark
March 2004
Supervised by
Hans-Peter Schwefel
Aalborg University, Denmark
Slide 3 of 21
Agenda
•
•
•
•
Goal and steps of this project
Considered Scenarios in the project
Short Reminder: TCP
Evaluation of Bluetooth Performance
– UDP in Single MN AP Scenario
– TCP in Single MN AP Scenario
• Conclusions
Slide 4 of 21
Goal of this project
• Goal:
– Identify TCP performance lacks in wireless scenarios
– Evaluate performance capabilites of a TCP Proxy
• Steps
–
–
–
–
Getting familiar with concepts of TCP
Research about common TCP implementations
Describing wireless scenarios
Analyzing TCP performance and Identifying TCP
performance lacks in wireless scenarios
– Designing and Implementing a TCP Proxy
– Evaluation of Scenarios using the TCP Proxy
Slide 5 of 21
Considered Scenarios
•
Definition:
„A Scenario consists of a description of the network infrastructure, mobility model and
traffic model.“
•
Network Infrastructure:
–
–
–
–
•
Access Technology
Proxy Location
Sender / Receiver Location
Network configuration
Wireless
supporting
Network
Wired
Network
Proxy
Mobility Model
– Fixed position
– Handover to same/different subnet
– Handover to new access technology
•
Server
Traffic Model
–
–
–
–
–
Size of transmitted data
Used bandwith
Single-/Multi-User
Cross-traffic
Constant / Burst Traffic
Mobile
Host
Slide 6 of 21
Short Reminder - TCP
• Goals of TCP:
–
–
–
–
–
–
Connection oriented, full duplex protocol
Multiplexing of IP-datagram service (Ports)
In-order data transfer (Sequence Numbers)
Reliable data transfer (Acknowledgements)
Prevent Receiver from flooding (Receiver Advertised Window)
Prevent intermediate systems from flooding (Congestion Control
Algorithm)
• Congestion Control
– Congestion Window: Number of bytes, that can be send in one
RTT without congestion
– Dynamically adjusted until congestion indicated via DUPACKs or
timeouts
– Exponential increase per RTT to reach maximum throughput
(slow-start)
– Continuous probing of maximum available bandwith via linear
increase/ multiplicative decrease per RTT
Slide 7 of 21
Evaluation
Slide 8 of 21
Evaluation – Measurement Procedure
• IPerf
– Setup a UDP/TCP connection from sender to receiver
– Send data from sender to receiver at maximum bandwidth (TCP)
or given bandwidth (UDP)
• Ethereal
– Trace Ethernet packets at sender and receiver in real-time into a
file
– Traces arrival times of packets t(n) and contents of Ethernet
packets
• TCPTrace
– Generate TCP Statistics offline
• Matlab
– Generating UDP Statistics offline
– Calculating statistical parameters
• GNUPlot
– Visualizing TCP Statistics (RTT Graphs, Throughput Graphs)
Slide 9 of 21
Evaluation - Metrics
• Instantaneous Throughput
payloadsiz en
 Inst (n) 
t n  t n 1
• Instantaneous Averaged Throughput
nk
 Inst, Avg (i ) 
 payloadsiz e
l
l  n 1
tnk  tn
, n  k * (i - 1), k const.
• Transmission Throughput
n
 transmission (n) 
 payloadsiz e
i
i 1
t n  t1
• Round-Trip-Times (RTT)
Slide 10 of 21
Single Connection over Bluetooth - Scenario
• Scenario Parameters:
Network Setup:
Aalborg
– MN: 2.6 GHz-P4 512MB
RAM, WinXP, Belkin Class2
BT USB Adapter
– AP: BlipNet BlipNode L1
– Supposed Master: AP
– Supposed Slave: Mobile Node
– Application Profile: PAN
– Distance AP->MN: 1m
– Server: PPro 166Mhz, 32MB
RAM, running Redhat 7.3
– Sending duration: 30sec
– UDP payloadsize: 1470 bytes
– UDP Bandwith: 700kBit/s
(Application Layer Bandwith)
– TCP receiver buffer: 8 kBytes
8 MBit/s
8 MBit/s
Tokyo
100 MBit/s
Delft
100 MBit/s
Shanghai
Toronto
100 MBit/s
100 MBit/s
Server
China
10.10.3.254
Downstream
10.10.1.X
Mobile Node
Legend:
Router
Switch
BT AP
Fixed Host
Mobile Host
Slide 11 of 21
Single UDP Connection over Bluetooth
Slide 12 of 21
Single UDP Connection over Bluetooth
Slide 13 of 21
Single TCP Connection over Bluetooth
Slide 14 of 21
Single TCP Connection over Bluetooth
Slide 15 of 21
Single TCP Connection over Bluetooth
• Possible Reasons for throughput jumps
– Traffic in low-bandwidth direction (Routers)
• Packet Scheduler has to send more data
• Adjusting to „more symmetric“ bandwidth
• Flow Control on Baseband
– Interference
• Channel quality driven data rate change (CQDDR)
Slide 16 of 21
Additional Results
• Upstream (Slave->Master) gains always
higher throughput than downstream
• Adhoc – Scenario:
– Same throughput jumps (UDP & TCP) as in
AP-scenario, but less likely
– Higher average throughput
• No significant differences between WinXP
(WidComm-Stack) and Linux (BlueZStack)
Slide 17 of 21
Conclusions - Questions
• Conclusion:
– Many factors could cause the throughputdropdown
– Difficult to analyze TCP performance lacks, if
underlying behaviour unclear
– To get deeper understandings, packet trace
tool for Baseband is needed
Slide 18 of 21
References
• Project WebSite:
http://kom.aau.dk/~dennis/
• IPLab WebSite:
http://kom.aau.dk/iplab/
• RFCs : RFC791 (IP), RFC793 (TCP), a.o.
http://www.ietf.org/
• Bluetooth Specification
http://www.bluetooth.org/
• eMail:
dennis@kom.aau.dk
Slide 19 of 21
Thanks for listening!
Any Questions?
Yes, i have some...
Slide 20 of 21
Questions
• How to figure out, which Bluetooth device is
master, which is slave (role switching)?
• How to figure out, which packet types are used
(DM, DF, AUX) ?
• How to figure out, if master/slave uses „Channel
quality driven data rate change” and when it
affects the channel
• How to figure out, how “Flow Control” on
baseband level is influencing the throughput?
=> Is it possible to trace packets at Baseband
level?
Slide 21 of 21
Backup
Slide 22 of 21
Adhoc UDP Connection over Bluetooth
• Scenario Parameters
Mobile Node 2
(supposed Slave)
Mobile Node 1
(supposed Master)
UDP Downstream
UDP Upstream
– MN 1: 2.6 GHz-P4 512MB
RAM, WinXP, Belkin Class2 BT
USB Adapter
– MN 2: 266MHz-P 64MB RAM,
WinXP, Belkin Class2 BT USB
Adapter
– Supposed Master: MN 1
– Supposed Slave: MN 2
– Application Profile: PAN
– Distance MN1->MN2: 1m
– Sending duration: 10sec
– UDP payload-size: 1470 bytes
– UDP Bandwith: 700kBit/s
(Application Layer Bandwith)
Slide 23 of 21
Adhoc UDP Connection over Bluetooth - Downstream
Slide 24 of 21
Adhoc UDP Connection over Bluetooth - Upstream
Slide 25 of 21
Adhoc UDP Connection over Bluetooth - Comparison
Slide 26 of 21
Adhoc TCP Connection over Bluetooth
• Scenario Parameters
Mobile Node 2
(supposed Slave)
Mobile Node 1
(supposed Master)
TCP Downstream
TCP Upstream
– MN 1: 2.6 GHz-P4 512MB
RAM, WinXP, Belkin Class2 BT
USB Adapter
– MN 2: 266MHz-P 64MB RAM,
WinXP, Belkin Class2 BT USB
Adapter
– Supposed Master: MN 1
– Supposed Slave: MN 2
– Application Profile: PAN
– Distance MN1->MN2: 1m
– Sending duration: 10sec
– Standard WinXP TCP
Implementation
– TCP Window Size: 8kByte
Slide 27 of 21
Adhoc TCP Connection over Bluetooth – Comparison US/DS
Slide 28 of 21
Adhoc TCP Connection over Bluetooth
Slide 29 of 21
Current
IPLab
network
architecture
IP LAB:
Current
Architecture
Istanbul
10.10.3.254
10.10.4.2
10.10.254.254
Shanghai
10.10.3.1
Toronto
Aalborg
Internet
San Francisco
130.225.51.6
Delft
GPRS
Network
Tokyo
Frankfurt
10.10.2.1
10.10.1.1
Toronto
Shanghai
10.10.2.254
10.10.2.2
10.10.1.254
10.10.1.2
Sydney
Dhaka
Slide 30 of 21
Single TCP Connection over Bluetooth - Scenario
• Scenario Parameters:
Network Setup:
8 MBit/s
8 MBit/s
Aalborg
– MN: 2.6 GHz-P4 512MB
RAM, SuSE Linux 9.0
(Kernel 2.4.21-166), BlueZ
Stack (Lib 2.5, SDP 1.5, PAN
1.1)
– AP: BlipNet BlipNode L1
– Master: AP
– Slave: Mobile Node
– Application Profile: PAN
– Distance AP->MN: 1m
– Server: PPro 166Mhz, 32MB
RAM, running Redhat 7.3
– Sending duration: 30sec
– Standard TCP
Implementations
– TCP Window Size: 8kByte
Tokyo
100 MBit/s
Delft
100 MBit/s
Shanghai
Toronto
100 MBit/s
100 MBit/s
Server
China
10.10.3.254
10.10.1.X
Mobile Node
Legend:
Router
Switch
BT AP
Fixed Host
Mobile Host
Slide 31 of 21
Single TCP Connection over Bluetooth (Linux)
Slide 32 of 21