Forum - TELEPOLIS.PL

Witam.

Mam pytanie do osób "siedzących w temacie". Chodzi mi o korzystanie z rozszerzonych stanów RCC u polskich operatorów. Konkretnie, chodzi mi o to, którzy operatorzy korzystają ze stanu Cell/URA PCH oprócz standardowych Cell DCH i Cell FACH.

Z własnych testów wiem, że w T-Mobile ten stan jest zaimplementowany. Wiem też, że w Playu go nie ma - sieć nie obsługuje Cell/URA PCH, więc terminale korzystają z Fast Dormancy i natychmiast przechodzą do stanu IDLE, co jak wiadomo zwiększa ruch sygnalizacyjny w sieci. Niestety nie wiem jak wygląda sprawa w Plusie i Orange, a nie mam możliwości sprawdzenia tego.

Z punktu widzenia użytkownika nie powinno to mieć większego znaczenia (zużycie energii jest niemal identyczne dla PCH i IDLE), ale sieć szkieletowa operatora może być poważnie obciążona przy wielu przejściach z IDLE do DCH.

mkowalski pisze:Konkretnie, chodzi mi o to, którzy operatorzy korzystają ze stanu Cell/URA PCH oprócz standardowych Cell DCH i Cell FACH.

Temat zapowiada się ciekawie.
mkowalski, niestety mało mi mówią w/w pojęcia

mkowalski pisze:że w Playu go nie ma - sieć nie obsługuje Cell/URA PCH, więc terminale korzystają z Fast Dormancy i natychmiast przechodzą do stanu IDLE, co jak wiadomo zwiększa ruch sygnalizacyjny w sieci.

Stan IDLE, to się domyślam , ale o co chodzi z tym Fast Dormancy? Mógłbyś też wyjaśnić szerzej i tak bardziej zrozumiale pojęcia, jak Cell DCH i Cell FACH?

mkowalski pisze:ale sieć szkieletowa operatora może być poważnie obciążona przy wielu przejściach z IDLE do DCH.

Ciekawe, ale nie wiem, o jakie obciążania sieci może chodzić?
Z góry dzięki za dokładniejsze wyjaśnienia

POZdrawiam.

Generalnie chodzi o transmisję danych w sieciach mobilnych. Wszystko jest proste gdy telefon transmituje dane - wtedy jest w stanie Cell DCH. Sytuacja jest też prosta, gdy jest offline - stan IDLE.

Drobne komplikacje pojawiają się wtedy, gdy telefon jest online ale nie transmituje danych (nie ma znaczenia czy chodzi o wysyłanie, czy odbieranie) - no bo co z nim wtedy zrobić? Oczywiście ze względów wydajnościowych nie trzyma się go w stanie DCH - po pierwsze, wymaga to rezerwacji zasobów sieciowych, po drugie ma największe zużycie energii.

Z tego właśnie powodu istnieją dwa pośrednie stany - Cell FACH i Cell PCH, jednak często operatorzy implementują jedynie FACH, zapominając o PCH. Czym się to objawia dla użytkownika? Ano większym zużyciem energii niż w trybie IDLE, mimo że telefon nie prowadzi transmisji.

W tym miejscu pojawia się Fast Dormancy, stworzony niejako przez producentów telefonów. Powoduje to, że telefon natychmiast po zakończeniu transmisji danych przechodzi do trybu IDLE aby zminimalizować zużycie energii. A jaki problem mają z tego tytułu operatorzy? Ano taki, że przy nawiązywaniu połączenia (czyli przechodzeniu z IDLE do DCH) występuje dużo ruchu sygnalizacyjnego. W porównaniu do przejścia z PCH do DCH jest to 6 razy większa transmisja.

Niestety nie znam się na tym temacie od strony praktycznej, dlatego nie wiem z jakiego powodu operatorzy rezygnują ze stanu Cell PCH. Mam też nadzieję, że nigdzie wyżej nie popełniłem dużych błędów - gdyby coś było nie tak, niech ktoś natychmiast mnie poprawi

rogmaniek, bardziej technicznie jest to opisane tutaj - http://www.umtsworld.com/technology/RCC_states.htm - jeśli chcesz, możesz się z tym zapoznać

Teraz jest już znacznie, dla mnie, jaśniej

mkowalski pisze:Drobne komplikacje pojawiają się wtedy, gdy telefon jest online ale nie transmituje danych (nie ma znaczenia czy chodzi o wysyłanie, czy odbieranie) - no bo co z nim wtedy zrobić?

Kiedyś się właśnie zastanawiałem, gdy nie kończymy/zamykamy sesji internetowej, a telefon informuje, że dalej jest połączony z internetem. A teraz już wiem, że jest coś takiego, jak...

mkowalski pisze:Z tego właśnie powodu istnieją dwa pośrednie stany - Cell FACH i Cell PCH, jednak często operatorzy implementują jedynie FACH, zapominając o PCH.

... także jeszcze raz dzięki za wyjaśnienia Jeszcze mnie zastanawia, czym się różni stan FACH, od PCH? Bo oczywiście, jak napisałeś...

