-
Die
Erfindung betrifft ein Verfahren zum Aufbau eines bidirektionalen
Kommunikationspfads in einem drahtlosen Netzwerk, insbesondere einem
drahtlosen Sensornetzwerk, wobei das Netzwerk Knoten in Form eines
Senkenknotens und einer Mehrzahl von Teilnehmerknoten aufweist,
wobei zwischen dem Senkenknoten und zumindest einem angefragten
Knoten der Teilnehmerknoten der Kommunikationspfad für
die bidirektionale Übermittlung von Datenpaketen aufzubauen
ist. Die Erfindung betrifft ferner ein Computerprogrammprodukt sowie
ein Netzwerk, insbesondere ein drahtloses Sensornetzwerk.
-
Drahtlose
Netzwerke sind häufig in der Gestalt drahtloser Sensornetzwerke
(auch Sensornetze genannt) realisiert. Ein drahtloses Sensornetz
wird durch eine Ansammlung von Sensoren, den Knoten oder Sensorknoten
des Sensornetzes, mit einer Funkschnittstelle gebildet. Die jeweiligen
Sensoren übertragen beispielsweise Messwerte und Statusinformationen
(allgemein: Daten) zu zumindest einem Senkenknoten, welcher typischerweise
als Gateway fungiert. Falls die Sensoren nicht in direkter Reichweite
zu dem Senkenknoten sind, leiten sie auch die Daten für
andere der Sensoren weiter. Es wird somit eine sog. Multi-Hop-Datenübertragung
etabliert. Hierzu wird in den Sensorknoten die Information über
den jeweils nächsten Knoten für die Weiterleitung
zu dem Senkenknoten, d. h. über den Pfad, vorgehalten.
Diese Information wird im Allgemeinen als Routing-Tabelleneintrag
bezeichnet.
-
Die
Sensorknoten als auch der Senkenknoten sind typischerweise auf extreme
Energieeffizienz sowie günstige Kosten in der Realisierung
ausgelegt. Dies bedeutet, dass die Knoten über sehr geringe
Ressourcen verfügen, insbesondere eine geringe Rechenleistung
und einen kleinen Hauptspeicher. Letzteres be deutet, dass auch die
Routing-Tabellen nur wenige Einträge enthalten können.
Darüber hinaus sind über die Funkschnittstelle
nur geringe Datenraten erreichbar, wobei die Ressource zudem möglichst
sparsam eingesetzt werden muss, da die Funkschnittstelle relativ
zu den anderen Komponenten, wie Sensor oder CPU, einen besonders
hohen Energieverbrauch aufweist.
-
Pfade
von einem jeweiligen Sensor zu dem Senkenknoten (Gateway), d. h.
in sog. Uplink-Richtung, können einfach und Ressourcen
sparend mit sog. Collection-Tree-Protokollen aufgebaut werden. Derartige Protokolle
basieren auf dem periodischen Austausch von Paketen zwischen benachbarten
Knoten, welche den jeweils kürzesten Abstand zur Senke
in Form einer Metrik signalisieren. Diese Pakete werden als Beacons
bezeichnet. Jeder Knoten verwaltet einen Pfad zu dem Senkenknoten,
indem er den benachbarten Knoten mit dem geringsten Abstand zur
Senke zur Weiterleitung seiner Datenpakete abspeichert. Allerdings
sollen gelegentlich auch Nachrichten, z. B. Konfigurationspakete,
von dem Senkenknoten an einen ausgewählten Knoten geschickt
werden. Dafür müssen entsprechende Pfade in der
entgegengesetzten Richtung, d. h. der sog. Downlink-Richtung, aufgebaut
werden, was von der Klasse der Collection-Tree-Protokolle nicht
unterstützt wird. Es sind deshalb bei Verwendung dieses
Protokolls zusätzliche Mechanismen erforderlich.
-
Daneben
besteht die Problematik, dass in einem großen Sensornetz
der Aufbau der Pfade besonders effizient erfolgen muss, insbesondere
da der verfügbare Speicher nicht ausreicht, um Pfade für
alle Knoten in der Senke bzw. in den der Senke naheliegenden Knoten
vorzuhalten. Dies führt dazu, dass die Pfade von dem Senkenknoten
zu dem ausgewählten Knoten detektiert und wiederholt aufgebaut
werden müssen, da sie nicht permanent vorgehalten werden
können.
-
Im
Zusammenhang mit drahtlosen Sensornetzwerken sind zwei Spezifikationen
bekannt, die sich mit dem Kommunikationsver halten in Multi-Hop-Netzwerken
beschäftigen: ZigBee und WirelessHART.
-
ZigBee
unterstützt neben dem Cluster-Tree-Protokoll ein reaktives,
auf AODV basierendes Multi-Hop-Protokoll. Das Cluster-Tree-Protokoll
vergibt Adressen in Abhängigkeit der Topologie, was das
oben genannte Problem effizient löst, aber in der Praxis
zu erheblichen Einschränkungen der Bedienbarkeit führt,
da die gesamte Applikationslogik bei Änderungen in der
Topologie und damit bedingten Adressänderungen ebenfalls
modifiziert werden muss. Da dies nicht praktikabel ist, wird das
Cluster-Tree-Verfahren von ZigBee in aktuellen Anwendungen nicht
benutzt.
-
Im
neueren ZigBee Pro-Feature Set wird deshalb das Cluster-Tree-Protokoll
nicht unterstützt und das AODV-basierte Protokoll durch
Many-to-One- und Source-Routing ergänzt. Eine Kommunikation
von dem Senkenknoten zu einzelnen Knoten kann sowohl durch einen
gezielten Aufbau von Routen mit dem reaktiven AODV-Mechanismus als
auch über die Source-Routing-Option realisiert werden.
Der reaktive Aufbau von Routen hat einen netzwerkweiten Broadcast
zur Folge. Durch die geringe Speicherkapazität der Knoten
bezüglich der Routing-Tabellen muss dieser Vorgang häufig
wiederholt werden, was zu einem erhöhten Verbrauch der Ressourcen,
insbesondere von Energie, führt.
-
Source-Routing
erfordert die Aufzeichnung aller Zwischenknoten in Datenpaketen,
die von einem Knoten zum Senkenknoten übertragen werden.
Diese Liste der Zwischenknoten wird dann im Datenpaket, welches
von dem Senkenknoten zu einem der Knoten (Sensoren) übertragen
wird, mitgeführt. Nachteile dieses Verfahrens sind die
Verringerung der maximalen Größe der Nutzdaten
der Pakete (im Standard IEEE 802.15.4 maximal 128
Byte einschließlich des Paket-Headers) in Abhängigkeit
von der Entfernung (gezählt in Hops, d. h. der Anzahl der
Zwischenknoten) zwischen Knoten und Senkenknoten sowie der zu sätzliche
Aufwand für die Realisierung einer zweiten Klasse von Routing-Protokollen.
-
WirelessHART
unterstützt sowohl tabellenbasiertes als auch Source-Routing.
Bei WirelessHART wird das Routing zentral von einem Netzwerkmanager,
der die Topologie kennt, gesteuert. Das tabellenbasierte Routing
ist durch den aufwändigen Konfigurationsprozess eher für
längerfristige Kommunikationsbeziehungen geeignet. Die
Ressourcenbeschränkung des Speichers macht eine häufige
Rekonfiguration der Routing-Tabellen unumgänglich, da nicht
alle Kommunikationsbeziehungen zwischen dem Senkenknoten und allen
Knoten des Sensornetzes im Speicher gehalten werden können.
Das Source-Routing löst das Speicherproblem, ist allerdings
bei WirelessHART auf insgesamt vier Hops eingeschränkt.
Ebenfalls ist der Aufwand für die Implementierung von zwei
Routing-Protokollen nicht zu vernachlässigen.
-
In
der Welt der drahtlosen Datenkommunikation, insbesondere IEEE
802.11 WLAN, sind ebenfalls Protokolle bekannt, die Pfade
zu Senkenknoten aufbauen. Der derzeitige Draft-Standard IEEE
802.11s D2.02 enthält auch das Mesh-Routing-Protokoll
HWMP (veröffentlicht in [1]). Neben dem On-Demand-Mode
ist es auch möglich, einen Routenbaum, der auch bidirektional
sein kann, von einem bestimmten Knoten, dem sog. Root-MP, aus aufzubauen.
In der Regel ist ein Root-MP ein Senkenknoten oder Gateway. Hierfür
sind zwei unterschiedliche Verfahren angegeben: proaktives PREQ-Modus
und RANN-Modus.
-
Im
proaktiven PREQ-Modus wird periodisch eine sog. Path-Request-Nachricht
(PREQ) mit einer Broadcast-Adresse als gesuchtes Ziel von dem Root-MP
in das Netz gesendet. Hierdurch wird in jedem Knoten des Netzes
ein unidirektionaler Pfad zu dem Root-MP aufgebaut. Das Ergebnis
dieses Verfahrens entspricht dem Collection-Tree-Routing in den
betrachteten Sensornetzen. Allerdings wird die PREQ-Nachricht in der
Regel „geflutet”, d. h. es wird von dem Knoten,
der die Nachricht empfangen hat, sofort mit aktualisierter Pfadmetrik
per Broadcast an alle benachbarten Knoten weitergeleitet.
-
Die
bidirektionalen Pfade im Root-MP zu den einzelnen Knoten können
im proaktiven PREQ-Modus von HWMP nach zwei unterschiedlichen Methoden
erzeugt werden. Bei einem gesetzten Flag „proaktives PREP” antwortet
jeder Knoten, der die PREQ-Nachricht an die Broadcast-Adresse erhalten
hat, mit einer entsprechenden sog. Path-Reply-Nachricht (PREP).
Dieses Verfahren ist selbst in WLAN-Netzen nicht besonders effizient,
und somit auch nicht in ressourcenbeschränkten drahtlosen
Netzwerken. Es würden nämlich N·L Übertragungen
von PREP-Paketen pro ausgesendeter PREQ-Nachricht vom Root-MP notwendig
sein. N stellt hierbei die Anzahl der Knoten in dem Baum und L die
mittlere Baumtiefe dar. Das Verfahren ist nicht energieeffizient
und erzeugt Overhead. Zudem würde der Root-MP einen Pfad
zu allen Knoten in dem Netzwerk haben, was zu Ressourcen-Problemen
wegen der Größe der Routing-Tabelle führen
würde. Ist das Flag „proaktives PREP” nicht
gesetzt, so schickt der Knoten nur dann eine PREP-Nachricht, wenn
er einen bidirektionalen Pfad benötigt, d. h. einen Pfad
vom Root-MP zum Knoten. Initiator ist hier der Knoten, wobei das
Verschicken von PREP-Nachrichten aufrecht erhalten wird, solange
der Knoten Daten an den Root-MP sendet. Mit dieser Methode ist die
Routing-Tabelle im Root-MP kleiner, allerdings würde sie
in dem Sensornetz alle Sensorknoten umfassen und deshalb für
ein ressourcenbeschränktes drahtloses Netzwerk zu groß sein,
da ja jeder Knoten Daten zum Senkenknoten schickt. Ein weiteres
Problem mit diesem Verfahren ist, dass der Bedarf für einen bidirektionalen
Pfad nur am Senkenknoten/Root-MP bekannt ist, der bidirektionale
Pfad aber nur von dem Knoten im Baum initiiert wird und es keine
Möglichkeit in HWMP gibt, diesen Bedarf an den Knotenbaum
zu übermitteln.
-
Der
RANN-Modus von HWMP unterscheidet sich lediglich im Aufbau der bidirektionalen
Routen. Dabei wird eine sog. Root-Announcement-Nachricht (RANN-Nachricht)
entsprechend der oben beschriebenen proaktiven PREQ-Nachricht in
dem Netzwerk geflutet. Es wird jedoch kein Eintrag in der Routing-Tabelle
vorgenommen, sondern nur der beste Vorgängerknoten zum
Root-MP ermittelt. Die Information wird nicht zum Weiterleiten von
Datenpaketen verwendet, sondern lediglich zum Weiterleiten von Routing-Nachrichten,
insbesondere von Path-Request(PREQ)-Nachrichten. Die Erstellung
der Pfade zwischen dem Knoten im Baum und dem Root-MP erfolgt über
einen PREQ-/PREP-Nachrichtenaustausch per Unicast. Dieser Austausch
von Routing-Nachrichten wird ebenfalls vom Knoten im Baum initiiert.
Es ist ebenfalls nicht möglich, den am Senkenknoten/Root-MP
vorliegenden Bedarf für einen bidirektionalen Pfad an den
Knoten im Baum zu kommunizieren. Außerdem müsste
ein PREQ/PREP-Nachrichten-Austausch für jeden Knoten gemacht
werden, um die Funktionalität eines Collection-Tree-Protokolls
zu erreichen.
-
In
HWMP wird beim Senden eines Datenpakets auf dem Pfad die Lebenszeit
des entsprechenden Hin- als auch des dazugehörigen Rückpfades
wieder auf den maximalen Wert gesetzt. In den oben beschriebenen Sensornetzen
würde das dazu führen, dass ein einmal aufgesetzter
bidirektionaler Pfad immer bidirektional bleibt, da immer wieder
Datenpakete von den Sensoren an den Senkenknoten geschickt werden
und dadurch auch die Lebenszeit des entsprechenden Pfads vom Senkenknoten
zum Sensorknoten immer mit erneuert werden würde. Der bidirektionale
Pfad würde dadurch nie durch ein Verstreichen der Lebenszeit,
sog. Time-out, gelöscht werden.
-
HWMP
erlaubt mehrere Zieladressen in den PREQ-Nachrichten. Definitionsgemäß dürfen
dabei entweder eine oder mehrere Zieladressen für einzelne
Knoten im reaktiven Modus oder nur die Broadcast-Adresse für
den Baum im PREQ stehen. Dadurch werden energieaufwändige
Anfrage-Nachrichten reduziert.
-
Es
ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben,
mit dem ein bidirektionaler Kommunikationspfad in einem drahtlosen
Netzwerk, insbesondere einem drahtlosen Sensornetzwerk, aufgebaut
werden kann. Dabei soll das Verfahren geeignet sein, in einem drahtlosen
Netzwerk mit geringen Ressourcen effizient ausgeführt werden
zu können. Es ist weiterhin Aufgabe der vorliegenden Erfindung,
ein Computerprogrammprodukt sowie ein Netzwerk anzugeben, in welchem
eine bidirektionale Datenübertragung bei geringem Ressourcenverbrauch
möglich ist.
-
Diese
Aufgaben werden gelöst durch Verfahren gemäß den
Merkmalen der Patentansprüche 1 und 4, ein Computerprogrammprodukt
gemäß den Merkmalen des Patentanspruches 23, sowie
ein Netzwerk gemäß den Merkmalen des Patentanspruches
24. Vorteilhafte Ausgestaltungen ergeben sich aus den abhängigen
Patentansprüchen.
-
Die
Erfindung schafft ein Verfahren zum Aufbau eines bidirektionalen
Kommunikationspfads in einem drahtlosen Netzwerk, insbesondere einem
drahtlosen Sensornetzwerk, wobei das Netzwerk Knoten in Form eines
Senkenknotens und einer Mehrzahl von Teilnehmerknoten aufweist,
wobei zwischen dem Senkenknoten und zumindest einem angefragten
Knoten der Teilnehmerknoten der Kommunikationspfad für
die bidirektionale Übermittlung von Datenpaketen aufzubauen
ist. Bei dem erfindungsgemäßen Verfahren wird
ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten zu dem
Senkenknoten dadurch ermittelt, dass ein periodischer Austausch
von Pfad-Nachrichten, das heißt von Nachrichten mit Pfadinformationen,
zwischen benachbarten Knoten des Netzwerks erfolgt, wobei eine jeweilige
Pfad-Nachricht den jeweils kürzesten Abstand zu dem Senkenknoten,
insbesondere in Form einer Metrik, signalisiert, und jeder der Knoten
einen Pfad zu dem Senkenknoten dadurch verwaltet, dass dieser die
Adresse des benachbarten Knotens mit der besten Metrik zu dem Senkenknoten
zur Weiterleitung der Datenpakete abspeichert. Die Pfad-Nachrichten
können sog. Beacons darstellen, wie diese aus Collection-Tree-Protokollen
bekannt sind. Mit diesem Vorgehen zur Ermittlung des Uplink-Pfads werden
die jeweils kürzesten Pfade zwischen den Senkenknoten und
einem jeweiligen Teilnehmerknoten ermittelt. Dieses Vorgehen ist
insgesamt als Collection-Tree-Protokoll bekannt, das eingangs beschrieben
wurde. Die ausgetauschten Nachrichten werden als Beacons bezeichnet.
Die beste Metrik umfasst z. B. die geringste Anzahl an auf dem Pfad
liegenden Teilnehmerknoten.
-
Bei
dem erfindungsgemäßen Verfahren wird ein Downlink-Pfad
von dem Senkenknoten zu dem zumindest einen angefragten Knoten dadurch
ermittelt, dass in zumindest eine der, von dem Senkenknoten gesendeten
Pfad-Nachrichten eine Adressliste eingefügt wird, welche
die Adresse eines jeweiligen angefragten Knotens umfasst. Jeder
Teilnehmerknoten, der eine Pfad-Nachricht mit einer Adressliste
empfängt, fügt die Adressliste an die von ihm
ausgesendete Pfad-Nachricht ein. Der oder die in der Adressliste
adressierten Teilnehmerknoten gehen hierbei beim Empfang der Pfad-Nachricht
mit der Adressliste als angefragte Knoten in einen dedizierten Sendezustand über.
-
Das
erfindungsgemäße Verfahren schlägt somit
vor, die Adresse oder Adressen des oder der angefragten Knoten in
ein Beacon gemäß dem Collection-Tree-Protokoll
einzufügen. Durch das Anhängen einer Adressliste
der angefragten Knoten an die Pfad-Nachricht (Beacon) ist es möglich,
dass sich die angefragten Knoten explizit bei dem Senkenknoten melden,
ohne dass dieser mit einer zusätzlichen Anfrage-Nachricht
das drahtlose Netzwerk energieaufwändig fluten muss. Hierdurch
wird den begrenzten Energieressourcen in einem drahtlosen Netzwerk,
insbesondere einem drahtlosen Sensornetzwerk, Rechnung getragen.
-
Durch
die Beschränkung auf wenige angefragte Sensorknoten ergibt
sich zusätzlich der positive Effekt, dass die Routing-Tabelle
des Senkenknotens nur diejenigen Teilnehmerknoten enthält,
mit denen dieser tatsächlich kommuniziert. Dadurch wird
der sehr begrenzten Speicherkapazität des Senkenknotens und
der Teilnehmerknoten, die Zwischenknoten sind, Rechnung getragen.
-
Durch
eine vorteilhafte Konfiguration von maximaler Lebenszeit, Pfad-Nachrichten-Intervall
(Beacon-Intervall) und Zusammenstellung der Listen der angefragten
Sensorknoten kann die Erfindung in vielen Ausprägungen
von drahtlosen Netzwerken zur Anwendung kommen.
-
Gemäß einer
zweckmäßigen Ausgestaltung entfernt ein angefragter
Knoten beim Empfang einer Pfad-Nachricht mit der Adressliste seine
Adresse aus der Adressliste, bevor der angefragte Knoten seine Pfad-Nachricht
mit der Adressliste an die zu ihm benachbarten Knoten aussendet.
-
Gemäß einer
weiteren Ausgestaltung berücksichtigt ein Teilnehmerknoten
Pfad-Nachrichten nur von einem solchen benachbarten Knoten, der
aufgrund der Pfad-Nachricht als nächster Hop zu dem Senkenknoten
ausgewählt wird. Hierdurch werden die in den Knoten verfügbaren
Ressourcen sparsam eingesetzt.
-
Die
Erfindung schafft ein weiteres Verfahren zum Aufbau eines bidirektionalen
Kommunikationspfads in einem drahtlosen Netzwerk, insbesondere einem
drahtlosen Sensornetzwerk, wobei das Netzwerk Knoten in Form eines
Senkenknotens und einer Mehrzahl von Teilnehmerknoten aufweist,
wobei zwischen dem Senkenknoten und zumindest einem angefragten
Knoten der Teilnehmerknoten der Kommunikationspfad für
die bidirektionale Übermittlung von Datenpaketen aufzubauen
ist. Bei diesem Verfahren wird ein Uplink-Pfad von einem jeweiligen
der Teilnehmerknoten zu dem Senkenknoten dadurch ermittelt, dass
ein periodischer Austausch von Pfad-Nachrichten zwischen benachbarten
Knoten des Netzwerks erfolgt, wobei eine jeweilige Pfad-Nachricht
den jeweils kürzesten Abstand zu dem Senkenknoten, insbesondere
in Form einer Metrik, signalisiert, und jeder der Knoten seinen
Pfad zu dem Senkenknoten dadurch verwaltet, dass dieser die Adresse des
benachbarten Knotens mit der bes ten Metrik zu dem Senkenknoten zur
Weiterleitung der Datenpakete abspeichert. Ein Downlink-Pfad von
dem Senkenknoten zu dem zumindest einen angefragten Knoten wird
erfindungsgemäß dadurch ermittelt, dass zusätzlich
zu den periodisch gesendeten Pfad-Nachrichten durch den Senkenknoten
eine Anfrage-Nachricht mit einer Adressliste, welche die Adresse
eines jeweiligen angefragten Knotens umfasst, ausgesendet wird;
die Anfrage-Nachricht durch jeden, diese Anfrage-Nachricht empfangenden
Knoten, an die jeweils benachbarten Knoten weitergeleitet wird;
und der oder die in der Adressliste adressierten Teilnehmerknoten
beim Empfang der Anfrage-Nachricht mit der Adressliste als angefragte
Knoten in einen dedizierten Sendezustand übergehen.
-
Die
Anfrage-Nachricht aktualisiert automatisch in allen Knoten, die
diese Anfrage-Nachricht erhalten, den Kommunikationspfad zum Senkenknoten.
Dieses Verfahrensprinzip beruht, ähnlich wie der On-Demand-Modus
von HWMP darauf, eine explizite Anfrage-Nachricht mit mehreren Zieladressen
zu senden. Eine solche explizite Anfrage-Nachricht braucht lediglich
einmal in dem drahtlosen Netzwerk verteilt zu werden, so dass die
Anzahl zusätzlicher Routing-Pakete gering gehalten werden
kann. Hierdurch ist ein energieeffizienter Betrieb des drahtlosen
Netzwerks möglich. Ein weiterer Vorteil besteht darin,
dass eine Kombination einer Anfrage-Nachricht mit dem Pfadaufbau
zum Senkenknoten eine zusätzliche Aktualisierung der Pfade
zum Senkenknoten mit sich bringt. Eine Anfrage-Nachricht, die vom
Senkenknoten initiiert wurde, aktualisiert automatisch in allen
Knoten, die diese Anfrage-Nachricht erhalten, den Pfad zum Senkenknoten.
-
Gemäß einer
zweckmäßigen Ausgestaltung entfernen die Teilnehmerknoten,
die in der Adressliste adressiert sind, ihre Adresse aus der Adressliste
vor dem Weiterleiten an die jeweils benachbarten Knoten.
-
Da
Knoten, die eine Anfrage-Nachricht erhalten und deren Adresse in
der Liste der Zieladressen enthalten ist, ihre Adresse vor dem Weiterleiten
aus der Liste zu löschen, kann es vorkommen, dass die Liste
der Zieladressen leer ist, aber noch nicht alle Teilnehmer die Anfrage-Nachricht
zum Aktualisieren der Pfade zum Senkenknoten bekommen haben. Es
führt zwar zu keinem Fehlverhalten des Netzwerks, wenn
diese Teilnehmerknoten die Anfrage-Nachricht nicht erhalten, allerdings
kann die Aktualität der Pfade zum Senkenknoten durch ein
Weiterleiten erhöht werden. Dazu muss dem Teilnehmerknoten
mitgeteilt werden, auch eine Anfrage mit einer leeren Liste von
Zieladressen weiterzuleiten. Hierzu gibt es folgende Möglichkeiten:
In
einer ersten Variante leiten die Teilnehmerknoten, die eine von
dem Senkenknoten initiierte Anfrage-Nachricht empfangen, diese an
ihre benachbarten Knoten weiter. Dies erfolgt bevorzugt unabhängig
davon, ob Zieladressen in der Adressliste vorhanden sind oder nicht.
-
Gemäß einer
anderen Variante leiten die Teilnehmerknoten, die eine von dem Senkenknoten
initierte Anfrage-Nachricht mit einer darin enthaltenen Broadcast-Adresse
als Zieladresse der Anfrage-Nachricht erhaltendie Anfrage-Nachricht
auch mit leerer Zieladressenliste an alle Teilnehmerknoten weiter
und interpretieren diese Broadcast-Adresse nicht als Anfrage. Da
aber Teilnehmerknoten mit den enthaltenen Zieladressen darüber
aufgefordert werden, ihre Datenpakete an den Senkenknoten zu markieren,
benötigt die Broadcast-Adresse dann eine Sonderbehandlung,
da nicht jeder, sondern nur bestimmte Teilnehmerknoten die Datenpakete
markieren sollen.
-
Gemäß einer
weiteren Variante wird in die Anfrage-Nachricht ein Indikator eingefügt,
welcher den die Anfrage-Nachricht empfangenden Knoten signalisiert,
dass die Anfrage-Nachricht auch bei leerer Adressenliste an die
benachbarten Knoten weiterzuleiten ist. Bei gesetztem Indikator
wird die Anfrage- Nachricht auch bei leerer Ziel-Adressenliste weitergeleitet.
Ist der Indikator nicht gesetzt, wird die Anfrage-Nachricht nicht
weitergeleitet, wenn die Zieladressenliste leer ist.
-
Gemäß einer
weiteren zweckmäßigen Ausgestaltung versieht der
angefragte Knoten zumindest das nächste, an den Senkenknoten
zu sendende Datenpaket in einer vorgegebenen Weise mit einer Markierung, welche
von den auf dem Kommunikationspfad zu dem Senkenknoten liegenden
Teilnehmerknoten als Indikator für eine Weiterleitungs-Nachricht
interpretiert wird.
-
Durch
die Integration der Funktionalität von Antwort-Nachrichten
in reguläre Datenpakete ergibt sich eine weitere Einsparung
von Routing-Paketen. Der Aufbau von Kommunikationspfaden wird dadurch
in dem drahtlosen Netzwerk ermöglicht, ohne zusätzlichen
Signalisierungsverkehr zu erzeugen. Hierdurch wird so gut wie keine
zusätzliche Energie benötigt: das Hinzufügen
einiger Bytes zu existierenden Datenpaketen benötigt deutlich
weniger Energie als das Versenden zusätzlicher Pakete.
Ein weiterer Vorteil des erfindungsgemäßen Verfahrens
besteht darin, dass durch den Aufbau von lokalen Routing-Tabellen
das Verfahren im Vergleich zu den aus dem Stand der Technik bekannten
Source-Routing-Verfahren skaliert.
-
Gemäß einer
weiteren zweckmäßigen Ausgestaltung tragen die
Teilnehmerknoten, die auf dem Pfad von einem angefragten Knoten
zu dem Senkenknoten liegen, sowie auch der Senkenknoten, den Downlink-Pfad
in ihre Weiterleitungs-Tabelle ein, wenn diese ein markiertes Datenpaket
von einem der angefragten Knoten erhalten.
-
Zweckmäßigerweise
werden in die Weiterleitungs-Tabelle zumindest folgende Informationen
eingetragen:
- – eine Zieladresse, welche
die Adresse des angefragten Knotens ist, und der Quelladresse eines
markierten Datenpakets entspricht;
- – eine Adresse eines benachbarten Teilnehmerknotens
(nächster Hop), welche die Adresse des nächsten Teilnehmerknotens
auf dem Pfad zur Zieladresse ist. Dies entspricht der Sender-Adresse
des markierten Datenpakets;
- – eine einer Lebensdauer eines Kommunikationspfads
entsprechende Information, wobei diese angibt, nach welcher Zeitdauer
der Pfad zum angefragten Knoten aus der Weiterleitungs-Tabelle gelöscht
wird.
-
Es
ist weiterhin vorgesehen, dass die Lebensdauer eines Pfads bei Eintritt
eines der folgenden Ereignisse auf ihren Maximalwert zurückgesetzt
wird:
- – bei Erhalt oder Weiterleiten
eines mit einer Markierung versehenen Datenpakets von dem angefragten Knoten,
welches an den Senkenknoten übertragen wird, oder
- – bei Erhalt oder Weiterleiten eines von dem Senkenknoten
gesendeten Datenpakets, das an den angefragten Knoten adressiert
ist.
-
Insbesondere
wird den Teilnehmerknoten die Lebensdauer des Kommunikationspfads
bei einer Konfiguration mitgeteilt. Ebenso ist es möglich,
diesen Wert in die markierten Datenpakete einzufügen, so
dass dann dieser Wert für die Routing-Tabelle verwendet
wird.
-
Der
Maximalwert für die Lebenszeit des Pfads vom Senkenknoten
zum angefragten Knoten sollte so gewählt werden, dass dieser
Pfad beim Senden des nächsten Datenpakets durch den Senkenknoten
auf diesem Pfad noch existiert.
-
Auf
eine Pfadmetrik für die Pfade vom Senkenknoten zu den angefragten
Sensorknoten kann verzichtet werden, da der Pfad vom Senkenknoten
zum angefragten Sensorknoten genau dem bereits existierenden Pfad
vom angefragten Sensorknoten zum Senkenknoten entspricht.
-
Eine
weitere zweckmäßige Ausgestaltung sieht vor, dass
ein markiertes Datenpaket mit einer Sequenznummer versehen wird.
Wenn ein markiertes Datenpaket eine Sequenznummer enthält,
mit der eindeutig die Reihenfolge der (markierten) Datenpakete von
ein und demselben angefragten Sensorknoten ermittelt werden kann,
dann ist es zweckmäßig, diese in den Routing-Tabellen-Eintrag
zu übernehmen, da die korrekte chronologische Verarbeitung
bei Datenübertragungsproblemen vereinfacht wird.
-
Die
Assoziation eines Teilnehmerknotens zu seinem Vorgänger
in der Baumstruktur kann aufgrund von sich ändernden Umgebungsbedingungen,
wodurch sich die Metrik zum Senkenknoten ändert, auf einen anderen
Vorgängerknoten wechseln. Im schlimmsten Fall geschieht
ein Bruch einer Kommunikationsverbindung zwischen zwei benachbarten
Teilnehmerknoten, so dass eine Übermittlung von Datenpaketen
zwischen dem Teilnehmerknoten und seinem Vorgängerknoten
nicht mehr möglich ist. Es sind Konstellationen in der
Topologie möglich, bei denen der Senkenknoten die Unterbrechung
des Pfads zum Teilnehmerknoten nicht mitbekommt und deshalb die
Pakete vom Senkenknoten nicht an den Teilnehmerknoten übermittelt
werden können. Aus diesem Grund müssen alle vom
Senkenknoten ausgehenden Pfade, die über diesen nicht mehr
benutzten oder sogar nicht mehr verfügbaren Link gingen,
in allen Zwischenknoten und im Senkenknoten aktualisiert werden.
Dieser Vorgang wird nachfolgend als Pfadwartung bezeichnet.
-
Die
Uplink-Pfade werden automatisch, z. B. über die erhaltenen
Pfad-Nachrichten (Beacons), aktualisiert. Damit auch die Pfade in
Downlink-Richtung aktualisiert werden, müssen die Datenpakete
der angefragten Knoten solange markiert werden, wie der entsprechende
Downlink-Pfad existieren soll.
-
Die
Notwendigkeit der Pfadwartung eines Downlink-Pfades in dem betreffenden
angefragten Knoten wird zweckmäßigerweise durch
ein Markierungs-Flag gekennzeichnet, wobei bei gesetz tem Markierungs-Flag die
Datenpakete an den Senkenknoten mit der Markierung gekennzeichnet
werden.
-
Hierzu
stehen zwei Varianten zur Verfügung.
-
Damit
ein angefragter Knoten weiß, ob ein Downlink-Pfad vom Senkenknoten
zu ihm existiert, der gewartet werden muss, wird gemäß einer
vorteilhaften Ausgestaltung des Verfahrens die Lebenszeit eines Downlink-Pfads
in den betreffenden angefragten Knoten gespeichert. Zweckmäßigerweise
wird ein mit der maximalen Pfad-Lebenszeit initialisierter Timer
beim Erzeugen eines Downlink-Pfads gestartet. Das Erzeugen des Pfads
ist der Zeitpunkt, wann das erste markierte Datenpaket nach einer
Anfrage vom angefragten Knoten verschickt wird. Insbesondere entspricht
die initiale Lebenszeit für den Downlink-Pfad vom Senkenknoten
zu diesem Teilnehmerknoten in diesem Teilnehmerknoten der Lebenszeit,
die in den dazwischen liegenden Knoten für diesen Downlink-Pfad
gesetzt wird.
-
Eine
Ausgestaltung dieser ersten Variante sieht vor, dass durch einen
Teilnehmerknoten das Markierungs-Flag und ein weiteres, ein erstes
Datenpaket kennzeichnendes Flag gesetzt werden, sobald dieser zu einem
angefragten Knoten wird, wobei das weitere Flag mit der Übertragung
des ersten, mit einer Markierung gekennzeichneten Datenpakets an
den Senkenknoten gelöscht wird. Insbesondere versieht der
zumindest eine angefragte Knoten ein an den Senkenknoten zu sendendes
Datenpaket nicht mehr mit der Markierung, wenn der Timer abgelaufen
ist und das weitere Flag und das Markierungs-Flag nicht gesetzt
sind. Alternativ wird das weitere Flag mit einer nicht-negativen
Markierungsressource kombiniert, welche die Anzahl der mindestens
markierten Datenpakete nach jeder Anfrage durch den Senkenknoten
berücksichtigt.
-
Gemäß einer
weiteren zweckmäßigen Ausgestaltung wird ein Markierungs-Flag
für die Existenz eines Downlink-Pfads verwendet, wobei
der betreffende angefragte Knoten die von ihm an den Senkenknoten
gesendeten Datenpakete mit der Markierung versieht, solange das
Markierungs-Flaggesetzt ist. Das Markierungs-Flag wird gesetzt durch
- – eine Pfad-Nachricht, in der der
Teilnehmerknoten in der Adressliste enthalten ist (d. h. angefragt
ist) und/oder
- – Datenpakete, die der angefragte Knoten von dem Senkenknoten
empfängt.
-
Durch
die Kombination dieser beiden Bedingungen braucht ein Teilnehmerknoten
nur einmal in den Pfad-Nachrichten für die Dauer eines
Downlink-Pfads angefragt werden, unabhängig davon, über
wie viele Pfad-Nachrichten-Intervalle dieser Pfad existiert. Dadurch
können auch trotz der beschränkten Anzahl von
angefragten Teilnehmerknoten in der Pfad-Nachricht unabhängig
von der maximal zulässigen Größe der Pfad-Nachricht
beliebig viele Downlink-Pfade gleichzeitig existieren, solange der
Senkenknoten auf diesen Downlink-Pfaden Datenpakete überträgt.
Auch können dadurch das Pfad-Nachrichten-Intervall und
die Lebenszeit des Downlink-Pfads vollkommen unabhängig
voneinander gewählt werden.
-
Das
Setzen des Markierungs-Flags durch Datenpakete, die der angefragte
Knoten von dem Senkenknoten empfängt, kann prinzipiell
auch entfallen. Allerdings kann dann lediglich eine begrenzte Anzahl
an Downlink-Pfaden gleichzeitig existieren, da die angefragten Knoten
mit jeder Pfad-Nachricht immer wieder angefragt werden müssen
und der Platz für die Adressen der Teilnehmerknoten in
den Pfad-Nachrichten begrenzt ist. Darüber hinaus ist zu
berücksichtigen, dass die Lebensdauer des Downlink-Pfads
größer ist als das Pfad-Nachrichten-Intervall,
wenn ein kontinuierliches Vorhandensein des Downlink-Pfads gewünscht
ist.
-
Gemäß einer
weiteren zweckmäßigen Ausgestaltung wird die das
Markierungs-Flag zurückgesetzt, wenn eine vorgegebene Anzahl
an mit einer Markierung versehenen Datenpaketen an den Sen kenknoten
von einem jeweiligen angefragten Knoten gesendet wurde.
-
Eine
Alternative der zweiten Variante sieht vor, dass das Markierungs-Flag
zurückgesetzt wird, wenn der angefragte Knoten in einer
vorgegebenen Anzahl an empfangenen Pfad-Nachrichten nicht mehr in
der Adressliste enthalten ist.
-
Die
Erfindung umfasst ferner ein Computerprogrammprodukt, das direkt
in den internen Speicher eines digitalen Rechners geladen werden
kann und Softwarecodeabschnitte umfasst, mit denen die Schritte
des erfindungsgemäßen Verfahrens ausgeführt
werden, wenn das Produkt auf dem Rechner läuft.
-
Die
Erfindung schafft weiterhin ein Netzwerk, insbesondere ein drahtloses
Sensornetzwerk, wobei das Netzwerk Knoten in Form eines Senkenknotens
und einer Mehrzahl von Teilnehmerknoten aufweist, wobei zwischen
dem Senkenknoten und zumindest einem angefragten Knoten der Teilnehmerknoten
der Kommunikationspfad für die bidirektionale Übermittlung
von Datenpaketen aufbaubar ist. Bei dem erfindungsgemäßen Netzwerk
ist ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten zu
dem Senkenknoten dadurch ermittelbar, dass ein periodischer Austausch
von Pfad-Nachrichten zwischen benachbarten Knoten des Netzwerks
erfolgt, wobei eine jeweilige Pfad-Nachricht den jeweils kürzesten
Abstand zu dem Senkenknoten, insbesondere in Form einer Metrik,
signalisiert, und jeder der Knoten seinen Pfad zu dem Senkenknoten
dadurch verwaltet, dass dieser die Adresse des benachbarten Knotens
mit der besten Metrik zu dem Senkenknoten zur Weiterleitung der
Datenpakete abspeichert. Ein Downlink-Pfad von dem Senkenknoten
zu dem zumindest einen angefragten Knoten ist dadurch ermittelbar,
dass in zumindest eine der, von dem Senkenknoten gesendeten Pfad-Nachrichten
eine Adressliste eingefügt wird, welche die Adresse eines
jeweiligen angefragten Knotens umfasst; dass jeder Teilnehmerknoten,
der eine Pfad-Nachricht mit einer Adressliste empfängt,
die Adressliste an die von ihm ausgesen dete Pfad-Nachricht einfügt;
und dass der oder die in der Adressliste adressierten Teilnehmerknoten
beim Empfang der Pfad-Nachricht mit der Adressliste des angefragten
Knotens in einen dedizierten Sendezustand übergehen.
-
Das
erfindungsgemäße Netzwerk weist die gleichen Vorteile
auf, wie diese in Verbindung mit dem erfindungsgemäßen
Verfahren beschrieben wurden.
-
Die
Erfindung wird nachfolgend näher anhand von Ausführungsbeispielen
in der Zeichnung erläutert. Es zeigen:
-
1 ein
schematisches, beispielhaftes Sensornetz mit einer Mehrzahl von
Knoten und einem jeweiligen Pfad eines Teilnehmerknotens zu einem
Senkenknoten,
-
2A, 2B zwei
mögliche Realisierungen von Pfad-Nachrichten mit Anfragen
an den Sensorknoten des Sensornetzes gemäß 1,
-
3 einen
erfindungsgemäßen Ablauf der Kommunikation im
angefragten Knoten J gemäß einem ersten Verfahren
zur Pfadwartung, und
-
4 einen
erfindungsgemäßen Ablauf der Kommunikation im
angefragten Knoten J gemäß einem zweiten Verfahren
zur Pfadwartung.
-
1 zeigt
ein beispielhaftes Sensornetz NET, welches Knoten in Form eines
Senkenknotens SK und einer Mehrzahl von Teilnehmerknoten SE aufweist.
Die Teilnehmerknoten stellen beispielsweise Sensorknoten dar und
weisen eine eindeutige Adresse auf, welche in 1 mit
A, B, C, ..., K, L gekennzeichnet ist. Zwischen jeweiligen Teilnehmerknoten
SE bestehende Kommunikationsverbindungen (sog. Links) sind in 1 mit
einer dünnen gepunkteten Linie dargestellt. Fett darge stellte
Linien zwischen zwei Knoten repräsentieren einen Kommunikationspfad
zwischen den verbundenen Knoten. Die Pfade zwischen den einzelnen
Teilnehmerknoten SE sind gemäß dem Collection-Tree-Protokoll
aufgebaut worden, das eingangs bereits erläutert wurde.
Ein später genauer diskutierter Kommunikationspfad zwischen
dem Senkenknoten SK und dem Teilnehmerknoten SE mit der Adresse „J” (kurz:
Knoten J) ist mit PF gekennzeichnet. Auf diesem Kommunikationspfad
liegende Teilnehmerknoten B und E werden als Zwischenknoten bezeichnet.
-
Die
Pfade der Teilnehmerknoten SE zum Senkenknoten SK werden dadurch
aufgebaut, dass jeder der Teilnehmerknoten A bis L in mit Beacons
bezeichneten Pfad-Nachrichten seine kürzeste Distanz zum
Senkenknoten SK mitteilt. Der Senkenknoten SK macht sich selbst
mit Beacons mit der Distanz „0” oder einem anderen
initialen Startwert, der der kleinste Wert ist, zu sich selbst in
seiner Umgebung bekannt. Nach Hinzufügen der Distanz zu
dem Teilnehmerknoten, von dem ein anderer Teilnehmerknoten ein Beacon
empfangen hat, zu der im Beacon mitgeteilten Distanz zum Senkenknoten,
kennt der Teilnehmerknoten die entsprechenden Distanzen zum Senkenknoten über
seine benachbarten Teilnehmerknoten. Ein Teilnehmerknoten SE schickt
Daten, die für den Senkenknoten SK bestimmt sind, an den
benachbarten Teilnehmerknoten SE, üben den er die kürzeste
Distanz zum Senkenknoten SK hat. Nach endlicher Zeit hat die Information über
die Distanz zum Senkenknoten SK, ausgehend vom Senkenknoten SK,
alle Teilnehmerknoten SE im Netz erreicht.
-
In
der nachfolgenden Beschreibung wird davon ausgegangen, dass der
Senkenknoten SK drei Daten- und Steuerpakete an den Teilnehmerknoten
mit der Adresse „J” schicken möchte.
Hierzu muss zunächst ein Kommunikationspfad von dem Senkenknoten
SK zu dem bestimmten Teilnehmerknoten ermittelt werden, wobei dieser
Teilnehmerknoten als angefragter Knoten SO bezeichnet wird.
-
An
das von dem Senkenknoten SK ausgesendete Beacon zum Aufbau jeweiliger
Pfade zum Senkenknoten SK wird hierzu eine Liste von Adressen der
Teilnehmerknoten angehängt, an die der Senkenknoten SK Daten
senden möchte. Im vorliegenden Fall ist dies der Teilnehmerknoten
SE mit der Adresse „J”. Jeder Teilnehmerknoten,
der solch ein Beacon empfängt, fügt diese Adressliste
in sein nächstes Beacon mit ein. Hierdurch werden die Adressen
allen Teilnehmerknoten SE des Sensornetzwerks NET mitgeteilt. Empfängt
ein Teilnehmerknoten SE, der in dieser Adressliste enthalten ist
(hier: Knoten „J”) solch ein Beacon, so entfernt
er seine Adresse aus der Adressliste bevor er sie in seinem nächsten
Beacon an die ihm benachbarten Teilnehmerknoten SE weiterleitet.
-
Prinzipiell
ist es ausreichend, nur diejenigen Beacons zu berücksichtigen,
die von einem benachbarten Teilnehmerknoten SE empfangen werden,
welcher dann aufgrund dieses Beacons als nächster Knoten
(Hop) zum Senkenknoten SK ausgewählt wird.
-
In
dem Ausführungsbeispiel gemäß 1 trägt
der Senkenknoten SK deshalb die Adresse des Teilnehmerknotens SE
mit der Adresse „J” als angefragter Knoten in
sein Beacon ein. Nach endlicher Zeit erreicht diese Anfrage in dem
Beacon eines seiner benachbarten Teilnehmerknoten (hier die Knoten
I, E, F oder K) den Knoten J. Im Ausführungsbeispiel werden
dabei nur diejenigen Beacons berücksichtigt, die von einem
benachbarten Teilnehmerknoten SE empfangen werden, welcher dann
aufgrund dieses Beacons als nächster Hop zum Senkenknoten
SK, auch wiederholt, ausgewählt wird. Im Ausführungsbeispiel
sind dies die Beacons des Knotens E.
-
In 2A ist
eine mögliche Realisierung eines Beacons mit einer Anfrage
an einen bestimmten Teilnehmerknoten SE des Sensornetzwerks NET
dargestellt. Mit EF sind hierbei in einem herkömmlichen
Beacon bereits vorhandene Felder gekennzeichnet. N kennzeichnet
die Anzahl angefragter Teilnehmerknoten SE. Mit ID1(SO), ..., IDN(SO)
sind die Kennzeichner (Adressen) der angefragten Teilnehmerknoten
bezeichnet. Die Adressliste kann prinzipiell, wie in 2A dargestellt,
eine Anzahl N an angefragten Knoten aufweisen, wobei die Anzahl
N ≥ 0 ist. Feld N kann auch weggelassen werden, wenn sich
Anzahl und Position der angefragten Teilnehmerknoten eindeutig aus
der Struktur des Beacons ergeben. Das ist der Fall, wenn die Adressen
der angefragten Teilnehmerknoten SE unmittelbar nach EF als letztem
Datenfelder folgen.
-
2B zeigt
eine bevorzugte Ausgestaltung, gemäß der das Beacon
zusätzlich ein Anfrage-Flag SOF aufweist, mit dem das Beacon
empfangenden Teilnehmerknoten SE signalisiert wird, dass Teilnehmerknoten für
eine bidirektionale Kommunikationsverbindung zwischen dem Senkenknoten
und ihnen angefragt werden und diese angefragten Teilnehmerknoten
in der eingefügten Adressliste enthalten sind. Nur dann,
wenn das Anfrage-Flag SOF gesetzt ist, sind die zusätzlichen
Felder (Anzahl N der angefragten Knoten sowie die Kennzeichner (Adressen)
der angefragten Knoten) dem Beacon angehängt. Auch hier
könnte das Feld N wegfallen, wenn das Ende der Adressenliste
auch ohne das Feld N eindeutig erkennbar ist (z. B. durch das Ende
der Nachricht).
-
Nach
dem Empfang eines Beacons durch den angefragten Knoten, der in der
Adressliste des Beacons enthalten ist, markiert der angefragte Knoten
SO (hier Knoten J) sein nächstes Datenpaket durch einen
geeigneten Mechanismus, wie z. B. ein Flag, zur Bearbeitung im Routing-Algorithmus.
Wurde ein Teilnehmerknoten SE angefragt, so muss er mindestens das
nächste Datenpaket an den Senkenknoten SK mit dieser Markierung versehen.
Da die Zeitpunkte zum Versenden von Datenpaketen jedoch unabhängig
vom Erhalt eines Beacons mit einer Anfrage sind, erlaubt es die
auf dem angefragten Knoten gesetzte Markierungs (z. B. in Gestalt
eines Markierungs-Flags oder einer ähnlichen Datenstruktur)
festzustellen, ob die Datenpakete erfindungsgemäß markiert
werden müssen. Ist die Markierung entsprechend gesetzt,
so werden alle Datenpakete des angefragten Knotens SO markiert.
Wird der angefragte Knoten SO in einem Beacon angefragt, so setzt
der angefragte Knoten SO die Markierung. Auf welche Weise die Markierung
zurückgesetzt werden kann, wird weiter unten beschrieben.
-
Die
Zwischenknoten auf dem Pfad zum Senkenknoten SK (hier die Knoten
E und B) sowie der Senkenknoten SK selbst behandeln ein markiertes
Datenpaket ähnlich einer Antwortnachricht und tragen die
entsprechende Route zum angefragten Knoten SO (Knoten J) in ihre
Routing-Tabelle ein. In dem Eintrag in der Routing-Tabelle müssen
mindestens die folgenden Informationen eingetragen werden:
- – Zieladresse: Dies ist die Adresse
des angefragten Knotens SO (hier: Knoten J), d. h. die Quelladresse des
markierten Datenpakets.
- – Nächster Hop zum Zielknoten: Die Adresse
des nächsten Sensorknotens auf dem Weg zum angefragten Sensorknoten,
d. h. die Sender-Adresse des markierten Datenpakets.
- – Eine Lebenszeit des Pfads: Die Zeitdauer, nach der
der Pfad zum angefragten Knoten SO aus der Routing-Tabelle gelöscht
wird.
-
Verschiedene
Mechanismen setzen die Lebenszeit auf ihren Maximalwert zurück,
die unten beschrieben werden. Auf alle Fälle geschieht
dies bei Erhalt eines erfindungsgemäß markierten
Datenpakets vom angefragten Sensorknoten SO (Zieladresse) und beim
Erhalt von Datenpaketen vom Senkenknoten SK, die an den angefragten
Sensorknoten SO adressiert sind. Der Maximalwert der Lebenszeit
kann dem Zwischenknoten durch Konfiguration mitgeteilt werden. Es
ist auch möglich, diesen Wert in die markierten Datenpakete
einzufügen, so dass dieser Wert für die Routing-Tabelle
genommen wird.
-
Der
Maximalwert für die Lebenszeit des Pfads vom Senkenknoten
SK zum angefragten Knoten SO (sog. Downlink-Pfad) sollte so gewählt
werden, dass dieser beim Senden des nächsten Datenpakets
durch den Senkenknoten SK auf diesem Pfad noch exis tiert. Eine Pfadmetrik
wird nicht benötigt, da der Pfad vom Senkenknoten SK zum
angefragten Knoten SO genau dem bereits existierenden Pfad vom angefragten
Sensorknoten zum Senkenknoten entspricht.
-
Alternativ
kann, ähnlich wie im On-Demand-Modus von HWMP, eine explizite
Anfrage-Nachricht mit mehreren Zieladressen gesendet werden. Das
erfordert zwar zusätzliche Routing-Pakete, aber zusammen
mit den anderen Mechanismen des Verfahrens braucht eine solche explizite
Anfrage-Nachricht nur einmal im Sensornetz verteilt werden, so dass
die Anzahl zusätzlicher Routing-Pakete gering ist. Es müssen
nicht alle Knoten des Sensornetzwerks die Anfrage-Nachricht empfangen.
In vermaschten Netzwerken wird die Anfrage-Nachricht jedoch meistens
an alle Knoten weitergeleitet. Deshalb bringt eine Kombination einer
Anfrage-Nachricht mit dem Pfadaufbau zum Senkenknoten SK eine zusätzliche
Aktualisierung der Pfade zum Senkenknoten SK. Eine Anfrage-Nachricht,
die vom Senkenknoten SK initiiert wurde, aktualisiert automatisch
in allen Teilnehmerknoten, die diese Anfrage-Nachricht enthalten,
den Pfad zum Senkenknoten.
-
Da
Knoten, die eine solche Anfrage-Nachricht erhalten und deren Adresse
in der Liste der Zieladresse enthalten ist, ihre Adresse vor dem
Weiterleiten aus der Liste löschen, kann es vorkommen,
dass die Liste der Zieladressen leer ist, aber noch nicht alle Teilnehmerknoten
SE die Anfrage-Nachricht zum Aktualisieren der Pfade zum Senkenknoten
SK bekommen haben. Es führt jedoch zu keinem Fehlverhalten
des Netzwerks NET, wenn diese Teilnehmerknoten SE die Anfrage-Nachricht
nicht erhalten.
-
Allerdings
kann die Aktualität der Pfade zum Senkenknoten SK durch
ein Weiterleiten erhöht werden. Dazu wird den Teilnehmerknoten
SE mitgeteilt, auch eine Anfrage mit einer leeren Liste von Zieladressen
weiterzuleiten. Hierzu gibt es verschiedene Möglichkeiten:
- – Es werden generell alle Anfrage-Nachrichten,
die vom Senkenknoten SK initiiert wurden, weitergeleitet, unabhängig
davon, ob eine Zieladresse in der Anfrage-Nachricht enthalten ist
oder nicht.
- – Es wird die Broadcast-Adresse als Zieladresse angegeben.
Da aber die Sensorknoten mit den enthaltenen Sensorknoten eigentlich
aufgefordert werden, eine Antwort-Nachricht an den Senkenknoten
zu senden, benötigt die Broadcast-Adresse eine Sonderbehandlung,
da nicht jeder, sondern nur bestimmte Sensorknoten eine Antwort-Nachricht
schicken sollen.
- – Es wird ein Flag in der Anfrage-Nachricht verwendet.
Bei gesetztem Flag wird die Anfrage-Nachricht auch bei leerer Zieladressenliste
weitergeleitet. Ist das Flag nicht gesetzt, wird die Anfrage-Nachricht
nicht weitergeleitet, wenn die Zieladressenliste leer ist.
-
Die
angefragten Knoten SO reagieren auf den Erhalt einer Anfrage-Nachricht
wie beim Erhalt eines Beacons, in dem sie in der Liste der Zieladressen
aufgeführt sind, d. h. mit dem Markieren ihrer Datenpakete zum
Senkenknoten SK.
-
Die
Lebenszeit des Pfads PF wird durch das Weiterleiten von Datenpaketen
auf diesem Pfad mit jedem Datenpaket wieder auf den Ausgangswert
gesetzt. In der Regel erneuert ein Datenpaket die Lebenszeit beider
Richtungen eines Pfads PF. Für das erfindungsgemäße
Verfahren ist es notwendig, dass Datenpakete, die nicht in der beschriebenen
Weise markiert sind, die Lebenszeit nur für die Richtung
des Pfads erneuern, in die sie weitergeleitet werden. Dies bedeutet,
dass der Pfad PF vom Senkenknoten SK zu dem angefragten Knoten SO
(Downlink-Pfad) durch Pakete, die der Senkenknoten SK, an einen
Teilnehmerknoten SO überträgt, aktualisiert wird,
jedoch nicht durch unmarkierte Datenpakete, die der Teilnehmerknoten
SO an den Senkenknoten SK im Rahmen seiner normalen Funktion schickt.
Ansonsten würde dies dazu führen, dass ein einmal aufgesetzter,
bidirektionaler Pfad dauerhaft bidirektional bleibt.
-
Eine
Ausnahme hiervon bilden die in beschriebener Weise markierten Datenpakete
des angefragten Knotens SO, die an den Senkenknoten SK übertragen
werden. Durch die mit ihrer Markierung mitgeteilte Routing-Funktionalität
setzen sie die Lebenszeit des Downlink-Pfads vom Senkenknoten SK
zum angefragten Knoten SO auch wieder auf den Ausgangswert.
-
Das
Verfahren berücksichtigt auch die Wartung eines einmal
aufgebauten bidirektionalen Pfads zwischen dem Senkenknoten SK und
einem angefragten Knoten SO bei Änderungen der Topologie.
-
Die
Assoziation eines Teilnehmerknotens SE zu seinem Vorgänger
in der Baumstruktur des Netzwerks kann aufgrund von schwankenden
Umgebungsbedingungen auf einen anderen Vorgängerknoten
wechseln, wodurch sich die Metrik zum Senkenknoten ändert.
Im schlimmsten Fall erfolgt ein Link-Bruch, so dass eine Übermittlung
von Datenpaketen zwischen dem Teilnehmerknoten und seinem Vorgängerknoten
nicht mehr möglich ist. Es sind Konstellationen in der
Netzwerk-Topologie möglich, bei denen der Senkenknoten
die Unterbrechung des Pfads zum Teilnehmerknoten nicht mitbekommt
und deshalb die Datenpakete vom Senkenknoten SK nicht an einen auf
dem Pfad befindlichen Teilnehmerknoten SE oder den angefragten Knoten
SO übermittelt werden können. Aus diesem Grund
müssen alle vom Senkenknoten SK ausgehenden Pfade, die über
diesen nicht mehr benutzten oder nicht mehr verfügbaren
Link gehen, in allen Zwischenknoten und im Senkenknoten SK aktualisiert
werden.
-
Die
Pfade in Uplink-Richtung, d. h. von einem Teilnehmerknoten SE oder
dem angefragten Knoten SO in Richtung des Senkenknotens SK, werden
automatisch über die erhaltenen Beacons aktualisiert. Damit
auch die Downlink-Pfade in umgekehrter Richtung vom Senkenknoten
SK zum angefragten Knoten SO aktuali siert werden, müssen
die Datenpakete der angefragten Knoten SO solange in der beschriebenen
Weise markiert werden, wie der entsprechende Pfad vom Senkenknoten
SK zum angefragten Knoten SO existieren soll.
-
Verfahren A
-
Damit
ein angefragter Knoten SO auch weiß, ob ein Pfad vom Senkenknoten
SK zu ihm existiert, der gewartet werden muss, wird die Lebenszeit
des Downlink-Pfads vom Senkenknoten SK zum angefragten Knoten SO
(abgekürzt SK → SO) auch im angefragten Knoten
SO mitgeführt. Es ist dafür ein Timer vorgesehen, der
mit der maximalen Lebenszeit des Pfads initialisiert wird und beim
Erzeugen des Pfads vom Senkenknoten SK zum angefragten Knoten SO
(Sensorknoten) gestartet wird. Dies ist der Zeitpunkt, an dem das
erste markierte Datenpaket nach einer solchen Anfrage vom angefragten
Knoten SO verschickt wird. Insbesondere entspricht die initiale
Lebenszeit für den Pfad vom Senkenknoten SK zum angefragten
Knoten SO in diesem Sensorknoten der Lebenszeit, die in den dazwischen
liegenden Knoten für diesen Pfad gesetzt wird.
-
Die
Lebenszeit für den Downlink-Pfad SK → SO im angefragten
Knoten SO wird mit jedem vom Senkenknoten SK erhaltenen Paket auf
den vorgegebenen Ausgangswert, d. h. die maximale Lebenszeit, zurückgesetzt.
Datenpakete, d. h. auch markierte Datenpakete, die der angefragten
Knoten SO als Originator an den Senkenknoten SK schickt, verändern
den Timer des angefragten Knotens SO in der Regel nicht. Eine Ausnahme
ist das erste markierte Datenpaket nach Erhalt eines Beacons, in
dem der Knoten SO angefragt wurde. Das markierte Datenpaket setzt
den Timer auf den Startwert und kann über ein weiteres
Flag, das sog. Erste-Datenpaket-Flag EDPF, erkannt werden. Ist das
Erste-Datenpaket-Flag EDPF gesetzt, wird beim Senden eines markierten
Datenpakets der Timer auf den Ausgangswert gesetzt und das Erste-Datenpaket-Flag
EDPF gelöscht. Das Erste- Datenpaket-Flag EDPF wird bei
Erhalt eines Beacons mit Anfrage für den angefragten Knoten
SO gesetzt.
-
Wenn
der Timer abläuft und zu diesem Zeitpunkt das Erste-Datenpaket-Flag
EDPF nicht gesetzt ist, wird das Markierungs-Flag MF zurückgesetzt,
so dass nachfolgende Datenpakete von dem angefragten Knoten SO nicht
mehr markiert werden.
-
Das
Erste-Datenpaket-Flag EDPF kann auch mit dem Markierungs-Flag MF
in einer nicht negativen ganzzahligen Markierungsressource MR kombiniert
werden. Bei dieser Alternative gelten die folgenden Regeln:
Initialisierung | MR
:= 0 |
Erhalt
eines Beacons mit Anfrage SO | MR
:= MR + n
n ≥ 1 |
Senden
eines Datenpaketes bei MR = 0 | MR
:= 0
Datenpaket unmarkiert |
Senden
eines Datenpaketes bei MR = 1 und Timer > 0 | MR
:= 1
Datenpaket wird markiert Timer unve ändert |
Senden
eines Datenpaketes bei MR = 1 und Timer = 0 | MR
:= 1
Datenpaket wird markiert Timer wird auf Startwert gesetzt |
Senden
eines Datenpaketes bei MR > 1 | MR
:= MR – 1
Datenpaket wird markiert Timer wird auf.
Startwert gesetzt |
Timer
läuft ab | MR
:= MR – 1 |
Erhalt
eines Datenpakets vom Senkenknoten SK bei MR = 0 | MR
:= 1
Timer wird auf Startwert gesetzt |
Erhalt
eines Datenpakets vom Senkenknoten SK bei MR > 0 | MR
:= MR
Timer wird auf Startwert gesetzt |
-
Der
Summand n entspricht hierbei der Anzahl der mindestens markierten
Datenpakete nach jedem Beacon mit einer Anfrage. Es ist ausreichend,
wenn n = 1 ist.
-
Obiges
Verhalten beim Zurücksetzen der Lebenszeit auf den Maximalwert
ist etwas anders im angefragten Sensorknoten SO als in den Zwischenknoten
und dem Senkenknoten SK. Es führt dazu, dass der Timer
im angefragten Sensorknoten SO eher ablaufen kann als die Timer
für die Lebenszeit des Downlink-Pfads SK → SO
in den Zwischenknoten und im Senkenknoten SK. Das führt
zu keinem Fehlverhalten, denn der entscheidende Timer für
die finale Übertragung von Datenpaketen zum angefragten
Knoten befindet sich in dem Zwischenknoten, der der direkte Vorgänger
des angefragten Sensorknotens SO ist. Der schnellere Time-out auf
dem angefragten Knoten SO ist beabsichtigt, denn genau genommen
entspricht dieser Timer der Zeit bzw. der Aussage, dass der Downlink-Pfad
SK → SO gewartet werden soll, d. h. die Datenpakete vom
angefragten Knoten SO an den Senkenknoten SK markiert werden. Läuft
der Timer auf dem angefragten Knoten SO ab, so wird die Lebenszeit
des Downlink-Pfads SK → SO durch die nicht mehr markierten
Datenpakete nicht mehr erneuert und wird nach Ablauf der Timer in
den Zwischenknoten und im Senkenknoten SK gelöscht.
-
Sollte
in diesem Zeitraum (d. h. der Timer ist im angefragten Knoten SO
abgelaufen, der Downlink-Pfad SK → SO existiert jedoch
noch) der angefragte Knoten SO ein Datenpaket vom Senkenknoten SK erhalten,
setzt er erneut das Markierungs-Flag MF, initialisiert seinen Timer
mit dem Maximalwert für dieLebenszeit und markiert wieder
solange seine Datenpakete erfindungsgemäß, wie
der Timer aktiv ist. Dies ist exemplarisch in 3 dargestellt.
-
3 zeigt
dabei die erfindungsgemäßen Abläufe im
angefragten Knoten SO mit der Adresse „J” entsprechend
dem eben beschriebenen Verfahren A, wobei das Markierungs-Flag MF
und das Erste-Datenpaket-Flag EDPF verwendet werden. Ein nicht gesetztes
Flag ist mit „ns” gekennzeichnet, ein gesetztes
Flag durch „s” gekennzeichnet. Rechts daneben
sind die von dem angefragten Knoten SO mit der Adresse J empfangenen
(Rx) bzw. gesendeten (Tx) Datenpakete dargestellt. Die Datenpakete
sind dabei wie folgt zu lesen: „B(E), (J)” bedeutet,
dass ein Beacon des Teilnehmerknotens mit der Adresse E (Originator
des Beacons) empfangen wird, wobei das Beacon eine Anfrage für
den Knoten mit der Adresse J enthält. „D(J) → SK” bedeutet, dass
ein Datenpaket von dem Knoten mit der Adresse J an den Senkenknoten
SK übertragen/gesendet wird. Ein an den Senkenknoten SK
gerichtetes und markiertes Datenpaket ist mit D(J) → SK(m)
gekennzeichnet. Der chronologische Ablauf ergibt sich in der Figur
von oben nach unten.
-
Zunächst
sind sowohl das Erste-Datenpaket-Flag EDPF als auch das Markierungs-Flag
nicht gesetzt. Zum Zeitpunkt t1 erhält
der angefragte Knoten SO mit der Adresse J (kurz: Knoten J) ein
Beacon vom Teilnehmerknoten E, in welchem Knoten J angefragt ist
(B(E), (J)). Daraufhin werden sowohl das Erste-Datenpaket-Flag EDPF
als auch das Markierungs-Flag MF gesetzt (d. h. die Flags wechseln
jeweils von „ns” nach „s”). Zwischen
dem Zeitpunkt t1 und t2 empfängt
Knoten J weitere Beacons von den Knoten F und I, in welchen jeweils
der Knoten J angefragt ist. Zum Zeitpunkt t2 sendet
Knoten J ein markiertes Datenpaket an den Senkenknoten SK (D(J) → SK(m)).
Daraufhin wird der Timer T auf seinen Startwert SW gesetzt. Ebenfalls
wird das Erste-Datenpaket-Flag EDPF auf „nicht gesetzt-ns” geändert.
Das Markierungs-Flag MF verbleibt gesetzt „s”. Der
Timer T dekrementiert mit fortschreitender Zeit. Zum Zeitpunkt t3 empfängt Knoten J ein Datenpaket
vom Senkenknoten SK (D(SK) → J), woraufhin der Timer T
auf seinen Startwert SW zurückgesetzt wird. Gleiches passiert
zum Zeitpunkt t4. Zum Zeitpunkt t5 empfängt Knoten J ein Beacon von
Knoten E, in welchem Knoten J angefragt ist (B(E), (J)), woraufhin
das Erste-Datenpaket-Flag EDPF seinen Status auf „gesetzt-s” ändert. Zwischen
t5 und t6 ist der
Timer T von seinem Startwert SW auf den Wert 0 gefallen. Das Markierungs-Flag
MF verbleibt gesetzt „s”, da das Erste-Datenpaket-Flag
EDPF gesetzt „s” ist. Der Timer T verbleibt auf
0 bis zum Zeitpunkt t6, zu dem er auf seinen
Startwert SW gesetzt wird, da Knoten J ein markiertes Datenpaket
an den Senkenknoten SK überträgt (D(J) → SK(m)).
Gleichzeitig wird das Erste-Datenpaket-Flag EDPF in seinem Status
auf „nicht gesetzt-ns” geändert. Zum
Zeitpunkt t7 ist der Timer auf seinen Wert
0 gefallen, woraufhin auch das Markierungs-Flag MF seinen Status
auf „nicht gesetzt-ns” ändert, da das
Erste-Datenpaket-Flag EDPF ebenfalls „nicht gesetzt-ns” ist.
Zum Zeitpunkt t8 empfängt der Knoten
J ein Datenpaket vom Senkenknoten SK(D(SK) → J), woraufhin
das Markierungs-Flag seinen Status auf „gesetzt-s” ändert
und der Timer auf seinen Startwert SW gesetzt wird. Zwischen t8 und t9 erhält
Knoten J ein Beacon B(E), in dem kein Knoten angefragt ist. Deshalb
werden die Zustände des Erste-Datenpaket-Flags EDPF und
des Markierungs-Flags MF nicht verändert. Ebenfalls erreicht
der Timer T den Wert 0, und das Markierungs-Flag MF wird auf „nicht
gesetzt-ns” gesetzt. Zum Zeitpunkt t9,
an dem Knoten J ein Datenpaket an den Senkenknoten SK schickt, weist
der Timer T bereits einen Wert von 0 auf, ebenso ist das Markierungs-Flag
mittlerweile „nicht gesetzt-ns”. Ein vom Knoten J
an den Senkenknoten SK gesendetes Datenpaket ist deshalb nicht markiert
(D(J) → SK).
-
Verfahren B
-
Ein
alternatives und auf dem angefragten Knoten SO timerloses Verfahren
enthält ein entsprechendes Flag MF(B.1) bzw. MF(B.2) für
die Existenz des Downlink-Pfads SK → SO. Der angefragte
Knoten SO markiert so lange seine Datenpakete, wie das Markierungs-Flag
MF gesetzt ist. B.1 bzw. B.2 kennzeichnen hierbei zwei unterschiedliche
Verfahren, welche weiter unten näher erläutert
werden. Das Markierungs-Flag MF wird gesetzt
- – durch
Beacons, in denen der Knoten in der Liste der Zieladresse enthalten
ist, also angefragt wird, und/oder
- – durch Datenpakete, die der angefragte Knoten SO vom
Senkenknoten SK erhält.
-
Durch
die Kombination dieser beiden Bedingungen braucht ein Knoten nur
einmal in den Beacons für die Dauer eines Downlink-Pfads
SK → SO angefragt werden, unabhängig davon, über
wie viele Beacon-Intervalle dieser Pfad existiert. Dadurch können
auch trotz der beschränkten Anzahl von angefragten Knoten
SO im Beacon unabhängig von der maximal zulässigen
Größe der Pfad-Nachricht beliebig viele Downlink-Pfade SK → SO
gleichzeitig existieren, solange der Senkenknoten SK auf diesen
Pfaden Datenpakete schickt. Auch können dadurch das Beacon-Intervall
und die Lebenszeit des Pfads vollkommen unabhängig voneinander
gewählt werden.
-
Das
Markierungs-Flag MF wird zurückgesetzt
- – nach
dem Versenden von n (wobei n ≥ 1 ist) markierten Datenpaketen
an den Senkenknoten SK. Insbesondere bei n > 1 ist es vorteilhaft, wenn der Zähler
der noch zu sendenden markierten Datenpakete nach dem Erhalt eines
Beacons, in dem ein Knoten angefragt wurde, und/oder Erhalt eines
Datenpakets vom Senkenknoten SK wieder auf n gesetzt wird. Diese
Vorgehensweise entspricht dem Verfahren B.1.
- – durch das n-te (wobei n ≥ 1 ist) Beacon,
in dem der das Beacon empfangende Sensorknoten in der Liste der
Zieladressen nicht enthalten ist, also nicht angefragt wird (Verfahren
B.2).
-
Im
Verfahren B.1 hängt die Existenz des Downlink-Pfads SK → SO
stark vom Verkehrsangebot zwischen dem Senkenknoten SK und dem angefragten
Knoten SO, d. h. der Anzahl und Zeitpunkte der Datenpakete, ab.
Deshalb ist es zweckmäßig, die Lebenszeit des
Downlink-Pfads SK → SO so groß zu wählen,
dass in möglichst vielen Fällen der Pfad noch
existiert, wenn der Senkenknoten SK das Datenpaket an den angefragten
Knoten SO schicken möchte. Die Lebenszeit sollte also größer
als die Zeitspanne zwischen dem Schicken des markierten Datenpakets
und dem nächsten Datenpaket vom Senkenknoten SK an den
angefragten Knoten SO sein. Falls der Downlink-Pfad SK → SO
doch schon gelöscht sein sollte, muss der Senkenknoten SK
den Pfad explizit wieder aufsetzen, indem er den angefragten Knoten
SO in die Liste der Zieladressen im nächsten Beacon einträgt.
-
Im
Verfahren B.2 kann ein Konflikt mit dem eingangs beschriebenen Verfahren,
Adressen aus der Zieladressenliste zu löschen, entstehen:
Ein angefragter Knoten SO entfernt seine eigene Adresse aus der
Liste der Zieladressen im Beacon, bevor er es aussendet. Empfängt
er diese Beacon später noch einmal, würde er aufhören,
seine Datenpakete zu markieren. Eventuell hat er auch noch gar kein
markiertes Datenpaket gesendet. Diese Situation kann wie folgt berücksichtigt
werden:
- – Mindestens ein Datenpaket
an den Senkenknoten SK nach dem Erhalt des Beacons, in dem ein Teilnehmerknoten
angefragt wurde, wird markiert und die Lebenszeit des Downlink-Pfads
SK → SO wird so groß gewählt, dass mindestens
die Aussendung der nächsten Beacon-Runde in die Lebenszeit
fällt. Die Lebenszeit ist somit größer
als das Beacon-Intervall bzw. die Lebenszeit ist größer
als (n·Beacon-Intervall), falls (n – 1) Beacon-Ausfälle
tolerierbar sind.
- – Angefragte Knoten SO löschen sich nicht
aus der Liste der Zieladresse im Beacon beim Weiterleiten.
- – Die Liste der Zieladressen wird lediglich dann überprüft,
wenn die Sequenznummer des Beacons größer ist
als die Sequenznummer des Beacons, durch welches der aktuelle Pfad
zum Senkenknoten SK eingetragen wurde oder bei gleicher Sequenznummer
die Distanz zum Senkenknoten SK besser ist.
-
4 zeigt
die chronologischen Abläufe im angefragten Knoten SO mit
der Adresse „J” (kurz: Knoten J) entsprechend
den Verfahren B.1 und B.2. Bei beiden Varianten B.1 und B.2 ist
n = 1. Die Lebenszeit des Pfads ist etwas länger als dreimal
das Intervall zum Versenden von Daten durch den Knoten J.
-
Zum
Zeitpunkt t1 sendet der Knoten J ein Datenpaket
an den Senkenknoten SK (D(J) → SK). Zu diesem Zeitpunkt
sind in beiden Verfahren B.1 und B.2 die Markierungs-Flags MF(B.1)
bzw. MF(B.2) „nicht gesetzt-ns”. Zum Zeitpunkt
t2 empfängt der Knoten J ein Beacon
des benachbarten Knotens E, in welchem Knoten J angefragt ist (B(E),
(J)), woraufhin die Markierungs-Flags MF(B.1) bzw. MF(B.2) ihren
Status auf „gesetzt-s” ändern. Zwischen
dem Zeitpunkt t2 und t3 empfängt
der Knoten J weitere Beacons von den Knoten F und I, in welchen er
jeweils angefragt ist, was jedoch zu keinerlei Änderung
der Markierungs-Flags führt. Erst zum Zeitpunkt t3 mit dem Aussenden eines markierten Datenpakets
vom Knoten J an den Senkenknoten SK (D(J) → SK(m)) ändert
das Markierungs-Flag MF(B.1) gemäß Verfahren B.1
seinen Status auf „nicht gesetzt-ns”, während
das Markierungs-Flag MF(B.2) des Verfahrens B.2 seinen Status „gesetzt-s” beibehält.
Mit dem Empfang eines Datenpakets vom Senkenknoten SK (D(SK) → J)
zum Zeitpunkt t4 ändert das Markierungs-Flag
MF(B.1) gemäß dem Verfahren B.1 seinen Status
und ist wiederum „gesetzt-s”. Das Aussenden eines
markierten Datenpakets zum Zeitpunkt t5 an
den Senkenknoten SK (D(J) → SK(m)) ändert wiederum
den Status des Markierungs-Flags MF(B.1), während das Markierungs-Flag
des Verfahrens B.2 unverändert „gesetzt-s” bleibt.
Das beschriebene Verfahren wird bis zum Zeitpunkt t12 beibehalten.
Zum Zeitpunkt t13 empfängt der
Knoten J ein Beacon des Knotens E (B(E)), in dem der Knoten J nicht
angefragt ist, woraufhin das Markierungs-Flag gemäß dem
Verfahren B.2 MF(B.2) seinen Status auf „nicht gesetzt-ns” ändert.
Ein zum Zeitpunkt t14 ausgesendetes Datenpaket
des Knotens J an den Senkenknoten SK ist demgemäß in
beiden Verfahren B.1 und B.2 nicht mehr markiert (D(J) → SK).
Da nach dem Zeitpunkt t14 durch den Knoten
J kein Beacon mehr empfangen wird, in welchem dieser angefragt ist,
bleiben die Markierungs-Flags unverändert auf „nicht
gesetzt-ns”.
-
Die
markierten Datenpakete von J setzen die folgenden Einträge
in den Routing-Tabellen der entsprechenden Sensorknoten voraus.
Die unten stehende Routing-Tabelle gilt hierbei für sämtliche
Verfahren A, B.1 und B.2.:
Sensorknoten
der Routing-Tabelle | Zieladresse | Nächster
Hop | Lebenszeit |
E | J | J | < Lebenszeit > |
B | J | E | < Lebenszeit > |
SK | J | B | < Lebenszeit > |
-
Ändert
sich der Pfad J → SK beim Weiterleiten der Beacons, so
wird das nächste erfindungsgemäß markierte
Datenpaket von J dem Pfad SK → J auf diesen neuen Pfad
gelegt.
-
Bei
den vorgestellten Verfahren A, B.1 und B.2 hängt die Existenz
des Downlink-Pfads SK → SO davon ab, ob Datenpakete auf
diesem Pfad gesendet werden. Soll der Pfad auch vorgehalten werden,
wenn keine Datenpakete vom Senkenknoten zum angefragten Knoten SO
geschickt werden, so muss der Senkenknoten SK rechtzeitig diesen
angefragten Sensorknoten SO in die Liste der Zieladressen im Beacon
einfügen, damit der Timer für das Markieren der
Datenpakete im angefragten Knoten SO wieder auf den Maximalwert
gesetzt wird. Alternativ können auch leere Datenpakete
geschickt werden.
-
Weiterhin
darf allgemeiner Datenverkehr, welcher von den Sensorknoten zu dem
Senkenknoten gesendet wird, keine neuen Pfadeinträge im
Senkenknoten generieren. Dies ist nur bei speziell markierten Datenpaketen,
wie oben beschrieben, möglich. Dadurch wird die Anzahl
der Pfadeinträge auf dem Senkenknoten SK reduziert. Es
werden nur die Knoten eingetragen, zu welchen der Senkenknoten senden
möchte.
-
Literaturverzeichnis
-
- [1] IEEE 802.11s/D2.02 Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications Amendment
10: Mesh Networking, Kapitel 11 B.9.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - Standard IEEE
802.15.4 [0009]
- - IEEE 802.11 [0011]
- - IEEE 802.11s D2.02 [0011]