DE102006038896B4

DE102006038896B4 - Zeitsynchronisation und Beacon-Erzeugung für Mesh-Punkte, die in einem drahtlosen Mesh-Netz arbeiten

Info

Publication number: DE102006038896B4
Application number: DE102006038896A
Authority: DE
Inventors: Stephen P. Emeott; Hrishikesh Gossain
Original assignee: Motorola Inc
Current assignee: Arris Enterprises LLC
Priority date: 2005-08-24
Filing date: 2006-08-18
Publication date: 2012-03-01
Anticipated expiration: 2026-08-19
Also published as: CN1937556B; GB2429610A; GB2429610B; JP2007060670A; FR2893207A1; US7706822B2; DE102006038896A1; US20070050523A1; GB0616672D0; CN1937556A; FR2893207B1

Abstract

Verfahren zur Zeitsynchronisation und Beacon-Erzeugung für Mesh-Punkte, die in einem drahtlosen Mesh-Netz arbeiten, das umfasst: Übertragen einer Anzeige, ob der Mesh-Punkt die Synchronisation unterstützt (SynchSupp), in einem Synchronisationsfähigkeitsfeld von entweder einer Beacon- oder einer Probe-Antwort, Übertragen einer Anzeige, ob der Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (Synch-Req), in dem Synchronisationsfähigkeitsfeld, und Übertragen einer Anzeige, ob der Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (Synch-Peers), in dem Synchronisationsfähigkeitsfeld.

Description

