Kabel-Internet: HFC/DOCSIS-Traffic messen

Ich bin in der glücklichen Situation, bei mir zu Hause schon seit Anfang der 2000er Jahre breitbandiges Internet genießen zu können. Geliefert wird via “Antennenkabel”, also HFC.

Als Transport-Protokoll kommt dabei (Euro)DOCSIS zum Einsatz. Bis zur Version 3.0 - welche aktuell für mich noch relevant ist - gibt es keine signifikanten Unterschiede beim Transport der Daten zu “normalem” DVB-C. Das gibt einem recht einfach die Möglichkeit, sich zumindest die Transport-Ströme einmal näher anzusehen, und zwar mit handelsüblicher TV-Hardware.

Evt. fragt ihr Euch, wieso das relevant sein könnte: Beim Antennen-Kabel handelt es sich stets um ein geteiltes Medium: Man teilt sich die verfügbare gesamte Bandbreite nicht nur mit Radio- und Fernsehsendern (wobei vielerorts zumindest mal das analoge Programm deaktiviert wurde, was eine deutlich effizientere Bandbreiten-Nutzung erlaubt), sondern auch mit allen anderen Internet-Kunden, welche am selben Strang (“Segment” genannt) angeschlossen sind. Und diese Bandbreite ist begrenzt. Je nach Kodierung liegt die maximale Bandbreite nach der Fehlerkorrektur bei ungefähr 50MBit/s. Kann man jetzt z.B. mit 16 Trägern mit der sog. Kopfstelle kommunizieren, dann teilen sich also alle Kunden eine Bandbreite von 800MBit/s.

Aufgrund der starken Ähnlichkeit zu normalen Fernsehen kann man jetzt so ziemlich jede zum Empfang von DVB-C geeignete PC-Hardware benutzen, um zumindest “pi mal Daumen” zu bestimmen, wieviel Bandbreite insgesamt ausgenutzt wird. Dazu muss man lediglich die Symbolrate (6952ksym/s), Modulierung (immer 64-QAM oder 256-QAM) und den PID (8190) wissen, hinter dem sich EuroDOCSIS 3.0 verbirgt und schon kann man die Daten auslesen. Ich habe das mit einem Raspberry Pi 3 getan (nein, nicht die neueste Version), das Ergebnis findet sich hier (und falls es da nicht mehr zu finden ist - oben sind Bilder). Für mich war das der erste Kontakt mit einem Pi, und ich finde die Hardware eigentlich ganz nett - und trotz mangelnder I/O-Leistung und sehr begrenztem Speicher durchaus ausreichend für den Anwendungsfall. Zum Speichern und anzeigen der Daten verwende ich einen Stack bestehend aus go-carbon, carbonapi und Grafana, was sehr anständig “performed”. Das Sammeln der Daten selber habe ich in Python implementiert - ich wollte das schon immer mal lernen, und das war ein guter Vorwand, das auch endlich mal zu tun.

Abschließend sei noch gesagt, dass es ganz interessant war, sich mal anzusehen, wie man eigentlich mit Hardware kommuniziert - verwendet habe ich die DVB API 5.11 des Linux-Kernels, und obwohl die viel weg abstrahiert war es doch ungewohnt, sich mit Dingen wie Kodierung, Modulierung, Demuxern etc. zu beschäftigen.

Gelohnt hat es sich aber auf jeden Fall - wer weiß, vielleicht kann man sobald die Gestattungsverträge auslaufen die Daten ja nochmal benutzen um die eigene Verhandlungsposition zu stärken.

docsis  hfc  pi  python