Rola protokołu IPwsystemach GSM, GPRS iUMTS. Trudne czasy...

13
354 PRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 5–6/2001 S³awomir KUKLIÑSKI* Rola protokołu IP w systemach GSM, GPRS i UMTS. Trudne czasy dla operatorów sieci komórkowych * Instytut Telekomunikacji Politechniki Warszawskiej, Warszawa. e−mail: [email protected] Rozwój sieci komórkowych standardu GSM charakteryzuje niezwyk³a dynamika, œwiadcz¹ca o akceptacji zarówno funkcjo- nalnoœci tego systemu, jak i cen us³ug œwiadczonych w tym sys- temie. Pierwsza sieæ GSM powsta³a w Wielkiej Brytanii w 1992 roku, w roku 1996 by³o „zaledwie” 50 mln abonentów, w koñcu ubieg³ego roku ju¿ 440 mln, natomiast w bie¿¹cym roku przewi- duje siê na ca³ym œwiecie oko³o 600 mln abonentów. Obserwu- j¹c tê tendencjê mo¿na dojœæ do wniosku, ¿e w roku 2003 bêdzie wiêcej abonentów sieci komórkowych, ni¿ abonentów sieci sta- cjonarnej PSTN/ISDN. W kilku krajach liczba abonentów komór- kowych przekroczy³a ju¿ liczbê abonentów sieci PSTN/ISDN, w innych krajach liczby te zrównaj¹ siê w najbli¿szym czasie. W Polsce mamy obecnie ponad 6 mln abonentów sieci GSM i ponad 10 mln abonentów sieci stacjonarnej Drugim zaskoczeniem ostatnich 8 lat jest dynamiczny rozwój sieci Internet i us³ug internetowych. Bogactwo informacyjne tej sieci, ³atwoœæ tworzenia aplikacji, proste korzystanie z niej oraz globalny jej zasiêg, przy stosunkowo niskich kosztach inwesty-

Transcript of Rola protokołu IPwsystemach GSM, GPRS iUMTS. Trudne czasy...

✽ ✽ ✽

Oprócz istotnych ró¿nic koncepcyjnych i implementacyjnych,wa¿ne jest tak¿e to, ¿e modele IntServ i DiffServ s¹ wyrazem za-sadniczo ró¿nego spojrzenia na Internet. Ten pierwszy, przezfakt istnienia jednolitego protoko³u sygnalizacyjnego, unifikujeca³¹ sieæ, nadaj¹c jej zdolnoœæ samokonfiguracji w odpowiedzina ¿¹dania generowane przez terminale koñcowe. Znacznaczêœæ decyzji zwi¹zanych ze sterowaniem ruchem jest wykony-wana w wêz³ach sieciowych, zgodnie algorytmami zaimplemen-towanymi przez producentów wêz³ów.

Model DiffServ okreœla dla odmiany zestaw narzêdzi, którymioperator bêdzie dysponowa³, ³¹cznie z protoko³em zarz¹dzaniaCOPS, ale pozostawia otwart¹ sprawê zarz¹dzania sieci¹, takaby osi¹gn¹æ odpowiedni¹ jakoœæ us³ug. Stwarza to warunki dorywalizacji operatorów, stawiaj¹c w dobrej pozycji tych, którzydysponuj¹ metodami zarz¹dzania ruchem internetowym pod k¹-tem QoS, a w trudnej sytuacji tych, którzy tego aspektu nie doce-niaj¹.

LITERATURA

[1] Papir Z.: Optymalizacja szerokoœci okna dla sterowania przep³ywemw pakietowej sieci telekomunikacyjnej w warunkach zmiennego ob-ci¹¿enia. Zeszyty Naukowe AGH „Automatyka”, Wydawnictwa AGH,nr 51, Kraków 1990

[2] Stallings W.: High-speed Networks. TCP-IP and ATM Design Princi-ples. Prentice Hall, New Jersey, 1998

[3] Walrand J., Varaiya P.: High Performance Communication Networks.Morgan Kaufman Publishers, San Francisco (CA), USA, 2000

[4] Bernet Y.: The Complementary Roles of RSVP and DifferentiatedServices in the Full-Service QoS Network. IEEE CommunicationsMagazine, Vol. 38, No. 2, February 2000

[5] Yang C.-Q., Reddy A.V.S.: A Taxonomy for Congestion Control Algo-rithms in Packet Switching Networks. IEEE Network, Vol. 9, No. 4, Ju-ly/August 1995

[6] Jain R.: Myths about Congestion Management in High-Speed Net-works. Internetworking: Res. and Exp., Vol. 3, 1992

[7] Xiao X., Ni L. M.: Internet QoS: A Big Picture. IEEE Network,March/April 1999

[8] Pacyna P.: Wspó³praca IP i ATM – mo¿liwoœci i perspektywy, wielou-s³ugowe sieci korporacyjne WUSK’99, Kraków, 22–23 czerwiec 1999

[9] Braden R., Clark D., Shenker S.: RFC 1633 „Integrated Services inthe Internet Architecture: an Overview”, June 1994

[10] Shenker S., Partridge C., Guerin R.: RFC 2212 „Specification of theGuaranteed Quality of Service”, September 1997

[11] Wroclawski J.: RFC 2211 „Specification of the Controlled Load Qua-lity of Service”, September 1997

[12] Parekh A., Gallagher R.: A Generalized Processor Sharing Approachto Flow Control – The Single Node Case, IEEE/ACM Trans. Networ-king, Vol. 1, No. 3, 1993

[13] Parekh A., Gallagher R.: A Generalized Processor Sharing Approachto Flow Control – The Multiple Node Case, IEEE/ACM Trans. Networ-king, Vol. 2, No. 2, 1996

[14] Braden R., Zhang L., Berson S., Herzog S., Jamin S.: RFC 2205 „Re-source Reservation Protocol (RSVP) – Version 1 Functional Specifi-cation”, September 1997

[15] Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W.: RFC2475 „An Architecture for Differentiated Services”,

[16] Nichols K., Blake S., Baker F., Black D.: RFC 2474 „Definition of theDifferentiated Services Field (DS Field) in the IPv4 and IPv6 Hea-ders”, December 1998

[17] Jacobson V., Nichols K., Poduri K.: RFC 2598 „An Expedited Forwar-ding PHB”, June 1999

[18] Grenville A., Casati A., Crowcroft J., Halpern J., Kumar B., SchnizleinJ.: IETF Draft „A revised expression of the Expedited ForwardingPHB”, November 2000

[19] Baker F., Heinanen J., Weiss W., Wroclawski J.: Assured ForwardingPHB Group,

[20] Nichols K., Carpenter B.: IETF Draft „Definition of Differentiated Ser-vices Per-Domain Behaviours and Rules for their Specification”,October 2000

[21] Jacobson V., Nichols K., Poduri K.: IETF Draft „The ’Virtual Wire’ Per-Domain Behaviour”, July 2000

[22] Seddigh N., Nandy B., Heinanen J.: IETF Draft „An Assured RatePer-Domain Behaviour for Differentiated Services”, November 2000

354 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

S³awomir KUKLIÑSKI*

Rola protokołu IP w systemach GSM,GPRS i UMTS. Trudne czasy

dla operatorów sieci komórkowych

* Instytut Telekomunikacji Politechniki Warszawskiej, Warszawa. e−mail: [email protected]

Rozwój sieci komórkowych standardu GSM charakteryzujeniezwyk³a dynamika, œwiadcz¹ca o akceptacji zarówno funkcjo-nalnoœci tego systemu, jak i cen us³ug œwiadczonych w tym sys-temie. Pierwsza sieæ GSM powsta³a w Wielkiej Brytanii w 1992roku, w roku 1996 by³o „zaledwie” 50 mln abonentów, w koñcuubieg³ego roku ju¿ 440 mln, natomiast w bie¿¹cym roku przewi-duje siê na ca³ym œwiecie oko³o 600 mln abonentów. Obserwu-

j¹c tê tendencjê mo¿na dojœæ do wniosku, ¿e w roku 2003 bêdziewiêcej abonentów sieci komórkowych, ni¿ abonentów sieci sta-cjonarnej PSTN/ISDN. W kilku krajach liczba abonentów komór-kowych przekroczy³a ju¿ liczbê abonentów sieci PSTN/ISDN,w innych krajach liczby te zrównaj¹ siê w najbli¿szym czasie.W Polsce mamy obecnie ponad 6 mln abonentów sieci GSMi ponad 10 mln abonentów sieci stacjonarnej

Drugim zaskoczeniem ostatnich 8 lat jest dynamiczny rozwójsieci Internet i us³ug internetowych. Bogactwo informacyjne tejsieci, ³atwoœæ tworzenia aplikacji, proste korzystanie z niej orazglobalny jej zasiêg, przy stosunkowo niskich kosztach inwesty-

355PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

cyjnych i cenach us³ug, s¹ zapewne g³ównymi Ÿród³ami jej suk-cesu. Na rozwój sieci Internet bez w¹tpienia wp³ywaj¹ równie¿takie czynniki, jak upowszechnianie siê komputerów osobistych– nie tylko w biznesie, ale równie¿ w gospodarstwach domo-wych – oraz inteligentnych urz¹dzeñ przenoœnych (komputerówtypu notebook czy urz¹dzeñ typu personal digital assistant –PDA).

Wszystkie te czynniki, wraz z miniaturyzacj¹ terminali abo-nenckich, spowodowa³y zainteresowanie systemami ³¹cznoœciruchomej, które nie tylko bêd¹ w stanie œwiadczyæ us³ugi telefo-niczne, ale równie¿ zapewniæ ekonomiczny dostêp do Internetuw trybie komutacji pakietów. Pionierem w implementacji us³ugtypu internetowego dla abonentów ruchomych jest japoñski ope-rator DoCoMo i jego system i−mode – w Japonii liczba internau-tów komórkowych znacznie przewy¿sza liczbê internautówstacjonarnych. Z us³ugowego punktu widzenia ewolucja takawydaje siê zupe³nie naturalna, a jednoczeœnie pojawia siê zu-pe³nie nowy element, poniewa¿ u¿ytkownik systemu komórko-wego jest dostêpny wszêdzie (Anywhere-on), a w przypadkukomunikacji pakietowej staje siê dostêpny permanentnie (Al-ways-on). Dziêki temu jest mo¿liwe wprowadzenie zupe³nie no-wych aplikacji (us³ug), których rolê trudno przeceniæ. Aplikacjete nie bêd¹ jednak aplikacjami wy³¹cznie sieci GSM czy UMTS,ale bêd¹ aplikacjami dzia³aj¹cymi w sieciach heterogenicznych.Terminale przenoœne bêd¹ bowiem s³u¿y³y do komunikacjiz serwerami informacyjnymi oraz obiektami sieci stacjonarnej(np. gospodarstwami domowymi), które dziêki pod³¹czeniu dostacjonarnej sieci pakietowej stan¹ siê równie¿ Always-on. Pa-radoksalnie rozwój systemu UMTS bêdzie wiêc zwiêkszaæ rolêsieci stacjonarnej, która – dziêki obecnie wdra¿anym szeroko-pasmowym rozwi¹zaniom ³¹czy abonenckich xDSL – zapewni³¹cznoœæ z abonentem lub obiektem stacjonarnym typu Always-on (w wielu krajach modemy ADSL s¹ instalowane na skalê masow¹). Us³ugi tego typu okreœla siê równie¿ mianem Fixed--Mobile Convergence (FMC). Konwergencja mo¿e oznaczaæwykorzystanie terminalu UMTS zarówno jako ruchomego, jaki stacjonarnego (litera U w skrócie UMTS oznacza Universalw tym w³aœnie znaczeniu). W USA sta³a op³ata miesiêczna zakorzystanie z Internetu (flat-rate) powoduje, ¿e dostêp telefo-niczny przez modemy (dial-up) sieci stacjonarnej jest de factodostêpem typu Always-on.

