DE102023200297A1

DE102023200297A1 - Controller, der eine taktfrequenz basierend auf einer empfangenen symbolrate abstimmt

Info

Publication number: DE102023200297A1
Application number: DE102023200297.3A
Authority: DE
Inventors: Bar Shapira; Ariel Almog; Dotan David Levi; Natan Manevich; Thomas Kernen
Original assignee: Mellanox Technologies Ltd
Current assignee: Mellanox Technologies Ltd
Priority date: 2022-01-18
Filing date: 2023-01-16
Publication date: 2023-07-20
Also published as: US20230229188A1; US11835999B2; CN116470978A

Abstract

Es wird ein System offenbart, das zwei oder mehr Netzwerkelemente einschließt, die jeweils einen Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC) umfassen, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.

Description

GEBIET
Bestimmte Ausführungsformen beziehen sich auf Synchronisierung allgemein und insbesondere auf Takt- und/oder Frequenzsynchronisierung.
ALLGEMEINER STAND DER TECHNIK
Es ist, z. B. von dem im gemeinsamen Besitz stehenden US-Patent Nr. 10,778,406 nach Gaist et al. eine „Netzwerkvorrichtung, die eine Frequenzgenerationsbeschaltung, die konfiguriert ist, um ein Taktsignal zu generieren, einen Phasenregelkreis, der konfiguriert ist, um einen lokalen Takt basierend auf dem Taktsignal zu generieren, eine Vielzahl von Empfängern, die konfiguriert sind, um jeweilige Datenströme von jeweiligen entfernten Taktquellen zu empfangen, wobei jeder Empfänger der Vielzahl von Empfängern konfiguriert ist, um einen entfernten Takt von einem jeweiligen Datenstrom zu regenerieren, und einen Controller, der konfiguriert ist, um den von einem der Vielzahl von Empfängern regenerierten entfernten Takt als Mastertakt zu identifizieren, ein Taktdifferenzial zwischen dem identifizierten entfernten Takt und dem lokalen Takt zu finden, der Frequenzgenerationsbeschaltung reagierend auf das Taktdifferenzial ein Steuerungssignal bereitzustellen, das die Frequenzgenerationsschaltung veranlasst, das Taktsignal abzustimmen, um so einen absoluten Wert des Taktdifferenzials iterativ zu reduzieren, einschließt" bekannt.
ÜBERSICHT DER OFFENBARUNG
Die Erfindung wird durch die Ansprüche definiert. Um die Erfindung zu illustrieren, werden hierin Ausführungsformen, die möglicherweise im Umfang der Ansprüche liegen oder nicht, beschrieben.
Bestimmte Ausführungsformen sind bestrebt, eine verbesserte Takt- und/oder Frequenzsynchronisierung, z. B. in Netzwerkvorrichtungen, bereitzustellen.
Bestimmte Ausführungsformen sind bestrebt, ein verbessertes System und Verfahren zum Disziplinieren eines PHC (PTP-Hardware-Taktgebers) oder allgemein eines Taktgebers bereitzustellen.
Bestimmte Ausführungsformen sind bestrebt, PHC-Frequenzabstimmungen in mindestens einem Netzwerkvorrichtungs-PHC, basierend auf der Netzwerk-RX-Symbolrate, z. B. durch Aktualisieren des PHC-DPLL (Digital Phase-Locked Loop, digitalen Phasenregelkreises) bereitzustellen.
Bestimmte Ausführungsformen sind bestrebt, ein System bereitzustellen, das eine genaue Zeitsteuerung gewährleistet.
Bestimmte Ausführungsformen sind bestrebt, ein System oder Subsystem bereitzustellen, das interne Stabilität und/oder Genauigkeit zwischen Knoten des Systems oder Subsystems gewährleistet.
Bestimmte Ausführungsformen sind bestrebt, verbesserte Netzwerkvorrichtungen, wie etwa verbesserte NICs (Network Interface Cards, Netzwerkschnittstellenkarten), einschließlich verbesserter intelligenter NICs, und/oder verbesserte Schalter bereitzustellen.
Bestimmte Ausführungsformen sind bestrebt, die Genauigkeit und/oder Stabilität gegenüber dem PTP-Standard zu verbessern.
Bestimmte Ausführungsformen sind bestrebt, den SyncE-Standard zu verbessern.
Bestimmte Ausführungsformen sind bestrebt, die SyncE-Hardwareanforderungen zu lockern.
Bestimmte Ausführungsformen sind bestrebt, einen PHC durch Aufrechterhalten der Genauigkeit und/oder Stabilität der Frequenz des Präzisionszeitprotokoll(Precision Time Protocol, PTP)-Hardware-Taktgebers aufrechtzuerhalten. Das Bereitstellen des obigen Controllers ist nützlich für das Aufrechterhalten der Genauigkeit und/oder Stabilität der Frequenz des Präzisionszeitprotokoll(PTP)-Hardware-Taktgebers. Der Begriff „Taktgenauigkeit“ (oder „Taktfrequenzgenauigkeit“), wie hierin verwendet, beschreibt, zu welchem Grad eine tatsächliche Frequenz eines Taktes mit einer spezifizierten Taktfrequenz übereinstimmt bzw. dieser gleicht. Der Begriff „Taktstabilität“ (oder „Taktfrequenzstabilität“) beschreibt, zu welchem Grad eine Oszillatorfrequenz eines Taktes Schwankungen widersteht. Temperaturveränderung ist ein beispielhafter Faktor, der die Stabilität beeinträchtigen kann. Andere Faktoren, die die Stabilität beeinträchtigen können, schließen alle oder einen Teilsatz von Folgendem ein: Altern der Taktgeber-Hardware, Speisespannung an den Taktgeber, Schlag an oder Vibration von Taktgeber und am Taktgeber anliegende Kapazitätslast.
Im Umfang der Erfindung sind mindestens die folgenden Ausführungsformen eingeschlossen:

Ausführungsform 1. Ein System, das Folgendes umfasst: zwei oder mehr Netzwerkelemente, die jeweils einen Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC, HC = Hardware Clock) umfassen, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Ausführungsform 2. Das System nach einer vorhergehenden Ausführungsform, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Ausführungsform 3. Das System nach einer vorhergehenden Ausführungsform, wobei mindestens eines der zwei oder mehr Netzwerkelemente ein Mobilfunknetzwerkelement umfasst.
Ausführungsform 4. Das System nach einer vorhergehenden Ausführungsform, wobei die zwei oder mehr Netzwerkelemente eine erste Antenne und eine zweite Antenne umfassen.
Ausführungsform 5. Das System nach einer vorhergehenden Ausführungsform, wobei mindestens eines der zwei oder mehr Netzwerkelemente ein Datenzentrumselement, das zu einem Datenzentrums-Cluster gehört, umfasst.
Ausführungsform 6. Das System nach einer vorhergehenden Ausführungsform, wobei das Datenzentrumselement einen Top-of-Rack(ToR)-Schalter umfasst.
Ausführungsform 7. Das System nach einer vorhergehenden Ausführungsform, wobei ein Schalter die Frequenzinformationen extrahiert, um eine Ensemble-Zeit zu bestimmen, und wobei die Ensemble-Zeit verwendet wird, um die Frequenz des PHC und seiner TX-Symbolrate abzustimmen.
Ausführungsform 8. Das System nach einer vorhergehenden Ausführungsform, wobei der Schalter die Ensemble-Zeit mindestens basierend auf einer ersten RX-Symbolrate, die von mindestens einem ersten Netzwerkelement empfangen wird, und mindestens basierend auf einer zweiten RX-Symbolrate, die von mindestens einem zweiten Netzwerkelement empfangen wird, bestimmt.
Ausführungsform 9. Das System nach einer vorhergehenden Ausführungsform, wobei die zwei oder mehr Netzwerkelemente zu einem Subnetzwerk gehören, das einen Schalter einschließt.
Ausführungsform 10. Ein Mobilfunknetzwerk, das Folgendes umfasst: ein erstes Mobilfunknetzwerkelement, das einen ersten Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC) umfasst, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist, und ein zweites Mobilfunknetzwerkelement, das einen zweiten PHC umfasst, der, mindestens teilweise, basierend auf den Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Ausführungsform 11. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Ausführungsform 12. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, wobei die RX-Symbolrate einer RX-Symbolrate des ersten Mobilfunknetzwerkelements und/oder des zweiten Mobilfunknetzwerkelements entspricht.
Ausführungsform 13. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, das ferner einen Schalter umfasst, wobei ein lokaler Takt an dem Schalter basierend auf einem gewichteten Durchschnitt der zwei oder mehr RX-Symbolraten abgestimmt wird und wobei der lokale Takt verwendet wird, um den ersten PHC und den zweiten PHC abzugleichen.
Ausführungsform 14. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, wobei das erste Mobilfunknetzwerkelement eine erste Antenne umfasst und wobei das zweite Mobilfunknetzwerkelement eine zweite Antenne umfasst.
Ausführungsform 15. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, wobei das erste Mobilfunknetzwerkelement und das zweite Mobilfunknetzwerkelement zu einer gemeinsamen Mikrozelle gehören.
Ausführungsform 16. Das Mobilfunknetzwerk nach einer vorhergehenden Ausführungsform, wobei die Frequenzinformationen aus einer Differenz zwischen einer RX-Symbolrate und einer TX-Symbolrate oder aus einer Differenz zwischen der RX-Symbolrate und dem PHC extrahiert werden.
Ausführungsform 17. Ein Datenzentrum, das Folgendes umfasst: ein erstes Netzwerkelement und ein zweites Netzwerkelement, wobei das erste Netzwerkelement einen erste Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC) umfasst, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist, und wobei das zweite Netzwerkelement einen zweiten PHC umfasst, der, mindestens teilweise, basierend auf den Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Ausführungsform 18. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei das erste Netzwerkelement einen ersten Netzwerkschnittstellencontroller (Network Interface Controller, NIC) umfasst und wobei das zweite Netzwerkelement einen zweiten NIC umfasst.
Ausführungsform 19. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei die Physikalische-Schicht-Frequenz-Informationen von einem Schalter empfangen werden.
Ausführungsform 20. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei der Schalter außerhalb eines Subnetzwerkes, das das erste Netzwerkelement und das zweite Netzwerkelement enthält, liegt.
Ausführungsform 21. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Ausführungsform 22. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei die extrahierten Frequenzinformationen verwendet werden, um eine Ensemble-Zeit zu bestimmen, und wobei die Ensemble-Zeit verwendet wird, um die Frequenz des ersten PHC abzustimmen.
Ausführungsform 23. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei die Ensemble-Zeit verwendet wird, um die Frequenz des zweiten PHC abzustimmen.
Ausführungsform 24. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei das erste und zweite Netzwerkelement in einer Rücken-zu-Rücken-Konfiguration verbunden sind.
Ausführungsform 25. Das Datenzentrum nach einer vorhergehenden Ausführungsform, wobei das erste und zweite Netzwerkelement in einer Ringtopologie verbunden sind.

Jedes Merkmal eines Aspekts oder einer Ausführungsform kann auf andere Aspekte oder Ausführungsformen in jeder passenden Kombination angewandt werden. Insbesondere kann jedes Merkmal eines Verfahrensaspekts oder einer Ausführungsform an einen Geräteaspekt oder eine Ausführungsform angewandt werden und umgekehrt.
Figurenliste