Hintergrund
Der IEEE 802.11-Standard zum Zeitpunkt dieser Anmeldung stellt zwei Mechanismen vor, um die Zeitsynchronisation für Stationen bereitzustellen. In einem Infrastruktur-Betriebsmodus ist ein Zugangspunkt (access point = AP) die Zeitleitstelle des Basis-Servicesatzes (BSS), und die Stationen akzeptieren immer die Zeitsynchronisationsinformation des Beacons, das von der AP übertragen wird. In dem Betriebsmodus mit unabhängigem Basisservicesatz (independent basic service set = IBSS) wird die Zeitsynchronisationsfunktion (timing synchronisation function = TSF) von allen Stationen in einer verteilten Art und Weise durchgeführt, und die Stationen in einem IBSS nehmen die Zeitsteuerung, die von einer Beacon- oder Probe-Antwort empfangen wird, das einen TSF-Wert später als das eigene TSF-Timing hat.
Die Vielzahl der Vorrichtungen, die in einem Mesh zur Verfügung steht, gibt Anlass zu einer interessanten Herausforderung bei der Synchronisation und der Beacon-Erzeugung, weil es schwierig ist, eine strikte Klassifizierung von einigen Mesh-Einrichtungen durchzuführen. Während erwartet wird, dass ein Mesh eines drahtlosen Netzes für einen lokalen Bereich (wireless local area network = WLAN) das Konzept von der Beacon-Erzeugung bei auf BSS basierenden AP's und die IBSS-Stations-Beacon-Erzeugung wieder verwendet, muss den Vorrichtungen, beispielsweise einem Mesh-Punkt (MP), eine spezielle Aufmerksamkeit gewidmet werden, der ein drahtloses Gerät, das einen mit 802.11 konformen MAC und eine PHY-Schnittstelle zu einem drahtlosen Medium, das die Mesh-Dienste liefert, und ein Mesh-Zugangspunkt (mesh access point = MAP), der ein MP ist, der auch einen Zugangspunkt darstellt, und daher sowohl BSS als auch Mesh-Schnittstellenfunktionen unterstützt, sein kann. Beacon-Kollisionen zwischen mehrfachen MAP's und die Paketweiterleitung bei MP's mit Stromsparmodus (power safe = PS) gehören zu einigen Gebieten, die angesprochen werden müssen.
Die Druckschrift US 2005/0169233 A1 zeigt ein Verfahren zur Synchronisation des Systemtaktes zwischen Stationen in einem drahtlosen Ad-hoc-Netzwerk, bei dem ein Zeitstempel-Feld in einem Header verwendet wird, der von allen Stationen eines Netzwerks gelesen wird, die daraus die benötigte Zeitinformation gewinnen, diese an einen Taktgeber der Station schicken und den Takt entsprechend anpassen, wobei auf der Grundlage von IEEE 802.11 Beacon- und Probe-Antwort-Frames verwendet werden können.
Beschreibung der Ausführungsbeispiele
Der vorgeschlagene Beacon-Erzeugungsalgorithmus für Mesh-Netze umfasst Elemente des IEEE 802.11-Standards. Beispielsweise folgt der MAP einem Beacon-Erzeugungsalgorithmus in dem Infrastrukturmodus. Dies gibt dem MAP genügend Flexibilität, um seine eigenen BSS-Parameter auszuwählen, es ermöglicht ihm, ein Beacon bei jedem Beacon-Intervall zu übertragen, und es vermeidet seine Frequenzsynchronisation mit anderen MP's. Nicht-AP-Mesh-Geräte folgen andererseits dem IBSS-Betriebsmodus für die Beacon-Erzeugung, wenn sie mit anderen MP's synchronisiert sind.
Bezugnehmend auf 1 zeigt ein Systemdiagramm elektronische Geräte gemäß Ausführungsbeispielen der vorliegenden Erfindung, die in einem Mesh-Cluster 110 und in einem Infrastrukturnetz 105 arbeiten. In dem Infrastrukturnetz 105 arbeiten ein MAP 130 und eine Vielzahl von Basisservicesatzstationen s1 ... s4, einschließlich s4 125, die Legacy-Stationen sein können (eine Legacy-Station kann hier auch als STA bezeichnet werden). In dem Mesh-Cluster 110 arbeiten eine Vielzahl von Mesh-Geräten einschließlich MP1 115, MP2 135, MP3 140. Es ist zu beachten, dass sowohl das Mesh-Cluster 110 als auch das Infrastrukturnetz 105 erheblich mehr angeschlossene Geräte umfassen können, als in 1 gezeigt sind. Vom Konzept her kann ein MAP, beispielsweise der MAP 130, als Wurzel eines Baumes betrachtet werden, wobei alle die ihm zugeordneten Stationen, beispielsweise STA 125, als Zweige betrachtet werden. Die Nicht-AP-MP-Mesh-Geräte 115, 135, 140 (Mesh-Punkte, die keine Zugangspunkte sind) bilden ihr eigenes Cluster von Peer-zu-Peer-MP's in dem Mesh-Cluster 110. Ein Nicht-AP-MP kann auch einem oder mehreren AP-Geräten zugeordnet sein. Dies kann als Baum betrachtet werden, der mit einem Peer-zu-Peer-Cluster durch einen Schnittstellen-MP, beispielsweise den MP1 115, verbunden ist.
Ausführungsbeispiele der Erfindung stellen ein Zeitsynchronisations- und Beacon-Erzeugungsverfahren für Netzpunkte, die in einem drahtlosen Netz arbeiten, zur Verfügung, wobei die Beschreibung unter Verwendung eines WLAN-Mesh-Netzes als Beispiel erfolgt. Ein Nicht-AP-Mesh-Punkt, der gemäß der vorliegenden Erfindung aufgebaut ist, kann ein eine Mesh-Punkt-(MP)Synchronisationsfähigkeit betreffendes Feld in seinem Beacon übertragen, das eines oder mehrere der folgenden Unterfelder umfasst: Unterfelder, die anzeigen, ob er die Synchronisation unterstützt, ob er die Synchronisation von Peer-MP's anfordert und ob er bereits mit einem oder mehreren Peer-MP's synchronisiert ist. Eine Nicht-AP-MP kann anzeigen, dass er mit einem Peer synchronisiert werden kann, indem Bits in dem MP-Synchronisationsfähigkeitsfeld gesetzt wird, welches anzeigt, dass er die Synchronisation unterstützt und dass er die Synchronisation von Peers anfordert. Wenn zwei oder mehrere Nicht-AP-MP's sich dieser Unterstützungssynchronisation anschliessen und einer oder mehrere dieser MP's die Synchronisation mit ihrem Peer anfordern, werden diese MP's in Synchronisation gehen und Beacon unter Verwendung der IBSS-Synchronisation und den Beacon-Erzeugungsmerkmalen in dem IEEE 802.11-Standard erzeugen. Wenn keine der MP's zu erkennen gibt, dass sie sich der Synchronisation von Peers anschliessen, können beide ihre TSF unabhängig voneinander implementieren und Beacon unter Verwendung der Beacon-Erzeugungsfunktion erzeugen, die in dem IEEE 802.11-Standard für den Infrastrukturbetriebsmodus definiert ist. Ein MP, der es gestattet, dass Peers, die eine Unterstützung für PS-Dienste anfordern, sich anschließen, kann die Synchronisation unterstützen, und ein MP kann die Verbindung mit einem Peer zurückweisen, der beabsichtigt, in dem PS-Modus zu arbeiten, wenn der MP nicht anzeigt, dass er die Synchronisation unterstützt.
MAP-Kennwerte
Ein MAP tritt niemals in den PS-Modus ein, und er sollte nicht durch einen anderen MP synchronisiert werden. Ein MAP wählt sein Beacon-Intervall (BI) und die den Lieferverkehr anzeigende Karte(delivery traffic indication map = DTIM)-Perioden je nach seinen BSS-Bedürfnissen aus und startet seine TSF unabhängig von jeglichen gleichzeitig gestarteten MAP's. Ein MAP wird eine beliebige, zugeordnete MP, die in dem PS-Modus arbeitet, gleich wie die Legacy-Stationen (STA) behandeln, was bedeutet, dass der MAP annimmt, dass der MP im PS-Betrieb für den DTIM-Beacon des MAP aufweckt (was eine zeitgerechte Lieferung von gerichtetem und rundgesendetem Verkehr sicherstellt).
Nicht-AP-MP-Kennwerte
Wenn die Synchronisation eingeschaltet ist, können Nicht-AP-MP's als einfache STA's, die in dem IBSS-Modus arbeiten, mit zusätzlichen Mesh-Diensten betrachtet werden. Anderenfalls kann ein Nicht-AP-MP sein BI unabhängig auswählen und er kann seine TSF unabhängig von irgendeiner, gleichzeitig gestarteten MP starten.
Es ist für eine MP eine Option, den Stromsparmodus und die Synchronisation zu unterstützen. Wenn ein MP angibt, dass er die Synchronisation unterstützt, und dass er die Synchronisation mit Peers anfordert, wird er Beacons erzeugen und sich mit anderen Nicht-AP-MP's synchronisieren, als ob er in dem IBSS-Modus arbeitet, wie an anderer Stelle hier beschrieben wird. Andernfalls kann ein MP, der eine Unterstützung für die Synchronisation anzeigt, jedoch nicht mit Peers in Verbindung steht, die eine Synchronisation anfordern, unabhängig seine BI auswählen und seine TSF unabhängig von irgendeinem, gleichzeitig MP starten.
Jeglicher MP, der mit einem MAP in Verbindung steht und in den PS-Modus eintritt, muss für das DTIM-Beacons des MAP und zusätzlich für jegliches zusätzliche Beacon, das er empfangen muss, auf der Basis des Empfangsintervalls, das der MP mit dem MAP ausgehandelt hat, aufwachen. Wenn ein MP mit mehr als einem MAP in Verbindung steht, muss er für die DTIM-Beacons von jedem MAP zusätzlich zu jedem Mesh-TBTT aufwachen, der für seine synchronisierten MP-Nachbarn geplant sein kann. Ein MP, der es gestattet, dass Peers, die die Unterstützung für PS-Dienste anfordern, mit ihm in Verbindung treten, wird die Synchronisation unterstützen, und ein MP kann eine Verbindung mit einem Peer zurückweisen, der in dem PS-Modus arbeiten will, wenn er nicht in der Lage ist, die Synchronisationsdienste anzubieten.
Lightweight-MP-Charakteristiken
Ein Typ von Mesh-Punkt, der gegenwärtig in Vorschlägen für Mesh-Netze definiert ist, ist ein Lightweight-MP (LW-MP). Die Beacon-Erzeugung und das Synchronisationsverfahren für LW-MP's folgt dem IBSS-Modus der Beacon-Erzeugung und der Zeitsynchronisation. Wenn ein LW-MP eine Verbindung mit einem MAP herstellt und in den PS-Modus eintritt, muss er wenigstens für das DTIM-Beacon des MAP zusätzlich zu jeglichem Mesh-TBTT für seinen IBSS-Betrieb aufwachen. Alternativ kann ein Lightweight-MP eine Verbindung mit einem MAP als einfache STA aufbauen, wenn er in den PS-Modus eintreten will.
Zum Zwecke dieser Beschreibung kann ein Lightweight-Mesh-Punkt als ein Nicht-AP-Mesh-Punkt betrachtet werden. Ein Lightweight-MP sollte ein Synchronisationsfähigkeitsfeld in seinem Beacon übertragen, welches anzeigt, dass er die Synchronisation unterstützt und dass er die Synchronisation von seinen Peers benötigt.

