Marek ŒREDNIAWA* Przyszłość sieci inteligentnych Koncepcja klasycznej sieci inteligentnej (Intelligent Network IN), pochodz¹ca z pierwszej po³owy lat osiemdziesi¹tych 1), by³a udanym pomys³em rozwi¹zania problemu szybkiego wprowadzania do publicznej sieci telefonicznej nowych us³ug o elastycznych scenariuszach dzia³ania (takich jak np. po³¹czenie bezp³atne (Freephone) i kredytowane oraz inne us³ugi translacji numeru, takie jak VPN (Virtual Private Network). Podejœcie tradycyjne, polegaj¹ce na wprowadzeniu rozproszonej implementacji us³ug w oprogramowaniu central koñcowych, okaza³o siê niepraktyczne ze wzglêdu na ograniczenia wynikaj¹ce z koniecznoœci zapewnienia ci¹g³oœci œwiadczenia us³ug, czasoch³onnoœci operacji, wysokiego kosztu modernizacji oprogramowania central spowodowanego skal¹ tego przedsiêwziêcia du ¹ liczb¹ central i ich znaczn¹ ró norodnoœci¹ (ró ni dostawcy, ró ne wersje oprogramowania, konfiguracje i generacje techniczne). Sukces komercyjny us³ug IN w Stanach Zjednoczonych (przede wszystkim us³ugi 800, czyli po³¹czenia bezp³atnego) sta³ siê zachêt¹ dla innych operatorów oraz zapocz¹tkowa³ prace normalizacyjne w ITU T i ETSI. Ich wynikiem s¹ zalecenia i normy definiuj¹ce model koncepcyjny kolejnych generacji sieci IN: CS 1 (lata 1992 1994), CS 2 (lata 1997 1999), CS 3 (lata 2000 2001), CS 4 (2001?). Na rys. 1 przedstawiono drzewo genealogiczne IN, a w ramce 1 informacje o normalizacji w ITU-T i ETSI. O Ramka 1. Normalizacja IN ITU T: Zalecenia serii Q.12xy. x = 1, 2, 3 definiuj¹ odpowiednio kolejne generacje sieci inteligentnej: IN CS-1 (1992), CS-2 (1997), CS-3 (2000) i CS-4 (2001?). ETSI: Core INAP CS-1 (1994) ETS 300 374-1 (i nastêpne); INAP CS-2 (1999) ETS 301 140-1;IN CS-3 (2000) Draft EN 301 931-1. Pierwsza generacja sieci inteligentnej IN CS-1 dotyczy us³ug telefonicznych w sieci PSTN/ISDN dla po³¹czeñ punkt- -punkt. Druga generacja IN CS-2 uwzglêdnia dostêp bezprzewodowy (CTM Cordless Terminal Mobility) realizowany za pomoc¹ techniki DECT (Digital Enhanced Cordless Telecommunications), po³¹czenia wielostronne i wspó³pracê sieci IN nale ¹cych do ró nych operatorów. Trzecia generacja IN CS-3, której normalizacja jest w toku uwzglêdnia us³ugi multimedialne, realizacje idei VHE (Virtual Home Environment), zastosowanie w sieciach GSM oraz wspó³pracê z sieciami nie-in, w tym z sieciami IP i Internetem. Czwarta generacja IN CS-4, która jest na etapie prac studialnych definiuje zasady wspó³pracy miêdzy sieci¹ IN a sieci¹ IP nowej generacji. Rozwin¹³ siê tak e oddzielny nurt normalizacji CAMEL (Customized Applications for Mobile network Enhanced Logic), zwi¹zany z zastosowaniem koncepcji IN w sieciach GSM. * Instytut Telekomunikacji Politechniki Warszawskiej, e mail: mareks@tele.pw.edu.pl 1) Termin Intelligent Network, w odniesieniu do koncepcji scentralizowanej realizacji us³ug telefonicznych o elastycznych scenariuszach zosta³ wprowadzony w 1984 roku przez firmê Bellcore 2) W odniesieniu do zastosowañ tego typu u ywa siê terminu FMC (Fixed- Mobile Convergence). PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001 O Rys. 1. Drzewo genealogiczne sieci IN. Oznaczenia wyjaśniono w tekście Prace dotycz¹ce rozwoju sieci IN s¹ tak e prowadzone przez inne instytucje: IETF, Eurescom, IN Forum, Parlay, OMG, TINA C oraz w ramach projektów miêdzynarodowych finansowanych przez Komisjê Wspólnot Europejskich (CEC). Obecnie wiêkszoœæ operatorów œwiadczy us³ugi generacji IN CS-1. Wœród nich jest równie Telekomunikacja Polska S.A., która udostêpni³a nastêpuj¹ce us³ugi: M po³¹czenie bezp³atne FPH ( 0-800 linia bezp³atna), M po³¹czenie z podzia³em op³aty SPL ( 0-801 linia ulgowa), M uniwersalny numer dostêpowy UAN ( 0-804 linia firmowa), M teleg³osowanie VOT ( 0-707 ), M wirtualna sieæ wydzielona VPN ( 0-806 wkrótce). Niektórzy operatorzy wykorzystuj¹ platformê IN do wzbogacenia us³ug sieci GSM, a tak e do realizacji us³ug obejmuj¹cych sieæ stacjonarn¹ i ruchom¹ 2), np. VPN, numer osobisty, wspóln¹ pocztê g³osow¹, op³acany z góry wspólny dostêp do us³ug (karta prepaid na sieæ mobiln¹ i stacjonarn¹). Infrastruktura sieci IN jest równie postrzegana jako docelowe œrodowisko realizacji obligatoryjnych us³ug zachowywania numerów lokalnych LNP (Local Number Portability) i numerów us³ug SNP (Service Number Portability) przy zmianie operatora. Takie czynniki, jak rozwój Internetu i us³ug multimedialnych, postêp w dziedzinach: techniki œwiat³owodowej, szybkich sieci teleinformatycznych i komunikacji bezprzewodowej, sprawi³y, e nale y obecnie zweryfikowaæ przydatnoœæ koncepcji sieci inteligentnej, a tak e rozwa yæ jej potencjalne miejsce w nowych okolicznoœciach. W artykule podjêto próbê przewidywania dróg rozwoju przysz³oœciowej sieci IN oraz okreœlenia jej roli w ewolucji sieci telekomunikacyjnych. Podstaw¹ do tych przewidywañ jest klasyczna koncepcja i architektura sieci IN. W rozwa aniach dotycz¹cych przysz³oœci IN wziêto pod uwagê nastêpuj¹ce zagadnienia: 41
M wspó³dzia³anie sieci IN i Internetu w realizacji hybrydowych us³ug wykorzystuj¹cych mo liwoœci obu sieci, M realizacjê us³ug IN w œrodowisku sieci IP, M rolê IN w sieciach nowej generacji, M wykorzystanie us³ug IN w sieciach mobilnych, M ewolucjê normalizacji IN, M nowe techniki implementacji architektury, funkcjonalnoœci i us³ug IN. Ich zakres wi¹ e siê z g³ównymi tendencjami rozwoju us³ug telekomunikacyjnych, z których najwa niejsze to: M dostosowywanie scenariuszy i profili us³ug do indywidualnych wymagañ abonentów, M obs³uga mobilnoœci terminali, u ytkowników i us³ug, M integracja ró nych mediów, M wzrost inteligencji sieci i jej decentralizacja, M konwergencja sieci stacjonarnych i ruchomych FMC. Nale y podkreœliæ, e koncepcja IN mo e znaleÿæ zastosowanie w odniesieniu do ka dego z wymienionych kierunków rozwoju. SIEĆ INTELIGENTNA PODSTAWOWE FAKTY Termin inteligencja ma wiele znaczeñ. W kontekœcie technicznym inteligencja 3) jest zwykle postrzegana jako proaktywne zachowanie systemu, charakteryzuj¹ce siê elastycznoœci¹ dzia- ³ania zgodn¹ z oczekiwaniami u ytkownika i uwzglêdniaj¹ce towarzysz¹ce okolicznoœci. Tak w³aœnie rozumiana inteligencja, w tej lub innej formie, by³a zawsze obecna w historii us³ug teledobrych czasów elastycznego i personalnego trybu obs³ugi po- ³¹czeñ telefonicznych umo liwi³o, w pewnym zakresie, rozwi¹zanie techniczne nazywane sieci¹ inteligentn¹, w skrócie: IN. Termin sieæ inteligentna okreœla znormalizowan¹ koncepcjê uniwersalnej architektury sieciowej sposób rozbudowy podstawowej infrastruktury publicznej sieci telefonicznej, który umo liwia szybkie wprowadzanie nowych us³ug telekomunikacyjnych charakteryzuj¹cych siê elastycznymi scenariuszami, dostosowanymi do indywidualnych wymagañ abonentów. IN zapewnia realizacjê scenariuszy us³ug uwzglêdniaj¹cych kontekst po³¹czenia i zdarzenia w nim zachodz¹ce: np. identyfikacjê i lokalizacjê geograficzn¹ abonenta wywo³uj¹cego, porê dnia, dzieñ tygodnia, informacje przekazane przez abonenta podczas wstêpnej interakcji, preferencje abonenta dotycz¹ce po³¹czeñ przychodz¹cych sygna³ów zajêtoœci lub braku odpowiedzi. Istota dzia³ania IN polega na oddzieleniu funkcji sterowania us³ugami (SCF) od funkcji komutacyjnych (CCF/SSF). Us³ugi IN maj¹ charakter otwarty. Ich scenariusze projektuje siê jako aplikacje wykorzystuj¹ce biblioteki uniwersalnych modu³ów us³ugowych SIB (Service Independent building Blocks) za pomoc¹ wspomagaj¹cego œrodowiska programistycznego SCE (Service Creation Environment). Operatorzy i us³ugodawcy maj¹ dziêki temu mo liwoœæ samodzielnego projektowania i implementacji nowych us³ug. Normalizacja sieci IN obejmuje: M model koncepcyjny sieci IN INCM, M listê us³ug i funkcji us³ugowych, M listê uniwersalnych modu³ów us³ugowych SIB i zasady konstruowania z nich scenariuszy us³ug, O Rys. 2. INCM model koncepcyjny sieci IN. Oznaczenia wyjaśniono w tekście komunikacyjnych. W pocz¹tkowym okresie rozwoju telefonii by³a ona przede wszystkim realizowana osobiœcie przez personel central, który dba³ o w³aœciwy sposób obs³ugi abonentów bior¹c pod uwagê ich indywidualne preferencje. Powrót do dawnych 3) Takiemu w³aœnie rozumieniu inteligencji odpowiada jedna z encyklopedycznych definicji, która okreœla j¹ jako: zdolnoœæ rozumienia otaczaj¹cych sytuacji i znajdowania na nie w³aœciwych, celowych reakcji. M definicjê architektury funkcjonalnej i fizycznej sieci, M definicjê elementów architektury wraz z definicj¹ procesów i procedur charakteryzuj¹cych ich dzia³anie oraz protoko³ów i interfejsów Architektura IN jest okreœlona za pomoc¹ tzw. modelu koncepcyjnego sieci inteligentnej INCM (Intelligent Network Conceptual Model), który definiuje cztery p³aszczyzny (poziomy abstrakcji), reprezentuj¹ce ró ne perspektywy i poziomy szczegó³owo- 42 PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001
œci opisu IN (rys.2). Dla tak przyjêtego modelu okreœlono zasady odwzorowania p³aszczyzn wy szego poziomu na p³aszczyznê poziomu bezpoœrednio ni szego, które mo na traktowaæ jak hierarchiê (wogólnoœci rozproszonych) maszyn wirtualnych IN. Na rys. 3 przedstawiono typow¹ konfiguracjê sieci IN ilustruj¹c¹ odwzorowanie architektury funkcjonalnej w architekturê fizyczn¹. O Rys. 3. Typowa konfiguracjia sieci IN. Oznaczenia wyjaśniono w tekście Szczególnie istotne dla uniwersalnoœci koncepcji IN by³o wyró nienie wmodelu INCM: globalnej p³aszczyzny funkcjonalnej GFP (Global Functional Plane), rozproszonej p³aszczyzny funkcjonalnej DFP (Distributed Functional Plane) i p³aszczyzny fizycznej PP (Physical Plane), które odpowiednio reprezentuj¹: perspektywê projektanta us³ug GSL (Global Service Logic) (scenariusze us³ug budowane z modu³ów SIB za pomoc¹ œrodowiska SCE), architekturê funkcjonaln¹ i architekturê fizyczn¹ sieci inteligentnej. Wyró nienie architektury funkcjonalnej DFP i oddzielenie jej od architektury fizycznej stwarza swobodê wielowariantowej implementacji sieci IN. Opisane podejœcie wdu ym stopniu uniezale ni³o proces projektowania us³ug od architektury fizycznej sieci, a tak e umo liwi³o œwiadczenie us³ug IN w ró nych œrodowiskach sieci podstawowych (PSTN, ISDN, GSM, IP, B-ISDN). Dziêki opisanym w³asnoœciom idea sieci IN, opracowana pocz¹tkowo dla sieci stacjonarnych, znalaz³a równie zastosowanie do realizacji us³ug elastycznych zaawansowanych dla abonentów sieci GSM. Wielu operatorów GSM wykorzystuje platformê IN w celu wzbogacenia funkcjonalnoœci oferowanych us³ug wzasiêgu swojego dzia³ania, a tak e ich udostêpniania wsieciach innych wspó³pracuj¹cych operatorów (podczas roamingu). Udostêpnienie niestandardowych us³ug GSM poza macierzyst¹ sieci¹ wymaga³o zaadaptowania koncepcji IN do potrzeb sieci komórkowych. W tym celu ETSI opracowa³ zestaw norm CA- MEL, który opisuje zasady realizacji takich us³ug. Interfejs miêdzy sieci¹ telefoniczn¹ a platform¹ IN jest obs³ugiwany przez protoko³y warstwy aplikacyjnej systemu sygnali- zacji SS7 INAP i TCAP. W zwi¹zku z tym us³ugi IN mo na traktowaæ jako aplikacje (definiuj¹ce scenariusze poszczególnych us³ug) dzia³aj¹ce na serwerach IN wêz³ach SCP (Service Control Point), które wspó³pracuj¹ z procesami obs³ugi po³¹czeñ wcentralach telefonicznych SSP (Service Switching Point) za pomoc¹ protoko³u INAP (Intelligent Network Application Part). Zasadnicze znaczenie dla noœnoœci koncepcji IN ma przyjêcie znormalizowanego modelu podstawowego procesu obs³ugi po- ³¹czenia BCP (Basic Call Process). W znormalizowanych procesach obs³ugi po³¹czeñ wssp s¹ zdefiniowane stany i zwi¹zane z nimi kryteria, które umo liwiaj¹ zawieszenie procesu obs³ugi po³¹czenia i przekazanie sterowania (wraz z informacj¹ o zdarzeniach) za pomoc¹ w³aœciwej operacji protoko³u INAP do scenariusza us³ugi wscp, wœciœle okreœlonych sytuacjach (POI Point of Initiation). Opracowane, w wyniku interpretacji scenariusza us³ugi (z uwzglêdnieniem typu zdarzenia i kontekstu po³¹czenia), decyzje dotycz¹ce dalszego przebiegu po³¹czenia (np. wskazanie numeru katalogowego, z którym nale y zestawiæ po- ³¹czenie, interakcja z u ytkownikiem) s¹ przekazywane z SCP do SSP. Powrót sterowania do SSP i wznowienie procesu BCP mo e równie nast¹piæ tylko w jednym z miejsc POR (Point of Return) okreœlonych wnormie. P³aszczyzna DFP definiuje elementy sk³adowe architektury funkcjonalnej sieci IN (SCF, SSF, CCF, CCAF, SRF, SDF, SMF, SMAF) patrz ramka 2. O Ramka 2. Jednostki funkcjonalne DFP SSF (Service Switching Function) odpowiada za rozpoznawanie po- ³¹czeñ odwo³uj¹cych siê do us³ug IN i wspó³pracê z SCF i CCF przy realizacji scenariusza us³ugi. CCF (Call Control Function) zapewnia podstawow¹ funkcjonalnoœæ obs³ugi po³¹czeñ (w³aœciw¹ dla tradycyjnej centrali telefonicznej). Funkcje CCF opisuje proces BCSM. ¹cznie CCAF i CCF reprezentuj¹ sk³adniki istniej¹cej sieci PSTN/ISDN. CCAF (Call Control Agent Function) zapewnia dostêp u ytkowników do sieci IN (funkcje terminalu). SRF (Specialized Resources Function) wspomaga SSF przy realizacji scenariuszy us³ug (interakcja z abonentem zapowiedzi s³owne, rejestracja decyzji abonentów, rozpoznawanie mowy itp.). SCF (Service Control Function). steruje obs³ug¹ po³¹czeñ zgodnie z przechowanymi scenariuszami us³ug, a tak e steruje dzia³aniem SSF i SRF oraz wspó³pracuje z SDF (pobieranie danych do scenariuszy us³ug) i SMF. SDF (Service Data Function) zapewnia dostêp do danych us³ugi i maskuje ich fizyczne rozproszenie. SCEF (Service Creation Environment Function) reprezentuje œrodowisko wspomagaj¹ce definiowanie, projektowanie, testowanie oraz wprowadzanie nowych us³ug IN do SCF za poœrednictwem SMF. SMF (Service Management Function) reprezentuje funkcjonalnoœæ zarz¹dzania us³ugami IN. SMAF (Service Management Access Function) zapewnia zdalny dostêp u ytkownika SMF. IAF (Intelligent Network Access Function) zapewnia wspó³pracê z systemami spoza œwiata IN. O Rys. 4. Mechanizm działania sieci IN interakcja logiki usługi zlo kalizowanej w SCF z procesami O_BCSM i T_BCSM PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001 Na poziomie p³aszczyzny DFP podstawowy proces obs³ugi po³¹czenia BCSM (Basic Call State Model) jest reprezentowany przez dwie jego po³ówki jako O_BCSM i T_BCSM (Originating i Terminating). Reprezentuj¹ one procesy po³¹czenia wychodz¹cego i przychodz¹cego. Ka dy proces BCSM jest zdefiniowany przez zbiór stanów PIC (Point In Call), czyli miejsc wprocesie i DP punktów detekcji (Detection Point) oraz zbiór przejœæ. Napotkanie aktywnego punktu detekcji DP powoduje zawieszenie procesu BCSM i przekazanie sterowania z CCF/SSF do scenariusza us³ugi w SCF. Po powrocie sterowania do BCSM proces ten jest wznawiany w stanie wskazanym przez scenariusz us³ugi (rys. 4). 43
EWOLUCJA SIECI IN Generacja IN CS-2 Druga generacja sieci inteligentnej IN CS-2, dziedzicz¹c w pe³ni w³aœciwoœci IN CS-1, wprowadza rozszerzenia zwiêkszaj¹ce mo liwoœci us³ugowe. Do najwa niejszych z nich nale ¹: M obs³uga po³¹czeñ wielostronnych z mechanizmami sterowania stronami po³¹czenia CPH (Call Party Handling), M interakcja z us³ugami nie zwi¹zana z bie ¹cym kontekstem po³¹czenia (wykorzystanie funkcjonalnoœci ISDN DSS1), M uwzglêdnienie wymagañ dostêpu bezprzewodowego obs³uga CTM (Cordless Terminal Mobility), M UPT i integracja z UMTS (Universal Mobile Telecommunication System) (elementy obs³ugi mobilnoœci abonenta i terminalu), M mechanizmy wspó³dzia³ania sieci IN nale ¹cych do ró nych operatorów (komunikacja w relacjach: SCF-SCF i SDF-SDF), co umo liwia realizacjê us³ug IN o zasiêgu obejmuj¹cym sieci wspó³pracuj¹cych operatorów (np. miêdzynarodowej us³ugi po³¹czenia bezp³atnego), M realizacja skryptów SRF. Normalizacja IN CS-2 opiera siê na podstawowym modelu koncepcyjnym INCM. W zwi¹zku z tym rozszerzenia odnosz¹ siê do poszczególnych jego elementów. Wzbogacenie mo liwoœci us³ugowych reprezentowanych przez zmiany na p³aszczyÿnie us³ugowej (SP Service Plane) poci¹gnê³o za sob¹ koniecznoœæ modyfikacji pozosta³ych p³aszczyzn modelu INCM. Na poziomie globalnej p³aszczyzny funkcjonalnej (GFP) zdefiniowano nowe uniwersalne modu³y us³ugowe SIB i rozbudowano proces BCP. W konsekwencji na poziomie rozproszonej p³aszczyzny funkcjonalnej (DFP) konieczna by³a modyfikacja modeli O_BCSM i T_BCSM polegaj¹ca na dodaniu nowych stanów i przejœæ. Ponadto wprowadzono nowe jednostki funkcjonalne CUSF (Call Unrelated Service Function) i SCUAF (Service Control User Agent Function) reprezentuj¹ce pomocnicze funkcje sterowania realizowane poza kontekstem po³¹czenia. Zapewnienie komunikacji dla nowych jednostek funkcjonalnych wymaga³o z kolei zdefiniowania nowych strumieni przep³ywu informacji IF (Information Flow) i realizuj¹cych je operacji protoko³u INAP 4). Poniewa p³aszczyzna DFP reprezentuje jedynie architekturê funkcjonaln¹ sieci IN, to konieczne by³o tak e okreœlenie sposobów odwzorowania p³aszczyzny DFP na p³aszczyznê fizyczn¹. Znajduje to bezpoœrednie odzwierciedlenie w zalecanych wariantach implementacji sieci IN. Us³ugi oraz funkcje us³ugowe IN CS-2 stanowi¹ rozwiniêcie normalizacji przyjêtej w IN CS-1. W odró nieniu jednak od CS-1, które szczegó³owo opisuje konkretne us³ugi, w CS-2 zdefiniowano tylko tzw. kategorie grupy us³ug. S¹ to us³ugi dla abonentów ruchomych (mobility services), np. us³uga uniwersalnej ³¹cznoœci osobistej UPT (Universal Personal Telecommunications) i obs³uga bezprzewodowych aparatów koñcowych CTM oraz us³ugi systemu GSM trzeciej generacji UMTS. Generacja IN CS-3 Trzecia generacja sieci inteligentnej IN CS-3 dziedziczy w³aœciwoœci drugiej generacji IN CS-2. W zwi¹zku z rozwojem sieci IP i us³ug telekomunikacyjnych w œrodowisku sieci pakietowych architektura funkcjonalna typu IN CS-2 zosta³a rozszerzona 4) Dodano np. operacje przeznaczone do sterowania stronami po³¹czenia: CreateCallSegmentAssociation, MoveCallSegments, MergeCallSegments, SplitLeg, MoveLeg, DisconnectLeg o mechanizmy wspó³dzia³ania z sieciami nie-in, g³ównie z myœl¹ o Internecie i sieciach IP. Prace normalizacyjne ETSI i ITU-T od pewnego czasu s¹ prowadzone wspólnie z IETF, co wp³ywa korzystnie na zasiêg akceptacji opracowywanych dokumentów. Obecnie generacja IN CS-3 ma status roboczej wersji normy Draft EN 301 931-1 (wersja 1.1.1 z sierpnia 2000). W wersji IN CS-3 uzupe³niono architekturê funkcjonaln¹ DFP o jednostkê IAF (Intelligent Access Function), która reprezentuje funkcje wspó³pracy platformy IN z aplikacjami sieci nie-in (relacja SCF-IAF), np. z serwerami PINT i SPIRITS (patrz dalej). Przewidziano tak e mo liwoœæ wspó³pracy systemów zarz¹dzania nale ¹cych do ró nych operatorów (relacja SMF-SMF). Na rys. 5 przedstawiono architekturê funkcjonaln¹ typu IN CS-2/3. O Rys. 5. Architektura funkcjonalna sieci IN: CS 2 i CS 3. Oznacze nia wyjaśniono w tekście Z us³ugowego punktu widzenia do najwa niejszych rozszerzeñ wprowadzonych w IN CS-3 nale ¹: M mechanizmy wspó³pracy IN IP, M obs³uga protoko³ów PINT/SIP/H.323 w SSF, M obs³uga wielu punktów sterowania, M mechanizmy obs³ugi niepo ¹danej interferencji funkcji us³ugowych, M zaawansowane metody naliczania op³at, M w³¹czenie do normy specyfikacji Fazy 3 CAMEL, M obs³uga interfejsu Parlay API, M specyfikacja zasad dostêpu dla us³ugodawców, M minimalny podzbiór INAP dla stron trzecich, M zasady realizacji przenoœnoœci numerów (LNP/SNP), M ograniczone mo liwoœci B-ISDN dla po³¹czeñ punkt-punkt. Sieci IN i sieci mobilne CAMEL Uniwersalnoœæ koncepcji IN od razu zosta³a zauwa ona przez œrodowisko GSM. Sta³o siê tak miêdzy innymi dlatego, e sieæ GSM ma strukturê, która odpowiada w du ym stopniu architekturze sieci IN. Pocz¹tkowo koncepcja IN by³a wykorzystywana do wzbogacania oferty us³ugowej sieci GSM, a tak e do integracji us³ugowej sieci mobilnych i stacjonarnych. PóŸniej podjêto prace normalizacyjne, których celem by³o zaadaptowanie modelu IN do realizacji idei dostêpu do niestandardowych us³ug GSM sieci macierzystej podczas roamingu. Ich wynikiem by³a koncepcja CAMEL, której rozwój przebiega³ równolegle z IN. Zosta³ zdefiniowany protokó³ CAP (CAMEL Application Part) jako podzbiór INAP z dodatkowymi parametrami operacji (specyficznymi dla potrzeb sieci GSM) i zasady wspó³pracy 44 PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001
CSE (CAMEL Service Environment), czyli gsmscp z wêz³ami sieci GSM (HLR, VLR, MSC rozszerzony o funkcje SSF i pe³ni¹cy rolê gsmssp). Architekturê CAMEL przedstawiono na rys. 6. Wersje rozwi¹zania CAMEL by³y zwi¹zane z kolejnymi generacjami IN. Obecnie specyfikacja Fazy 3 CAMEL zosta³a w³¹czona do IN CS-3. ci¹ IP opiera siê przede wszystkim na wykorzystaniu mechanizmów protoko³u SIP. Zidentyfikowano m.in. nastêpuj¹ce obszary studiów dotycz¹cych wspó³dzia³ania sieci IN, IP i Internetu. M Sterowanie us³ugami PSTN/IN za pomoc¹ Internetu PINT (PSTN/Internet Interworking). M Przekazywanie informacji o zdarzeniach w PSTN/IN do Inter- O Rys. 6. Architektura CAMEL. Oznaczenia wyjaśniono w tekście Do najwa niejszych elementów funkcjonalnoœci us³ugowej CAMEL nale ¹: M realizacja idei VHE (w ograniczonym stopniu), M naliczanie op³at na bie ¹co, M transport informacji o aktualnej lokalizacji u ytkownika, M mo liwoœæ samodzielnego aktywowania dodatkowych us³ug GSM przez u ytkownika, M kontrola czasu trwania po³¹czeñ, M wprowadzenie dodatkowych punktów detekcji (GPRS DP i SMS DP), M zarz¹dzanie mobilnoœci¹, M zarz¹dzanie stronami po³¹czenia. SIECI IN, IP I INTERNET Ewolucja tradycyjnych sieci telekomunikacyjnych w kierunku uniwersalnych wielous³ugowych sieci pakietowych IP wi¹ e siê z radykalnymi zmianami architektury sieci i funkcjonalnoœci us³ug telekomunikacyjnych. Ich realizacja wymaga³a opracowania nowej koncepcji architektury sieci dostosowanej do wymagañ techniki komutacji IP i umo liwiaj¹cej wspó³pracê z istniej¹cymi klasycznymi sieciami telekomunikacyjnymi PSTN/ISDN/IN i GSM. Tworz¹ j¹ nowe typy wêz³ów sieci (np. rutery, bramy dla mediów i sygnalizacji, ró nego rodzaju serwery) i nowe protoko³y. Zakres ich funkcji obejmuje sterowanie (w szerokim sensie) po³¹czeniami i transportem sygna³ów z zachowaniem wymagañ jakoœciowych (QoS Quality of Service). W odniesieniu do telefonii IP g³ówne znaczenie maj¹ dwa rozwi¹zania: rodzina protoko³ów (Zalecenia H.323 wraz z H.245, H.225 i H.450) [7] opracowana przez ITU-T i protokó³ SIP (Session Initiation Protocol) zdefiniowany przez grupê robocz¹ IETF MMUSIC (Multiparty Multimedia Session Control) jako RFC 2543 [3]. Oba protoko³y maj¹ zbli on¹ funkcjonalnoœæ i wykorzystuj¹ te same protoko³y RTP, RTCP, RSVP, UDP i TCP do transportu mediów. Ró ni¹ siê one natomiast podejœciem do projektowania i realizacji us³ug oraz wizj¹ architektury sieci. Zalecenie H.323 wywodzi siê z klasycznego nurtu telekomunikacyjnego (przeniesienie standardu wideokonferencji ISDN H.320 w œrodowisko sieci pakietowych LAN/WAN). Natomiast SIP reprezentuje filozofiê internetow¹. Realizacja wspó³dzia³ania PSTN/IN z sie- PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001 netu SPIRITS (Services in the PSTN/ IN Requesting Internet Services). M Wykorzystanie istniej¹cych scenariuszy us³ug IN i przeniesienie ich implementacji w œrodowisko IP. M Dostêp do us³ug IN z sieci IP. M Przeniesienie protoko³ów aplikacyjnych INAP/TCAP w œrodowisko IP. M Odwzorowanie modelu procesu po³¹czenia IN BCSM w model po³¹czenia SIP/H.323. Koncepcje PINT i SPIRITS uzupe³niaj¹ siê wzajemnie. PINT dotyczy wykorzystania Internetu do sterowania us³ugami PSTN/IN, a SPIRITS opisuje sposób udostêpniania funkcjonalnoœci Internetu w zwi¹zku z przekazywan¹ informacj¹ o statusie realizacji us³ug w PSTN/IN. Protokó³ SIP SIP jest protoko³em tekstowym warstwy aplikacji, typu klientserwer, przeznaczonym do inicjowania, ustanawiania, modyfikacji i koñczenia interaktywnych multimedialnych sesji komunikacyjnych dla dwóch lub wiêcej uczestników. Sesj¹ mo e byæ np. wideokonferencja, telefonia internetowa (komunikacja g³osowa z wykorzystaniem techniki VoIP), wspólne nawigowanie po Internecie/intranecie. W sesji mog¹ uczestniczyæ zarówno u ytkownicy, jak i aplikacje. W trakcie sesji mo na do³¹czaæ kolejnych uczestników oraz zmieniaæ wykorzystywane media. Protokó³ SIP mo e byæ wykorzystany do inicjowania sesji, a tak e do zapraszania uczestników do sesji ju istniej¹cych, które zosta³y wczeœniej rozg³oszone i ustanowione innymi œrodkami (np. za pomoc¹ protoko³u SAP Service Advertisement Protocol wykorzystuj¹cego mechanizm multicast). Do opisu mediów u ywanych podczas sesji jest stosowany protokó³ SDP (Session Description Protocol). Protokó³ SIP w przezroczysty sposób realizuje funkcje odwzorowywania adresów i przekierowywania, co umo liwia implementacjê w sieciach pakietowych IP us³ug znanych z ISDN i sieci IN, w tym pewnych aspektów mobilnoœci u ytkownika, a tak e nowych us³ug integruj¹cych funkcjonalnoœæ PSTN/IN, sieci IP i Internetu. Rodowód protoko³u SIP sprawia, e dziedziczy on wiele mechanizmów i cech protoko³ów internetowych i mo na go uwa aæ 45
za rozwiniêcie protoko³u HTTP (np. sk³adnia i tekstowa forma SIP bardzo przypomina HTTP). Podobnie jak w HTTP, wiadomoœci SIP, nazywane metodami, przekazuj¹ dane wykorzystuj¹c mechanizm MIME. Identyfikatory SIP URL, s³u ¹ce do adresacji u ytkowników, s¹ w formie zbli one do adresów w poczcie elektronicznej (user@host) i mog¹ pe³niæ rolê odsy³aczy umieszczanych na stronach WWW lub innych hiper³¹czach i informowaæ, e u ytkownik jest dostêpny przez SIP. Wa n¹ cech¹ SIP jest niezale noœæ od wykorzystywanego protoko³u transportowego. Koncepcja SIP URL uwzglêdnia tak e mo liwoœæ u ycia numeru telefonicznego zgodnego z Zaleceniem E.164 jako prawid³owego adresu. Dziêki wspomnianym cechom protokó³ SIP mo e byæ u yty do realizacji zupe³nie nowych kategorii us³ug integruj¹cych funkcjonalnoœæ klasycznej sieci telefonicznej, Internetu i sieci IP. Adres SIP sk³ada siê z nazwy u ytkownika (lub jego numeru telefonicznego w PSTN) i nazwy wêz³a sieci (lub bramki) pe³ni¹cego rolê serwera SIP. Sk³adnia adresu SIP jest nastêpuj¹ca: SIP-URL = sip: [userinfo @ ] hostport url-parameters [headers] Adresy SIP uwzglêdniaj¹ plan numeracji E.164. W zwi¹zku z tym przyk³adowi u ytkownicy mog¹ mieæ nastêpuj¹ce adresy: sip: Jan.Kowalski@tele.pw.edu.pl sip: +4822999876@gateway.com; user=phone Odsy³acze SIP mog¹ byæ umieszczane na stronach WWW i s³u yæ jako mechanizm inicjowania po³¹czeñ telefonicznych (via adres w poczcie elektronicznej). Mo na sobie wyobraziæ, przez analogiê do us³ugi IN po³¹czenia bezp³atnego, np. us³ugê bezp³atnego URL. Przyk³adem wykorzystania protoko³u SIP jest, opisany dalej, zestaw us³ug i protokó³ PINT. Koncepcja SIP pozwala na realizacjê elastycznych us³ug komunikacji personalnej z uwzglêdnieniem po³¹czeñ wielostronnych, z mo liwoœci¹ negocjacji typu wykorzystywanych strumieni medialnych. Udostêpnia tak e mechanizmy zapewniaj¹ce: M obs³ugê mobilnoœci u ytkownika, M dystrybucjê informacji o bie ¹cym statusie dostêpnoœci u ytkowników (gotowoœæ do komunikacji i preferowany jej sposób), M realizacjê tradycyjnych teleus³ug i us³ug dodatkowych w³aœciwych dla PSTN/IN, M jednolit¹ adresacjê integruj¹c¹ plan numeracji E.164 i adresacjê IP. Dziêki otwartoœci architektury, us³ugi mog¹ byæ realizowane przez bezpoœrednie wykorzystanie funkcjonalnoœci SIP, jak równie przez do³¹czenie do sieci wspó³pracuj¹cych zewnêtrznych serwerów aplikacji. Aplikacje mog¹ byæ konstruowane na wiele sposobów, np.; M w jêzyku programowania CPL (Call Processing Language), stanowi¹cym rozszerzenie jêzyka XML (Extended Markup Language), M przez wykorzystanie API: np. Parlay lub JAIN; wykorzystanie API pozwala budowaæ i udostêpniaæ zaawansowane us³ugi wykorzystuj¹ce funkcjonalnoœæ IN niezale nym us³ugodawcom, którzy mog¹ dziêki znormalizowanemu API wykorzystaæ istniej¹ce zasoby sieciowe, M przez wykorzystanie interfejsu CGI lub aplikacji SIP zaprogramowanych w Javie (SIP servlets), M przez przekazywanie apletów (napisanych w jêzyku Java) w ¹daniach SIP. Protokó³ PINT Zalecenie IETF RFC 2848 specyfikuje protokó³ us³ugowy PINT, który s³u y do wywo³ywania wybranych us³ug telefonicznych z sieci IP. Nale ¹ do nich: inicjowanie po³¹czeñ telefonicznych, wysy³anie i odbieranie wiadomoœci telefaksowych i odbieranie treœci internetowych przez telefon. Protokó³ zosta³ zdefiniowany jako zbiór rozszerzeñ protoko³ów SIP i SDP. Rozszerzeniem o zasadniczym znaczeniu jest w³¹czenie numerów telefonicznych (zgodnych z zasadami planu numeracji E.164) jako jednego z wariantów adresu SIP. W ten sposób u ytkownicy aplikacji SIP mog¹ komunikowaæ siê z abonentami PSTN. Pocz¹tkowa lista PINT obejmuje nastêpuj¹ce us³ugi. M ¹danie zestawienia po³¹czenia (Request to call): ¹danie to wys³ane z wêz³a IP powoduje zestawienie po³¹czenia miêdzy abonentami A i B. Przyk³adowym zastosowaniem jest dostêp z Internetu do telefonicznego centrum obs³ugi klientów. Wybór przycisku w witrynie centrum inicjuje zestawienie po³¹czenia telefonicznego z centrum do u ytkownika. M ¹danie wys³ania wiadomoœci telefaksowej (Request to fax): ¹danie to wys³ane z wêz³a IP powoduje nadanie wiadomoœci telefaksowej pod wskazany numer. M ¹danie odtworzenia g³osowego treœci (Request to hear content): ¹danie to wys³ane z wêz³a IP powoduje odtworzenie w postaci g³osowej zawartoœci wskazanej strony WWW. Us³uga umo liwia abonentom telefonicznym (klasycznym i pakietowym) g³osowe nawigowanie w Internecie/intranecie. M ¹danie do³¹czenia/ustanowienia telekonferencji (Request to Conference) w najbli szych planach. Zasada dzia³ania protoko³u PINT polega na przekazywaniu ¹dañ realizacji us³ug z wêz³ów sieci IP do serwera PINT, który z kolei komunikuje siê z w³aœciwym zasobem sieci PSTN/IN (np. z SCP). Wêze³ SCP realizuje us³ugê i przekazuje zwrotnie do inicjuj¹cej po³¹czenie aplikacji IP informacjê o statusie sesji us³ugowej. Nale y oczekiwaæ, e doœwiadczenie dotycz¹ce implementacji us³ug PINT doprowadzi do ujednolicenia zasad wspó³dzia³ania sieci IP z IN. Trzecia generacja sieci inteligentnej IN CS-3 uwzglêdnia w swoim modelu koncepcyjnym wspó³pracê SCF z jednostkami funkcjonalnymi spoza œwiata IN reprezentowanym jako IAF (Intelligent Network Access Function). Równie us³ugi PINT s¹ brane pod uwagê przez ITU-T przy normalizacji IN CS-3/4. Koncepcja SPIRITS Koncepcja SPIRITS zak³ada wykorzystanie Internetu i sieci IP do wspomagania sieci PSTN/IN i wzbogacania w ten sposób funkcjonalnoœci us³ug. Podstaw¹ do aktywowania funkcji us³ugowych Internetu/sieci IP s¹ przekazane informacje o zdarzeniach w PSTN/IN. W modelu koncepcyjnym IN CS-3 uwzglêdniono wspó³pracê z sieci¹ IP i mechanizm przekazywania informacji z/do procesów O-BCSM i T-BCSM. Dziêki temu scenariusze IN w SCF mog¹ wspó³pracowaæ z serwerami aplikacji w sieci IP. Najbardziej reprezentatywn¹ us³ug¹ SPIRITS jest powiadamianie i zarz¹dzanie po³¹czeniami przychodz¹cymi podczas nawigowania w Internecie ICW (Internet Call Waiting), rys. 7. Sieæ telefoniczna przekazuje do serwera SPIRITS informacjê o zajêtoœci linii w zwi¹zku z korzystaniem z dostêpu komutowanego do ISP. Nawiguj¹cy u ytkownik jest powiadamiany o przychodz¹cym po³¹czeniu przez Internet. Powiadomienie aktywuje u u ytkownika aplikacjê, która pozwala mu, na podstawie identyfikacji abonenta A, podj¹æ decyzjê o dalszym sposobie obs³ugi po³¹czenia przychodz¹cego (zakres mo liwoœci jest uwarunkowany typem dostêpu). Przyk³adowe mo liwoœci to: M przerwanie sesji internetowej i przyjêcie po³¹czenia, M kontynuacja sesji i przyjêcie po³¹czenia jako VoIP, M kontynuacja sesji i przekierowanie po³¹czenia na inny numer (np. do serwera poczty g³osowej), M kontynuacja sesji po odrzuceniu po³¹czenia, Dalej przytoczono przyk³adow¹ listê zdarzeñ w sieciach PSTN/IN/GSM/UMTS, które mog¹ inicjowaæ wspó³dzia³anie SCF z serwerami aplikacji w sieci IP. 46 PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001
elastycznych us³ug rozszerzaj¹cych telefoniê i komunikacjê multimedialn¹ o mo liwoœci w³aœciwe dla Internetu. G³ówny nurt ewolucji IN bêdzie wiêc si³¹ rzeczy zwi¹zany ze stopniow¹ migracj¹ od klasycznych stacjonarnych sieci publicznych z komutacj¹ ³¹czy ku mobilnym wielous³ugowym sieciom pakietowym nowej generacji. Na rys. 8 przedstawiono architekturê sieci, O Rys. 7. Ilustracja usługi ICW. Oznaczenia wyjaśniono w tekście Zdarzenia w sieci IN/PSTN: M powiadomienie o po³¹czeniu przychodz¹cym, M zakoñczenie po³¹czenia, M rozpoczêcie wybierania numeru (np. numeru dostawcy us³ug internetowych ISP), M zakoñczenie po³¹czenia z ISP, M zestawienie po³¹czenia do ISP, M pojawienie siê nowej wiadomoœci w poczcie g³osowej/elektronicznej, M próba aktywacji us³ugi dodatkowej, M wyczerpanie kredytu upowa niaj¹cego do korzystania z us³ug. Zdarzenia w sieci mobilnej: M w³¹czenie lub wy³¹czenie terminalu mobilnego (MS), M zmiana sieci (roaming In/ Out). PODSUMOWANIE Infrastruktura IN jest obecnie powszechnie wykorzystywana do realizacji us³ug zarówno w sieciach mobilnych, jak i stacjonarnych, a architektura IN, w ca³oœci lub w istotnych swoich fragmentach, wpisuje siê w modele przewidywanej ewolucji sieci (UMTS, IMT 2000). Tak e uniwersalne wielous³ugowe sieci pakietowe nowej generacji uwzglêdniaj¹ elementy architektury i funkcjonalnoœæ IN w swojej strukturze. Ewolucja sieci przebiega w kierunku rozproszenia i decentralizacji inteligencji odpowiedzialnej za realizacjê us³ug. Sieæ nowej generacji stanowi po³¹czenie dwóch przeciwstawnych paradygmatów: koncepcji klasycznej sieci inteligentnej opartej na scentralizowanym modelu realizacji us³ug w³aœciwej dla sieci z komutacj¹ ³¹czy i zak³adaj¹cej jedynie elementarn¹ funkcjonalnoœæ aparatów koñcowych (sygnalizacja abonencka DTMF, byæ mo e tak e DSS1) i modelu specyficznego dla Internetu i sieci IP, w którym sieæ (pakietowa) jest g³upia nieinteligentna [18] i s³u y jedynie do transportu strumieni informacji miêdzy inteligentnymi serwerami aplikacji i terminalami. Dziêki postêpowi technicznemu w dziedzinie technik informacyjnych (nadal zgodnego z prawem Moore a) pojawi³y siê szerokie mo liwoœci przetwarzania, interakcji i wizualizacji informacji w urz¹dzeniach koñcowych, które, w praktyce maj¹c funkcjonalnoœæ miniaturowego komputera osobistego PDA (Personal Digital Assistant) staj¹ siê komunikatorami osobistymi. W sieciach pakietowych IP wykorzystuj¹cych protokó³ SIP zak³ada siê, e ka dy terminal pe³ni rolê zarówno klienta, jak i serwera, co, jak wczeœniej opisano, zapewnia rozproszon¹ implementacjê funkcjonalnoœci sieci IN, a tak e realizacjê zupe³nie nowych kategorii PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001 O Rys. 8. Ewolucja architektury IN. Etap współpracy sieci IP z PSTN/ISDN. Oznaczenia: BCP T Best Current Practice for Tele phony, BICC Bearer Independent Call Control, MGC Media Gate way Controller, MGW Media Gateway, SG Signalling Gateway. Pozostałe oznaczenia wyjaśniono w tekście w której s¹ realizowane us³ugi IN dla abonentów w sieciach PSTN i IP. Pojawi¹ siê us³ugi i zastosowania hybrydowe, wykorzystuj¹ce po³¹czon¹ funkcjonalnoœæ IN, IP, Internetu i sieci mobilnych [1]. [2], [15], [19]. Jednym z przejawów tej tendencji jest, opisana w treœci niniejszego artyku³u, integracja us³ugowa PSTN/IN z Internetem (koncepcje PINT i SPIRITS). Zmieni siê tak e rynek us³ugodawców. Przejœcie ku technice IP, któremu towarzyszy opracowywanie znormalizowanych interfejsów programistycznych API, do zasobów sieci, np. Parlay i JAIN TCAP Java Be ans, zmieni radykalnie model udostêpniania us³ug, czyni¹c go masowym. Klasyczna implementacja us³ug telekomunikacyjnych (zamkniête aplikacje firmowe, specyficzne dla platformy ka dego dostawcy), w tym us³ug IN, zostanie zast¹piona przez otwarte nowe aplikacje wykorzystuj¹ce np. Parlay API. Mo e to spowodowaæ otwarcie rynku us³ug i aplikacji na tak¹ skalê, jak obecnie w Internecie. Otwart¹ spraw¹ pozostaje sposób implementacji przysz³ej sieci inteligentnej. Wœród wielu koncepcji implementacyjnych najbardziej obiecuj¹ce wydaj¹ siê ró ne rozproszone techniki obiektowe CORBA, Java i DCOM oraz koncepcja mobilnych agentów MAT (Mobile Agent Technology) [16]. Przez analogiê do znanego z teleinformatyki sloganu: tak naprawdê dopiero sieæjest komputerem mo na stwierdziæ, e wielous³ugowa sieæ nowej generacji bêdzie nasz¹ now¹ central¹ telefoniczn¹. Dostêp do jej us³ug przewodowy lub bezprzewodowy stanie siê mo liwy z dowolnego miejsca i za pomoc¹ dowolnego terminalu. Przez pewien czas po wprowadzeniu do eksploatacji pierwszych central telefonicznych o sterowaniu programowym fakt ten podkreœlano u ywaj¹c terminu centrala SPC (Stored Programme Control). Poniewa od kilkunastu lat w sieciach s¹ instalowane wy³¹cznie tego typu centrale i jest to dla wszystkich oczywiste zaniechano u ywania okreœlenia SPC. Nale y tak e s¹dziæ, e zamiast u ywania terminu sieæ inteligentna bêdzie siê mówi³o o inteligencji sieci jako ca³oœci, a klasyczna architektura IN pozostanie jej szczególnym przypadkiem. Bêdzie to zwi¹zane z przejœciem od modelu scentralizowanego, w³aœciwego dla klasycznej sieci IN, do modelu rozproszonego, w którym w sieciach nowej generacji wszystkie ele- 47
menty architektury bêd¹ potencjalnie wyposa one w funkcje aktywnego przetwarzania informacji i sygnalizacji. Np. model funkcjonalny VHE w UMTS zak³ada tak¹ mo liwoœæ, a praktyczna jego realizacja opiera siê na ró nych wariantach wspó³dzia³ania sieci IN generacji CS-2/3. LITERATURA [1] Cykl artyku³ów pod has³em: Intelligent Networks in the New Millenium, IEEE Communications Magazine, nr 6, June 2000 [2] Materia³y konferencji IEEE: IN 2000 Intelligent Network Workshop, Cape Town, 7-11 May 2000 [3] Handley M., Schulzrinne H., Schooler E., Rosenberg J.: Session Initiation Protocol, RFC 2543, IETF, 2000 [4] Handley M., Jacobson V.: SDP: Session Description Protocol, RFC 2327, IETF, 1998 [5] Petrack S., Conroy L.: The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services, RFC 2848, IETF, 2000 [6] ITU-T Zalecenie Q.1221: Intelligent Network, Introduction to Intelligent Network Capability Set 2, ITU, Genewa, 1998 [7] ITU-T Zalecenie H.323: Packet Based Multimedia Communications Systems, ITU, Genewa, 1998 [8] ETSI TIPHON Working Group: http://www.etsi.org/tiphon [9] Œredniawa M.: Sieci inteligentne architektura, us³ugi, zastosowania, materia³y dla s³uchaczy Studium CITCOM-PW, Warszawa, 1998 [10] Extensible Markup Language (XML), W3C, http://www.3w.org/xml [11] Dokumenty i materia³y UMTS Forum i WAP Forum [12] PINT: http://www.ietf.org/html.charters/pint-charter.html [13] SPIRITS: http://www.ietf.org/html.charters/spirits-charter.html [14] IPTEL: http://www.ietf.org/html.iptel/spirits-charter.html [15] Spring 2000 / Fall 2000: Voice on the Net Conference VON 2000, materia³y konferencyjne, Las Vegas /Atlanta, 2000 [16] Breugst M., Magedanz T.: Mobile Agents Enabling Technology for Active Intelligent Network Implementation, IEEE Network, May/June 1998 [17] Faggion N., Hua T.: Personal Communications Services Through the Evolution of Fixed and Mobile Communications and the Intelligent Network Concept, IEEE Network, July/August 1998 [18] Isenberg D.S.: The Dawn of the Stupid Network, ACM Networker 2.1, February/March 1998 [19] D¹browski M., Œredniawa M.: Ewolucja us³ug telekomunikacyjnych, Przegl¹d Telekomunikacyjny i Wiadomoœci Telekomunikacyjne, nr 1, 2000 Artykuł recenzowany (Artyku³ nades³ano do red. listopad 2000 r.) 48 PRZEGLĄD TELEKOMUNIKACYJNY! ROCZNIK LXXIV! nr 1/2001