1 illustriert eine HW(Hardware)-Architektur, bei der aus der Symbolrate extrahierte Daten für Abstimmungen an dem PHC verwendet werden können.
2 ist ein SyncE-Systemlevelbild.
3 ist eine Ausführungsform, die auf existierende oder ältere HW anwendbar ist, ohne Platinenmodifikation, die das Einsetzen eines Taktsynchronisators auf der Platine beinhaltet.
4 ist eine beispielhafte Implementierung der Ausführungsform von 1, die typischerweise einen Paketzeitstempelungspfad, durch den PHC, einschließt.
5 ist eine vereinfachte Blockbildillustration der Time-Source-Selection-Funktionalität (Zeitquellenauswahlfunktionalität), die in Übereinstimmung mit einer Ausführungsform aufgebaut und funktionsfähig ist, welche einen Netzwerkport, der eine RX-Symbolrate aufweist, die einem Partner bekannt ist, aus mehreren Netzwerkports, die eine RX-Symbolrate aufweisen, die dem Partner bekannt ist, aus der der Partner die Netzwerk-Peer-Oszillatorfrequenz extrahieren wird, auswählt. 6 illustriert ein System, das mehrere PHCs bedient.
7a, 7b und 7c zeigen jeweils Graphen, die ein typisches Verhalten der HW-UTC-Zeit unter Verwendung verschiedener Synchronisierungsverfahren illustrieren.
8 ist eine schematische Blockbildansicht einer Netzwerkvorrichtung, die in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung aufgebaut und funktionsfähig ist.
9 ist eine vereinfachte Blockbildillustration eines SyncE-Baums, einschließlich einer PRC(Primary Reference Clock, primärer Referenztaktgeber)- und mehrerer EEC(Ethernet Equipment Clock, Ethernet-Gerät-Taktgeber)-Vorrichtungen. Die Pfeile geben den Zeitsteuerungsfluss an; die „Blätter“ des Baumes werden fettgedruckt gezeigt.
10 ist ein Blockbild, das eine Architektur für den Aufbau einer Ensemble-Zeit und für die Verwendung einer Ensemble-Zeit, um einen PHC und/oder einen lokalen Takt abzustimmen, veranschaulicht.
11 ist ein Blockbild, das eine Architektur für die Unterstützung der Synchronisierung eines Clusters von Netzwerkelementen veranschaulicht.
12 ist ein Blockbild, das eine Architektur für die Unterstützung der Synchronisierung eines Clusters von Netzwerkelementen unter Verwendung einer Ensemble-Zeit veranschaulicht.
13 ist ein Blockbild, das eine Vielzahl von Subnetzwerken, aus denen sich ein größeres System oder Netzwerk zusammensetzt, veranschaulicht.
14 ist ein Blockbild, das ein illustratives Mobilfunknetzwerk veranschaulicht, das eine Anzahl von Subnetzwerken einschließen kann, die die Synchronisierung zwischen Netzwerkelementen von diesen unterstützen.

DETAILLIERTE BESCHREIBUNG BESTIMMTER AUSFÜHRUNGSFORMEN
Synchrones Ethernet, auch SyncE, ist ein Standard für eine Rechnernetzwerkanordnung, die verwendet werden kann, um den Transfer von Taktsignalen über die physikalische Schicht des Ethernets zu ermöglichen. Synchrones Ethernet wird zum Beispiel in dem folgenden https-Link beschrieben: albedotelecom.com/src/lib/WP-SynE-explained.pdf. Bei SyncE können Synchronisierungs- und Transportnetzwerke teilweise gemischt sein, z. B. falls einige Netzwerkelemente Daten übertragen und außerdem Taktsignale an andere Netzwerkelemente verteilen. Netzwerke mit SyncE können unterschiedliche Topologien aufweisen, wie etwa am aller typischsten Baum/Bäume- und/oder Wald/Wälder- oder als nicht einschränkendes Beispiel Ring- oder Vermaschte-Topologien. In einem Netzwerk weist eine SyncE-Takthierarchie typischerweise eine „Baum“-Topologie" oder eine „Wald“-Topologie, einschließlich einer disjunkten Vereinigung von Bäumen, auf. Die SyncE-Takthierarchie beruht typischerweise auf einem Referenztakt (auch Mastertakt), der an „Slave-“ oder Nachfolgetakte verteilt werden kann.
IEEE Std 1588™-2008 (1588v2) ist ein Standard, der das Präzisionszeitprotokoll (Precision Time Protocol, PTP) definiert, das verwendet werden kann, um Frequenz, Phase und Zeit über paketbasierte Netzwerke zu verteilen.
Taktsynchronisierung, die für Rechenmaschinen, die PTP-Clients aufweisen, nützlich ist, wird in der publizierten US-Anmeldung 2020/0162234 nach Almog et al. beschrieben.
Taktsynchronisatortechnologie (wie etwa als nicht einschränkendes Beispiel TI-BAW - Texas Instruments Bulk-Acoustic-Wave-Technologie) ermöglicht extrem jitterarme Takte für Hochgeschwindigkeitsnetzwerke, z. B. wie in der folgenden Online-Informationsschrift beschrieben:

ti.com/lit/wp/snoaa34/snoaa34.pdf'?ts=1630651534227&ref url=https%253A%252F%252Fww w. google. com%252F.

Zeitsynchronisierung und Frequenzsynchronisierung (auch Syntonisierung) bei Netzwerkvorrichtungen (z. B. verbunden über Ethernet oder einem anderen passenden Netzwerk) können in vielen Netzwerkanwendungen verwendet werden. Eine Anwendung für die Verwendung eines synchronisierten Taktwertes ist das Messen der Latenz zwischen zwei Vorrichtungen. Falls die Takte nicht synchronisiert sind, wird die resultierende Latenzmessung ungenau sein.
In Anbetracht des Vorstehenden wurden zwei Standards entwickelt: (a) PTP (Precision Time Protocol, Präzisionszeitprotokoll) und (b) SyncE (Synchronous Ethernet, synchrones Ethernet). PTP ist ein Standard, der sich mit Taktsynchronisierung beschäftigt, während SyncE ein Standard ist, um die PTP-Stabilität zu steigern und den Quarzoszillator (Crystal Oscillator, XO) zu disziplinieren.
PTP stellt ein Protokoll bereit, das die Hostzeit und Frequenz mit einem externen Takt (einem sogenannten PTP-Master) abgleicht. Die Verteilung von Zeit und Frequenz über das Netzwerk erfolgt durch Übertragen von zeitgestempelten Paketen. Bei Verwendung von PTP muss die Abstimmung der lokalen Taktfrequenz nicht die Verwendung einer physikalischen Änderung der Oszillatorfrequenz (z. B. eine analoge Implementierung) beinhalten; es kann einen lokalen Oszillator mit fester Frequenz verwenden, das Verhältnis von PTP-Master- und lokalen Raten errechnen und den festen lokalen Takt mit diesem Verhältnis multiplizieren (z. B. eine digitale Implementierung).
SyncE ist ein International-Telecommunication-Union-Telecommunication(ITU-T)-Standardization-Sector-Standard für eine Rechnernetzwerkanordnung, die den Transfer von Taktsignalen über die physikalische Schicht des Ethernets ermöglicht. Insbesondere ermöglicht SyncE eine Taktsynchronisierung innerhalb eines Netzwerks mit Bezug auf eine SyncE-Masterfrequenzquelle. Jedes Netzwerkelement (z. B. ein Schalter, eine Netzwerkschnittstellenkarte (NIC) oder ein Router) muss den Mastertakt aus Hochgeschwindigkeitsdaten regenerieren und den regenerierten Mastertakt für seine Datenübertragung auf eine Weise verwenden, dass sich der Mastertakt über das ganze Netzwerk verbreitet. Dies erfordert typischerweise eine analoge Implementierung.
Die SyncE-Synchronisierungshierarchie wird typischerweise über einen dedizierten Ethernet-Kanal (ESMC - Ethernet-Synchronization-Messaging-Channel) verwaltet. Die Nachrichten in diesem Kanal führen typischerweise Informationen bezüglich des Quelltaktes, den dieser Zeitsteuerungsfluss verbreitet. Diese Informationen, auch „Zeitsteuerungsquelleninformationen“, schließen typischerweise das Qualitätslevel (QL) des Quelltaktes ein.
Probleme bei Verwendung der PTP-Synchronisierung ohne SyncE können Folgendes einschließen:

1. In dem Intervall zwischen Sync.-Nachrichten kann der lokale Oszillator driften, was in einem Zeitoffset zwischen der Vorrichtung und dem PTP-Master resultiert.
2. Während des Austausches von Sync.-Nachrichten kann der lokale Oszillator driften. Falls die Vorrichtung und der Master nicht während des Austausches von Sync.-Nachrichten syntonisiert werden, wird die PTP-Synchronisierung weniger genau sein.
3. Typischerweise wird, falls PTP-Nachrichten nicht verfügbar sind (z. B. PTP-Holdover), die Vorrichtung schnell nicht mehr synchron sein.

Dies kann verbessert werden durch (a) Erhöhen der Rate der Sync.-Nachrichten auf Kosten von Netzwerkressourcen und/oder (b) durch Verwendung eines besseren oder kostspieligeren lokalen Oszillators.
Die Ausführungsformen hierin sind kostengünstig und erfordern keine Netzwerklast. Darüber hinaus kann typischerweise, wenn SyncE verwendet wird, jede SyncE-Vorrichtung dedizierte kostspielige HW benötigen, wie etwa einen Jitter-Dämpfer-PLL, um der SyncE-Vorrichtung zu erlauben, die Masterfrequenz über das ganze Netzwerk unter Verwendung von Datenübertragung zu verbreiten. Im Gegensatz dazu kann die Anwendung von hierin beschriebenen Ausführungsformen für Blätter in dem SyncE-Baum (z. B. der Baum von 9) eine ähnliche Performance bei niedrigeren Kosten liefern, selbst bei Verwendung von älteren Geräten.
Im Gegensatz dazu verhindert dies, falls HW-Platinenmodifikationen benötigt werden, z. B. um einen anwendungsspezifischen Taktsynchronisator auf einer Platine einzusetzen, die Anwendbarkeit für existierende Einsätze, bei denen eine Platine mit dem anwendungsspezifischen Taktsynchronisator nicht vorhanden ist.
Der Begriff „Netzwerk-Peer-Oszillatorfrequenz“ wird hierin verwendet, um sich auf die Frequenz der Oszillation eines Oszillators zu beziehen, der in einem „Netzwerk-Peer“ eingeschlossen ist; der „Netzwerk-Peer“ ist eine Netzwerkvorrichtung, die als „Peer“ einer lokalen Vorrichtung dient, da die Netzwerkvorrichtung über ein Netzwerk mit der lokalen Vorrichtung verbunden ist.
Gemäß bestimmten Ausführungsformen wird die Netzwerk-Peer-Oszillatorfrequenz aus der RX-Symbolrate extrahiert und wird die so extrahierte Netzwerk-Peer-Oszillatorfrequenz verwendet, um die Frequenz von mindestens einem Netzwerkvorrichtungs-PHC (PTP-Hardware-Taktgeber) abzustimmen. Es ist nachvollziehbar, dass im Gegensatz zu PTP Frequenzinformationen aus der RX-Symbolrate extrahiert werden, anstatt in Paketen, wie beim PTP, eingekapselt zu sein. Die Extrahierung und Abstimmung können in Firmware, z. B. wie hierin beschrieben, implementiert werden, alternativ kann jedoch beides (zusammen oder getrennt) oder eines auf Hardware ausgeladen werden.
Selbst wenn diese Ausführungsform der Vorrichtung (z. B. eine NIC, wie in 1 gezeigt, und ein Schalter oder eine andere passende Netzwerkvorrichtung) nicht ermöglicht, die Masterfrequenz über das ganze Netzwerk unter Verwendung von Datenübertragung zu verbreiten, ist die Ausführungsform in verschiedenen Verwendungsfällen vorteilhaft, wie etwa, aber nicht darauf beschränkt, die Folgenden:

1. Wenn die Vorrichtung der letzte Knoten in einem SyncE-Zeitsteuerungsfluss ist (ein Blatt im SyncE-Baum, z. B. wie in 9 fettgedruckt gezeigt)
2. In Abwesenheit von SyncE, wenn:
- 2a. Ein oder mehrere der Peers der Vorrichtung einen besseren Oszillator aufweisen als der lokale (eigene) Oszillator der Vorrichtung; und/oder
- 2b. Ein oder mehrere der Peers der Vorrichtung ihre lokale Taktrate nach der Referenz oder dem PTP-Master, unter Verwendung von PTP (unter Verwendung einer analogen Implementierung), syntonisiert haben; und/oder
- 2c. Eine Notwendigkeit für eine relative Syntonisierung (z. B. Syntonisierung zwischen Knoten und nicht nach einer absoluten Referenzfrequenz) in einem flachen System (zum Beispiel wenn alle Knoten mit einem Schalter verbunden sind) besteht.

