[INFO] Fast Dormancy

[Rob2222]

Huhu,

Fast Dormancy ist das schnelle Zurückschalten in einen energiesparenden UMTS Zustand nach jedem Datentransfer.

UMTS hat für die Luftschnittstelle verschiedene Zustände, die verschieden viel Energie benötigen. Der Energiebedarf in Relation zum IDLE Zustand mal in Klammern angegeben.
DCH (100x) (Datentransfer möglich)
FACH (50x) (Datentransfer sehr begrenzt möglich)
PCH (1x-2x) (ein besserer Bereitschaftszustand)
IDLE (1x) (Bereitschaft (idle))

Ob ein IDLE oder ein PCH Zustand als Bereitschaftszustand verwendet wird, hängt von der Konfiguration der UMTS Zelle ab, in der Ihr Euch gerade befindet.
FACH und DCH nicht mit 3G und H(+) gleichsetzen! Das ist nicht so. FACH ist ein Funkkanal, den sich alle Handys in der Funkzelle teilen und der nur 32kBit/s hat. (Link)


Wenn das Handy keine Daten überträgt, ist es in einem der energiesparenden idle-Zustände IDLE oder PCH.
Will das Handy nun Daten übertragen, muß es von dem Bereitschaftszustand (IDLE bzw. PCH) in den energieintensiven Übertragungszustand DCH hochschalten.
Da DCH jetzt aber den hundertfachen Energiebedarf von IDLE hat, will man natürlich nicht länger als nötig in dem energieintensiven Übertragungszustand DCH bleiben.

Wenn FD aktiviert ist, schaltet das Handy nach einem kurzen Timer (oft 5 Sekunden) zurück in den Bereitschaftszustand (IDLE bzw. PCH).
Wenn FD deaktiviert ist, hängt es von der Konfiguration der Funkzelle ab, in der Ihr Euch gerade befindet, wie schnell in einen der Bereitschaftszustände IDLE oder PCH runtergeschaltet wird.

Der Timer, wie lange nach der letzten Datenübertragung noch in DCH geblieben wird, heißt T1.
Der Timer, wie lange dann noch in FACH geblieben wird, heißt T2.
Also, wenn der letzte Datentransfer abgeschlossen ist gilt: DCH ==(Zeit:T1)==> FACH ==(Zeit:T2)==> IDLE bzw. PCH.

Wie schnell das Handy in einen energiesparenden Bereitschaftsmodus schaltet, hängt also bei deaktiviertem FD von Eurem Netzanbieter bzw. sogar von der Funkzelle ab.
Die Funkzellen eines Anbieters sind durchaus verschieden konfiguriert. Zumindest haben wir schon verschiedene Konfigurationen bei Vodafone und E-Plus gesehen. Bei T-Mobile und O2 wird es nicht anders sein. Hier mal ein paar Beispiele von Konfigurationen aus Italien 2011.

Bei deaktiviertem FD:
Läßt meine Vodafone Zelle hier, mein Handy nach einem Datentransfer für 5 Sekunden im Zustand DCH (T1), dann für 30 Sekunden im Zustand FACH (T2) und schaltet zum Schluß auf IDLE.
Also: DCH ==(5s)==> FACH ==(30s)==> IDLE.

Läßt meine E-Plus Zelle hier, mein Handy nach einem Datentransfer für 10 Sekunden im Zustand DCH (T1), dann für 2 Sekunden im Zustand FACH (T2) und schaltet zum Schluß auf PCH.
Also: DCH ==(10s)==> FACH ==(2s)==> PCH.

(NB: Unterwegs habe ich umgedreht auch schon Vodafone Zellen gesehen, die schnell zurückschalten und PCH nutzen und wiederum auch E-Plus Zellen, die längere Timer haben und IDLE benutzen. Es kommt also wirklich auf die Zelle drauf an. Einheitliche Aussagen für alle Zellen eines Netzbetreibers kann man scheinbar noch nicht geben, da die Zellen der Reihe nach modernisiert werden.)

Manche Anbieter/Zellen, schalten das Handy bei deaktiviertem FD ausreichend schnell zurück in einen der energiesparenden Zustände IDLE oder PCH. In dem Fall könnte man FD im Handy guten Gewissens abschalten.


