DE602004011484T2

DE602004011484T2 - Verfahren und Vorrichtung zum Synchronisieren von Uhren von Netzknoten

Info

Publication number: DE602004011484T2
Application number: DE200460011484
Authority: DE
Inventors: Lenardi Dr. Massimiliano; Masato Sagamihara-shi Hayashi
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-05-28
Filing date: 2004-05-28
Publication date: 2009-01-15
Anticipated expiration: 2024-05-29
Also published as: EP1601124A1; EP1601124B1; DE602004011484D1

Description

Diese Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zum Synchronisieren von Uhren in Netzknoten in einem Kommunikationsnetz.
Jeder Knoten in einem Kommunikationsnetz besitzt normalerweise eine Uhr, die die Zeitmessung für lokale Anwendungen, die in dem Knoten ausgeführt werden, und/oder für Kommunikationszwecke bereitstellt. Die Synchronisation der Knotenuhren im Netz ist wichtig, weil im Allgemeinen lokale Uhren, die in den Knoten ausgeführt werden, nicht genau und zuverlässig sind. Verteilte Anwendungen und kommunizierende Programme können ohne eine richtige Uhrensynchronisation nicht richtig arbeiten. Ohne eine richtige Synchronisation ist z. B. keine genaue Kenntnis, warm Daten durch andere Knoten gesendet worden sind, verfügbar, können Netzwerkzeuge nicht richtig koordiniert werden und kann eine E-Mail empfangen werden, die einen Sendezeitpunkt in der Zukunft besitzt.
Ein bekanntes Protokoll zum Synchronisieren der Uhr eines Netzknotens mit einer zentralisierten Netzzeit, die durch einen Zeitserver bereitgestellt wird, ist NTP (siehe RFC 1305). Der Netzzeitserver hält z. B. ein GPS-System, um eine genaue Zeitmessung bereitzustellen. Ein Knoten, der Zeitinformationen abfragt, muss jedoch die richtige IP-Adresse (z. B. den Host-Namen) des NTP-Servers spezifizieren. Weil NTP verdrahteten Netzen mit stabilen und zuverlässigen Verbindungen zugewiesen ist, funktioniert es in drahtlosen Netzen oder in Ad-hoc-Netzen nicht gut.
In einem Ad-hoc-Netz (AHN) kann jeder Knoten als ein Client, ein Relaisknoten und/oder ein Server wirken. Außerdem kann jeder Knoten jederzeit und unerwartet dem Netz beitreten und das Netz jederzeit und unerwartet verlassen. Deshalb sind irgendwelche automatischen Prozeduren notwendig, damit der Knoten richtig (erneut) mit den anderen Knoten im Netz verbunden wird, um zu kommunizieren oder um Datenpakete weiterzuleiten.
Weil in einem Ad-hoc-Netz oft Peer-zu-Peer-Kommunikationen (P2P-Kommunikationen), deren Management durch irgendwelche Anwendungen und/oder Dienste ausgeführt wird, die in den Knoten ausgeführt werden, zwischen allen oder einem Teil der Mitglieder eines AHN aufgebaut werden, kann kein permanenter Master-Uhrenknoten (Zeitserver), der allen anderen Knoten bekannt und verfügbar ist, geschaffen werden. Folglich können master-/slave-gestützte Uhrensynchronisationsprotokolle, wie z. B. NTP, nicht direkt in einem AHN angewendet werden.
Außerdem kann eine Teilmenge der AHN-Endgeräte in Bezug auf eine spezielle Anwendung oder einen speziellen Dienst eine Gemeinschaft bilden, in der die Uhren der Knoten innerhalb der Gemeinschaft synchronisiert sein müssen. Folglich ist die Uhrensynchronisation zwischen den Entitäten, die jede einen einzigen Knoten oder eine Gruppe von Knoten in dem Netz umfassen (in denen eine oder mehrere gemeinsame Anwendungen oder ein oder mehrere gemeinsame Dienste ausgeführt werden), notwendig. Dies erfordert einen effizienten Mechanismus zum Synchronisieren der Uhren der Knoten in den Entitäten, wenn diese Entitäten in Kontakt gelangen und wenigstens eine gemeinsame Anwendung oder ein gemeinsamer Dienst in jeder Entität ausgeführt wird (d. h., die Entitäten bilden eine gemeinsame Gemeinschaft).
US-B-63174751 bezieht sich auf ein Verfahren zum Erzeugen eines Synchronisationsnetzes in einem Telekommunikationsnetz. Das Netz umfasst mehrere Knoten, die mit Verbindungen miteinander verbunden sind und die Synchronisationszustandsnachrichten senden, die das Qualitätsniveau des entsprechenden Signals bezüglich der Synchronisation angeben. Wenigstens eine Master-Uhr wird als eine Synchronisationsquelle für die Netzknoten verwendet, wobei das Synchronisationsnetz aufgebaut wird, indem in Übereinstimmung mit einer durch die Verbindungen definierten Topologie durch aufeinanderfolgende Knoten gebildete Synchronisationsketten ausgewählt werden, wobei durch diese Ketten das Signal wenigstens der Hauptuhr zu den Knoten in der Kette verteilt wird, und indem für die verschiedenen Knoten in der Kette eine knotenspezifische Prioritätsliste definiert wird, die die Knotenschnittstellen mit verschiedenen Prioritätsniveaus enthält und die die durch den Knoten auszuwählende Synchronisationsquelle bestimmt, wenn diese Signale gleicher Qualitätsniveaus an den Knotenverbindungen empfangen werden. Außerdem wird zuerst ein grundlegendes Synchronisationsnetz aus den besten Synchronisationsketten zwischen zwei verschiedenen Master-Uhren aufgebaut. Danach werden die Synchronisationsketten, die von anderen Knoten zu diesem Synchronisationsnetz führen, in das Synchronisationsnetz aufgenommen, indem die Ketten in einer Reihenfolge des Vorrangs in Übereinstimmung mit den vorgegebenen Kriterien ausgewählt werden.
Es ist deshalb eine Aufgabe der vorliegenden Erfindung, einen effizienten Mechanismus zu schaffen, um die Uhren von Netzknoten zu initialisieren und zu synchronisieren, insbesondere für die Uhren von gemeinsamen Anwendungen und/oder Diensten, die in den Knoten laufen.
Diese Aufgabe wird durch die unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche beziehen sich auf bevorzugte Ausführungsformen der Erfindung.
In einem Verfahren zum Synchronisieren von Uhren von Netzknoten in einem Kommunikationsnetz wird eine erste Priorität einer Uhr eines ersten Knotens zugewiesen und wird eine zweite Priorität einer Uhr eines zweiten Knotens zugewiesen. Um die Uhren des ersten und des zweiten Knotens zu synchronisieren, werden die Prioritäten der Uhren des ersten und des zweiten Knotens verglichen, wobei anhand des Ergebnisses des Vergleichs eine Referenzuhr mit einer höheren Priorität und eine abhängige Uhr mit einer niedrigeren Priorität unter den Uhren des ersten und des zweiten Knotens bestimmt werden. Falls sich die zugewiesenen Prioritäten auf eine Rangordnung der Uhren beziehen, kann die wichtigere Referenzuhr, der eine höhere Priorität zugewiesen ist, leicht von den Uhren, die eine Synchronisation erfordern, bestimmt werden.
Dann kann die Zeit der abhängigen Uhr, der eine niedrigere Priorität zugewiesen ist, auf die durch die Referenzuhr angegebene Zeit gestellt werden. Folglich werden die Uhren des ersten und des zweiten Knotens ohne die Notwendigkeit, eine permanente Master-Uhr zu definieren, synchronisiert. Weil die Auswahl der Referenzuhr auf dem des Ergebnis des Vergleichs der Prioritäten, die den fraglichen Uhren zugewiesen sind, basiert, ist die Entscheidung dynamisch und wählt automatisch die zum Zeitpunkt der Synchronisation verfügbare "beste" Uhr aus. Wenn eine Uhr später mit einer weiteren Uhr synchronisiert wird, kann eine Uhr, die vorher eine Referenzuhr gewesen ist, dann eine abhängige Uhr werden und umgekehrt. Dies erlaubt eine flexible prioritätsgestützte Zeitauswahl/Synchronisation.
Vorzugsweise steht die einer Uhr eines Knotens zugewiesene Priorität mit einer relativen Rangordnung der Uhren im Netz, einer Eigenschaft der Uhr und/oder einer Eigenschaft des Knotens in Beziehung. Die Prioritätszuweisung kann z. B. so sein, dass sie sich auf die Ganggenauigkeit bezieht. Einer Uhr mit einer hohen Genauigkeit, z. B. einer GPS-gestützten Uhr, die die absolute Zeit angibt, kann eine hohe Priorität zugewiesen sein. Den Uhren, die eine relative Zeit oder eine weniger genaue Zeit angeben, kann eine niedrigere Priorität zugewiesen sein. Folglich wählt die Uhrensynchronisation gemäß der Erfindung automatisch die genauere Zeitmessung, die eine höhere Priorität besitzt, als eine Referenzuhr aus. Die einer Uhr zugewiesene Priorität kann außerdem davon abhängen, ob die Uhr die Systemuhr des Knotens ist. Weil die Änderung der Zeit einer Systemuhr mehr Schwierigkeiten nach sich ziehen kann, kann eine entsprechend hohe Priorität zugewiesen sein. Im Allgemeinen ist es bevorzugt, dass die Priorität einer Uhr der Wichtigkeit der Uhr in Bezug auf die Uhren der anderen Knoten entspricht.
Falls die Prioritäten der jeweiligen Uhren für die Synchronisation die gleichen sind, kann der Vergleich anhand einer anderen Eigenschaft der Uhren oder der Knoten ausgeführt werden. Falls zwei Uhren, denen gleiche Prioritäten zugewiesen sind, synchronisiert werden müssen, kann folglich die Auswahl der Referenzuhr und der abhängigen Uhr auf zusätzlichen Kriterien basieren, wie z. B. dem Typ der Uhren, der Ganggenauigkeit, ob die Uhren eine absolute oder eine relative Zeit angeben und/oder ob die Uhr eines Systemuhr ist. Dies besitzt den Vorteil, unter Verwendung zusätzlicher Auswahlkriterien, die in einer Entscheidungshierarchie angeordnet sind, eine Pattsituation der Priorität aufzulösen.
Es ist ferner bevorzugt, dass sich die einer Uhr zugewiesene Priorität auf eine Anwendung oder einen Dienst bezieht, die bzw. der in dem Knoten ausgeführt wird. Folglich können wichtigere Anwendungen und/oder Dienste eine höhere Priorität besitzen, die der jeweiligen Uhr zugewiesen ist, wobei es folglich wahrscheinlicher ist, dass sie als eine Referenzuhr bestimmt wird, wenn die Uhrensynchronisation notwendig ist.
Ein Knoten kann mehr als eine Uhr umfassen, wobei jeder eine Priorität zugewiesen ist. Vor dem Vergleich der Prioritäten kann eine Uhr der mehreren Uhren des Knotens für die Synchronisation ausgewählt werden. Dies wird vorzugsweise anhand einer Anwendung oder eines Dienstes ausgeführt, die bzw. der dem ersten und dem zweiten Knoten gemeinsam ist. Dies bedeutet, dass, wenn zwei Knoten, die eine gemeinsame Anwendung oder einen gemeinsamen Dienst ausführen, die Synchronisation benötigen, eine jeweilige Uhr in jedem Knoten ausgewählt werden kann. Die Uhrenauswahl basiert vorzugsweise auf einer Beziehung zwischen einer Anwendung oder einem Dienst und einer entsprechenden Uhr, die in dem Knoten ausgeführt wird. In einem Knoten kann z. B. eine separate Uhr für jede Anwendung und/oder jeden Dienst, die bzw. der in dem Knoten ausgeführt wird, aufrechterhalten werden.
Falls im ersten und im zweiten Knoten eine gemeinsame Anwendung oder ein gemeinsamer Dienst erfasst worden ist, kann bestimmt werden, ob die entsprechenden Uhren die Synchronisation erfordern. Im positiven Fall können die Auswahl der Referenzuhr und das Stellen der abhängigen Uhr ausgeführt werden. Falls z. B. die Uhren vorher in irgendeiner Weise synchronisiert worden sind und/oder kein Zeitunterschied zwischen den Uhren vorhanden ist, kann keine Synchronisation notwendig sein.
Vorzugsweise werden mehrere Anwendungen und/oder Dienste in einem Knoten ausgeführt. Für jede ausgeführte Anwendung und/oder jeden ausgeführten Dienst kann eine separate Uhr im Knoten zugewiesen sein und aufrechterhalten werden. Jeder Uhr kann eine Priorität zugewiesen sein. Vorzugsweise bezieht sich die einer Uhr zugewiesene Priorität auf die Anwendung oder den Dienst, die bzw. der seine Zeitinformationen von der jeweiligen Uhr empfängt. Gemäß einer bevorzugten Ausführungsform gibt es eine Eins-zu-Eins-Entsprechnung zwischen der Anwendung/dem Dienst, der Uhr und der Priorität. Dies bedeutet, dass für eine in einem Knoten laufende Anwendung oder einen in einem Knoten laufenden Dienst eine entsprechende Uhr und eine entsprechende Priorität vorgesehen sind.
Wenn ferner zwei Knoten die Kommunikation beginnen, können sie bestimmen, ob entsprechende Anwendungen und/oder Dienste im ersten und zweiten Knoten ausgeführt werden. Im positiven Fall – der bedeutet, dass die gemeinsame Anwendung/der gemeinsame Dienst in den Knoten läuft – werden die jeweiligen Uhren des ersten und des zweiten Knotens, die der bestimmten entsprechenden Anwendung/dem bestimmten entsprechenden Dienst zugewiesen sind, für die Synchronisation ausgewählt. Dies besitzt den Vorteil einer anwendungs-/dienstgesteuerten Uhrensynchronisation. Die der gemeinsamen Anwendung oder dem gemeinsamen Dienst entsprechenden Uhren werden automatisch für die Synchronisation bestimmt.
Dies erlaubt eine automatische Synchronisation der Uhren, selbst wenn die Knoten mehrere Anwendungen und/oder Dienste ausführen. Dieser Aspekt der Erfindung ist besonders nützlich, wenn ein erster Knoten eine Anwendung oder einen Dienst mit einem zweiten Knoten gemeinsam hat und eine weitere gemeinsame Anwendung oder einen weiteren gemeinsamen Dienst mit einem dritten Knoten hat. In diesem Fall können die Uhren des ersten und des zweiten Knotens, die der jeweiligen gemeinsamen Anwendung oder dem jeweiligen gemeinsamen Dienst zugewiesen sind, synchronisiert werden, wobei die Uhren des ersten und des dritten Knotens, die der Anwendung oder dem Dienst, die bzw. der für diese Knoten gemeinsam sind, zugewiesen sind, außerdem jeweils synchronisiert werden können. In Abhängigkeit von den jeweils zugewiesenen Prioritäten kann der erste Knoten z. B. die Referenzuhr in Bezug auf den zweiten Knoten und die abhängige Uhr in Bezug auf den dritten Knoten oder umgekehrt umfassen.
Ein Netz kann eine Systemuhr und bei Bedarf zusätzliche virtuelle Uhren umfassen, die einen Versatz zur Systemuhr besitzen können. Eine virtuelle Uhr kann sich auf eine spezielle Anwendung und/oder einen speziellen Dienst beziehen, die bzw. der in dem Knoten läuft, wobei sie über das Netz mit anderen Knoten synchronisiert werden kann.
Bei dem Beginn einer neuen Anwendung oder eines neuen Dienstes in dem Knoten kann der Knoten bestimmen, ob für die neue Anwendung oder den neuen Dienst eine virtuelle Uhr notwendig ist. Es ist z. B. keine virtuelle Uhr notwendig, falls die neue Anwendung oder der neue Dienst keine Uhrensynchronisation mit einem oder mehreren anderen Knoten erfordert. Falls ein synchronisierter Betrieb der Anwendung oder des Dienstes notwendig ist, kann eine neue virtuelle Uhr initialisiert werden, wobei der virtuellen Uhr eine Priorität zugewiesen werden kann. Dies erlaubt eine Zuordnung und Unterhaltung virtueller Uhren in den Knoten bei Bedarf und schafft mehr Flexibilität in Bezug auf die Uhrenkonstruktion. Jede Anwendung oder jeder Dienst, die ihre bzw. der seine eigene Uhr erfordert, kann eine zugewiesene virtuelle Uhr empfangen, die mit den entsprechenden Uhren der anderen Netzknoten synchronisiert ist, die die gleiche Anwendung oder den gleichen Dienst ausführen.
Zwei oder mehr Knoten des Kommunikationsnetzes können in einer Gemeinschaft von Knoten angeordnet sein, die eine gemeinsam genutzte Anwendung und/oder einen gemeinsam genutzten Dienst anhand einer gemeinsam synchronisieren Uhr in der Gemeinschaft ausführen. Falls sich die erste und die zweite kommunizierende Gemeinschaft auf dieselbe Anwendung und/oder denselben Dienst beziehen, kann die Synchronisation der jeweiligen Uhren notwendig sein. Nach der Uhrensynchronisation können die erste und die zweite Gemeinschaft eine gemeinsame Gemeinschaft bilden, die eine gemeinsame synchronisierte Uhr in der neuen vergrößerten Gemeinschaft der Knoten besitzt. Dies wird gemäß der Erfindung durch das Vergleichen der den synchronisierten Uhren der ersten Gemeinschaft zugewiesenen Priorität mit der den synchronisierten Uhren der zweiten Gemeinschaft zugewiesenen Priorität, dem Bestimmen der Referenzuhr und der abhängigen Uhr und dem Stellen der Zeit der abhängigen Uhr auf die durch die Referenzuhr angegebene Zeit ausgeführt. Folglich kann der Uhrensynchronisationsmechanismus der vorliegenden Erfindung auf einzelne Netzknoten und/oder auf ganze Gemeinschaften von Netzknoten angewendet werden. Ein einzelner Knoten oder eine Gruppe von Knoten, die eine Gemeinschaft bilden, werden im Folgenden als eine Entität bezeichnet, die eine/einen oder mehrere Anwendungen/Dienste ausführt. Folglich bezieht sich die vorliegende Erfindung außerdem auf die Situation einer beitretenden Entität, die eine gemeinsame Zeit für eine weitere Entität bereitstellen oder von einer weiteren Entität erfassen muss, die die gleiche Anwendung/den gleichen Dienst ausführt.
Vorzugsweise sendet ein Knoten, der eine Anwendung und/oder einen Dienst ausführt, eine Zeitangabenachricht, die die laufende Anwendung und/oder den laufenden Dienst und die Priorität der jeweils zugewiesenen Uhr angibt, an andere Knoten. Die Zeitangabenachrichten können vorzugsweise periodisch gesendet werden, um die laufenden Anwendungen/Dienste, ihre Uhren und die jeweiligen Prioritäten ständig bekanntzugeben. Ein Knoten, der eine Zeitangabenachricht empfangt, kann anhand der empfangenen Informationen beurteilen, ob eine Uhrensynchronisation notwendig ist.
Es ist bevorzugt, dass die Zeitangabenachricht durch Rundsenden an alle Knoten in der Umgebung des sendenden Knotens gesendet wird. Dies kann ausgeführt werden, indem die Weiterleitung der Zeitangabenachrichten verhindert wird, so dass sie nur innerhalb einer einzigen Sprungdistanz gesendet werden.
Bei Empfang einer Zeitangabenachricht kann ein Knoten bestimmen, ob er eine Anwendung und/oder einen Dienst ausführt, die bzw. der der Anwendung und/oder dem Dienst entspricht, die bzw. der in der empfangenen Zeitangabenachricht angegeben ist. In diesem Fall kann es einen Bedarf an der Synchronisation der jeweiligen Uhren geben, die der Anwendung und/oder dem Dienst zugewiesen sind. Dann kann der Knoten die mit der Zeitangabenachricht empfangene Priorität mit der Priorität der jeweiligen Uhr, die der entsprechenden Anwendung und/oder dem entsprechenden Dienst zugewiesen ist, die bzw. der in dem Knoten läuft, vergleichen. Dies erlaubt, die Referenzuhr und die abhängige Uhr aus den jeweiligen Uhren des empfangenden Knotens und den jeweiligen Uhren des Knotens, von dem die Zeitangabenachricht ausging, zu bestimmen. Folglich kann ein Knoten, der eine Zeitangabenachricht empfangt, bestimmen, ob die Uhrensynchronisation notwendig ist und ob er die gemeinsame Zeit dem Knoten, von dem die Zeitangabenachricht ausging, bereitstellen oder die gemeinsame Zeit von dem Knoten, von dem die Zeitangabenachricht ausging, empfangenen muss. Dies erlaubt eine automatische Uhrensynchronisation für die beitretende Entität oder die vorhandene Entität anhand der zugewiesenen Prioritäten. Eine Anwendung oder ein Dienst, der bzw. die gestartet worden ist, als der Knoten einzeln war, kann automatisch mit den Uhren der anderen Knoten synchronisiert werden, wenn eine Kommunikation zwischen den Knoten aufgebaut wird.
Bei Empfang einer Zeitangabenachricht kann ein Knoten bestimmen, ob er interessiert ist, eine entsprechende Anwendung und/oder einen entsprechenden Dienst in dem Knoten zu starten. Dies erlaubt den automatischen Start einer Anwendung oder eines Dienstes, die bzw. der eine Kommunikationsverbindung zu anderen Knoten in dem Netz erfordert, die die gleiche Anwendung oder den gleichen Dienst ausführen. Wenn eine entsprechende Zeitangabenachricht empfangen wird (d. h. die Netzverbindung aufgebaut ist), wird die jeweilige Anwendung und/oder der jeweilige Dienst im neu angeschlossenen Knoten gestartet. Dies sorgt für eine automatische Hochfahrprozedur für synchronisierte Peer-zu-Peer-Anwendungen/-Dienste. Vorzugsweise werden die jeweilige Anwendung und/oder der jeweilige Dienst nach der Initialisierung oder der Synchronisation der entsprechenden Uhren gestartet. In einigen Fällen kann es jedoch bevorzugt sein, die Anwendung oder den Dienst vor der Synchronisation oder Initialisierung der entsprechenden Uhren zu starten.
Ein Knoten, der eine Zeitangabenachricht empfängt und seine eigene entsprechende Uhr als eine abhängige Uhr bestimmt, kann seine abhängige Uhr entsprechend den Zeitinformationen der Referenzuhr stellen, die z. B. zusammen mit der Zeitangabenachricht empfangen werden. Außerdem ist es bevorzugt, eine geschätzte Ausbreitungsverzögerung für die Nachrichten zwischen dem ersten und dem zweiten Knoten zu betrachten, um die Genauigkeit der Uhrensynchronisation zu verbessern. Dies erlaubt es, eine schnelle und genaue Uhrensynchronisation für die beitretende Entität zu erreichen, die die Zeit von der vorhandenen Entität erfasst.
Sobald ein Knoten seine Uhr mit einer Referenzuhr eines weiteren Knoten synchronisiert hat, kann er außerdem das Senden von Zeitangabenachrichten beginnen, die die gemeinsame Anwendung/den gemeinsamen Dienst und die jeweilige Priorität angeben. Vorzugsweise werden die Zeitangabenachrichten außerdem periodisch gesendet.
Ein Knoten, der eine Zeitangabenachricht empfängt und seine eigene entsprechende Uhr als eine Referenzuhr bestimmt, kann eine Zeitreferenznachricht an den Knoten senden, von dem die empfangene Zeitangabenachricht ausging. Die Zeitreferenznachricht umfasst vorzugsweise die Zeit der Referenzuhr, so dass der Ursprungsknoten seine entsprechende Uhr entsprechend den Zeitinformationen der Referenzuhr stellen kann. Es ist außerdem bevorzugt, die Zeitrefe renznachricht für das Schätzen der Nachrichtenausbreitungsverzögerung zwischen dem ersten und dem zweiten Knoten zu verwenden, um die Genauigkeit der Uhrensynchronisation zu verbessern.
Ein Knoten, der eine Zeitreferenznachricht empfängt und auf eine vorher gesendete Zeitangabenachricht antwortet, kann auf den Nachrichtenursprungsknoten antworten, um die Nachrichtenausbreitungsverzögerung zu schätzen, oder seine entsprechende Uhr entsprechend den mit der Zeitreferenznachricht empfangenen Zeitinformationen stellen. Falls ein Knoten mit der Zeitreferenznachricht antwortet, hat er bestimmt, dass seine entsprechende Uhr die Referenzuhr für die gemeinsame Anwendung/den gemeinsamen Dienst sein soll, wobei folglich die entsprechende Uhr des anderen Knotens die abhängige Uhr des Uhrenpaars sein muss. In diesem Fall stellt die beitretende Entität die gemeinsame Zeit der vorhandenen Entität bereit, die ihre Uhr demgemäß synchronisiert.
Die vorliegende Erfindung schafft effiziente Maßnahmen zum Synchronisieren von zwei Entitäten. Eine vorhandene Entität, die eine laufende Anwendung/einen laufenden Dienst besitzt und die Rundsendung entsprechender Bekanntmachungen (Zeitangabenachrichten, die außerdem als Zeitbaken bezeichnet werden) ausführt, kann eine gemeinsame Zeit einer beitretenden Entität bereitstellen oder von einer beitretenden Entität erfassen, die die Bekanntmachungen empfängt und entscheidet, die Uhren beider Entitäten zu synchronisieren, weil eine gemeinsame Anwendung/ein gemeinsamer Dienst in beiden Entitäten läuft. Es wird anhand der zugewiesenen Prioritäten entschieden, welche Entität die gemeinsame Zeit bereitstellt und welche Entität die gemeinsame Zeit von der anderen Entität erfasst. Weil diese Entscheidung hauptsächlich auf den zugewiesenen Prio ritäten basiert, ist der Synchronisationsbetrieb sehr flexibel und erlaubt, viele Bedingungen zu berücksichtigen. Es ist z. B. möglich, einer Entität, die am Management einer Notfallsituation beteiligt ist, eine hohe Priorität zuzuweisen. Wenn eine weitere Entität, die eine niedrigere Priorität besitzt, beitritt, muss sie die gemeinsame Zeit von der vorhandenen Entität erfassen, obwohl sie eine genauere Uhr besitzen kann und unter normalen Umständen die gemeinsame Zeit der vorhandenen Entität, die eine weniger genaue Uhr besitzt, bereitstellen würde.
Gemäß einer bevorzugten Ausführungsform wird eine Ausbreitungsverzögerung für Nachrichten, die in dem Kommunikationsnetz zwischen dem ersten Knoten und dem zweiten Knoten gesendet werden, bestimmt, wobei die Zeit der abhängigen Uhr anhand der Zeit der Referenzuhr und der bestimmten Ausbreitungsverzögerung gestellt wird. Dies erlaubt eine genaue Uhrensynchronisation in Anbetracht der Netzausbreitungsverzögerungen.
Die Ausbreitungsverzögerung kann anhand einer geschätzten Umlaufzeit für die zwischen dem ersten und einem zweiten Knoten ausgetauschten Nachrichten bestimmt werden. Als eine Nachrichtumlaufzeit wird die Zeitdauer zwischen dem Senden einer Nachricht von einem Knoten zu einem weiteren und dem Empfangen der jeweiligen Antwort betrachtet. Folglich enthält die Umlaufzeit die Netzausbreitungsverzögerung für die Nachricht, die Netzausbreitungsverzögerung für die Antwort und die Verarbeitungsverzögerung des antwortenden Knotens. Die für das Schätzen der Umlaufzeit verwendeten Nachrichten können separate Nachrichten sein, die zwischen dem ersten und dem zweiten Knoten ausgetauscht werden. Es ist jedoch bevorzugter, außerdem die Zeitangabenachricht und die Zeitrefe renznachricht für die Schätzung der Umlaufzeit zu verwenden. Dies spart unnötige Netzlast.
Um genauere Schätzungen zu erlangen, kann die Schätzung der Umlaufzeit anhand mehrerer ausgetauschter Nachrichten wiederholt werden. Vorzugsweise geht die Schätzung weiter, bis ein vorgegebenes Stabilitätskriterium erfüllt ist. Das Stabilitätskriterium kann auf den Varianzen oder den Standardabweichungen der geschätzten Werte basieren.
Die vorliegende Erfindung schafft ein Protokoll für die effiziente und preiswerte Uhrensynchronisation zwischen Entitäten (einzelnen Knoten oder Gruppen von Netzknoten) in einem Kommunikationsnetz. Die Uhrensynchronisation, wenn zwei Entitäten verbunden werden, kann zwei Phasen umfassen. In einer ersten Phase wird eine schnelle Zeitauswahl anhand der den Uhren zugewiesenen Prioritäten ausgeführt. In jedem Knoten sind eine Systemuhr und bei Bedarf zusätzliche virtuelle Uhren vorgesehen, die den in dem Knoten laufenden Anwendungen/Diensten zugewiesen sind. In einer zweiten Phase wird die schnelle Uhrensynchronisation zwischen den Entitäten anhand der Zeit der ausgewählten Referenzuhr ausgeführt. Dies kann die Berücksichtigung einer geschätzten Nachrichtenausbreitungsverzögerung enthalten, um die Genauigkeit der Uhrensynchronisation zu vergrößern.
Ein Netzknoten in einem Kommunikationsnetz kann zum Synchronisieren der Uhren der Netzknoten Zeitauswahlmittel und Uhrenmanagementmittel umfassen. Die Zeitauswahlmittel können ausgelegt sein, um eine Priorität, die einer Uhr eines ersten Knotens zugewiesen ist, mit einer Priorität, die einer Uhr eines zweiten Knotens zuge wiesen ist, zu vergleichen. Die Zeitauswahlmittel bestimmen anhand des Ergebnisses des Vergleichs eine Referenzuhr mit einer höheren Priorität und eine abhängige Uhr mit einer niedrigeren Priorität unter die Uhren des ersten und des zweiten Knotens. Die Uhrenmanagementmittel können ausgelegt sein, um die Zeit der abhängigen Uhr auf die Zeit, die durch die Referenzuhr angegeben wird, zu stellen. Dies erlaubt dem Netzknoten, eine gemeinsame Zeit für einen weiteren Netzknoten bereitzustellen oder von einem weiteren Netzknoten zu erfassen, wobei die Auswahl der Referenzuhr auf einem flexiblen Prioritätsbewertungsschema basiert. Die zugewiesenen Prioritäten können fest oder dynamisch sein und basierend auf irgendeinem nützlichen Kriterium den Änderungen während des Knotenbetriebs unterworfen sein.
Vorzugsweise umfasst ein Knoten eine Uhrentabelle zum Speichern von Beziehungen zwischen Anwendungen oder Diensten, zugewiesenen Uhren und Prioritäten der Uhren. Die Zeitauswahlmittel können ausgelegt sein, um zu bestimmen, ob entsprechende Anwendungen und/oder Dienste in dem ersten und dem zweiten Knoten ausgeführt werden. Die Anwendungen und/oder die Dienste können einander entsprechen, falls sie völlig gleich sind, völlig gleiche/entsprechende Aufgaben ausführen, und/oder in irgendeiner Weise in Beziehung stehen, so dass sie eine synchronisierte Uhr/Zeitmessung benötigen. Im positiven Fall wählen die Zeitauswahlmittel die entsprechenden Uhren des ersten und des zweiten Knotens aus der jeweiligen Uhrentabelle der Knoten für die Synchronisation aus. Dies besitzt den Vorteil einer anwendungs-/dienstgesteuerten Uhrensynchronisation, bei der die jeweiligen Uhren einer gemeinsamen Anwendung/eines gemeinsamen Dienstes automatisch synchronisiert werden, wenn eine Kommunikation zwischen den Knoten aufgebaut wird.
Die Uhrenmanagementmittel können ausgelegt sein, um Zeitinformationen für die Anwendungen/Dienste, die in dem Knoten ausgeführt werden, anhand der entsprechenden Uhr, die in der Uhrentabelle aufgelistet ist, bereitzustellen. Dies besitzt den Vorteil des Schaffens einer allgemeinen Schnittstelle für die Anwendungen/Dienste, die ihre jeweiligen Zeitinformationen empfangen, ohne sich um die Uhrensynchronisation kümmern zu müssen. Falls eine Synchronisation der Uhren notwendig wird, wird dies durch die Zeitauswahlmittel ohne irgendeine Notwendigkeit für die Beteiligung der jeweiligen Anwendung/des jeweiligen Dienstes ausgeführt. Dies besitzt den Vorteil der Vereinfachung der Anwendungs-/Dienstkonstruktion.
Gemäß einer bevorzugten Ausführungsform kann ein Knoten eine Systemuhr umfassen, wobei die Uhrenmanagementmittel ferner ausgelegt sein können, um zusätzliche virtuelle Uhren zu managen. Falls eine neue Anwendung oder ein neuer Dienst in dem Knoten begonnen wird, können die Uhrenmanagementmittel bestimmen, ob eine virtuelle Uhr, die eine Zeit angibt, die von der Systemuhr verschieden ist, für die neue Anwendung oder den neuen Dienst notwendig ist. Im positiven Fall initialisieren die Uhrenmanagementmittel eine neue virtuelle Uhr und weisen eine Priorität zu. Vorzugsweise steht die Priorität mit einer Eigenschaft der Uhr, einer Eigenschaft der Anwendung und/oder einer Eigenschaft des Knotens in Beziehung. Dies erlaubt eine sehr flexible Auswahl der Referenzuhr, die an viele verschiedene Situationen angepasst werden kann.
Ein Netzknoten kann ferner Sendemittel umfassen, die ausgelegt sind, um Zeitangabenachrichten, die eine Anwendung oder einen Dienst, die bzw. der in einem Knoten abläuft, und die Priorität der jeweils zugewiesenen Uhr angeben, zu senden. Eine Zeitangabenachricht wird vorzugsweise gesendet, nachdem eine Anwendung oder ein Dienst den Betrieb im Knoten begonnen hat. Sie kann verwendet werden, um diese ausgeführte Anwendung/diesen ausgeführten Dienst anderen Knoten und die Möglichkeit oder die Notwendigkeit für die Uhrensynchronisation anzugeben. Falls mehrere Anwendungen/Dienste in einem Knoten ausgeführt werden, kann eine einzige Zeitangabenachricht Informationen bezüglich der mehreren Anwendungen/Dienste umfassen.
Ein Knoten kann ferner Empfangsmittel umfassen, die ausgelegt sind, um Zeitangabenachrichten von dem Kommunikationsnetz zu empfangen. Es ist bevorzugt, dass die Zeitauswahlmittel konfiguriert sind, um zu bestimmen, ob der Knoten eine Anwendung und/oder einen Dienst ausführt, die bzw. der einer Anwendung und/oder einem Dienst entspricht, die bzw. der in einer empfangenen Zeitangabenachricht angegeben ist. Im positiven Fall sind die Zeitauswahlmittel ferner konfiguriert, um eine in der Zeitangabenachricht empfangene Priorität mit einer Priorität der jeweiligen Uhr, die der entsprechenden Anwendung und/oder dem entsprechenden Dienst, die bzw. der in dem Knoten ausgeführt wird, zugeordnet ist, zu vergleichen. Anhand des Ergebnisses dieses Vergleichs können die Zeitauswahlmittel die Referenzuhr und die abhängige Uhr bestimmen. Dies erlaubt eine automatische Identifikation der betroffenen Uhr und ihre Synchronisation.
Die Uhrenmanagementmittel können ferner ausgelegt sein, um eine Uhr, die durch die Zeitauswahlmittel als eine abhängige Uhr bestimmt wird, in Übereinstimmung mit den mit der Zeitangabenach richt empfangenen Zeitinformationen zu stellen. Dies erlaubt eine automatische Erfassung der durch die Referenzuhr angegebenen Zeit. Um die Genauigkeit der Uhrensynchronisation zu vergrößern, kann eine Nachrichtenumlaufzeit oder eine Nachrichtenausbreitungsverzögerung berücksichtigt werden.
Wenn ein Knoten eine Zeitangabenachricht empfängt und seine eigene entsprechende Uhr als eine Referenzuhr bestimmt, ist es bevorzugt, dass die Sendemittel ausgelegt sind, um eine Zeitreferenznachricht an den Ursprungsknoten der empfangenen Zeitangabenachricht zu senden. Dies erlaubt dem Ursprungsknoten, der die abhängige Uhr für die betroffene Anwendung/den betroffenen Dienst umfasst, die für die Synchronisation notwendigen Zeitinformationen zu erfassen. Das Stellen der abhängigen Uhr im Ursprungsknoten kann optional auf einer geschätzten Nachrichtumlaufzeit oder einer Nachrichtenausbreitungsverzögerung basieren.
Die Empfangsmittel können ferner ausgelegt sein, um von anderen Knoten Zeitreferenznachrichten zu empfangen, die die Zeit der Referenzuhr umfassen. Es ist bevorzugt, dass bei Empfang einer Zeitreferenznachricht die Uhrenmanagementmittel ausgelegt sind, um die entsprechende abhängige Uhr, die in der Uhrentabelle aufgelistet ist, entsprechend den mit der Zeitreferenznachricht empfangenen Zeitinformationen zu stellen. Dies besitzt den Vorteil des Schaffens einer automatischen Zeiterfassung für eine Synchronisation einer vorhandenen Entität.
Um die Genauigkeit der Zeitsynchronisation zu verbessern, können die Zeitauswahlmittel ausgelegt sein, um eine Ausbreitungsverzögerung und/oder eine Umlaufzeit für Nachrichten, die im Kommunika tionsnetz zwischen dem ersten und dem zweiten Knoten übertragen werden, zu schätzen. Vorzugsweise sind die Uhrenmanagementmittel ausgelegt, um die in der Uhrentabelle aufgelistete abhängige Uhr anhand der Zeit der Referenzuhr und der bestimmten Nachrichtenausbreitungsverzögerung und/oder der bestimmten Umlaufzeit zu stellen.
Gemäß einer bevorzugten Ausführungsform sind die Sendemittel ausgelegt, um Nachrichten zu einem Ad-hoc-Netz zu senden. Die Empfangsmittel sind vorzugsweise ausgelegt, um Nachrichten von einem Ad-hoc-Netz zu empfangen. Das Ad-hoc-Netz kann ein mobiles Ad-hoc-Netz sein, das mehrere Endgeräte umfasst, die drahtlos unter Verwendung der Funkübertragung miteinander verbunden sind. Jeder Knoten kann als ein Client, ein Relaisknoten und/oder ein Server wirken und kann jederzeit dem Netz beitreten und das Netz verlassen.
Die vorliegende Erfindung schafft einen Netzknoten, der für eine schnelle und effiziente Synchronisation der Uhren der Netzvorrichtungen ausgelegt ist. Die Synchronisation wird vorzugsweise durch eine Anwendung und/oder einen Dienst, die bzw. der den Netzknoten gemeinsam ist, gesteuert. Der Netzknoten kann eine Systemuhr und zusätzliche virtuelle Uhren umfassen, die bei Bedarf erzeugt und aufrechterhalten werden. Die vorliegende Erfindung ist vorzugsweise in einem Synchronisationsprotokoll, in Software- und/oder Hardware-Komponenten, die in einem Netzknoten arbeiten, z. B. als Teil des Netzknoten-Betriebssystems, implementiert. Dies besitzt den Vorteil, dass für die Anwendungen und die Dienste separate Zeitmessungen bereitgestellt werden können, die automatisch synchronisiert werden, wenn es möglich/notwendig ist.
Gemäß dem Uhrensynchronisationsmechanismus der vorliegenden Erfindung kann (können) die synchronisierte(n) Netzzeit(en) auf Anwendungen und/oder Diensten des beitretenden AHN oder des vorhandenen AHN basieren. Die Zeitauswahl basiert zuallererst auf den spezifischen Prioritäten, die den Uhren zugewiesen sind. Es ist keine Zeit-Mittelwertbildung notwendig, sondern es ist eine auf höherer Ebene gesteuerte Zeitauswahl vorgesehen. Die Uhrensynchronisation wird durch Zeitangabenachrichten (Zeitbaken), die durch irgendeinen Knoten in einem AHN gesendet werden, der eine jeweilige Anwendung oder einen jeweiligen Dienst ausführt, begonnen. Es gibt keine Notwendigkeit, einen dedizierten Zeitserver im Voraus zu spezifizieren. Folglich überwindet der Uhrensynchronisationsmechanismus der Erfindung die Probleme, die bekannten Zeitsynchronisationsprotokollen zugeordnet sind, die die Spezifikation eines dedizierten Zeitservers und/oder einer Client-Server-Struktur erfordern. Sobald das beitretende AHN seine Anwendungszeit synchronisiert hat, beginnt es außerdem das Senden von Zeitangabenachrichten, d. h. es wird dynamisch ein Zeitserver für diese Anwendung/diesen Dienst. Dies schafft eine mehrfachsprungartige Ausbreitung für die Zeitangabenachrichten. Die zum Synchronisieren der Anwendungszeiten notwendige Dauer ist schnell und preiswert. Die Prozedur ist für Ad-hoc-Netze optimiert und berücksichtigt die Knotenmobilität.
Diese und weitere potentielle Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung erscheinen aus der folgenden ausführlichen Beschreibung der bevorzugten Ausführungsformen der Erfindung ausführlicher. Es ist jedoch selbstverständlich, dass der Umfang der vorliegenden Erfindung nicht auf die gegebenen Ausführungsformen eingeschränkt ist, die in der beigefügten Zeichnung gezeigt sind, worin:
1 die allgemeine Struktur eines drahtlosen Ad-hoc-Netzes schematisch zeigt, das Multisprung-Peer-zu-Peer-Kommunikationen und Gemeinschaften umfasst;
2 eine Situation von zwei beitretenden AHNs schematisch veranschaulicht, wo eine relative Zeitmessung (lokale Zeitmessung) im vorhandenen AHN wichtiger als eine im beitretenden AHN bereitgestellte absolute Zeit ist;
3 eine Situation von zwei beitretenden AHNs mit nur einer (System-)Uhr pro AHN-Endgerät schematisch veranschaulicht;
4 die Modulstruktur eines Ad-hoc-Endgerätes gemäß einer Ausführungsform der Erfindung schematisch veranschaulicht;
5 eine Uhrentabelle schematisch zeigt;
6 die Hardware-Struktur eines Ad-hoc-Knotens gemäß einer Ausführungsform der Erfindung schematisch veranschaulicht;
7 eine graphische Darstellung zeigt, die die Uhrensynchronisationsmechanismen gemäß einer Ausführungsform der vorliegenden Erfindung schematisch veranschaulicht;
8 einen Ablaufplan zeigt, der einen Prozess veranschaulicht, der durch einen isolierten Knoten, der eine Anwendung oder einen Dienst startet, ausgeführt wird oder in einem Knoten, der am Starten einer Anwendung oder eines Dienstes, die bzw. der in einer empfangenen Zeitangabenachricht aufgelistet ist, interessiert ist, ausgeführt wird;
9 das Format der THELLO-Pakete zeigt, die als Zeitangabenachrichten verwendet werden;
10 einen Ablaufplan einer periodischen THELLO-Rundsendeprozedur zeigt;
11 einen Ablaufplan für einen Zeitsynchronisationsprozess zeigt;
12 ein Beispiel für den Fluss der Nachrichten veranschaulicht, der verwendet wird, um die Umlaufzeit oder die Ausbreitungsverzögerung zu schätzen;
13 das Format für die TREQ-Pakete zeigt;
14 das Format für die TACK-Pakete zeigt;
15 einen Ablaufplan zeigt, der eine Verzögerungsschätzprozedur veranschaulicht; und
16 einen Ablaufplan zeigt, der eine weitere Verzögerungsschätzprozedur veranschaulicht.
1 zeigt schematisch die allgemeine Struktur eines drahtlosen Ad-hoc-Netzes, das Multisprung-Peer-zu-Peer-Kommunikationen (Multisprung-P2P-Kommunikationen) und anwendungs-/dienstgesteuerte Gemeinschaften umfasst. Die Netzknoten (die Kreise) sind in den Gemeinschaften 20, 21 angeordnet, die eine gemeinsame Anwendung oder einen gemeinsamen Dienst gemeinsam nutzen und eine Zeitmessung mit synchronisierten Uhren benötigen. Die Knoten im Netz nach 1 können in P2P-Quell- oder -Zielknoten (gefüllte schwarze Kreise), Relaisknoten (graue Kreise: dies sind Knoten, die keine Quellen oder Ziele und/oder keine Mitglieder einer Gemeinschaft sind, die aber die P2P-Kommunikationen zwischen den anderen Knoten weiterleiten) und passive Knoten (weiße Kreise: dies sind Knoten, die Mitglieder einer Gemeinschaft sind oder nicht, die aber an keiner direkten oder weitergeleiteten Kommunikation beteiligt sind) klassifiziert werden.
Die kleinen Doppelpfeile zwischen den Knoten geben Einsprung-Kommunikationsverbindungen an. Diese drahtlosen Verbindungen können unter Verwendung von Funkübertragungsmodulen (insbesondere drahtlosen 802.11-a/b/g-Netzkarten) implementiert sein, die in einer Ad-hoc-Betriebsart (d. h. keine Trägereinrichtungen) verwendet werden. Den Knoten ist ein spezieller Netzname für die Zugangssteuerung zugewiesen. Um eine Verbindung der Knoten miteinander zu erlauben, müssen die Netznamen völlig gleich sein. Die Knoten, die zu einer Gemeinschaft gehören, müssen einen Gemeinschaftsnamen gemeinsam nutzen, der mit dem Netznamen übereinstimmen kann (wie im Fall der Gemeinschaft 21) oder nicht übereinstimmen kann (wie im Fall der Gemeinschaft 20).
Für die Mehrfachsprung-Paketzustellung (die durch dicke Pfeile in 1 veranschaulicht ist) werden spezielle IP-Weiterleitungsprotokolle verwendet. Diese Weiterleitungsprotokolle können eine Punkt-Punkt-Kommunikation (Eins-zu-Eins), z. B. OLSR, und/oder eine Punkt-Mehrpunkt-Kommunikation (Einer-zu-Vielen), z. B. MAODV, sein. Ein Weiterleitungsprotokoll erlaubt, das die von der Quelle gesendeten Datenpakete ein Ziel erreichen, das keine direkte Funkverbindung mit der Quelle besitzt. Die IP-Netzunterhaltung kann durch den Austausch von Paketen mit Weginformationen ausgeführt werden. In derartigen Netzen ist die dynamische Weiterleitungseinstellung infolge der potentiellen Endgerätemobilität nützlich.
Zwischen allen oder einem Teil der Mitglieder eines AHN werden Peer-zu-Peer-Kommunikationen (P2P-Kommunikationen) aufgebaut. Das Management einer P2P-Kommunikation kann durch eine Anwendung und/oder einen Dienst (ApplServ) ausgeführt werden. Die Endgeräte, die zu einem AHN gehören, können als ein Relaisknoten für die Kommunikation zu weiteren AHN-Mitgliedern wirken. Eine Teilmenge der AHN-Endgeräte kann eine Gemeinschaft innerhalb des AHN in Bezug auf eine spezielle Anwendung oder einen speziellen Dienst bilden. Drei Mitglieder (vgl. Bezugszeichen 22) des Ad-hoc-Netzes (in 1) sind keine Mitglieder der vorhandenen Gemeinschaften 20, 21. Diese Netzknoten sind jedoch potentielle Relais für die Kommunikation zwischen den Gemeinschaftsmitgliedern (siehe den grauen Knoten 23).
Dieses Beispiel veranschaulicht eine Situation mit einer beitretenden Entität (die Gemeinschaft 21, die hier dem beitretenden AHN selbst entspricht), die eine/einen oder mehrere Anwendungen/Dienste ausführt und die die Zeit(en) einer weiteren vorhandenen Entität (der Gemeinschaft 20, die hier Teil des vorhandenen AHN ist), die die gleichen Anwendungen/Dienste ausführt, bereitstellen muss oder von dieser Entität erfassen muss. Der Ausdruck Entität wird verwendet, um einen einzelnen Netzknoten für eine Gruppe von Netzknoten, die eine Gemeinschaft bilden, zu bezeichnen.
Wenn sich zwei AHNs oder Gemeinschaften einander nähern, erlaubt ihnen ein Austausch von Systemkommunikationen, zu bestimmen, ob sie miteinander verbunden werden oder nicht. Insbesondere sind die Netznamen, die Betriebsfrequenzen und schließlich die Weiterleitungs- und Adressierungsprotokolle der Gegenstand der Vereinbarungen während dieser Initialisierungsphase.
In bekannten Netzprotokollen fehlt es an Kommunikation und Vereinbarung in Bezug darauf, welche Art von Gruppenmanagement, Anwendungen oder Diensten tatsächlich in den beitretenden AHNs ausgeführt wird. Außerdem sind die Zeitmessungen der laufenden Prozesse nicht koordiniert, so dass aus der Asynchronität der ausgetauschten Pakete eine Anzahl von potentiellen Problemen auftreten kann. Folglich gibt es einen Bedarf an einer Zeitsynchronisation (Uhrensynchronisation) der beitretenden AHNs, die eine/einen oder mehrere gemeinsame Anwendungen/Dienste ausführen.
Wenn sich nämlich eine zweite Gruppe von Netzknoten, die eine weitere Gemeinschaft 21 bilden, der vorhandenen Gemeinschaft 20 nähert und beide Gemeinschaften 20, 21 eine gemeinsame Anwendung/einen gemeinsamen Dienst gemeinsam nutzen, gibt es einen Bedarf an einem Mechanismus, um die Zeitmessungen zwischen der gemeinsamen Anwendung/dem gemeinsamen Dienst zu synchronisieren, die bzw. der in den zwei Gemeinschaften 20, 21 ausgeführt wird. Nach der Synchronisation können die Gemeinschaften 20, 21 verschmelzen, um eine große gemeinsame Gemeinschaft zu bilden.
2 veranschaulicht schematisch eine Situation von zwei beitretenden AHNs, wo eine relative Zeitmessung (lokale Zeitmessung) im vorhandenen AHN 24 wichtiger als eine im beitretenden AHN 25 bereitgestellte absolute Zeit ist. In diesem Beispiel stellt das beitretende AHN 25 eine genaue GPS-Zeitmessung bereit und nähert sich dem vorhandenen AHN 24, das eine lokale virtuelle relative Uhr für eine Anwendung für die Verwendung in einer Notfallsituation (wie z. B. bei einem Unfall mit einem Fahrzeug, einem großen Feuer, einem Flugzeugabsturz usw.) bereitstellt. In diesem Fall sollte das beitretende AHN 25 für Notfallzwecke die lokale Zeitmessung des vorhandenen AHN 24 erfassen und nicht umgekehrt. Folglich wird die relative Zeitmessung für die Notfallanwendung des beitretenden AHN für die Synchronisation zugewiesen. Selbstverständlich würde das Gleiche gelten, falls sich die lokale Uhr im vorhandenen AHN 24 ebenfalls auf eine genaue GPS-Zeitmessung bezieht.
Gemäß der Erfindung kann die Synchronisation der obigen Situation ausgeführt werden, indem jeweilige Prioritäten den Uhren der Gemeinschaften 24, 25 zugewiesen werden. Die Systemuhr des beitretenden AHN 25 wird auf die GPS-Zeit gestellt und durch die Hintergrunds-Notfallanwendung mit z. B. einem Prioritätswert von 3 verwendet. Die lokale virtuelle relative Uhr des vorhandenen Notfall-AHN 24 wird mit z. B. einem Prioritätsniveau von 1 gestellt. Entsprechend der prioritätsgestützten Zeitauswahl der Erfindung wird die lokale relative Uhr des vorhandenen AHN 24 als eine Referenzuhr ausgewählt, während eine virtuelle Uhr für die Hintergrund-Notfallanwendung begonnen wird.
3 veranschaulicht schematisch eine Situation von zwei beitretenden AHNs mit nur einer (System-)Uhr pro AHN und mit der gleichen Uhrenpriorität. In der vorhandenen Gemeinschaft 26 wird durch die gemeinsame Anwendung nur eine lokale Uhr verwendet. Es wird angenommen, dass nur eine Anwendung, die eine auf die absolute GPS-Zeit gestellte lokale Uhr verwendet, im beitretenden AHN 27 ausgeführt wird. Falls zwei Entitäten 26, 27, die die gleiche ApplServ ausführen, verbunden werden, ist die absolute Zeit T1 des AHN 27 wichtiger als die lokale Zeit T2 der Gemeinschaft 26. Folglich sollte die Entität 26 mit T2 die Zeit T1 erfassen und nicht umgekehrt. Dies bedeutet, dass die GPS-Zeitmessung außerdem der Anwendung der vorhandenen Gemeinschaft 26 für die Synchronisation zugewiesen wird. Falls die Zeit T2 von der Systemuhr genommen wird, muss schließlich eine virtuelle Uhr in der Entität 26 begonnen werden.
Gemäß der Erfindung kann die Synchronisation für die obige Situation ausgeführt werden, indem der GPS-Zeit des beitretenden AHN 27 eine größere Wichtigkeit gegeben wird (auf Grund des absoluten Wertes). Dies erlaubt die Auswahl der genaueren Zeit des beitretenden AHN 27.
4 veranschaulicht schematisch die Modulstruktur eines Ad-hoc-Endgerätes 10 gemäß einer Ausführungsform der Erfindung. Der Knoten umfasst ein Zeitauswahlmodul 1 für eine schnelle Entscheidung, welche Zeitmessung bei der Synchronisation (und mit welcher Priorität) ausgewählt wird. Ein Uhrenmanagementmodul 2 erhält eine (physikalische) Systemuhr und eine Menge von ApplServ-gesteuerten virtuellen Uhren aufrecht. Das Uhrenmanagementmodul 2 initialisiert, aktualisiert und beendet die virtuellen Uhren auf Anforderung der im Knoten 10 laufenden Anwendungen/Dienste.
Eine Uhrentabelle 3 speichert die aktiven Uhren des Knotens, die Identitäten (Namen) der entsprechenden Anwendungen/Dienste und die zugeordneten Prioritäten (siehe 5). Die ApplServS (und/oder irgendwelche Sitzungs-/Gruppenmanagementwerkzeuge) treten mit dem Uhrenmanagementmodul 2 direkt in Wechselwirkung, das die Einträge in der Uhrentabelle 3 steuert.
Das Uhrenmanagementmodul 2 bildet mit dem TCP/IP-Modul 4 für das Senden der Zeitangabenachrichten (Zeitbaken) eine Schnittstelle, um die laufenden ApplServS oder Gruppen/Sitzungen zu identifizieren. Das Zeitauswahlmodul 1 bildet mit dem MAC-Schicht-Modul 5 für das Management empfangener Zeitbaken von anderen Endgeräten eine Schnittstelle. Das Zeitauswahlmodul 1 empfangt die Informationen von der Uhrentabelle 3 hinsichtlich dessen, welche Anwendungen, Dienste und/oder Sitzungen mit welchen (virtuellen) Uhren und Prioritäten lokal ausgeführt werden. Das Zeitauswahlmodul 1 tauscht Nachrichten mit den entsprechenden Modulen der anderen Knoten für die Schätzung der Funkausbreitungsverzögerung zwischen den kommunizierenden Knoten aus. Das Uhrenmanagementmodul 2 empfangt die Schätzungen der Ausbreitungsverzögerungen vom Zeitauswahlmodul 1.
Ein Sitzungsschichtmodul 6 ist für die Erzeugung, die Unterhaltung und die Beendigung von Kommunikationssitzungen oder Gruppen in einer auf einer ApplServ basierenden Gemeinschaft vorgesehen, z. B. eine Online-Konferenz für nur 2 Knoten in einer Sprache-über-IP-Audiokonferenz (VoIP-Audiokonferenz) für 3 Knoten.
Das Modul 7 für die physikalische Schicht bildet mit dem Kommunikationsnetz 8, das vorzugsweise ein drahtloses Ad-hoc-Netz ist, eine Schnittstelle.
Es wird nicht angenommen, dass die Endgeräte eine Standard-Zeitsynchronisations-Hardware (wie GPS) besitzen, wobei aber einige Knoten damit ausgerüstet sein können. Folglich repräsentiert die Systemuhr nicht notwendigerweise eine absolute Zeit, wobei nicht angenommen wird, dass sie die wichtigste Zeit für den Knoten ist. Jede Anwendung oder jeder Dienst verwendet die Systemuhr oder eine virtuelle Uhr, die auf Anforderung von einer ApplServ durch das Uhrenmanagementmodul 2 begonnen worden ist. Eine virtuelle Uhr kann beendet werden, nachdem sie verwendet worden ist, wenn ihre entsprechende ApplServ nicht mehr ausgeführt wird.
5 zeigt schematisch eine Uhrentabelle 3, die für die Unterhaltung der Systemuhr und der virtuellen Uhren (VClocks) verwendet wird. Die Uhrennamen sind in der ersten Spalte aufgelistet. Die entsprechende Anwendung oder der entsprechende Dienst für jede Uhr und die zugewiesene Priorität sind in der zweiten bzw. der dritten Spalte aufgelistet. Eine Zeile in der Uhrentabelle 3 repräsentiert die für eine einzelne Uhr gespeicherten Informationen.
Die Hardware-Struktur eines Ad-hoc-Knotens 10 ist in 6 dargestellt. Ein Knoten 10 umfasst eine CPU 11, einen Speicher 12, dessen Management direkt durch die CPU 11 ausgeführt werden kann, eine Konsolen-Steuereinheit 13 zum Steuern einer optionalen Konsole 14 und eine Netz-Steuereinheit 15 für das Management der Netzverbindungen zu einem drahtlosen Ad-hoc-Netz 8. Optionale Hardware-Module sind eine Platten-Steuereinheit 16 und ein Festplattenlaufwerk 17.
7 zeigt eine graphische Darstellung, die den Uhrensynchronisationsmechanismus gemäß einer Ausführungsform der vorliegenden Erfindung schematisch veranschaulicht. In Bezug auf eine ApplServ sind ein Zeitinitiatorknoten B (TI_node), ein Unter-Zeitinitiatorknoten C (sTI_node = TI_node nach der Synchronisation) und nicht synchronisierte Knoten A, D, E (N_node) definiert.
Ein isolierter N_node A führt eine ApplServ aus, ist aber nicht mit anderen Knoten über Funk verbunden. Folglich gibt es keinen Bedarf an einer Zeitsynchronisation. Deshalb kann der Knoten weiterhin seine eigene lokale Zeitmessung verwenden, die eine relative Zeit sein kann (es sei denn, dass die ApplServ aus anderen Gründen einer absoluten Zeit entspricht). In diesem N_node A wird z. B. nur die Systemuhr benötigt und aufrechterhalten.
Der Knoten B hat in der Vergangenheit eine oder mehrere ApplServS begonnen, wobei folglich in diesem TI_node eine oder mehrere in Beziehung stehende Uhren (eine Systemuhr oder virtuelle Uhren) aufrechterhalten werden. Die Uhr im Knoten B muss sich nicht auf eine absolute Zeitmessung beziehen, d. h. der Knoten B benötigt kein GPS-Modul. Das Uhrenmanagement des Knotens B führt periodisch die Rundsendung von Zeitangabenachrichten (von THELLO-Paketen, siehe 9 für das Paketformat) aus, um die anderen Netzknoten über die laufende ApplServ und die jeweilige Uhrenpriorität zu informieren. Weil die Zeitangabenachrichten nicht durch andere Netzknoten weitergeleitet werden, erreichen sie nur die Netzknoten innerhalb einer Sprungdistanz um den Knoten B.
Der Knoten C führt wenigstens eine der gleichen ApplServS des Knotens B aus. Er wird der Unter-Zeitinitiatorknoten (sTI_node) der durch die Knoten B und C gebildeten Gemeinschaft. Die jeweiligen Uhren der gemeinsamen ApplServ, die in den Knoten B, C der Gemeinschaft ausgeführt wird, sind zeitsynchronisiert. Der sTI_node C führt außerdem periodisch die Rundsendung von 1-Sprung-Zeitangabenachrichten aus.
Die Zeitauswahlmodule verwerfen die empfangenen Zeitangabenachrichten, falls sie keine neuen interessierenden ApplServS enthalten oder falls sie eine gemeinsame ApplServS enthalten, es aber keinen Bedarf an einer (erneuten) Synchronisation gibt.
Der Knoten D empfangt die vom TI_node B gesendete Zeitangabenachricht, ist aber nicht an der Synchronisation einer seiner laufenden ApplServ mit der vorhandenen Gemeinschaft interessiert. Dies wird durch das Zeitauswahlmodul 1 des N_node D entschieden, das die empfangenen Zeitangabenachrichten analysiert. Weil ein THELLO-Paket (siehe 9) Informationen hinsichtlich der Uhrentabelle des TI_node B enthält, kann das Zeitauswahlmodul 1 des Knotens D bestimmen, ob eine entsprechende ApplServ, die die (erneute) Synchronisation erfordern würde, im Konten D ausgeführt wird oder gestartet werden sollte. Hier gibt es keinen Bedarf an einer Synchronisation des N_node D.
Wenn der N_node E die vom sTI_node C gesendete Zeitangabenachricht (gestrichelter Pfeil) empfängt, bestimmt er, dass er an der Synchronisation einer oder mehrerer seiner laufenden ApplServS oder am Starten einer oder mehrerer ApplServS, die mit der durch die Knoten C, B gebildeten vorhandenen Gemeinschaft nicht bereits gemeinsam sind, interessiert ist. Der schnelle Zeitsynchronisationsmechanismus gemäß der Erfindung umfasst die folgenden drei Schritte.
Zuerst führt das Zeitauswahlmodul 1 des N_node E den Zeitauswahlschritt aus. Das Zeitauswahlmodul 1 muss entscheiden, zu welcher der entfernt laufenden ApplServS es beabsichtigt, beizutreten, und welche (virtuellen) Uhren vom sTI_node C zu erfassen sind oder dem sTI_node C bereitstellen sind. Dies wird anhand der mit der Zeitangabenachricht (dem THELLO-Paket) empfangenen Informationen bezüglich der Uhrentabelle des sTI_node C ausgeführt. Die ApplServ im Knoten E kann obligatorisch im Hintergrund ausgeführt werden (wie z. B. die ApplServS für öffentliche Notfälle, z. B. für eine Notfall-Nachrichtenübermittlung zwischen Fahrzeugen auf einer Hauptverkehrsstraße) oder kann optional für nützliche oder Unterhaltungszwecke ausgeführt werden.
In der zweiten Phase der Zeitsynchronisation schätzen die Zeitauswahlmodule 1 des N_node E und des sTI_node C einen Durchschnitt der Umlaufzeit (RTT) oder der Ausbreitungsverzögerung (PD) zwischen den Knoten E und C. Dies wird ausgeführt, indem einige Zeitanforderungspakete (TREQ) und entsprechende Zeitquittierungspakete (TACK) ausgetauscht werden. Wenn eine ausreichende stabile RTT- oder PD-Schätzung verfügbar ist, leitet das Zeitauswahlmodul 1 diese Informationen bis zum Uhrenmanagementmodul 2. Dies wird z. B. entschieden, wenn die RTT-Varianz kleiner als ein vorgegebener Schwellenwert ist. Die Entscheidung, die Schleife der TREQs und TACKs anzuhalten, kann durch den Uhrzeit-Erfassungsknoten (d. h. den Knoten, der die abhängige Uhr besitzt), getroffen werden.
In der letzten Phase der Synchronisation aktualisiert schließlich das Uhrenmanagementmodul 2 der zwei Knoten E, C ihre lokalen (virtuellen) Uhren in der Uhrentabelle 3, um die entsprechende ApplServ in der beigetretenen Gemeinschaft zu synchronisieren. Der Uhrzeit- Erfassungsknoten stellt seine jeweilige abhängige Uhr. Nach der Synchronisation wird der N_node E außerdem ein sTI_node für die vergrößerte Gemeinschaft. Nun beginnt der sTI_node E außerdem das Senden von Zeitangabenachrichten für die gemeinsamen ApplServS. Die Periodizität der THELLO-Pakete kann (automatisch) im Bereich von 200 ms bis 2 s gewählt werden, der z. B. mit der Verbindungsstabilität oder der Endgerätemobilität oder dem Ausgleich der Netzlast in Beziehung steht.
Weil die Mobilität der Endgeräte Verbindungs- und Kommunikationsunterbrechungen verursachen kann, hält das Uhrenmanagementmodul 2 vorzugsweise die gleiche Uhrentabelle 3 während einer minimalen Periode aufrecht (dieser Zeitablauf kann mit den Umgebungseigenschaften wie der Verbindungsstabilität oder der Endgerätegeschwindigkeit in Beziehung stehen), bevor sie alle Einträge (bis auf den der Systemuhr) löscht.
Wenn im Netz 8 kein TI_node für eine ApplServ vorhanden ist, bedeutet dies einfach, dass die ApplServ nicht über dem AHN ausgeführt wird, wobei sich die Zeit auf den Knoten bezieht, der diese ApplServ zuerst beginnt. Wenn sich zwei AHNs, die die gleiche ApplServ ausführen, einander nähern, wird die Synchronisation hauptsächlich durch das Auswählen der Uhr mit der höheren Priorität ausgeführt. Wenn die zwei Prioritäten die gleichen sind, ist es bevorzugt, zu bestimmen, ob eine der zwei Uhren eine Systemuhr ist oder ob sie mit einer absoluten Zeitmessung in Beziehung steht. Wenn beide Uhren von der gleichen Art sind (relative Zeitmessung, System- oder virtuelle Uhren), ist ein weiteres Kriterium, um zu entscheiden, welche Synchronisationsrichtung zu nehmen ist, die Betrachtung der Anzahl der Mitgliedschaften im anderen AHN: d. h., die Minderheit der Knoten erfasst die Zeitmessung von der Mehrheit. Andernfalls kann keine Entscheidung getroffen werden, wobei die zwei AHNs weiterhin getrennt bleiben müssen, wenigstens soweit wie die ApplServ betroffen ist.
Deshalb schafft die vorliegende Erfindung ein Protokoll für die Synchronisation anwendungs-/dienstgesteuerter Uhren im AHN (was mehr Initialisierung als Unterhaltung betrifft). Dieses Protokoll kann im Namen "schnelle anwendungs-/dienstgesteuerte Zeitsynchronisation für Ad-hoc-Netze" (FASTANET) zusammengefasst werden.
8 zeigt einen Ablaufplan, der den Prozess veranschaulicht, der durch das Uhrenmanagementmodul 2 in einem isolierten N_node, der eine ApplServ beginnt, oder in einem Knoten, der am Ausführen einer ApplServ, die in einem empfangenen THELLO-Paket aufgelistet ist, interessiert ist, ausgeführt wird. Der Prozess beginnt im Schritt 100, in dem eine neue ApplServ startet. Im Schritt 110 werden die Prioritäten der bereits laufenden ApplServS überprüft, wobei infolgedessen eine neue Priorität für die neue ApplServ gesetzt wird.
Falls die Systemuhr aus irgendeinem Grund noch nicht verwendet wird, kann sie für diese neue ApplServ verwendet werden. Wenn die Systemuhr bereits verwendet wird und eine weniger wichtige Priorität besitzt, dann erzeugt das Uhrenmanagementmodul 2 eine neue virtuelle Uhr für die neue ApplServ. Als Nächstes werden die jeweiligen ApplServS und die relativen Prioritäten mit der Systemuhr umgeschaltet, so dass die Systemuhr immer die gegenwärtig höchste Priorität in dem Knoten besitzt. Dies wird nun ausführlich erklärt.
Im Schritt 120 wird bestimmt, ob die Systemuhr bereits verwendet wird. Im negativen Fall kann die Systemuhr im Schritt 130 für die neue Anwendung mit der zugewiesenen Priorität verwendet werden. Falls sich die Systemuhr bereits in Gebrauch befindet, wird im Schritt 140 bestimmt, ob die Priorität der Systemuhr höher als die oder gleich der Priorität der neuen Anwendung ist. Falls die Priorität der Systemuhr niedriger als die Priorität der neuen Anwendung ist, wird eine neue virtuelle Uhr in der Uhrentabelle 3 initialisiert. Die ApplServ, die die Systemuhr vorher verwendet hat, wird der neuen virtuellen Uhr zugewiesen, während die neue ApplServ der Systemuhr zugewiesen wird. Folglich ist die Systemuhr immer der ApplServ mit der höchsten gegebenen Priorität zugewiesen. Falls andererseits die neue Priorität nicht höher als die Priorität der Systemuhr ist, initialisiert der Prozess im Schritt 160 eine neue virtuelle Uhr in der Uhrentabelle und weist sie der neuen ApplServ mit der neu zugewiesenen Priorität zu. Im Schritt 170 werden die Felder der THELLO-Pakete aktualisiert und wird die Rundsendung der THELLO-Pakete fortgesetzt.
9 zeigt schematisch das Format der THELLO-Pakete, die als Zeitangabenachrichten verwendet werden. Ein THELLO-Paket 30 enthält einen Paketkopf 31 und eine Kopie der Uhrentabelle 32. Die grundlegenden Informationen sind im Paketkopf 31 angegeben. Das Versionsfeld enthält die Protokollversion, z. B. 0 als die erste Version. Das Gemeinschafts-ID-Feld enthält den Identifikationsnamen der Uhrengemeinschaft (der mit einem AHN oder mit dem Knotennamen selbst übereinstimmen kann). Das (s)TI_node-Feld enthält die IP-Adresse des Knotens, der die Rundsendung des THELLO-Pakets ausführt. Das Feld der Anzahl der Mitglieder gibt die Anzahl der Knoten im AHN oder in der Gemeinschaft an. Das Referenzzeitstem pelfeld enthält den genauen Zeitpunkt, zu dem das THELLO-Paket durch den (s)TI_node erzeugt worden ist. Die Informationen bezüglich der Uhr(en) des sendenden (s)TI_node sind im Uhrentabellenblock 32 des THELLO-Pakets 30 vorgesehen. Der Uhrentabellenblock 32 enthält die Informationen über die genaue Zeitmessung aller Uhren in der ersten Spalte, über die Namen der entsprechenden ApplServS in der zweiten Spalte und über die jeweiligen Prioritäten in der dritten Spalte. Die Uhrenwerte (Zeiten) sind der Reihe nach aufgelistet, d. h. der erste Eintrag (die erste Zeile) ist immer die Systemuhr, wobei dann die virtuelle Uhr 1 (die zweite Zeile), die virtuelle Uhr 2 usw. kommen. Dies bedeutet, dass in dem THELLO-Paket die Informationen der Uhrentabelle des sendenden Knotens enthalten sind.
10 zeigt einen Ablaufplan einer periodischen THELLO-Rundsendeprozedur. Der Prozess wird im Schritt 200 begonnen, wenn wenigstens eine Anwendung ApplServ ausgeführt wird. Als Nächstes werden im Schritt 210 die Kriterien für die THELLO-Periodizität überprüft, wobei die Periode P schließlich aktualisiert wird. Im Schritt 220 wird bestimmt, ob irgendeine neue ApplServ in dem Knoten ausgeführt wird. Im positiven Fall werden im Schritt 230 das Format/die Felder des THELLO-Pakets aktualisiert, wobei im Schritt 240 ein Zeitgeber für eine Warteperiode aktiviert wird. Die Warteperiode wird entsprechend der THELLO-Rundsendeperiode P – 5·x ms berechnet. Die Zeit x (ms) entspricht einer Hardware-/Software-Operation, d. h. einer Entscheidungs- oder einer Aktualisierungsoperation. Dies ist so, weil es höchstens vier Operationen in 8 gibt, die ausgeführt werden, wenn eine neue ApplServ startet, zuzüglich zweier Operationen in der in 10 gezeigten Schleife (die Schritte 210 und 230). Dies führt zu fünf Operationen im Durchschnitt, die von der Periode P abgezogen werden müssen, wenn eine neue ApplServ begonnen wird. Nach dem Verstreichen der Warteperiode wird im Schritt 250 die Rundsendung eines THELLO-Pakets ausgeführt. Falls bestimmt wird, dass keine neue ApplServ ausgeführt wird, wird im Schritt 260 der Zeitgeber für eine Wartezeit p – x ms gesetzt, wobei, nachdem diese Zeit abgelaufen ist, im Schritt 250 die Rundsendung eines neuen THELLO-Pakets ausgeführt wird.
11 zeigt einen Ablaufplan für einen Zeitsynchronisationsprozess, der im Schritt 300 für jedes empfangene THELLO-Paket begonnen wird. Die in der dem THELLO-Paket beigefügten Uhrentabelle aufgelisteten ApplServS werden im Schritt 310 untersucht, wobei im Schritt 320 bestimmt wird, ob eine gemeinsame ApplServ im Knoten ausgeführt wird. Im negativen Fall wird im Schritt 325 bestimmt, ob eine im empfangenen THELLO-Paket aufgelistete ApplServ von Interesse ist; im positiven Fall werden im Schritt 335 die Prozeduren nach 8 und 10 vor dem im Folgenden beschriebenen Schritt 350 angewendet. Im negativen Fall (kein Interesse am Starten einer neuen ApplServS) wird im Schritt 330 das THELLO-Paket verworfen. Im Fall irgendeiner gemeinsamen ApplServS wird im Schritt 340 bestimmt, ob es einen Bedarf an einer Synchronisation der gemeinsamen ApplServ gibt. Wenn nicht, wird das empfangenen THELLO-Paket im Schritt 330 verworfen. Falls eine Synchronisation notwendig ist, wird im Schritt 350 durch das Zeitauswahlmodul 1 des N_node die Ausbreitungsverzögerungs-Schätzprozedur ausgeführt. Dann synchronisiert das Uhrenmanagementmodul 2 im Schritt 360 die (virtuelle) Uhr des gemeinsamen ApplServ. Dies beendet die Verarbeitung für das empfangene THELLO-Paket, wobei im Schritt 370 das nächste Paket ausgewählt wird.
12 veranschaulicht ein Beispiel für den Fluss der Nachrichten, der verwendet wird, um die Umlaufzeit oder die Ausbreitungsverzögerung zu schätzen. Die Ereignisse im N_node sind auf der linken Seite der 12 gezeigt, während die Ereignisse im (s)TI_node auf der rechten Seite gezeigt sind. Im Allgemeinen beginnt die Paketnumerierung mit 1 für den N_node und mit 0 für den (s)TI_node. Dies ist so, weil der Empfang des durch den N_node gesendeten Pakets i durch den (s)TI_node als t_{T(i – 1)_rec} mit einem Zeitstempel versehen wird. Das in 12 gezeigte erste TREQ-Paket und das entsprechende TACK-Paket besitzen die Paketnummer i – 1. Die Pakete, die eine Paketnummer i und i + 1 besitzen, sind außerdem gezeigt.
In der in 12 gezeigten Situation ist der N_node der Uhrzeit-Erfassungsknoten, der die TREQ-Pakete sendet, während der (s)TI_node mit den TACK-Paketen antwortet. Falls der Uhrzeit-Erfassungsknoten der (s)TI_node ist, wirken die TACK-Pakete als TREQ-Pakete und umgekehrt, aber der Zeitablauf ist grundsätzlich der gleiche.
Um die relative RTT und ihre Varianz zu schätzen, müssen die folgenden Informationen in den ausgetauschten Nachrichten enthalten sein: für die RTT-Berechnung die letzten vier gesendeten oder empfangenen Zeitstempel; für die Varianzberechnung die vier Summen aller früheren quadrierten RTTs und aller früheren RTTs sowohl im N_node als auch im (s)TI_node. Die bedeutet, dass insgesamt nur acht Werte erforderlich sind (siehe die 13 und 14 für das TREQ- und das TACK-Paketformat).
Jedesmal, wenn ein TREQ- oder ein TACK-Paket gesendet oder empfangen wird, aktualisiert der entsprechende Knoten, nachdem er alle Zeitstempel-Felder nach rechts verschoben hat (und auf diese Weise das Zeitstempel-Feld ganz rechts, t_stamp 4, aus dem Paket gelöscht hat), den Zeitstempel t_stamp 1 im entsprechenden Feld des TREQ- oder TACK-Pakets. In dieser Weise sind immer die letzten vier aktualisierten Zeitstempel in den Paketen enthalten.
Die folgenden Werte sind für die RTT-Berechnung definiert:

• t_Nis: der Zeitstempel im N_node für das zu sendende TREQ-Paket Nummer i;
• t_Nir: der Zeitstempel im N_node für das soeben empfangene TACK-Paket Nummer i;
• t_Tis: der Zeitstempel im (s)TI_node für das zu sendende TACK-Paket Nummer i;
• t_Tir: der Zeitstempel im (s)TI_node für das soeben empfangene TREQ-Paket Nummer i;
• RTT_Ni: die nach dem Empfang des TACK Nummer i berechnete Umlaufzeit im N_node;
• RTT_Ti: die nach dem Empfang des TREQ (i + 1) berechnete Umlaufzeit im (s)TI_node;
• PT_Ni oder PT_Ti; die Verarbeitungszeiten (PT) im N_node oder s(TI)_node nach dem empfangenen Paket i;
• PD_i: es wird angenommen, dass die im N_node oder (s)TI_node geschätzten Ausbreitungsverzögerungen (PD) beim Empfang des TACK bzw. des TREQ gleich sind (unter Bedingungen einer schnellen Mobilität können diese Verzögerungen nicht gleich sein, aber ihre separate Schätzung erfordert kompliziertere und längere Paketaustausche);
• S² _N und S_N: die Summen der vorher im N_node geschätzten quadrierten und einfachen RTT_N; diese Summen werden auf null initialisiert;
• S² _T und S_T: die Summen der vorher im (s)TI_node geschätzten quadrierten und einfachen RTT_T; diese Summen werden auf null initialisiert.