Nicht-AP-MP's können ein MP-Synchronisationsfähigkeitsfeld in einem WLAN-Meshfähigkeitselement von allen übertragenen Beacon- und Probe-Antwortrahmen umfassen, welches anzeigt, ob er die Synchronisation unterstützen kann. Ein neues „MP-Synchronisationsfähigkeits”-Feld in dem WLAN-Mesh-Eigenschaftselement (Tabelle 1 wird verwendet, um anzugeben, ob ein Nicht-AP-MP die Synchronisation unterstützen kann, wenn eine Zeitsynchronisation von dem Peer-MP angefordert wird, und wenn der MP bereits mit einem anderen Peer-MP synchronisiert ist). Sie kann auch in Beacons enthalten sein, die von Nicht-AP-MP's übertragen werden, und sie ist auch in Probe-Antwort-Nachrichten enthalten

Feld	Betrag/Beschreibung
ID	T. B. D.
Länge	Variable
Version	1
Aktivprotokoll-ID	benutztes Wegauswahlprotokoll
Aktivmetrik-ID	benutzte Pfadauswahlmetrik
Peerfähigkeit	Peerfähigkeitswert
Stromsparfähigkeit	Unterstützung für Stromsparbetrieb und Stromsparstatus
Kanalvorläufer	Kanalvorläuferwert
Synchronisationsfähigkeit	Wenn Synchronisation durch diesen MP unterstützt wird

Tabelle 1: WLAN-Mesh-Fähigkeits-Elementfelder

Ein Format für das Synchronisationsfähigkeitsfeld ist in Tabelle 2 gezeigt.

Bits: 0 1 2 3–7

Unterstützt Synchronisation Fordert Synchronisation von Peer an Synchronisiert mit einem Peer-MP Reserviert

Tabelle 2: Synchronisationsfähigkeitsfeld
Das Unterfeld „Unterstützung von Synchronisation” zeigt an, ob der Nicht-AP-Mesh-Punkt eine Zeitsynchronisation mit Peer-MP's unterstützt. Das Unterfeld „Fordert Synchronisation von Peer an” zeigt an, ob dieser Mesh-Punkt es erfordert, dass Nicht-AP-MP-Peers, die versuchen, sich mit ihm in Verbindung zu setzen, sich mit seiner Zeitsynchronisationsfunktion (TSF) synchronisieren. Das Unterfeld „Synchronisiert mit einem Peer-MP” zeigt an, ob der Nicht-AP-MP gegenwärtig mit einem anderen MP in Verbindung steht, und ob die zwei MP's synchronisierte TSF's haben.
Zu einem vorgegeben Zeitpunkt kann ein Nicht-AP-MP in einem der zwei folgenden Zustände arbeiten:

• Synchronisierter Zustand (Synch): Der Synch-Zustand ist ein solcher, bei dem der MP mit wenigstens einem anderen Peer-MP synchronisiert ist oder der MP die Synchronisation mit Peers anfordert oder beides.
• Unsynchronisierter Zustand (UnSynch): Wenn ein MP nicht mit einem Peer-MP synchronisiert ist, und wenn der MP die Synchronisation mit Peer-MP's nicht anfordert, dann ist der MP in einem Zustand UnSynch.