mkowalski pisze:Czym się to objawia dla użytkownika? Ano większym zużyciem energii niż w trybie IDLE, mimo że telefon nie prowadzi transmisji.

... to jest jasne. Ale co daje operatorowi FACH, że opłaca się to zaimplementować?

POZdrawiam.

rogmaniek pisze:

mkowalski pisze:Z tego właśnie powodu istnieją dwa pośrednie stany - Cell FACH i Cell PCH, jednak często operatorzy implementują jedynie FACH, zapominając o PCH.

... także jeszcze raz dzięki za wyjaśnienia Jeszcze mnie zastanawia, czym się różni stan FACH, od PCH? Bo oczywiście, jak napisałeś...

Dla użytkownika? Zużyciem energii. FACH pobiera podobną ilość energii co w trakcie transmisji danych. Za to PCH pobiera tyle co IDLE, czyli prawie nic.

Od strony operatora jest różnica w potrzebnych zasobach, które muszą być zarezerwowane dla użytkownika.

rogmaniek pisze:

mkowalski pisze:Czym się to objawia dla użytkownika? Ano większym zużyciem energii niż w trybie IDLE, mimo że telefon nie prowadzi transmisji.

... to jest jasne. Ale co daje operatorowi FACH, że opłaca się to zaimplementować?

Nie tyle, że mu się opłaca, co po prostu musi. Po pierwsze, stany RRC są zdefiniowane przez 3GPP, więc nie można sobie samemu wprowadzać "co nam się podoba".

Po drugie w DCH dla użytkownika trzeba przeznaczyć kanał fizyczny do transmisji danych (a ich ilość jest oczywiście ograniczona). Z optymalizacyjnego punktu widzenia byłoby kompletnie bez sensu trzymać w DCH użytkownika, który nie przesyła danych.

mkowalski pisze:Dla użytkownika? Zużyciem energii. FACH pobiera podobną ilość energii co w trakcie transmisji danych. Za to PCH pobiera tyle co IDLE, czyli prawie nic.

Od strony operatora jest różnica w potrzebnych zasobach, które muszą być zarezerwowane dla użytkownika.

Ok.

mkowalski pisze:Nie tyle, że mu się opłaca, co po prostu musi. Po pierwsze, stany RRC są zdefiniowane przez 3GPP, więc nie można sobie samemu wprowadzać "co nam się podoba".

Po drugie w DCH dla użytkownika trzeba przeznaczyć kanał fizyczny do transmisji danych (a ich ilość jest oczywiście ograniczona). Z optymalizacyjnego punktu widzenia byłoby kompletnie bez sensu trzymać w DCH użytkownika, który nie przesyła danych.

Aha Rzeczywiście wszystko tłumaczy, dlaczego operatorzy stosują FACH.
Na pewno dotychczasowe informacje są, dla mnie, bardzo przydatne

POZdrawiam.

Udało mi się sprawdzić, jak wygląda sprawa w Plusie - tam też nie ma stanu Cell/URA PCH. Nadal nie wiem jak to wygląda w Orange.

No i w dalszym ciągu proszę o wyjaśnienie, jaki jest powód takiej sytuacji. Nie wiem też, czy jest znacząca różnica dla użytkownika między stanem PCH a IDLE. Ktoś potrafi to wyjaśnić?

RRC (Radio Resource Control) State

Cell_FACH tp stan wiązany z możliwością transmisji pomiędzy siecią a terminalem na kanałach RACH (uplink) i FACH (downlink). To są wspólne kanały, z których mogą korzystać wszystkie terminale w celli. W tym stanie są terminale, które np. zestawiają połączenie, robią location update, wysyłąją/otrzymują SMSy albo przesyłają do sieci małą ilośc danych -np. jak rozmawiasz przez gg, to też przerzuci Cię na Cell_FACH.
Na FACHa system (RNC) przerzuci też terminal, który był w stanie DCH ale zakończył transmisję (bo zawsze się może okazać, że jeszcze transmisja będzie wznowiona za chwile, a z FACHa do DCH można przejść szybciej (czyli lepsza jakość dla usera) i mniejszy signalling (czyli mniejsze obciązenie dla sieci).
Niestety za "bycie na FACHu" terminal "płaci" więlszym zużyciem baterii niż w IDLE, a trzymanie dużej ilości userów na FACH obciąża procesory RNCa, więc po jakimś czasie ( * zobacz koniec postu) od zakończenia transmisji, RNC nakazuje mobilowi przejść z FACH do IDLE.

W stanie Cell_PCH, bateria telefonu nie jest jakoś specjalnie obciążona, w RNC ten mobile jest ciągle w pamięci i po każdym przejściu do innej Celli robi cell update, tak że RNC zapisuje sobie jego położenie z dokładnością do celli. To też może obciążać RNCa dla dużej ilośći userów w Cell_PCH, więc również są timery, po jakich user przechodzi z Cell_PCH do Idle, jesli nie nadaje żadnych danych.

URA_PCH jesty jak Cell_PCH, tylko że RNC zarządzany przez siebie obszar ma podzielony na tzw. obszary URA, które mogą skłądać sięz kilku cell i mobile robi ura_update rzadziej, bo tylko gdy przechodzi pomiędzy tymi obszarami (A RNC zna jego położenie z dokładnościa do URA). Zawsze operator możę sobie zdefiiować URA jako poszczególne celle i wtedy jest to tożsame z Cell_PCH.

Ericsson ma zaimplementowane URA_PCH, a NSN Cell_PCH, pozostali nie wiem.

Dlaczego dopiero to się wprowadza?

1)Bo wcześniej nie było potrzeby, to jest problem z duż ąilością smartphonów, stosunkowo nowy
2)Bo dostawcy wcześniej tego nie oferowali, to że coś jest w specyfikacjach, nie oznacza że automatycznie znajdzie się wplatformach dostawców, to złożony feature, wchodzący w interakcje z innymi. Jedno to stworzyć go i przetestować, a drugie to wprowadzić go do żywych sieci. Dlatego zazwyczaj najpierw robi się to na jednym RNCu, potem obserwuje i wprowadza się sukcesywnie dalej.
Oczywiście od pewnego czasu u niektórych operatorów już jest i działa, ale dostawcy oferują to względnie niedługo w porównaniu z czasem gdy zaczęli sprzedawać systemy WCDMA.

