WAP, alias Wireless Application Protocol

Zřejmě nejznámější a nejpopulárnější platformou je dnes protokol WAP. Je třeba se na něj dívat jako na standardizovaný způsob komunikace mezi mobilním terminálem a serverem instalovaným v mobilní síti (ne nutně GSM, ale v zásadě jakékoli mobilní síti). Podobně jako SIM Toolkit vychází i WAP v zásadě z architektury klient/server, ale přeci jen zde uplatňuje poněkud jiný přístup. SIM Toolkit totiž počítá s klasickou architekturou klient/server a s tím, že klientská část aplikace je "pevně" umístěna v mobilním terminálu (je nahrána na SIM kartě) a je na mobilním terminálu také provozována (v prostředí které SIM Toolkit pro běh aplikace vytváří). To samozřejmě klade jistá omezení na možnost současného provozování více různých aplikací i jejich instalování.

Naproti tomu u protokolu WAP je vhodné si představit, podobně jako u aplikací přístupných prostřednictvím služby World Wide Web, že vychází spíše z tříúrovňové architektury klient/server. Tedy z předpokladu, že uživatel má k dispozici nikoli jednoúčelovou klientskou část, ale naopak velmi univerzální prezentační prostředek, který může být beze změny použit pro zpřístupnění nejrůznějších různých aplikací. Ve světě služby World Wide Web je takovýmto univerzálním prezentačním prostředkem dobře známý WWW browser (prohlížeč), v případě WAP-u jím je "mikrobrowser", zabudovaný do mobilního terminálu. Zbývající část aplikace, zahrnující jak tzv. aplikační logiku, tak i eventuelní databázi, pak může být realizována v podstatě kdekoli i mimo mobilní síť (v případě WAP-u), resp. mimo Internet (v případě Web-u). Potřebné přizpůsobení a propojení totiž realizuje v obou případech brána (gateway), která z jedné strany komunikuje se "zbývající" částí aplikace, takovým způsobem jaký je potřebný (zde není nutná standardizace), a z druhé strany komunikuje s webovým browserem (resp. WAP-ovým mikrobrowserem) přesně definovaným a standardizovaným způsobem - v případě web-u jde o komunikaci prostřednictvím protokolu HTTP (Hypertext Transfer Protocol), a v případě WAP-u jde o komunikaci prostřednictvím tohoto protokolu, tj. protokolu Wireless Application Protocol.

Výsledný efekt je v případě WAP-u stejný jako u web-u: uživateli stačí jeden identický browser (mikrobrowser) k tomu, aby mohl používat celou širokou škálu služeb nejrůznějšího obsahu a zaměření. Tyto služby jsou přitom zajišťovány aplikacemi, které "sídlí" v síti (v Internetu či v mobilní síti) za příslušnými bránami, či dokonce zcela mimo tyto sítě (a vlastně to ani není podstatné). Rozdíl mezi web-em a WAP-em je samozřejmě v konkrétním způsobu fungování - nejen v komunikaci mezi browserem a bránou, ale i ve formátu přenášených dat (web pracuje s formátem HTML, WAP s formátem WML), ale především v samotných prezentačních možnostech: zatímco web počítá s poměrně bohatými zobrazovacími schopnostmi počítače, WAP může počítat jen s velmi omezenými možnostmi které skýtá mobilní terminál.

Co pod WAP-em?

Velmi důležitým aspektem WAP-u je jeho nezávislost na konkrétním přenosovém mechanismu. Pod protokol WAP totiž lze "podložit" prakticky cokoli, co v mobilní síti dokáže přenášet data - od SMS zpráv až po GPRS, a také se tak v praxi děje, WAP je provozován "nad" různými přenosovými mechanismy. Samozřejmě to ale neznamená, že by každý z existujících přenosových mechanismů byl pro WAP stejně vhodný. Pojďme si proto udělat malý výčet a okomentovat vhodnost jednotlivých mechanismů, které připadají v úvahu v sítích GSM.

WAP nad SMS

Protokol WAP funguje stylem "požadavek - odpověď", a tak nespojovaný způsob přenosu SMS zpráv je pro něj velmi vhodný - v jednoduchosti si lze představit, že na mobilním terminálu je sestaven příslušný požadavek a vložen do SMS zprávy, která je odeslána. Odpověď přijde stejným způsobem, pomocí SMS zprávy, a náklady na celou transakci jsou dány výhradně počtem SMS zpráv, a nejsou závislé na čase.

Určitý problém je s velikostí SMS zpráv - ta je omezená (140 bytů, resp. 160 znaků), a i jednoduché transakce mohou být tak velké, že "spotřebují" hned několik SMS zpráv. Především je zde ale problém s omezenými možnostmi odesílání SMS zpráv (jednou za 5 vteřin) i s jejich potenciálním "čekáním" v SMS centru. Vzhledem k nenulové ceně za jednu zprávu to ve výsledném efektu může být příliš pomalé a drahé řešení.

