5G - Fixed Wireless Access

  • Jeder Gamer würde dich jetzt lünchen... Sprich jedes Onlinegame.

    Klar ist jemand mit 30ms gegenüber jemanden mit 65ms Ping im Vorteil.


    Aber auf die letzten 10ms kommt es dann nicht mehr drauf an. Ausser vielleicht fuer professionelle Hardcore-Gamer.


  • Nicht nur die Gamer! Schon beim Surfen macht ein schlechter Ping überhaupt keinen Spaß. Möchte mir auch erst recht nicht vorstellen, wie katastrophal sich ein schlechter Ping vor einer Operation per Roboter machen würde...:confused:

    Zum surfen find ich alles unter 80ms okay. Zum gamen sollten es maximal 65ms, lieber aber maximal 40ms sein.


    Mit so 25-40ms kann dann auch ein Gamer gluecklich sein.


    Undd wenn mal Roboteroperation moeglich werden macht man sie wohl kam von einem Funkanschluss aus sondern fuer solche Faelle gibts Glasfaser.


    Fixed Wireless ist eher ein Home&Office Ding.

  • Sportsfreunde, bei den <10ms in 5G geht es um die Latenz auf der Luftschnittstelle, also der Kommunikation zwischen Terminal und gNodeB. Dazu kommt natürlich noch die Latenz auf dem Aggregationsnetz (Midhaul und Backhaul) bis zum nächsten Internet-Gateway und dann die ganz normalen Internet-Latenzen, die jeden betreffen - egal ob sein Internetzugang per DSL, DOCSIS oder Glasfaser erfolgt.


    In dem zu oberst verlinkten Video sieht man, daß ein Speedtest zu einem Interoute-Server in Frankfurt durchgeführt wird. Dessen IP lautet 213.251.53.187. Wie Ihr im nachfolgenden Traceroute sehen könnt, ist der ca. 15ms vom Access-Router von O2 in Hamburg entfernt und die Route passiert dabei auch noch die Netze von zwei fremden IP-Transit Providern, nämlich Telxus (AS12956) und GTT (AS3257) - und welchen Weg die Datenpakete auf dem Rückweg nehmen, bleibt wie üblich im Internet ein Geheimnis:


    traceroute to 213.251.53.187 (213.251.53.187) 64 hops max, 76 byte packets
    1 192.168.179.1 (192.168.179.1) [AS???] 7.436 ms 1.345 ms 1.342 ms
    2 loopback1.0002.acln.01.ham.de.net.telefonica.de (62.52.200.148) [AS6805] 8.783 ms 8.244 ms 48.015 ms
    3 bundle-ether28.0006.dbrx.01.ham.de.net.telefonica.de (62.53.12.18) [AS6805] 9.29 ms 8.211 ms 8.182 ms
    4 ae5-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.232) [AS6805] 14.947 ms 20.712 ms 22.573 ms
    5 ae6-0.0002.corx.02.fra.de.net.telefonica.de (62.53.0.49) [AS6805] 14.895 ms 15.204 ms 15.044 ms
    6 bundle-ether6.0001.dbrx.02.fra.de.net.telefonica.de (62.53.0.127) [AS6805] 15.458 ms 14.982 ms 14.996 ms
    7 bundle-ether1.0004.prrx.02.fra.de.net.telefonica.de (62.53.8.187) [AS6805] 14.981 ms 14.935 ms 14.931 ms
    8 176.52.252.28 (176.52.252.28) [AS12956] 14.816 ms 15.016 ms 14.921 ms
    9 5.53.4.29 (5.53.4.29) [AS12956] 15.209 ms 14.976 ms 15.008 ms
    10 94.142.107.13 (94.142.107.13) [AS12956] 15.06 ms 23.667 ms 20.141 ms
    11 interoute-gw.ip4.gtt.net (77.67.82.142) [AS3257] 15.683 ms 18.324 ms 15.362 ms
    12 ae1-0.fra-006-score-3-re0.interoute.net (84.233.207.114) [AS8928] 15.131 ms 14.887 ms 14.866 ms
    13 213.251.53.187 (213.251.53.187) [AS8928] 15.621 ms 15.216 ms 15.206 ms


    Das wäre wohl die denkbar direkteste Route vom O2 POP in Hamburg zu Interoute. Anzunehmen ist jedoch, daß O2 das 5G Core-Netz in der Unternehmenszentrale ein München aufgebaut hat und der ganze Traffic aus Hamburg erst einmal nach München gebackhauled wird bevor er über das dortige Internet-Gateway zu den Interoute-Servern nach Frankfurt läuft. So oder so sind die 26ms ein passabler Wert.


    Was man bei diesem ganzen Gewäsch über 5G und die geringen Latenzen auch beachten muß, ist daß das Internet bis heute immer noch recht zentral aufgebaut ist und es recht wenig bringt die Latenz auf der Luftschnittstelle zu reduzieren, wenn der Traffic danach kreuz und quer durch's Land oder den Kontinent geroutet wird. Für die ganzen ultra-low latency Anwendungen wird man da auch noch sehr viel an der Netz-Architektur verändern müssen und v.a. die Server näher an die Edge bringen müssen.


    Und noch ein kleiner Exkurs: Glasfaser ist ein Festkörper und bremst als solcher die Ausbreitung des Lichts. Tatsächlich erreicht Licht in der Glasfaser nur 204,190,477 m/s, also rund ein Drittel weniger als die Lichtgeschwindigkeit (299,792,458 m/s). Da elektromagnetische Wellen in der Atmosphäre annährend Lichtgeschwindigkeit erreichen haben per Richtfunk angebundene eNB/gNB daher immer bessere Latenzen als solche, die per Glasfaser angebunden sind. Dazu kommt natürlich, daß Richtfunk einen direkteren Weg nimmt als die meist Verkehrswegen entlang gelegte Glasfaser. Nicht umsonst haben sich die Hochfrequenzhändler Richtfunkstrecken zwischen den großen Finanzhandelsplätzen einrichten lassen um durch die eingesparten Milli- und sogar Nanosekunden ihre Arbitragegewinne erhöhen zu können (siehe https://arstechnica.com/information-...financial-hft/).


    Merke: Wenn man von Latenzen spricht, dann immer die Gegenstellen definieren.

  • [USER="18086"]sailing2capeside[/USER] [USER="219829"]habehandy[/USER] [USER="203826"]Senfdazugeber[/USER]


    Hm, komplexer als ich dachte. Bedanke mich für die Kommentare hinsichtlich dieser Thematik. :)

  • Was auffällt sind relativ hohe Pingwerte. Theoretisch war immer die Rede von niedriger Latenz (weniger als 10 Millisekunden). Oder wieder nur Marketing, real nicht machbar?


    Es hat ja niemand gesagt, dass 5G grundsätzlich niedrigere Latenzzeiten als LTE bieten wird. 5G wird ganz verschiedene Anwendungsszenarien bieten, eine davon ist WTTH, eine andere kann MMTC (massive machine type communication) sein und eine dritte zum Beispiel URLLC (ultra reliable low latency communication). Welche dieser Komponenten der Operator in seinem 5G Netz realisiert und in welcher zeitlichen Abfolge, ist nicht definiert. 5G besteht also anders als LTE aus vielen verschiedenen "Komponenten" oder auch Network Slices.

  • Der Ping war schon immer bei 5G bis zum Server, welcher am Mast hängt angesagt. Für die schnelle Kommunikation der Autos untereinander. Es war nie die Rede davon, dass der PING zu Servern am anderen Ende von Deutschland auch so schnell ist.


    Lediglich für die Kurzstrecken und da wurde immer von Autos gesprochen, welche hintereinander fahren und man dort schnelle Reaktionen benötigt, wenn der Vordermann hinter der Kurve meldet, dass es einen Stau gibt und alle hinter ihm schnell mal abbremsen sollten. Hier sollte der Ping klein sein.


    Wenn ich mich nicht irre, werden diese Informationen (oder sollen diese Informationen) direkt am Mast aufbewahrt werden.


    Niemand hat gesagt das ein Arzt in Bayern jemanden über 5G im Ruhrgebiet mit 1ms operieren kann und soll und wird.


    Die Ping werte sind für so einen Test mehr als ordentlich. Manche VDSL Anschlüsse haben schlechtere PINGs, manche auch bessere.

  • Es hat ja niemand gesagt, dass 5G grundsätzlich niedrigere Latenzzeiten als LTE bieten wird. 5G wird ganz verschiedene Anwendungsszenarien bieten, eine davon ist WTTH, eine andere kann MMTC (massive machine type communication) sein und eine dritte zum Beispiel URLLC (ultra reliable low latency communication). Welche dieser Komponenten der Operator in seinem 5G Netz realisiert und in welcher zeitlichen Abfolge, ist nicht definiert. 5G besteht also anders als LTE aus vielen verschiedenen "Komponenten" oder auch Network Slices.


    Aus meiner Sicht ist die Formulierung "hat ja niemand gesagt" eine Übertreibung. Nur mal so als Beispiel: Was schreibt denn die englische Wikipedia zu 5G? Zitat: "However, the speeds and latency in early deployments, using 5G NR software on 4G hardware (non-standalone), are only slightly better than new 4G systems, estimated at 15% to 50% better."


    Also, da steht wortwörtlich: Zu Beginn, leichte Verbesserung der Latenz + Geschwindigkeit, ungefähr 15 - 50 Prozent gegenüber existierenden LTE Anlagen. Geschwindigkeit ja eindeutig, ist im Test zu sehen. Beim Ping irgendwo zwischen 20 - 30 ms oder knapp drunter. Im LTE Netz von Telefónica sind 25 ms nichts Ungewöhnliches. Ja, 5G soll skalierbar sein, entsprechend der Anwendung. Ich wäre jetzt erst mal davon ausgegangen (unabhängig von speziellen Anwendungen / Modi), dass die Latenz generell niedriger ist. Scheint so nicht zu sein, deswegen wurde ich eines Besseren belehrt. Wie die Kommentatoren nachvollziehbar erläuterten, abhängig von zusätzlichen Faktoren.


  • doch, genau das soll ein 5G use case sein und wurde auch verschiedentlich so publiziert


    https://www.itproportal.com/ne…healthcare-possibilities/


  • 3 bundle-ether28.0006.dbrx.01.ham.de.net.telefonica.de (62.53.12.18) [AS6805] 9.29 ms 8.211 ms 8.182 ms
    4 ae5-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.232) [AS6805] 14.947 ms 20.712 ms 22.573 ms


    Naja, böse gesagt von 8,2ms auf 20,7ms bei Übergabe vom Segment in den Core-Network Bereich.




    Dazu muss man sagen, dass die Latenz an dem Punkt durch Telxus nicht merklich erhöht wird. Was viel interessanter ist, warum der Traffic durch AS12956 geht, obwohl alle drei am DE-CIX FRA peeren (Vgl. PeeringDB der jeweiligen AS-Ids) und "bestimmt" ein DirectPeering (nicht öffentlich aus PeerindDB einsehbar) vorliegen wird (dazu unten mehr), welches theoretisch auf etwaige Fehlkonfigurationen, Route-Prepending (Gewichtung-/Kostenfakotr oder ähnlichem) hinweisen könnte, aber Telxius Telecom SA ist letztlich Telefonica als Tier 1.



    [...] und welchen Weg die Datenpakete auf dem Rückweg nehmen, bleibt wie üblich im Internet ein Geheimnis:


    Ja und nein... Hier zurück bis zu deinem ersten outhome HOP resp. BRAS bei Dir in Hamburg:


    Der nächste HOP ist direkt Telefonica...


    Whatever: Was man aber immer beachten sollte, wie du schon schreibst, bei Latenzen/Ping Tests ist die Gegenstelle immer wichtig, die Betrachtung der Hops (auch hier sind Darkfibers nicht ersichtlich, wie du ja auch schon schriebst bzgl. Verbindung MUC <-> HAM) und idR. de-priorisiert die Forward-Engine bei $X% Last sowieso.



    Insgesamt sieht man also, dass es selbst via Festnetzanschluss bei [USER="203826"]Senfdazugeber[/USER] schon "hohe" Latenzen über das Core-Network bei O2 vorliegen und nicht grundsätzlich an 5G liegen.


  • Naja, böse gesagt von 8,2ms auf 20,7ms bei Übergabe vom Segment in den Core-Network Bereich.

    Da sich die Hops 3 und 4 ausweislich ihres DNS-Namens beide in Hamburg befinden, vermute ich, daß der rapide Anstieg zwischen den beiden um 12ms an der Depriorisierung von ICMP liegt und Hop 4 einfach aufgrund seiner Auslastung verzögert geantwortet hat. Wenn die 12ms tatsächlich aufgrund geografischer Distanz entstanden sein sollten, müßten die beiden Hops über 1200km auseinanderliegen.


    Zitat

    Dazu muss man sagen, dass die Latenz an dem Punkt durch Telxus nicht merklich erhöht wird.

    Auch der Transit über GTT erhöht die Latenz nicht maßgeblich, weil die Route von Telefonica über Telxius und GTT zu Interoute offenbar innerhalb Frankfurts verlief. Ich wollte mit den beiden involvierten Transit-Providern aber nicht die Latenz erklären, sondern vielmehr aufzeigen, daß Datenpakete im Internet oft für den Laien kaum nachvollziehbare Wege nehmen und jedes Segment die Latenz erhöht (und übrigens auch bandbreitenmäßig einen Flaschenhals bilden kann).


    Zitat

    Was viel interessanter ist, warum der Traffic durch AS12956 geht, obwohl alle drei am DE-CIX FRA peeren (Vgl. PeeringDB der jeweiligen AS-Ids) und "bestimmt" ein DirectPeering (nicht öffentlich aus PeerindDB einsehbar) vorliegen wird (dazu unten mehr), welches theoretisch auf etwaige Fehlkonfigurationen, Route-Prepending (Gewichtung-/Kostenfakotr oder ähnlichem) hinweisen könnte, aber Telxius Telecom SA ist letztlich Telefonica als Tier 1.

    Du unterliegst wie viele (und ich lange Zeit auch) dem Irrtum, daß die Teilnahme an einem Internetknoten wie dem DE-CIX mit offenem Peering gleichzusetzen ist, sprich jeder DE-CIX-Teilnehmer mit jedem anderen Datenverkehr austauscht ("peert"). Das ist aber nicht der Fall. Internetknoten sind erst einmal nur eine Plattform zur physichen Konnektivität. Ob und in welchem Umfang ein Teilnehmer tatsächlich mit anderen Teilnehmern Datenverkehr austauscht ("peert"), ist eine Frage der BGP-Sessions und steht insoweit auf einem anderen Blatt geschrieben. Grundsätzlich kann man zwar per Route-Server allen Teilnehmern seine Präfixe (IP-Adressbereiche) per BGP annoncieren und "offen" mit jedem anderen Teilnehmer peeren, in der Praxis machen das aber die wenigsten Teilnehmer und insbesondere die großen IP-Transit-Provider nicht, denn damit würden sie sich ihr eigenes Geschäft, nämlich die entgeltliche Durchleitung von Datenverkehr, kaputt machen. Tatsächlich peeren viele DE-CIX Teilnehmer nur auf individueller Basis mit anderen Teilnehmern, wofür die beiden Parteien eine entsprechende BGP-Session konfigurieren müssen und das wiederum geschieht oft nur gegen Bezahlung.
    Peeringdb listet für den DE-CIX Frankfurt zwar 560 Netze mit "open peering policy", 317 als "selective" und 29 als "restrictive", jedoch heißt "open peering" noch lange nicht, daß der Teilnehmer alle seine Präfixe annonciert.
    Vor diesem Hintergrund verwundert es auch nicht, daß Du im looking glass vom DE-CIX Frankfurt unter AS12956 (Telxus) keinen einzigen der Präfixe aus meinem Traceroute findest (176.52.248.0/21, 5.53.0.0/21, 94.142.107.13). Und wenn Du im looking glass nach GTT (AS3257) schaust, wirst Du verwundert feststellen, daß kein einziger Eintrag erscheint, weil GTT dem Route-Server und damit der "open BGP Community" schlicht überhaupt keine Netze annonciert. Da GTT laut peeringdb lediglich einen 1G-Port am DE-CIX Frankfurt hat, ist auch klar, daß sie da nicht wirklich ernsthaft peeren.


    Zitat

    Ja und nein... Hier zurück bis zu deinem ersten outhome HOP resp. BRAS bei Dir in Hamburg:

    Sitze gar nicht in Hamburg, sondern habe https://www.globaltraceroute.com/ verwendet (was seinerseits auf den RIPE Atlas Probes basiert), aber das ist nebensächlich.


    Zitat

    Der nächste HOP ist direkt Telefonica...

    Hast Du den traceroute aus dem Interoute-Netz (AS8928) gemacht? Aber egal, von wo aus Du ihn gemacht hast, wurdest Du offensichtlich von GTT ohne Umweg über Telxius direkt zu Telefonica Deutschland geroutet, was eben genau die erwähnte Asymmetrie des Internetroutings aufzeigt.


    Zitat

    Whatever: Was man aber immer beachten sollte, wie du schon schreibst, bei Latenzen/Ping Tests ist die Gegenstelle immer wichtig, die Betrachtung der Hops (auch hier sind Darkfibers nicht ersichtlich, wie du ja auch schon schriebst bzgl. Verbindung MUC <-> HAM) und idR. de-priorisiert die Forward-Engine bei $X% Last sowieso.

    Nicht nur dark fibres sind nicht ersichtlich, sondern alles, was auf Layer-2 passiert ist für den Internetnutzer völlig unsichtbar. Zwischen den im Traceroute auftauchenden Hops können theoretisch noch dutzende Switches und Leitungssegment liegen. Wieviel Layer-2 Routing vom User versteckt ist, kann man ganz gut sehen, wenn man von amerikanischen ISPs Traceroutes zu deutschen Telekom-Anschlüssen macht. Hier einmal von AT&T in San Francisco (Atlas RIPE Probe Nr. 17797) zu einer Telekom IP-Adresse im Raum Stuttgart:


    traceroute to 79.209.61.130 (79.209.61.130) 64 hops max, 76 byte packets
    1 192.168.1.254 (192.168.1.254) [AS???] 1.589 ms 0.666 ms 0.66 ms
    2 adsl-71-145-208-1.dsl.austtx.sbcglobal.net (71.145.208.1) [AS7018] 2.302 ms 5.687 ms 3.602 ms
    3 71.148.149.94 (71.148.149.94) [AS7018] 1.837 ms 1.405 ms 1.22 ms
    4 12.122.149.190 (12.122.149.190) [AS7018] 11.796 ms 13.648 ms 13.721 ms
    5 12.122.28.121 (12.122.28.121) [AS7018] 18.041 ms 14.236 ms 13.162 ms
    6 gar29.la2ca.ip.att.net (12.122.129.233) [AS7018] 11.897 ms 13.735 ms 13.709 ms
    7 193.158.5.9 (193.158.5.9) [AS3320] 10.982 ms 10.845 ms 10.951 ms
    8 87.137.235.93 (87.137.235.93) [AS3320] 167.706 ms 182.013 ms 167.408 ms
    9 p4fd13d82.dip0.t-ipconnect.de (79.209.61.130) [AS3320] 180.842 ms 181.579 ms 182.154 ms


    Von Hop 7 (193.158.5.9), der offenbar in Los Angeles steht, zu Hop 8 (87.137.235.93), hinter dem sich ein Core-Router in Stuttgart verbirgt, besteht offenbar eine direkte Route. Natürlich hat die Telekom keine direkte Glasfaserstrecke bzw. durchgeschleifte Wellenlänge von Los Angeles bis nach Stuttgart, sondern verwendet hier MPLS oder irgendein anderes Protokoll unterhalb von Layer 3, sodaß die sicherlich ein halbes dutzend Router unsichtbar bleiben. Das macht man übrigens aus Effizienzgründen, weil Layer-3 Router teuer und aufwändig zu warten sind.


    Zitat

    Insgesamt sieht man also, dass es selbst via Festnetzanschluss bei [USER="203826"]Senfdazugeber[/USER] schon "hohe" Latenzen über das Core-Network bei O2 vorliegen und nicht grundsätzlich an 5G liegen.

    Inwieweit die Latenz nun im Internet steigt und wieviel davon im Backhaul- bzw. Core-Netz entsteht, sei einmal dahingestellt. Mit großer Sicherheit ist der Anteil der 5G-Luftschnittstelle aber verschwindend gering.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!