Z aplikacyjnego punktu widzenia mo¿na sobie wyobraziæ wie-le us³ug, w których sta³a ³¹cznoœæ pomiêdzy abonentem a jegodomem w istotny sposób podnosi komfort ¿ycia, zwiêksza po-ziom bezpieczeñstwa oraz tworzy nowe zachowania biznesowe(np. telepraca, lokalizacja osób i pojazdów, sterowanie urz¹dze-niami domowymi, ci¹g³y kontakt z pracodawc¹). Potencja³ us³u-gowy tego typu systemów jest olbrzymi, jednak wymaga onstworzenia zarówno systemów aplikacyjnych, jak i wysokiego po-ziomu infrastruktury telekomunikacyjnej i us³ugowej w szerokimrozumieniu tego s³owa. Nale¿y równie¿ zauwa¿yæ, ¿e w omawia-nych systemach komunikacja mo¿e wystêpowaæ nie tylko w rela-cji cz³owiek-cz³owiek czy cz³owiek-maszyna, ale równie¿ w relacjimaszyna-maszyna. Oznacza to oczywiœcie, ¿e liczba sprzeda-nych terminali, np. GPRS lub UMTS, nie bêdzie bezpoœredniopowi¹zana z liczb¹ abonentów, ale raczej z liczb¹ zainstalowa-nych systemów, które s¹ IP-ready (mo¿e byæ ich zatem znaczniewiêcej). W praktyce operatorskiej oznacza to, ¿e jeden „fizyczny”abonent mo¿e byæ wielokrotnym abonentem „logicznym” – posia-daæ kilka numerów komórkowych czy adresów IP dla terminalio ró¿nym przeznaczeniu. Ju¿ obecnie w systemie GSM abonentma ró¿ne numery dla us³ug telefonicznych, telefaksowych i da-nych.

Jak zosta³o zuwa¿one komunikacja w sieciach heterogenicz-nych wymaga stworzenia zunifikowanych platform aplikacyjnych,które zgodnie z koncepcj¹ Internetu umo¿liwi¹ tworzenie us³ugnie tylko operatorom sieciowym (network providers) czy tzw. ofe-

rentom treœci (content providers), ale równie¿ (a mo¿e przedewszystkim) u¿ytkownikom sieci.

Istnieje obecnie tendencja, aby wykorzystaæ Internet nie tyl-ko do œwiadczenia us³ug „internetopochodnych”, ale aby sta³siê on platform¹ wielous³ugow¹, zastêpuj¹c istniej¹ce dotych-czas odrêbne systemy, takie jak sieæ telefoniczna (np. wykorzy-stuj¹c transmisjê g³osu przez Internet – VoIP) czy sieætransmisji danych, potencjalnie integruj¹c w sobie us³ugi o cha-rakterze radiowo-telewizyjnym (wzbogacone o now¹ funkcjo-nalnoœæ, tak¹ jak interaktywnoœæ, automatyczna preselekcjamateria³u audiowizualnego, dynamiczne przekazywanie treœcipomiêdzy wêz³ami sieci dla potrzeb us³ug multimedialnych typu„prawie na ¿yczenie” – near-on-demand). Za integracj¹ wszyst-kich tych rozwi¹zañ w jednej sieci przemawiaj¹ g³ównie kosztyjej budowy, utrzymania oraz elastycznego dysponowania zaso-bami. Warto tu przypomnieæ, ¿e stworzona na pocz¹tku lat 80.koncepcja ISDN (Integrated Services Digital Network) polega³ana integracji wielu us³ug realizowanych w tradycyjnych ³¹czachtelefonicznych. Czas pokaza³, ¿e po 20 latach koncepcja ta mo-¿e byæ spe³niona nie w klasycznej sieci telekomunikacyjnejz komutacj¹ kana³ów, ale w sieci z komutacj¹ pakietów i proto-ko³em IP (Integrated Services IP Network – ISIPN). Powszech-na akceptacja Internetu powoduje, ¿e to w³aœnie platformyaplikacyjne Internetu staj¹ siê najprostszymi i najefektywniej-szymi narzêdziami us³ugowymi, które mo¿na zastosowaæw systemach telekomunikacyjnych XXI wieku. Oznacza to, ¿eprotokó³ IP (Internet Protocol) sta³ siê lingua franca wspó³cze-snej telekomunikacji. Protokó³ ten wystêpuje tutaj w roli „proto-ko³u aplikacyjnego”.

Od kilku lat s¹ znane analizy œwiadcz¹ce o znacz¹cym wzro-œcie wielkoœci ruchu transmisji danych w porównaniu z ruchemtelefonicznym (paradoksalnie nie znajduje to jednak odzwiercie-dlenia w przychodach operatorów). Doskonale równie¿ wiado-mo, ¿e sieæ transmisji danych to obecnie g³ównie sieæ z proto-ko³em IP. Czynniki te powoduj¹ znaczne zainteresowanie imple-mentacj¹ sieci telekomunikacyjnych okreœlanych mianem All−IP,w których protokó³ IP eliminuje istniej¹ce obecnie protoko³ywarstw ni¿szych. Celem takiego podejœcia jest stworzenie efek-tywnej sieci transportowej (eliminacja elementów pochodz¹cychz innych protoko³ów warstw ni¿szych), która jest jednoczeœnieprosta i tania w zarz¹dzaniu. Podejœcie do protoko³u IP mo¿naokreœliæ bardzo lapidarnie jako Everything over IP + IP over Eve-rything. Ten entuzjazm wokó³ IP ugasi³ zimny prysznic: ostatniewydarzenia na gie³dzie NASDAQ wykaza³y, ¿e IP over Enthu-siasm dzia³a poprawnie jedynie w perspektywie krótkotermino-wej.

W artykule zostan¹ przedstawione rozwi¹zania, które umo¿-liwiaj¹ komunikacjê IP w sieciach GSM, GPRS i UMTS. Zewzglêdu na obszern¹ tematykê i ograniczone ramy niniejszegoartyku³u, zostanie w nim przedstawiona ogólna architekturasystemów GPRS oraz UMTS w kontekœcie transmisji IP. Zewzglêdu na du¿e oczekiwania zarówno operatorów, jak i poten-cjalnych u¿ytkowników tego systemu, wiêcej uwagi zostaniepoœwiêcone problemom zwi¹zanym z systemem GPRS. Systemten dotychczas traktowano jako pomost pomiêdzy systemami³¹cznoœci ruchomej drugiej i trzeciej generacji (jest on okreœlo-ny mianem systemu generacji 2+ lub 2,5). Wydaje siê bowiem,¿e sam system ma liczne ograniczenia techniczne, jego maso-we wdro¿enie jest ju¿ obecnie spóŸnione o kilkanaœcie miesiê-cy, a sama implementacja i zarz¹dzanie nim o wiele bardziejkosztowne i z³o¿one, ni¿ tego oczekiwali operatorzy jeszcze2 lata temu.

System UMTS zostanie omówiony w sposób bardziej ogólny.Bêdzie przedstawiona jego architektura wraz z wymienie-niem istotnych jej cech uwzglêdniaj¹cych komunikacjê IP. Na-le¿y dodaæ, ¿e prace nad specyfikacj¹ tego systemu s¹ wci¹¿w toku.

TRANSMISJA DANYCH W SYSTEMIEGSM

W systemie GSM w trybie komutacji kana³ów transmisja da-nych jest mo¿liwa za pomoc¹ dwóch technik: M bezpoœredniej transmisji danych „w kanale rozmównym” GSM– szybkoœæ takiej transmisji jest ograniczona do 9,6 kbit/s (cza-sami do 14,4 kbit/s); M za pomoc¹ mechanizmu HSCSD (High Speed Circuit Swit-ched Data), który dziêki z³o¿eniu kilku szczelin czasowych jed-nego kana³u czêstotliwoœciowego umo¿liwia transmisjê z szyb-koœci¹ do 45 kbit/s (a zatem z szybkoœci¹ zbli¿on¹ do transmisjimodemowej V. 90 w sieci stacjonarnej PSTN).

Powy¿sze rozwi¹zania dedykuj¹ pojedynczemu u¿ytkowniko-wi zarówno zasoby radiowe, jak i transmisyjne i nie za-pewniaj¹ w zwi¹zku z tym agregacji strumieni danych i wspó³-dzielenia zasobów radiowych, a zatem potencjalnie ni¿szychkosztów korzystania z systemu. Obydwie wymienione us³ugi s¹obecnie oferowane przez operatorów GSM.

System GPRS

Jak ju¿ wspomniano, system GPRS (General Packet RadioService) w swoim za³o¿eniu mia³ byæ pomostem miêdzy syste-mami ³¹cznoœci ruchomej drugiej oraz trzeciej generacji. Jest onopracowywany od 1995 roku. Specyfikacjê Fazy 1.0 tego stan-dardu zakoñczono w roku 1998, a obecnie jest wdra¿ana jego nowsza wersja oznaczona jako GPRS Faza 2.0. Podstawo-w¹ us³ug¹ systemu GPRS jest „szybka” (teoretycznie do171,5 kbit/s) transmisja danych w kanale wspó³dzielonym przezwielu u¿ytkowników (packet bearer service). Wspó³dzielone ka-na³y transmisji radiowej i PLMN (Public Land Mobile Network)

umo¿liwiaj¹, dziêki agregacji ruchu pochodz¹cego od wielu u¿yt-kowników, stosunkowo atrakcyjn¹ taryfikacjê us³ug transmisji da-nych. W odró¿nieniu od po³¹czeñ z komutacj¹ kana³ów,transmisje pakietowe mog¹ byæ taryfikowane raczej w zale¿noœciod liczby przekazanych danych (volume based billing), ni¿ odczasu trwania po³¹czenia. GPRS zapewnia komunikacjê u¿yt-kowników tego systemu z sieciami X. 25 i IP (Internet). Opis sys-temu przedstawiono miêdzy innymi w [4] [10], [11], [12], [13].Poni¿szy artyku³ ujmuje zagadnienia GPRS od strony „praktycz-nej”, a mianowicie omawia doœwiadczenia operatorów wdra¿aj¹-cych ten system.

Istotn¹ cech¹ sieci GPRS jest stosunkowo eleganckie wkom-ponowanie nowych elementów s³u¿¹cych do pakietowej transmi-sji danych w istniej¹c¹ sieæ GSM – sieæ GPRS mo¿e byætraktowana jako sieæ nak³adkowa sieci GSM. Sieæ GSM/GPRSmo¿e oferowaæ us³ugi „podobne” do us³ug, które w przysz³oœcibêd¹ oferowane w systemie UMTS. Wielu operatorów uzna³owiêc, ¿e popularnoœæ us³ug GPRS bêdzie mo¿na traktowaæ jakodobry prognostyk przysz³ego zainteresowania systemem UMTSoraz platformê do wykreowania us³ug, które ³atwo przenieœæ dosystemu UMTS.

Architektura systemu GPRS jest przedstawiona na rysunku 1.Jak wynika z niego, w systemie GSM pojawi³y siê nowe elemen-ty, zwane GPRS Support Nodes (GSN). Urz¹dzenia GSN s¹ od-powiedzialne za dostarczanie i ruting pakietów pomiêdzy stacj¹ruchom¹ (MS – Mobile Station) u¿ytkownika systemu GPRSa zewnêtrzn¹ dla systemu GPRS pakietow¹ sieci¹ transmisji da-nych. M Wêze³ SGSN (Serving GPRS Support Node) jest odpowie-dzialny za dostarczenie i rutowanie pakietów uzyskanych ze sta-cji ruchomej, która znajduje siê w obszarze podlegaj¹cym jegokontroli. W tym celu SGSN realizuje takie funkcje, jak: przekazy-wanie pakietów, ruting, zarz¹dzanie mobilnoœci¹ i sesjami (ope-racje typu attach i detach), zarz¹dzanie warstw¹ logiczn¹ ³¹cza,

356 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

OO Rys. 1. Architektura systemu GSM/GPRS. Oznaczenia wyjaśniono w tekście

357PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

uwierzytelnianie, kolejkowanie zg³oszeñ transmisji pakietowejoraz gromadzenie danych dla potrzeb rozliczeniowych. M Wêze³ GGSN (Gateway GPRS Support Node) pe³ni rolê in-terfejsu pomiêdzy sieci¹ GPRS/PLMN a zewnêtrzn¹ pakietow¹sieci¹ transmisji danych. Do jego zadañ nale¿y konwersja pa-kietów otrzymywanych z wêz³a SGSN do odpowiedniego for-matu sieci zewnêtrznej (X. 25 lub IP) i przekazywanie tychpakietów pomiêdzy wêz³ami SGSN oraz sieci¹ zewnêtrzn¹.W kierunku odwrotnym GGSN dokonuje konwersji adresówPDP (Packet Data Protocol) na numery abonentów GSM – pa-kiety te s¹ nastêpnie wysy³ane do odpowiedniego wêz³a SGSN.Do realizacji tej funkcji GGSN zapisuje adres stowarzyszonegoz u¿ytkownikiem wêz³a SGSN w rejestrze VLR (Visitor LocationRegister). Do funkcji GGSN nale¿y równie¿ uwierzytelnianieu¿ytkowników i gromadzenie danych dla potrzeb rozliczenio-wych.

