DE102009043403B4

DE102009043403B4 - Verfahren zum Aufbau eines bidirektionalen Kommunikationspfads in einem drahtlosen Netzwerk

Info

Publication number: DE102009043403B4
Application number: DE102009043403A
Authority: DE
Inventors: Michael Bahr; Torsten Meyer; Dr. Vicari Norbert
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2009-09-29
Filing date: 2009-09-29
Publication date: 2012-04-12
Anticipated expiration: 2029-09-30
Also published as: EP2484152A1; CN102577518A; DE102009043403A1; WO2011038963A1; US20120182943A1

Abstract

Die Erfindung beschreibt ein Verfahren zum Aufbau eines bidirektionalen Kommunikationspfads (PF) in einem drahtlosen Netzwerk (NET), insbesondere einem drahtlosen Sensornetzwerk, wobei das Netzwerk (NET) Knoten in Form eines Senkenknotens (SK) und einer Mehrzahl von Teilnehmerknoten (SE) aufweist und wobei zwischen dem Senkenknoten (SK) und zumindest einem angefragten Knoten (SO) der Teilnehmerknoten (SE) der Kommunikationspfad (PF) für die bidirektionale Übermittlung von Datenpaketen aufzubauen ist. Ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten (SE) zu dem Senkenknoten (SK) wird dadurch ermittelt, dass ein periodischer Austausch von Pfad-Nachrichten zwischen benachbarten Knoten (SK, SE) des Netzwerks (NET) erfolgt, wobei eine jeweilige Pfad-Nachricht den jeweils kürzesten Abstand zu dem Senkenknoten (SK), insbesondere in Form einer Metrik, signalisiert. Des Weiteren verwaltet jeder der Knoten (SE) seinen Pfad zu dem Senkenknoten (SK) dadurch, dass dieser die Adresse des benachbarten Knotens (SE) mit der besten Metrik zu dem Senkenknoten (SK) zur Weiterleitung der Datenpakete abspeichert. Ein Downlink-Pfad von dem Senkenknoten (SK) zu dem zumindest einen angefragten Knoten (SO) wird dadurch ermittelt, dass in zumindest eine der, von dem Senkenknoten (SK) gesendeten Pfad-Nachrichten eine Adressliste eingefügt wird, welche die Adresse eines jeweiligen angefragten Knoten (SO) umfasst. Jeder Teilnehmerknoten (SE), der eine Pfad-Nachricht mit einer Adressliste empfängt, fügt die Adressliste an die von ihm ausgesendete Pfad-Nachricht ein, und der oder die in der Adressliste adressierten Teilnehmerknoten (SE) gehen beim Empfang der Pfad-Nachricht mit der Adressliste als angefragte Knoten (SO) in einen dedizierten Sendezustand über.

Description

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.
Aus der EP 1 677 473 A1 ist ein Verfahren zur Organisation einer Mehrzahl von Kommunikationseinheiten in einem ad hoc Kommunikationssystem bekannt, bei der die Kommunikationseinheiten in einen oder mehreren Kommunikationsgraphen organisiert werden.
Aus der US 2006/0088013 A1 ist ein drahtloses Sensornetzwerk bekannt, das eine Mehrzahl von miteinander drahtlos kommunizierenden Knoten umfasst. Dabei legt zumindest einer der Sensorknoten ein Eintreffen eines Ereignisses fest, anhand dessen diesbezügliche Daten an andere Sensorknoten gesendet werden.
Aus der WO 02/076028 A1 geht ein Netzwerkprotokoll hervor, bei dem Netzknoten mit geringer Energieaufnahme in einem selbst organisierendem drahtlosen Netzwerk unter Einsatz eines spanning tree protocol organisiert werden.
Aus der US 2006/0034191 A1 geht ein Verfahren zum Austausch von Informationen in einem Kommunikationsnetzwerk mit einer Mehrzahl hierarchisch adressierter Knoten hervor.
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 bedeutet, 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 Kommunikationsverhalten 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, fuhrt.
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 zusä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 zur Anforderung 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 zur Anforderung 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 besten 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 gesetztem 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 Senkenknoten 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 ausgesendete 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 dargestellte 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, über 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 existiert. 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 Senkenkonten 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 aktualisiert 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 unverä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 die Lebenszeit 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 t₁ 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 t₁ und t₂ empfängt Knoten J weitere Beacons von den Knoten F und I, in welchen jeweils der Knoten J angefragt ist. Zum Zeitpunkt t₂ 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 t₃ 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 t₄. Zum Zeitpunkt t₅ 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 t₅ und t₆ 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 t₆, 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 t₇ 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 t₈ 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 t₈ und t₉ 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 t₉, 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 t₁ 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 t₂ 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 t₂ und t₃ 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 t₃ 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 t₄ ä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 t₅ 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 t₁₂ beibehalten. Zum Zeitpunkt t₁₃ 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 t₁₄ 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 t₁₄ 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.