Co do Fast Dormancy, to z Cell/URa_Pch mobile też potrafi od razu przeskoczyć do Idla , dopiero teraz będzie się wdrażało bardziej inteligentne zachowania po obu stronach (sieć/terminal). Zob. http://www.nokiasiemensnetworks.com/sit ... ow-res.pdf

* A teraz prośba: jak już tak badasz te stany, to mógłbyś zrobić dla różnych operatorów taki eksperyment:
ściągaj dane, aż znajdziesz się w DCH, przestań ściągać i sprawdź po jakim czasie przerzuci Cię do FACHa, a potem (opcjonalnie) do URA (Cell)_Pch, a potem po jakim czasie do Idla.

Ciekaw jestem ustawień dla polskich operatorów (one mogą się różnic per RNC).

Marcin_7 pisze: Co do Fast Dormancy, to z Cell/URa_Pch mobile też potrafi od razu przeskoczyć do Idla , dopiero teraz będzie się wdrażało bardziej inteligentne zachowania po obu stronach (sieć/terminal). Zob. http://www.nokiasiemensnetworks.com/sit ... ow-res.pdf

Ale to chyba już nie ma żadnego logicznego uzasadnienia. Bo o ile FACH powoduje duże zużycie energii, to między PCH a IDLE nie ma żadnej różnicy. Jaki jest więc powód, dla którego telefony wolałyby wracać do IDLA, zamiast być w PCH?

Nie wiem jak to wygląda u konkretnych producentów, ale Nokia ma to chyba najlepiej rozwiązane - Fast Dormancy jest używane tylko, gdy operator nie korzysta z PCH.

Marcin_7 pisze:* A teraz prośba: jak już tak badasz te stany, to mógłbyś zrobić dla różnych operatorów taki eksperyment:
ściągaj dane, aż znajdziesz się w DCH, przestań ściągać i sprawdź po jakim czasie przerzuci Cię do FACHa, a potem (opcjonalnie) do URA (Cell)_Pch, a potem po jakim czasie do Idla.

Ciekaw jestem ustawień dla polskich operatorów (one mogą się różnic per RNC).

Timery dla PTC:
DCH -> FACH - 3 sekundy
FACH -> PCH - 3 sekundy
PCH -> IDLE - 15 minut

Play i Plus nie zaimplementowali PCH, więc nie sprawdzę timerów - telefon korzysta z Fast Dormancy, więc po wejściu w FACH "ucieka" do IDLA i ignoruje ustawienia operatora. Podejrzewam, że mają timery ustawione w następujący sposób: DCH -> FACH - 10 sekund, FACH -> IDLE - 30 sekund.

Dla Orange nie mam jak przeprowadzić testów, więc nie wiem nawet czy korzystają z PCH.

Mi w Polkomtelu akurat korzysta z URA_PCH.
LAC: 34121 przykładowy CID: 675 PSC: 3412

Screenshot

A u mnie w Polkomtelu jest Cell_PCH.

W netmonitorze gdzieś są podane czasy po jakich telefon przechodzi w poszczególne stany, czy po prostu trzeba sprawdzać aktualny stan z zegarkiem w ręku?

A może ktoś napisać, na której stronie FTD, da się sprawdzić te stany RRC? Coś mam na stronie 09.17 czy 09.18, ale chyba to nie to...

POZdrawiam.

[ Dodano: 2011-06-23, 18:28 ]
Chyba sobie znalazłem, na stronie 47.01

POZdrawiam.

McCm pisze:Mi w Polkomtelu akurat korzysta z URA_PCH.
LAC: 34121 przykładowy CID: 675 PSC: 3412

ezaq pisze:A u mnie w Polkomtelu jest Cell_PCH.

A u mnie Polkomtel za nic nie chce przejść do PCH. Z DCH idzie do FACH-a, a potem po 10. sekundach wraca do IDLA. Prawdopodobnie sieć Polkomtela w moim regionie nie obsługuje jeszcze PCH. LAC: 31027.