IEEE 802.15 – Survey of Scatternet Formation Protocols and Algorithms

1. IEEE 802.15 –Survey of Scatternet Formation Protocols and Algorithms Vivek Kumar Joy Ghosh University at Buffalo

2. Why Bluetooth ? • Operates in license free ISM band centered around 2.45GHz (available worldwide) • Interference immunity (FH) ,Crosstalk avoidance (TDD) also => single chip • Low power (30µA in sleep ,300µA standby ,8-30mA transmitting) ~ Cell phone power (50 – 100 mA ?) • Channel access contention free (~ 802.11 ?) • Saves contention overhead (feasibility with 625bits packet ?) • No line of sight requirement (~IrDA ?) ,low cost,high data rate (~ 1Mbps, practically 721kbps ?) [BT2.0 ~ 10Mbps] • => Bluetooth very viable for wire replacement, short range ad-hoc n/w ,and now aiming to be access point technology to wide area voice/data n/w (competes with 802.11) • We must think bigger than piconets !!!( Routing )

3. Overview • What do we know already? • Bluetooth basics • Connection establishment • Concept of an ad-hoc piconet • Today : Concept of a scatternet • Set of independent piconets -> scatternet? • Protocols: • Tree Scatternet Formation (TSF) • BlueStar-BlueConstellation • BlueMesh • BTSpin (proposed by us)

4. S S M B S S S S S M Scatternets • Internetworking multiple piconets • How to make two or more independent and non-synchronized piconets communicate with each other? • Bluetooth alludes the possibility, but does not say how • Realisation possible with bridges: slave relay (shared slave) or master relay

5. M ? ? M ? ? ? ? ? ? ? Problem ? • How do a collection of isolated devices form a scatternet?i.e how do we go from A to B • Each device is not aware of the others •  The scatternet formation protocol must be distributed • Devices are in the communication range of each other •  Potentially, any two devices could be connected directly • Potentially large number of topologies for n nodes ,which one is best ? A B

6. Criteria for efficient Scatternet Formation • Number of Piconets • Scatternet should have minimum number of Piconets • Reduces the inefficient intra-piconet communication • Reduces co-channel interference • Number of Roles per node • The number of roles per node should be minimized • Gateway nodes (Bridges) incur additional cost of switching, scheduling and re-synchronization between piconets • Size of Piconets • Piconets should be as full as possible (7 slaves in each piconet) • Optimal system capacity utilization • More than 7 not desirable  park / unpark

7. Criteria for efficient Scatternet Formation • Average Shortest Path (ASP) • Average number of hops needed for 2 devices to communicate • Lower ASP  better routing efficiency • Message Overhead • Minimize control packet overhead • Bandwidth is scarce • Very small packets (625 bits) ~ 40 bytes for TCP headers!! • Convergence • Algorithm should converge quickly to possible optimal solution • Low power devices spend power in setting up scatternet (Energy!) • Applicable to short term ad hoc networks (Time!)

8. Classification of Scatternet Protocols

9. Tree Scatternet Formation Protocol (TSF) • Proposed by G. Tan et. al. MIT Technical Report, Oct 2001 • Scatternet Topology is at any time a collection of one or more rooted trees • Trees are autonomously attempting to merge. Goal: only one tree. • Why Trees => no cycles, simple routing (unique path), minimal # of links • Vulnerable to single point faults: importance for fast self-healing • Possible bottleneck at roots while routing. • Three kinds of nodes: roots, non-roots and free nodes • Each node knows its type – via state diagrams and IACs • Each node in the network runs algorithm transitioning between two states • FORM: “social” task, to reduce number of scatternet components • COMM: state for data communication within component

10. FORM STATE…. • FORM state: • Every node tries to make a link to another node belonging to a different tree/component • Two substates FORM:INQ and FORM:INQSCAN • All nodes spend time in this state • Roots spend more time in it than others • How long shall we be social? T_form = random (E[Tinq], D) • Too long => waste of time if environment does not change • Too short => not able to meet properly • Randomized to avoid periodic synchronization effects • E [Tinq] is the time taken to complete an INQUIRY process. • T_form must be at least as long to ensure that a handshake can take place. • D decides the size of random interval