Was die Betrachtung von Fast Dormancy (FD) nun etwas verkompliziert ist der Punkt, daß es zwei verschiedene Versionen von Fast Dormancy gibt.
Einmal ein FD, welches die Handyhersteller entwickelt haben (2006 oder früher, ich nenne es hier mal FD-alt), und ein Standartisiertes nach 3GPP-Release8 (12/2008, das nenne ich hier mal FD-neu).

Wie man an dem Beispiel meiner Vodafone Zelle hier zu Hause sieht, ist es schlecht, wenn das Handy nach jedem Datentransfer für 5 Sekunden in dem energieintensiven Zustand DCH und dann nochmal 30 Sekunden in dem auch noch energieintensiven Zustand FACH bleibt, selbst wenn das Handy schon weiß, daß in den nächsten 35 Sekunden gar kein weiterer Datentransfer stattfinden wird.
Die schlechte Akkuleistung bleibt natürlich nicht an dem Netzbetreiber hängen, sondern an dem Handyhersteller. Also haben sie sich hingesetzt und FD-alt entwickelt. Wenn das Handy bei aktiviertem FD-alt weiß, daß in den nächsten Sekunden kein Datentransfer mehr folgen wird, läßt das Handy die Verbindung einfach nach einem kurzen Timer von vielleicht 5 Sekunden von DCH zurück auf IDLE zurückfallen.

Also kann das Handy nach gewissen Datentransfers (wenn es weiß, daß in den nächsten Sekunden keine Daten mehr folgen werden) bei aktiviertem FD-alt superschnell in den energiesparenden IDLE Zustand.

Also alles wunderbar, Ziel erreicht. Nunja, nicht ganz. FD-alt hat durchaus markante Nachteile.
Zum Einen dauert das Hochschalten von IDLE auf DCH rund 2,5 Sekunden, bis überhaupt Daten übertragen werden können. Wenn man auf einen LINK in einer Webseite klickt, merkt man diese Verzögerung deutlich und das kann schon etwas nerven.

Zum Anderen löst das andauernde Hochschalten und das selbstständige Runterschalten von FD-alt bei jedem Datentransfer einen massiven Signalisierungsaufwand in der Netzwerktechnik der Mobilfunkanbieter aus. Wenn das Handy nach 5 Sekunden herunterschaltet und der Kunde nun nach 6 Sekunden einen Link klickt, hat der Mobilfunkanbieter ein Herunterschalten und ein Hochschalten mehr Signalisierungsaufwand als ohne FD. Gerade als die Smartphones mehr und mehr wurden, fiel den Mobilfunkanbietern dieses Problem, welches die Handyhersteller mit der Entwicklung von FD-alt erzeugt haben, in den Rücken.

Dazu kommt dann auch noch ein großes Problem, daß eigentlich das Mobilfunknetz bestimmen sollte, wann in welchen Zustand geschaltet werden soll. Einige (wenige) Mobilfunknetze/Zellen kamen nicht damit klar, daß die Handy nun einfach selbständig und ohne Rücksprache mit dem Netz die Datenverbindung von DCH zu IDLE zurückfallen ließen. Das führte dann in den betroffenen "inkompatiblen" Zellen zu einem ständigen Hin und Her und zu einem starken Akkuverbrauch, bis der Benutzer FD-alt in seinem Handy abschaltete. Das wiederum führte zu der in der Community verbreiteten (Falsch-)Aussage "Fast Dormancy im Handy deaktivieren, um Akku zu sparen". Im Normalfall ist das Gegenteil der Fall, nur wenn man wirklich in so einer Problemzelle war sollte man FD abschalten. Und ich habe Meldungen diesbezüglich bis jetzt nur bei den XDA-Devs bei Funkzellen in den USA gelesen. Trotzdem wird nun immer Halbwissen weitergeben und es wird geraten, FD blind zu deaktivieren.


Also war FD-alt eher eine Maßnahme der Handyhersteller, ihre Akkuleistung in 3G UMTS Netzen zu retten bzw zu verbessern und noch lange nicht der Weisheit letzter Schluß. Aufgrund der Probleme setzten sich nun die Mobilfunkanbieter und die Handyhersteller zusammen überarbeiteten Fast Dormancy und standartisierten es in 3GPP-Release8. Ich nenne das jetzt hier FD-neu.