7 zeigt Graphen a, b, c, die ein typisches Verhalten der HW-UTC-Zeit unter Verwendung verschiedener Synchronisierungsverfahren illustrieren. Im Graph (a) verwendet die Synchronisierung PTP. Wie gezeigt wird der Fortschritt der HW-UTC-Zeit durch den freilaufenden Takt bestimmt und auf die ideale Zeit der Referenz oder des Masters unter Verwendung von PTP-Nachrichten abgestimmt. Zwischen Nachrichten driftet daher die HW-UTC-Zeit, was zu einem Jittern rund um die ideale Zeit der Referenz oder des Masters führt. Graph (b) zeigt, dass im Fall eines Fehlers in dem PTP die HW-UTC-Zeit weiter driftet. Graph (c) zeigt eine Synchronisierung, die sowohl PTP als auch SyncE (oder PTP- und PHC-Frequenzabstimmungen basierend auf RX-Symbolrate) verwendet. Die Frequenz der HW-UTC-Zeit ist zwischen PTP-Nachrichten stabil, d. h. weniger jittrig.
1 illustriert eine HW-Architektur, bei der aus der Symbolrate extrahierte Daten für Abstimmungen an dem PHC verwendet werden können, wie durch den Pfeil von dem Controller und dem PHC in 1 angegeben.
Zum Beispiel können die RX-Frequenz und TX-Frequenz (wobei sich RX und TX hierin jeweils auf den Empfang durch die lokale Vorrichtung , auf der die Ausführungsformen hierin implementiert werden können (wie etwa die in 1-6 illustrierte NIC, als nicht einschränkendes Beispiel, oder eine andere passende Netzwerkvorrichtung) und die Übertragung durch die lokale Vorrichtung, z. B. von/an den/die Link-Partner der lokalen Vorrichtung beziehen) aus der physikalischen Schicht (z. B. der physikalischen Schicht des Ethernets, über die SyncE Taktsignale transferiert) extrahiert werden. Danach kann, basierend auf RX-TX-Frequenzverhältnis und/oder RX-PHC-Frequenzverhältnis, die PHC-Aktualisierungsrate aktualisiert werden. Typischerweise wird somit der interne digitale Phasenregelkreis (DPLL), der innerhalb des PHC der lokalen Netzwerkvorrichtung (z. B. der von 1) liegt und möglicherweise für das Umsetzen der nativen Frequenz in aufeinanderfolgende PHC-Zeitaktualisierungsbefehle verantwortlich ist, aktualisiert.
Der Begriff „DPLL“, wie hierin verwendet, kann ersetzt werden durch eine Referenz auf ein Steuerungssystem, das ein Ausgangssignal generiert, dessen Phase auf die Phase eines Eingangssignals bezogen ist, oder eine passende Vorrichtung, die erlaubt, dass eine Änderungsrate oder Taktfrequenz mit Bezug auf (z. B. errechnet in Echtzeit bezogen auf) eine Originalrate oder -frequenz eines Vorrichtungstaktgebers, oder eine passende Hardware, die den PHC aktualisiert und/oder die PHCs aktualisiert und/oder eine interne Taktfrequenz auf eine PHC-Aktualisierungsfrequenz umsetzt, ausgedrückt wird, wobei der PHC selbst dann typischerweise dementsprechend aktualisiert wird.
Ein Beispiel eines digitalen Phasenregelkreises wird im US-Patent Nr. 11,070,214 nach Franck et al. beschrieben.
Ein „Link" ist etwas, das eine Datenkommunikation zwischen Netzwerkelementen (auch Netzelementen) oder Knoten bereitstellt. Ein Link-Partner ist ein Netzelement, auch Peer, auch Netzwerkknoten, auch Netzwerkvorrichtung auf der anderen Seite des Kabels, z. B. wie in 1 und 4 gezeigt, das ein SyncE sein kann oder nicht.
Eine mögliche SW-HW/FW-Schnittstelle ist ein „Set-Status“-Befehl, der der HW mitteilt, einen ihrer Netzwerkports zu verfolgen oder zu ignorieren und beispielsweise einen internen Takt mit Standardkonfiguration zu verwenden.
Eine mögliche Ergänzung einer solchen SW-HW/FW-Schnittstelle ist der Übergang zu einem „Holdover-Zustand“, nachdem ein Netzwerkknoten einen Link-Partner mit hoher Genauigkeit (einen Partner, dessen Takt eine höhere Genauigkeit aufweist als der Netzwerkknoten selbst) verliert. Dies erlaubt, vergangene Informationen bezüglich der eingehenden Rate zu verwenden, um genauer zu sein als die Standardkonfiguration des Systems.
Allgemein wird jeder PHC typischerweise von einer spezifischen Softwareentität, wie etwa beispielsweise einem Container, einem Prozess oder einer virtuellen Maschine, kontrolliert. Somit werden diese, falls eine Netzwerkvorrichtung, z. B. NIC, n PHCs aufweist, jeweils von n Softwareentitäten kontrolliert. Weiterhin mit Bezug auf 1 ist es nachvollziehbar, dass gemäß bestimmten Ausführungsformen eine gegebene Softwareentität oder ein Daemon, die/der einen gegebenen PHC kontrolliert, bestimmt oder auswählt, ob eine Phasenabstimmung (z. B. durch Aktivieren oder Initiieren des Daemons) durchgeführt werden soll und/oder ob eine Frequenzabstimmung (z. B. durch Aktivieren oder Initiieren eines- Firmware- oder eines Hardwarecontrollers, womit die hierin beschriebene Frequenzabstimmung implementiert wird) durchgeführt werden soll. Diese Entscheidung kann eine Bestimmung, z. B. durch die gegebene Softwareentität, ob in Übereinstimmung mit empfangenen PTP-Nachrichten agiert werden soll oder nicht, einschließen.
Es ist nachvollziehbar, dass das Präzisionszeitprotokoll (PTP) Frequenz, Phase und Zeit über paketbasierte Netzwerke verteilt.
Der Begriff „Daemon“, z. B. in einem Multitasking-Rechnerbetriebssystem, soll ein Rechnerprogramm einschließen, das als Hintergrundprozess läuft anstatt direkt von einem interaktiven Benutzer gesteuert zu werden. Ein Daemon kann zum Beispiel während der Hochlaufzeit gestartet werden und kann eine Aufgabe/Aufgaben während geplanter Zeiten und/oder reagierend auf eine bestimmte Netzwerkanforderung/en und/oder Hardwareaktivität und/oder andere Programme durchführen.
Die Architektur des PHC von 1 kann wie in einer der Ausführungsformen in der parallelen United-States-Patentanmeldung 20200162234 nach Almog et al. oder in dem im gemeinsamen Besitz stehenden US-Patent Nr. 10,778,406 nach Gaist et al. beschrieben sein.
Es ist nachvollziehbar, dass eine Extrahierung der Netzwerk-Peer-Oszillatorfrequenz aus der RX-Symbolrate in einem passenden Typ eines physikalischen Netzwerks (wie etwa als nicht einschränkendes Beispiel Ethernet, InfiniBand, PCIe, NVlink) implementiert werden kann. Die Extrahierung kann in in FW oder HW, z. B. um SW- zu FW/HW-Schnittstellenjitter zu vermeiden, implementiert werden.
Es ist nachvollziehbar, dass die RX-Symbolrate typischerweise eine Anzahl von Symbolen umfasst, die ein Controller einer lokalen Netzwerkvorrichtung pro Zeiteinheit, z. B. 1 Sekunde, empfängt, wobei die Zeiteinheit gemäß des Controllertaktgebers der lokalen Netzwerkvorrichtung gemessen wird.
Alternativ kann die Frequenzdifferenz unter Verwendung der Differenz zwischen der Anzahl von empfangenen und auf demselben Weg übertragenen Symbolen gemessen werden. Da die Anzahl von übertragenen Symbolen/Sek. ein Resultat der lokalen Frequenz, multipliziert mit einem konstanten Wert, ist, kann gefolgert werden, dass das Empfangen von mehr Symbolen als übertragenen im gleichen Zeitraum angibt, dass die lokale Frequenz langsamer als die Nennfrequenz ist und die lokale Frequenz erhöht werden sollte. Andererseits kann gefolgert werden, dass das Empfangen von weniger Symbolen als übertragenen im gleichen Zeitraum angibt, dass die lokale Frequenz schneller als die Nennfrequenz ist und die lokale Frequenz gesenkt werden sollte. Dies gilt, wenn der PHC und die SerDes-PHY von derselben Taktquelle gespeist werden. Die Extrahierung und/oder Verwendung der Netzwerk-Peer-Oszillatorfrequenz, die so extrahiert wurde, um die Frequenz von mindestens einem Netzwerkvorrichtungs-PHC abzustimmen, kann/können periodisch erfolgen. Zum Beispiel können Dutzende von Korrekturen, oder Hunderte, oder Tausende, oder mehr, oder weniger, pro Sekunde vorgenommen werden.
Das periodische Extrahieren der Netzwerk-Peer-Oszillatorfrequenz und/oder Verwenden der Netzwerk-Peer-Oszillatorfrequenz, um die PHC-Frequenz abzustimmen, kann an einem gegebenen Link-Port durch eine SW-Komponente ausgelöst werden, die zum Beispiel eine Nachricht bereitstellen kann, die die Verfügbarkeit eines Takt-Link-Partners angeben kann, dessen Genauigkeit höher als der lokale Takt ist (und typischerweise höher als mindestens ein anderer oder die meisten oder alle anderen Link-Partner, die die Netzwerkvorrichtung aufweisen kann). Diese Nachricht kann den hierin gezeigten und beschriebenen „Extrahieren und Verwenden“-Mechanismus an dem gegebenen Link-Port auslösen.
2 ist ein SyncE-Systemlevelbild. Wie gezeigt, ist die NIC mit einem PRC (Primary Reference Clock, primärer Referenztaktgeber, z. B. wie in ITU-T G. 811 definiert, oder SyncE-Hochqualitäts-SRC-Taktgeber über die Netzwerkports verbunden; es ist nachvollziehbar, dass das Taktqualitätslevel wie in ITU-G.781 definiert sein kann. Eine digitale Logik 320 misst die Wanderdifferenz zwischen der Übertragungssymbolrate und der Rate von Symbolen, die von dem SyncE-SRC-Link empfangen werden. Die Wanderdifferenz wird in Frequenzabstimmungsbefehle 202 an die externe Komponente auf der Taktsynchronisatorplatine 210 „umgesetzt“. Diese Platine 210 kann eine Feineinstellung des Referenztaktgebers 280 vornehmen. Änderungen an dem Referenztaktgeber werden typischerweise in Änderungen an der TX-Symbolrate, z. B. durch APLL+DPLL 310, umgesetzt. Die digitale Messung 320 schließt dann den Regelkreis mit der Sync.-Wander. Der Referenztaktgeber stimmt typischerweise die Frequenz des PHC 350 ab und nähert die PHC-Frequenz an den Nennwert, unter der Annahme, dass der SRC-Taktgeber in der Sync. besser ist als der Oszillator der lokalen Vorrichtung (auch der „lokale Oszillator“), z. B. unter der Annahme, dass die Oszillatorqualität des Link-Partners der lokalen Vorrichtung besser ist als die Qualität des lokalen Oszillators.
Reagierend muss die PTP-SW keine Frequenzabstimmungen 420 an den DPLL 301 des PHC 350 senden; die PTP-SW kann stattdessen lediglich Zeitabstimmungen 410 senden. Dies liefert ein generiertes SyncE-Signal (10) für den nächsten Inline-Netzwerkknoten und/oder einen genaueren PHC, dessen Frequenz stabilisiert wurde.
Beispielhafte Systeme, die mindestens einige der obigen Operationen durchführen, werden in dem US-Patent Nr. 10,778,406 nach Gaist et al. präsentiert.
Es ist nachvollziehbar, dass möglicherweise HW-Platinenmodifikationen nötig sind, wobei spezifisch der Taktsynchronisator 210 auf der Platine zwischen dem XO (z. B. Quarzoszillator) und der NIC eingesetzt wird, wodurch die Produkt-SKUs (Stock Keeping Units, Bestandseinheiten) des Produkts verdoppelt werden und möglicherweise die Anwendbarkeit auf existierende Einsätze, bei denen keine Platine mit Taktsynchronisator 210 vorhanden ist, verhindert wird.
3 ist eine Ausführungsform, die auf existierende oder ältere HW anwendbar ist, ohne Platinenmodifikation, die das Einsetzen eines Taktsynchronisators auf der Platine beinhaltet. In dieser Ausführungsform, wenn ein Generieren eines SyncE-Signals keine Anforderung darstellt, nutzt das System die Tatsache, dass ein stabiles Frequenzsignal (z. B. SyncE-Signal) eintrifft, und kann (z. B. falls das eingehende Quellen-SyncE-Signal, in 3 repräsentiert durch einen Süden-nach-Norden-Pfeil, verrauscht ist) Filtern und/oder Messungen verwenden (z. B. als nicht einschränkendes Beispiel entweder lineares oder nichtlineares Filtern, wie etwa, aber nicht darauf beschränkt, Durchschnitts(Mittel)- und/oder Median- und/oder Tiefpass- und/oder Bandpassfiltern), um erforderlichenfalls den lokalen DPLL zu disziplinieren, der wiederum den lokalen PHC steuert. Dies liefert einen stabileren PHC-Takt, sodass der PTP-Softwarestapel (z. B. Daemon) nicht mit dem Durchführen von Frequenzabstimmungen belastet werden muss.
Der Filter kann als Teil der FW-Logik (z. B. „FW-Controller“-Block von 4) implementiert werden oder kann dedizierte HW, falls eine solche existiert, verwenden. Übliche Filter, die verwendet werden können, sind Durchschnittsfilter, Medianfilter, Tiefpassfilter, Bandpassfilter.
In der Ausführungsform von 3 werden die Frequenzabstimmungen 202 von der digitalen Messbeschaltung 320 an den DPLL 301 gesendet, während in der Ausführungsform von 2 die Frequenzabstimmungen an den Taktsynchronisator 210 gesendet werden. Die Operationen der digitalen Messbeschaltung 320, z. B. in 2 und 3, befreien den PTP-Softwarestapel (z. B. Daemon) von der Last des Durchführens von Frequenzabstimmungen.
4 ist eine beispielhafte Implementierung der Ausführungsform von 1, die typischerweise einen Paketzeitstempelungspfad, durch den PHC, einschließt. Es ist nachvollziehbar, dass der PTP-Daemon einen PTP-SW-Stapel umfassen kann, der Performance-Zähler in dem Netzwerkport oder in der physikalischen Schicht sein kann und die SW-Schnittstelle von 4 einen Referenzzeitquellenauswahlalgorithmus, z. B. wie hierin beschrieben, einschließen kann, um dadurch den internen Controller zu steuern, der die Frequenz des PHC-DPLL abstimmt.
In 4 wird die Frequenz-Diff. (typischerweise die Differenz zwischen (a) der Taktfrequenz eines PHC, dessen Netzwerkelement konfiguriert ist, um eine Ausführungsform der vorliegenden Erfindung zu verwenden, und der von dem Link-Partner empfangenen RX-Symbolrate; oder (b) der TX-Symbolrate des Netzwerkelements, das konfiguriert ist, um eine Ausführungsform der vorliegenden Erfindung zu verwenden, und der von dem Link-Partner empfangenen RX-Symbolrate), gemessen, z. B. durch die digitale Messbeschaltung 320 von 2, 3. Alternativ kann ein Standard, der sich von der Taktfrequenz des Link-Partners unterscheidet, verwendet werden, um die Taktfrequenz des PHC zu messen, dessen Netzwerkvorrichtung konfiguriert ist, um eine Ausführungsform der vorliegenden Erfindung zu verwenden, um dadurch zu bestimmen, ob die Taktfrequenz f des PHC, dessen Netzwerkvorrichtung konfiguriert ist, um eine Ausführungsform der vorliegenden Erfindung zu verwenden, die gleiche wie der Standard ist oder höher als der Standard ist, wobei in diesem Fall f auf den Standard reduziert werden kann, oder niedriger ist, wobei in diesem Fall f auf den Standard erhöht werden kann. Demgemäß wird der PHC-DPLL von 4 (der mit dem DPLL 301 in 2, 3 identisch sein kann) typischerweise aktualisiert. Es ist nachvollziehbar, dass die Konfiguration des digitalen PLL (DPLL) die Frequenz des PHC bestimmt, die wiederum von dem Kerntakt abgeleitet wird. Typischerweise ist die PHC-Frequenz die Kerntaktfrequenz multipliziert mit einem Faktor (Skalar), der aus der aktuellen Konfiguration des DPLL extrahiert wird. Die Zeitquellenauswahl-SW (Time-Source-Selection-SW) weiß typischerweise, dass der Firmware-/Hardwarecontroller, der die Frequenzabstimmung implementiert, zu aktivieren ist, da z. B. die Zeitquellenauswahl-SW an einer gegebenen Netzwerkvorrichtung Pakete mit Daten über Taktqualitätslevel von Link-Partnern empfangen kann; diese Daten können angeben, ob Taktgenauigkeiten von Partnern hoch oder niedrig sind, z. B. relativ zueinander und/oder relativ zu dem Takt der gegebenen Netzwerkvorrichtung. Die Zeitquellenauswahl-SW kann alternativ oder zusätzlich die gegebene Netzwerkvorrichtung hinsichtlich des Qualitätslevels des lokalen Taktes abfragen. Falls es einen/mehrere Link-Partner mit besserer (z. B. höherer Genauigkeit) Taktqualität gibt, wird sich die gegebene Netzwerkvorrichtung mit einem dieser Link-Partner koppeln, typischerweise mit dem besten verfügbaren Partner (der Partner mit dem genauestens Takt), und/oder beginnen, diese Frequenz zu verwenden (z. B. Verwendung des „Set-Status“). Es ist nachvollziehbar, dass 4 eine HW/FW-Ausführungsform illustriert, die einen Steuerkreisansatz verwendet. Wie gezeigt, wird eine Frequenzdifferenz, z. B. zwischen der RX-Symbolrate und TX-Symbolrate oder zwischen der PHC-Frequenz und TX-Symbolrate) periodisch von der FW der Netzwerkvorrichtung gemessen und wird der PHC-DPLL dementsprechend aktualisiert. Zum Beispiel können alle oder beliebige Teilsätze der folgenden Operationen (z. B. durch den Firmwarecontroller von 4), in jeder geeigneten Reihenfolge durchgeführt werden, z. B. wie folgt:

