Beiträge von Senfdazugeber

    [USER="222482"]spock2018[/USER]
    Du scheinst die Befürchtung zu haben, daß die Drosselung auf die vertragliche vereinbarte Bandbreite auf der Funkschnittstelle erfolge und Du bei hoher Auslastung proportional weniger Bandbreite abbekommst. Das ist nicht der Fall. Die Drosselung erfolgt vielmehr erst im Core-Netz, sodaß Du als Kunde eines langsameren Tarifs keine Nachteile in stärker ausgelasteten Zellen erleidest.

    In Tübingen wurde gestern die bislang einzige eNodeB, die interessanterweise nur auf B7 funkte, um B1 erweitert. Daher sind wahrscheinlich im Live Check für die PLZ-Bereiche 72074 und 72076 bis einschließlich morgen (8.5.) andauernde Wartungsarbeiten angekündigt. Zusätzlich werden aber für den PLZ-Bereich 72072 Wartungsarbeiten "bis spätestens 10.05.2019" angekündigt, weshalb ich spekuliere, daß der Standort in der Hegelstraße 29, 72072 Tübingen mit der STOB-Nr. 750411 diese Woche noch dran sein könnte. Das ist der einzige im PLZ-Gebiet 72072, auf dem bislang LTE genehmigt ist und zwar laut STOB vom 14.06.2018 für B1+B3+B7.

    Durch die höhere Frequenz ist die Antenne sogar kleiner wenn die Sendeleistung ausreichend ist. Schüsseln mit Nachführung sind nur bei geringen Empfangspegel und/oder wenn zuviele Sender auf der gleichen Frequenz senden und sich gegenseitig stören.

    Du hast leider überhaupt keine Ahnung wovon Du da schreibst. Mal abgesehen davon, daß Du im Ku-Band unmöglich mit ungerichteten Antennen ins All funken kannst, vernachlässigst Du einen ganz wesentlichen Umstand der Satellitenkommunikation, nämlich daß es keine exklusiven Frequenzen gibt und sich eine Vielzahl an Satelliten und deren Betreiber dieselben Frequenzen teilen, weshalb es strenge ITU-Regularien bzgl. der EIRP/PFD-Maske gibt. Selbst wenn man mit einer ungerichteten Antenne ausreichende Signalqualität erreichen würde, dürfte man das nicht.


    Zitat

    Dank der niedrigen Umlaufbahn reicht auch bei einer nahezu ungerichteten Antenne eine relativ geringe Sendeleistung aus.

    Unfug. Hier einmal ein paar exemplarische Quellen zur Antennenproblematik:
    https://spacenews.com/does-the-satel...icit-disorder/
    https://www.nsr.com/satcom-future-hi...-steered-fpas/
    https://www.nsr.com/fpas-from-a-niche-to-a-necessity/
    https://spacenews.com/satellite-ante...p-flat-panels/


    Zitat

    Oneweb hat jetzt die Finanzierung gesichert und plant ab Q4 30 Satelliten/Monat ins All zu schießen.


    https://www.oneweb.world/newsroom/on...cessful-launch

    Du solltest lieber einmal die Fachpresse lesen statt diese Schaumschlägerei aus der unternehmenseigenen Marketingabteilung für bare Münze zu nehmen: https://spacenews.com/oneweb-raises-...ing-investors/


    Demnach wird die initiale OneWeb-Konstellation von 600 Satelliten laut Gründer Greg Wyler $6 Mrd., laut externen Sachverständigen eher $7,5 Mrd. kosten, sodaß OneWeb mit ihren aktuell $3,4 Mrd. noch weit davon entfernt ist die Finanzierung gesichert zu haben. Hinzu werden sehr hohe laufende Kosten für die 50-60 Gateways samt weltumspannendem Backbone-Netz sowie die nach rund 7 Jahren erforderliche Ersetzung der kurzlebigen Satelliten kommen. Und vor allem droht von Telesat LEO, SpaceX Starlink, LeoSat und weiteren Wettbewerbern aus China ernsthafte Konkurrenz, mit der man sich den Kuchen teilen muß.
    Der Umstand, daß OneWeb nun doch nochmal $1,25 Mrd. Eigenkapital aufnehmen mußte und eben nicht, wie ursprünglich antizipiert, die verbliebene Finanzierungslücke für den Aufbau der Konstellation fremdfinanzieren kann (das ist schon seit September bekannt: https://spacenews.com/amid-concerns-...llations-cost/), zeigt genau in die entgegengesetzte Richtung, nämlich daß die Konstellation noch lange nicht durchfinanziert ist.


    Absolut nicht.
    Genau das können sie eben nicht.
    Die Antennen müssen es erstens können und das können bisher die aller, aller wenigsten bei TEF, und zweitens muss bei TEF immer zumindest mal einer zum Standort fahren, wenn es auch für wenig Aufwand ist.
    Diese relativ zügigen LTE800 Ausbauten an bestehendem GSM900 im (Nord-)Osten und mittlerweile auch viele im ländlichen Süden werden schon mit Minimaleinsatz gemacht und selbst da brauchen die Teams 1-2 Tage vor Ort.


    Für einen halbwegs ernsthaften Einsatz von 700 müssen sie die meisten Antennen tauschen und weitere ihrer typischen Systemtechnikkästchen aufstellen..

    Stimmt nicht. O2 verbaut schon seit einiger Zeit Panels mit 2 oder sogar 4 Low-Band Ports, die 698-862 MHz bzw. sogar 690-960 MHz abdecken und daher neben weiteren Bändern B20 und B28 senden können. Und die RRUs (z.B. Huawei RRU3262/3268) können auch schon B28 neben weiteren (meist B20 und B7).

    Aber ich glaube einen bundesweiten Ausbau auf 700 MHz bekommt o2 so oder so nicht auf die Reihe.


    Ich glaub wir muessen schon froh sein wenn o2 die eigentlich fuer Ende 2019 geforderte 98% Abdeckung wenigstens bis Ende 2022 auf die Reihe bekommt, und eine Abdeckung aller Grossdoerfer und POIs wenigstens bis Ende 2025.


    Wenn o2 jetzt noch alle bestehenden LTE800 und UMTS2100/LTE800 anfassen muesste, dann wird die 98% Abdeckung nicht vor 2030 erreicht.


    Du kannst davon ausgehen, daß O2 B28 an nahezu allen bestehenden B20-Standorten per Software anknipsen kann. Der Rollout könnte tatsächlich rasend schnell erfolgen, wird aber alleine wegen der Lizenzgebühren nur bedarfsweise erfolgen.

    Freunde, OneWeb wird für die Userlinks Ku-Band einsetzen, also rund 10-fach höhere Frequenzen als Satellitentelefonnetze wie Iridium, Globalstar, Thuraya. Das wird niemals von mobilen Endgeräten aus nutzbar sein, sondern große Satellitenantennen erfordern. Aktuell braucht man dafür noch mindestens zwei mechanische Schüsseln, die aufgrund der erforderlichen Nachführung sechsstellige Beträge kosten. Zwar entwickeln zahlreiche Unternehmen Flachantennen (Flat Panel Antennas), die durch Phased Array und Metamaterialien rein elektronisch eine bzw. mehrere Keulen bilden sollen, aber die werden erst einmal für den Endverbraucher unerschwinglich bleiben. Die einzige aktuell kommerziell verfügbare FPA, die mTenna von Kymeta, kostet über € 30k und kann kein Multi-Beam, ist also außer Stande einen unterbrechungsfreien Handover von Satellit zu Satellit zu bewerkstelligen (was bei OneWeb rund alle 6-8 Minuten geschehen muß).
    Zwar hofft man, daß solche Flachantennen eines Tages unter $1000 kosten werden und man auch Privathaushalte direkt versorgen kann, aber bis dahin ist es noch ein weiter Weg. Vorerst bleiben Unternehmen, Fluggesellschaften, Reedereien, Behörden und Mobilfunkanbieter die Zielgruppe für OneWeb. Mobilfunkanbietern sollen dabei den Backhaul von abgelegenen Basisstationen über OneWeb herstellen.
    Jedenfalls ist es weder technisch noch kostenmäßig möglich OneWeb oder eine der anderen Megakonstellationen als Ersatz für ein Handynetz zu nutzen - es ist primär ein Aggregationsnetz und kein Zugangsnetz.


    Davon abgesehen dauert es noch mindestens zwei Jahre bis die ersten 300 von den geplanten 600 Satelliten im All sind und der Wirkbetrieb beginnt.


    Die Latenz von OneWeb soll bei 30ms liegen. Das kann man auch ohne weiteres selbst berechnen:


    Funkwellen breiten sich annährend in Lichtgeschwindigkeit aus. Wenn man die Höhe der Umlaufbahn (1200km) kennt und den seit Jahren öffentlich zugänglichen FCC-Lizenzanträgen entnimmt, das die Bodenterminals bis zu einem minimalen Elevationswinkel von 50° mit den Satelliten funken werden, kann man folgendes errechnen:


    Maximale Distanz zwischen Bodenterminal und Satellit bei 50° Elevation: 1487km
    Maximale Distanz zwischen Gateway und Satellit bei 10° Elevation: 3130km


    Demnach beträgt der Signalweg im schlechtesten Fall 4617km bzw. für den Roundtrip das doppelte, also 9234km / 299792 km/s = 0,030801s


    Wenn wir noch etwas Toleranz für die Signalverarbeitung und das kurze Stück durch die Atmosphäre addieren, landen wir bei einem RTD von 32ms. Demgegenüber steht eine bestmögliche Latenz von geostationären Satelliten von 477ms (wenn beide Erdfunkstellen direkt unter dem Satelliten - also am selben Punkt - auf dem Äquator liegen). OneWebs Latenz wird also bei nur einem Fünfzehntel liegen. Aber das ist natürlich nur die Latenz auf der Funkstrecke - vom Gateway auf dem Boden addieren sich natürlich noch die gewöhnlichen Internet-Latenzen hinzu.


    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.

    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.

    Laut Cellmapper 5 MHz. Auf 10 MHz wird scheinbar bisher nur in größeren Städten erhöht, also an Orten wo richtig Last auf dem LTE-800 Träger ist.


    Eine entscheidende Rolle bei der Wahl der Trägerbandbreite spielt sicherlich auch die Backhaul-Bandbreite. Wo kein Glas anliegt und man Richtfunk bemühen muß, stellt die Anbindung einen Flaschenhals dar, sodaß es keinen Sinn macht unnötig Lizenzkosten für breitere LTE-Träger auszugeben.