11. Mas/Slav Root Non-Root Free Root 1 0 0 Non-root 0 0 1 Free 0 1 1 The FORM state…. Assume each node knows it type Link formation combination: Entries with 0 are Invalid • “Every node tries to join with other components” • Opportunity: distributed formation • Non-root connects to Free only if Free is not within its Root’s range • Danger: how to save the invariant to have only trees?  Use the knowledge of the node’s type!

12. The FORM state – avoid the invariant • Non-root/Root and Non-root/Non-Root connections could create cycles • Links of root nodes are saved for merging with other trees later (no Root/Free Connections) • Non-root nodes help free nodes to join scatternet • Rule: Free node becomes the slave (with probability 0.5 a role switch procedure takes place) • Therefore: a node can never be in more than two piconets • Only root nodes attempt to heal partitions & join another tree as a slave • Healing function => roots spend more time in FORM state • When root joins root ,the master becomes the new root of the merged tree

13. The FORM state…. • Improvement: The coordinator • We don‘t want a root to waste time and energy to do INQUIRY, root should do communication only • Thus a root designates a node in the component to be coordinator • Elects a child randomly • Maybe the child does not want to be coordinator => elects one of its children and so on • A leaf must accept the job (no bottleneck anyway)

14. The FORM state…. • Coordinators establish link, then send PAGE and PAGE SCAN info to their roots and break the link • Roots can make the link quickly • New root selects new coordinator randomly • Idea: change coordinator also periodically, that‘s robust if a coordinator breaks and distributes the energy-intensive task on many nodes • Problem: not only the coordinators but also the roots have to be in radio range

15. The COMM State • Communication-within-component state • How long shall we work in our component? • T_comm = fcomm * random(R,D) • fcomm: for free nodes fcomm=0 • for other nodes suggestion as a function of age (how long ago it joined the scatternet: younger nodes should spend more time in trying to form bigger scatternet, older ones more in data communication) and number of children in the current tree (the more children the more a node is expected to be involved in communication)

16. Healing • Dynamic environment • Nodes can leave anytime • Two ways a connectivity can be lost • Master loses connection to slave • Slave loses connection to master • When a master detects loss of child => master must only check if it has become a free node • No control messages, works completely locally • When a slave loses its parent => slave updates its node type and sets age to zero • Leaf node becomes free node • Internal node becomes root node

17. Problem • Arrival “en masse” • Results in many components • TSF allows only roots to merge • But: Bluetooth allows max. 7 connections per device • Consequence: roots may not be able to merge together because they’re full, so components remain seperated

18. Solution • When a root node is about to reach max. number of children, it designates a child to become the root • Then the two nodes switch roles as master and slave

19. Routing (1) • Root topology • No loops possible • Unique paths • Therefore simple routing • Idea: nodes have unique addresses based upon their position in the tree • Mapping from IP to these adresses using ARP (a node returns its scatternet address in response to ARP query) • With this identifier, packet forwarding protocol works by simply having each node look at the destination and forward it along one of its links • No per packet overhead like source routing, no extra memory needed like distance vector

20. Routing (2) • A partial realization • Each node has an address dependent on its position and a portion of address space that it can distribute to its children • Each node knows it children’s addresses • Forwarding can be done by longest prefix match; if no child’s address is applicable the packet is pushed upwards • But what happens when nodes leave? How do we merge trees?

21. Generated Topologies

22. Statistics : Formation delay

23. Effects of increasing inter-piconet scheduling latency n/w size=50

24. TSF Summary • Tree structure • Incremental and efficient • Devices need not to be in radio range • Simple routing • Comments? Questions? • Further reading • http://nms.lcs.mit.edu/projects/blueware/body.htm

