Kann man aus dem First Seen Wert zumindest schließen, dass er zumindest im letzten Jahr errichtet wurde, oder kann es genau so sein, dass er einfach über Jahre noch nicht gemappt wurde?
Ich sehe bei "first seen" den 19.04.2019, das deckt sich mit der "first seen"-Angabe aus den Daten der Mozilla Location Services, daher würde ich davon ausgehen, dass er dieses Jahr errichtet wurde. Insbesondere da er auch in der LTE-Ausbau-Liste für die Woche 19.04.2019 - 26.04.2019 enthalten war.
Keine Regel ohne Ausnahme.
Auch die 6-stelligen sind nach derselben Regel gebildet, wie die 5-stelligen. 
Aber "in der Regel" bedeutet ja auch nur "meistens".
Da stimme ich Dir im Prinzip zu, allerdings habe ich mir angewöhnt, nach Regeln zu suchen, die nur noch ein Minimum an Ausnahmen übrig lassen. Bei "in der Regel 5-stellig" bliebe eine für mich zu große Zahl an Ausnahmen zurück.
Einigen wir uns doch auf die Formulierung "eNode-IDs sind bei O2 in der Regel mindestens 5-stellig". (Jetzt bin ich gespannt, ob doch jemand eine 4-stellige im Produktivnetz findet).
(fünfstellig ist ja die Regel)
Öhm, nö. Hier in meiner Umgebung haben DT und O2 6-stellige eNB-IDs und mindestens bei O2 gibt es noch weitere solche Regionen.
Wollte mal auf einen kleinen Setzfehler der eNB ID 21734 von o2 in der nördlichen Altmark hinweisen.
Der ist zur Zeit bei Iden gesetzt gehört aber zu dem Standort bei Werben.
Stimmt, erledigt.
Wer hat denn die eNB ID 181 von o2 im Atlantischen Ozean verfrachtet?
Das dürften fehlerhafte Daten sein, vermutlich ein GSM-Sektor dessen Daten als LTE interpretiert wurden. Manche CM-Nutzer schieben solche fehlerhaften Sender ins Ausland, denn nach Löschung kommen sie oft neu rein.
eNB ID 109273 müsste auch mal Platziert werden.
Nein, gelöscht:
- eNodeID passt so garnicht in diese Region
- TAC war falsch
- Sektor-ID war falsch
Vermutlich auch fehlerhafte Daten
Mich hat eher nur gewundert das man in Suedbayern so wenig geaendert at.
Die haben bei Euch "oben" geprobt und dann gemerkt, dass sie bei uns "unten" weniger ändern müssen.
Spaß beiseite: Wir hatten eine Zeit lang Übergangs-LACs/TACs für GSM/LTE für frisch konsolidierte Sender in 5305x, die dann auf 5105x geändert wurden. O2-Alt war vorher in 5104x, wurde von daher schon auch geändert.
BTW: In Suedbayern nutzt o2 LTE neuerdings wohl 515xx TACs wobei 515xx aber auch der Bereich ist der dort vor der Konsollidierung fuer UMTS LACs genutzt wurde.
Die alten UMTS LACs gingen bis 51509, die neuen LTE-TACs sind im Prinzip eine feinere Aufteilung der vorherigen:
Aus 51x5y (mit x aus 0 oder 1) wurde 515yz (und durch mehrere z entsteht die Aufteilung in kleinere Areas).
... und drittens weil der Upload immer die höchste Geschwindigkeit hat.
Das schließt eine Überlastung (der Anbindung) nicht aus. Die Anbindung der eNode ist symmetrisch, die Nutzung stark asymmetrisch, d.h. schlechte Downloadraten aber gute Uploadraten sind im Gegenteil sogar ein Indiz für eine Überlastung der Anbindung.
Der Download geht auf bis zu 70 MBit/s und sofort fällt der Download stark zurück.
Auch das spricht nicht gegen eine Überlastung (der Anbindung) aber deutlich für aktives Traffic-Shaping: Ein kurzer Burst mit hoher Datenrate wird durchgelassen, danach setzt der Shaper ein.
@o2 ist jetzt wohl schohn im Sommerferien Modus bei der Länge der Liste ;):(
Eher im Pfingstferienmodus, die waren nämlich gerade. Dementsprechend könnte ich mir vorstellen, dass die Liste am 28.6. auch nochmal kürzer ausfällt (Nachwirkungen der Pfingstferien) und es dann wieder mehr wird.
Und die die bei Cellmapper gemessen haben, haben keinen Plan.
Na was ein Glück, dass Du wenigstens einen Plan in der Konfiguration DSLAMs und eNodeBs hast und mit so viel Plan findest Du sicher auch den Weg nach nebenan in den passenden Thread für Störungen und Netzausfälle. Hier geht es nämlich um LTE-Ausbau.