Dla potrzeb GPRS w systemie stacji bazowych BSS (BaseStation System) nale¿y zainstalowaæ modu³ nazwany PacketControl Unit (PCU). Modu³ ten umo¿liwia transmisje pakietowew sieci radiowej, bez koniecznoœci modernizacji interfejsu radio-wego. Dane pakietowe s¹ przesy³ane z modu³u PCU do wêz³aSGSN. PCU zainstalowany w BTS (Base Transceiver Station)nazywa siê Integrated PCU, natomiast zainstalowany w BSC(Base Station Controller) – Remote PCU. Zadaniem PCU jest za-rz¹dzanie wspó³dzielonymi przez wielu u¿ytkowników zasobamiradiowymi. Umo¿liwia on równie¿ przyporz¹dkowanie wieluszczelin czasowych pojedynczemu u¿ytkownikowi.

Dla wdro¿enia GPRS niezbêdne s¹ modyfikacje nastêpuj¹-cych elementów systemu GSM: M rejestru HLR (Home Location Register), który przechowujeprofil QoS u¿ytkownika (omówiony w dalszej czêœci artyku³u),obecny adres obs³uguj¹cego go wêz³a SGSN i adres kontekstuPDP; M rejestru VLR, który po rozbudowaniu – podobnie jak HLR –mo¿e dodatkowo mieæ informacje, zapewniaj¹ce koordynacjêoperacji GSM i GPRS (wspólne operacje zestawiania po³¹czeñ,aktualizacjê po³o¿enia u¿ytkownika itp.); M SMS−GMSC (Short Message Service – Gateway Mobile Swit-ching Centre), maj¹cego interfejs ³¹cz¹cy je z SGSN w celu prze-

kazywania krótkich wiadomoœci SMS (Short Message Service)za pomoc¹ systemu GPRS.

Powy¿sze operacje charakteryzuje stosunkowo niski stopieñzmian w dotychczasowej strukturze sieci GSM i zwi¹zana z tym³atwoœæ jej modernizacji. W systemie GPRS dla potrzeb agrega-cji strumieni danych zastosowano sieæ Frame Relay. Sieæ ta wy-korzystuje popularne w systemie GSM interfejsy E1 (2 Mbit/s), cou³atwia jej instalacjê. Wszystkie wêz³y GSN komunikuj¹ siê zapomoc¹ protoko³u IP, który jest podstaw¹ „sieci szkieletowejGPRS” (GPRS Backbone Network). W obrêbie sieci szkieletowejGPRS pakiety IP nie s¹ jednak przekazywane bezpoœrednio,lecz s¹ one enkapsulowane (tunelowane) za pomoc¹ protoko³uGTP (GPRS Tunneling Protocol). W ³¹czu radiowym jest wyko-rzystywany protokó³ SNDCP (Subnetwork Dependent Conver-gence Protocol) umo¿liwiaj¹cy multipleksacjê ró¿nych protoko³ów(wraz z kompresj¹ „nadmiarowych” nag³ówków np. TCP/IP)i kompresjê przekazywanych danych (np. V. 42). Protokó³ BaseStation System GPRS Protocol (BSSGP) jest odpowiedzialny zaprzekazywanie pomiêdzy SGSN a BSS informacji zwi¹zanychz funkcjami RLC/MAC (Radio Link Control/ Medium Access Con-trol) oraz informacji s³u¿¹cych do zarz¹dzania tymi wêz³ami. Stosprotoko³ów systemu GPRS pokazano na rysunku 2.

Cech¹ charakterystyczn¹ systemu GPRS jest sesyjnoœæ. Se-sje s¹ nadzorowane przez wêze³ SGSN. Podstawowa jednostkasesyjna u¿ytkownika zosta³a nazwana Packet Data Protocol con-text (kontekst PDP). Dziêki temu mechanizmowi mo¿liwe jestmiêdzy innymi przyporz¹dkowanie numeru IP dla stacji MS orazprzekazywanie informacji o rutingu do wêz³ów SGSN i GGSN.

W warstwie ³¹cza LLC (Logical Link Control) zaimplementowa-no mechanizm ARQ (Automatic Repeat Request), s³u¿¹cy do re-transmisji b³êdnych ramek LLC pomiêdzy stacjami MS i wêz³emSGSN. Drugi podobny mechanizm ARQ zastosowano w war-stwie RLC/MAC (Radio Link Control/ Medium Access Control).Jego zadaniem jest retransmisja bloków o sta³ej d³ugoœci (po-wsta³ych w wyniku segmentacji ramek LLC). Na czas transmisjidanych w kanale radiowym s¹ zestawiane mikropo³¹czenia, tzw.przep³ywy chwilowe TBF (Temporary Block Flows). S¹ oneutrzymywane na czas potrzebny do przes³ania okreœlonej porcjidanych (np. ca³ego pakietu IP). Mikropo³¹czenie TBF dedykuje

OO Rys. 2. Stos protokołów systemu GPRS. Oznaczenia wyjaśniono w tekście

zasoby radiowe okreœlonemu u¿ytkownikowi – jest wiêc wskaza-ne, aby trwa³o ono stosunkowo krótko.

Oferowane w systemie GPRS us³ugi przenoszenia mo¿na po-dzieliæ na dwie kategorie:

M komunikacjê typu punkt-punkt (point-to-point – PTP); M komunikacjê typu punkt-wielopunkt (point-to-multipoint –PTM).

Komunikacja typu PTP mo¿e byæ realizowana w trybie bezpo-³¹czeniowym (w przypadku transmisji IP) lub po³¹czeniowym (wprzypadku transmisji X. 25), natomiast komunikacja grupowaPTM dopuszcza dwa tryby: ! komunikacjê grupow¹ dla okreœlonego obszaru geograficzne-go (nazwan¹ PTM−M); ! komunikacjê adresowan¹ do arbitralnie wybranej grupy u¿yt-kowników (nazwan¹ PTM−G).

Brak w chwili obecnej informacji dotycz¹cych implementacjimechanizmów PTM.

System dopuszcza ró¿ne typy jakoœciowe QoS (Quality of Ser-vice) us³ug przenoszenia. Tzw. profile u¿ytkownika GPRS (sub-scriber QoS profile) uwzglêdniaj¹ ró¿ne klasy priorytetówtransmisji: high precedence, normal precedence, low preceden-ce oraz ró¿ne klasy niezawodnoœci transmisji (tabela 1), a tak¿eró¿ne klasy opóŸnieñ (tabela 2) [4].

W systemie GPRS zdefiniowano kilkanaœcie klas przep³ywno-œci, bior¹c pod uwagê wartoœci szczytowe: od 8 kbit/s do 2048kbit/s oraz wartoœci œrednie: od 0,22 bit/s (sic!) do 111 kbit/s. Wcelu zapewnienia du¿ych szybkoœci transmisji umo¿liwiono z³o-¿enie do 8 szczelin czasowych (Time Slot) w kanale radiowymo szerokoœci 200 kHz. Dopuszczalne s¹ 4 techniki kodowaniakana³owego (Coding Scheme, okreœlane jako CS-1 do CS-4),które w przypadku kana³ów radiowych o dobrej jakoœci umo¿li-wiaj¹ uzyskiwanie wiêkszych przep³ywnoœci (kosztem redukcjiinformacji przesy³anych dla potrzeb korekcji b³êdów). Ich charak-terystykê przedstawiono w tabeli 3.

Problemy z GPRS: za wolno, za du¿eopóŸnienia

Wydaje siê, ¿e obecnie u¿ytkownicy systemu GSM z niecier-pliwoœci¹ oczekuj¹ na system GPRS, wiele sobie po nim obiecu-j¹c, a w ka¿dym razie mo¿liwoœæ „szybkiej” transmisji danychi stosunkowo niskie koszty korzystania z tego typu us³ugi. Mog¹siê oni poczuæ rozczarowani, poniewa¿ wbrew powszechnej doniedawna opinii omawiane rozwi¹zanie nie jest jednak wolne odwad, a w ka¿dym razie znacz¹co odbiega od powszechnie sto-sowanego modelu sieci IP. M Ze wzglêdu na znaczn¹ objêtoœæ, nag³ówek IP jest kompreso-wany w kanale radiowym (nie s¹ zatem wykorzystywane mecha-nizmy IP dostêpu do medium). M Pakiety IP przekazywane miêdzy wêz³ami SGSN oraz GGSNs¹ tunelowane za pomoc¹ protoko³u GTP – oznacza to brak wy-korzystywania mechanizmów rutingowych sieci IP oraz centrali-zacjê ruchu w wybranych wêz³ach. Rozwi¹zanie takie jestsprzeczne z filozofi¹ internetow¹. M Teoretycznie osi¹gane przep³ywnoœci zale¿¹ zarówno od licz-by wykorzystywanych szczelin radiowych, jakoœci samego kana-³u radiowego (parametr zmienny w czasie), jak i od liczby rów-noczesnych u¿ytkowników systemu. Wszystkie te cechy powo-duj¹, ¿e trudno mówiæ o systemie GPRS jako systemie szybkie-go dostêpu do sieci Internet. Wielu potencjalnych u¿ytkowników,którzy oczekiwali „dedykowanej” przep³ywnoœci na poziomie170 kbit/s mo¿e byæ rozczarowanych obecn¹ œredni¹ przep³yw-noœci¹ na poziomie kilkunastu kbit/s (w praktyce mo¿e to byæjeszcze mniej). M Zastosowane mechanizmy transmisji powoduj¹, ¿e czas uzy-skiwania potwierdzeñ w przypadku transmisji niezawodnych (re-liable), z wykorzystaniem takich protoko³ów, jak TCP czy HTTP,jest bardzo d³ugi (nawet rzêdu sekund), znacz¹co wp³ywa naosi¹gane przep³ywnoœci i mo¿e nie zostaæ zaakceptowany przezu¿ytkowników (odczuwalne obni¿enie komfortu korzystaniaz sieci WWW). M Wystêpuj¹ przerwy w transmisji danych zwi¹zane z prze-mieszczaniem siê u¿ytkownika pomiêdzy komórkami sieci. Przer-wy te wi¹¿¹ siê z zastosowanym w systemie mechanizmempreselekcji stacji bazowej. Do wymienionych „wad wrodzonych”systemu GPRS nale¿y dodaæ wiele problemów praktycznychzwi¹zanych z jego implementacj¹: M brak GPRS killer application; M nieznan¹ liczbê potencjalnych u¿ytkowników (byæ mo¿e niewiêcej ni¿ 10% abonentów GSM); M klêskê rynkow¹ systemu WAP (skrót odczytywany z³oœliwiejako Wait for Another Product), który potencjalnie móg³by dosko-nale wspó³pracowaæ z systemem GPRS; ocena WAP jest tutajporównywana z popularnoœci¹ japoñskiego systemu i-mode –ponad 20 mln u¿ytkowników w marcu 2001 r; M ma³e przep³ywnoœci oferowane u¿ytkownikom – w ekspery-mentach BT Cellnet osi¹gniêto œredni¹ przep³ywnoœæ na pozio-mie 10 kbit/s;

358 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

OO Tabela 1. Klasy niezawodności transmisji

1 10–9 10–9 10–9 10–9

2 10–4 10–5 10–5 10–6

3 10–2 10–5 10–5 10–2

Klasa

Prawdopodobieństwo

utraty pakietów

powiele−nia

pakietu

utraty kolejno−ści przesyłania

pakietów

uszkodzenia pakietu (brakmożliwościkorekcji)

OO Tabela 2. Klasy opóźnień transmisji

Kla−sa

Pakiety 128−bajtowe Pakiety 1024−bajtowe

Wartośćśrednia

opóźnienia

Opóźnienie95%

pakietów

Wartość średnia

opóźnienia

Opóźnienie95%

pakietów

1 < 0,5 s < 1,5 s <2 s < 7 s

2 < 5 s <25 s <15 s < 75 s

3 < 50 s <250 s <75 s <375 s

4 best effort best effort best effort best effort

OpóŸnienia s¹ definiowane jako czas przekazywania pakietów pomiê-dzy dwoma terminalami ruchomymi. Warto zwróciæ uwagê na stosun-kowe du¿e opóŸnienia transmisji. Tak du¿e wartoœci opóŸnieñ nie s¹obecnie spotykane nawet w publicznej sieci Internet dzia³aj¹cej w try-bie best effort. Utrudniaj¹ one (o ile nie uniemo¿liwiaj¹) implementacjêus³ug interaktywnych, a w wielu przypadkach poprawn¹ pracê nieza-wodnych protoko³ów transportowych (np. TCP).

CS-1 0,5 9,05 kbit/s

CS-2 0,66 13,4 kbit/s

