Scatternet Formation - Ausarbeitung zum Seminarvortrag der Abteilung Rechnernetze, WS2001/02 Roland Gronarz
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Scatternet
Formation
Aufbau von Bluetooth AdHoc-Netzwerken
Ausarbeitung zum Seminarvortrag der Abteilung
Rechnernetze, WS2001/02
Roland GronarzInhaltsverzeichnis
1. Einleitung .......................................................................................................................2
1.1. Über dieses Dokument ............................................................................................2
1.2. Bluetooth ................................................................................................................2
1.3. Technische Eigenschaften .......................................................................................3
1.4. Motivation ..............................................................................................................4
1.5. Stand der Dinge ......................................................................................................5
1.6. Problemstellung ......................................................................................................5
1.7. Formalismen ...........................................................................................................5
1.8. Effizienzanforderungen...........................................................................................6
2. Scatternet Formation mit Bluetrees .................................................................................7
2.1. Voraussetzungen.....................................................................................................7
2.2. Erstellen von Bluetrees mit einer Wurzel ................................................................7
2.3. Begrenzung der Anzahl Slaves eines Master ...........................................................8
2.4. Variante: Verteilte Bluetrees ...................................................................................9
2.5. Bewertung ............................................................................................................10
3. Das Blueroot Topology Construction Protocol (BTCP).................................................11
3.1. Der Algorithmus........................................................................................................11
3.2. Bewertung .................................................................................................................13
4. Scatternet Formation mit Komponenten (NewTCP)......................................................13
4.1. Überblick...................................................................................................................13
4.2. Der Algorithmus........................................................................................................14
4.3. Erweiterung für dynamische Umgebungen.................................................................17
4.4. Bewertung .................................................................................................................17
5. Zusammenfassung ........................................................................................................18
6. Quellen.........................................................................................................................18
1. Einleitung
1.1. Über dieses Dokument
Bei diesem Dokument handelt es sich um eine Ausarbeitung zu einem Seminarvortrag in
der Abteilung Rechnernetze der Universität Bonn im Wintersemester 2001/02.
Kapitel 1 bietet einen Einstieg in die Thematik Bluetooth, Scatternets und
Effizienzkriterien.
Kapitel 2, 3 und 4 beschreiben jeweils verschiedene Ansätze zur Scatternet Formation auf
Basis wissenschaftlicher Ausarbeitungen [3], [4], [5].
1.2. Bluetooth
Bluetooth ist ein Kommunikationsstandard für drahtlose Funkkommunikation, der einen
Datenaustausch zwischen allen denkbaren Gerätetypen ermöglichen soll. Ob Notebook,
Organizer, Mobiltelefon oder Peripheriegeräte von Computern, alles soll durch Bluetooth die
Fähigkeit erhalten, miteinander kommunizieren zu können. Bluetooth arbeitet in der
stromsparenden Variante über Reichweiten von bis zu 10 Metern. Und auch eine Ad-hoc-
Vernetzung verschiedener Geräte ist vorgesehen, allerdings noch nicht genauer spezifiziert.
Dieses Dokument befasst sich vor allem mit dem Aufbau von Ad-hoc-Netzen, der
sogenannten Scatternet Formation.1.3. Technische Eigenschaften
Bluetooth Geräte operieren auf 79 Kanälen mit jeweils 1 MHz Bandbreite im 2.45 GHz
Frequenzbereich. Bei der Kommunikation wird nicht ständig ein und der selbe Kanal benutzt,
sondern es wird 1600 mal in der Sekunde die Frequenz gewechselt (Frequency Hopping), um
Interferenzen zu anderen Geräten auszugleichen. Dies ist notwendig, da das benutzte
Frequenzband frei verfügbar ist.
Wesentliche Eigenschaften eines Bluetooth Gerätes sind zum einen eine innere Uhr
(Clock), welche die Taktung bei den Frequenzsprüngen vorgibt, sowie eine eindeutige
Bluetooth Device Adress. Aus dieser ergibt sich dann auch die Identität des Gerätes, welche
die verschiedenen Frequenzen der Hopping-Sequence festlegt.
Bei der Verbindung zweier Bluetooth Geräte übernimmt eines die Rolle des Master und
das andere die Rolle des Slave. Dabei ist zu beachten, dass es so etwas wie dezidierte Master
oder Slave Geräte nicht gibt, die Rollenverteilung findet dynamisch beim Verbindungsaufbau
statt. Der Master legt verbindlich für den Slave die Hopping-Sequence, also die „Sprünge“
zwischen den Frequenzen, fest und verteilt Senderechte.
Beim Verbindungsaufbau werden zwei Phasen durchlaufen.
Verbindungsaufbau, Phase 1: INQUIRY
Die INQUIRY-Methode wird dann verwendet, wenn nach noch nicht entdeckten Geräten
gesucht werden soll, über die noch keinerlei Informationen vorliegen.
Solange keine Verbindung besteht, wechselt ein Bluetooth Gerät ständig zwischen den
Zuständen INQUIRY (Anfrage) und INQUIRY SCAN (suche nach Anfrage).
Im Zustand INQUIRY springt das Gerät zwischen 32 Frequenzen und schickt seine
Suchanfrage aus. Im Zustand INQUIRY SCAN springt das Gerät ebenfalls zwischen 32
Frequenzen und sucht nach einer INQUIRY-Nachricht. Empfängt ein Gerät im Zustand
INQUIRY SCAN eine solche Anfrage, so antwortet es, indem es seine Adresse und seine
Clock übermittelt, und eine Kommunikation kann beginnen. Die Rollenverteilung ist dabei so
festgelegt, dass das anfragende Gerät Master und das andere Slave wird.
Verbindungsaufbau, Phase 2: PAGE
In dieser Phase befindet sich der Master im Zustand PAGE (Ruf) und der Slave im
Zustand PAGE SCAN (Suche nach Ruf). Voraussetzung ist, dass dem Master die Bluetooth-
Device Adress des Slave bekannt ist. Der Page-Vorgang kann beschleunigt werden, wenn
dem Master neben der Adresse auch die Clock des Slave vorliegt. Der Master übermittelt dem
Slave seine eigene Taktung und Hopping-Sequence und weist ihn an, diese zu übernehmen.
Der Slave synchronisiert sich daraufhin auf den Master und kann so mit ihm kommunizieren.
Piconets
Ein Piconet besteht aus einem Master und bis zu sieben aktiven Slaves. Ein Master kann
prinzipiell mehr als sieben Slaves kontrollieren, indem er einige Slaves in eine Art
Schlafmodus schickt. Dies kann den Datenaustausch allerdings erheblich verlangsamen, vor
allem, wenn ein aktiver Slave Daten an einen Schläfer schicken will.
Die Kommunikation läuft hierbei grundsätzlich ausschließlich über den Master, welcher
Senderechte verteilt und die zu nutzenden Frequenzen vorgibt. Eine Master-Master oder
Slave-Slave Kommunikation ist nicht möglich.
Der Master verteilt abwechselnd Senderechte an die einzelnen Slaves.S
S
M
S
S
Abb. 1.1: Ein Piconet
Scatternets
Wegen der Anwendung von Frequency-Hopping ist eine Koexistenz mehrer Piconets
nebeneinander möglich. Dabei kann ein Gerät B sogar Mitglied in mehreren Piconets sein.
Dazu speichert B einfach die Hopping-Sequence aller Master, in deren Piconet B Mitglied ist
und kann sich so auf die Frequenz eines jeden Piconet einstellen. Ein solches Gerät wird als
Bridge-Node bezeichnet, da es quasi eine Brücke zwischen Piconets darstellt. Mehrere, auf
diese Weise verbundene Piconets bilden ein Scatternet. Dabei kann ein Gerät M zwar Master
in einem Piconet und Slave in einem anderen sein, jedoch niemals die Master-Rolle für zwei
Piconets übernehmen, da ja sonst beide nach der Hopping-Sequence von M arbeiten würden
und somit ein und dasselbe Piconet wären.
Master
Bridge
Slave
Abb 1.2: Ein Scatternet
Anders als bei Wireless LAN gibt es bei Bluetooth Scatternets keine von vorneherein
festgelegten oder gar statischen Master-Nodes, welche die Kommunikation im Netzwerk
koordinieren.
1.4. Motivation
Ursprünglich wurde der Bluetooth Standard entwickelt, um eine drahtlose
Kommunikation verschiedenster Geräte über kurze Entfernung zu ermöglichen. Erst mit der
Zeit kam der Bedarf an einer Vernetzung von Bluetooth Geräten, der Erstellung eines
sogenannten adhoc-Netzwerks. Beispielsweise befinden sich mehrere Teilnehmer eines
Seminars mit Bluetooth-fähigen Geräten in einem Raum und diese Personen möchten ihre
Daten untereinander austauschen. Idealerweise würde nun jeder Teilnehmer einen Befehl der
Art „Baue Verbindung zu Adhoc Netzwerk auf“ ausführen, nach kurzer Zeit eine Meldung„Verbindung zu Adhoc Netzwerk steht“ erhalten und daraufhin den Datenaustausch mit
beliebigen anderen Teilnehmern aufnehmen können.
Dabei gibt es allerdings einige Probleme:
• Wie soll ein Bluetooth Netzwerk aufgebaut werden?
• Wie soll Routing geschehen?
• Wie soll auf räumliche Bewegung von Geräten reagiert werden, nachdem der
Netzwerkaufbau abgeschlossen ist?
Dieses Dokument beschäftigt sich vor allem mit dem Aufbau eines Bluetooth Netzwerkes,
der Scatternet Formation.
Dieses Gebiet ist noch Teil der Forschung, einen einheitlichen Standard gibt es noch nicht.
In den Kapiteln 2, 3 und 4 werden drei verschiedene Ansätze zur möglichst effizienten
Scatternet Formation beschrieben.
1.5. Stand der Dinge
Aktuelle Bluetooth Geräte haben noch nicht die Möglichkeit, zwischen Piconets hin- und
herzuschalten, dies soll erst in zukünftigen Bluetooth-Implementationen realisiert werden.
Ein reales Bluetooth Scatternet ist also noch nicht implementierbar. Dies hat zur Folge, dass
die Bewertungen der vorgestellten Algorithmen auf Simulationen basieren und eben noch
nicht in „Real Life“ getestet werden konnten.
Dabei ergibt sich dann auch die Frage nach der Vollständigkeit der vorliegenden
Simulationsergebnisse.
1.6. Problemstellung
Ausgangspunkt ist eine Menge von Bluetooth Nodes, die initial nur wissen, dass sie Teil
eines Adhoc Netzwerkes werden sollen. Informationen über Anzahl der Nodes, der Nachbarn
und so weiter sind anfangs nicht verfügbar und müssen im Laufe eines Protokolls in
Erfahrung gebracht werden. Nach Beendigung des Protokolls soll ein vollständig verbundenes
Scatternet vorhanden sein. Vollständig verbunden heißt hierbei, dass erstens alle Nodes in das
Netzwerk integriert sind und zweitens dass es zwischen allen Nodes mindestens einen
Kommunikationspfad gibt.
Die Wahrscheinlichkeit für ein Versagen des Protokolls, was beispielsweise in einem
nicht vollständig verbundenen Scatternet bestehen würde, muss dabei auf ein hinreichend
kleines Maß reduziert werden.
Neben diesen grundsätzlichen Anforderung gibt es noch eine Reihe von Constrains, die in
1.8. erläutert werden.
1.7. Formalismen
In den folgenden Algorithmen werden zur Veranschaulichung Digraphen G = (V,E)
verwendet. In diesen werden die Bluetooth-Geräte als Knoten (im weiteren Verlauf als Nodes
bezeichnet) aufgefasst. Master-Slave Beziehungen werden als gerichtete Kanten (M,S)
dargestellt. Farben kennzeichnen die Funktion der einzelnen Nodes:
• Dunkelblauer Node = Master
• Hellblauer Node = Slave
• Oranger Node = BridgeDabei stellt die Anordnung der Nodes nicht zwangsläufig die tatsächliche Topologie der
Bluetooth-Geräte dar.
1.8. Effizienzanforderungen
Eine vergleichende Bewertung der vorgestellten Protokolle erweist sich als schwierig. Die
vorliegenden Informationen enthalten zwar Simulationsergebnisse, allerdings konzentrieren
diese sich dabei jeweils auf unterschiedliche Aspekte der Scatternet Formation, so dass ein
direkter Vergleich zweier Protokolle nur sehr begrenzt möglich ist.
Grundsätzlich gibt es zwei Gesichtspunkte, nach welchen ein Scatternet Formation
Protocol beurteilt werden kann.
Zum einen kann man die eigentliche Scatternet Formation betrachten und dort Größen
wie Geschwindigkeit oder Wahrscheinlichkeit für Korrektheit feststellen. Zum anderen ist
natürlich auch die Topologie des entstehenden Ad hoc Netzwerkes von Interesse, da hiervon
vor allem Übertragungszeiten zwischen einzelnen Nodes abhängen.
Folgende Auflistung soll einen Überblick über die verschiedenen Anforderungen an ein
Scatternet Formation Protocol geben.
• Korrektheit:
Das Protokoll sollte natürlich alle Geräte in Reichweite in das Netzwerk
integrieren. Dabei sollte die Wahrscheinlichkeit, dass ein Gerät nicht integriert
wird, „hinreichend klein“ sein, bestenfalls sogar gleich null sein. Zusätzlich soll
das Scatternet vollständig verbunden sein.
• Geschwindigkeit:
Die Scatternet Formation sollte in „akzeptabler“ Zeit stattfinden. Es wird sich
zeigen, dass Korrektheit und Geschwindigkeit konkurrierende Constrains sind.
• Mobilität:
Es ist wünschenswert, dass das entstandene Scatternet ein gewisses Maß an
Toleranz gegenüber Bewegungen der einzelnen Geräte aufweist. Würde die
Verbindung zu einem Gerät abbrechen, wenn es bewegt wird, oder sogar das
ganze Scatternet zusammenbrechen, so würde dies die praktische Anwendbarkeit
des Bluetooth Adhoc Netzwerkes stark einschränken.
• Flexibilität:
Müssen alle Geräte gleichzeitig mit der Scatternet Formation beginnen? Wäre es
vielleicht sogar möglich, ein Gerät nach Beendigung des Protokolls trotzdem noch
in das Netzwerk zu integrieren? Was geschieht, falls ein Gerät ausfällt?
• Beschränkung für Bridge-Nodes:
Jeder Bridge-Node sollte in so wenig Piconets wie möglich sein, bestenfalls in
zwei. Die zeitliche Overhead für das Routing über eine Bridge wächst mit jedem
Piconet, an welchem die Bridge teilnimmt. Dies liegt zum einen daran, dass die
Bridge zu jedem Zeitpunkt in nur einem Piconet „lauschen“ kann und zum
anderen, dass in den Wechselzeiten, in denen sich die Bridge auf ein anderes
Piconet synchronisiert, keinerlei Kommunikation mit der Bridge stattfinden kann.[6]
• Beschränkung für die Zahl der Piconets:
Je weniger Piconets vorhanden sind, um so weniger groß ist die Anzahl an
verwendeten FH-Kanälen und damit sinkt die Wahrscheinlichkeit von Interferenz.
Außerdem sinkt mit der Anzahl der Piconets auch der „Network Diameter“, d.h.
die Länge eines maximalen Kommunikationspfades zwischen zwei Geräten.
• Reichweite:
Es würde die Einsetzbarkeit des Protokolls erheblich erhöhen, wenn es keine
zwingende Voraussetzung ist, dass alle Geräte paarweise in direkter
Kommunikationsreichweite sind.
2. Scatternet Formation mit Bluetrees
In diesem Abschnitt wird ein Lösungsansatz von drei Mitarbeitern der Universität Texas
beschrieben [3].
2.1. Voraussetzungen
Gegeben seien Bluetooth Nodes in einer räumlichen Umgebung. Nach Ausführung ihrer
Boot Sequenzen kennen alle Nodes die Anzahl und Identities (=Bluetooth Adressen) ihrer
Nachbarn. Die Menge der Nachbarn eines Node x besteht in diesem Fall aus allen Nodes, die
in der Kommunikationsreichweite von x liegen. Des weiteren wird gefordert, dass die
einzelnen Nodes nicht sehr stark bewegt werden.
2.2. Erstellen von Bluetrees mit einer Wurzel
Theorem – Zu jedem geographisch verbundenen Netzwerk gibt es mindestens ein
zugehöriges Bluetooth Scatternet, in welchem für jeden Node X gilt:
• X ist entweder Master, oder
• X ist Slave, oder
• X ist Master in einem Piconet und Slave in einem anderen und damit Bridge-Node.
Beweisen lässt sich dieses Theorem mittels folgendem Algorithmus.
Begonnen wird das Protokoll mit der Auswahl eines Nodes, der Blueroot. Diese Wurzel
übernimmt die Rolle eines Master. Nun wird ein Spannbaum auf folgende Weise aufgebaut:
1. Wähle einen noch nicht markierten Knoten t des Baumes
2. Falls dieser Knoten keine nicht markierten Nachbarn hat, so ist dieser Knoten Blatt
und hat damit die einzige Rolle eines Slaves.
Andernfalls hat t Nachbarn, für die er jetzt die Rolle des Master übernimmt. Dadurch
übernehmen die Nachbarn alle die Rolle des Slave. Sofern t nicht die Blueroot ist, ist t
innerer Knoten des Bluetree und hat damit die Rollen Master/Slave.
3. Markiere t
4. Falls es noch nicht markierte Knoten gibt, gehe zu Schritt 1.Es wird vorausgesetzt, dass jedem Node bekannt ist,
• Ob er Blueroot ist oder nicht
• Wie die Adressen seiner Nachbarn sind (lässt sich durch INQUIRY
herausfinden)
• Ob sie bereits Teil eines Piconet im resultierenden Scatternet sind
Die vorliegenden Informationen schweigen sich darüber aus, wie man einen eindeutigen
Knoten als Blueroot auswählen kann. Eine Möglichkeit wäre der unter ?? beschriebene
Algorithmus zur „Leader Election“. Dies funktioniert allerdings nur, wenn alle Geräte
paarweise miteinander kommunizieren können, was bei der Scatternet Formation mit
Blueroots nicht explizit vorausgesetzt wird.
Wird ein Node von einem anderen gerufen („page“) und ist noch nicht Teil eines Piconet,
so akzeptiert er und wird Slave des ihn rufenden Nodes. Andernfalls wird er den rufenden
Knoten entweder ignorieren, oder er wird ihn sofort davon unterrichten, dass er bereits Teil
eines Piconet ist und die Kommunikation abbrechen. Sobald ein Knoten die Funktion eines
Slave übernommen hat, beginnt er seine Nachbarn zu rufen und so weiter.
2.3. Begrenzung der Anzahl Slaves eines Master
Problem: Obiger Algorithmus kann bei der tatsächlichen Implementierung in Bluetooth
versagen, da ein Master maximal sieben Slaves kontrollieren kann. Was ist, wenn ein Node
mehr als sieben Nachbarn hat?
Um eine Lösung für dieses Problem zu entwickeln, macht man zuerst folgende
Beobachtung: Hat ein Bluetooth-Node n in einer offenen, interferenzfreien Umgebung
mehr als fünf Nachbarn, so gibt es unter diesen wenigstens zwei Nodes, die selber Nachbarn
sind.
Beweis: Wähle unter den nach Voraussetzung mehr als fünf Nachbarn von n sechs aus. Im
worst case haben alle Nachbarn maximalen Abstand voneinander. In diesem Fall bilden sie
ein perfektes Sechseck um den Knoten n. In einem solchen ist aber der Radius genauso groß
wie die Kantenlänge. Also haben die benachbarten Eckpunkte zueinander den gleichen
Abstand wie ein Eckpunkt zum Mittelpunkt.
Diese Beobachtung kann nun dazu verwendet werden, die Anzahl der Slaves, die ein
Master im Scatternet kontrollieren soll, auf fünf zu beschränken:
Sei m ein Master mit mehr als fünf Slaves. m kann sicher sein, dass mindestens zwei
seiner Slaves eine eigenständige Beziehung aufbauen können. Der Master m pollt nun seine
Slaves an, um die Identifier ihrer Nachbarn zu erhalten. m kann nun zwei seiner Slaves s1 und
s2 auswählen und ihnen die Aufgabe zuteilen, eine eigenständige Verbindung aufzubauen.
Dabei wird s1 Master von s2. s1 sollte dabei so ausgewählt werden, dass er der Node mit der
kleinsten Anzahl eigener Slaves ist.2.4. Variante: Verteilte Bluetrees
Um eine bessere Verteilung der Verbindungen zu erreichen gibt es folgende Variante der
unter 2.3. beschriebenen Technik: Anstatt einem einzigen großen Bluetree werden hier
zunächst mehrere kleine erstellt und diese dann letztendlich mit dem gleichen Algorithmus
verbunden.
Phase 0: Auswahl der Blueroots
Initial werden mehrere Blueroots ausgewählt und zwar so, dass sie möglichst verteilt
liegen. Dies kann dadurch sichergestellt werden, dass alle Nodes ihre Identifier mit denen
ihrer Nachbarn vergleichen. Hat ein Node den höchsten Identifier unter seinen Nachbarn, so
ernennt sich selber zur Blueroot.
Phase 1: Erstellen der Scatternets
Danach wird in jedem Blueroot der unter 2.3. beschriebene Algorithmus mit folgenden
Modifikationen gestartet:
• Bei Etablierung einer Intra-Piconet Verbindung wird der neu hinzugenommene
Slave über den Identifier der Blueroot des zugehörigen Baumes informiert
• Werden Nodes gerufen, die bereits Teil eines Piconet sind, so werden
Informationen über die jeweiligen Blueroots zwischen rufendem und
antwortendem Node ausgetauscht. Diese Knoten stellen potentielle Bridge-Nodes
für die Verbindung der Scatternets in Phase 2 dar.
Die in Phase 1 gesammelten Informationen werden in Phase 2 benötigt werden.Phase 2: Verbinden der Scatternets
Es wird nun ein neuer virtueller Graph erstellt, in welchem die in Phase 1 erstellten
Scatternets als Knoten aufgefasst werden. Auf diesen Graphen wird nun wiederum
Algorithmus 2.3. angewandt. Um eine Verbindung zwischen zwei Scatternets zu erstellen
werden die Informationen aus Phase 1 benötigt. Die Koordination läuft dann jeweils über die
Blueroots der einzelnen Scatternets.
2.5. Bewertung
Der große Vorteil dieses Protokolls (vor allem der Variante mit verteilten Bluetrees) liegt
in seiner Anwendbarkeit für Scatternets mit einer sehr großen Anzahl Nodes. Simulationen
zeigen, dass dieses Protokoll für 2000 Nodes eine Scatternet Formation durchführen kann.
Außerdem fällt für die Variante die Forderung nach paarweiser Erreichbarkeit weg, welche
bei sehr großen Scatternets auch kaum erfüllbar ist.
Average Route Errors
Zur Qualität des entstehenden Scatternets wurden in der Simulation „Average Route
Errors“ betrachtet. Diese sind ein Maß für die Länge von Kommunikationspfaden und geben
die durchschnittliche Abweichung vom Idealfall (berechnet durch einen Kürzesten Wege
Algorithmus angewandt auf den Topologie-Graphen) an. Ein ARE-Wert von 4 würde
beispielsweise bedeuten, dass jede Route im tatsächlichen Scatternet um 4 Hops größer ist als
im Idealfall.3. Das Blueroot Topology Construction Protocol (BTCP)
Dieser Algorithmus zur Scatternet Formation hat eine besondere Voraussetzung: Alle
Geräte müssen paarweise in ihrer Kommunikationsreichweite liegen [3].
3.1. Der Algorithmus
Phase 1: Wahl des Koordinators
In dieser Phase wird ein eindeutiger Node ausgewählt, welcher die spätere Scatternet
Formation koordiniert. Am Ende dieser Phase wird dieser „Koordinator“ die Anzahl,
Identifier und die Taktung aller am Netzwerk teilnehmenden Nodes kennen.
Jeder Node x speichert in einer Variable VOTES die Anzahl der Stimmen, die er schon
erhalten hat. Initial hat jeder Node einen VOTES-Wert von 1. Nu beginnt jeder Node damit,
zwischen den Zuständen INQUIRY (Aussenden eines Verbindungswunsches) und INQUIRY
SCAN (Warten auf eintreffende Verbindungswünsche). Bei einer Verbindung zwischen zwei
Nodes kommt es zu einer Konfrontation: Der Node mit dem höheren VOTES-Wert (bzw. der
größeren Bluetooth-Adresse bei Gleichheit der VOTES) gewinnt die Auseinandersetzung und
addiert die VOTES-Werte des Verlierers zu seinen eigenen hinzu. Der Verlierer geht in den
PAGE SCAN Modus über (wird in Phase 2 und 3 benötigt) und wird von nun an alle
INQUIRY-Rufe ignorieren. Der Gewinner alterniert wieder zwischen den Zuständen
INQUIRY und INQUIRY SCAN.
Gibt es in der Scatternet Formation N Nodes, so steht nach N-1 Konfrontationen der
Koordinator fest.
Bereits in dieser Phase wird die Notwendigkeit der oben angesprochenen Voraussetzung
klar: Seien X und Y Nodes, welche sich nicht direkt gegenseitig erreichen können. In einem
ungünstigen Fall bleiben X und Y in Phase 1 am Ende übrig, können aber nicht in die
Konfrontation eintreten, da sie ja nicht miteinander kommunizieren können. Beide Knoten
würden also annehmen, dass sie die Rolle des Koordinators haben und somit würde ein nicht-
verbundenes Scatternet entstehen.
An dieser Stelle gibt es allerdings ein Problem: Woher soll der Koordinator wissen, dass
er die Wahl gewonnen hat und in Phase 2 übergehen kann?
Dazu wird für jeden Node ein Timer eingeführt, welcher immer dann, wenn ein Node eine
Auseinandersetzung gewinnt oder gebootet wird auf den Initialwert ALT_TIMEOUT gesetzt.
Sobald der Timer abläuft geht der zugehörige Node davon aus, dass er die Wahl gewonnen
hat und Koordinator ist.
Was ist nun ein geeigneter Wert für ALT_TIMEOUT?
• Ein zu großer Wert würde dazu führen, dass der gewählte Koordinator noch lange
nach seiner Wahl im alternierenden Modus verbleibt. Daraus würde eine zu lange
Phase 1 resultieren.
• Ein zu kleiner Wert kann bewirken, dass mehrere Nodes fälschlicherweise von
einem Gewinn der Wahl ausgehen und es somit mehrere Koordinatoren gibt, was
zwangsläufig ein nicht vollständig verbundenes Scatternet zur Folge hätte.
Folgende Überlegungen können bei der Bestimmung eines ALT_TIMEOUT-Wertes
behilflich sein: Da die Dauer eines Verbindungsaufbaus bei zwei Nodes den schlimmsten Falldarstellt, kann diese als Basis für die Berechnung von ALT_TIMEOUT verwendet werden.
Aus Platzgründen wird auf eine detailliertere Betrachtung verzichtet.
Am Ende dieser Phase (also nach Ablauf von ALT_TIMEOUT beim Koordinator) sieht
die Situation folgendermaßen aus:
• Der Koordinator hat FHS-Pakete und damit Clock und Hopping Sequence aller an
der Scatternet Formation teilnehmenden Geräte. Er ist damit in der Lage, mittels
Page jedes dieser Geräte anzusprechen.
• Alle anderen Nodes warten im Zustand PAGE SCAN auf Anfragen
Phase 2: Rollenbestimmung
Zu Beginn dieser Phase überprüft der Koordinator die Anzahl N aller Nodes, die ihm ja
aus Phase 1 bekannt ist. Sollte N 8, so reicht ein
Piconet nicht mehr aus.
Da dem Koordinator sämtliche Informationen über alle Nodes vorliegen, kann er nun
eigenständig das Scatternet planen und die Rolle (Master, Slave, Bridge) eines jeden Nodes
festlegen.
Dabei geht der Koordinator folgendermaßen vor:
• Für ein Scatternet mit N Nodes werden mindestens
17 − 289 − 8 N
P= Master benötigt. Dies gilt für 1 ≤ N ≤ 36
2
Der Koordinator selektiert also P Nodes als Master.
• Des weiteren wählt er P(P-1)/2 Bridge-Nodes aus.
• Die restlichen Nodes bekommen die Rolle eines einfachen Slave zugeteilt.
Der Koordinator weist sich selber dabei grundsätzlich eine Master-Rolle zu.
Danach erstellt er für jeden ausgewählten Master x eine SLAVELIST(x) und eine
BRIDGELIST(x), welche alle x zugehörigen Slaves und Bridge-Nodes enthalten. Jeder der
Einträge der Liste enthält Adresse und Taktung (also die FHS-Pakete) der Nodes, so dass der
spätere Verbindungsaufbau sofort mit PAGE beginnen kann.
Daraufhin baut der Koordinator durch Paging eine Verbindung zu allen von ihm
bestimmten Mastern auf und übermittelt ihnen die SLAVELIST und BRIDGELIST. Sobald
die Master die Informationen erhalten haben beginnen sie mit Phase 3. Der Koordinator
verliert seine Rolle und geht als Master ebenfalls in Phase 3 über.
Phase 3: Verbindungsaufbau
Jeder Master baut nun gemäß seiner SLAVE/BRIDGELIST eine Verbindung zu den ihm
zugeordneten Nodes auf und teilt diesen ihre Rolle mit. Dabei beginnt er mit den reinen
Slaves und fährt erst danach mit den Bridge-Nodes fort. Sobald ein Node darüber informiert
wird, dass er Bridge-Node ist, wartet er auf die Verbindung mit seinem zweiten Master. Ist
dies geschehen, so schickt er an beide Master eine Nachricht „CONNECTED“. Hat ein
Master diese Nachricht von allen ihm zugeordneten Bridge-Nodes erhalten, wird das BTCP
beendet in diesem Master beendet und es ist sichergestellt, dass ein vollständig verbundenes
Scatternet entsteht.3.2. Bewertung
Im Gegensatz zur Scatternet Formation mittels Bluetrees ist dieses Protokoll nur für
relativ kleine Scatternets brauchbar. Dies liegt zum einen daran, dass alle Teilnehmer
während Phase 0 paarweise miteinander kommunizieren können müssen und zum anderen,
dass die in Phase 1 angewandten Formeln nicht mehr für N > 36 gelten.
Dauer der Formation
Die durchgeführten Simulationen mit dem BTCP konzentrieren sich auf die Dauer der
Scatternet Formation. Die Geschwindigkeit der Scatternet Formation mittels BTCP hängt
wesentlich von der Wahl von ALT_TIMEOUT ab.
Die vorliegende Abbildung zeigt die Dauer von Phase 0 in Abhängigkeit der Anzahl der
Nodes N.
Die Kurven „exp1000“ und „exp2000“ entstehen bei der Annahme, dass alle Benutzer
innerhalb von 1000 bzw. 2000 ms ihre Bluetooth-Geräte anweisen, an der Scatternet
Formation teilzunehmen. Die Kurve „no offset“ setzt voraus, dass alle beteiligten Geräte
gleichzeitig in Phase 0 eintreten.
Diese sehr flachen Kurven sprechen dafür, dass die Dauer der Scatternet Formation nicht
sehr stark mit der Anzahl der Geräte wächst. Eine Angabe der Größenordnung liegt allerdings
nicht vor.
4. Scatternet Formation mit Komponenten
4.1. Überblick
In diesem Ansatz werden Komponenten gebildet [4]. Eine Komponente besteht dabei• aus einem einzelnen Gerät, oder
• aus einem Piconet oder
• aus einem Scatternet.
Initial bestehen die Komponenten aus den einzelnen Nodes. Ziel ist es, die einzelnen
Komponenten zusammenzufügen, so dass am Ende nur noch ein einziges Scatternet
übrigbleibt.
Jede Komponente hat hierbei genau einen Leader.
• Ist die Komponente ein einzelnes Gerät, so ist dieses der Leader
• In einem Piconet ist der zugehörige Master der Leader
• In einem Scatternet ist einer der Master der Leader
Die Leader bestimmen jeweils die auszuführenden Aktionen und koordinieren die
Verschmelzungen der Komponenten. Alle Geräte, die keine Leader sind, verhalten sich
passiv. Ein Leader kann seine Rolle verlieren, indem er „zurücktritt“ (retires). Umgekehrt
kann einem Gerät die Leaderrolle übertragen werden, wobei immer gilt:
Ein Leader ist grundsätzlich Master eines (möglicherweise einelementigen) Piconets.
Als Formalismus wird noch für jedes Gerät v die Bezeichnung S(v) eingeführt, welche die
Menge aller Slaves von v angibt. Zusätzlich wird die Maximalzahl der aktiven Slaves eines
Masters die Variable k statt der Zahl Sieben verwendet, damit die Arbeitsweise des
Algorithmus leichter nachvollzogen werden kann. Bei allen Zeichnungen wird k=7
vorausgesetzt.
Folgende Bedingungen sind invariant gegenüber dem vorgestellten Algorithmus:
• Jeder Leader hat entweder keinen Slave, oder mindestens einen „ungeteilten“
Slave, der nicht Teil eines weiteren Piconet ist.
• Jeder Leader hat weniger als k Slaves in seinem Piconet.
Invariant bedeutet hier: Diese Bedingungen sind bei Start des Protokolls erfüllt und sind
nach jedem Schritt des Algorithmus ebenfalls erfüllt.
4.2. Der Algorithmus
Im Folgenden werden die Methoden beschrieben, mit welchen die Scatternet Formation
durchgeführt werden soll. Dabei wird so vorgegangen, dass ein Leader u entweder nach
anderen Komponenten Ausschau hält, oder einen seiner Slaves auffordert, anderen Leadern
auf ihre Suchanfrage zu antworten. Wird eine andere Komponente entdeckt, so werden die
beiden Komponenten mittels der Connected Funktion zu einer Komponente vereinigt.
Verhalten der Komponenten
Im Laufe der Scatternet Formation wenden die Komponenten mehrmals folgenden
Algorithmus an:
• Mit der Wahrscheinlichkeit p (1/3 < p < 2/3) suchen die Komponenten aktiv nach
anderen Komponenten. Dabei führt der Leader u solange INQUIRY aus, bis er
eine Antwort einer bis dahin unbekannten Komponente über deren Mitglied v
erhält. Der Leader verbindet sich dann mittels PAGE mit v. Daraufhin werden diebeiden Komponenten durch die CONNECTED-Methode zu einer Komponente
verschmolzen.
• Andernfalls (d.h. mit Wahrscheinlichkeit 1-p) lauscht die Komponente auf
Suchanfragen anderer Komponenten. Dabei gibt es zwei Fälle:
1. Leader u hat mindestens einen ungeteilten Slave w: Dann wird w durch u
angewiesen, INQUIRY SCAN auszuführen und bei Anfragen anderer
Komponenten in PAGE SCAN zu wechseln.
2. Leader u hat keinen ungeteilten Slave. Damit ist |S(u)|=0 (siehe Voraussetzung!)
und u ist dazu gezwungen, selber INQUIRY SCAN auszuführen.
CONNECTED(leader u, slave v)
Diese Methode stellt das Herzstück des Algorithmus dar, da hier die Zusammenlegung der
Komponenten stattfindet. Dazu müssen alle möglichen Konstellationen behandelt werden.
Man beachte, dass in jedem Fall die geforderten Voraussetzungen (Jeder Leader u mit |S(u)| >
0 hat mindestens einen ungeteilten Slave und |S(u)| < k für alle Leader u) invariant gegenüber
den angegebenen Algorithmen sind.
Fall 1: v ist selber Leader
Dann ist v isoliert, da v ansonsten nicht die SCAN-Methode aufgerufen hätte und u
demnach auch keine Verbindung zu v hätte aufbauen können.
Fall 1.1: |S(u)| < k
Dann ist im Piconet von u noch Platz für ein weiteres Gerät und v kann einfach
hinzugefügt werden:
v retires
Fall 1.2: |S(u)| = k
In diesem Fall ist u ausgelastet und gibt einen ungeteilten Slave y sowie seine
Leader Rolle an v ab. Dieser ungeteilte Slave existiert nach Voraussetzung.
MOVE({y}, u, v)
u retires
u u
y v
v
y
Fall 2: v ist Slave eines anderen Master w
Fall 2.1: |S(u) ∪ S(w)| + 1 < k
Im Piconet von u ist soviel Platz, dass sämtliche Slaves von w sowie w selber
aufgenommen werden können. u wird also Leader und Master aller Nodes vom
Piconet von w. Die Piconets werden „verschmolzen“.
MERGE(u, v, w)u w u w
v
v
Fall 2.2: |S(u)| = 1
u übernimmt v von w und fügt sich selber dem Piconet von w hinzu. Daraufhin
wird u Leader des so entstehenden Scatternet.
MOVE(u, NULL, w)
v disconnects from w
u w u w
v v
Fall 2.3: |S(u) ∪ S(w)| + 1 = k
Zunächst werden die Piconets wie in Fall 2.1 verschmolzen. Dies kann jedoch
nicht so bleiben, da sonst u genau k Slaves kontrollieren müsste. Daher wählt u
einen ungeteilten Slave y und übergibt diesen sowie seine Leader Rolle an v.
u retires
MERGE(u, v, w)
MOVE({y}, u, v)
v becomes leader
u w u w
v
y
v
y
Fall 2.4: alle sonstigen Fälle
u gibt solange Nodes an w ab, bis w keine weiteren Slaves mehr aufnehmen
kann (d.h. |S(w)| = k), oder bis die Anzahl der Slaves von u auf 2 gesunken ist.
Im ersten Fall wird u für den Rest der Scatternet Formation inaktiv.
MIGRATE(u, v, w)
u w u w
v v4.3. Erweiterung für dynamische Umgebungen
In der tatsächlichen Anwendung eines Scatternets ist es nahezu ausgeschlossen, dass alle
Geräte quasi gleichzeitig mit der Scatternet Formation beginnen, oder dass kein Gerät ausfällt.
Das beschriebene Protokoll erlaubt bereits die Integration neuer Geräte in das Scatternet,
indem diese als Leader starten und dann andere Komponenten entdecken bzw. von diesen
entdeckt werden. Einzige Voraussetzung dafür ist, dass der letzte Leader der Scatternet
Formation damit fortfährt, nach anderen Geräten zu suchen bzw. seine Slaves anzuweisen, auf
Suchanfragen zu reagieren.
Einzig der Ausfall von Geräten ist noch nicht vollständig ausgearbeitet, einige
grundlegende Gedanken wurden allerdings bereits formuliert:
• Bei Ausfall eines Masters kann einer seiner Slaves seine Rolle übernehmen. Falls
der Master Slave in einem anderen Piconet war, so wird der neue Master Leader
seines Piconet und integriert sich wie beschrieben in das Scatternet.
• Falls ein geteilter Slave ausscheidet, so wird der ihm zugehörige Master Leader
und integriert sein Piconet wieder in das Scatternet.
• Falls ein ungeteilter Slave ausscheidet, ist keine Aktion notwendig, außer dieser
Slave war der einzige ungeteilte Slave eines Leaders u. Dies wäre dann der
schlimmste Fall, der Leader müsste sich von seinen Slaves trennen, die anderen
Master würden wieder zu Leadern und der Rest würde wieder durch das vom
Protokoll vorgeschriebene Verhalten ausgeführt.
4.4. Bewertung
Dieses Protokoll bemüht sich um eine Minimierung der Anzahl Piconets. Außerdem ist
die Rollenzahl für jedes Gerät auf zwei beschränkt.
Anzahl an versendeten Nachrichten
Dies ist sowohl insgesamt, als auch für jedes einzelne Gerät zu prüfen, da die Zahl der
durch ein Gerät verschickten und empfangenen ein direkter Hinweis darauf ist, wie viel
Energie ein Bluetooth Gerät bei der Scatternet Formation benötigt. Gerade bei mobilen
Geräten wie Mobiltelefonen oder PDAs ist ein sparsamer Umgang mit Energie sehr
angebracht. Dabei lassen sich drei verschiedene Nachrichtentypen unterscheiden:
• Inquiries – Bluetooth INQUIRY und INQUIRY RESPONSE Pakete
• Pages – Bluetooth PAGE und PAGE RESPONSE Pakete
• Sonstige Nachrichten (z.B. Slave informiert seinen Leader über eintreffendes
INQUIRY Paket)
Simulationsergebnisse belegen, dass die Gesamtzahl der versendeten Nachrichten linear mit
der Anzahl der Nodes steigt, was zu einer Größenordnung von O(N) führt. Daraus folgt auch,
dass der durchschnittliche Energieverbrauch eines einzelnen Gerätes während der Scatternet
Formation nicht mit der Größe des Scatternets steigt.Die Anzahl der Nachrichten, die ein einzelnes Gerät verschicken muss, liegen in O(log N).
Der worst case trifft dabei genau den Leader, der als letzter zurücktritt.
Laufzeit
Zunächst stellt sich die Frage, wie viele Runden der Algorithmus benötigt, um das
Scatternet zu etablieren. Simulationen liefern einen Wert von 1,2log N + 2, was eine
Zeitkomplexität von O(log N) rechtfertigt.
Die Dauer der einzelnen Runden hängt von dem eingestellten Timeout-Wert ab. Dieser
sollte der Anzahl der Nodes angepasst sein. Simulationen haben gezeigt, dass ein Wert von
1,4 Sekunden für jede Runde bei 32 Nodes ausreichend ist.
5. Zusammenfassung
Alle der vorgestellten Protokolle erfüllen ihre Aufgabe, eine Menge von isolierten
Bluetooth Geräten zu einem Scatternet zu verbinden. Dabei wurden verschiedene
Schwerpunkte gesetzt.
Es ist schwer zu sagen, welcher der beschriebenen Ansätze der beste ist, für eine solche
Aussage kommt es auf die Anforderungen an.
Das Distributed Blueroot Construction Protocol eignet sich vor allem für sehr große
Netze, die über einen größeren räumlichen Bereich angesiedelt sind.
Das BTCP hat einen theoretischen Laufzeitvorteil gegenüber dem Komponenten-basierten
Protokoll, allerdings funktioniert BTCP nur korrekt bei paarweiser Erreichbarkeit der Geräte.
Als für den praktischen Einsatz am geeignetsten scheint das Komponenten-Protocol zu
sein, vor allem wegen der Möglichkeit, neue Geräte in ein bereits vorhandenes Scatternet zu
integrieren bzw. Geräte ausscheiden zu lassen, ohne dass das gesamte Netz zusammenbricht.
Allen vorgestellten Protokollen ist gemein, dass sie noch keine endgültige Lösung
darstellen, sondern weiterentwickelt werden müssen, um einen praktischen Einsatz zu
ermöglichen.
Die Bluetooth-Spezifikation erwähnt Scatternet-Unterstützung nur am Rande, eine
tatsächliche Lösung steht also noch aus.
6. Quellen
[1] The Bluetooth Radiosystem, Jaap C. Haartsen, Ericsson Radio Systems B.V., Februar
2000
[2] BLUETOOTH: A new radio interface providing ubiquitous connectivity, Jaap
C.Haartsen, Ericsson Radio Systems B.V.
[3] Bluetrees – Scatternet Formation to Enable Bluetooth-Based Ad Hoc Networks,
Gergely V. Záruba/Stefano Basagni/Imrich Chlamtac
[4] Distributed Topology Construction of Bluetooth Personal Area Networks, Theodoros
Salonidis/Pravin Bhagwat/Leandros Tassiulas/Richard LaMaire[5] Performance of a New Bluetooth Scatternet Formation Protocol, Ching Law/Amar K.
Mehta/Kai-Yeung Siu, Massachusetts Institute of Technology
[6] Performance Aspects of Bluetooth Scatternet Formation,
Gy.Miklos/A.Racz/Z.Turanyi/A.Valko,P.Johanson, Traffic Analysis and Network
Performance Lab, Ericsson Research, BudapestSie können auch lesen