Werden die Indizes N und T für einen Augenblick unterdrückt, kann die Umlaufzeit RTT_i an einem Knoten, wenn das Paket Nummer i empfangen wird, berechnet werden, indem die Verarbeitungszeit PT_i des gegenüberliegenden Knotens von der verstrichenen Zeitdauer zwischen dem letzten Paar von gesendeten und empfangenen Paketen subtrahiert wird. Eine Schätzung der Ausbreitungsverzögerung PD_i kann erhalten werden, indem die letzte berechnete RTT_i durch zwei dividiert wird. Dies nimmt eine symmetrische Situation mit völlig gleichen Ausbreitungsverzögerungen in beiden Richtungen an. Die Varianz Ω_i ² wird berechnet, indem RTT_i ² zu S² addiert wird, das Ergebnis durch i dividiert wird und vom Ergebnis das Quadrat der Summe aus RTT_i und S subtrahiert wird. Falls diese berechnete Varianz kleiner als ein Systemschwellenwert ist, kann die Schätzung angehalten werden, wobei kein weiterer Paketaustausch notwendig ist. Dies wird durch den Knoten entschieden, der die Uhrzeit erfasst.
13 zeigt das Format eines TREQ-Pakets. Ein TREQ-Paket 40 besitzt zwei Blöcke. Die grundlegenden Informationen sind im Kopfblock 41 enthalten, während die Informationen bezüglich der Uhren des sendenden N_node im Uhrentabellenblock 42 enthalten sind. Das Versionsfeld enthält die Protokollversion, z. B. 0 als die erste Version. Das Gemeinschafts-ID-Feld enthält den Identifikationsnamen der Uhrengemeinschaft (der mit einem AHN oder mit dem Knotennamen selbst übereinstimmen kann). Das N_node-Feld enthält die IP-Adresse des Senders des TREQ-Pakets, während das Feld für die laufende Nummer eine inkrementale Paketnummer (i = 1, 2, 3, ...) enthält. Das Zeitstempel-Feld enthält vier Zeitstempel t_stamp 1, t_stamp 2, t_stamp 3, t_stamp 4, die von links nach rechts numeriert sind. Falls i = 1 gilt, d. h. das erste Paket einer Folge von TREQ-/TACK-Paketen ausgetauscht wird, sind die drei Zeitstempel ganz rechts, t_stamp 2, t_stamp 3, t_stamp 4, auf null gesetzt. Die S²-Felder (S² _N und S² _T) geben die Summen der bisher berechneten quadrierten Verzögerungen (RTT_Ni ² oder RTT_Ti ²) an. Die S-Felder (S_N und S_T) enthalten die Summen der bisher berechneten Verzögerungen (RTT_Ni und RTT_Ti). Der Uhrentabellenblock 42 enthält einen Teil der lokalen Uhrentabelle 3 des N_node. Nur die Einträge der Uhren, die den ApplServS entsprechen, an denen der N_node interessiert ist, sind nach dem Systemuhr-Eintrag aufgenommen (der mit einer ApplServ in Beziehung stehen kann oder nicht; im negativen Fall kann er trotzdem aufgelistet sein).
14 zeigt das Format eines TACK-Pakets. Ein TACK-Paket 50 enthält einen Block 51 mit den grundlegenden Informationen, der sich auf den Paketkopf bezieht, und einen Uhrentabellenblock 52, der die Informationen bezüglich der Uhren des sendenden (s)TI_node enthält. Das Versionsfeld enthält die Protokollversion, z. B. 0 als die erste Version. Das Gemeinschafts-ID-Feld enthält den Identifikationsnamen der Uhrengemeinschaft (der mit einem AHN oder mit dem Knotennamen selbst übereinstimmen kann). Das (s)TI_node-Feld enthält die IP-Adresse des TACK-Senders, während das Feld für die laufende Nummer eine inkrementale Paketnummer (i = 1, 2, 3, ...) enthält. Das Zeitstempel-Feld enthält vier Zeitstempel t_stamp 1, t_stamp 2, t_stamp 3, t_stamp 4, die von links nach rechts numeriert sind. Falls i = 1 gilt, d. h. das erste TACK-Paket, sind die drei Zeitstempel ganz rechts, t_stamp 2, t_stamp 3, t_stamp 4, auf null gesetzt. Die S²-Felder geben die Summen der bisher berechneten quadrierten Verzögerungen (RTT_Ni ² oder RTT_Ti ²) an. Die S-Felder geben die Summen der bisher berechneten Verzögerungen (RTT_Ni und RTT_Ti) an. Der Uhrentabellenblock 52 enthält einen Teil der Uhrentabelle des lokalen (s)TI_node. Er enthält nur die Einträge der Uhren bezüglich der ApplServS, an denen der N_node interessiert ist (die Werte der Uhren sind selbstverständlich diejenigen im (s)TI_node, wobei einer von ihnen die Systemuhr selbst sein kann; im negativen Fall kann er trotzdem als erster Eintrag aufgelistet sein).
15 zeigt einen Ablaufplan, der die im N_node ausgeführtre Verzögerungsschätzprozedur veranschaulicht. Der Prozess wird im Schritt 400 begonnen, wenn das Zeitauswahlmodul 1 bestimmt, dass der Knoten an einer ApplServ interessiert ist, die in einem empfangenen THELLO-Paket angegeben ist. Im Schritt 410 werden die TREQ-Paket-Blöcke vorbereitet oder bestätigt und über das MAC-Schicht-Modul 5 an den (s)TI_node gesendet. Im Schritt 420 wird bestimmt, ob ein Zeitablauf auftritt, bevor ein entsprechendes TACK-Paket empfangen wird. Falls ein TACK vor dem Zeitablauf empfangen wird, wird das Paket im Schritt 430 untersucht, wobei die Umlaufzeit RTT_N und ihre Varianz im Schritt 430 berechnet werden. Der N_node bestimmt im Schritt 440, ob er die gemeinsame Uhrzeit vom (s)TI_node erfasst oder ob er die Uhrzeit bereitstellt. Wenn der N_node die Uhrzeit bereitstellt, kehrt der Prozess zum Schritt 410 für das Senden eines neuen TREQ-Pakets zurück. Andernfalls wird die berechnete Varianz der Umlaufzeit im Schritt 450 untersucht. Falls die Varianz größer als ein gegebener Schwellenwert ist, wird die berechnete Umlaufzeit als nicht ausreichend stabil betrachtet, wobei der Prozess zum Schritt 410 für das Senden eines neuen TREQ-Pakets zurückkehrt. Falls die Varianz die gegebene Bedingung erfüllt, wird im Schritt 460 die Ausbreitungsverzögerung PD_N berechnet und dem Uhrenmanagementmodul bereitgestellt. Der Zeitablauf und der Schwellenwert, die bei der Verzögerungsschätzprozedur verwendet werden, können Systemparameter oder dynamische Variable sein, die mit irgendwelchen Eigenschaften der drahtlosen Umgebung (wie der Verbindungsstabilität oder die Endgerätemobilität) in Beziehung stehen.
16 zeigt einen Ablaufplan, der die im (s)TI_node ausgeführte Verzögerungsschätzprozedur veranschaulicht. Der Prozess wird im Schritt 500 begonnen, wenn das Zeitauswahlmodul 1 des (s)TI_node ein TREQ-Paket empfängt. Im Schritt 510 wird bestimmt, ob das empfangene TREQ-Paket das erste TREQ-Paket oder wenigstens das zweite in einer Folge von empfangenen TREQ-Paketen ist. Falls wenigstens ein vorhergehendes TREQ-Paket empfangen worden ist, werden im Schritt 520 die Umlaufzeit RTT_T und ihre Varianz berechnet. Dann bestimmt der Knoten im Schritt 530, ob er der Uhrzeit-Erfassungsknoten oder der Uhrzeit-Bereitstellungsknoten ist. Falls der (s)TI_node die Uhrzeit vom N_node erfasst, geht der Prozess zum Schritt 540 weiter, um die berechnete Varianz mit einem Schwellenwert zu vergleichen. Falls die berechnete Varianz kleiner als der Schwellenwert ist, wird im Schritt 550 die Ausbreitungsverzögerung PD_T dem Uhrenmanagementmodul 2 bereitgestellt, wobei die Verzögerungsschätzprozedur beendet wird. Im Schritt 560 wird ein TACK-Paket-Block vorbereitet und über das MAC-Schicht-Modul 5 an den N_node gesendet. Dieser Schritt wird ausgeführt, wenn das empfangene TREQ-Paket das erste TREQ-Paket ist (Schritt 510), der (s)TI_node der Uhrzeit-Bereitstellungsknoten ist (Schritt 530) oder die geschätzte Varianz die Bedingung nicht erfüllt (Schritt 540). Als Nächstes wird im Schritt 570 bestimmt, ob ein TREQ-Paket empfangen wird, bevor eine gegebene Wartezeit abläuft. Diese Wartezeit ist vorzugsweise auf das Zweifache des durch den N_node verwendeten Zeitablaufwerts gesetzt. Die Wartezeit für den (s)TI_node ist auf eine längere Periode gesetzt, weil ein TACK-Paket verloren werden kann oder der N_node gerade keinen Bedarf an weiteren TACK-Paketen bei der Verzögerungsschätzprozedur besitzen kann. Wenn ein TREQ-Paket innerhalb der Zeitdauer empfangen wird, fährt der Prozess im Schritt 520 mit der Berechnung der Umlaufzeit fort. Andernfalls hält das Zeitauswahlmodul im Schritt 580 die Verzögerungsschätzprozedur an.
Obwohl die vorliegende Erfindung unter Bezugnahme auf die Ausführungsformen für mobile Ad-hoc-Netze erklärt worden ist, ist sie nicht auf die veranschaulichten spezifischen Ausführungsformen eingeschränkt. Es wird von einem Durchschnittsfachmann auf dem Gebiet erkannt, dass die vorliegende Erfindung auf andere Typen der Kommunikationsnetze angewendet werden kann und dass an den obenbeschriebenen Ausführungsformen Modifikationen vorgenommen werden können, ohne den Umfang der Erfindung zu verlassen.

