-IEEE 802.15 –Survey of Scatternet Formation Protocols and Algorithms

Vivek Kumar

Joy Ghosh

University at Buffalo

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 )

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)

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

SM B

SS

S

MS

S

S

Problem ?

?

?

?

?

??

?

?

?

MM

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

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

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

Centralized Distributed

Single-hop

Static

BTCP, Marsan_MinMax, 1-Factors

BlueTrees, BlueRings, Lin et al.

Single-hop Dynamic

None LMS, TSF

Multi-hop

Static

Marsan_ILP BlueMesh, BlueStar_Basagni

Multi-hop Dynamic

None Three phase-Bluestar,

BTSpin

Classification of Scatternet Protocols

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

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

The FORM state….

110Free

100Non-root

001Root

FreeNon-RootRootMas/Slav

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!

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

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)

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

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)

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

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

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

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

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?

Generated Topologies

Statistics : Formation delay

Effects of increasing inter-piconet scheduling latency

n/w size=50

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

BlueStar & BlueConstellation

A distributed approach to forming mesh like scatternets

Phases of the Protocol

Phase I Topology discovery

Phase II BlueStar (Piconet) formation

Phase III BlueConstellation (Scatternet) formation

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!

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

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;

}

}

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}

Example Network : Phase I (topology)

3428

51

45

7

4

3532

108

19

42

23

9

3

1215

14

1

5

6

Init NodeNon-Init Node

Example Network : Phase II (piconets)

3428

51

45

7

4

3532

108

19

42

23

9

3

1215

14

1

5

6

Master Slave

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

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;

}

Example Network : Phase III (scatternets)

3428

51

45

7

4

3532

108

19

42

23

9

3

1215

14

1

5

6

Master Slave Slave-Bridge Master-Bridge

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!

BlueMesh

Degree constrained multihop scatternet

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)

Phases of the Protocol

Phase I Topology discovery

Phase II Scatternet formation

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

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

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

Iterative Process: Role Selection (contd.) All init nodes execute the following process Master (v)

1 myRole master2 PageMode3 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

Iterative Process: Role Selection (contd.) ComputeS(v)

1 S(v) NULL;2 U C(v);3 while U != NULL4 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

Iterative Process: Role Selection (contd.) NonInit(v)

1 PageScanMode2 for each bigger neighbor w3 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 PageMode8 for each w in C(v)9 do Page (w, v, slave, false, NIL);10 PageScanMode11 for each w in C(v)12 do Wait Page (v, w, r, j, NIL) from smaller w13 Wait Page (v, w, slave, false, M(w)) from bigger w14 PageMode15 for each w in C(v)16 do Page (w, v, slave, false, M(v));17 PageScanMode18 for each smaller slave w19 do Wait Page (v, w, slave, false, M(w));20 EXIT21 else Master(v)

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

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

BlueMesh Simulation Results I

BlueMesh Simulation Results II

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

Some other work (other than Trees & Mesh) BlueRing:

Forms a ring like network No routing required pass it on the ring Overcomes single and multi point failures Handles nodes joining / leaving

Disadvantages: Centralized algorithm leader election Assumes one hop network Changing direction to fix single point failures

increase network traffic unnecessarily

BTSpin – our proposal

Distributed and Adaptive Single phase Scatternet formation

Main features

Distributed No leader required No distribution of unique weights

Single phase no topology discovery Spin technique

Grows piconet omni directionally Handles nodes joining Allocates substantial time for intra-piconet traffic

Backup Gateways Handles nodes leaving / single point failures

Creates a multi-hop multi-path meshed network

Spin Technique

Used to maintain balance between Scatternet formation and intra-piconet data communication.

Spin = INQ phase followed by INQ SCAN phase. Spin node obtains parameters like size of Piconet,

Master ID Master puts “Spin” slave in hold mode. Master itself also “spins” Slave-Slave bridges are not scheduled for spin.

Definition of 2-hop & 3-hop connection

(i) A & B are two hop connected (ii) A & B are three hop connected

Free node meets with a Slave node

Slave node meets with a Slave node

Slave node meets with a Master node

Master node meets with a Master node

Master node meets a M-S Bridge node

Backup Gateway

We observed other multi-phased, meshed based approaches have large number of “temporary” piconets

BTSpin keeps a backup gateway table When two connected nodes disconnect

without forming a bridge ,the information about Master ID ,FHS and type of node is recorded

Used later to directly page ‘potential” bridge nodes without INQ & INQ SCAN phase

Node Failures

Slave node – do nothing Master node – If not Bridge it becomes free

node, Bridges continue their role in the other piconet.

Bridge node – if Slave-Slave bridge use backup information.

Scatternet formation delay

Total number of Piconets

Average number of roles

References G. Tan, A. Miu, J. Guttag, H. Balakrishnan, “Forming Scatternets from Bluetooth

Personal Area Networks”, in Technical Report – MIT-LCS-TR-826, October 2001 Ching Law and Kai-Yeung Siu. A Bluetooth scatternet formation algorithm. In

Proceedings of the IEEE Symposium on Ad Hoc Wireless Networks 2001, San Antonio, Texas, USA, November 2001.

Ching Law, Amar K. Mehta, and Kai-Yeung Siu. Performance of a new Bluetooth scatternet formation protocol. In Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing 2001, Long Beach, California, USA, October 2001.

Ching Law, Amar K. Mehta, and Kai-Yeung Siu. A new bluetooth scatternet formation protocol. ACM Mobile Networks and Applications Journal, 2002.

S. Basagni and C. Petrioli, “A scatternet formation protocol for ad hoc networks of Bluetooth devices,” in Proceedings of the IEEE Semiannual Vehicular Technology Conference, VTC Spring 2002, Birmingham, AL, May 6–9 2002.

C. Petrioli and S. Basagni, “Degree-Constrained Multihop Scatternet Formation for Bluetooth Networks”, in Proceedings of IEEE Globecom, 2002, Taipei, Taiwan, R.O.C., November 2002

Ting-Yu Lin, Yu-Chee Tseng, Formation, Routing, and Maintenance Protocols for the BlueRing Scatternet of Bluetooths, 36th Annual Hawaii International Conference on System Sciences (HICSS 2003)

Bluetooth Implementation: Practical Considerations Use two IAC types

Repetition: IAC are the ID packets a master sends in INQ state

Two types: GIAC and LIAC Nodes can filter different IAC types Roots only transmit and receive LIAC, other

nodes only GIAC This can still lead to a bad connection

because the FHS packets can not be distinguished. We have to tear down this bad connection when we discover that the types are incompatible.

Back

Connection Establishment

Back

Review-Piconets

Set of Bluetooth devices (each has clock and unique bluetooth device address BDA)

1 master, up to 7 slaves (why ?) Communication only via master Time Divison Duplex (TDD)

Polling – master allocates time slots for slaves Pseudo-random frequency hopping scheme to

minimize interference e.g. with other piconets Pseudo – 32 frequencies chosen out of 79 allowed ones

Back