Im Betrieb ist der Zustand UnSynch ähnlich dem Betrieb eines Legacy-AP. Ein MP kann jedoch je nach seinen Synchronisationserfordernissen von dem Zustand Synch in den Zustand UnSynch und umgekehrt umschalten. Wenn ein MP in dem Zustand Synch kein Beacon empfängt, wobei der Satz „Fordere Synchronisation für Peer an” während einer ausgedehnten Zeitdauer auf wahr gesetzt ist, kann der MP sich beispielsweise selbst in den Zustand UnSynch zurückversetzen und die Anzeige für die Synchronisation mit einem Peer-MP auf falsch setzen. Diese Periode wird „RETURN_TO_UNSYNCH_PERIOD”-Periode für die Rückkehr in den unsynchronisierten Zustand genannt. Der Wert dieser Periode ist ein Systemparameter und kann auf der Basis der Anzahl der MP's, der Netzdynamiken und der Verkehrsbedingungen in dem Mesh gewählt werden.
Die Zeitsynchronisationsfunktion (TSF) hält die Taktsignale der Nicht-AP-MP's mit anderen MP's in Synchronisation. Die TSF in einem Nicht-AP-MP kann über einen verteilten Algorithmus implementiert werden. Ein Nicht-AP-MP in einem WLAN-Mesh kann Beacons entsprechend dem hier beschriebenen Algorithmus übertragen. Ein synchronisierter Nicht-AP-MP in einem WLAN-Mesh kann die Zeitsteuerung von einer Beacon- oder einer Probe-Antwort nehmen, das einen TSF-Wert später als das eigene TSF-Timing hat, wenn entweder der Indikator für die Anforderung der Synchronisation von dem Peer oder der Indikator für die Synchronisation mit einem Peer-MP in dem Synchronisationsfähigkeitsfeld auf wahr gesetzt ist.
In jedem WLAN-Mesh, wo die MP's wahlweise eine Verbindung mit PS herstellen können, kann ein Nicht-AP-MP die Zeitsteuerung und jede andere relevante Information annehmen, die in einer Beacon- oder einer Probe-Antwort empfangen werden, das von MP's übertragen wird, die Mitglieder des gleichen Meshs sind, und nicht nur von Beacon- oder Probe-Antwort, die von einer zugeordneten MP übertragen werden.
Wenn MP's gemäß den Ausführungsbeispielen der vorliegenden Erfindung ausgeführt sind, sollte ein MAP keine Synchronisation mit einem anderen MP herstellen. Stattdessen sollte er seine Beacon-Intervallperioden und seine Perioden zur Lieferung der Verkehrsinformationsmap (DTIM) unabhängig auswählen, und er sollte seine TSF unabhängig von irgendeiner, gleichzeitig gestarteten MAP starten. MAP's treten niemals in einen Stromsparmodus ein (PS), und daher müssen sie nicht mit anderen MP's synchronisiert werden. Da ein MAP nicht mit MP's synchronisiert ist, die eine Synchronisation von Peers anfordern, wird ein MAP einen beliebigen, zugeordneten MP, der in dem PS-Modus arbeitet, genauso wie Legacy-Stationen (STA's) behandeln, was bedeutet, dass der MAP annimmt, dass der MP für das DTIM-Beacon des MAP im PS-Betrieb aufwacht (wodurch eine zeitgerechte Lieferung von gerichtetem und gesendetem Verkehr sichergestellt wird).
Aufrechterhaltung der Synchronisation – Beacon-Erzeugung
2 zeigt ein Flußdiagramm eines Verfahrens für die Nicht-AP-MP-Beacon-Erzeugung entsprechend Ausführungsbeispielen der vorliegenden Erfindung. Das Verfahren ist auch bei Lightweight-Mesh-Punkten anwendbar.
Das Verfahren des Beacon-(und Probe-Antwortsignal-)-Erzeugung, das von einem Nicht-AP-MP angenommen wird, hängt von dem Zustand (synchronisiert (Synch) oder unsynchronisiert (Unsynch)) ab, in dem er sich befindet, was an dem Schritt 215 festgestellt wird. Im Folgenden kann die Bezugnahme auf ein Beacon als eine Bezugnahme auf eine Beacon- oder Probe-Antwort interpretiert werden. Ein synchronisierter MP (wie an dem Schritt 215 bestimmt), der versucht, eine Beacon- oder Probe-Antwort zu übertragen, verwendet eine Beacon-Backoff-Funktion (Schritte 220, 225) ähnlich zu dem Zugangsverfahren, das für den IBSS-Betrieb in dem 802.11-1999 Standard (Abschnitt 11.1.2.2) und dem 802.11e-Entwurf beschrieben ist. Insbesondere kann ein MP, der ein Beacon nach einer Ziel-Beacon-Übertragungszeit (TBTT) von einem anderen MP (wie an dem Schritt 210 gemessen) empfängt, bevor er in der Lage ist, seine eigene zu senden, diese Beacon-Übertragung unterbinden (am Schritt 230), wenn dieser MP entweder das Flag für die Anforderung der Synchronisation von Peers oder das Flag für die Synchronisation mit einem Peer-MP in dem Synchronisationsfähigkeitsfeld auf wahr gesetzt ist (was an dem Schritt 225 aus dem Ausdruck „IS(SYNCPEERS//SYNCREG)” bestimmt wird und wahlweise, wenn die Bake von einem zugeschalteten MP (was an dem Schritt 225 aus dem Ausdruck „IS ASSOCIATED WITH (BEACON SENDER)„ bestimmt wird) empfangen wurde. Insbesondere treffen die folgenden Regeln für die Beacon-Übertragung zu.

a. Unterbrich die Abwärtszählung der Backoff-Timings für jeglichen Beacon-Verkehr.
b. Berechne eine beliebige Verzögerung gleichmäßig über den Bereich von Null bis zu dem zweifachen von „aCWminXaSlot time” („aCWminXaSlot time” ist eine im System definierte Dauer).
c. Warte während der Dauer der Zufallsverzögerung, wobei das Zufallsverzögerungs-Timing unter Verwendung des gleichen Algorithmus wie für das Backoff (an dem Schritt 220) heruntergezählt wird.
d. Wenn ein Beacon ankommt, bevor das Zufallsverzögerungs-Timing abläuft, lösche die restliche Zufalls-Timing-Verzögerung und die anstehende Beacon-Übertragung (an dem Schritt 230), wenn entweder das Flag für die Anforderung einer Synchronisation vom Peer oder das Flag für die Synchronisation mit einem Peer-MP in dem Synchronisationsfähigkeitsfeld des Beacon auf wahr gesetzt ist, und wahlweise, wenn das empfangene Beacon von einem zugeordneten MP empfangen wurde.
e. Sende ein Beacon (an den Schritt 235), wenn die Zufallsverzögerung abgelaufen ist und kein Beacon während der Verzögerungsperiode von irgendeinem MP empfangen wurde, dessen Flag für die Anforderung einer Synchronisation vom Peer oder dessen Flag für die Synchronisation mit einem Peer-MP in dem Synchronisationsfähigkeitsfeld auf wahr gesetzt ist, und wahlweise, wenn das empfangene Beaconsignal von einem zugeordneten MP empfangen wurde.

Wenn eine Nicht-AP-MP bekannt gibt, dass er die Synchronisation unterstützt oder dass er die Synchronisation mit Peers anfordert, kann er Beacons erzeugen und sich mit anderen Nicht-AP-MP's synchronisieren, wie wenn er in dem IBSS-Modus arbeiten würde, wie oben beschrieben wurde. Andererseits kann ein Nicht-AP-MP sein Beacon-Intervall (BI) unabhängig auswählen und kann seine TSF unabhängig von jeglicher TSF in einem anderen MP starten. Das Beacon-Erzeugungsverfahren im letzteren Fall folgt dem Verfahren, wie es in dem Betrieb nach dem IEEE 802.11 Infrastrukturmodus beschrieben ist. In einem beliebigen WLAN-Mesh, wo es eine Option für den MP ist, eine Verbindung mit anderen Peers herzustellen, kann ein Nicht-AP-MP die Beacon-Übertragung löschen, wenn ein Beacon von einem synchronisierten Peer-MP empfangen wird, der nicht mit dem Nicht-AP-MP in Verbindung steht, wenn der das Beacon übertragende MP ein Mitglied desselben Meshs ist.
Aufnahme der Synchronisation
Ein Nicht-AP-MP kann entweder in einem passiven Scanmodus oder einem aktiven Scanmodus je nach dem gegenwärtigen Wert eines Scanmodusparameters der Medium-Zugangssteuerungs-(MAC) Subplayer-Management-Größe(MLME)-SCAN.request primitive annehmen.
Nach dem Empfang von MLME-SCALA-request primitive kann ein Nicht-AP-MP einen Scanvorgang ausführen. Der Mesh-Identifikations-(ID)-Parameter bezeichnet das WLAN-Mesh, nach dem gesucht werden soll. Um ein Mitglied eines bestimmten Meshs unter Verwendung des passiven Scanmodus zu werden, kann ein Nicht-AP-MP die Beacon-Rahmen abtasten, die diese WLAN-Messh-ID enthalten, wobei er alle Beacon-Rahmen vorgibt, die zu der gewünschten WLAN-Mesh in dem Mesh-Description-Set-Parameter der entsprechenden MLME-SCAN.confirm primitive passt, mit den geeigneten Bits in dem Fähigkeitsinformationsfeld. Um einen aktiven Scanvorgang durchzuführen, kann der Nicht-AP-MP Probenrahmen übertragen, die die gewünschte WLAN-Mesh enthalten. Beim Abschluß des Scavorgangs wird MLME-SCAN.confirm typischerweise von dem MLME ausgegeben, was die gesamte empfangene WLAN-Mesh-Information zeigt.
Anfänglich kann eine Nicht-AP-MP entscheiden, entweder in dem Synch- oder UnSynch-Zustand zu arbeiten. Ein MP in dem UnSynch-Zustand wählt nach dem Empfang von MLME-START.request seinen eigenen BSS-Parametersatz. Es können jedoch zusätzliche Maßnahmen erforderlich sein, um eine Beacon-Kollision auf der Basis der empfangenen Beacons der BI- und DTIM-Periode von anderen MP's zu vermeiden und um seine eigenen BSS-Parameter von seinem TBTT-Versatz entsprechend auszuwählen.
3 zeigt ein Flußdiagramm des Verhaltens eines Nicht-AP-MP entsprechend Ausführungsbeispielen der vorliegenden Erfindung nach dem Empfang von entweder einer Beacon- oder einer Probe-Antwort, während er in dem UnSynch-Zustand ist. Das Verfahren ist auch auf Lightweight-Mesh-Punkte anwendbar. An dem Schritt 310 wird entweder eine Beacon- oder Probe-Antwort von einem Nicht-AP-MP empfangen. Der Nicht-AP-MP nimmt die Beacon-Timing-Parameter an dem Schritt 335 an und speichert einen Wert von SYNCHPEERS (BEACON.SENDER) an dem Schritt 325, wenn der Nicht-AP-MP festgestellt hat, dass der Beacon-Zeitstempel größer ist als der Takt des Nicht-AP-MP an dem Schritt 330, und dass sein SYNCHREQ-Zustand an dem Schritt 320 auf wahr ist, und dass (wahlweise) er mit dem Beacon-Sender an dem Schritt 315 verbunden ist. Wenn der optionale Schritt 315 verwendet wird und der Nicht-AP-MP feststellt, dass er nicht mit dem Beacon-Sender verbunden ist, führt er keinen der Schritte 320, 325, 330 und 335 aus. Wenn der Nicht-AP-MP feststellt, dass sein SYNCHREQ-Zustand an dem Schritt 320 nicht auf wahr ist, führt er keinen der Schritte 320, 325, 330 aus. Wenn der Nicht-AP-MP feststellt, dass des Beacon-Zeitstempel nicht größer ist als der Takt des Nicht-AP-MP an dem Schritt 330, führt er den Schritt 335 nicht aus.
Wenn der Nicht-AP-MP, der sich in dem UnSynch Zustand befindet, sich dafür entscheidet, in dem Synch-Zustand zu arbeiten, nimmt er den IBSS-Parametersatz an, der von einem synchronisierten oder wahlweise zugeordneten MP empfangen wird. Im letzteren Fall kann er Beacons wie oben beschrieben erzeugen.
Wenn ein Nicht-AP-MP-Scanvorgang nicht zum Ergebnis hat, dass ein Mesh mit der gewünschten Mesh-ID und von dem gewünschten Typ gefunden wird, oder dass überhaupt kein Mesh gefunden wird, kann der Nicht-AP-MP sein eigenes Mesh beim Empfang des MLME-START.request starten.
Einstellung der Timings
In Antwort auf MLME-START.request kann ein Nicht-AP-MP sein TSF-Timing auf Null initialisieren, und er sollte keine Beacon- oder Probe-Antwort senden, bis er eine Beacon- oder Probe-Antwort von einem Mitglied des WLAN-Mesh mit einer passenden Mesh-ID hört.
4 zeigt ein Flußdiagramm der Verhaltensweise eines Nicht-AP-MP's nach Empfang von einer Beacon- oder Probe-Antwort, während er sich in dem Synch-Zustand befindet. Alle Beacon- und Probe-Antworten sollen ein Zeitstempelfeld tragen. Ein MP in dem Synch-Zustand, der solch einen Rahmen (an dem Schritt 410) von einem anderen MP in dem WLAN-Mesh mit derselben WLAN-Mesh (an dem Schritt 415) empfängt, und, wenn entweder das Flag für die Anforderung der Synchronisation vom Peer oder das Flag für die Synchronisation mit einem Peer-MP in dem Synchronisationsfähigkeitsfeld des anderen MP's auf wahr gesetzt ist (ausgedrückt als IS(SYNCHREQ//SYNCHPEER)? In dem Schritt 420) kann er das Zeitstempelfeld mit seiner eigenen TSF-Zeit an dem Schritt 455 vergleichen. Optional muss an dem Schritt 415 der andere MP ein zugeordneter MP sein. Wenn das Zeitstempelfeld des empfangenen Rahmens später liegt als seine eigene TSF-Zeit, wird der MP alle Beacon-Timing-Parameter, die in dem Beacon-Rahmen enthalten sind, an dem Schritt 460 annehmen. Wenn ein synchronisierter MP ein Beacon von einem anderen MP empfängt, wobei der Satz „vordere Synchronisation von Peer an” an dem Schritt 420 auf falsch gesetzt ist, und wenn dies der einzige andere MP war, der eine Synchronisation angefordert hat, hat der MP zusätzlich die Option, von dem Synch-Zustand in den UnSynch-Zustand an dem Schritt 440 über die Schritt 425, 430 und 435 umzuschalten. Als Option muss der andere MP ein zugeordneter MP sein (an dem Schritt 315).
MP-Verhalten bei Stromsparmodus
Ein Nicht-AP-MP, der es gestattet, dass Peers, die eine Unterstützung für PS-Dienste anfordern, eine Verbindung herstellen, kann eine Synchronisation unterstützen, und ein Nicht-AP-MP kann die Verbindung mit einem Peer ablehnen, der in einem PS-Modus arbeiten will, wenn er nicht in der Lage ist, Synchronisationsdienste anzubieten.
Ein Nicht-AP-MP, der eine Verbindung mit einem MAP herstellt und in den PS-Modus eintritt, sollte für jede DTIM-Bake des MAP plus jegliche zusätzliche Beacons, die er empfangen muss, auf der Basis eines Empfangsintervalls aufwachen, das mit dem MAP ausgehandelt wird. Wenn ein MP eine Verbindung mit mehr als einem MAP herstellt, sollte er für jeden DTIM und für die im Sendeintervall befindlichen Beacons für jeden MAP aufwachen. Dies ist zusätzlich zu einem Meshn-TBTT, die für seine synchronisierten und verbundenen Nicht-AP-MP Nachbarn eingeplant sein kann. Daher sollte jeder MP, der in dem Stromsparmodus arbeitet und der mit einem MAP verbunden ist, den Versatz zwischen seiner internen TSF und der angegebenen TSF von einem MAP, mit dem er verbunden ist, zusammen mit den DTIM- und Beacon-Intervallen der MAP's verfolgen. Hier ist der Versatzwert gleich der Differenz zwischen der internen TSF und der bekanntgegebenen TSF von jedem MAP, mit dem er verbunden ist. Er kann die Versatzwerte von benachbarten MAP's bei jeder TBTT des benachbarten MAP auf den neuesten Stand bringen.
Vorteile
Die Ausführungsbeispiele der vorliegenden Erfindung, unterscheiden sich von dem Stand der Technik, weil ein MP, der nach den Ausführungsbeispielen ausgeführt ist, eine Synchronisation nur mit Nicht-AP-Mesh-Punkten herstellt, wenn einer oder mehrere der Nicht-AP-Mesh-Punkte eine Synchronisation anfordert. Die vorliegende Erfindung ermöglicht es, dass Mitglieder des Mesh voraussagen können, wenn andere Mitglieder, die in einem Stromsparmodus arbeiten, aufwachen werden, um gerichteten oder rund-gesendeten Verkehr zu empfangen, ohne dass der MAP sich mit einem anderen MP synchronisieren muss. Einer der Vorteile der Ausführungsbeispiele ist es, dass die vorgeschlagene Beacon-Erzeugung und das Synchronisationsschema einfach umzusetzen sind, und dass bereits existierende Mechanismen verwendet werden. Die Ausführungsbeispiele erfordern keine komplexe Computerberechnung oder -Verarbeitung durch den MP. Die Ausführungsbeispiele schützen auch einen MAP plus die Stationen und einen mit dem MAP verbundenen MP gegenüber einem MP, der beispielsweise entweder aufgrund einer ungenügenden Kompensation der Temperatur oder aufgrund von Alterung des MP-Kristalloszillators oder aufgrund einer böswilligen Absicht nicht konform sein kann. Der nicht konforme MP kann sonst ein ganzes Mesh unterbrechen statt nur ein kleines Segment. Die vorgeschlagenen Ausführungsbeispiele liefern eine Flexibilität für einen Nicht-AP-MP, um entweder Beaconzuständigkeiten gemeinsam zu nutzen, oder einzeln Kontrolle für diese Funktionen zu übernehmen. Beispielsweise kann es für ein Segment in einem Mesh geeignet sein, die Zeitsynchronisation und den Stromsparmodus einzuschalten, während ein anderes Segment diese Funktionen einschränken kann.
Einige Verfahrensaspekte der Ausführungsbeispiele
In 2 und der zugehörigen Beschreibung wird ein Verfahren von einem Mesh-Punkt verwendet, der ein Zugangspunkt-Mesh-Punkt, ein Nicht-Zugangs-Mesh-Punkt oder Lightweight-Mesh-Punkt sein kann. Das Verfahren umfasst die Formatierung eines Synchronisationsfähigkeitsfelds in entweder einer Beacon- oder einer Probe-Antwort. Das Synchronisationsfähigkeitsfeld umfasst eine Anzeige, ob der Mesh-Punkt die Synchronisation unterstützt (SynchSupp), eine Anzeige, ob der Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (SynchReq), und eine Anzeige, ob der Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (SynchPeers).
Wenn der Mesh-Punkt ein Nicht-Zugangspunkt-Mesh-Punkt oder ein Lightweight-Zugangspunkt ist, umfasst das Verfahren ferner das Initialisieren einer Beacon-Backoff-Funktion nach Ablauf eines Ziel-Beacon-Übertragungs-Timings, wenn wenigstens das SynchReq oder SynchPeers des Mesh-Punkts wahr ist, und die Abschaltung des Beaconsignal-Backoff-Funktion, wenn ein Beacon- oder Probe-Antwort von einem anderen Mesh-Punkt empfangen wird, in dem SynchReq und/oder SynchPeers des anderen Mesh-Punkts wahr ist/sind.
In 3 und deren Beschreibung wird ein Verfahren von einem Mesh-Punkt verwendet, der entweder ein Nicht-Zugangspunkt-Mesh-Punkt oder ein Lightweight-Mesh-Punkt ist. Das Verfahren umfasst das Empfangen von entweder einer Beacon- oder einer Probe-Antwort von einem anderen Mesh-Punkt, die Bestimmung, ob der Mesh-Punkt in einem unsynchronisierten Zustand ist, die Bestimmung von einer Anzeige in entweder der Beacon- oder der Probe-Antwort, ob der andere Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (SynchReq), die Einstellung eines Zustandes, ob der Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (SynchPeers), auf wahr und das Durchführen einer Beacon-Timing-Synchronisationsfunktion, wenn der Mesh-Punkt in dem synchronisierten Zustand ist und SynchReq des anderen Mesh-Punktes wahr ist.
In 4 und deren Beschreibung wird ein Verfahren von einem Mesh-Punkt verwendet, der ein Nicht-Zugangspunkt-Mesh-Punkt oder ein Lightweight-Mesh-Punkt ist. Das Verfahren umfasst den Empfang von entweder einer Beacon- oder einer Probe-Antwort von einem anderen Mesh-Punkt, die Bestimmung, dass der Mesh-Punkt sich in einem synchronisierten Zustand befindet, die Bestimmung von einem oder mehreren Anzeigen in entweder der Beacon- oder der Probe-Antwort, ob der andere Mesh-Punkt synchronisiert ist, und die Hinzufügung einer Identität von jedem Mesh-Punkt zu einer Datenbank des Beacon-Sender, die von dem Mesh-Punkt gehalten werden, und die Durchführung einer Beacon-Timing-Synchronisationsfunktion, wenn der Mesh-Punkt und der andere Mesh-Punkt beide synchronisiert sind.
Es ist zu beachten, dass die Ausführungsbeispiele der Erfindung, die hier beschrieben wurden, aus einem oder mehreren herkömmlichen Prozessoren und einzigartigen, gespeicherten Programminstruktionen bestehen können, die den einen oder die mehreren Prozessoren steuern, um im Zusammenhang mit gewissen, nicht zum Prozessor gehörigen Schaltkreisen einige, die meisten oder alle Funktionen der Zeitsynchronisation und der Beacon-Erzeugung umsetzt, die hier beschrieben ist. Die nicht zum Prozessor gehörenden Schaltkreise können einen Radioempfänger, einen Radiosender, Signaltreiber, Taktschaltungen, Stromquellenschaltungen und Benutzereingabevorrichtungen umfassen, sind jedoch nicht darauf beschränkt. Als solches können diese Funktionen als Verfahrensschritte interpretiert werden, um die Zeitsynchronisation und die Beacon-Erzeugung durchzuführen. Alternativ können einige oder alle Funktionen durch eine State-Maschine, die keine gespeicherten Programminstruktionen hat, oder durch einen oder mehre anwendungsspezifische, integrierte Schaltungen (ASIC's) implementiert werden, in denen jede Funktion oder einige Kombinationen gewisser Funktionen als kundenspezifische Logik implementiert sind. Selbstverständlich kann auch eine Kombination der zwei Ansätze verwendet werden. Somit sind Verfahren und Mittel für diese Funktionen hier beschrieben. Ferner ist zu erwarten, dass ein Durchschnittsfachmann, wenn er durch die Konzepte und Prinzipien, die hier beschrieben wurden, angeleitet wird, in der Lage sein wird, solche Softwarebefehle und Programme und IC's mit einem minimalen Aufwand an Experimenten erzeugen kann unabhängig von einem möglicherweise erheblichen Aufwand und vielen Design-Wahlmöglichkeiten, die beispielsweise durch die zur Verfügung stehende Zeit, die gegenwärtige Technologie und wirtschaftliche Überlegungen motiviert sein kann.

Claims

Verfahren zur Zeitsynchronisation und Beacon-Erzeugung für Mesh-Punkte, die in einem drahtlosen Mesh-Netz arbeiten, das umfasst: Übertragen einer Anzeige, ob der Mesh-Punkt die Synchronisation unterstützt (SynchSupp), in einem Synchronisationsfähigkeitsfeld von entweder einer Beacon- oder einer Probe-Antwort, Übertragen einer Anzeige, ob der Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (Synch-Req), in dem Synchronisationsfähigkeitsfeld, und Übertragen einer Anzeige, ob der Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (Synch-Peers), in dem Synchronisationsfähigkeitsfeld.
Verfahren nach Anspruch 1, worin der Mesh-Punkt entweder ein Zugangspunkt, ein Nicht-Zugangspunkt oder Lightweight-Mesh-Punkt ist.
Verfahren nach Anspruch 1, ferner umfassend, wenn der Mesh-Punkt entweder ein Nicht-Zugangspunkt-Mesh-Punkt oder ein Lightweight-Mesh-Punkt ist: Einleiten einer Beacon-Backoff-Funktion auf den Ablauf eines Ziel-Beacon-Übertragungs-Timings hin, wenn SynchReq und/oder SynchPeers des Mesh-Punktes wahr ist/sind; und Abschalten der Beacon-Backoff-Funktion, wenn eine Beacon- oder Probe-Antwort von einem anderen Mesh-Punkt empfangen wird, in der SynchReq und/oder SynchPeers des anderen Mesh-Punktes wahr ist/sind.
Verfahren zur Zeitsynchronisation und Beacon-Erzeugung für entweder einen Nicht-Zugangspunkt-Mesh-Punkt oder einen Lightweight-Mesh-Punkt, die in einem drahtlosen Mesh-Netz arbeiten, das aufweist: Empfangen von entweder einer Beacon- oder einer Probe-Antwort von einem anderen Mesh-Punkt; Bestimmen, ob der Mesh-Punkt in einem unsynchronisierten Zustand ist; Bestimmen aus der Anzeige in der entweder einen Beacon- oder Probe-Antwort, ob der andere Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (Synch-Req); Setzen eines Zustandes, ob der Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (SynchPeers), auf wahr und Durchführen einer Beacon-Timing-Synchronisationsfunktion, wenn der unsynchronisierte Zustand des Mesh-Punktes und der SynchReq des anderen Mesh-Punktes beide wahr sind.
Verfahren nach Anspruch 4, worin weder das Setzen des Zustandes von SynchPeers auf wahr noch die Durchführung des Beacon-Signal-Timing-Synchronisationsfunktion durchgeführt werden, wenn der Mesh-Punkt nicht mit dem anderen Mesh-Punkt in Verbindung steht.
Verfahren nach Anspruch 4, worin der Mesh-Punkt in einem unsynchronisierten Zustand ist, wenn sowohl SynchReq als auch SynchPeers des Mesh-Punktes falsch sind.
Verfahren nach Anspruch 4, worin das Setzen des Zustandes ferner das Hinzufügen einer Identität des anderen Mesh-Punktes zu einer Datenbank von Mesh-Punkten, die Beacon-Sender sind, die von dem Nicht-Zugangspunkt-Mesh-Punkt gehalten wird.
Verfahren zur Zeitsynchronisation und Beacon-Erzeugung für entweder einen Nicht-Zugangspunkt-Mesh-Punkt oder einen Lightweight-Mesh-Punkt, die in einem drahtlosen Mesh-Netz arbeiten, das umfasst: Empfang von entweder einer Beacon- oder Probe-Antwort von einem anderen Mesh-Punkt; Bestimmen, dass der Mesh-Punkt in einem synchronisierten Zustand ist; Bestimmen aus einer oder mehreren Anzeigen in der entweder einen Beacon- oder Probe-Antwort, ob der andere Mesh-Punkt synchronisiert ist; Hinzufügen einer Identität des anderen Mesh-Punktes zu einer Datenbank von Beacon-Sendern, die von dem Mesh-Punkt gehalten wird, und Durchführen einer Beacon-Timing-Synchronisationsfunktion, wenn der Mesh-Punkt und der andere Mesh-Punkt beide synchronisiert sind.
Verfahren nach Anspruch 8, worin die eine oder die mehrere(n) Anzeige(n) der Beacon- oder Probe-Antwort umfasst/umfassen: eine Anzeige, ob der andere Mesh-Punkt die Synchronisation von einem Peer-Mesh-Punkt anfordert (SynchReq); und eine Anzeige, ob der andere Mesh-Punkt bereits mit einem oder mehreren Peers synchronisiert ist (SynchPeers), und der andere Mesh-Punkt synchronisiert ist, wenn zumindest SynchReq und/oder SynchPeers des anderen Mesh-Punktes wahr ist/sind.
Verfahren nach Anspruch 8, worin das Hinzufügen der Identität des anderen Mesh-Punktes und die Durchführung der Beacon-Timing-Funktion des weiteren von dem Mesh-Punkt und dem damit verbundenen, anderen Mesh-Punkt abhängen.
Verfahren nach Anspruch 8, ferner umfassend: Bestimmen, ob der andere Mesh-Punkt ein Zugangspunkt ist, und Speichern der Differenz zwischen der Timing-Synchronisationsfunktion des anderen Mesh-Punktes und einer Timing-Synchronisationsfunktion des Mesh-Punktes als ein Beacon-Offset-Wert und Speichern der Lieferverkehr-Anzeigeliste (”delivery traffic indication map” (DTIM)) und der Beacon-Intervalle, wenn der andere Zugangspunkt ein Zugangspunkt-Mesh-Punkt ist und der andere Mesh-Punkt sich nicht in einem synchronisierten Zustand befindet.
Verfahren nach Anspruch 8, ferner umfassend: Bestimmen, ob der andere Mesh-Punkt ein Zugangspunkt-Mesh-Punkt ist, und Löschen einer Identität des anderen Mesh-Punktes von einer Datenbank des Beacon-Senders, die von dem Mesh-Punkt gehalten wird, wenn der andere Mesh-Punkt ein Nicht-Zugangspunkt-Mesh-Punkt ist und der andere Mesh-Punkt sich nicht in einem synchronisierten Zustand befindet.