Claims

Verfahren zur Anforderung eines bidirektionalen Kommunikationspfads (PF) in einem drahtlosen Netzwerk (NET), insbesondere einem drahtlosen Sensornetzwerk, wobei das Netzwerk (NET) Knoten in Form eines Senkenknotens (SK) und einer Mehrzahl von Teilnehmerknoten (SE) aufweist, wobei zwischen dem Senkenknoten (SK) und zumindest einem angefragten Knoten (SO) der Teilnehmerknoten (SE) der Kommunikationspfad (PF) für die bidirektionale Übermittlung von Datenpaketen aufzubauen ist, bei dem: – ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten (SE) zu dem Senkenknoten (SK) dadurch ermittelt wird, dass – ein periodischer Austausch von Pfad-Nachrichten zwischen benachbarten Knoten (SK, SE) des Netzwerks (NET) erfolgt, wobei eine jeweilige Pfad-Nachricht den jeweils kürzesten Abstand zu dem Senkenknoten (SK), insbesondere in Form einer Metrik, signalisiert, und – jeder der Knoten (SE) seinen Pfad zu dem Senkenknoten (SK) dadurch verwaltet, dass dieser die Adresse des benachbarten Knotens (SE) mit der besten Metrik zu dem Senkenknoten (SK) zur Weiterleitung der Datenpakete abspeichert; – ein Downlink-Pfad von dem Senkenknoten (SK) zu dem zumindest einen angefragten Knoten (SO) dadurch ermittelt wird, dass – in zumindest eine der, von dem Senkenknoten (SK) gesendeten Pfad-Nachrichten eine Adressliste eingefügt wird, welche die Adressen der jeweiligen angefragten Knoten (SO) umfasst; – jeder Teilnehmerknoten (SE), der eine Pfad-Nachricht mit einer Adressliste empfängt, die Adressliste an die von ihm ausgesendete Pfad-Nachricht einfügt, und – der oder die in der Adressliste adressierten Teilnehmerknoten (SE) beim Empfang der Pfad-Nachricht mit der Adressliste als angefragte Knoten (SO) in einen dedizierten Sendezustand übergehen.
Verfahren nach Anspruch 1, bei dem ein angefragter Knoten (SO) beim Empfang einer Pfad-Nachricht mit der Adressliste seine Adresse aus der Adressliste entfernt, bevor der angefragte Knoten seine Pfad-Nachricht mit der Adressliste an die zu ihm benachbarten Knoten aussendet.
Verfahren nach Anspruch 1 oder 2, bei dem ein Teilnehmerknoten (SE) Pfad-Nachrichten nur von einem solchen benachbarten Knoten berücksichtigt, der aufgrund der Pfad-Nachricht als nächster Hop zu dem Senkenknoten (SK) ausgewählt wird.
Verfahren zur Anforderung eines bidirektionalen Kommunikationspfads (PF) in einem drahtlosen Netzwerk (NET), insbesondere einem drahtlosen Sensornetzwerk, wobei das Netzwerk (NET) Knoten in Form eines Senkenknotens (SK) und einer Mehrzahl von Teilnehmerknoten (SE) aufweist, wobei zwischen dem Senkenknoten (SK) und zumindest einem angefragten Knoten (SO) der Teilnehmerknoten (SE) der Kommunikationspfad (PF) für die bidirektionale Übermittlung von Datenpaketen aufzubauen ist, bei dem: – ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten (SE) zu dem Senkenknoten (SK) dadurch ermittelt wird, dass – ein periodischer Austausch von Pfad-Nachrichten zwischen benachbarten Knoten (SK, SE) des Netzwerks (NET) erfolgt, wobei eine jeweilige Pfad-Nachricht den jeweils kürzesten Abstand zu dem Senkenknoten (SK), insbesondere in Form einer Metrik, signalisiert, und – jeder der Knoten (SE) seinen Pfad zu dem Senkenknoten (SK) dadurch verwaltet, dass dieser die Adresse des benachbarten Knotens (SE) mit der besten Metrik zu dem Senkenknoten (SK) zur Weiterleitung der Datenpakete abspeichert; – ein Downlink-Pfad von dem Senkenknoten (SK) zu dem zumindest einen angefragten Knoten (SO) dadurch ermittelt wird, dass – zusätzlich zu den periodisch gesendeten Pfad-Nachrichten durch den Senkenknoten (SK) eine Anfrage-Nachricht mit einer Adressliste, welche die Adresse eines jeweiligen angefragten Knoten (SO) umfasst, ausgesendet wird, – die Anfrage-Nachricht durch jeden diese empfangenden Knoten an die jeweils benachbarten Knoten weitergeleitet wird, und – der oder die in der Adressliste adressierten Teilnehmerknoten (SE) beim Empfang der Anfrage-Nachricht mit der Adressliste als angefragte Knoten (SO) in einen dedizierten Sendezustand übergehen.
Verfahren nach Anspruch 4, bei dem die Teilnehmerknoten (SE), die in der Adressliste adressiert sind, ihre Adresse aus der Adressliste vor dem Weiterleiten an die jeweils benachbarten Knoten entfernen.
Verfahren nach Anspruch 5, bei dem die Teilnehmerknoten (SE), die eine von dem Senkenknoten initiierte Anfrage-Nachricht empfangen, diese an ihre benachbarten Knoten weiterleiten.
Verfahren nach Anspruch 5, bei dem die Teilnehmerknoten (SE), die eine von dem Senkenknoten initiierte Anfrage-Nachricht mit einer darin enthaltenen Broadcast-Adresse als Zieladresse der Anfrage-Nachricht erhalten, diese Broadcast-Adresse nicht als Anfrage interpretieren und die Anfrage-Nachricht an ihre benachbarten Knoten weiterleiten.
Verfahren nach Anspruch 5, bei dem in die Anfrage-Nachricht ein Indikator (Flag) eingefügt wird, welcher den die Anfrage-Nachricht empfangenden Knoten signalisiert, dass die Anfrage-Nachricht auch bei leerer Adressliste an die benachbarten Knoten weiterzuleiten ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der zumindest eine angefragte Knoten (SO) zumindest das nächste, an den Senkenknoten (SK) zu sendende Datenpaket in vorgegebener Weise mit einer Markierung versieht, welche von den auf dem Kommunikationspfad (PF) zu dem Senkenknoten (SK) liegenden Teilnehmerknoten (SE) als Indikator für eine Antwort-Nachricht interpretiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Teilnehmerknoten (SE), die auf dem Pfad von einem angefragten Knoten (SO) zu dem Senkenknoten (SK) liegen, als auch der Senkenknoten (SK) den Downlink-Pfad in ihre Weiterleitungs-Tabelle eintragen, wenn diese ein markiertes Datenpaket von einem der angefragten Knoten (SO) empfangen.
Verfahren nach Anspruch 10, bei dem in die Weiterleitungs-Tabelle zumindest folgende Informationen eingetragen werden: – eine Zieladresse, welche die Adresse des angefragten Knotens (SO) ist, und der Quelladresse eines markierten Datenpakets entspricht; – eine Adresse eines benachbarten Teilnehmerknotens (SE), welche die Adresse des nächsten Teilnehmerknotens (SE) auf dem Pfad zur Zieladresse ist; – eine einer Lebensdauer eines Kommunikationspfads (PF) entsprechende Information, wobei diese angibt, nach welcher Zeitdauer der Pfad zum angefragten Knoten (SO) aus der Weiterleitungs-Tabelle gelöscht wird.
Verfahren nach Anspruch 11, bei dem die Lebensdauer eines Pfades vom Senkenknoten (SK) zum angefragten Knoten (SO) 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 (SO), welches an den Senkenknoten (SK) übertragen wird, oder – bei Erhalt oder Weiterleiten eines von dem Senkenknoten (SK) gesendeten Datenpakets, das an den angefragten Knoten (SO) adressiert ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein markiertes Datenpaket mit einer Sequenznummer versehen wird.
Verfahren nach einem der Ansprüche 9 bis 13, bei dem eine Notwendigkeit der Pfadwartung eines Downlink-Pfades in dem betreffenden angefragten Knoten (SO) durch ein Markierungs-Flag (MF) gekennzeichnet wird, wobei bei gesetztem Markierungs-Flag (MF) die Datenpakete an den Senkenknoten (SK) mit der Markierung gekennzeichnet werden.
Verfahren nach Anspruch 14, bei dem ein mit der maximalen Pfad-Lebenszeit initialisierter Timer beim Erzeugen eines Downlink-Pfads gestartet wird.
Verfahren nach Anspruch 15, bei dem durch einen Teilnehmerknoten (SE) das Markierungs-Flag MF und ein weiteres Flag (EDPF) gesetzt wird, sobald dieser zu einem angefragten Knoten (SO) wird, wobei das weitere Flag (EDPF) mit der Übertragung des ersten, mit einer Markierung gekennzeichneten Datenpakets an den Senkenknoten (SK) gelöscht wird.
Verfahren nach Anspruch 16, bei dem der zumindest eine angefragte Knoten (SO) ein an den Senkenknoten (SK) zu sendende Datenpaket nicht mehr mit der Markierung versieht, wenn der Timer abgelaufen ist und das weitere Flag (EDPF) sowie das Markierungs-Flag (MF) nicht gesetzt sind.
Verfahren nach Anspruch 16, bei dem das Flag (EDPF) mit einer nicht-negativen Markierungsressource kombiniert wird, welche die Anzahl der mindestens markierten Datenpakete nach jeder Anfrage durch den Senkenknoten (SK) berücksichtigt.
Verfahren nach einem der Ansprüche 11 bis 13, bei dem ein Markierungs-Flag (MF) für die Existenz eines Downlink-Pfades verwendet wird, wobei der betreffende angefragte Knoten (SO) die von ihm an den Senkenknoten (SK) gesendeten Datenpakete mit der Markierung versieht, solange das Markierungs-Flag (MF) gesetzt ist.
Verfahren nach Anspruch 19, bei dem das Markierungs-Flag (MF) zurückgesetzt wird, wenn eine vorgegebene Anzahl an mit einer Markierung versehenen Datenpaketen an den Senkenknoten (SK) von einem jeweiligen angefragten Knoten (SO) gesendet wurde.
Verfahren nach Anspruch 19, bei dem das Markierungs-Flag (MF) zurückgesetzt wird, wenn der angefragte Knoten (SO) in einer vorgegeben Anzahl an empfangenen Pfad-Nachrichten nicht mehr in der Adressliste enthalten ist.
Verfahren nach einem der Ansprüche 14 bis 21, bei dem das Markierungs-Flag (MF) gesetzt wird durch: – eine Pfad-Nachricht, in der der Teilnehmerknoten (SE) in der Adressliste enthalten ist, und/oder – Datenpakete, die der angefragte Knoten (SO) von dem Senkenknoten (SK) empfängt.
Computerprogrammprodukt, das direkt in den internen Speicher eines digitalen Rechners geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß einem der vorhergehenden Ansprüche ausgeführt werden, wenn das Produkt auf dem Rechner läuft.
Netzwerk (NET), insbesondere drahtloses Sensornetzwerk, wobei das Netzwerk (NET) Knoten in Form eines Senkenknotens (SK) und einer Mehrzahl von Teilnehmerknoten (SE) aufweist, wobei zwischen dem Senkenknoten (SK) und zumindest einem angefragten Knoten (SO) der Teilnehmerknoten (SE) der Kommunikationspfad (PF) für die bidirektionale Übermittlung von Datenpaketen aufbaubar ist, bei dem: – ein Uplink-Pfad von einem jeweiligen der Teilnehmerknoten (SE) zu dem Senkenknoten (SK) dadurch ermittelbar ist, dass – ein periodischer Austausch von Pfad-Nachrichten zwischen benachbarten Knoten (SK, SE) des Netzwerks (NET) erfolgt, wobei eine jeweilige Pfad-Nachricht den jeweils kürzesten Abstand zu dem Senkenknoten (SK), insbesondere in Form einer Metrik, signalisiert, und – jeder der Knoten (SE) seinen Pfad zu dem Senkenknoten (SK) dadurch verwaltet, dass dieser die Adresse des benachbarten Knotens (SE) mit der besten Metrik zu dem Senkenknoten (SK) zur Weiterleitung der Datenpakete abspeichert; – ein Downlink-Pfad von dem Senkenknoten (SK) zu dem zumindest einen angefragten Knoten (SO) dadurch ermittelbar ist, dass – in zumindest eine der, von dem Senkenknoten (SK) gesendeten Pfad-Nachrichten eine Adressliste eingefügt wird, welche die Adresse eines jeweiligen angefragten Knoten (SO) umfasst; – jeder Teilnehmerknoten (SE), der eine Pfad-Nachricht mit einer Adressliste empfängt, die Adressliste an die von ihm ausgesendete Pfad-Nachricht einfügt; und – der oder die in der Adressliste adressierten Teilnehmerknoten (SE) beim Empfang der Pfad-Nachricht mit der Adressliste als angefragte Knoten (SO) in einen dedizierten Sendezustand übergehen.