CS-3 0,75 15,6 kbit/s

CS-4 1 21,34 kbit/s

OO Tabela 3. Typy kodowania kanałowego i ich przepływności

Typ kodowania

Szybkość kodu

Strumień danych dla pojedynczej szczeliny

czasowej

359PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

M zbyt ograniczon¹ ca³kowit¹ pojemnoœæ jednej komórki dlatransmisji danych [1]; M mechanizm Always-on, który ³atwo mo¿e prowadziæ do prze-ci¹¿enia systemu [3]; M koniecznoœæ starannego rozplanowania pokrycia radiowegoz uwzglêdnieniem kana³ów dedykowanych transmisji GPRS [3],a tak¿e brak jasnych regu³ umo¿liwiaj¹cych planowanie sieci ra-diowej dla tego systemu (brak charakterystyk ruchowych u¿yt-kowników GPRS, tzw. modelu u¿ytkownika); M przy korzystaniu z trybu CS-2 osi¹ga siê wprawdzie popraw-ne transmisje do 80-90 proc. zasiêgu dla telefonii w systemieGSM, ale transmisja w trybach CS-3 i CS-4 jest mo¿liwa naznacznie mniejszym obszarze; M du¿e opóŸnienia: wymagana optymalizacja protoko³u TCP dlapotrzeb GPRS (retransmission timeout, rozmiar okna TCP,SACK) [6]; w przypadku korzystania z systemu WAP jest wyso-ce prawdopodobna koniecznoœæ transmisji ma³ych plików, co im-plikuje wielokrotne zestawianie kana³ów TBF i zwi¹zane z tymdu¿e opóŸnienia; M brak obecnie narzêdzi umo¿liwiaj¹cych satysfakcjonuj¹cemonitorowanie systemu GPRS [5]; M brak mechanizmu store & forward, który zapewni³by eleganc-k¹ wspó³pracê z podsystemem SMS [1]; M brak dostatecznej liczby typów terminali systemu GPRS; domarca 2001 r. zaledwie dwóch producentów oferowa³o terminaleGPRS, terminale te umo¿liwiaj¹ obecnie sk³adanie zaledwie2 lub 3 szczelin czasowych, co oznacza maksymalne przep³yw-noœci transmisji na poziomie 20-30 kbit/s (zaledwie!); istniejeobawa, ¿e ze wzglêdu na szkodliwe promieniowanie radiowe niepojawi¹ siê odbiorniki konkatenuj¹ce wiêcej ni¿ 3 szczeliny cza-sowe (zapewni to transmisjê do 30 kbit/s) [3]; M nieznany dok³adnie pobór mocy terminali GPRS; M obecnie oferowane terminale pracuj¹ jedynie w trybach CS-1i CS-2 (dotychczas nie zaimplementowano trybów CS-3 i CS-4),brak jest regu³ okreœlaj¹cych przechodzenie od jednego do dru-giego trybu CS, w miarê pogarszaj¹cego siê stosunku C/I (Car-rier to Interference); M problemy ze wspó³prac¹ urz¹dzeñ pochodz¹cych od ró¿nychproducentów; M brak miêdzyoperatorskiej (miêdzynarodowej) sieci umo¿liwia-j¹cej roaming GPRS powodowany miêdzy innymi ró¿nymi termi-nami wdro¿enia systemu GPRS przez operatorów GSM;zagadnienia z tym zwi¹zane (GPRS Roaming Exchange – GRX)s¹ dopiero w fazie wstêpnych propozycji (numeracja, adresacja,sygnalizacja, QoS, poufnoœæ) [2].

Wdro¿enie systemu GPRS znacznie siê opóŸni³o. Pierwotniejego wdro¿enie mia³o nast¹piæ w roku 2000. Obecnie wielu ope-ratorów zapowiada uruchomienie systemu GPRS w drugiej po³o-wie bie¿¹cego roku i zapowiada prawdziw¹ jego eksplozjêdopiero w 2002 roku. Trudno jednak oszacowaæ potencjaln¹ licz-bê jego u¿ytkowników. Problem polega na tym, ¿e w 2002 rokuma siê pojawiæ komercyjnie system UMTS, którego funkcje trans-misji danych s¹ o wiele efektywniejsze ni¿ systemu GPRS. Gdy-by system UMTS zosta³ uruchomiony w planowanym terminie, tooznacza³oby to, ¿e GPRS ma przed sob¹ zaledwie „rok ¿ycia”(mo¿liwe jest oczywiœcie „celowe” opóŸnienie wdro¿enia systemuUMTS, aby zamortyzowaæ koszty instalacji systemu GPRS).Z punktu widzenia operatorów GSM, którzy ponieœli koszty namodernizacjê sieci PLMN (rzêdu 100–300 mln USD), a dodatko-wo bêd¹ musieli ponieœæ koszty zwi¹zane z dop³at¹ do terminaliGPRS, marketingiem i obs³ug¹ systemu, sytuacja nie wygl¹daoptymistycznie. Mo¿liwe (i wysoce prawdopodobne) jest utrzymy-wanie sieci GSM/GPRS i UMTS równolegle, jednak ze wzglêdówbiznesowych jest to rozwi¹zanie kontrowersyjne. Pojawiaj¹ce siêinformacje o wprowadzeniu wielosystemowych telefonówGSM/GPRS/UMTS nie wydaj¹ siê zbyt realistyczne, skoro pro-dukcja samych terminali GPRS przysparza tak wielu problemów.

Jak wynika z wymienionej listy zagadnieñ, system GPRS, któ-ry mia³ byæ wzglêdnie tanim i ³atwym do wdro¿enia systemem„emuluj¹cym us³ugi systemów trzeciej generacji” sta³ siê ju¿ dlawielu operatorów sieci GSM doœæ powa¿nym problemem i trud-no obecnie przewidzieæ jego przysz³oœæ, poniewa¿ jest ona za-le¿na od wielu czynników. Najwa¿niejszym z nich wydaje siêrzeczywisty termin wdro¿enia systemu UMTS. GPRS mia³ byætestem popularnoœci us³ug systemu UMTS, a wszystko wskazu-je na to, ¿e sta³ siê probierzem problemów, przed którymi stoj¹operatorzy systemów UMTS. Symptomatyczny dla systemuUMTS, podobnie jak w przypadku GPRS, jest brak w oferciehandlowej terminali. Powszechnie uwa¿a siê, ¿e fakt ten mo¿eznacz¹co opóŸniæ jego wdro¿enie.

Ze wzglêdu na dostrze¿one problemy, zwi¹zane z du¿ymiopóŸnieniami transmisji danych oraz przerwami w transmisjiw systemie GPRS, warto przedstawiæ dwa mechanizmy tegosystemu, czêœciowo odpowiedzialne za te zjawiska.

M Capacity on demand – w systemie GPRS zosta³o wprowa-dzonych wiele logicznych kana³ów transmisji danych (PacketData CHannel – PDCH). Czêœæ z nich to kana³y sygnalizacyjne,natomiast pozosta³e kana³y s³u¿¹ do transmisji danych. W przy-padku transmisji uplink abonent ruchomy musi najpierw prze-s³aæ do systemu BSS, za pomoc¹ wspó³dzielonego przez innychu¿ytkowników kana³u sygnalizacyjnego (Packet Random Ac-cess CHannel – PRACH), ¿¹danie transmisji danych (mecha-nizm typu slotted ALOHA) i dopiero po uzyskaniu potwierdzeniarezerwacji odpowiednich szczelin czasowych jest realizowanatransmisja danych. Operacja ta mo¿e byæ wyd³u¿ona w przypad-ku kolizji w kanale sygnalizacyjnym – w górê (uplink) orazw przypadku obci¹¿enia kana³u – w dó³ (downlink) przez innychu¿ytkowników (kolejkowanie zg³oszeñ z uwzglêdnieniem priory-tetów, jak równie¿ autonomicznie podejmowanych operacjiARQ).

M Cell selection, cell re−selection. Terminal abonenta rucho-mego dokonuje wyboru stacji bazowej GPRS na podstawie ana-lizy wielu parametrów, zwi¹zanych ze stanem ³¹cza radiowegostacji bazowych znajduj¹cych siê w zasiêgu terminalu. W przy-padku koniecznoœci zmiany tzw. obszaru rutingowego (RoutingArea – RA), wskutek np. przemieszczenia siê abonenta lubzmiany warunków ruchowych, nale¿y uruchomiæ stosunkowoz³o¿on¹ procedurê, która w praktyce powoduje przerwê w trans-misji rzêdu 6–10 sekund [5].

Warto przytoczyæ wyniki opóŸnieñ transmisji danych, któreuzyskano w realizowanych eksperymentach. Wyniki badañ do-konanych przez operatora portugalskiego TMN dla trybu pracyTS = 3 + 1, przedstawiono poni¿ej [8]:

M operacja attach: 6 sekund; M operacja ping: od 1,5 do 3 sekund; M WAP access: od 10 do 20 sekund; M nawigacja WAP: od 2 do 4 sekund; M transfer plików (FTP): od 20 kbit/s (ma³e pliki) do ponad30 kbit/s (du¿e pliki).

Bardziej szczegó³owe badania opóŸnieñ pomiêdzy stacj¹ MSi wêz³em GGSN dokonane przez BT Cellnet przedstawionow tabeli 4 [9].

Podstawowe elementy wprowadzaj¹ce opóŸnienia w systemieGPRS to:

M Mobile Station (MS) – opóŸnienie wprowadzane przez stacjêruchom¹ MS, wynikaj¹ce z przetwarzania pakietów IP i ¿¹daniauzyskania zasobów radiowych; M zestawienie/roz³¹czenie TBF – czas wymagany przez modu³PCU systemu BSS w celu przydzielenia lub zwolnienia zasobówradiowych w kana³ach uplink lub downlink; operacja ta pojawia

siê jedynie podczas pierwszej transmisji i nie jest wymagana a¿do zwolnienia zasobów przez dan¹ stacjê MS; M opóŸnienie ³¹cza radiowego – opóŸnienie zale¿ne od szybko-œci, z jak¹ dane u¿ytkownika s¹ przesy³ane w kanale radiowym,po zestawieniu TBF; opóŸnienie to jest zale¿ne od wielkoœci pa-kietu IP i liczby wykorzystywanych szczelin TS; M SGSN/GGSN – opóŸnienie wprowadzane przez wêz³y SGSNi GGSN w zwi¹zku z przetwarzaniem pakietów, jak widaæ opóŸ-nienie to (zgodnie z oczekiwaniami) przyjmuje stosunkowo ma³ewartoœci.

Przedstawione wyniki eksperymentów wskazuj¹ wyraŸnie, ¿ekomercyjny sukces systemu GPRS nie jest gwarantowany. Niejest pewne, jak u¿ytkownicy zareaguj¹ na stosunkowo niskieprzep³ywnoœci i d³ugie opóŸnienia transmisji. Byæ mo¿e operato-rzy bêd¹ musieli przygotowaæ specjalny zestaw aplikacji, którynie jest specjalnie wra¿liwy na te cechy. Nie bêd¹ to jednak takiesamie us³ugi, jakie bêdzie mo¿na zaoferowaæ w systemie UMTS.Trudno obecnie przes¹dziæ o klêsce rynkowej systemu GPRS,jednak paradoksalnie mog³oby siê okazaæ, ¿e ta klêska by³abysiln¹ motywacj¹ do... szybszego wdro¿enia systemu UMTS.

Nale¿y równie¿ podkreœliæ, ¿e oczekiwana przez wielu opera-torów GSM, a podkreœlana przez wielu producentów, ewolucjasieci GSM w kierunku sieci UMTS via GPRS ma niewiele wspól-nego z rzeczywistoœci¹. Ró¿nice pomiêdzy systemami UMTSi GSM/GPRS s¹ fundamentalne, bowiem pomijaj¹c urz¹dzeniawarstwy fizycznej i transmisyjnej wszystkie pozosta³e elementys¹ zupe³nie inne.

Czasopismo 3G Mobile (luty 2001) wymienia a¿ 35 operatorówkomercyjnego systemu GPRS, w tym 2 z Polski. Nale¿y jednakdomniemywaæ, ¿e w wiêkszoœci przypadków s¹ to jedynie danedotycz¹ce eksperymentów. Brak jest obecnie danych dotycz¹-cych rzeczywistej liczby u¿ytkowników komercyjnych systemuGPRS, a jest to jedyny miernik prawdziwej skali implementacjitego systemu.

