Analogové vs. digitální připojení k Internetu

Samotná čistě digitální či kombinovaná digitálně/analogová přenosová cesta ještě sama o sobě nestačí k tomu, aby dvě strany usilující o vzájemnou komunikaci mohly úspěšně navázat spojení a skutečně komunikovat. Musí zde totiž existovat i vhodné protokoly, které jim umožní dorozumět se, navázat spojení, a také průběh tohoto spojení řídit.

Opět se zde setkáme se dvěma základními možnostmi, z nich jednu můžeme označit jako čistě digitální, a druhou jako analogovou. Základem první možnosti je použití digitálního protokolu V.110, který je běžně používán v sítích ISDN. Druhým je naopak použití protokolu V.32, který pochází naopak z prostředí analogových sítí.

Nejmarkantnější rozdíl mezi oběma variantami je zřejmě patrný na příkladu připojování k Internetu. Pomocí protokolu V.110 je totiž připojení k Internetu (včetně přihlášení do sítě internetového providera) velmi rychlé a trvá jen několik sekund. Naproti tomu stejná aktivita realizovaná pomocí protokolu V.32 při rychlosti 9,6 kbps (resp. V.32bis při rychlosti 14,4 kbps, či V.34 u HSCSD) trvá výrazně déle, například půl minutu, někdy dokonce až kolem minuty. Ovšem připojovat se pomocí protokolu V.110 (tedy vlastně plně digitálně) je možné jen tam, kde je váš mobilní operátor propojen s příslušným internetovým providerem také digitálním způsobem (prostřednictvím sítě ISDN nebo přímým propojením IP směrovačů s GSM sítí), a nikoli přes (analogovou) telefonní síť s využitím modemů (resp. zařízení IWU). V tomto druhém případě není připojení pomocí V.110 možné a musí být používáno připojení pomocí V.32.

Transparentní a netransparentní datové přenosy

Další významnou vlastní datových přenosů v sítích GSM, o které je vhodné se zmínit, je jejich schopnost vyrovnat se s případnými chybami při přenosu. Jak jsme si již uvedli výše, při přenosu zdigitalizovaného hlasu je použito takové kódování, které umožňuje následnou opravu některých poškozených dat příjemcem (také díky tomu ale původních 13 kbps dat "naroste" na 22,8 kbps). V případě, kdy je zmiňovaných 22,8 kbps v každém slotu využíváno pro přenos dat (ať již rychlostí 14,4 nebo 9,6 kbps) jsou sice využívány jiné konkrétní mechanismy pro realizaci přenosu, ale tyto také zajišťují určitou míru spolehlivost, resp. zabezpečení proti chybám (která ale rozhodně není absolutní). Důležité ale je uvědomit si, že tyto mechanismy chránící proti chybám fungují podobně jako u přenosu hlasu "dopředně", tj. snaží se přidávat k přenášeným datům určité doplňující údaje, pomocí kterých pak příjemce může některé eventuelní chyby opravit sám, bez toho, že by chybně přenesená data musela být přenášena znovu.

Takovéto řešení sice nezpomaluje tok dat ani nezpůsobuje žádné nepravidelnosti v jejich doručování, ale na druhé straně je velmi náročné na přenosovou kapacitu - aby dokázal opravit více chyb, musí k "užitečným" datům přidávat více režijních dat (zvyšovat jejich redundanci, neboli nadbytečnost), a k tomu má jen velmi málo prostoru (v případě přenosů rychlostí 9,6 kbps se musí "vejít" do cca 13,2 kbps, které zbývají do dostupných 28,8 kbps, a u přenosů 14,4 má ještě méně prostoru a musí se "vejít" do 8,4 kbps).

Daší zvýšení spolehlivosti při datových přenosech takovouto "dopřednou" cestou již není vhodné, protože je značně neefektivní. Místo toho se používá tradiční řešení, typické pro počítačové sítě fungující na paketovém principu - využívá se toho, že mezi odesilatelem a příjemcem existuje zpětná vazba, a pokud příjemce přijme nějaká poškozená data, pošle odesilateli zpět zprávu s žádostí o jejich opětovné zaslání. V praxi to samozřejmě vyžaduje, aby obě komunikující strany byly přesně domluveny na konkrétním postupu, neboli na konkrétním protokolu který budou používat. Tímto protokolem je RLP (Radio Link Protocol), odvozený od linkového protokolu HDLC, který pochází z paketových sítí. Ani on sice neodkáže zcela eliminovat možnost výskytu chyby v přenášených datech, ale dokáže toto nebezpečí výrazně zmírnit, na úroveň pravděpodobnosti výskytu chyby 10-8 (… na minus 8, prosím pozor na exponent …).

Protokol RLP se týká výhradně datových přenosů v GSM sítí (nikoli faxových), a je implementován v koncových bodech GSM sítě - na jedné straně v mobilním terminálu, a na straně druhé za ústřednou MSC (Mobile Switching Centre), resp. v zařízení IWU (Inter Working Unit).

Používání protokolu RLP není povinné, resp. je možné jej vypnout. Režim, kdy je tento protokol zapnut a používán, je označován jako netransparentní. Jeho výhodou je nízká chybovost, která je ale na druhou stranu vyvážena větším rozptylem přenosového zpoždění, neboli většími nepravidelnostmi v doručování dat. Pokud totiž protokol RLP objeví nějakou chybu v přenesených datech, nechává si je poslat znovu, a tím se samozřejmě narušuje pravidelnost toku dat. Navíc režie, kterou protokol RLP nutně způsobuje, jde na úkor přenosové kapacitě odpovídající rychlostem 9,6 resp. 14,4 kbps, a efektivní přenosová rychlost se tudíž ještě o něco snižuje.

Používání protokolu RLP je možné vypnout, což odpovídá tzv. transparentnímu režimu (transparentnímu v tom smyslu, že přenosová cesta se pak chová jako "průběžně průchozí roura" a není z ní vůbec patrné, že přenos probíhá po síti GSM). Existence transparentního režimu je nutná kvůli tomu, že některé terminály (mobilní telefony i jiná koncová zařízení) nemusí protokol RLP podporovat. Stejně tak je ale nutná i proto, že některým aplikacím nemusí vyhovovat důsledky nasazení protokolu RLP, zejména pak nepravidelnosti v doručování dat. Existují totiž takové aplikace, kterým ani tak nevadí případná chybovost, jako spíše pravidelnost v doručování dat. Jsou to zejména všechny multimediální aplikace, například přenosy obrazu a zvuku.

Představa transparentního a netransparentního přenosu

I při použití transparentního režimu přenosu samozřejmě mohou být použity mechanismy zajištující spolehlivost přenosů - nyní již ale jsou implementovány až v koncových uzlech které spolu komunikují (zatímco protokol RLP, pokud je v netransparentním režimu používán, je implementován přímo v GSM síti).

Přímo v rámci přenosové části GSM sítě přitom mohou být implementovány i další mechanismy, konkrétně mechanismus komprese přenášených dat. V praxi jde o protokol V.42bis, jehož komprimační schopnosti jsou samozřejmě závislé na povaze přenášených dat a v optimálním případě dosahuje tento protokol kompresního poměru až 4:1. Důležité ale je, že použití tohoto protokolu je vázáno jen na netransparentní režim (tedy na současné použití protokolu RLP).