V odborné literatuře je citován pouze jediný operátor (SBC v USA) který má připravovat WAP nad SMS. Ostatní operátoři s touto variantou nepočítají.

WAP nad CSD (či HSCSD)

Dnes je zdaleka nejrozšířenější variantou provozování WAP-u nad "klasickými" datovými přenosy (CSD, Circuit Switched Data), případně HSCSD (High Speed Circuit Switched Data), které fungují na principu přepojování okruhů. Tak jak bývá zvykem, má i toto řešení své výhody a nevýhody.

Výhodou je především dobrá dostupnost samotného přenosového mechanismu (SCD či HSCSD) a to, že objem přenášených dat zde není apriorně omezen jako u SMS zpráv (i když je omezen rychlostí).

Proti hovoří zejména to, že CSD (i HSCSD) je spojovaný protokol, který předpokládá navázání spojení (a také placení za dobu, po kterou toto spojení existuje). Při použití digitálního protokolu V.110 je sice navázání spojení relativně rychlé, ale pro samotný WAP přeci jen může způsobovat znatelné zpoždění (v případě analogového protokolu jde o dobu cca 30 sekund, která je již zcela nepřijatelná). Hlavně je ale CSD i HSCSD zpoplatňováno podle doby, po kterou spojení existuje a nikoli podle toho, zda jsou fakticky nějaké přenosy prováděny. Takže pokud například váš mobilní terminál naváže spojení a předá požadavek nějaké bráně, která na odpovědi určitou dobu pracuje, platíte za celou dobu existence spojení. Pokud je ihned po obdržení odpovědi spojení zrušeno, již za něj dále neplatíte (samozřejmě v závislosti na způsobu tarifikace, kde záleží na tom zda je tarif účtován po sekundách nebo po větších intervalech), ale při dalším požadavku znovu čekáte na navázání spojení. Pokud spojení po získání odpovědi nezrušíte, protože předpokládáte že budete mít další požadavek (například budete pokračovat v listování nějakým nabídkovým menu), pak platíte i za dobu kdy se rozmýšlíte a připravujete se ke vznesení dalšího požadavku.

WAP nad USSD

Pro přenos dat pro potřeby protokolu WAP je možné využít mechanismus USSD (Unstructured Supplementary Services Data), popisovaný v samostatném boxu (prosím doplnit odkaz…). Alespoň samotný protokol WAP je na tuto možnost připraven, ale u mobilních operátorů zatím nejsou signály svědčící o zájmu využít této možnosti. O důvodech lze jen spekulovat, pravděpodobně souvisí s nejasným způsobem tarifikace - USSD totiž přenáší data spojovaným způsobem po řídících kanálech, a nikoli po dopravních kanálech (TCH, Traffic Channels), které jsou standardním způsobem tarifikovány.

WAP nad GPRS

CSD (HSCSD) a USSD jsou charakteristické tím, že fungují na spojovaném principu, zatímco SMS a GPRS fungují ne nespojovaném principu. To znamená, že SMS ani GPRS nepotřebují navazovat žádné spojení (také se u nich neplatí za dobu existence takovéhoto spojení), a přenáší data právě a pouze tehdy, když je co přenášet. To lépe odpovídá typickému stylu práce uživatele s aplikacemi na bázi WAP-u, který produkuje spíše nárazové než pravidelné požadavky na přenos dat - uživatel určitou dobu přemýšlí, čte, vyplňuje či volí v menu apod., pak nějakou svou volbu potvrdí, a teprve v tomto okamžiku je zapotřebí nějaká data přenést tam a zpět, načež se celý cyklus zase opakuje. Nespojovaný způsob fungování přenosových mechanismů navíc podporuje "svobodu" uživatele, v tom smyslu že jej nenutí k žádnému spěchu a dává mu plnou volnost postupovat takovým tempem resp. v takovém časovém sledu, jaký sám považuje za vhodný. Je to možné i díky tomu, že nespojované přenosové mechanismy nejsou tarifikovány (zpoplatňovány) podle času, ale podle skutečně realizovaných přenosů - podle počtu přenesených zpráv u SMS, a podle objemu přenesených dat u GPRS.

U SMS zpráv je ale problém s jejich omezenou velikostí, a pak především s (relativně) nízkou četností, s jakou je možné je odesílat, což je způsobeno tím že SMS zprávy jsou přenášeny skrze řídící kanály. GPRS tyto nevýhody nemá, protože k přenosům využívá dopravní kanály TCH.

Vše tedy nasvědčuje tomu, že ideálním "nosičem dat" (bearer) pro WAP bude GPRS - samozřejmě až jej budou mobilní operátoři ve svých sítích skutečně nabízet, a až bude podporován také samotnými mobilními terminály.