Warto równie¿ wspomnieæ o rozwi¹zaniu EDGE (EnhancedData rate for GSM Evolution). W systemie EDGE zastosowanobardziej efektywn¹ modulacjê (8−PSK versus GMSK stosowan¹w systemie GSM/GPRS), co zapewnia uzyskanie przep³ywnoœcido 59,2 kbit/s w TS (a ca³kowite przep³ywnoœci s¹ zbli¿one dotych, które uzyskuje siê w systemie UMTS). Architektura EDGEzapewnia ewolucyjne przejœcie od systemu GSM do systemuUMTS. W szczególnoœci system EGPRS umo¿liwia transparent-n¹ wspó³pracê z systemem GPRS i wykorzystanie wspólnychelementów sieci szkieletowej. Przysz³oœæ systemu EDGE nie jestzbyt pewna w zwi¹zku z wdra¿aniem ju¿ w przysz³ym roku sys-temu UMTS.

USŁUGI IP W SIECI UMTS

W odró¿nieniu od systemu GSM, w którym dominuj¹c¹ us³ug¹mia³a byæ us³uga g³osowa, w systemie UMTS od momentu roz-poczêcia jego projektowania zak³adano „równoprawne” œwiad-czenie us³ug telefonicznych i transmisji danych. Wypada równie¿zwróciæ uwagê na zdolnoœæ systemu UMTS do realizacji przeka-zów wizyjnych. Zagadnienie to jest interesuj¹ce, ale w sposóbnieco prowokacyjny: przekazy wizyjne s¹ mo¿liwe techniczniew sieci ISDN (jak sama nazwa wskazuje w sieci z integracj¹us³ug), jednak wbrew pierwotnym oczekiwaniom nie s¹ one po-pularne, mimo znacz¹cego spadku kosztu sprzêtu do transmisjiwideokonferencyjnych. Inna forma przekazów wizyjnych, a mia-nowicie wideo na ¿yczenie (video-on-demand), która mia³a byækiller application dla telekomunikacji szerokopasmowej (B−ISDN)i wykorzystywa³a system ATM, równie¿ zakoñczy³a swój ¿ywotpo wielu niezwykle kosztownych eksperymentach i nie zosta³a nigdzie wdro¿ona komercyjnie. Popularnoœæ us³ug wykorzystuj¹-cych przekazy wizyjne nie zosta³a wiêc potwierdzona w odniesie-niu do systemów stacjonarnych.

Nie ulega równie¿ w¹tpliwoœci, ¿e przekaz us³ug g³osowychb¹dŸ krótkich wiadomoœci tekstowych (SMS) jest znakomicie ob-s³ugiwany przez system GSM. Je¿eli wiêc ma siê przyj¹æ system³¹cznoœci ruchomej nowej generacji, to musi on mieæ istotne ce-chy, które przyci¹gn¹ równie¿ abonentów systemu GSM. Za ta-k¹ us³ugê twórcy systemu UMTS uznali „szybki dostêp” do sieciIP, maj¹c równie¿ na uwadze fakt, ¿e wiele aplikacji multimedial-nych bêdzie dzia³a³o w trybie over IP.

Nale¿y podkreœliæ, ¿e twórcy specyfikacji tego systemu zdecy-dowali siê na niezwykle radykalny krok, a mianowicie na skorzy-stanie z najnowszych technik telekomunikacyjnych (zarównoobecnie dostêpnych, jak i tych, które znajduj¹ siê dopiero w trak-cie opracowywania). Zastosowane podejœcie ma jedn¹, ale bar-dzo istotn¹ wadê – brak mo¿liwoœci ewolucyjnego przejœciaz systemu GSM do systemu UMTS. Obydwa systemy dziel¹ zbytfundamentalne ró¿nice.

Wydaje siê, ¿e najkrótsza charakterystyka systemu UMTS po-winna zawieraæ trzy jego cechy: M przesy³anie wszelkich informacji, w tym telefonicznych, w po-staci pakietowej; M uwzglêdnienie dedykowanych i wspó³dzielonych kana³ówo zmiennych przep³ywnoœciach; M zastosowanie modulacji W-CDMA jako techniki ³¹cza radio-wego dopuszczaj¹cego ró¿ne przep³ywnoœci strumieni danych.

Warto podkreœliæ, ¿e zaproponowane w systemie UMTS pakie-towe przesy³anie g³osu w postaci skompresowanej pomiêdzyabonentami (transparentne w sieci szkieletowej) niesie ze sob¹nastêpuj¹ce korzyœci: – mniejsze strumienie w sieci szkieletowej w porównaniu z sys-temem GSM, w którym sygna³ mowy by³ poddawany dekompre-sji (4–8 razy mniejszy strumieñ bitów); – eliminacjê ciszy; – redukcjê opóŸnienia typu end-to-end dziêki eliminacji operacjitranskodowania g³osu; – ni¿szy koszt urz¹dzeñ (brak transkoderów w sieci, z wyj¹t-kiem transkoderów do sieci stacjonarnej); – eleganck¹ integracjê danych i g³osu w jednej sieci (konwer-gencjê).

Przedstawione cechy umo¿liwiaj¹ obs³ugê przez systemUMTS kilkunastokrotnie wiêkszej liczby abonentów ni¿ w syste-mie GSM, przy wykorzystaniu ³¹czy transmisyjnych tego syste-mu. „Inteligencja” adaptacyjnego kodeka mowy AMR (AdaptiveMulti-Rate), zastosowanego w systemie UMTS, umo¿liwiaj¹cegodynamiczne reagowanie na stan ³¹cza radiowego, jest dodatko-wym atutem tej sieci. Du¿a efektywnoœæ obs³ugi us³ug g³osowychjest jednym z istotniejszych argumentów przemawiaj¹cych za

360 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

Stacja ruchomaMS 250 ms 100 ms 150 ms 150 ms

Zestawienie przep³ywu chwilowego TBF 400 ms 0 1000 ms 0

OpóŸnienie³¹cza radiowego 400 ms 400 ms 200 ms 200 ms

OpóŸnienie wnoszone przez wêz³y SGSN/GGSN 50 ms 50 ms 50 ms 50 ms

OpóŸnienie ca³kowite 1,1 s 0,55 s 1,4 s 0,4 s

OO Tabela 4. Wyniki pomiarów opóźnień pomiędzy stacją MS a wę−złem GGSN

Elementwprowadzają−cy opóźnienie

Z zestawie−niem

TBF−uplinkdla 1TS

ZestawionyTBF−uplink

dla 1TS

Z zestawie−niem TBF−−downlinkdla 2TS

Zestawio−ny TBF−

−downlinkdla 2TS

361PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

wdro¿eniem systemu UMTS – niestety nie jest to argument po-wszechnie znany.

Najistotniejsz¹ korzyœci¹ jest oczywiœcie mo¿liwoœæ agregacjiruchu transmisji danych (czytaj IP) oraz ruchu g³osowego. Rolaprotoko³u IP w najnowszych wersjach specyfikacji systemuUMTS jest wrêcz fundamentalna i choæ pierwotne specyfikacjetraktowa³y protokó³ IP jako protokó³ warstwy aplikacyjnej, to póŸ-niejsze wersje specyfikacji uwzglêdniaj¹ równie¿ zastosowanieprotoko³u IP w warstwach ni¿szych (z eliminacj¹ pozosta³ychprotoko³ów) oraz przekazywanie us³ugi g³osowej przez sieæ IP(VoIP). Model ten jest czêsto nazywany modelem All−IP.

System UMTS jest opisywany przez kilka wersji specyfikacjiopracowanych przez organizacjê 3GPP (Third Generation Part-nership Project: www.3gpp.org), która powsta³a w 1998 roku.Ewolucja specyfikacji dotycz¹cych systemu UMTS wynika z za-stosowanego podejœcia: punktem startowym powinna byæ wer-sja oparta na istniej¹cych rozwi¹zaniach (podejœcierealistyczne, doœæ czêsto stosowane przez organizacje standa-ryzacyjne), natomiast kolejne wersje mog¹ zawieraæ nowszekoncepcje.

Do pocz¹tku bie¿¹cego roku specyfikacje UMTS rozró¿nia³ydwie wersje systemu: M UMTS Release 99 (R99); M UMTS Release 2000 (R2000).

Od pocz¹tku bie¿¹cego roku wersja R2000 zosta³a podzielonana dwie nowe wersje specyfikacji oznaczone jako: M UMTS Release 4 (R4) – przewidywany termin zakoñczeniaprac: marzec 2001 r; M UMTS Release 5 (R5) – przewidywany termin zakoñczeniaprac: grudzieñ 2001 r.

Specyfikacje te ró¿ni¹ siê „skal¹ ingerencji” rozwi¹zañ IPw system UMTS. W przypadku specyfikacji R5 system UMTSmo¿na nazwaæ systemem IP dla abonentów ruchomych (nie jestto jednak to samo, co system Mobile IP).

Poni¿ej, w celu omówienia stopnia dostosowania UMTS doaplikacji internetowych, zostan¹ przedstawione jego podstawo-we cechy us³ugowe, czyli us³ugi przenoszenia (bearer services),poniewa¿ s¹ one niezale¿ne od wersji specyfikacji. Nastêpniezostan¹ omówione ró¿nice pomiêdzy wymienionymi wy¿ej spe-cyfikacjami w kontekœcie roli protoko³u IP w systemie UMTS.

Us³ugi przenoszenia w systemie UMTS

Z punktu widzenia wymagañ us³ugi dziel¹ siê na: ! us³ugi czasu rzeczywistego (real-time services) – dopuszczal-ne opóŸnienia przesy³ania informacji mieszcz¹ siê w zakresie20÷300 ms; ! us³ugi nie wymagaj¹ce czasu rzeczywistego (non real-timeservices) – opóŸnienia wynosz¹ 150 ms i wiêcej.

Z punktu widzenia lokalizacji abonentów oraz szybkoœci ichprzemieszczania rozró¿nia siê nastêpuj¹ce klasy przep³ywnoœci: ! tereny wiejskie (lub szybkoœæ przemieszczania do 500 km/h)– od 144 kbit/s do 384 kbit/s; ! tereny miejskie, podmiejskie (lub szybkoœæ przemieszczaniado 120 km/h) – od 384 kbit/s (typowo 512 kbit/s); ! wewn¹trz budynków (lub szybkoœæ przemieszczania do 10 km/h) – do 2 Mbit/s.

Dopuszcza siê dynamiczn¹ zmianê przep³ywnoœci, zale¿n¹np. od czynników radiowych (zak³ócenia itp.).

W systemie UMTS wyró¿nia siê cztery klasy us³ug: M klasê konwersacyjn¹ (conversational class), charakteryzuj¹c¹siê ma³ymi opóŸnieniami; M klasê us³ug strumieniowych (streaming class); M klasê us³ug interaktywnych (interactive class); M klasê us³ug „dzia³aj¹cych w tle” (background class).

Jak ³atwo siê domyœliæ, aplikacje korzystaj¹ce z wymienionychklas wymagaj¹ ró¿nych charakterystyk transmisyjnych (opóŸnie-nia, zmiennoœci opóŸnieñ transmisji pakietów, stopy b³êdów BER,asymetrii transmisji itp.). Dodatkowo wymienia siê us³ugi o cha-rakterze rozsiewczym (broadcast) i grupowym (multicast) [16].

Wykorzystanie ³¹cza radiowego W-CDMAdla transmisji IP

W publikacjach doœæ czêsto mo¿na znaleŸæ materia³y porów-nuj¹ce efektywnoœæ wykorzystania ³¹cza radiowego w syste-mach CDMA i TDMA w przypadku komunikacji g³osowej.W odniesieniu do systemu UMTS nale¿y równie¿ uwzglêdniæ ko-rzyœci wynikaj¹ce z zastosowania techniki W−CDMA (Wideband– Code Division Multiple Access) dla potrzeb pakietowej transmi-sji danych. W przypadku systemu UMTS wszystkie zagadnieniatransmisji radiowej s¹ rozwi¹zywane na poziomie warstwy ³¹czaW-CDMA. Warto wymieniæ kilka charakterystycznych cech tegorozwi¹zania: M mo¿liwoœæ transmisji pakietowej o niewielkich strumieniachw ³¹czach sygnalizacyjnych; M mo¿liwoœæ transmisji pakietowej w kana³ach wspó³dzielonych; M mo¿liwoœæ transmisji pakietowej w kanale dedykowanym; M mo¿liwoœæ transmisji danych w kanale o zmiennej przep³yw-noœci (zmiany mog¹ nastêpowaæ co 10 ms) dziêki zastosowaniukodów ortogonalnych OVSF (Orthogonal Variable SpreadingFactor); rozwi¹zanie to nie wymaga ¿adnych procedur sygnaliza-cyjnych, z wyj¹tkiem odpowiedniej rezerwacji na pocz¹tku trwa-nia sesji; M mo¿liwoœæ asymetrycznej alokacji strumieni uplink/downlinkdla potrzeb komunikacji klient-serwer.

