Die Yealink DECT-Basis W90B ist Stand 2025 das aktuellste DECT-Modell von Yealink. Damit in einem DECT-Netz alle Teilnehmer reibungslos miteinander kommunizieren können, muss die Funkstrecke „organisiert“ werden.
Kennt man es noch vom Walkie-Talkie, dass immer nur eine Person gleichzeitig sprechen sollte, da man sich sonst überlagert und dem Anderen in das Wort fällt, so bestehen doch höhere Anforderung an ein DECT-Netzwerk, wo gleichzeitige Kommunikation mit vielen Teilnehmern der Standard ist.
Wie funktioniert die Organisation eines DECT-Netzes?
Der Standard ist hier TDM. Time Divison Multiplexing[1]. Dieses Verfahren sorgt dafür, dass die Funkzeit in viele einzele Slots unterteilt wird und jeder Teilnehmer für eine kurze Zeit, Sendeerlaubnis (einen Slot zugewiesen bekommt) erhält.
Zur Einfachheit hier ein Beispiel. In der Praxis sind die Zeit-Slots deutlich kleiner und unter 1ms (Milisekunde).
Teilnehmer 1 darf immer das erste 1/25 einer Sekunde sprechen.
Teilnehmer 2 darf immer das erste 2/25 einer Sekunde sprechen.
Aus Teilnehmersicht fühlt es sich an, als könnte man immer sprechen. Tatsächlich aber, da der Zeit-Slot ja sehr sehr häufig vorhanden ist (am o.g. Beispiel, jede Sekunde) spricht man der Reihe nach.
Nun zeigt sich sehr deutlich, dass eine exakte Zeit und deren Synchronisierung in DECT-Netzen zwingend erforderlich ist. Primär um den „Takt“ einzuhalten, wann – durch wen – gesprochen werden darf. Für diesen Fall gibt einen zentralen Taktgeber. Dies ist bei Yealink der DECT-Manager (W90DM), welcher der Sync-Master ist. Um nun über alle beteiligten DECT-Manager eine zuverlässige Synchronisierung zu erreichen, bietet Yealink 2 Sync-Methoden. Die Over-the-Air-Methode (DECT-Sync) und die Ethernet-basierte Synchronisation (LAN-Sync).
Für die DECT-Synchronisation ist zwingend eine korrekte Verschaltung aller DECT-Sender nötig. Korrekt meint, dass die Dämpfung zwischen allen beteiligten Basen gut sein muss (nicht schlechter als -70). -80 ist schlechter als -70.
In kleinen Umgebungen bietet sich DECT-Sync an, wenn alle DECT-Basen, direkte Verbindung zum DECT-Manager haben. In sehr großen DECT-Umgebungen ist es möglich, dass eine Basis den DECT-Manager nur über andere Basen erreicht. Dies führt zu Abhängigkeiten und häufig zu Problemen bei nicht ausreichender Ausleuchtung. Fällt eine Basis auf dem Weg zum DECT-Manager aus, fallen alle darüber synchronisierten Basen aus.
Für diesen Fall, bzw. generell für alle Setups, mit einer größeren Anzahl von DECT-Basen, empfiehlt Yealink den Lan-Sync. Das zugrundeliegende Protokoll ist PTP. Der Protokollablauf ist wie folgt:
Der Master sendet eine Sync-Nachricht mit einem Zeitstempel (Zeitpunkt des Sendens).
Optional sendet der Master eine Follow_Up-Nachricht, falls der Zeitstempel erst nachträglich ermittelt wird (z.B. bei Hardware-Timestamping).
Der Slave empfängt die Sync-Nachricht und notiert den Empfangszeitpunkt.
Der Slave sendet eine Delay_Req-Nachricht an den Master und notiert den Sendezeitpunkt.
Der Master empfängt die Delay_Req-Nachricht und sendet eine Delay_Resp-Nachricht mit dem Empfangszeitpunkt zurück.
Der Slave kann jetzt mit den vier Zeitstempeln die Offset- und Laufzeitkorrektur berechnen, um die eigene Uhr an die Master-Uhr anzupassen.
(Slave ist die DECT-Basis, bzw. jeder Empfänger).
Empfängt der Master keine Nachrichten vom Slave, oder diese zu spät oder unpräzise, ist kein LAN-Sync möglich. Yealink erfordert für den Einsatz von Lan-Sync, Switches mit PTP-Unterstützung.
Dies erfordert häufig ein Upgrade von Switches, was mit erheblichen Kosten verbunden ist.
Was genau tut PTP und wie kann man es sich vorstellen:
PTP ist ein Protokoll, was die Verarbeitungszeit von Datenpaketen im Netzwerk erkennt und als Korrektur hinterherliefert. Einer meiner Kunden hat kürzlich ein sehr gutes Beispiel dafür gebracht (Danke Max!):
Ich sage dem Lehrling im Keller, er soll auf einem Zettel die aktuelle Uhrzeit notieren (es ist 10:24 Uhr) und diesen Zettel im 2OG der Buchhaltung übergeben.
Er kommt 2 Minuten später (3 Stockwerke dazwischen) in der Buchhaltung an und überbringt die Information, es ist 10:24 Uhr.
Diese Information wäre veraltet und falsch. PTP stellt nun sicher, dass die „Verarbeitungszeit“ – also der Weg zwischen Keller und 2OG, auf die Zeit addiert wird oder zumindest der Empfänger informiert wird, dass zwischen Keller und 2OG-Strecke, 2 Minuten vergangen sind.
Im Netzwerkbereich müssen Switche diese Funktion extra können, da der Switch dazu ja die Zeit-Informationen im Netz erkenne und korrigieren muss. Es gibt hier zwei Arten:
One-step clock (Ein-Schritt-Uhr)
- Die Zeitstempel (Zeitpunkt des Sendens der Sync-Nachricht) wird direkt im Sync-Paket eingetragen und sofort mitgeschickt.
- Vorteil: Weniger Nachrichten, geringer Overhead.
- Nachteil: Exakte Zeitstempel müssen sofort erfasst werden (meist Hardware-Timestamping nötig).
Two-step clock (Zwei-Schritt-Uhr)
- Der Master sendet zuerst ein Sync-Paket ohne exakten Zeitstempel.
- Kurz danach folgt ein Follow_Up-Paket, das den exakten Zeitstempel enthält, wann das Sync-Paket tatsächlich gesendet wurde.
- Vorteil: Erlaubt präzises Hardware-Timestamping, auch wenn der Zeitstempel erst nach dem Senden bestimmt werden kann.
- Nachteil: Zusätzlicher Paketverkehr (Follow_Up-Nachricht).
Für die Lan-Synchronisation ist i.d.R. der DECT-Master (W90DM) der Zeitgeber. PTP nennt dies OC – ordinary clock. Diese ordinary clock kann Zeitgeber (Master) oder Empfänger (Slave) sein.
Um nun in einem geswitchten Netzwerk die Verarbeitungszeiten zu erkennen und die Zeitpakete zu korrigieren, gibt es seit 2008 in der PTP-Spezifikation, die Erweiterung der transparent Clock (TC). Dies ist das eigentliche Feature der Switch, die die Switching/Verarbeitungszeit im Netzewrk berücksichtigt und empfangende/weiterleitende PTP-Pakete, korrigiert/aktualisiert.
Befinden sich sämtliche DECT-Sender alle mit dem DECT-Master an einem Switch angeschlossen, kann i.d.R. auch ohne Switch-Feature, PTP genutzt werden und die Lan-Synchronisation funktioniert.
Über mehrere Switche hinweg jedoch ist i.d.R. die Verarbeitungszeit zu groß.
[1] https://en.wikipedia.org/wiki/Time-division_multiplexing