25. BlueStar & BlueConstellation A distributed approach to forming mesh like scatternets

26. Phases of the Protocol • Phase I • Topology discovery • Phase II • BlueStar (Piconet) formation • Phase III • BlueConstellation (Scatternet) formation

27. I. Topology discovery • Each node has unique ID and weight • Symmetric 1-hop neighbor information: • Requires pair of neighbors to be in opposite mode • Inquirer: sends ID pkt. containing GAC • Inquired: • On receiving ID pkt, backs off randomly • If ID pkt persists, sends FHS pkt. (ID + BT clock) • Temporary piconet for symmetric knowledge • Phase time needs to be determined well • Nodes may not discover all neighbors!

28. II. BlueStar formation • “init nodes” • Nodes with biggest weight in their neighborhood • Ties broken with unique ID • “init nodes” become MASTERS of neighbors • Non-init nodes wait to hear from bigger neighbors to decide their role • Become SLAVE to first big MASTER to page • If all big neighbors are SLAVES, become MASTER • Communicate role to all smaller neighbors • If role != MASTER, learn roles of smaller neighbors • For smaller SLAVE neighbor, note its MASTER ID

29. BlueStar formation protocols • initOperations() { if (for each neighbor u: myWeight > uWeight) { myRole = MASTER; go to PAGE mode; PAGE(v, MASTER, v) to all smaller neighbors; exit; } }

30. BlueStar formation protocols (contd.) • ReceivedPage (deviceID u, string role, deviceID t) { record that u has paged; record role(u); if (role(u) == SLAVE)  master(u) = t; if (myWeight < uWeight) { if (role(u) == MASTER) { if (myRole == none)  myMaster = u; myRole = SLAVE; else  inform u about myMaster ID; } if (some bigger neighbor is yet to page)  wait for following page; else { if (all bigger neighbors are SLAVES) myRole = MASTER; PAGE (v, MASTER, v) to all neighbors; else PAGE (v, SLAVE, myMaster) to each neighbor; switch to PAGE SCAN; } } else if (all neighbors have not paged)  wait for next page }

31. 6 3 23 28 9 34 15 12 5 7 14 42 1 4 45 8 10 35 32 51 19 Example Network : Phase I (topology) Init Node Non-Init Node

32. 6 3 23 28 9 34 15 12 5 7 14 42 1 4 45 8 10 35 32 51 19 Example Network : Phase II (piconets) Master Slave

33. III. BlueConstellation formation • mNeighbors • Neighboring masters that are atmost 3 hops away • 2 hops: 1 slave in between 2 masters • 3 hops: 2 slaves in between 2 masters • iMasters • Biggest weight amongst all mNeighbors • Scatternet formation • Select gateways to connect masters to all its mNeighbors