In FD-neu wurde das schnelle Zurückschalten in einen der energiesparenden Bereitschaftszustände wieder zwischen Handy und Mobilfunknetz koordiniert. Das verringert den unnötigen Signalisierungsaufwand in den Mobilfunknetzen erheblich.

Dazu nutzen die Mobilfunkzellen nun auch öfter den PCH Bereitschaftszustand. Das ist aber kein Muß. Der PCH Zustand hat gegenüber IDLE den riesen Vorteil, daß das Hochschalten in den DCH-Übertragunszustand nur 0,5 (statt 2,5) Sekunden dauert. Davon profitiert dann in erster Linie der Kunde. Nach dem Klick auf den Link 2 Sekunden weniger Wartezeit. Da nun das Hochschalten wesentlich schneller vonstatten geht, darf man natürlich auch schneller Runterschalten, da man dem Kunden beim erneuten Hochschalten ja keine 2,5 Sekunden Wartezeit zumuten muß. Und das Handy spart auch noch Strom dabei. Also eine win-win Situation für Kunde, Handyhersteller und Mobilfunkanbieter.

Zwischenfazit: Man sollte Fast Dormancy keineswegs blind deaktivieren! Es ist durchaus ein sehr sinnvolles Feature.

Und bevor jetzt die Frage kommt: "Ich bin im Netz XY, unterstützt das Fast Dormancy?" => Ich habe keine Ahnung.
Mit dem Wissen dieses Beitrags stelle ich mal die Gegenfrage in den Raum: Was bedeutet die Frage "Unterstützt Netz XY Fast Dormancy?"

-Bedeutet es, daß das Netz "kompatibel" zu FD-alt ist?
-Oder bedeutet es, daß das Netz schon von alleine kurze Zurückschalt-Timer T1 und T2 nutzt?
-Oder bedeutet es, daß das Netz PCH statt IDLE als Bereitschaftszustand nutzt?
-Oder bedeutet es, daß das Netz schon vollständig in allen Zellen FD-neu nutzt?

Ich weiß es wirklich nicht. Gerade wenn man jetzt (2012) sieht, daß z.B. mindestens Vodafone und auch E-Plus noch verschiedene Konfigurationen in ihren Zellen haben, macht es eigentlich keinen Sinn, da eine einheitliche Aussage für ein ganzes Netz zu treffen.

Das bringt mich dann auch zum eigentlichen Fazit:
Wenn ihr das S3 im Originalzustand nutzt, oder ein CustomRom mit der korrekten FD-Netzwerkdatenbank in der CSC, dann ist bei Euch bereits alles sinnvoll und korrekt konfiguriert. Ihr müßt nichts ändern oder umschalten.


Das S3 hat in der CSC eine Datenbank, in denen die Dormancy Settings für die verschiedenen Provider enthalten sind. (/data/data/com.android.providers.telephony/databases/nwk_info.db).
In der Datenbank ist FD für alle deutschen Mobilfunkanbieter konfiguriert und das FD-Timeout ist auf 5 Sekunden bei angeschaltetem Display und auch auf 5 Sekunden bei ausgeschaltetem Display festgelegt.
Wenn ihr diesen Beitrag komplett verstanden habt, und etwas Experimentieren und Beobachten möchtet, könnt ihr FD in dieser Datenbank abschalten, das Handy neustarten und unter *#0011# am Ende jedes Datentransfers die Zeiten der Wechsel der RRC-Zustände beobachten.


Weiteren Lesestoff gibt es hier im Forum schon in dem alten Thread zum Thema: LINK
Solltet Ihr speziell zu diesem Artikel fragen haben, stellt diese aber ruhig hier im Thema.


Viele Grüße
Robert

PS: Nachlesen könnt ihr das hier, hier, hier, hier und im vollen Detail hier und hier.
Etwas zu RRC-States. Noch eine weitere, verständliche Quelle: hier .


EDIT: Komplette Überarbeitung des Artikels 28.10.2012.

[smartis70]

Wo kann man das einstellen?