Claims

Verfahren zum Synchronisieren von Uhren von Netzknoten (10) in einem Kommunikationsnetz (8), gekennzeichnet durch die folgenden Schritte: Vergleichen einer Priorität, die einer Uhr eines ersten Knotens zugewiesen ist, mit einer Priorität, die einer Uhr eines zweiten Knotens zugewiesen ist; anhand des Ergebnisses des Vergleichs der Prioritäten Bestimmen einer Referenzuhr mit einer höheren Priorität und einer abhängigen Uhr mit einer niedrigeren Priorität unter den Uhren des ersten und des zweiten Knotens; und Stellen der Zeit der abhängigen Uhr auf die Zeit, die durch die Referenzuhr angegeben wird.
Verfahren nach Anspruch 1, wobei die einer Uhr eines Knotens (10) zugewiesene Priorität mit einer Eigenschaft der Uhr, insbesondere der Ganggenauigkeit und/oder ob die Uhr eine absolute oder eine relative Zeit angibt und/oder ob sie die Systemuhr des Knotens ist, oder mit einer Eigenschaft einer Anwendung der Uhr in Beziehung steht.
Verfahren nach Anspruch 1 oder 2, wobei dann, wenn die Prioritäten der jeweiligen Uhren gleich sind, der Vergleich auf einem zusätzlichen Kriterium, der insbesondere mit einer Eigenschaft der Uhren in Beziehung steht, basiert.
Verfahren nach wenigstens einem der Ansprüche 1 bis 3, wobei ein Knoten (10) wenigstens zwei Uhren besitzt, die eine ihnen zugewiesene Priorität haben, wobei das Verfahren vor dem Vergleich der Prioritäten umfasst: Auswählen einer der wenigstens zwei Uhren des Knotens (10) für die Synchronisation anhand einer Anwendung oder eines Dienstes, die bzw. der dem ersten und dem zweiten Knoten gemeinsam sind, und Bestimmen, ob die Uhren des ersten und des zweiten Knotens, die der gemeinsamen Anwendung oder dem gemeinsamen Dienst entsprechen, eine Synchronisation erfordern.
Verfahren nach wenigstens einem der Ansprüche 1 bis 4, wobei mehrere Anwendungen und/oder Dienste in einem Knoten (10) ausgeführt werden, wobei das Verfahren ferner die folgenden Schritte umfasst: Bestimmen, ob eine entsprechende Anwendung und/oder ein entsprechender Dienst in dem ersten und in dem zweiten Knoten ausgeführt werden; und im positiven Fall Auswählen der entsprechenden Uhren des ersten und des zweiten Knotens, die der bestimmten entsprechenden Anwendung und/oder dem bestimmten entsprechenden Dienst zugewiesen sind, unter mehreren Uhren, die in dem Knoten arbeiten, für die Synchronisation.
Verfahren nach wenigstens einem der Ansprüche 1 bis 5, wobei ein Knoten eine Systemuhr enthält, wobei das Verfahren ferner die folgenden Schritte umfasst: bei einer Initialisierung einer neuen Anwendung oder eines neuen Dienstes in dem Knoten (10) Bestimmen, ob für die neue Anwendung oder den neuen Dienst eine virtuelle Uhr, die eine Zeit angibt, die von der Systemuhr verschieden ist, notwendig ist; und im positiven Fall Initialisieren der virtuellen Uhr und Zuweisen einer Priorität zu der virtuellen Uhr.
Verfahren nach wenigstens einem der Ansprüche 1 bis 6, wobei wenigstens zwei Knoten (10) des Kommunikationsnetzes (8) in einer Gemeinschaft von Knoten (10) angeordnet sind, die eine gemeinsam genutzte Anwendung und/oder einen gemeinsam genutzten Dienst anhand einer gemeinsam synchronisierten Uhr in der Gemeinschaft ausführen, wobei eine Uhr einer ersten Gemeinschaft und eine Uhr einer zweiten Gemeinschaft synchronisiert werden, falls sich beide Gemeinschaften auf dieselbe Anwendung und/oder denselben Dienst beziehen.
Verfahren nach wenigstens einem der Ansprüche 1 bis 7, wobei ein Knoten, der eine Anwendung und/oder einen Dienst ausführt, über das Kommunikationsnetz (8) eine Zeitangabenachricht sendet, die die laufende Anwendung und/oder den laufenden Dienst sowie die Priorität der jeweils zugewiesenen Uhr angibt.
Verfahren nach Anspruch 8, wobei ein Knoten, der eine Zeitangabenachricht empfangt, die folgenden Schritte ausführt: Bestimmen, ob der Knoten (10) eine Anwendung und/oder einen Dienst ausführt, die bzw. der der Anwendung und/oder dem Dienst entspricht, die bzw. der in der empfangenen Zeitangabenachricht angegeben wird; Vergleichen der mit der Zeitangabenachricht empfangenen Priorität mit der Priorität der jeweiligen Uhr, die der entsprechenden Anwendung und/oder dem entsprechenden Dienst, die bzw. der in den Knoten ausgeführt wird, zugewiesen ist; und Bestimmen der Referenzuhr und der abhängigen Uhr aus den jeweiligen Uhren des empfangenden Knotens und des Knotens, von dem die Zeitangabenachricht ausging.
Verfahren nach Anspruch 8 oder 9, wobei ein Knoten, der eine Zeitangabenachricht empfängt, bestimmt, ob er am Start einer entsprechenden Anwendung und/oder eines entsprechenden Dienstes in dem Knoten (10) interessiert ist, und die entsprechende Anwendung und/oder den entsprechenden Dienst nach der Synchronisation der entsprechenden Uhren startet.
Verfahren nach Anspruch 9 oder 10, wobei ein Knoten, der eine Zeitangabenachricht empfängt und seine eigene Uhr, die der Anwendung und/oder dem Dienst zugewiesen ist, die bzw. der in der empfangenen Zeitangabenachricht angegeben wird, als abhängige Uhr bestimmt, die abhängige Uhr in Übereinstimmung mit Zeitinformationen der Referenzuhr und einer geschätzten Ausbreitungsverzögerung PD für Nachrichten zwischen dem ersten und dem zweiten Knoten stellt.
Verfahren nach Anspruch 9 oder 10, wobei ein Knoten (10), der eine Zeitangabenachricht empfängt und seine eigene Uhr, die der Anwendung und/oder dem Dienst zugewiesen ist, die bzw. der in der empfangenen Zeitangabenachricht angegeben wird, als Referenzuhr bestimmt, eine Zeitreferenznachricht, die die Zeit der Referenzuhr enthält, zu dem Ausgangsknoten (10) der empfangenen Zeitangabenachricht sendet, um die Nachrichtenausbreitungsverzögerung PD zu schätzen.
Verfahren nach wenigstens einem der Ansprüche 8 bis 12, wobei ein Knoten, der eine Zeitangabenachricht empfängt, dem Nachrichtenausgangsknoten (10) antwortet oder seine entsprechende Uhr in Übereinstimmung mit den Zeitinformationen, die mit der Zeitreferenznachricht empfangen werden, stellt.
Verfahren nach wenigstens einem der Ansprüche 1 bis 13, wobei ein Knoten, der eine seine Uhr mit einer Uhr eines weiteren Knotens synchronisiert, damit beginnt, Zeitangabenachrichten periodisch über das Kommunikationsnetz (8) zu senden.
Verfahren nach wenigstens einem der Ansprüche 1 bis 14, das das Bestimmen einer Ausbreitungsverzögerung PD für Nachrichten, die in dem Kommunikationsnetz (8) zwischen dem ersten Knoten und dem zweiten Knoten gesendet werden, und das Stellen der Zeit der abhängigen Uhr anhand der Zeit der Referenzuhr und der bestimmten Ausbreitungsverzögerung PD umfasst.
Verfahren nach Anspruch 15, das umfasst: Schätzen einer Umlaufzeit RTT für Nachrichten, die zwischen dem ersten und dem zweiten Knoten ausgetauscht werden, und Bestimmen der Ausbreitungsverzögerung PD anhand der geschätzten Umlaufzeit RTT.
Verfahren nach Anspruch 16, wobei Nachrichten ausgetauscht werden und die Umlaufzeit RTT oder die Ausbreitungsverzögerung PD geschätzt wird, bis die geschätzte Ausbreitungsverzögerung PD und/oder die Umlaufzeit RTT ein vorgegebenes Stabilitätskriterium erfüllen.
Vorrichtung zum Synchronisieren von Uhren von Netzknoten (10) in einem Kommunikationsnetz (8), gekennzeichnet durch Zeitauswahlmittel (1), die ausgelegt sind, um eine Priorität, die einer Uhr eines ersten Knotens zugewiesen ist, mit einer Priorität, die einer Uhr eines zweiten Knotens zugewiesen ist, zu vergleichen und um anhand des Ergebnisses des Vergleichs der Prioritäten eine Referenzuhr mit einer höheren Priorität und eine abhängige Uhr mit einer niedrigeren Priorität unter den Uhren des ersten und des zweiten Knotens zu bestimmen; und Uhrenmanagementmittel (2), die ausgelegt sind, um die Zeit der abhängigen Uhr auf die Zeit, die durch die Referenzuhr angegeben wird, zu stellen.
Vorrichtung nach Anspruch 18, die umfasst: eine Uhrentabelle (3) zum Speichern von Beziehungen zwischen Anwendungen oder Diensten, zugewiesenen Uhren und Prioritäten der Uhren, wobei die Zeitauswahlmittel (1) ausgelegt sind, um zu bestimmen, ob entsprechende Anwendungen und/oder Dienste in dem ersten und in dem zweiten Knoten ausgeführt werden, und um die entsprechenden Uhren des ersten und des zweiten Knotens aus der entsprechenden Uhrentabelle (3) der Knoten (10) für die Synchronisation auszuwählen.
Vorrichtung nach Anspruch 19, wobei die Uhrenmanagementmittel (2) ausgelegt sind, um Zeitinformationen für die Anwendungen und/oder Dienste anhand der entsprechenden Uhr, die in der Uhrentabelle (3) aufgelistet ist, bereitzustellen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 20, wobei ein Knoten eine Systemuhr enthält und die Uhrenmanagementmittel (2) ferner ausgelegt sind, um zu bestimmen, ob für eine neue Anwendung oder einen neuen Dienst, die bzw. der in dem Knoten (10) initialisiert wird, eine virtuelle Uhr, die eine von der Systemuhr verschiedene Zeit angibt, notwendig ist, und um die virtuelle Uhr zu initialisieren und der virtuellen Uhr eine Priorität zuzuweisen, falls die Antwort positiv ist.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 21, die umfasst: Sendemittel, die ausgelegt sind, um Zeitangabenachrichten, die eine Anwendung und/oder einen Dienst, die bzw. der in einem Knoten abläuft, und die Priorität der jeweils zugewiesenen Uhr angeben, über das Kommunikationsnetz (8) zu senden.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 22, die umfasst: Empfangsmittel, die ausgelegt sind, um Zeitangabenachrichten von dem Kommunikationsnetz (8) zu empfangen, wobei die Zeitauswahlmittel (1) konfiguriert sind, um zu bestimmen, ob der Knoten eine Anwendung und/oder einen Dienst ausführt, die bzw. der einer Anwendung und/oder einem Dienst entspricht, die bzw. der in einer empfangenen Zeitangabenachricht empfangen wird, um eine in der Zeitangabenachricht empfangene Priorität mit einer Priorität der jeweiligen Uhr, die der entsprechenden Anwendung und/oder dem entsprechenden Dienst, die bzw. der in dem Knoten ausgeführt werden, zugewiesen ist; und die Referenzuhr und die abhängige Uhr zu bestimmen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 23, wobei die Uhrenmanagementmittel (2) ausgelegt sind, um eine Uhr, die als eine abhängige Uhr bestimmt wird, in Übereinstimmung mit den mit einer Zeitangabenachricht empfangenen Zeitinformationen zu stellen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 24, wobei die Sendemittel ausgelegt sind, um eine Zeitreferenznachricht, die die Zeit der Referenzuhr enthält, zu dem Knoten (10), von dem die empfangene Zeitangabenachricht ausging, zu senden.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 25, wobei die Empfangsmittel ausgelegt sind, um Zeitreferenznachrichten zu empfangen, und die Uhrenmanagementmittel (2) ausgelegt sind, um die abhängige Uhr in Übereinstimmung mit Zeitinformationen, die mit einer Zeitreferenznachricht empfangen werden, zu stellen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 26, wobei die Zeitauswahlmittel (1) ausgelegt sind, um eine Ausbreitungsverzögerung PD und/oder eine Umlaufzeit RTT für Nachrichten, die in dem Kommunikationsnetz (8) zwischen dem ersten und dem zweiten Knoten übertragen werden, zu schätzen, und die Uhrenmanagementmittel (2) ausgelegt sind, um die in der Uhrentabelle (3) aufgelistete abhängige Uhr anhand der Zeit der Referenzuhr und der bestimmten Ausbreitungsverzögerung PD und/oder der Umlaufzeit RTT zu stellen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 27, wobei die Sende- und/oder Empfangsmittel ausgelegt sind, um Nachrichten zu/von einem Ad-hoc-Netz (8), insbesondere zu/von einem Ad-hoc-Mobilnetz (8) zu senden bzw. zu empfangen.
Vorrichtung nach wenigstens einem der Ansprüche 18 bis 28, die als eine Netzvorrichtung (10) in einem Ad-hoc-Mobilnetz (8) ausgelegt ist.
Computerprogrammprodukt, das direkt in den internen Speicher eines digitalen Computers geladen werden kann und Softwarecode-Abschnitte enthält, um die Schritte wenigstens eines der Ansprüche 1 bis 17 auszuführen, wenn das Produkt auf dem Computer abläuft.