Operation a: Einrichten oder Bereitstellen einer Mess-HW für neue periodische Frequenz-Diff.-Messung (z. B. Zurücksetzen von Performance-Zähler der physikalischen Schicht).
Operation b: Starten der Messung und Warten über eine Periode eines vordefinierten Fensters.
Operation c: Nachdem eine Zeit zurückgelegt wurde, Daten bezüglich RX- und TX-Symbol während des Messfensters sammeln und Frequenzdifferenzen berechnen (z. B. 10.235 PPB).
Operation d: Aktualisieren von PHC-DPLL gemäß der gemessenen PPB-Diff.
Operation e: Den Prozess durch Zurückkehren auf die obige Operation mindestens einmal wiederholen, z. B. periodisch, z. B. kontinuierlich. Die Ausführungsform von 4 kann mit einem aktiven PTP (das PTP-Daemon-Frequenzaktualisierungen bereitstellt) coexistieren. Eine DPLL-Implementierung zum Konvertieren des Kerntaktes auf PHC kann Zähler- und Nennerparameter aufweisen, die die aktuelle Frequenz bestimmen können. Einer dieser Parameter, z. B. der Zähler, kann den PTP-Daemon-Frequenzaktualisierungen zugewiesen werden und der andere Parameter kann dem Implementieren der Ausführungsform von 4 zugewiesen werden. Dies würde die kumulierte Drift zwischen aufeinanderfolgenden PTP-Aktualisierungen reduzieren.

Alternativ kann ein Regelkreisansatz verwendet werden, bei dem ein Steuerungsmechanismus kumulierte RX-Symbole und PHC-Zeit synchron hält.
Bei dem Steuerkreisansatz wird typischerweise kein Feedback bezüglich der Abstimmung der PHC-Frequenz, zwischen RX und TX (oder zwischen der RX-Rate und TX-Rate), generiert. Im Gegensatz zu dem Regelkreisansatz wird PHC typischerweise direkt gemessen, anstatt (oder in Ergänzung zu) dem Messen von TX (oder der TX-Rate); dies liefert ein Feedback bezüglich der Abstimmung der PHC-Frequenz. Typischerweise weist diese „Regelkreis“-Implementierung eine Zeitvorgabe auf, die auf dem lokalen PHC zurückgelegt wurde, beginnend mit der anfänglichen Zeit, zu der sich der lokale PHC mit dem aktuellen Link-Partner koppelt. Gemäß einer möglichen Ausführungsform kann ein PD-Controller (PD = Proportional-Differenzial) bereitgestellt werden, wobei der Kreis der lokalen Vorrichtung dann möglicherweise versucht, mit der gleichen Geschwindigkeit wie der Link-Partner zu laufen, aber gleichzeitig versucht, die gleiche Distanz zurückzulegen, wobei die Distanz zur Zeit proportional ist (z. B. Zeit * Konstante1). Bei einer gegebenen Link-Geschwindigkeit kann die Distanz als Zahl von Bits * Konstante2 == Zahl von „Symbolen“ * Konstante3 errechnet werden. Die Zeit/Bits/Symbole, die auf dem Link-Partner zurückgelegt wurden, können extrahiert oder bestimmt oder geschätzt werden, z. B. durch Kumulieren von Bits/ „Symbolen" auf der RX-Seite und Versuchen, diesen Wert auf der TX-/lokalen Seite zu „verfolgen“.
Zum Beispiel können RX-Symbole in Zeit umgesetzt werden, wodurch ein Ausgabeskalar geliefert wird, der mit der Zeit verglichen werden kann, die auf dem PHC verstrichen ist. Geeignete Parameter (wie etwa als nicht einschränkendes Beispiel (1) in Zeit umgesetzte RX-Symbole; und/oder (2) die Zeit, die auf dem PHC verstrichen ist, und/oder (3) ob Filtern oder nicht, um den lokalen DPLL zu disziplinieren, und/oder falls ja, welcher Filter verwendet werden soll) können dem HW/FW-Controller hinzugefügt (z. B. als Eingabe an den Controller bereitgestellt) werden, um sicherzustellen, dass die Controlleroperation diese Parameter berücksichtigt. Es ist nachvollziehbar, dass PID-Controller (PID = Proportional-Integral-Differenzial) ein geeigneter Typ von programmierbaren Controllern sind, die solche Parameter für ihre interne(n) Logik/Berechnungen verwenden können. Als nicht beschränkendes Beispiel würden PI(Proportional-Integral)- und PD (Proportional-Differenzial)-Controller geeignet sein, um einen Regelkreis, z. B. wie hierin beschrieben, aufrechtzuerhalten.
Gemäß bestimmten Ausführungsformen wird die RX-Symbolrate innerhalb der physikalischen Schicht des Netzwerkports gemessen oder extrahiert z. B. mittels „Perf-Zähler/n“ (Performance-Zählern in der Netzwerkvorrichtung, z. B. NIC, wobei sich Performance-Zähler allgemein auf Code beziehen, der, in Software, Messeereignisse überwacht und/oder zählt -- wie etwa Empfang von Symbolen von der Netzwerkvorrichtung, die von einem Link-Partner der Netzwerkvorrichtung gesendet wurden).
Typischerweise gibt es in der Ausführungsform von 4 nur Zeitabstimmungen in dem PTP; diese werden typischerweise dem PHC von dem PTP-Daemon bereitgestellt. Es gibt typischerweise Frequenzabstimmungen, die dem PHC-DPLL von dem FW-Controller bereitgestellt werden, z. B. wie bei jeder hierin beschriebenen Ausführungsform. Bei normalem Verhalten oder herkömmlicherweise sendet der PTP-Daemon außerdem (typischerweise kleine) Frequenzabstimmungen. Im Gegensatz dazu sind in der Ausführungsform von 4 diese Frequenzabstimmungen von dem PTP-Daemon nicht mehr notwendig.
Jede der illustrierten Ausführungsformen kann Zeitquellenauswahlsoftware einschließen, die als Softwareschnittstelle zu dem Controller dient, wie in 4 beispielhaft dargestellt, in der tatsächlich ein „Softwareschnittstellen“-Block gezeigt wird. Der Zeitquellenauswahl-SW-Block wählt typischerweise einen Netzwerkport, der eine RX-Symbolrate aufweist, die einem Partner bekannt ist, aus mehreren Netzwerkports, die eine RX-Symbolrate aufweisen, die dem Partner bekannt ist, aus der der Partner die Netzwerk-Peer-Oszillatorfrequenz extrahieren kann, aus. Eine beispielhafte Implementierung dieses Zeitquellenauswahlblocks wird in 5 gezeigt, der mit einer „NIC“, wie etwa der NIC von 4, oder einer anderen passenden Netzwerkvorrichtung eine Schnittstelle bildet. Die „Set-Status (Referenzquelle)“- und „Lokale-Takt-Qualität“-Pfeile von 5 werden zwecks Einfachheit in 4 als einzelner Pfeil dargestellt, da beide auf die Netzwerkvorrichtung, typischerweise auf die FW-gerichtet sind. Der „Senden\Empfangen Verwaltungspakete“-Pfeil kann auf den Netzwerkport und den Netzwerklink gerichtet sein, typischerweise, wie herkömmlich, unter Verwendung des Netzwerkstapels der Vorrichtung.
Falls zum Beispiel die SW von 5 einen bestimmten Port x auswählt, bleibt der relevante Partner typischerweise mit dem Port x gekoppelt, bis die SW etwas anderes entscheidet (entscheidet, den Port zu ändern), z. B. weil eine Nachricht über Port y empfangen wird, die ein höheres QL angibt, wobei es möglicherweise eine Entscheidung gibt, zu beginnen, Port y zu folgen, oder vielleicht weil eine Änderung des Qualitätslevels (auch QL) von Port x möglicherweise darin resultieren kann, dass das Qualitätslevel von Port x niedriger ist als das lokale QL, wobei es möglicherweise eine Entscheidung gibt, auf Holdover zu gehen.
Allgemeiner illustriert 5 eine SW-implementierte Architektur, die allein oder als beispielhafte Implementierung für die hierin gezeigte und beschriebene Zeitquellenauswahlfunktionalität bereitgestellt werden kann. Die Architektur von 5 schließt typischerweise Zeitbereitsteller (Time Provider/s), z. B. mindestens eine SW-Entität (typischerweise mehrere solcher Entitäten), die mit einem Port assoziiert sind und ausgewählt sind, um die Zeitsteuerungsquelle zu sein, und einen Wähler ein. Eine derartige Softwareentität kann eine Klasse oder Struktur einschließen, z. B. wie herkömmlich bei objektorientiertem Programmieren.
Jeder Zeitbereitsteller (oder „Taktbereitsteller“) umfasst typischerweise ein Netzwerkmodul, das konfiguriert ist, um alle oder einen Teilsatz der folgenden Operationen in einer geeigneten Reihenfolge durchzuführen, z. B. wie folgt:

Operation a: Öffnen eines Sockets für Verwaltungspakete auf dem mit Zeitbereitsteller assoziierten Port. Die Verwaltungspakete können zum Beispiel ESMC PDUs (Ethernet-Synchronization-Messaging-Channel- Protokolldateneinheiten) sein, wie definiert in ITU-T G.8264, ein Spezifikationsdokument, das von der International Telegraph Union (ITU)'s Telecommunication Standardization Sector (ITU-T) erstellt wurde und das online z. B. unter dem https-www-Link itu.int/rec/T-REC-G.8264 erhältlich ist und den Ethernet-Synchronization-Messaging-Channel (ESMC, Ethernetsynchronisierungsnachrichtenkanal) spezifiziert. Oder die Verwaltungspakete können ein beliebiges Paket umfassen, das Informationen bezüglich Qualität/en eines/von Nachbartaktes/Nachbartakten führt.
Operation b: Senden von Verwaltungspaketen, um Nachbarn bezüglich Qualität des lokalen Taktes zu aktualisieren.
Operation c: Parsen von empfangenen Verwaltungspaketen, um aus diesen die Zeitsteuerungsquelleninformationen zu extrahieren. Bei einer Änderung der Zeitsteuerungsquelleninformationen (die in den empfangenen und geparsten Paketen identifizierte Zeitsteuerungsquelle unterscheidet sich von der aktuellen Zeitsteuerungsquelle ) initiiert das Netzwerkmodul den Wähler, um zu bestimmen, ob die Referenzzeitsteuerungsquelle (die Quelle für das Signal, dem gefolgt werden soll) geändert werden soll oder nicht, und stattdessen eine neue Referenz, oder ein neuer Master, ausgewählt werden soll oder nicht.