Gesendet vom SGSIII mit Tapatalk2.

[Rob2222]

Man muß die Datenbank unter der angegebenen Datei mit einem SQ-Lite Editor bearbeiten.
Zum Beispiel mit dem SQLite Editor. Allerdings ist es keine kostenfreie App und man braucht Root Rechte.

Gruß
Rob

[trigg3r]

bin mir nicht sicher aber ich glaub der Syiah kernel bringt ne App mit. Oder es war die Custom Rom. Das war aber noch unter ICS

[g0dsCookie]

Du meinst nicht zufällig "Fast Dormancy Toggle i9300" im AppDrawer?
Die ist mir erst mit Jelly Bean aufgefallen irgendwann. ^^

[Rob2222]

Huhu,

ja, aber wenn ich mich recht entsinne, setzt diese Fast Dormancy Toggle App die Timeout Werte nur auf 0 oder danach blind zurück auf 5 Sekunden. Egal wie sie davor eingestellt waren. Dazu war nach dem Test der App in der Datenbank hinter der 5 noch ein Steuerzeichen, was davor nicht da war. Kann sein, daß das nichts ausmacht, aber das weiß ich nicht.
Aus dem Grund habe ich nicht gleich auf diese App verwiesen.

Gruß
Rob

[trigg3r]

jo genau die APP^^

[blackn01s3]

Die größten Anbieter unterstützten aber dieses features und es funktioniert eigentlich sehr gut.

Kann bestätigen das tmobile, Vodafone und O2 es nutzen.

ıllıllı ... ѕenт ғroм нell wιтн мy ѕgѕιιι (gт - ι9300) ... ıllıllı

[spline]

Anhand der Datenbank kann man auch eine Liste machen, welcher Provider FD unterstützt.
In Österreich zum Beispiel alle ausser "drei".

Erfahrungsgemäß haben fast alle Custom Rom's oder Firmwares (CSC) anderer Länder nicht die korrekten Einstellungen der ...telephony.provider ...

Gesendet von meinem GT-N7100 mit Tapatalk 2

[gthorsten]

wenn ich dich richtig verstehe, bedeutet es wenn ich die UK Version installiert habe ([Firmware]I9300XXDLJ4 Android 4.1 Jelly Bean (United Kingdom-OXA 23.10.12)) dann könnte es sein das ich als deutscher Vodafonler nicht die korrekten Einstellungen habe?

[spline]

Sehr wahrscheinlich.
Kontrollieren kannst du es in der telephony.provider Datenbank.

Gesendet von meinem GT-N7100 mit Tapatalk 2

[gthorsten]

kennst du einen link wor die inhalte erklärt werden bzw weisst du wie sie richtig stehen müssen?

Möchte jetzt nicht unbedingt erst ne dbt installlieren um die andere DB zu sehen.

[Rob2222]

Also,
zuerst googelst Du die PLMN Deines Mobilfunkanbieters. (Vodafone.de hat z.b. 26202).

Damit schaust Du dann in die /data/data/com.android.providers.telephony/databases/nwk_info.db Datenbank.

In der Tabelle "nwkinfo" sollte die Spalte "dormancy" für Deinen PLMN auf "on" stehen.

Die Tabelle "dormpolicy" beinhaltete früher die Spalten "lcdonfdtime" und "lcdofffldtime" und da Stand der Timer in Sekunden drin, nachdem das Handy auf einen Idlezustand (IDLE/PCH) zurückschaltet. Einmal ein Wert für eingeschaltetes Display und einmal den Wert für ausgeschaltetes Display. Unter ICS waren beide Werte für alle deutschen Netze auf "5".

Jetzt habe ich gerade unter Jelly Bean mal geschaut, jetzt gibt es in der Tabelle "dormpolicy" noch zwei zusätzliche Spalten "lcdonfdtime_Rel8" und "lcdofffdtime_Rel8".

Das ist jetzt scheinbar die Möglichkeit, "FD-alt" und "FD-neu" getrennt an und abschalten zu können.