Ze wzglêdu na stosunkowo du¿y rozmiar nag³ówków IP, dla po-trzeb transmisji radiowej s¹ one kompresowane – podobnie jakw systemie GPRS, w systemie UMTS klasyczne mechanizmy do-stêpu pakietowego, takie jak IP czy ATM, nie s¹ wykorzystywane.

System UMTS – wersja R99

Architekturê tej wersji systemu przedstawiono na rysunku 3.Jak widaæ architektura ta jest zbli¿ona do modelu GSM/GPRS –zachowano nawet podobne nazwy urz¹dzeñ (czasami z przed-rostkiem 3G-). Podobna jest równie¿ filozofia funkcjonalna syste-mu (zastosowanie tunelowania danych via protokó³ GTP,kontekst PDP itd.). Niestety, funkcjonalnoœæ urz¹dzeñ znacznieodbiega od funkcjonalnoœci urz¹dzeñ stosowanych w systemieGSM/GPRS, maj¹ one równie¿ inne interfejsy o znacznie wiêk-szych przep³ywnoœciach.

We wszystkich wersjach specyfikacji 3GPP systemu UMTSwyodrêbnia siê nastêpuj¹ce podsystemy:

M Core Network (zwany czêsto Core lub CN); sieæ UMTS Corenie jest jednak sieci¹ szkieletow¹ w powszechnym rozumieniutego znaczenia; M UMTS Terrestrial Access Network (UTRAN) – dostêp odpo-wiedzialny za aspekty zwi¹zane z ³¹czem radiowym (radiowasieæ dostêpowa systemu UMTS).

Bloki podsystemu CN pe³ni¹ tak¹ sam¹ rolê w systemie UMTSjak w systemie GSM/GPRS i w zwi¹zku z tym ich omówienie wy-daje siê zbêdne. W podsystemie UTRAN wystêpuj¹ dwa urz¹-dzenia: Node B i RNC (Radio Network Controller). Urz¹dzenia tes¹ odpowiednikami urz¹dzeñ BTS i BSC systemu GSM, jednakze wzglêdu na specyfikê systemu W-CDMA ich dzia³anie jest zu-pe³nie inne.

W wersji R99 wykorzystano technikê ATM, zarówno w sieciCN, jak i UTRAN [15], przy czym pe³ni ona tutaj rolê g³ównie sie-ci transportowej. W sieci CN wyraŸnie wyodrêbniono dwa pod-systemy (podobnie jak w modelu GSM/GPRS): M CS – Channel Switching – „komutacja kana³ów” do obs³ugikomunikacji g³osowej; M PS – Packet Switching – „komutacja pakietów” do obs³ugitransmisji danych.

W tej wersji urz¹dzenia systemu UTRAN maj¹ interfejsy typuATM (IuPS, IuCS, Iur, Iubis).

Zwolennicy techniki ATM – jako powody jej zastosowaniaw systemie UMTS wymieniaj¹: M dojrza³oœæ i stabilnoœæ w porównaniu z rozwi¹zaniami IP; M gwarantowanie przez ATM wartoœci QoS na poziomie nie-osi¹galnym w ¿adnym z innych obecnych rozwi¹zañ pakieto-wych; M mo¿liwoœæ monitorowania sesji u¿ytkowników z wykorzysta-niem mechanizmu CDR (Call Detail Record) dla potrzeb rozli-czeñ; M wysok¹ poufnoœæ po³¹czeñ wirtualnych; M mo¿liwoœæ wykorzystania sieci Core/ATM do pod³¹czaniaurz¹dzeñ dostêpowych innych systemów (np. modemówADSL/VDSL czy modemów sieci HFC typu Euromodem).

Urz¹dzenia UTRAN, czyli Node B i RNC s¹ ³¹czone za pomo-c¹ interfejsów ATM z nastêpuj¹cym rozgraniczeniem: M podsystem CS ³¹czy siê korzystaj¹c z ATM/AAL2 (rt-VBR) –styk IuCS; M podsystem PS ³¹czy siê korzystaj¹c z ATM/AAL5 (transmisjadanych) – styk IuPS.

Istotn¹ rolê w systemie odgrywa interfejs Iur s³u¿¹cy do prze-kazywania danych stacji ruchomej, o ile zmieni³a ona po³o¿eniei przemieœci³a siê z obszaru obs³ugiwanego przez RNC, którewykorzystano do nawi¹zania po³¹czenia lub rozpoczêcia sesji(zwany jest on Serving-RNC) do obszaru obs³ugiwanego przezs¹siednie RNC (zwane Drift-RNC). Tego typu podejœcie ozna-

cza, ¿e sieæ Core nie musi podejmowaæ ¿adnych dzia³añ w przy-padku przemieszczenia siê stacji ruchomej i zwiêksza separacjêfunkcjonaln¹ podsystemów CN i UTRAN oraz zapewnia szybsz¹reakcjê na zdarzenia.

W systemie PS sieci Core droga pakietów jest podobna do wy-stêpuj¹cej w systemie GPRS: przekazywane s¹ one do wêz³aSGSN, a nastêpnie (o ile abonent komunikuje siê z urz¹dzenia-mi sieciowymi innego operatora) do wêz³a GGSN. Niestety za-stosowany model ma te same wady, które zosta³y wymienioneprzy okazji omawiania systemu GPRS.

Opis CS mo¿na np. znaleŸæ w [15]. Warto zauwa¿yæ na rys. 3istnienie urz¹dzenia, okreœlonego mianem 3G−MSC, które pe³nirolê „centrali do obs³ugi ruchu g³osowego”. Ze wzglêdu na inhe-rentne mo¿liwoœci komutacji sieci ATM, obecnoœæ w tym modeluscentralizowanego urz¹dzenia do obs³ugi po³¹czeñ g³osowychwydaje siê zbêdna, a dodatkowo zastosowane podejœcie koncen-truje ruch w wybranych punktach sieci. Zagadnienie to bardziejelegancko rozwi¹zano w kolejnych wersjach specyfikacji systemuUMTS, w których urz¹dzenie 3G-MSC po prostu wyeliminowano,a jego funkcjonalnoœæ zapewniono w sposób rozproszony.

O specyfikacji R99 mo¿na powiedzieæ, ¿e opiera siê na spraw-dzonych technikach. Wiêkszoœæ realizowanych eksperymentówz systemami komórkowymi trzeciej generacji wykorzystywa³aw³aœnie tê specyfikacjê. Pierwszy na œwiecie operator, który jesz-cze w tym roku bêdzie komercyjnie oferowa³ us³ugi 3G, czyli Do-CoMo, wykorzystuje w swoim systemie technikê ATM.

Protokó³ IP w specyfikacjach UMTS R4i R5

Jak ju¿ zauwa¿ono, tendencja do wprowadzania rozwi¹zañ IPjest obecnie zauwa¿alna w wielu istniej¹cych systemach tele-komunikacyjnych, brak jest jednak klarownej motywacji do dez-instalowania istniej¹cych klasycznych central i sprzêtu telekomu-nikacyjnego oraz zastêpowania ich rozwi¹zaniami typu All-IP.Operacja taka jest kosztowna, wi¹¿e siê bowiem z koniecznoœci¹wprowadzania nowych urz¹dzeñ (w tym kodeków mowy). W wie-lu przypadkach konieczna jest równie¿ wymiana zainstalo-wanych ju¿ urz¹dzeñ sieci IP, poniewa¿ nie maj¹ one mechaniz-mów gwarantuj¹cych obs³ugê aplikacji IP czasu rzeczywistego.W przypadku us³ug telefonicznych uzyskana funkcjonalnoœæ nieprzewy¿sza jakoœciowo rozwi¹zañ klasycznych, a w wielu przy-padkach jest wrêcz przeciwnie. W przypadku systemu UMTS sy-tuacja wygl¹da odmiennie, przy czym du¿¹ czêœæ funkcjonal-noœci All-IP mo¿na osi¹gn¹æ w wersji zgodnej ze specyfikacj¹R99.

Argumenty za stworzeniem sieci UMTS typu All-IP z pominiê-ciem sieci ATM, wymieniane g³ównie przez zwolenników rozwi¹-zañ IP, to: M nieefektywnoœæ obs³ugi ruchu IP przez system ATM; M skomplikowane zarz¹dzanie po³¹czeniami SVC lub PVC (ko-niecznoœæ zestawiania po³¹czeñ na poziomie zarz¹dzania sie-ci¹); M niewykorzystanie zaawansowanych mechanizmów ATM dlapotrzeb komunikacji IP (brak ATM API); M znaczny ruch sygnalizacyjny; M s³aba skalowalnoœæ sieci ATM; M znaczny koszt urz¹dzeñ ATM w porównaniu z urz¹dzenia-mi IP.

Konstrukcja sieci UMTS jako modelu All−IP ma wiêc swojeuzasadnienie. Jest to bowiem system, który staje siê ³¹czem in-ternetowym abonenta ruchomego, zapewniaj¹c mu ³¹cznoœæ IPtypu Anywhere-on and Always-on.

Warto przypomnieæ, ¿e w modelu All-IP us³uga g³osowa mo¿ebyæ realizowana w trybie VoIP. Zastosowanie sieci IP do œwiad-

362 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

OO Rys. 3. Architektura systemu UMTS R99. Oznaczenia wyjaśnionow tekście

363PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

czenia us³ug g³osowych czy innych us³ug wymagaj¹cych stru-mieni danych czasu rzeczywistego nie jest bezproblemowe,a w³aœciwie mo¿na mówiæ, ¿e rodzi istotne problemy. Dotychczasnie uda³o siê bowiem zapewniæ gwarancji QoS w sieci IP. Od kil-ku lat istnieje co prawda rozwi¹zanie oparte na protokole RSVP(uto¿samiane równie¿ z modelem Integrated Services – Int−Serv), jednak ze wzglêdu na brak jego skalowalnoœci nie jest po-wszechnie stosowane. Olbrzymim zainteresowaniem cieszy siêostatnio model DiffServ (Differentiated Services), który umo¿li-wia przypisywanie priorytetów pakietom IP (podzia³ ich na prede-finiowane klasy) i odpowiedni¹ ich obs³ugê pomiêdzy s¹siednimiwêz³ami sieci (Per-Hop-Behaviour). W oryginalnej wersji modelDiffServ nie wymaga³ sygnalizacji, jednak nie oferuje on QoSw relacji end-to-end (oferowany QoS jest okreœlany mianem soft-QoS). Innym protoko³em Internetu, który cieszy siê du¿ymzainteresowaniem jest protokó³ MPLS (Multiprotocol Label Swit-ching). G³ówn¹ jego cech¹ jest zdolnoœæ do efektywnego trans-portu pakietów (przewa¿nie IP, chocia¿ jego nazwa wskazuje, ¿enie tylko) w sieci szkieletowej. Protokó³ ten w kontekœcie sieci IPma równie¿ istotne wady – jest on mianowicie protoko³em po³¹-czeniowym, nie obs³uguje multicastu (nie jest wiêc prawd¹, ¿esieæ MPLS to sieæ IP!), jak równie¿ nie gwarantuje QoS. Ostatnietrendy wskazuj¹ na zastosowanie protoko³u RSVP dla dokony-wania rezerwacji dla zagregowanych strumieni zarówno w sieciDiffServ, jak i MPLS (MPLS-TE). Oznacza to oczywiœcie wpro-wadzenie elementów sygnalizacji, jednak na du¿o mniejszym po-ziomie ni¿ w przypadku samego protoko³u RSVP, dzia³aj¹cegow trybie per flow. To w³aœnie zintegrowane rozwi¹zanie Dif-fServ/MPLS jest upatrywane jako docelowe rozwi¹zanie IP/QoSsieci UMTS (zarówno CN, jak i UTRAN). Niestety, sytuacja niejest tak prosta, jak mog³oby siê to wydawaæ. Zarówno model Dif-fServ, jak i MPLS, znajduj¹ siê wci¹¿ w fazie opracowañ, istnie-j¹ce specyfikacje ci¹gle podlegaj¹ ewolucjom, brak jestpraktycznych doœwiadczeñ z ich implementacj¹ na szerok¹ ska-lê, uwzglêdniaj¹c¹ potrzeby QoS. Dodatkowo brak jest wspó³pra-cy rozwi¹zañ pochodz¹cych od ró¿nych producentów.Uruchomiono wiele programów badawczych (np. europejskieprojekty IST), w których za³o¿ono rozwi¹zanie omawianych pro-blemów w perspektywie 2–3 – letniej. Oznacza to, ¿e szanse nauzyskanie stabilnych specyfikacji UMTS, opartych na modelu All-IP, w bie¿¹cym roku (zgodnie z planami 3GPP) s¹ nik³e. Nierozwi¹zanym zagadnieniem jest równie¿ wybór pomiêdzy proto-ko³ami IPv4 i IPv6. Na korzyœæ tego ostatniego przemawia jegowiêksza przestrzeñ adresowa, zwiêkszony poziom bezpieczeñ-stwa i zdolnoœæ do autokonfiguracji urz¹dzeñ, natomiast jego wa-d¹ jest wiêkszy nag³ówek pakietów IP.

