1 / 17

BlueTorrent: P2P Application Using Bluetooth

BlueTorrent: P2P Application Using Bluetooth. Sewook Jung and Alex Chang Network Research Lab. UCLA. Outline. Problem Statement Measurement Setup Hardware Software Experiments Simulation Conclusion. Problem Statement.

amadis
Download Presentation

BlueTorrent: P2P Application Using Bluetooth

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BlueTorrent: P2P Application Using Bluetooth Sewook Jung and Alex Chang Network Research Lab. UCLA

  2. Outline • Problem Statement • Measurement Setup • Hardware • Software • Experiments • Simulation • Conclusion

  3. Problem Statement • Recently, in PerCom’07, we have describe the possibility of Bluetooth-based content sharing • Sharing small size audio/video ad files (<10MB) • Through digital billboards on the street with BT-APs. • Motivation • High penetration rate of Bluetooth devices (cell phones and PDA) – energy efficient • Mobile user must go/stop/wait for full download • The bandwidth of AP is limited • The server range of AP is short (less than 10 meters) • Due to obstacles (humans), channel is error-prone • Goal: provide an “effective” content sharing mechanism for Bluetooth users

  4. Measurement Setup- Hardware Part • Laptops • Dell Latitude D610 Pentium M 770 (2.00GHz) 512MB RAM • PDA – iPaq 3870 • 206MHz StrongArm processor • 64MB RAM, 32MB Flash ROM • Built-in bluetooth – v1.1 CSR • Bluetooth Dongles • http://www.holtmann.org/linux/bluetooth/features.html • Belkin F8T003v – v1.1 CSR • Belkin F8T013V – v2.0EDR Broadcom • Belkin F8T012V – v2.0EDR Broadcom (Class 1) • Kensington 33348 – v2.0EDR Broadcom • Bluetake BT009Si – v1.2 – Silicon Wave

  5. S/W specification • Basic measurement tool • Platform: BlueZ v3.7, C language • Master: • hci_inquiry() and discover peers • Check COD (class of device) of each peer • Try to connect a peer through L2CAP sockets • Send dummy data to the slave node • Slave: • Initially, inquiry scan mode • Setup a server (listen) for a potential connection • If there’s a connection, start receiving data

  6. S/W specification • P2P-Mode • Two parts: peer discovery, connection • AP as a master node • Laptop/PDA periodically change their roles • Random role selection: 1) startup 2) after connection reset • Master: hci_inquiry() + connect() (How long?) • Slave: listen() (fixed) MASTER MASTER SLAVE SLAVE Time hci_inquiry() Connect Listen (inq-scan) Application Layer T_inq CONNECT_TIMEOUT ACCEPT_TIMEOUT = T_inq_scan Tperiod Connect: if there’s a node to connect

  7. S/W specification • Usage() • -r role: master, slave, p2p • -d send size : size in bytes to send in each send api call (<64KB) • -o pageto : page timeout - 1 slot = 0.625 ms, eg : 8000 slots = 5000 ms • -s inquiry scan window/interval (unit=slot) e.g., 18:512 <=> 11ms:320ms • -p page scan window/interval (unit=slot) e.g., 18:512 <=> 11ms:320ms • -t packet type: DM3 DM5 DH3 DH5 HV2 HV3 EDR: 2-DH3 2DH5 3-DH3 3-DH5 • -c class of device: 24bit Hex code: 3e0100 • -i inquiry length (unit 1.28s): 5 <=> 5*1.28s • -a accept timeout (unit 1s): eg. 10s • -l log level: default (2) verborse, 1 concise • Sample Data • INFO: Log level, timestamp, I(info), TPL, LQ, RSSI, AFH(2:non, 1:yes, 0:no) • DATA: Log level, timestamp, D(data), received data (for 0.5s), total data received so far • Ex) • 1 1164157164.44 D 12000 9518400 • 1 1164157164.48 I 2 136 0 2 • 1 1164157164.73 I 2 137 0 2 • 1 1164157165.6 D 12000 9530400 • With this program, we also need to use hcidump • hcidump data |grep dlen | awk '{"date +%s" | getline D; print D, $9; close("date +%s")}'

  8. Experiment Setup • Experiment #1 • Ackerman union • Experiment #2 • Various places in UCLA • BT Dongles (somehow all different chipmakers) • BT 1.1 CSR (class 2) • BT 1.2 Silicon Wave (class 2) • BT 2.0 Broadcom (class 1 & 2)

  9. Experiment #1 • Real environment test. • Ackerman Union • Speed 1 m/s (5 meter marks) • Use stop-watch • BT 1.1  1.1 • BT 2.0  2.0 master slave 60M

  10. Experiment #1 • Real Env. Result BT 1.1  1.1 BT 2.0  2.0

  11. Experiment #2 • Distributed BT discovery • Scan software cooperatively discover and connect peers passing by! • usage: ./scan <mode:1/2> <inq len: n*1.28s> • mode 1: compact print, 2: verbose print • inq len: how man inquiries? (1.28s ea) • ex) ./scan 1 8 • Log Format: • Log, Timestamp, BDADDR, COD, LMP Version, Company #, Readable COD • Example: • 1 6362.35 00:0F:DE:4B:5A:20 520204 1.1 37 Phone Cellular • 1 6363.64 00:0B:0D:0C:53:34 211112 1.2 11 - - • 1 6370.13 00:16:FE:90:77:F0 3e0100 2.0 10 Computer Uncategorized • 1 6371.33 00:02:C7:09:7E:23 120112 1.1 10 Computer Handheld • 1 6372.93 08:00:46:E0:17:C5 3e0100 1.2 10 Computer Uncategorized • 1 6373.30 00:0A:3A:53:27:28 211111 1.1 10 - - • 1 6373.48 D 00:0A:3A:53:27:28 211111 (D: Duplicated) • Many devices allow to create connections w/o authentication.. (security implication..)

  12. Experiment #2: Scanning Results • Nov 29/30 scanning inside the campus • Bruin walk, student center (Ackerman), library • 402 distinct devices found • 75% (300 devices) allow connections • No authentication at all!! • General over various devices • Bluetooth LMP version information was read from remote devices (after connection) • LMP version is almost equivalent to Bluetooth version • Makers: CSR, Broadcom, Philips, TI, Qualcomm, Silicon Wave, Errison, Nokia BT LMP version distribution

  13. Design/Implementation of BT • Data sharing with coding schemes • Network coding • Rateless coding (digital fountain) • Energy-efficient P2P mode • Initially nodes are all scan mode (slave) • APs are all MASTERS. • Nodes in scan mode can be connected to the AP, and they turn on P2P mode • These P2P nodes can in turn activate other peers • Inquiry/Scan intervals are dynamically adjusted if there’s not enough contacts • i.e., less contacts, more inquiry scan (slave) • Thus, P2P mode is only activated nearby AP (i.e., social orbit-style; or bazaar concept)

  14. Simulations- Protocol setting • Inquiry • Every Bluetooth Node has a alternately do inquiry and inquiry scan • AP always do inquiry • Connection • When Inquiry node founds the other node, it connects found node • Inquiry node becomes master node and inquiry scan node becomes slave node • If connection is not helpful (there is no data to transfer for both direction), master disconnects connection • If connection is disconnected, master connects other nodes which are detected by inquiry

  15. Simulations- Protocol setting • Data Transfer • Normal Data Transfer • Exchange segment map (shows list of current segments) • make Helpful data list • Randomly choose one segment from Helpful data list • Network Coding Data Transfer • Encode Code Block • Transfer Code Block • If received Code Block is helpful, decode received Code Block • Rateless Coding Data Transfer • Encode Code Block beforehand • make Helpful data list • Randomly choose one segment from Helpful data list • Disconnection

  16. Simulations- Result

  17. Conclusion • We characterize and measure the Bluetooth-based content sharing system • Show that P2P in mobile environments is feasible. (download several mega bytes for EDR, and 0.5M) • We also showed that understanding characteristics of different BT versions and their compatibility is important • To maximize the performance in a dynamic environment we presented/evaluated • Coding techniques • Adaptive p2p mode

More Related