Beiträge von Senfdazugeber

Natürlich widerspricht das Deiner These. Du behauptest speedtest Apps würden irgendwelche Chipsätze erkennen. Fakt ist, daß die speedtest App überhaupt nicht erkennt, sondern einfach eine standardisierte API anspricht.

Zitat

Original geschrieben von mk25
der Chipsatz im alpha ist sehr speziell und wird u.a. von manchen Speedtests nicht richtig erkannt, d.h. die Feldstärke nicht ausgelesen

Da du jetzt eines hast, wirst du die Codes bestimmt bald finden..

Unsinn! Keine App liest irgendwas auf Hardware- bzw. Treiberebene aus. Die Feldstärke holt man sich über die android.telephony API mit der Funktion getGsmSignalStrength() und daß die android.telephony API an die Feldstärke gelangt, ist Treibersache.

Nichts davon ist korrekt. Die Drosselung erfolgt im Core Netzwork auf dem Serving GPRS Support Node (SGSN) und dort ganz bestimmt nicht über ein Java Archiv (.jar).

Die einzige Chance, die Ihr habt, ist, mit Yagi-Antennen zu arbeiten und sie so auszurichten, daß der Pegel der gewünschten Nachbarzelle höher ist als der der überlasteten Zelle. Ein LTE-Endgerät, das die softwareseitige Manipulation der Handover-Entscheidung zuläßt, ist mir nicht bekannt und sowas wirst Du auch kaum finden, zumal das bei LTE auch überhaupt nichts brächte solange der Pegel einer näheren Zelle höher ist und entsprechend starke Interferenzen bei einer etwaigen Kommunikation zur Nachbarzelle auftreten. Sowas ging bei GSM, wo es keine Frequenzüberlappungen gab, aber bei LTE ist das technisch unmöglich, da ja die Nachbarzelle dasselbe Frequenzspektrum nutzt (es sei denn die Nachbarzelle liefe in einem anderen Frequenzband).

Zitat

Original geschrieben von Anja Terchova
Angeblich ist das aber schon oefter passiert das LTE langsamer als UMTS ist.

Das ist Fakt, v.a. in ländlichen Regionen mit schlechter leitungsgebundener Breitbandversorgung, wo die LTE-Zellen dank "Vodafone LTE Zuhause" Kunden rappelvoll sind.

Meiner Beobachtung nach wählt speedtest.net die Server ausschließlich nach geografischer Distanz. Natürlich wäre es viel schlauer nach der Latenz zu gehen, aber ich vermute, daß sich dann der Traffic massiv auf wenige Server konzentrieren würde, weshalb man hier wider der technischen Vernunft handelt.

Halte diese Theorie für groben Unfug. O2 kann es sich überhaupt nicht erlauben den überwältigenden Großteil seiner Kunden mit nur einem UMTS-Träger zu versorgen. Läßt sich auch ziemlich leicht widerlegen indem man einen Samsung Androiden mit nicht-LTE-berechtigter o2 SIM-Karte zur Hand nimmt und mal in der Innenstadt einer Großstadt beobachtet, welcher Kanal nach Eingabe von *#*#197328640#*#* unter 'Debug Screen' > 'Basic Information' im Feld 'CH DL' angezeigt wird. Da taucht bestimmt auch mal 10762 oder 10738 auf.

Zitat

Original geschrieben von Magnataaa
War gestern in Hamburg Harburg und mir sind sowohl über Speedtest.net als auch dem Netmeterproject-Speedtest hohe Pingzeiten aufgefallen. Bei LTE um die 60-70 ms und UMTS rund 100/110ms... Kann das jemand bestätigen? Server war ca 13km entfernt bei speedtest.net...

Teste mal einen Server der in Frankfurt steht. Einen geographischen nahegelegenen Server zu verwenden, wie es speedtest standardmäßig tut, macht überhaupt keinen Sinn, denn gepeert wird ganz überwiegend am DE-CIX, sodaß Deine ICMP-Pakete von Hamburg über Düsseldorf nach Frankfurt und von dort aus wieder zurück nach Hamburg geleitet werden, was die Latenz maßgeblich erhöht.

Zitat

Original geschrieben von flamesoldier
Und das bringt genau was gegenüber der Versteigerung der Frequenzen direkt an die NB´s?

Verstehe Deine Frage nicht, denn ich habe mich nicht zum Vergabemodus geäußert. Aber Versteigerungen in bekannter Form schützen nur das bestehende Oligopol und entziehen diesem auch noch Kapital, das für den Netzaufbau erforderlich ist. Und der Bund mißwirtschaftet anschließend mit den vereinnahmten Erlösen.

Zitat

Dazu ist das Ganze ja im 2600 MHz Band, Liquid Broadband will aber das Frequenzen aus dem 700 MHz Band für Lau haben, die sind nicht gerade für kleine Hotspots nutzbar.

Werden sie aber nicht bekommen. Meinen Deut auf Cloudberry solltest Du etwas abstrakter betrachten - das Konzept bestimmte Versorgungsbereiche von einem neutralen Infrastrukturprovider bedienen zu lassen, läßt sich doch auch in anderem Maßstab realisieren. Statt daß dünn besiedelte Bereiche teuer von drei Netzbetreibern versorgt werden, könnte hier nur einer versorgen und die anderen drei roamen lassen. Im Prinzip wäre das auch nur eine Form des Infrastructure Sharing.

Ich denke Liquid Broadband beabsichtigt gar nicht ein flächendeckend verfügbares Netz aufzubauen. Eher vermute ich ein Geschäftsmodell wie das des norwegischen Anbieters Cloudberry dahinter - der hat 2*10MHz Spektrum im 2600MHz-Band und betreibt ausschließlich Picos und Femtos an urbanen Hotspots einschließlich vieler indoor Flächen um die großen inländischen Netzbetreiber bei sich roamen zu lassen.