Leider ist meine CSC gerade irgendwie verpfuscht, daß ich da selber gerade keine Originalwerte drin habe.
Die Werte, die bei mir gerade drin stehen sind z.b.:
PLMN: "310150"
nwkname: "ATT"
lcdonfdtime: "0"
lcdofffdtime: "3"
lcdonfdtime_Rel8: "-1"
lcdofffdtime_Rel8: "-1"



EDIT:
Mache gerade ein paar Tests in meiner Vodafone-Zelle, die mittlerweile URA_PCH als besseren Bereitschaftszustand kann. Vor 2-3 Monaten schaltete sie noch auf IDLE zurück.

Die erste Spalte bezieht sich auf den "dormancy" Wert in der "nwkinfo" Tabelle.
Die vier Zahlen stehen für die lcdonfdtime/lcdofffdtime/lcdonfdtime_Rel8/lcdofffdtime_Rel8 Spalten in der "dormpolicy" Tabelle.
Die angegeben Zeit ist die gemessene Zeit nach Ausgehen der Datenübertragungspfeile bis in den Bereitschaftszustand IDLE/PCH (bei mir hier URA_PCH).

----------
on und "PLMN kommt in "dormpolicy"-Tabelle nicht vor" => ca. 7-8 Sekunden
off und "PLMN kommt in "dormpolicy"-Tabelle nicht vor" => ca. 7-8 Sekunden
----------
on und 5/5/-1/-1 => ca. 7-8 Sekunden.
----------
on und 15/15/25/25 => ca. 15-16 Sekunden.
off und 15/15/25/25 => ca. 15-16 Sekunden.
----------
on und 15/15/0/0 => ca. 15-16 Sekunden.
off und 15/15/0/0 => ca. 15-16 Sekunden.
on und 15/15/-1/-1 => ca. 15-16 Sekunden.
off und 15/15/-1/-1 => ca. 15-16 Sekunden.
----------
off und -1/-1/-1/-1 => ca. 35-36 Sekunden.
on und 45/45/-1/-1 => ca. 35-36 Sekunden.
----------
on und 0/0/25/25 => ca. 35-36 Sekunden.
off und 0/0/25/25 => ca. 35-36 Sekunden.
on und -1/-1/25/25 => ca. 35-36 Sekunden.
off und -1/-1/25/25 => ca. 35-36 Sekunden.
----------

Auswertung:
35-36 Sekunden scheint das Timeout der Zelle zu sein, wenn das Handy nicht zurückschalten will (FD-deaktiviert).
Ansonsten gelten (zumindest in meiner Zelle) scheinbar die Timer in den ersten beiden Spalten.

Ich denke das Hinzufügen von "on und 5/5/-1/-1" für die eigene PLMN kann nicht schaden, obwohl es zumindest in meiner Heimatzelle hier scheinbar nicht notwendig wäre. Aber wer weiß, wie die anderen Zellen konfiguriert sind.




PS: Ich werde diesen Post bezüglich Informationen zu dieser Tabelle erweitern, sofern ich mehr weiß.

Gruß
Rob

[gthorsten]

Hi Rob,

In der Tabelle nwkinfo sieht es aus wie von dir beschrieben:
plmn für vodafone (26202) ist on.

In der Tabelle dormpolicy taucht aber diese plmn nicht mehr auf. stattdessen 2x der nwkname vodafone, aber mit einer plmn
von 310560 und 310680. Dabei sind die Zeiten auf Null.

Habe die englische 4.1.1 drauf, meinen CSC kontrolliert, der StAND AUF dbt.

Wenn es also keine BEziehung zwischen den beiden verschiedenen plmn in den tabellen nwkinfo und dormpolicy gibt,
dann sieht es aus als wenn da was oberfaul wäre.

Gruß
thorsten

[Rob2222]

Huhu,

es könnte sein, daß die Funktionen im Handy jetzt so programmiert sind, daß sie bezüglich Fast Dormancy gewisse Standardwerte für alle Netzwerke haben, die sie auch nutzen und nur für die Ausnahmen, die anders sind, einen Eintrag in der "dormpolicy" Tabelle haben.

Es kann auch sein, daß sie bei der CSC Mist gebaut haben und einfach die falschen Werte in der "dormpolicy" Tabelle sind. Ich weiß es nicht.

Naja, mal schauen, evtl. setze ich mich da nochmal ran.

Gruß
Rob