34. BlueConstellation formation protocol • mInitOperations() { if (for each mNeighbor u: myWeight > uWeight) { myRole = iMaster; instruct gateway slaves to 3 hop mNeighbors to page slave of mNeighbor; instruct gateway slaves to 2 hop mNeighbors to page mNeighbor; page slaves of 2 hop mNeighbors identified as gateways; } else { instruct all gateway slaves to bigger mNeighbors to go to page scan; if (slaves of bigger mNeighbors identified as gateways are neighbors) go to page scan; while (links to bigger mNeighbors are not up)  WAIT; instruct gateway slaves to smaller mNeighbors to go to page mode; if (slaves of smaller mNeighbors identified as gateways are nearby) go to page mode; }

35. Example Network : Phase III (scatternets) 6 3 23 28 9 34 15 12 5 7 14 42 1 4 45 8 10 35 32 51 19 Master Slave Slave-Bridge Master-Bridge

36. Conclusion • Advantages • Assign weights to specify suitability of a Master • Robust connected mesh (multiple paths) • No leader required to initiate process • Multihop scatternet • Disadvantages • Many temporary piconets formed incurs delay • Unable to account for joining / leaving nodes • May have more than 7 slaves in a piconet – Park!

37. BlueMesh Degree constrained multihop scatternet

38. What is new? • If there are more than 7 neighbors, choose a maximum of 7 slaves which cover all other neighbors • No need for park / unpark • No extra hardware required (unlike some other solutions provided which require GPS in each device to perform degree reduction techniques on network topology graph)

39. Phases of the Protocol • Phase I • Topology discovery • Phase II • Scatternet formation

40. I. Topology discovery • Each node has unique ID and weight • Weight signifies node’s suitability as master • Symmetric 1-hop neighbor information • Done similar to last discussed protocol • Symmetric 2-hop neighbor information • Nodes with biggest weight in neighborhood (init nodes) pages its smaller neighbors and exchange 1-hop neighbor information • After being paged by all bigger weight neighbors, non-init nodes start paging and exchanging similar information with its smaller neighbors

41. II. Scatternet formation • BlueMesh formed in local successive iterations • Each iteration has two parts: • Role Selection • Gateway Selection • After each iteration: • Masters, Gateway Slaves and non-Gateway Slaves exit execution of the iterative process • Intermediate gateways proceed to form extra piconets needed to connect 3-hop Masters

42. Iterative Process: Role Selection • Definitions • N(v) : set of v’s 1-hop neighbors • S(v) : set of at most 7 slaves selected by master v • C(v) : set of v’s • Bigger slave neighbors • Smaller neighbors • M(v) : set of v’s masters

43. Iterative Process: Role Selection (contd.) • All init nodes execute the following process • Master (v) 1 myRole  master 2 PageMode 3 ComputeS(v); 4 for each u in S(v) 5 do Page (u, v, master, true, NIL); 6 for each u in C(v) – S(v) 7 do Page (u, v, master, false, NIL); 8 exit

44. Iterative Process: Role Selection (contd.) • ComputeS(v) 1 S(v)  NULL; 2 U  C(v); 3 while U != NULL 4 do x  bigger node in U; 5 S(v)  S(v) U {x}; 6 U  U – N(x); 7 S(v)  S(v) U Get (7 - |S(v)|, C(v) – S(v)); • Get (n, B) : selects n nodes from set B • Criteria for selection is user specified

45. Iterative Process: Role Selection (contd.) • NonInit(v) 1 PageScanMode 2 for each bigger neighbor w 3 do Wait Page (v, w, r, j, NIL); 4 if ((r == master) && (j == true)) 5 myRole  slave; Join (w); M(v)  M(v) U {w}; 6 if (myRole == slave) 7 PageMode 8 for each w in C(v) 9 do Page (w, v, slave, false, NIL); 10 PageScanMode 11 for each w in C(v) 12 do Wait Page (v, w, r, j, NIL) from smaller w 13 Wait Page (v, w, slave, false, M(w)) from bigger w 14 PageMode 15 for each w in C(v) 16 do Page (w, v, slave, false, M(v)); 17 PageScanMode 18 for each smaller slave w 19 do Wait Page (v, w, slave, false, M(w)); 20 EXIT 21 else Master(v)

46. Iterative Process: Gateway Selection • Slaves tell Masters: • Neighbor roles • Neighbor’s list of Masters • Whether any neighboring Master selected them as slave • Masters decide: • Which slaves shall act as gateways to which piconets • Which slaves need to be intermediate gateways • Intermediate nodes carry on the iterative process

47. BlueMesh Simulation • Parameters • 200 nodes • Transmission radius of 10 m • Node distribution: random and uniform • Square region with size varying with number of nodes to always give connected networks

48. BlueMesh Simulation Results I

49. BlueMesh Simulation Results II

50. Conclusion • Advantages: • No more than 7 slaves per piconet • On an average of 2.3 roles per node • Route lengths not significantly longer than shortest path in the network • Disadvantages: • Multiple phases might incur unacceptable delay • Still not suitable for nodes leaving/joining • Simulations assumed network connectivity