Download IEEE 802.15 - Survey of Scatternet Formation

-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
S
S
M
B
S
S
S
S
S
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
?
?
?
M
?
M
Criteria for efficient Scatternet Formation

Number of Piconets
 Scatternet should have minimum number of Piconets



Number of Roles per node
 The number of roles per node should be minimized


Reduces the inefficient intra-piconet communication
Reduces co-channel interference
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


Message Overhead
 Minimize control packet overhead



Lower ASP  better routing efficiency
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!)
Classification of Scatternet Protocols
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 phaseBluestar,
BTSpin
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:



All nodes spend time in this state


Every node tries to make a link to another node belonging to a different
tree/component
Two substates FORM:INQ and FORM:INQSCAN
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….
Mas/Slav
Root
Non-Root
Free
Root
1
0
0
Non-root
0
0
1
Free
0
1
1
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 energyintensive 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


Phase II


Topology discovery
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)
6
3
23
28
9
34
15
12
5
7
14
42
1
4
10
35
51
8
32
Init Node
45
19
Non-Init Node
Example Network : Phase II (piconets)
6
3
23
28
9
34
15
12
5
7
14
42
1
4
10
35
51
Master
32
Slave
8
45
19
III. BlueConstellation formation

mNeighbors

Neighboring masters that are atmost 3 hops away



iMasters


2 hops: 1 slave in between 2 masters
3 hops: 2 slaves in between 2 masters
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)
6
3
23
28
9
34
15
12
5
7
14
42
1
4
10
35
32
51
Master
Slave
Slave-Bridge
8
45
19
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


Symmetric 1-hop neighbor information


Weight signifies node’s suitability as master
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  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
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
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)
Iterative Process: Gateway Selection

Slaves tell Masters:




Masters decide:



Neighbor roles
Neighbor’s list of Masters
Whether any neighboring Master selected them as slave
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




Single phase  no topology discovery
Spin technique




Grows piconet omni directionally
Handles nodes joining
Allocates substantial time for intra-piconet traffic
Backup Gateways


No leader required
No distribution of unique weights
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