Na marginesie warto zauwa¿yæ, ¿e œwiadczone obecnie us³u-gi VoIP nie zapewniaj¹ jakoœci us³ug QoS, a ich „w miarê” po-prawne dzia³anie jest zapewniane przez „nadwymiarowanie”sieci (over-dimensioning).

Istniej¹c¹ sytuacjê mo¿na oceniæ jako nieco schizofreniczn¹:istnieje rozwi¹zanie gwarantuj¹ce hard−QoS (tzn. ATM), aleuznaje siê, ¿e narzuty zwi¹zane z jego obs³ug¹ s¹ nadmierne;istnieje (a raczej jest oczekiwane) drugie rozwi¹zanie oferuj¹cesoft−QoS (tzn. DiffServ), w którym z kolei za³o¿ono „lekkie nad-wymiarowanie” sieci. Jak widaæ, obydwa rozwi¹zania nie roz-wi¹zuj¹ problemu efektywnego wykorzystania pasma. Nasuwasiê zreszt¹ pytanie: czy w dobie DWDM every bit must be coun-ted1)?

Specyfikacja UMTS wersja R4W specyfikacjach R4 i R5 zak³ada siê ewolucyjne przekszta³-

canie modelu R99 w stronê modelu All-IP.

Architekturê modelu R4 przedstawiono na rys. 4. Zasadniczymnovum jest dekompozycja 3G-MSC i wykorzystanie mechani-zmów komutacyjnych sieci pakietowej. Nowe elementy architek-tury tego rozwi¹zania to: M Media Gateways (MGW) – urz¹dzenia s³u¿¹ce do prze-kszta³cenia informacji uzyskiwanych z innych typów sieci, b¹dŸ wychodz¹cych do innych typów sieci (kompresja, dekompre-sja, usuwanie echa), do postaci pakietowej (ATM/AAL-2,IP/UDP/RTP); M MSC Server – sterownik sygnalizacji obs³uguj¹cy po³¹czenia(call control) realizowane za poœrednictwem urz¹dzeñ MGW; dosterowania jest wykorzystywany protokó³ H. 248/MEGACO;urz¹dzenie to bywa równie¿ okreœlane jako Media Gateway Con-troller (MGC); M Roaming Signalling Gateway (R−SGW) – urz¹dzenie do kon-wersji sygnalizacji SS7 u¿ywanej w systemie R99 na sygnaliza-cjê przenoszon¹ w sieci IP (SS7/MTP versus Sigtran SCTP/IP).

Omawiane rozwi¹zanie jest obecnie oferowane przez wieluproducentów, nie tylko dla potrzeb UMTS. Bywa równie¿ okreœla-ne mianem Softswitch lub Virtual Switch (VS). Zastosowanew nim podejœcie zapewnia separacjê p³aszczyzn steruj¹ceji u¿ytkownika. Wyj¹tkow adekwatnoœæ tego rozwi¹zania dla sys-temu UMTS wynika z: M sieci pakietowej jako podstawy systemu UMTS – stanowi onanaturaln¹ czêœæ modelu VS; M dominuj¹cej postaci skompresowanej informacji g³osowej(operacja kompresji/dekompresji jest realizowana w terminalachu¿ytkowników), co powoduje, ¿e urz¹dzenia MGW s¹ potrzebnewy³¹cznie na styku z innymi sieciami; M efektywnej obs³ugi przez VS aplikacji real-time o ró¿nych wy-maganiach QoS, które – jak to ju¿ zosta³o wymienione – stano-wi¹ cechê wyró¿niaj¹c¹ systemu UMTS.

W tej wersji specyfikacji „wzmocniono” równie¿ rolê protoko³uIP, dopuszczaj¹c nowe formy interfejsów urz¹dzeñ zarówno CN,jak i UTRAN.

1) Trawestacja powtarzanego do znudzenia po wyborach prezydenckichw USA w 2000 roku przez Al Gore’a zdania Every vote must be counted!

OO Rys. 4. Architektura systemu UMTS R4. Oznaczenia wyjaśnionow tekście

System IM jest do³¹czony do interfejsu Gi wêz³a GGSN i za-wiera nastêpuj¹ce bloki: M MGW (Media Gateway) – wykorzystywany równie¿ w mode-lu R4; M MGCF (Media Gateway Control Function) – blok odpo-wiedzialny za sterowanie urz¹dzeniami MGW oraz wspó³-pracê z urz¹dzeniem CSCF (konwersja protoko³ów ISUP,R1/R2); M T−SGW (Transport – Signalling Gateway Function) – urz¹dze-nie realizuj¹ce mapowanie sygnalizacji z/do sieci PSTN/PLMNna sieæ IP oraz przesy³aj¹ce j¹ do urz¹dzenia MGCF; M CSCF (Call State Control Function) – sterownik sesji u¿ytkow-ników (call control, incoming call gateway);

M R−SGW (Roaming – Signalling Gateway) – wykorzystywanyrównie¿ w modelu R4; M MRF (Multicast Resource Function) – sterownik komunikacjigrupowej, odpowiadaj¹cy funkcjonalnie urz¹dzeniu H. 323 MCU(Multipoint Control Unit); M HSS (Home Subscriber Server) – rozszerzony odpowiednikHLR, zawieraj¹cy bazê danych o u¿ytkownikach.

Wymieniony podsystem umo¿liwia realizacjê po³¹czeñ telefo-nicznych za pomoc¹ podsystemu PS, a zatem po³¹czeñ okreœla-nych mianem VoIP. Dopuszczalne jest zastosowanie zarównostandardu H. 323, jak i SIP (Session Initiation Protocol). Wartozauwa¿yæ, ¿e w wymienionych standardach jest mo¿liwy równie¿przekaz informacji wizyjnych i danych (np. zgodnie z zalecenia-mi T. 120/H. 323), co uzasadnia nazwê podsystemu, jako umo¿-liwiaj¹cego komunikacjê multimedialn¹ over IP. Istotn¹ cech¹jest jednak zapewnienie QoS (lub jego negocjacje) dla podsyste-mu IM, co w praktyce oznacza modyfikacjê istniej¹cych standar-dów H. 323 i SIP.

Nowe cechy tej wersji specyfikacji to równie¿:

M szybka transmisja pakietowa w kanale downlink; M modyfikacje UTRAN w celu wsparcia operacji podsystemu IM; M wsparcie dla us³ug typu push.

Oczywiœcie dla zapewnienia pe³nej funkcjonalnoœci podsyste-mu IM, a zwi¹zanej z us³ugami typu IN, potrzebne s¹ równie¿ od-powiednie modyfikacje specyfikacji CAMEL.

W najnowszych dokumentach 3GPP doœæ czêsto pojawia siêrównie¿ has³o IP−UTRAN, co nale¿y interpretowaæ jako po³¹cze-nie wielu wêz³ów Node B i RNC za pomoc¹ sieci IP/QoS (do-puszczalne jest jednak stosowanie sieci ATM). Brak obecniedok³adniejszych informacji na temat tego rozwi¹zania, jednakmotywacja dla jego wprowadzenia jest jasna: wszystkie urz¹dze-nia systemu UMTS powinny byæ pod³¹czone do wielous³ugowejsieci IP/QoS, co pozwoli na znaczn¹ redukcjê kosztów instalacjii utrzymania systemu UMTS.

Przedstawione (z koniecznoœci w du¿ym skrócie) rozwa¿aniazwi¹zane z obs³ug¹ ruchu IP w systemie UMTS wskazuj¹ na je-go istotn¹, o ile nie podstawow¹, rolê w tym systemie. Debatadotycz¹ca wyboru rozwi¹zania ATM lub IP przybra³a obecniecharakter „wojny religijnej”. Wydaje siê, ¿e z punktu widzeniau¿ytkownika powy¿szy dylemat nie jest specjalnie istotny,a z punktu widzenia kosztów instalacji i zarz¹dzania sieci¹oraz us³ugami ró¿nice pomiêdzy omawianymi rozwi¹zaniami nies¹ znacz¹ce. Analiza kosztowa rozwi¹zañ R99 i R5, przedsta-wiona na rysunku 6, wykazuje stosunkowo niewielkie ró¿nice po-miêdzy wymienionymi rozwi¹zaniami, natomiast narzuty nag³ów-ków w rozwi¹zaniach ATM i IP systemu UMTS dla us³ug g³oso-

364 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

OO Rys. 5. Architektura systemu UMTS R5. Oznaczenia wyjaśnionow tekście

OO Rys. 6. Analiza kosztowa rozwiązań R99 i R4/R5 [6]

Specyfikacja UMTS wersja R5 (All−IP) Specyfikacja UMTS wersja R5 to obecnie docelowa specyfika-

cja systemu UMTS. Prace nad ni¹ s¹ wci¹¿ w toku, jednakprzedstawione jej cechy nie powinny ulec zmianie. Architekturasystemu UMTS R5 to architektura systemu R4 wzbogaconao tzw. IP-based Multimedia System [16] oznaczany jako IM. Ar-chitekturê systemu przedstawiono na rys. 5.

365PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

wych i transmisji danych, pokazane na rys. 7, nie wykazuj¹ prze-wagi ¿adnego z rozwi¹zañ (w przedstawionym porównaniu niezastosowano kompresji nag³ówków IP, która jest realizowanaw systemie UMTS za pomoc¹ protoko³u PDCP).

Bezdyskusyjna dla operatora jest natomiast stabilnoœæ rozwi¹-zañ technicznych i tu odpowiedŸ nasuwa siê sama. Wbrew de-klaracjom wielu producentów, bez cienia w¹tpliwoœci mo¿nastwierdziæ, ¿e na rozwi¹zania All-IP gwarantuj¹ce QoS i pouf-noœæ, a oparte na zintegrowanych rozwi¹zaniach DiffServ/RSVPi MPLS/RSVP, jest zdecydowanie za wczeœnie (s¹ one dopierow stadium eksperymentów).

Z³o¿onoœæ systemu UMTS i w wielu przypadkach koniecznoœæjego budowy prawie „od podstaw” (from scratch) umo¿liwia ope-ratorom UMTS zbudowanie najnowoczeœniejszej infrastrukturytelekomunikacyjnej, integruj¹cej najbardziej zaawansowane kon-cepcje telekomunikacyjne i internetowe. Nie ma w¹tpliwoœci, ¿e

to oni w³aœnie bêd¹ spiritus movens rozwoju telekomunikacji XXIwieku. Wi¹¿e siê to oczywiœcie z wielkoœci¹ nak³adów, które mu-sz¹ oni ponieœæ na instalacjê systemów UMTS i z charakterysty-k¹ tego systemu. Budowana przez operatorów UMTS sieæszkieletowa CN, oparta na rozwi¹zaniach IP/QoS czy ATM, bê-dzie wielous³ugow¹ sieci¹ telekomunikacyjn¹ nowej generacji(Next Generation Network – NGN), zdoln¹ do obs³ugi ruchu nietylko abonentów UMTS, ale równie¿ abonentów sieci stacjonar-nej. Takie jej wykorzystanie zmienia rolê operatorów UMTS, alenajwa¿niejsz¹ jego konsekwencj¹ jest zmniejszenie jednostko-wego kosztu budowy i utrzymania infrastruktury UMTS. OperatorUMTS musi do³¹czyæ do sieci typu NGN jedynie kilka specyficz-nych typów urz¹dzeñ (iloœciowo bêd¹ dominowaæ urz¹dzeniaUTRAN: w modelu R99 bêd¹ to urz¹dzenia RNC, a w wersji All-IP UTRAN, dziêki po³¹czeniu Node B z RNC via IP, urz¹dzeniatypu Node B i RNC). Jest to w³aœciwie jedyna cecha odró¿niaj¹-ca go od typowego operatora sieci NGN.

