DOCSIS 3.1 Kanal für Upload nun verfügbar?

[Flole]

Der OFDMA und die SC-QAM Kanäle teilen sich das Spektrum mittels TaFDM, so wäre es richtig. Wobei daraus nicht hervorgeht ob und wo Lücken im OFDMA Block konfiguriert sind, es könnte also auch ohne TaFDM gehen.

Mir ist noch nicht klar, wie das mit TaFDM auf der Zeitachse geht: SC-QAM hat einen Basistakt von 160kHz, OFDMA hier einen von 50kHz - da ist das eine kein ganzzahliges Vielfaches des anderen. Gibt's beim Wechsel vom einen zum anderen in einem Frequenzbereich dann "Verschnitt" variabler Dauer, in dem weder das eine noch das andere verwendet werden kann? Dann wäre die Effizienz tatsächlich nicht so schick wie bei FDM, wo beides für sich "nahtlos" ohne Totzeiten genutzt werden kann... oder gibt es da noch einen Trick, Sendepausen bei TaFDM zu vermeiden?

Schau mal in CM-SP-MULPIv3.1-I10-170111, Seite 65. Da steht auch beschrieben warum die OFDMA-Löcher um die SC-QAM Kanäle sein müssen.

[robert_s]

Das heißt je niedriger desto besser? Gibt es eine Tabelle der Werte?

Hatte ich einst schon hier gepostet:
viewtopic.php?p=698589#p698589

IUC = Profile. Wobei die damalige Annahme, dass das völlig dynamisch geändert werden könne, wohl falsch war.

[robert_s]

Mir ist noch nicht klar, wie das mit TaFDM auf der Zeitachse geht: SC-QAM hat einen Basistakt von 160kHz, OFDMA hier einen von 50kHz - da ist das eine kein ganzzahliges Vielfaches des anderen. Gibt's beim Wechsel vom einen zum anderen in einem Frequenzbereich dann "Verschnitt" variabler Dauer, in dem weder das eine noch das andere verwendet werden kann?

Schau mal in CM-SP-MULPIv3.1-I10-170111, Seite 65. Da steht auch beschrieben warum die OFDMA-Löcher um die SC-QAM Kanäle sein müssen.

Mein Archiv geht nur bis zur I11 zurück, diese Uraltversion habe ich nicht. Aber im aktuellen findet man es ja auch:

Note that a guard band is needed between OFDMA and SC-QAM channels in both the Time and the Frequency Domain. While SC-QAM channels can effectively run adjacent to each other, OFDMA will require some guard band in the Frequency domain to separate itself from the SC-QAM channels. Similarly, the SC-QAM channels will need to maintain a guard band in time with respect to the OFDMA channel. Since the OFDMA Frame interval may not be an integer number of SC-QAM minislots, the SC-QAM scheduler needs to account for any differences.

Das finde ich erschreckend schwach spezifiziert. Da hätte man doch vorrechnen können, wie viel Frequenz- und Zeitabstand notwendig ist. Auch im PHY-Dokument, welche den Physical Layer spezifiziert, findet sich nichts dazu. Stattdessen nur so ein "findet es selbst heraus". Kein Wunder, dass die Entwicklung ewig gedauert hat.

Immerhin haben wir die Guard Bands im Frequenzbereich schon identifizieren können: 200kHz Abstand hält der OFDMA zu den SC-QAM Upstreams.

Aber im Zeitbereich sehe ich gutes Potenzial für Implementierungsfehler. Mit der variablen Verschiebung zwischen SC-QAM und OFDMA-Zeitschlitzen ergibt sich eine entsprechende Variabilität der Guard Bands. Und wenn der CMTS-Algorithmus einen Fehler hat, ist das Guard Band vielleicht gelegentlich doch mal zu kurz und es hagelt Übertragungsfehler. Vielleicht ist das ja auch die Erklärung dafür, dass der OFDMA-Betrieb noch nicht ganz stabil wirkt.

Und nicht zuletzt dürfte das Demodulieren doch recht fummelig sein, wenn man aus dem gleichen Spektrum asynchron SC-QAM und OFDMA demodulieren soll. Auch noch schönes Fehlerpotenzial für schwer zu findende sporadische Fehler.

Ich kann mir gut vorstellen, dass die CMTS-Entwickler da schon einiges über die Spezifikation geflucht haben. Das hätte man vielleicht auch durchdachter machen können, z.B. mit 40kHz OFDMA-Subträgern...

[NoNewbie]

Im gesamten Spektrum gibt es dann auch noch Lücken für die Messträger.

[Anda]

Heute war in Garmisch-Partenkirchen von 00:19 - 01:56 Nachts das Internet weg und nun habe ich auch einen Docsis 3.1 Kanal im Upload. Denke mal nicht mehr lange und der Upload wird erhöht.

[r2d2]

Irgendwie ist das seit der Umstellung auf den zusätzlichen DS3.1 Upstream Channel seltsam. Wo ich sonst in Speedtests konstant über 50 Mbit Upload hatte, ist es nun oft so, dass der Speedtest mit vollem Upload Speed losrennt, dann aber stark einbricht auf teils unter 18 Mbit.

Es treten auch sehr viel mehr T3 timeouts auf. Aussetzer habe ich aber keine - auch mein Smokeping zeigt keine Probleme.

Oder es liegt gar nicht an meiner Leitung, sonder andere Modems im Segment haben Probleme mit dem OFDMA und nutzen nun vielleicht die Upstream Channel ungleichmäßig!?

[hypnorex]

Bei mir läuft der Upstream nach wie vor stabil bei etwas über 50.

[Yoshi2000]

Im Netz Passau wurde jetzt auch der ODFM Kanal im Upstream aufgeschaltet.

Vom Signalpegel 37.0 dBmV ist der Kanal jetzt nicht so optimal. Die alten Kanäle haben weiterhin zwischen 44.0 dBmV und 46.0 dBmV.

[maik005]

beachte dabei, dass der OFDMA sehr wahrscheinlich ganz andere Pegelvorgaben haben wird die wohl (noch) nicht bekannt sind.

[millen]

Im Netz Passau wurde jetzt auch der ODFM Kanal im Upstream aufgeschaltet.

Vom Signalpegel 37.0 dBmV ist der Kanal jetzt nicht so optimal. Die alten Kanäle haben weiterhin zwischen 44.0 dBmV und 46.0 dBmV.

Der Pegel von 37 dBmV ist super. Der OFDMA ist liegt meine ich immer so um die 6-9 dBmV unter den anderen Kanälen.