Der Wähler kann einen Auswahlalgorithmus umfassen, der auf einem Hardwareprozessor läuft, um die beste Zeitsteuerungsquelle aus dem Satz verfügbarer Zeitsteuerungsquellen, z. B. dem lokalen Takt und einem beliebigen Zeitbereitsteller, auszuwählen. Der Auswahlalgorithmus vergleicht typischerweise die Qualität (und möglicherweise andere relevante Merkmale, wie manuell konfigurierbare Priorität) von mehreren Zeitsteuerungsquellen, z. B. allen Zeitstörungsquellen, in dem Satz Zeitsteuerungsquellen, die für die lokale Vorrichtung verfügbar sind (z. B. bei Kommunikation mit oder verlinkt mit dieser). Die Auswahlalgorithmusausgabe umfasst typischerweise einen Status und eine Referenzzeitsteuerungsquelle, die der HW-Block von 5, der die Netzwerkvorrichtung, z. B. NIC oder DPU oder Schalter, repräsentiert, verfolgen soll (z. B. als Zeitsteuerungsquelle verwenden soll, gemäß der die PHC-Frequenz abgestimmt wird). Der Begriff „Status“, wie hierin verwendet, soll eine Verfolgungs(Tracking)- oder „Holdover“- oder freilaufende Referenzzeitsteuerungsquelle oder einen Takt, der verfolgt wird (wie zum Beispiel der Takt hinter dem Link von Port 1), einschließen.
Es ist nachvollziehbar, dass, falls eine Netzwerkvorrichtung mehrere PHCs aufweist, das System hierin nur einem von diesen oder einigen oder allen dienen kann. Zum Beispiel illustriert 6 ein System, das mehrere PHCs (als Beispiel 2) bedient, anstatt lediglich einen PHC zu bedienen, wie als Beispiel in 1 gezeigt.
Es wird nun auf 8 Bezug genommen, die eine schematische Blockbildansicht einer Netzwerkvorrichtung 1100 ist, die in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung aufgebaut und funktionsfähig ist. Die Netzwerkvorrichtung 1100 umfasst eine Frequenzgenerationsbeschaltung, einschließlich eines spannungsgesteuerten Oszillators 1104 der, unter Steuerung mittels eines Controllers 1034 (der den Controller 34 von 1 umfassen kann) und unter Verwendung eines Steuerungssignals 1102, das Taktsignal generiert. Bevor der Mastertakt oder Referenztakt von der Netzwerkverwaltungsfunktion designiert wird, wird der Controller 1034 konfiguriert, um den spannungsgesteuerten Oszillator 1104 zu steuern, um ein Taktsignal mit einer geeigneten Frequenz, z. B. 156 MHz, zu generieren. Sobald der Mastertakt von der Netzwerkverwaltungsfunktion designiert worden ist, wird der Controller 1034 konfiguriert, um das von dem spannungsgesteuerten Oszillator 1104 generierte Taktsignal unter Verwendung des Steuerungssignals 1102 basierend auf RX-Symbolrate-TX-Symbolrate oder dem Taktdifferenzial 1040 zwischen dem regenerierten entfernten Takt (designiert als Mastertakt) und dem durch den PLL 1026 generierten lokalen Takt abzustimmen.
Die Netzwerkvorrichtung 1100 schließt ein Schalterkerndie 1012 und ein Satellitendie 1014 ein. Das Schalterkerndie 1012 schließt eine Multichipmodul(MCM)-Kernlogik 1016 und Schaltbeschaltung, um Schaltfunktionen durchzuführen, ein. Das Satellitendie 1014 schließt MCM-Satellitenlogik 1024, um Empfangs- und Übertragungsfunktionen des Schalters durchzuführen, ein. Das Satellitendie 1014 kann auch einen PLL 1026 und eine Vielzahl von Empfängern 1028 und Verbindungen zu einer Vielzahl von Ports (gezeigt) einschließen. Die Empfänger 1028 wurden individuell als 1028-1, 1028-2 und 1028-3 zwecks vereinfachter Referenz gekennzeichnet. Das Schalterkerndie 1012 und das Satellitendie 1014 sind allgemein unter Verwendung einer MCM-Zwischenverbindung 1030 verbunden.
Obwohl die Netzwerkvorrichtung 1010 mit Bezug auf einen Multi-Die-Netzwerkschalter beschrieben worden ist, können Ausführungsformen der vorliegenden Erfindung auf einem geeigneten Netzwerkschalter, der ein oder mehr Dies einschließt, oder einer geeigneten Netzwerkvorrichtung, zum Beispiel, aber nicht darauf beschränkt, ein Netzwerkrouter mit einem oder mehr Dies, implementiert werden.
Die Empfänger 1028 sind konfiguriert, um jeweilige Datenströme 1038 (gekennzeichnet 1038-1 bis 1038-3) von jeweiligen entfernten Taktquellen (nicht gezeigt) zu empfangen und (in einem Puffer 1044) zu puffern. Zwecks Einfachheit wurde nur einer der Puffer 1044 mit dem Referenzzeichen 1044 gekennzeichnet. Jeder Empfänger 1028 kann unter Verwendung geeigneter Hardware, wie etwa einem Serialisierer/Deserialisierer (SerDes), zum Beispiel, aber nicht darauf beschränkt, ein LR-SerDes-RX, implementiert werden. Die Daten in den Datenströmen 1038 treffen allgemein von den entfernten Taktquellen ohne Taktwert ein. Jeder Empfänger 1028 kann einen Takt- und Datenregenerierungsprozess (CDR, Clock and Data Recovery) 1042 einschließen, der in diesem läuft, um einen entfernten Takt aus seinem empfangenen Datenstrom (oder RX-Symbolrate) 1038 zu regenerieren, zum Beispiel basierend auf Transitionen der Daten des empfangenen Datenstroms 1038. Zwecks Einfachheit wurde nur einer des Takt- und Datenregenerierungsprozess (CDR-Prozessors) 1042 mit dem Referenzzeichen 1042 gekennzeichnet. Der CDR von jedem Empfänger 1028 kann auch ein Taktdifferenzial 1040 (gekennzeichnet 1040-1 bis 1040-3) errechnen, das eine Differenz zwischen seinem regenerierten entfernten Takt und dem lokalen Takt (generiert durch den PLL 1026) (z. B. der regenerierte entfernte Takt minus dem lokalen Takt) der Netzwerkvorrichtung 1010 ist, sodass für jeden empfangenen Datenstrom 1038 eine Differenz zwischen dem regenerierten entfernten Takt des Datenstroms 1038 und dem lokalen Takt errechnet wird Das Taktdifferenzial 1040 wird in einem Register der Netzwerkvorrichtung 1100 gespeichert. In einigen Ausführungsformen wird jedes Taktdifferenzial 40 in einem Register des Empfängers 1040, der das Taktdifferenzial 40 berechnete, gespeichert. Die Taktregenerierung kann basierend auf einem beliebigen geeigneten Prozess implementiert werden, einschließlich eines Nicht-CDRbasierten Prozessors, zum Beispiel, aber nicht darauf beschränkt, unter Verwendung eines Verzögerungsregelkreises (Delay-Locked Loop) und Übertastung des Datenstroms. Die Datenströme 1038 umfassen, abgesehen von ihrer Verwendung bei der Regenerierung der entfernten Takte, allgemein Takte zum Weiterleiten an andere Vorrichtungen in dem Netzwerk. Die Datenströme 1038 werden daher allgemein über die MCM-Zwischenverbindung 1030 an die Multichipmodul-Kernlogik 1016 weitergeleitet, verschiedene Schaltfunktionen (oder Routingfunktionen, wenn die Netzwerkvorrichtung 1010 als Router implementiert ist) durchzuführen. Die regenerierten Takte und Taktdifferenziale 1040 werden allgemein nicht an die Multichipmodul-Kernlogik 1016 über die MCM-Zwischenverbindung 1030 weitergeleitet.
Das Beispiel von 8 zeigt drei Empfänger 28. Die Anzahl von Empfängern 1028 kann eine beliebige geeignete Anzahl von Empfängern sein und ist nicht auf drei beschränkt. Das Beispiel von 1 zeigt drei Kästchen für den PLL 1026, eines als Kästchen mit durchgehender Linie und zwei als Kästchen mit gestrichelter Linie. Die drei Kästchen repräsentieren denselben PLL 1026, der zwecks Einfachheit zweimal dupliziert wurde.
8 zeigt, dass der von dem Empfänger 1028-1 empfangene Datenstrom 1038-1 einen regenerierten Takt von 3,001 GHz aufweist. Das Taktdifferenzial 1040-1 zwischen dem regenerierten Takt des empfangenen Datenstroms 1038-1 von 3,001 GHz und dem lokalen Takt von 3 GHz beträgt daher +333 PPM (z. B. der Mastertakt ist um 333 PPM schneller als der lokale Takt). Der von dem Empfänger 1028-2 empfangene Datenstrom 1038-2 weist einen regenerierten Takt von 3,002 GHz auf. Das Taktdifferenzial 1040-2 zwischen dem regenerierten Takt des empfangenen Datenstroms 1038-2 von 3,002 GHz und dem lokalen Takt von 3 GHz beträgt daher +666 PPM (z. B. der Mastertakt ist um 666 PPM schneller als der lokale Takt). Der von dem Empfänger 1028-3 empfangene Datenstrom 1038-3 weist einen regenerierten Takt von 2,999 GHz auf. Das Taktdifferenzial 1040-3 zwischen dem regenerierten Takt des empfangenen Datenstroms 1038-3 von 2,999 GHz und dem lokalen Takt von 3 GHz beträgt daher -333 PPM (z. B. der Mastertakt ist um 333 PPM langsamer als der lokale Takt).
Es ist nachvollziehbar, dass die Ausführungsformen hierin den SyncE-Standard verbessern, indem nur ein Teilsatz dessen gemacht wird, was der SyncE-Standard fordert (z. B. nicht Generieren eines SyncE-Signals in dem Ausgabesignal und optional nicht Verwenden und/oder Extrahieren des Taktes so genau wie in dem SyncE-Standard) definiert, aber Bereitstellen eines viel stabileren Frequenztaktes für eine Netzwerkvorrichtung (und/oder eines anderen vom SyncE abwesenden Wertes), z. B. durch Verwenden der extrahierten Daten von der Symbolrate für Abstimmungen am PHC, ohne Hinzufügen von Hardwareanforderungen (im Gegenteil, hierin beschriebene Ausführungsformen weisen weniger Hardwareanforderungen, auch HW-Anforderungen, bezüglich SyncE auf).
10 illustriert ein System, in dem eine Ensemble-Zeit berechnet wird und dann verwendet wird, um eines oder beides von einem PHC und einem lokalen Takt abzustimmen. In diesem Beispiel kann die Vorrichtung, wie etwa ein Schalter, einen FW/HW-Controller einschließen, der Daten von einer Vielzahl von NICs empfängt. Jede NIC (z. B. NIC1, NIC2, NIC3, ..., NICN) kann eine einmalige Übertragungssymbolrate (z. B. NIC1 Tx, NIC2 Tx, NIC3 Tx, ..., NICN Tx) aufweisen. Die Symbolrate für jede NIC kann an dem FW/HW-Controller der Vorrichtung gemessen werden.
In einigen Ausführungsformen kann der FW/HW-Controller die Frequenz von allen Peers (z. B. von jeder NIC) durch Messen von jeder Tx-Symbolrate der NIC messen. Die für jede NIC gemessene Frequenz kann verwendet werden, um eine Ensemble-Zeit zu berechnen. Anders ausgedrückt, bei zwei oder mehr Peer-Frequenzen kann der FW/HW-Controller eine Ensemble-Zeit berechnen oder bestimmen. In einigen Ausführungsformen kann eine Ensemble-Zeit einem gewichteten Durchschnitt von jeder Frequenz, die für jede NIC gemessen wird, entsprechen. Die Ensemble-Zeit kann einem gewichteten Durchschnitt von jeder Frequenz entsprechen, der basierend auf einem QL des Quarzoszillators einer NIC und/oder basierend auf einer vergangenen Performance des Quarzoszillators einer NIC gewichtet wird.
Der FW/HW-Controller kann dann die Ensemble-Zeit als Teil des Bestimmens einer nach dem lokalen Takt und/oder einem PHC vorzunehmenden Abstimmung nutzen. Um ein Beispiel zu nennen, der FW/HW-Controller kann eine Differenz zwischen dem lokalen Takt und der Ensemble-Zeit bestimmen. Die Differenz zwischen dem lokalen Takt und der Ensemble-Zeit kann die Differenz in Teile pro Million (Parts Per Million) und/oder pro Milliarde (Per Billion) und/oder pro Billion (Per Trillion) (z. B. PPM/PPB/PPT) bestimmen. Die PPM-Differenzen können dann zum Beispiel verwendet werden, um die Frequenz des lokalen Taktes und/oder des PHC der Vorrichtung abzustimmen. In einigen Ausführungsformen können Änderungen des lokalen Taktes der Vorrichtung verwendet werden, um andere Taktabstimmungen an Peers, die mit der Vorrichtung verbunden sind, zu erstellen. Mit anderen Worten, eine am lokalen Takt der Vorrichtung vorgenommene Abstimmung kann auf andere Taktänderungen im Netzwerk propagieren. In einigen Ausführungsformen können zwei oder mehr der Peer-Vorrichtungen (z. B. die NICs) einen ähnlichen oder identischen Typ eines Quarzoszillators aufweisen. Die Nutzung einer Ensemble-Zeit kann helfen, eine kostengünstige und frequenzstabile Vorrichtung zu erzielen.
Wie oben beschrieben, kann die Ensemble-Zeit basierend auf Frequenzen bestimmt werden, die von zwei oder mehr Peers gemessen werden (z. B. eine Tx-Symbolrate von zwei oder mehr NICs). In einigen Ausführungsformen kann der FW/HW-Controller außerdem konfiguriert werden, um eine oder mehrere gemessene Frequenzen als Ausreißerfrequenz zu identifizieren und selektiv zu bestimmen, diese gemessene Frequenz nicht im Satz von gemessenen Frequenzen einzuschließen, die verwendet werden, um die Ensemble-Zeit zu berechnen. Anders ausgedrückt, der FW/HW-Controller kann konfiguriert werden, um zu identifizieren, wann eine oder mehrere Tx-Symbolraten einer Ausreißer-Tx-Symbolrate entspricht. Der Ausreißer kann dann von der Berücksichtigung als Teil der Ensemble-Zeit ausgeschlossen werden. Die Fähigkeit, Ausreißerfrequenzen zu identifizieren, kann dem FW/HW-Controller ermöglichen, fehlerhafte Takte als Teil des Bestimmens der Ensemble-Zeit zu detektieren und zu behandeln. Auf diese Weise kann die Ensemble-Zeit unter Verwendung von Takten von unterschiedlichen Peers, die korrekt arbeiten, bestimmt werden.
In einigen Ausführungsformen kann der Ansatz der Verwendung der Ensemble-Zeit, wie in Verbindung mit 10 veranschaulicht und beschrieben, mit anderen hierin veranschaulichten und beschriebenen Ansätzen kombiniert werden. Zum Beispiel kann ein FW/HW-Controller konfiguriert werden, um eine vollständige Lösung für eine Cluster-Syntonisierung unter Verwendung eines Taktes zu erstellen, der basierend auf einer berechneten Ensemble-Zeit aktualisiert wurde. In einigen Ausführungsformen kann die Vorrichtung (Schalter) ihren lokalen Takt mit PHCs von einer oder mehreren NICs (z. B. NIC1, NIC2, NIC3, ..., NICN) verbunden haben. Der PHC der einen oder mehreren NICs kann konfiguriert werden, um dem lokalen Takt der Vorrichtung (Schalter) zu folgen, der basierend auf einer am FW/HW-Controller der Vorrichtung unter Verwendung der von den NICs gemessenen Frequenzen berechneten Ensemble-Zeit abgestimmt wird. Mit anderen Worten, die Vorrichtung (Schalter) kann konfiguriert werden, um die Symbolrate von mehreren NICs zu verwenden, um ein Zeit-Ensemble zu erstellen, und stimmt dann ihre Tx-Symbolrate demgemäß ab. Danach werden alle NIC-PHCs dem lokalen Takt der Vorrichtung (Schalter) folgen, wodurch jeder NIC die Zeit-Ensemble-Qualitätsfrequenz bereitgestellt wird. Solange die NICs das passende Taktsignal von der Vorrichtung (Schalter) empfangen, wird die PHC-Drift ausreichend verwaltet und minimiert werden.
11 illustriert eine weitere Konfiguration des Systems, bei dem ein oder mehr Netzwerkelemente (z. B. NIC1, NIC2, NIC3, ... NICN, etc.) ihren PHC syntonisiert haben oder dieser dem lokalen Takt eines Gruppenleaders folgt. Es ist bekannt, dass beim Transferieren von Frequenzinformationen die Verwendung eines schnelleren Signals (mit höherer Frequenz) besser ist als das Transferieren von Frequenzinformationen unter Verwendung eines langsamen Signals. Hochgeschwindigkeitsnetzwerkkomponenten stehen an der Spitze der Hochgeschwindigkeitsfrequenztechnologie, was das Teilen von Frequenzinformationen unter derartigen Komponenten umso schwieriger macht. In der veranschaulichten Ausführungsform ist der Gruppenleader als Schalter illustriert und wird gezeigt, dass dieser anderen Netzwerkelementen ein Leader-TX-Signal bereitstellt, was diesen Netzwerkelementen erlaubt, ihre PHCs basierend auf dem aktuellen Zustand des lokalen Taktes im Gruppenleader abzustimmen.
In einigen Ausführungsformen kann es nützlich sein, eine relative Syntonisierung (z. B. Syntonisierung zwischen Knoten/Netzwerkelementen und nicht nach einer absoluten Referenzfrequenz) in einem flachen System bereitzustellen. 11 illustriert ein Beispiel eines Systems, in dem Knoten/Netzwerkelemente mit einem Schalter verbunden sind und so konfiguriert sind, dass ihre PHCs dem lokalen Takt des Schalters folgen. In einigen Ausführungsformen weist jedes Netzwerkelement (z. B. NIC) seinen eigenen PHC auf, der, mindestens teilweise basierend, auf den Physikalische-Schicht-Frequenz-Informationen abstimmbar ist, die den lokalen Takt des Schalters treiben. Anders ausgedrückt, es ist mehr als ein Netzwerkelement in dem System konfiguriert, seinen entsprechenden PHC unter Verwendung der Physikalische-Schicht-Frequenz-Informationen, wie am Schalter bestimmt, zu disziplinieren. Zum Beispiel können, wie oben erörtert, die Physikalische-Schicht-Frequenz-Informationen aus einer RX-Symbolrate am Gruppenleader extrahiert werden, was in einer Abstimmung am lokalen Takt des Gruppenleaders resultiert.
Es ist nachvollziehbar, dass der Gruppenleader nicht unbedingt einem Schalter entsprechen muss und dass es mehr als ein Subnetzwerk innerhalb eines Systems geben kann. Des Weiteren können die Netzwerkelemente einer beliebigen Anzahl von Vorrichtungen oder Vorrichtungstypen entsprechen und können in einer Anzahl von unterschiedlichen Netzwerken oder Systemen bereitgestellt werden. Zum Beispiel können die Netzwerkelemente Mobilfunknetzwerkelementen (z. B. Antennen, Routern, mobilen Substationen, einem verteilten Antennensystem (Distributed Antenna System, DAS) etc.), Datenzentrumsnetzwerkelementen (z. B. einem Top-of-Rack(ToR)-Schalter, NICs, Routern, Servern, Schaltern, Netzwerkadaptern etc.), Kombinationen davon und dergleichen entsprechen.
In einigen Ausführungsformen kann eine Zelle mit einer Anzahl von Mobilfunknetzwerkelementen (z. B. Antennen) bereitgestellt werden, deren Takte /PHCs relativ zueinander synchronisiert werden. Falls die Zelle klein ist (z. B. eine Mikrozelle), kann die Zelle einen einzelnen Schalter (z. B. höchstens einen Netzwerkschalter) enthalten. Falls die Zelle höchstens einen Netzwerkschalter enthält, erlauben durch die vorliegende Offenbarung bereitgestellte Lösungen einen Frequenzabgleich in allen Netzwerkelementen (z. B. Rechenknoten) der Zelle durch Abstimmen von jedem Rechenknoten nach der Schaltersymbolrate. In einigen Ausführungsformen kann der Frequenzabgleich mit einer linearen Multiplikation des internen PLL des Schalters erzielt werden.
In einigen Ausführungsformen kann die vorgeschlagene Lösung bei einem bereits existierenden Zelleneinsatz eingesetzt werden. Der Zelleneinsatz muss nicht unbedingt SyncE nativ unterstützen, das der Standard für Frequenztransfer über Ethernet ist. Wie hierin ausführlicher erörtert werden wird, muss die Zelle oder das Subnetzwerk, deren/dessen Netzwerkelemente relativ zueinander synchronisiert werden, nicht unbedingt einen Schalter als Gruppenleader enthalten. Ein weiterer Verwendungsfall kann einen Einsatz einschließen, der einen Frequenztransfer in einem Datenzentrum ermöglicht, wo keine SyncE-unterstützten Schalter existieren.
12 illustriert ein weiteres Beispiel des Systems, bei dem eine Ensemble-Zeit verwendet wird, um den lokalen Takt des Gruppenleaders abzustimmen, wonach der lokale Takt (der gemäß einer Ensemble-Zeit aktualisiert wurde) verwendet wird, um Abstimmungen an PHCs der Netzwerkelemente (z. B. NIC1, NIC2, NIC3, ..., NICN) zu treiben. 12 repräsentiert eine Kombination des in 10 veranschaulichten Systems und des in 11 veranschaulichten Systems. In dieser konkreten Konfiguration kann der Schalter als Teil der Zelle oder des Subnetzwerks betrachtet werden, deren/dessen Takte basierend auf den gemeinsamen Physikalische-Schicht-Frequenz-Informationen (z. B. wie durch die Ensemble-Zeit bestimmt) synchronisiert werden.
Die Ensemble-Zeit, die verwendet wird, um den lokalen Takt des Gruppenleaders abzustimmen, kann auf mindestens einer ersten RX-Symbolrate, die von mindestens einem ersten Netzwerkelement empfangen wird, basieren und kann ferner mindestens auf einer zweiten RX-Symbolrate, die von einem zweiten Netzwerkelement empfangen wird, basieren. Die Ensemble-Zeit kann verwendet werden, um den lokalen Takt des Gruppenleaders abzustimmen, womit anschließend die Leader-TX angetrieben wird und was in weiteren Änderungen der PHCs der Netzwerkelemente im Subnetzwerk, das den Schalter einschließt, resultiert.
Wie in 13 ersichtlich, kann die Konfiguration eines Subnetzwerkes variieren. Zum Beispiel können Netzwerkelemente eines Subnetzwerkes in einer Rücken-zu-Rücken-Konfiguration, einer Ringkonfiguration oder einer anderen Konfiguration verbunden sein.
Unabhängig von der verwendeten Konfiguration können sich die PHCs der Netzwerkelemente in einem Subnetzwerk gemäß Physikalische-Schicht-Frequenz-Informationen miteinander synchronisieren. In einigen Ausführungsformen können die Physikalische-Schicht-Frequenz-Informationen von einem Schalter oder Gruppenleader innerhalb eines konkreten Subnetzwerks empfangen werden. In einigen Ausführungsformen können die Physikalische-Schicht-Frequenz-Informationen an zwei oder mehr Netzwerkelementen von einem Schalter oder Gruppenleader empfangen werden, der außerhalb ihres Subnetzwerks liegt. Die verschiedenen Subnetzwerke können miteinander verbunden werden, müssen aber nicht unbedingt wie hierin beschrieben miteinander synchronisiert werden. Es können zum Beispiel andere Synchronisierungstechniken verwendet werden, um unterschiedliche Subnetzwerke zu synchronisieren, während die Netzwerkelemente innerhalb eines konkreten Subnetzwerks weiter synchronisiert werden oder Frequenzinformationen innerhalb des Subnetzwerks teilen.
14 illustriert eine weitere Systemkonfiguration, bei der die verschiedenen Subnetzwerke Mobilfunksubnetzwerken entsprechen und die Netzwerkelemente innerhalb der Mobilfunksubnetzwerke eine relative Synchronisierung aufrechterhalten. Beispiele der Netzwerkelemente können unter anderem die hierin beschriebenen Netzwerkelemente (NE), Schalter (SW), Mobilvermittlungsstellen (Mobile Switching Centers, MSC) etc. einschließen. Wie nachvollziehbar ist, kann jedes Subnetzwerk des Mobilfunknetzwerks ein Kernnetzwerk, eine Metrozelle, eine Massive-MIMO, eine kleine Outdoor-Zelle, ein Outdoor-DAS, ein Indoor-DAS oder dergleichen einschließen. Mit anderen Worten, es kann jede beliebige Ansammlung von Mobilfunknetzwerkelementen in einem Subnetzwerk wie hierin beschrieben eingeschlossen sein und ihre PHCs relativ zueinander wie hierin beschrieben synchronisiert haben.
Zum Beispiel, falls eine Nvidia-Netzwerkvorrichtung, z. B. NIC ohne SyncE-Unterstützung, in einem SyncE-Netzwerk verwendet wird, würden Ausführungsformen hierin dem NIC-PHC einen viel stabileren Frequenztakt bereitstellen.
Es ist nachvollziehbar, dass Frequenzabstimmungen entweder absolut oder relativ sein können. Betrachten wir zum Beispiel den Controller von 1, kann dieser in Firmware implementiert werden und das SyncE-Protokoll verwenden. Die FW kann frequenzbezogene Daten von der HW erfassen und kann beispielsweise Differenzen in Teile pro Million und/oder pro Milliarde und/oder pro Billion (auch PPM/PPB/PPT) zwischen RX- und TX-Raten errechnen, die als Frequenz-Diff. wert verwendet werden. 1 PPB bedeutet zum Beispiel 1 Nanosekunde kumulierte Drift für jede Sekunde, unter der Annahme, dass eine der Frequenzen perfekt ist. Eine positive/negative Zahl gibt an, welcher Takt schneller/langsamer ist. Die FW konvertiert dann den Frequenz-Diff. wert, z. B. den PPB-Wert, in einen DPLL-konfigurationsbezogenen Parameter (z. B. „TI BAW“) der externen Taktvorrichtung. Die interne Konfiguration kann von folgendem Typ sein: $FREQ_OUT = FREQ_IN * (INT + Z \ddot{A} HLER / NENNER)$
Typischerweise wird alles, abgesehen von dem Zähler, konstant gehalten, sodass die interne Konfiguration „gelöst“ werden kann, nachdem der relative PPB-Wert in einen Wert konvertiert wird, der dem Zähler hinzugefügt/oder von dem Zähler abgezogen wird, um den gewünschten PPB zu erhalten. Alternativ entspricht der PHC-DPLL dem Typ $FREQ_OUT = FREQ_IN * (Z \ddot{A} HLER / NENNER)$
bei dem der INT-Wert des DPLL-konfigurationsbezogenen Parameters (Taktsynchronisator) fehlt, wobei sich die Konvertierung von dem relativen PPM/PPB/PPT-Wert in die DPLL-Parameter dementsprechend ändert.
PTP4L (eine Implementierung des Präzisionszeitprotokolls (Precision Time Protocol, PTP) gemäß IEEE-Standard 1588 für Linux, womit ein Grenztakt (Boundary Clock, BC) und ein Gewöhnlicher Takt (Ordinary Clock, OC) implementiert werden) verwendet absolute Frequenzaktualisierungen und weist einen PPB-Wert auf, der zu 1 Milliarde relativ ist. Dieser Wert ist absolut, da er zu einer Konstante relativ ist. Falls zum Beispiel der Wert + 1 Million => ist, wird die Originalfrequenz der Vorrichtung (wie von der Kerntaktfrequenz der Vorrichtung abgeleitet) um (1 Milliarde + 1 Million)/(1 Milliarde) = 1,001 erhöht. Falls derselbe Wert noch einmal erhalten wird, wird die Originalfrequenz der Vorrichtung noch einmal um denselben Wert erhöht, z. B. der Vorgang ist derselbe wie der Vorgang nach der vorhergehenden Aktualisierung. Im Gegensatz dazu wird bei einem relativen Aktualisierungsmodus (oder entsprechenden Ausführungsform) eine 1-Million-PPB-Aktualisierung, die zweimal hintereinander empfangen wird, in einer Erhöhung resultieren von 1,001 * 1,001 = 1,002001 die Sekundenzeit, z. B. in einem relativen Aktualisierungsmodus (oder entsprechenden Ausführungsform) ist der Vorgang beim zweiten Mal nicht derselbe wie der Vorgang nach der vorhergehenden Aktualisierung.
SyncE ist ein Ethernetprotokoll, aber die Anwendbarkeit der Ausführungsformen hierin ist nicht auf Ethernet beschränkt und sie können in (typischerweise paketbasierten) Netzwerken implementiert werden, die sich von Ethernet unterscheiden (wie etwa InfiniBand, PCIe, NVlink etc.). SyncE ist speziell ein Standard, der erfordert, dass Frequenzinformationen durch einen ausgewählten Netzwerkport von mehreren Netzwerkports bereitgestellt werden, und wo dann der Partner des ausgewählten Netzwerkports mit diesen Frequenzinformationen folgendes macht: a. verteilt den durch den ausgewählten Port bereitgestellten Takt an anderen Netzwerkports; und b. stimmt seinen eigenen PHC (den der Partner) ab. Dies verursacht genaue Takte, die über das Netzwerk verteilt werden.
Ein geeignetes Protokoll kann von Netzelementen gemäß Ausführungsformen der Erfindung verwendet werden, wenn mit einem Link-Partner kommuniziert wird, um eine Frequenz, wie hierin beschrieben, zu extrahieren und zu verwenden. Wie an anderer Stelle beschrieben, können die Verwaltungspakete zum Beispiel ESMC PDUs (Ethernet-Synchronization-Messaging-Channel-Protokolldateneinheiten) sein, wie definiert in ITU-T G.8264, ein Spezifikationsdokument, das von der International Telegraph Union (ITU)'s Telecommunication Standardization Sector (ITU-T) erstellt wurde und das online z. B. unter dem https-www-Link itu.int/rec/T-REC-G.8264 erhältlich ist und den Ethernet-Synchronization-Messaging-Channel (ESMC, Ethernetsynchronisierungsnachrichtenkanal) spezifiziert. Falls zum Beispiel das Netzwerk SyncE verwendet und ein gegebenes Netzelement, auch Netzwerkvorrichtung, die letzte Vorrichtung in einer SyncE-Kette ist, können ESMC-Nachrichten (z. B. wie in ITU-T G.8264 definiert) von einer SyncE-Vorrichtung mindestens einmal pro Sekunde gesendet werden und verwendet werden, um die Taktqualität zu deklarieren. Falls die SW, die diese Nachrichten empfängt, erkennt, dass ihr Link-Partner eine Taktqualität aufweist, die besser oder genauer als ihre eigene Taktqualität ist, beginnt die Software typischerweise, diese Link-Partner-Frequenz zu verfolgen, und extrahiert und verwendet diese Link-Partner-Frequenz wie hierin beschrieben.
Ausführungsformen hierin können jedoch ohne einen SyncE-Link-Partner verwendet werden, wobei das Protokoll ESMC ähnlich ist und außerdem wie folgt gekennzeichnet sein kann:

Das Protokoll kann Informationen bezüglich der Taktqualität von Nachbarn (z. B. Link-Partnern) führen. Diese Qualität kann zum Beispiel durch SSM-Codes und Enhanced-SSM-Codes (verwendet in ESMC) repräsentiert sein oder kann alternativ andere Codes verwenden. Das Protokoll kann alternativ oder zusätzlich andere Informationen über die Frequenzstabilität des Taktes führen, wie etwa die erwartete Frequenzstabilität bei unterschiedlichen Temperaturen und/oder über unterschiedliche Perioden (kurzfristige/langfristige Stabilität). Die Vorrichtungssymbolrate kann nach einer externen Frequenz, wie etwa GPS oder SyncE, synchronisiert werden.

Das Protokoll kann alternativ oder zusätzlich einen Takt-Identifizierer (z. B. eine einmalige Bitsequenz pro Takt), der von der Zeitquellenauswahl-SW verwendet werden kann, um jeden Takt zu identifizieren.
Nachrichten können von jedem Netzwerkelement an seine Link-Partner gesendet werden und werden möglicherweise nicht von jedem Netzwerkelement weitergeleitet. Informationen können in einem Handschlag-Vorgang ausgetauscht werden oder können periodisch angekündigt werden (z. B. Heartbeat-Nachricht, periodisch z. B. jede Sekunde. Im Fall einer Änderung des Qualitätslevels, z. B. des Taktes/der Takte der Link-Partner, kann eine spezielle Nachricht, die die Änderung ankündigt, übertragen werden.
Es ist nachvollziehbar, dass auf NICs hierin als Beispiel für ein Netzwerk Bezug genommen wird. Die Ausführungsformen hierin sind jedoch nicht in ihrer Anwendbarkeit beschränkt und können stattdessen in jeder Netzwerkvorrichtung implementiert werden, wie etwa als nicht einschränkendes Beispiel einer NIC, Datenverarbeitungseinheit, auch DPU (Data Processing Unit), oder einem Schalter
Der Begriff „Master“ (oder „Referenz“) wird hierin verwendet, um ein Netzwerkelement zu beschreiben, dem andere Netzwerkelemente („Nachfolge“- oder „Slave“-Netzwerkelemente) folgen. Typischerweise beeinflussen zwischen Netzwerkelementen gesendete Nachrichten (wie etwa periodische und/oder spezielle SyncE-Nachrichten) die Entscheidung von jedem Netzwerkelement, wem zu einem gegebenen Zeitpunkt gefolgt werden soll, z. B. wie hierin beschrieben. Es ist nachvollziehbar, dass bei einer gegebenen Netzwerktopologie einige Netzwerkelemente (z. B. „Blätter“) möglicherweise nicht von einem anderen Netzwerkelement verfolgt werden. Die Abwesenheit von Nachrichten kann ebenfalls die Entscheidung von jedem Netzwerkelement, wem zu einem gegebenen Zeitpunkt gefolgt werden soll, beeinflussen, z. B. falls das Netzwerkelement eine Nachricht von einem gegebenen Link-Partner innerhalb einer gegebenen Zeitperiode erwartete und diese nicht empfangen hat.
Der Begriff „Netzwerkvorrichtung“ (auch Netzwerkelement), wie hierin verwendet, soll als nicht beschränkendes Beispiel einen Schalter, eine Netzwerkschnittstellenkarte (NIC), wie etwa eine intelligente NIC, einen Router, oder eine DPU einschließen.
Die Begriffe „RX-Symbolrate“ und „RX-Frequenz“ werden hierin als Synonyme verwendet.
Die Begriffe „TX-Symbolrate“ und „TX-Frequenz“ werden hierin als Synonyme verwendet.
Der Begriff „alle“ wird hierin zwecks Einfachheit verwendet, um beispielhafte Ausführungsformen zu beschreiben. Es ist jedoch nachvollziehbar, dass alternativ, ganz gleich, was hierin als wahr für oder kennzeichnend für oder gehörend zu „alle/n“ Glieder/n oder „jedes/jedem“ Glied eines bestimmten Satzes gesagt wird, in anderen Ausführungsformen auch wahr für oder kennzeichnend für oder gehörend zu die/den meisten, aber nicht allein Glieder/n von diesem Satz, oder allein, bis auf wenige/n Glieder/n von diesem Satz, oder mindestens ein/em (aber weniger als allen) Mitglieder/n von diesem Satz sein kann.
Zum Beispiel kann ein Auswahlalgorithmus die Qualität und/oder manuell konfigurierbare Priorität und/oder andere Merkmale aller Quellen in einem Satz von verfügbaren Zeitsteuerungsquellen vergleichen. Aber alternativ können die meisten, aber nicht alle Quellen, oder alle, bis auf wenige Quellen, oder mindestens eine (aber weniger als alle) Quelle/n in diesem Satz verglichen werden.
Die hierin gezeigten und beschriebenen spezifischen Ausführungsformen sind nicht als beschränkend zu verstehen. Jedes hierin bereitgestellte Detail kann in Verbindung mit einem allgemeinen System bereitgestellt werden oder nicht bereitgestellt werden, das TX und/oder RX auf einer lokalen Vorrichtung und dem/den Link-Partner/n der lokalen Vorrichtung misst, dementsprechend eine Ausgabe generiert, die Frequenzabstimmungen in Hardware steuert, anstatt unbedingt die Firmware des Controllers der lokalen Vorrichtung zu verwenden, um die PHC-Frequenzabstimmungen der lokalen Vorrichtung zu ermöglichen.
Es ist nachvollziehbar, dass Softwarekomponenten der vorliegenden Erfindung, falls gewünscht, in ROM-Form (ROM = Read Only Memory, Nur-Lese-Speicher) implementiert werden können. Die Softwarekomponenten können allgemein, falls gewünscht, in Firmware oder Hardware implementiert werden, unter Verwendung herkömmlicher Techniken. Es ist weiter nachvollziehbar, dass Softwarekomponenten zum Beispiel als Rechnerprogrammprodukt oder auf einem greifbaren Medium instanziiert werden können. In einigen Fällen kann es möglich sein, die Softwarekomponenten als Signal zu instanziieren, das von einem passenden Rechner interpretiert werden kann, obwohl eine derartige Instanziierung in gewissen Ausführungsformen der vorliegenden Erfindung ausgeschlossen sein kann.
Es ist nachvollziehbar, dass verschiedene Merkmale der Erfindung, die zwecks Übersichtlichkeit im Kontext separater Ausführungsformen beschrieben werden, auch in Kombination mit einer einzigen Ausführungsform bereitgestellt werden können. Umgekehrt können verschiedene Merkmale der Erfindung, die zwecks Übersichtlichkeit im Kontext einer einzigen Ausführungsform beschrieben werden, auch separat oder in einer beliebigen geeigneten Subkombination bereitgestellt werden.
Es wird für Fachleute auf dem Gebiet nachvollziehbar sein, dass die vorliegende Erfindung nicht durch das beschränkt ist, was hierin oben speziell gezeigt und beschrieben wurde. Vielmehr schließt der Umfang der Erfindung unter anderem die anhängenden Patentansprüche und Äquivalente davon ein.
Es versteht sich, dass Aspekte und Ausführungsformen oben lediglich beispielhaft beschrieben werden und das Modifikationen im Detail innerhalb des Umfangs der Ansprüche vorgenommen werden können.
Jedes in der Beschreibung und (falls zutreffend) den Ansprüchen und Zeichnungen offenbartes Gerät, Verfahren und Merkmal kann unabhängig oder in einer beliebigen passenden Kombination bereitgestellt werden.
In den Ansprüchen erscheinende Bezugszeichen dienen lediglich der Illustration und sollen keinen beschränkenden Effekt auf den Umfang der Ansprüche haben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 10778406 [0002, 0043, 0050]
US 2020/0162234 [0018]
US 11070214 [0036]
US 20200162234 [0043]

Claims

Ein System, das Folgendes umfasst: zwei oder mehr Netzwerkelemente, die jeweils einen Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC, HC = Hardware Clock) umfassen, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Das System nach Anspruch 1, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Das System nach Anspruch 1 oder 2, wobei mindestens eines der zwei oder mehr Netzwerkelemente ein Mobilfunknetzwerkelement umfasst.
Das System nach Anspruch 3, wobei die zwei oder mehr Netzwerkelemente eine erste Antenne und eine zweite Antenne umfassen.
Das System nach Anspruch 1, wobei mindestens eines der zwei oder mehr Netzwerkelemente ein Datenzentrumselement, das zu einem Datenzentrums-Cluster gehört, umfasst.
Das System nach Anspruch 5, wobei das Datenzentrumselement einen Top-of-Rack(ToR)-Schalter umfasst.
Das System nach einem vorhergehenden Anspruch, wobei ein Schalter die Frequenzinformationen extrahiert, um eine Ensemble-Zeit zu bestimmen, und wobei die Ensemble-Zeit verwendet wird, um die Frequenz des PHC und dessen TX-Symbolrate abzustimmen.
Das System nach Anspruch 7, wobei der Schalter die Ensemble-Zeit mindestens basierend auf einer ersten RX-Symbolrate, die von mindestens einem ersten Netzwerkelement empfangen wird, und mindestens basierend auf einer zweiten RX-Symbolrate, die von mindestens einem zweiten Netzwerkelement empfangen wird, bestimmt.
Das System nach Anspruch 1, wobei die zwei oder mehr Netzwerkelemente zu einem Subnetzwerk gehören, das einen Schalter einschließt.
Ein Mobilfunknetzwerk, das Folgendes umfasst: ein erstes Mobilfunknetzwerkelement, das einen ersten Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC) umfasst, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist; und ein zweites Mobilfunknetzwerkelement, das einen zweiten PHC umfasst, der, mindestens teilweise, basierend auf den Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Das Mobilfunknetzwerk nach Anspruch 10, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Das Mobilfunknetzwerk nach Anspruch 11, wobei die RX-Symbolrate einer RX-Symbolrate des ersten Mobilfunknetzwerkelements und/oder des zweiten Mobilfunknetzwerkelements entspricht.
Das Mobilfunknetzwerk nach Anspruch 10, 11 oder 12, das ferner einen Schalter umfasst, wobei ein lokaler Takt an dem Schalter basierend auf einem gewichteten Durchschnitt der zwei oder mehr RX-Symbolraten abgestimmt wird und wobei der lokale Takt verwendet wird, um den ersten PHC und den zweiten PHC abzugleichen.
Das Mobilfunknetzwerk nach einem der Ansprüche 10 bis 13, wobei das erste Mobilfunknetzwerkelement eine erste Antenne umfasst und wobei das zweite Mobilfunknetzwerkelement eine zweite Antenne umfasst.
Das Mobilfunknetzwerk nach einem der Ansprüche 10 bis 14, wobei das erste Mobilfunknetzwerkelement und das zweite Mobilfunknetzwerkelement zu einer gemeinsamen Mikrozelle gehören.
Das Mobilfunknetzwerk nach Anspruch 10, wobei die Frequenzinformationen aus einer Differenz zwischen einer RX-Symbolrate und einer TX-Symbolrate oder aus einer Differenz zwischen der RX-Symbolrate und dem PHC extrahiert werden.
Ein Datenzentrum, das Folgendes umfasst: ein erstes Netzwerkelement und ein zweites Netzwerkelement, wobei das erste Netzwerkelement einen ersten Präzisionszeitprotokoll(PTP)-Hardware-Taktgeber (PHC) umfasst, der, mindestens teilweise, basierend auf Physikalische-Schicht-Frequenz-Informationen abstimmbar ist, und wobei das zweite Netzwerkelement einen zweiten PHC umfasst, der, mindestens teilweise, basierend auf den Physikalische-Schicht-Frequenz-Informationen abstimmbar ist.
Das Datenzentrum nach Anspruch 17, wobei das erste Netzwerkelement einen ersten Netzwerkschnittstellencontroller (NIC) umfasst und wobei das zweite Netzwerkelement einen zweiten NIC umfasst.
Das Datenzentrum nach Anspruch 17 oder 18, wobei die Physikalische-Schicht-Frequenz-Informationen von einem Schalter empfangen werden.
Das Datenzentrum nach Anspruch 19, wobei der Schalter außerhalb eines Subnetzwerkes, das das erste Netzwerkelement und das zweite Netzwerkelement enthält, liegt.
Das Datenzentrum nach einem der Ansprüche 17 bis 20, wobei die Frequenzinformationen aus einer RX-Symbolrate extrahiert werden.
Das Datenzentrum nach einem der Ansprüche 17 bis 21, wobei die extrahierten Frequenzinformationen verwendet werden, um eine Ensemble-Zeit zu bestimmen, und wobei die Ensemble-Zeit verwendet wird, um die Frequenz des ersten PHC abzustimmen.
Das Datenzentrum nach Anspruch 22, wobei die Ensemble-Zeit verwendet wird, um die Frequenz des zweiten PHC abzustimmen.
Das Datenzentrum nach einem der Ansprüche 17 bis 23, wobei das erste und zweite Netzwerkelement in einer Rücken-zu-Rücken-Konfiguration verbunden sind.
Das Datenzentrum nach einem der Ansprüche 17 bis 23, wobei das erste und zweite Netzwerkelement in einer Ringtopologie verbunden sind.