W przypadku rozwi¹zañ sieci stacjonarnej upowszechnione naszerok¹ skalê modemy xDSL (ADSL, SDSL i VDSL) stan¹ siêznakomitym uzupe³nieniem systemu UMTS, umo¿liwiaj¹c trans-parentne œwiadczenie us³ug over IP, w³¹czaj¹c w to równie¿us³ugê VoDSL (Voice over DSL). Wydaje siê, ¿e operatorzy sie-ci stacjonarnej (PSTN, ISDN) nie bêd¹ mieli specjalnej motywa-cji do wdra¿ania najnowszych technik typu VS, a kosztwdro¿enia techniki xDSL w Polsce bêdzie du¿o ni¿szy, ni¿ sameop³aty koncesyjne za system UMTS.

UWAGI KOŃCOWE

Przedstawione w niniejszym artykule zastosowania protoko³uIP w systemach ³¹cznoœci ruchomej s¹ interesuj¹ce, zarównoz us³ugowego, jak i technicznego punktu widzenia. Wdro¿enietych rozwi¹zañ w systemie GSM/GPRS i UMTS bêdzie jednakzadaniem skomplikowanym i to z wielu powodów. Warto wy-mieniæ równie¿ te powody, które nie wi¹¿¹ siê bezpoœrednio z zagadnieniami technicznymi, a mog¹ stanowiæ bariery w upo-wszechnieniu siê systemu UMTS.

Popularnoœæ systemu GSM w Europie i zwi¹zane z tym zyskioperatorów takich systemów oraz ekstrapolowane przychodyz systemu UMTS spowodowa³y znaczne ceny licencji na œwiad-czenie us³ug w systemie UMTS. Rz¹dy wielu krajów potraktowa-³y sprzeda¿ pasma radiowego jako niezwykle cenne Ÿród³oprzychodów bud¿etu pañstwa (z nielicznymi wyj¹tkami, np. Fin-landia i Belgia), co doprowadzi³o do fatalnej kondycji finansowejwielu najwa¿niejszych operatorów europejskich (np. France Te−lecom czy Deutsche Telecom). Politycy wykazali dba³oœæo krótkoterminowy zastrzyk gotówki do bud¿etu, nie analizuj¹cd³ugoterminowych konsekwencji. Wysokie koszty korzystaniaz systemu UMTS mog¹ drastycznie ograniczyæ liczbê potencjal-nych jego u¿ytkowników – jest przecie¿ oczywiste, ¿e za kosztylicencji zap³ac¹ w koñcu abonenci systemu UMTS. Wydaje siê,¿e o systemie UMTS utar³a siê opinia, jako maj¹cym „posmakluksusu” i gwarantuj¹cym operatorom olbrzymie zyski. Trudnoo bardziej b³êdny pogl¹d. Z punktu widzenia pañstwa sieæ UMTSnale¿a³o bowiem potraktowaæ jako atrakcyjny element infrastruk-tury biznesowej, a z punktu widzenia integracji europejskiejwdro¿enie tego systemu powinno byæ zharmonizowane z jegowdro¿eniem w wiêkszoœci krajów Unii Europejskiej. Samo stwo-rzenie platformy us³ug dodatkowych dla sieci UMTS (w tym us³ugsieci IP) jest czynnikiem znacznie pobudzaj¹cym rynek pracyw dziedzinie high-technology oraz otwiera potencjalne mo¿liwo-œci eksportu produktów i oprogramowania.

£atanie dziury bud¿etowej, a byæ mo¿e równie¿ brak wiedzyna temat prawdziwej funkcjonalnoœci systemu UMTS i proble-mów, przed którymi stoj¹ przyszli operatorzy UMTS, doprowadzi³

OO Rys. 7. Porównanie efektywności transmisji głosu i danychw systemie UMTS dla rozwiązań ATM i IP [6]. Oznaczenia: R – RTP,U – UDP, I – IP, G – GTP, A – ATM. Pozostałe oznaczenia wyjaśnio−no w tekście

w Polsce do powstania sytuacji, któr¹ mo¿na uznaæ za zdecydo-wanie niekorzystn¹. Jest bowiem oczywiste, ¿e sama instalacjaurz¹dzeñ UMTS jest niezwykle kosztowna, a ca³e przedsiêwziê-cie jest skomplikowane i obarczone wysokim ryzykiem. Wartopodkreœliæ, ze potencja³ rynku polskiego jest nieporównaniemniejszy ni¿ krajów Europy Zachodniej. W œwietle przedstawio-nych faktów dotychczasowe stanowisko Ministerstwa £¹cznoœcimo¿e byæ interpretowane jako wynik niezrozumienia zjawisk za-chodz¹cych w telekomunikacji i dyskusyjnego wype³niania przezten urz¹d roli promotora nowoczesnych technik komunikacyj-nych pro publico bono. Na marginesie nale¿y zauwa¿yæ, ¿e UniaEuropejska dostrzeg³a post factum obecne zagro¿enia dla roz-woju systemu UMTS w Europie (w szczególnoœci konsekwen-cje wysokich op³at licencyjnych) i postanowi³a podj¹æ dzia³ania,które umo¿liwi¹ obni¿kê kosztu instalacji systemu UMTS i przy-spiesz¹ jego wdro¿enie (np. regulacje zwi¹zane ze wspó³u¿ywal-noœci¹ infrastruktury UMTS). Nale¿y mieæ nadziejê, ¿e podobnedzia³ania podjête zostan¹ równie¿ w Polsce.

Niestety, obecne zachowania przysz³ych polskich operatorówsieci UMTS (de facto istniej¹cych obecnie operatorów sieciGSM) równie¿ œwiadcz¹ o braku zrozumienia i zaakceptowanianowej sytuacji, któr¹ wytworzy³o pojawienie siê systemu UMTS.Do tej pory operatorzy ci instalowali urz¹dzenia GSM w trybie „odpodstaw” (greenfield), licz¹c na ich wieloletni¹ eksploatacjêi amortyzacjê. Obecnie maj¹ infrastrukturê GSM, któr¹ wobectempa rozwoju technik informacyjnych nale¿y uznaæ za „przesta-rza³¹” – technika ta powsta³a w 1992 roku i wykorzystuje nieefek-tywn¹ komutacjê kana³ów. Po raz pierwszy operatorzy stanêliprzed problemem „moralnego zu¿ycia siê” zainstalowanegosprzêtu i podjêcia radykalnych dzia³añ typu upgrade. Paradok-salnie „moralne zu¿ycie” terminali GSM zosta³o przez operato-rów i u¿ytkowników zaakceptowane bardzo ³atwo – ten samproces obejmuje równie¿ urz¹dzenia sieciowe! Stanowisko ope-ratorów œwiadczy, ¿e nie rozumiej¹ oni skoku technicznego orazwszystkich korzyœci, które niesie ze sob¹ system UMTS, maj¹ograniczone mo¿liwoœci finansowe i raczej pesymistycznie oce-niaj¹ potencja³ polskiego rynku zaawansowanych us³ug sieci ru-chomej. Rozwijaj¹c system GSM bêd¹ w dalszym ci¹gu inwe-stowaæ w technikê „przestarza³¹” i bez przysz³oœci – ograniczonemo¿liwoœci jej modernizacji wyraŸnie wykazuje omówiony casusGPRS. Tego typu podejœcie jest rozwi¹zaniem prowadz¹cymdonik¹d – któregoœ dnia i tak trzeba bêdzie „wy³¹czyæ” systemGSM. Fundamentalne ró¿nice pomiêdzy tym systemem i syste-mem UMTS powoduj¹ bowiem, ¿e proponowana przez produ-centów sprzêtu telekomunikacyjnego tzw. „ewolucyjna œcie¿karozwoju” systemu GSM do systemu UMTS (równie¿ via GPRS)jest ma³o realistyczna. Wdra¿anie stosunkowo nieskomplikowa-nego systemu, jakim jest GPRS, znacznie siê opóŸni³o i jegoprzysz³oœæ nie rysuje siê w zbyt ró¿owych barwach. Wydaje siê,¿e po okresie olbrzymiego i bezdyskusyjnego sukcesu rynkowe-go systemu GSM operatorzy komórkowi bêd¹ musieli dokony-waæ staranniejszych analiz i podejmowaæ bardziej przemyœlanedzia³ania, bowiem operatorzy systemu UMTS bêd¹ ró¿niæ siêmiêdzy sob¹ ju¿ nie tylko „tabelk¹ taryfikacyjn¹”, jak w przypad-ku systemu GSM, ale wieloma aspektami us³ugowymi, opartymi

na doborze odpowiednich rozwi¹zañ technicznych. Wielu obser-watorów podkreœla, ¿e w sektorze telekomunikacyjnym (a zatemw sektorze wysokich technik) nadmiern¹ rolê odgrywaj¹ obecniepiony finansowe i marketingowe kosztem pionu technicznego.Wyzwania techniczne, jakie niesie instalacja systemu UMTS, wy-magaj¹ nadania nie tylko w³aœciwej rangi pracownikom pionutechnicznego operatora, ale równie¿ podniesienia poziomu ichkwalifikacji (dotyczy to g³ównie wiedzy z zakresu rozwi¹zañIP/ATM).

Nie ulega najmniejszej w¹tpliwoœci, ¿e instalacje systemówUMTS s¹ wielkim prze³omem w telekomunikacji, o wiele wiêk-szym ni¿ instalacje systemów GSM, a ich wdro¿enie bêdzie pro-cesem nie tylko kosztownym, ale i trudnym. Instalacja systemówUMTS, ze wzglêdu na wymienione w artykule uwarunkowania,jest dla ich przysz³ych operatorów wypraw¹ w nieznane (maidenvoyage). Ze wzglêdu na olbrzymi potencja³ us³ugowy systemuUMTS i jego rolê cywilizacyjn¹, nale¿y im ¿yczyæ jak najwiêcejsukcesów (oczywiœcie w interesie klientów!).

LITERATURA

[1] White Paper: Yes 2 GPRS, z serwera www.gsmworld.com[2] 3G Mobile, Volume 3, Number 3, February 7, 2001, Baskerville Com-

munications[3] Scrase A.: 3GPP and ongoing GSM standardization, The 3GSM

World Congress, 20-23 February 2001, Cannes[4] Bettstetter Ch., Vogel H. J., Eberspracher J.: GSM Phase 2+ – Ge-

neral Packet Radio Service GPRS: Architecture, Protocols, and AirInterface , IEEEE Communications Surveys, Third Quarter 1999, vol. 2, No 3

[5] Righenzi de Villers F. (France Telecom Mobiles): QoS lessons fromthe early GPRS implementations, The 3GSM World Congress, 20-23February 2001, Cannes

[6] Wilton A. (Motorola), The Benefits of All-IP Networks, The 3GSMWorld Congress, 20-23 February 2001, Cannes

[7] Jones D. (Motorola), Booth D. (BT Wireless): GPRS Launches, The3GSM World Congress, 20-23 February 2001, Cannes

[8] Tournassoud P. (Alcatel), Lages A. (TMN): Field Study: TMN GPRSCommercial Network, The 3GSM World Congress, 20-23 February2001, Cannes

[9] Donahue J., (BT Cellnet), Lisle P. (BT Cellnet): GPRS Network Infra-structure Dimensioning and Performance, www. gsmworld. com

[10] Baudet S., Freþne P.: Rozwi¹zania GPRS firmy Alcatel, Przegl¹d Te-lekomunikacyjny i Wiadomoœci Telekomunikacyjne, nr 5, 2000

[11] Jajszczyk A.: Telekomunikacja ruchoma w pierwszych latach XXIwieku, Przegl¹d Telekomunikacyjny i Wiadomoœci Telekomunikacyj-ne, nr 5, 2000

[12] Ziêcina K.: Rozwi¹zania Lucent Technologies dla ³¹cznoœci ruchomejnastêpnych generacji, Przegl¹d Telekomunikacyjny i WiadomoœciTelekomunikacyjne, nr 5, 2000

[13] Zalecenia ETSI: GSM 02.60, GSM 03.60, www. etsi. org. [14] Lisle P. et al.: Generally poor reception speeds disprove GPRS myth,

3G Mobile, Volume 3, Number 2, January 2001, Baskerville Commu-nication

[15] Zalecenia organizacji 3GPP: TS 23.002 v3.0.0, TS 23.002 v4.0.0, TS23.002 v5.0.0, TS 22.105 v3.10.0, www. 3gpp. org

Artykuł recenzowany

366 PRZEGLĄD TELEKOMUNIKACYJNY !! ROCZNIK LXXIV !! nr 5–6/2001

Zapraszamy na nasz¹ stronê internetow¹

www.ptiwtel.com.plWiêcej informacji na stronie 431