Sieci Inteligentne (IN) Sieci Następnej Generacji (NGN) Telefonia IP H.323 i SIP Architektura usługowa IMS

Transkrypt

1 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Sieci Inteligentne (IN) Sieci Następnej Generacji (NGN) Telefonia IP H.323 i SIP Architektura usługowa IMS Michał Jarociński, Marek Średniawa INSTYTUT TELEKOMUNIKACJI POLITECHNIKA WARSZAWSKA Marzec - kwiecień

2 2

3 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Spis treści 1 SIECI INTELIGENTNE WPROWADZENIE PODSTAWY IN EWOLUCJA IN IN CS IN CS IN CS IN I SIECI MOBILNE - CAMEL IN, IP I INTERNET WPROWADZENIE DO NGN KONWERGENCJA Charakterystyka usług konwergentnych Uwarunkowania techniczne NGN - CZYLI TELEKOMUNIKACJA WYNAJDYWANA NA NOWO WPROWADZENIE KORZENIE KOMUNIKACJI I EWOLUCJA KU NGN NGN, IMS I INTERNET NGN I WEB X PODSUMOWANIE NORMALIZACJA USŁUG, PROTOKOŁÓW I ARCHITEKTURY NGN WPROWADZENIE STANDARYZACJA ARCHITEKTURY NGN W ITU-T Architektura i podział funkcjonalny Wizja konwergencji usług NGN wg ITU-T - CSF ETSI TISPAN NGN NGN Release 2 i Release STANDARYZACJA PROTOKOŁÓW NGN W IETF Wprowadzenie H.323 I SIP GŁÓWNE PROTOKOŁY APLIKACYJNE NGN H Elementy architektury H Charakterystyka i zastosowania H SIP Budowa protokołu oraz model sesji Adresacja

4 Negocjacja parametrów sesji SIP Model obecności Informacja o statusie obecności Format RPID bogata obecność Standard obecności i wymiany wiadomości natychmiastowych Przetwarzanie informacji o obecności Kierunki rozwoju protokołu SIP oraz jego rola w IMS ARCHITEKTURA TISPAN NGN USŁUGI FMC WPROWADZENIE ARCHITEKTURA TISPAN NGN ZACHOWANIE CIĄGŁOŚCI SESJI GŁOSOWYCH - VCC MODEL STEROWANIA SESJĄ I REALIZACJA USŁUG W IMS SERWERY APLIKACJI I REALIZACJA USŁUG WARIANTY REALIZACJI SERWERÓW APLIKACYJNYCH MECHANIZM WYZWALANIA USŁUG W SERWERACH APLIKACYJNYCH Profil Użytkownika Kryteria Filtrowania MODELE IMPLEMENTACJI APLIKACJI NGN W ARCHITEKTURZE USŁUGOWEJ IMS Wprowadzenie IMS i Web MODEL REALIZACJI USŁUG - DYSKUSJA IMS I USŁUGI IPTV Przegląd normalizacji IPTV ETSI TISPAN IPTV ITU-T FG IPTV GPP MBMS OMA BCAST IETF Ewolucja rozwiązań i architektury IPTV ku NGN Modele realizacji usług IPTV w NGN Realizacja usług IPTV z wykorzystaniem IMS Funkcje sterowania usługami IPTV Funkcje IPTV związane z obsługą mediów Usługi IMS IPTV Tryby usługi IPTV i scenariusze usługowe MIGRACJA KU ARCHITEKTURZE SIECI NGN OPARTEJ NA IMS WPROWADZENIE

5 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 8.2. PROTOKOŁY STEROWANIA SESJAMI ITU-T GPP ETSI TISPAN IETF Porównanie SIP-T z SIP-I (Q Profil C) SCENARIUSZE MIGRACJI USŁUG Zapewnienie ciągłości usług za pomocą IM-SSF Migracja usług dodatkowych PSTN/ISDN/GSM Migracja usług IN z wykorzystaniem techniki OSA/Parlay Interakcje między tradycynyjmi usługami a aplikacjami OSA/SIP IM-SCF: Migracja aplikacji SIP PODSUMOWANIE LITERATURA

6 Lista skrótów 3GPP AAA ABG-FE ACTS ADSL AGCF AMG AMG-FE API APL-GW-FE AS AS-FE ATM BGCF BS BSC CAMEL CAP CCF CDMA CS CS CSCF CS-PES DNS DRM DSL DSLAM DTV DVB DWDM EDGE ETSI FDM 3 rd Generation Partnership Project Authentication, Authorization and Accounting Access Border Gateway Functional Entity Advanced Communication Technologies and Services Asymmetric Digital Subscriber Line Access Gateway Control Function Access Media Gateway Access Media Gateway Functional Entity Application Programming Interface Application Gateway Functional Entity Application Server Application Server Functional Entity Asynchronous Transfer Mode Breakout Gateway Control Function Base Station Base Station Cotroller Customized Applications for Mobile Enhanced Logic CAMEL Application Part Call Control Function Code Division Multiple Access Capability Set Call Server Call Session Control Function Call Server based PSTN/ISDN Emulation Service component Domain Name Server Digital Right Management Digital Subscriber Line Digital Subscriber Line Access Multiplexer Digital TV Digital Video Broadcasting Dense Wave-Division Multiplexing Enhanced Data Rates for GSM Evolution European Telecommunications Standards Institute Frequency Division Multiplexing 6

7 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS FE FITL FSN FTTB FTTC FTTCab FTTH FTTN GII GPRS GSM HLR HSS HTML HTTP IBC-FE IBG-FE I-CSCF IETF IFN IMS IMS-PES IM-SSF IN INAP IP IPTV ISC ISDN ISUP ITU-T LAN LEX LMDS MAP MDA Functional Entity Fibre in the Loop Full Service Network Fibre to the Building Fibre to the Curb Fibre to the Cabinet Fibre to the Home Fibre to the Distribution Node Global Information Infrastructure General Packet Radio System Global System For Mobile Communication Home Location Register Home Subscriber Server HyperText Markup Language HyperText Transfer Protocol Interconnection Border Gateway Control Functional Entity Interconnection Border Gateway Functional Entity Interrogating CSCF Internet Engineering Task Force IMS for Next Generation Networks IP Multimedia Service component IMS base PSTN/ISDN Emulation Service component IP Multimedia Service Switching Function Intelligent Network IN Application Part Internet Protocol IP Television IMS Service Control Integrated Services Digital Network ISDN User Part International Telecommunications Union-Telecommunications Sector Local Area Network Local Exchange Local Multipoint Distribution Service Mobile Application Part Mobile Digital Assistant 7

8 MEGACO MG MGC MGCF MRCF MRFC MRP-FE MTP NACF NGN NNI NSIW-FE NT OAM OMA ONP OSA PC P-CSCF PDA PDF PDH PES PLMN PNO PON POTS PSTN QOS RACF RF RSU RTP SAA-FE SCIM SCP MEdia GAteway COntrol protocol Media Gateway Media Gateway Controller Media Gateway Control Function Media Resource Control Function Multimedia Resource Function Controller Media Resource Process Functional Entity Message Transfer Part Network Access Control Functions Next Generation Network Network Network Interface Network Signalling Interworking Functional Entity Network Termination Operation, Administration And Maintenance Open Mobile Alliance Open Network Provisioning Open Service Architecture Personal Computer Proxy CSCF Personal Digital Assistant Policy Decision Function Plesiochronous Digital Hierarchy PSTN/ISDN Emulation Service component Public Land Mobile Network Public Network Operator Passive Optical Network Plain Old Telephone Service Public Switched Telephone Network Quality of Service Resource and Admission Control Functions Routing Function Remote Subscriber Unit Real-time Transport Protocol Service Authentication and Authorization Functional Entity Service Capability Interaction Manager Service control point 8

9 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS S-CSCF S-CSC-FE SCTP SDH SDSL SG SG-FE SIF SIP SL-FE SME SPF SS7 SSF SSP STB STP SUP-FE TMG TMG-FE UMTS USO VDSL VGW VoD VXML WDM Serving CSCF Serving Call Session Control Functional Entity Stream Control Transmission Protocol Synchronous Digital Hierarchy Symmetric Digital Subscriber Line Signalling Gateway Signalling Gateway Functional Entity Signalling Interworking Function Session Initiation Protocol Subscription Locator Functional Entity Small and Medium Enterprise Service Provide Function Signalling System No.7 Service Switching Function Service Switching Point Set Top Box Signalling Transfer Points Service User Profile Functional Entity Trunking Media Gateway Trunking Media Gateway Functional Entity Universal Mobile Telecommunications System Universal Service Obligation Very High Speed Digital Subscriber Line Voice over IP Gateway Video on Demand Voice extensible Markup Language Wavelength Division Multiplexing 9

10 1 Sieci Inteligentne 1.1. Wprowadzenie Koncepcja klasycznej sieci inteligentnej (Intelligent Network - IN), pochodząca z pierwszej połowy lat osiemdziesiątych, była udanym pomysłem na rozwiązanie problemu szybkiego wprowadzania nowych usług o elastycznych scenariuszach działania (takich jak. np. połączenie bezpłatne i inne usługi translacji numeru, VPN, połączenie kredytowane) do publicznej sieci telefonicznej. Podejście tradycyjne polegające na rozproszonej implementacji usług w oprogramowaniu central końcowych okazało się niepraktyczne ze względów logistycznych (ograniczenia wynikające z wymagania ciągłości świadczenia usług, czasochłonność, wysoki koszt modernizacji central spowodowany skalą przedsięwzięcia - duża liczba central i ich znaczna różnorodność - różni dostawcy, wersje oprogramowania, konfiguracja, generacja techniczna). 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, ETSI Ich wynikiem są zalecenia i normy definiujące model koncepcyjny kolejnych generacji sieci IN: CS-1 (1992-4), CS- 2 ( ), CS-3 ( ), CS-4 (2003). (Na Rys. 1 przedstawiono drzewo genealogiczne IN). 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) za pomocą techniki DECT, 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 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. Prace dotyczące rozwoju 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). 10

11 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS IN związana z usługami (800, ACCS, VPN, ) AIN Rel. 0.1 AIN Rel. 0.2 AIN Rel. 1 & 2 ITU-T CS-1 GR1298 (Rel. 0.2) ITU-T CS-1R ETSI Core INAP CS-1 ITU-T CS-2 ETSI INAP CS-2 ANSI ANS dla IN ITU-T CS-3 ETSI INAP CS-3 GSM CAMEL Legenda TR45.2 WIN FPLMTS/IMT-2000 UMTS USA Bellcore - Standardy de facto USA - ANSI, TIA - Standardy de jure Zalecenia ITU-T Normy europejskie (ETSI) Rys. 1.1 Drzewo genealogiczne IN Obecnie większość operatorów świadczy usługi IN CS-1. Wśród nich jest również Telekomunikacja Polska S.A., która udostępniła następujące usługi: połączenie bezpłatne - FPH ( 800 linia bezpłatna) połączenie z podziałem opłaty - SPL ( 801 linia ulgowa) uniwersalny numer dostępowy - UAN ( 804 linia firmowa) teległosowanie - VOT ( 400 ) wirtualna sieć wydzielona - VPN ( 806 ) Niektórzy operatorzy wykorzystują platformę IN do wzbogacenia usług sieci GSM, a także do realizacji usług obejmujących sieć stacjonarną i mobilną 1, np. VPN, numer osobisty, wspólna poczta glosowa, 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 i numerów usług (LNP i SNP - Local Number Portability i Service Number Portability). Czynniki takie 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 rozważaniach dotyczących IN wzięto pod uwagę następujące zagadnienia: 1 W odniesieniu zastosowań tego typu używa się terminu FMC (Fixed-Mobile Convergence). 11

12 IN i Internet. Współdziałanie IN i Internetu do realizacji hybrydowych usług wykorzystujących możliwości obu sieci. IN i IP. Realizacja usług IN w środowisku sieci IP. Rola IN w sieciach nowej generacji. Wykorzystanie IN w sieciach mobilnych. Ewolucja normalizacji IN. 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: dostosowywanie scenariuszy i profili usług do indywidualnych wymagań abonentów obsługa mobilności terminali, użytkowników i usług integracja mediów wzrost inteligencji sieci i jej decentralizacja konwergencja sieci stacjonarnych i mobilnych - FMC Należy podkreślić, że w odniesieniu do każdego z wymienionych kierunków rozwoju koncepcja IN może znaleźć zastosowanie Podstawy IN Termin inteligencja ma wiele znaczeń. W kontekście technicznym inteligencja 2 jest zwykle postrzegana jako proaktywne zachowanie systemu charakteryzujące się elastycznością działania zgodną z oczekiwaniami użytkownika i uwzględnieniem towarzyszących okoliczności. Tak właśnie rozumiana Inteligencja, w tej lub innej formie, była w historii usług telekomunikacyjnych zawsze obecna. W początkowym okresie rozwoju telefonii sieci była ona przede wszystkim realizowana osobiście przez personel central, który dbał o właściwy sposób obsługi abonentów uwzględniający ich indywidualne preferencje. Powrót do dawnych dobrych czasów elastycznego i personalnego trybu obsługi połączeń telefonicznych umożliwiło, w pewnym zakresie, rozwiązanie techniczne nazywane siecią inteligentną (IN Intelligent Network). Sieć inteligentna definiuje znormalizowaną koncepcję uniwersalnej architektury sieciowej, która określa sposób rozbudowy podstawowej infrastruktury publicznej sieci telefonicznej, umożliwiający szybkie wprowadzanie nowych usług telekomunikacyjnych charakteryzujących się elastycznymi scenariuszami, dostosowanymi do indywidualnych wymagań abonentów. IN pozwala na 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, zajętość lub brak odpowiedzi. 2 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. 12

13 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Główna zasada działania IN polega 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 IN obejmuje: model koncepcyjny IN - IN CM listę usług i funkcji usługowych listę uniwersalnych modułów usługowych SIB i zasady konstruowania z nich scenariuszy usług definicje architektury funkcjonalnej i fizycznej sieci 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 zdefiniowana 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ści opisu IN (por. Rys.1.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ę (w ogólności rozproszonych) maszyn wirtualnych IN. Na Rys. 1.2 przedstawiono typową konfigurację sieci IN (uwzględniono odwzorowanie DFP na PP). Oferowane usługi IN Usługa VPN funkcje us ługowe: PNP, ONA, OFA Płaszczyzna usługowa - SP Usługa FPH funkcje usługowe: ONE, REVC, TDR, ODR, OUP, Projektowanie usług IN BCP SIB1 SIB2 SIB3 Globalna Płaszczyzna Funkcjonalna - GFP Globalna logika usługi - GSL Architektura funkcjonalna IN SDF IF CCF SSF SCF Rozproszona Płaszczyzna Funkcjonalna - DFP SMF SCEF SRF SSF Architektura fizyczna IN SSP SCP INAP IP Płaszczyzna Fizyczna - PP SMP Rys IN CM model koncepcyjny sieci IN 13

14 Szczególnie istotne dla uniwersalności koncepcji IN było wyróżnienie w modelu IN CM: Globalnej Płaszczyzny Funkcjonalnej GFP (Global Functional Plane), Rozproszonej Płaszczyzny Fukcjonalnej DFP (Distributed Functional Plane) i Płaszczyzny Fizycznej PP (Physical Plane), które odpowiednio reprezentują: perspektywę projektanta usług (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 architektury fizycznej stwarza swobodę implementacji sieci IN. wielowarianto. Opisane podejście w dużym stopniu uniezależniło proces projektowania usług od architektury sieci, a także umożliwiło świadczenie IN usług w różnych środowiskach sieci bazowych (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 IN dla abonentów sieci GSM. Wielu operatorów GSM wykorzystuje platformę IN w celu wzbogacenia funkcjonalności oferowanych usług w zasięgu swojego działania, a także w sieciach innych współpracujących operatorów (roaming). Udostępnienie niestandardowych usług GSM poza macierzystą siecią wymagało zaadaptowania koncepcji IN do potrzeb sieci komórkowych. ETSI opracował zestaw norm CAMEL. SCEP SCF SCEF SCP SDF X.25 TCP/IP SMP INAP INAP SMF Sieć sygnalizacyjna SS7 IP SRF ISUP SSP CCF SSF ISUP SSP SRF SSF CCF CCAF CCAF Rys. 1.3 Typowa konfiguracja sieci IN Interfejs między siecią telefoniczną a platformą IN jest obsługiwany przez protokoły warstwy aplikacyjnej 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ń w centralach 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. W znormalizowanych procesach obsługi połączeń w SSP 14

15 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS zdefiniowane są stany i związane z nimi kryteria, które pozwalają na zawieszenie 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 w SCP, w ściśle określonych sytuacjach (POI - Point of Initiation). Wypracowane, 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 BCP może również nastąpić tylko w jednym ze zdefiniowanych normą miejsc POR (Point of Return). DFP definiuje elementy składowe architektury funkcjonalnej IN (SCF, SSF, CCF, CCAF, SRF, SDF, SMF, SMAF). 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 tel.). 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 terminala). SRF (Specialized Resources Function). wspomaga SSF przy realizacji scenariuszy usług (interakcja z abonentem - zapowiedzi słowne, rejestracja decyzji ab., rozpoznawanie mowy, itp.) SCF (Service Control Function). steruje obsługą połączeń zgodnie z przechowanymi scenariuszami usług. 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 przesłania 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). Zdalny dostęp użytkownika SMF. 15

16 Rys.1.4 Mechanizm działania IN interakcja logiki usługi zlokalizowanej w SCF z procesami O_BCSM i T_BCSM Na poziomie DFP podstawowy proces obsługi połączenia BCSM (Basic Call State Model) jest reprezentowany przez dwie swoje połówki jako O_BCSM i T_BCSM (Originating i Terminating) reprezentujące procesy połączenia wychodzącego i przychodzącego. Każdy z BCSM jest zdefiniowany przez zbiór stanów PIC (Point In Call) - miejsc w procesie i DP - punktów detekcji (Detection Point) oraz zbiór przejść. Napotkanie uzbrojonego (aktywnego) punktu detekcji powoduje zawieszenie 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 (por. Rys.1.4) Ewolucja IN IN CS-2 IN CS-2, dziedzicząc w pełni własności IN CS-1, wprowadza rozszerzenia zwiększające możliwości usługowe sieci inteligentnej. Do najważniejszych z nich należą: Obsługa połączeń wielostronnych z mechanizmami sterowania stronami połączenia - CPH (Call Party Handling). Interakcja z usługami nie związana z bieżącym kontekstem połączenia (wykorzystanie funkcjonalności ISDN DSS1) Uwzględnienie wymagań dostępu bezprzewodowego obsługa CTM (Cordless Terminal Mobility). UPT i integracja z UMTS (elementy obsługi mobilności abonenta i terminala). 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). Realizacja skryptów SRF. 16

17 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Normalizacja IN CS-2 opiera 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) pociągnęło za sobą konieczność modyfikacji pozostałych płaszczyzn 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) rozbudowano modele O_BCSM i T_BCSM dodając nowe stany i przejścia. Ponadto wprowadzono nowe elementy 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 3. Ponieważ płaszczyzna DFP reprezentuje jedynie architekturę funkcjonalną sieci IN to konieczne było także określenie sposobów odwzorowania DFP na Płaszczyznę Fizyczną. Znajduje to bezpośrednie odzwierciedlenie w zalecanych wariantach implementacji sieci IN. Usługi oraz funkcje usługowe zestawu CS-2 stanowią rozwinięcie zestawu CS-1. W odróżnieniu jednak od CS-1, który szczegółowo opisuje konkretne usługi, w zestawie CS-2 zdefiniowano tylko tzw. kategorie grupy usług. Są to usługi dla abonentów ruchomych (ang. mobility services), np. usługa uniwersalnej łączności osobistej UPT (ang. Universal Personal Telecommunications) i obsługi bezprzewodowych aparatów końcowych CTM (ang. Cordless Terminal Mobility) oraz abonentów systemu GSM trzeciej generacji - UMTS, (ang. Universal Mobile Telecommunication System) IN CS-3 IN CS-3 stanowi poprawioną wersję IN CS-2, do której dołączono normalizację dotyczącą architektury CAMEL (adaptacji IN do potrzeb sieci GSM/UMTS). W 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. Przewidziano także możliwość współpracy systemów zarządzania należących do różnych operatorów (relacja SMF-SMF). Na Rys.1.5 przedstawiono architekturę funkcjonalną IN CS-2/3. Z usługowego punktu widzenia do najważniejszych rozszerzeń wprowadzonych w IN CS-3 należą: Mechanizmy współpracy IN IP. Obsługa protokołów PINT/SIP/H.323 w SSF. Obsługa wielu punktów sterowania Mechanizmy obsługi niepożądanej interferencji funkcji usługowych Zaawansowane metody naliczania opłat Włączenie do normy specyfikacji Fazy 3 CAMEL. Obsługa Parlay API Specyfikacja zasad dostępu dla usługodawców Zasady realizacji przenośności numerów Ograniczone możliwości B-ISDN dla połączeń punkt-punkt 3 Dodano np. operacje przeznaczone do sterowania stronami połączenia: CreateCallSegmentAssociation, MoveCallSegments, MergeCallSegments, SplitLeg, MoveLeg, DisconnectLeg. 17

18 Granica między sieciami SMAF SMF Inne SMF SCEF SDF CS-1R CS-2 CS-1R SDF CS-1R SCF CS-2 SCF Terminal SCUAF CS-2 CS-2 CUSF CS-2 SSF CS-1R SRF IAF SRF CCAF CCF CCF Rys. 1.5 Architektura funkcjonalna IN CS-2 i CS IN CS-4 W związku z rozwojem sieci IP i usług telekomunikacyjnych w środowisku sieci pakietowych architektura funkcjonalna IN CS-3 została rozszerzona o mechanizmy współdziałania z sieciami nie-in, głównie z myślą o Internecie i sieciach IP (por. Rys.1.6). SDF SCF SRF SM Session Manager Serwer SIP Proxy SSF SSF SM IP/Internet CCF Gatekeeper H.323 Domena IN Domena IP Rys.1.6 Architektura IN CS IN i sieci mobilne - CAMEL Uniwersalność koncepcji IN została od razu zauważona przez środowisko GSM/UMTS. Stało się tak między innymi dlatego, że sieć GSM/UMTS ma strukturę, która odpowiada w dużym stopniu architekturze sieci IN. Początkowo koncepcja IN została wykorzystana do wzbogacenia oferty usługowej sieci GSM/UMTS, a także do integracji 18

19 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 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/UMTS sieci macierzystej podczas roamingu. Ich wynikiem była koncepcja CAMEL, której rozwój przebiegał równolegle z IN. Zdefiniowany został protokół CAP (CAMEL Application Part) jako podzbiór INAP z dodatkowymi parametrami operacji (specyficznymi dla potrzeb sieci GSM/UMTS) i zasady współpracy CSE (CAMEL Service Ennvironment) czyli gsmscp z węzłami sieci GSM/UMTS (HLR, VLR, MSC rozszerzonego o funkcje SSF i pełniącego rolę gsmssp). Architekturę CAMEL przedstawiono na Rys.1.7. Sieć macierzysta HLR MAP MAP gsmscf CSE CAP MAP CAP gsmssf Incoming line Roaming leg GMSC forwarded leg CAP Sieć wysyłająca zapytanie VLR gsmssf VMSC outgoing leg MS Sieć wizytowana gsmsrf Rys.1.7 Architektura CAMEL 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. Specyfikacja CAMEL Faza 4 stał się częścią normalizacji IMS. Do najważniejszych elementów funkcjonalności usługowej koncepcji CAMEL należą: Naliczanie opłat na bieżąco. Transport informacji o lokalizacji użytkownika. Możliwość samodzielnego aktywowania usług dodatkowych GSM przez użytkownika. Kontrola czasu trwania połączeń. Wprowadzenie dodatkowych punktów detekcji (GPRS DP i SMS DP). Zarządzanie mobilnością. Realizacja idei VHE (w ograniczonym stopniu). Zarządzanie stronami połączenia IN, IP i Internet Ewolucja tradycyjnych sieci telekomunikacyjnych ku uniwersalnym wielousługowym sieciom pakietowym 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/UMTS. Tworzą ją nowe typy węzłów sieci (np. routery, 19

20 bramy dla mediów i sygnalizacji, serwery różnego rodzaju) i nowe protokoły, których zakres funkcji obejmuje sterowanie (w szerokim sensie) połączeniami i transport mediów z zachowaniem wymagań jakościowych (QoS). W odniesieniu do telefonii IP główne znaczenie mają dwa rozwiązania: rodzina protokołów 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 do transportu mediów (RTP, RTCP, RSVP, UDP i TCP). Różnią się one natomiast podejściem do projektowania i realizacji usług oraz wizją architektury sieci. 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ą. Główny realizacji współdziałania PSTN/IN z siecią IP opiera się przede wszystkim na wykorzystaniu mechanizmów protokołu SIP. Zidentyfikowano m.in. nastepujące obszary współdziałania IN, IP i Internetu: Sterowanie usługami PSTN/IN za pomocą Internetu - PINT (PSTN/Internet Interworking). Przekazywanie informacji o zdarzeniach w PSTN/IN do Internetu - SPIRITS (Services in the PSTN/ IN Requesting Internet Services). Wykorzystanie istniejących scenariuszy usług IN i przeniesienie ich implementacji w środowisko IP. Dostęp do usług IN z sieci IP Przeniesienie protokołów aplikacyjnych INAP/TCAP w środowisko IP. Odwzorowanie modelu procesu połączenia IN 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 statise realizacji usług w PSTN/IN. Opisane koncepcje zostały uwzględnione w zaleceniach ITU-T dla IN CS-4. 20

21 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 2 Wprowadzenie do NGN 2.1. Konwergencja Kluczowym pojęciem, które pojawia się w związku z sieciami następnej generacji jest konwergencja. Wyraża ono zjawisko przenikania się technik, idei, rozwiązań i koncepcji z obszaru telekomunikacji, informatyki, Internetu i mediów elektronicznych, które sprawia, że należy w nowy sposób spojrzeć na każdą z wymienionych dziedzin osobno jak również całościowo na wszystkie razem. Konwergencja jest zjawiskiem wieloaspektowym, zachodzi w wielu płaszczyznach, może być rozpatrywana z różnych punktów widzenia i rodzi również problemy pozatechniczne natury prawnej i biznesowej. Użytkownicy postrzegają konwergencję jako możliwość uzyskania zbliżonego pakietu usługowego obejmującego telefonię, dostęp do Internetu i telewizję, od podmiotów, które wcześniej należały do odrębnych segmentów rynku. Operatorzy telekomunikacyjni oprócz usług telefonii i dostępu do Internetu oferują usługi IPTV, operatorzy telewizji kablowej oferują usługi telefoniczne i dostępu do Internetu, podmioty z rynku internetowego oferują usługi komunikacji głosowej i wideo oraz dostęp do treści na życzenie, nadawcy radiowi i telewizyjni wykorzystują Internet do dystrybucji swoich programów 4. Konwergencja jest postrzegana przez użytkowników jako możliwość stałego korzystania przez klienta ze swojego specyficznego (skonfigurowanego na życzenie) pakietu usług z dowolnego miejsca i bez względu na sposób dostępu w sensie rodzaju wykorzystywanej sieci (przewodowa / bezprzewodowa, stacjonarna / mobilna, wąsko- /szerokopasmowa) i typu terminala (telefon stacjonarny, smartfon, telefon bezprzewodowy, tablet, komputer przenośny lub stacjonarny). W płaszczyźnie usługowej konwergencja polega na różnych formach integracji usług dla głosu, danych i multimediów. Przykładami praktycznymi są np. takie usługi jak zunifikowana obsługa wiadomości (Unified Messaging) integrująca pocztę elektroniczną, pocztę głosową, wiadomości tekstowe SMS i usługi VPN (Virtual Private Network) i PN (Personal Number) obejmujące zarówno sieć mobilną jak i stacjonarną. Nowe rozwiązania, w szczególności protokół SIP wraz z rozszerzeniami, umożliwia realizację usług wykorzystujących informację o dostępności, obecności, preferencjach użytkownika, (np. Push-To-Talk, Find-Me), w sposób integrujący mechanizmy sieci PSTN/ISDN/IN/GSM z sieciami IP i Internetem. Z technicznego punktu widzenia głównym czynnikiem wpływającym na rozwój usług konwergentnych jest technika IP i mechanizmy udostępniane przez protokoły aplikacyjne, a przede wszystkim protokół SIP Session Initiation Protocol) w powiązaniu z różnymi metodami dostępu szerokopasmowego. Realizacja usług konwergentnych pociąga za sobą liczne konsekwencje natury technicznej, marketingowej i prawnej dla operatora. Z technicznego punktu widzenia bazę dla realizacji usług konwergentnych w sieciach stacjonarnych stanowi architektura NGN. Z kolei w sieciach mobilnych podstawą do realizacji usług konwergentnych jest architektura IMS (IP Multimedia Subsystem) w UMTS. W obu przypadkach czynnikiem sprawczym są różne formy dostępu szerokopasmowego przewodowego (ADSL, VDSL, FTTx) i bezprzewodowego (HSPA i różne techniki WLAN), znormalizowane interfejsy 4 Np. Eurosport udostępnia przez Internet przekaz z imprez sportowych (np. turniejów tenisowych). Igrzysk Orange Polska oferuje pakiety programów telewizyjnych dostarczanych przez Internet. Operatorzy telewizji kablowej, oprócz kanałów telewizyjnych, oferują usługi telefoniczne stacjonarne i mobilne oraz dostęp do Internetu. 21

22 Parlay/OSA API i protokół SIP. Infrastrukturę sieciową stanowią sieci szkieletowe IP, Internet i klasyczne sieci TDM przewodowe i bezprzewodowe wraz z elementami zapewniającymi konwersję sygnalizacji i mediów. Bardzo ważnym, z praktycznego punktu widzenia, dodatkowym elementem infrastruktury, niezbędnym do działania usług konwergentnych jest baza danych ENUM (Electronic NUMber), która pozwala rozwiązać problem współpracy telefonicznego planu numeracji E.164 z systemem adresacji DNS dla sieci IP. Telekomunikacja Obecność i kontekst Mobilność Szerokopasmowość Dostęp bezprzewodowy Konwergencja Web Sieć semantyczna Bezpieczeństwo Multimedia Open Source Informatyka Rys. 2.1 Czynniki sprawcze zjawiska konwergencji usług Charakterystyka usług konwergentnych Termin usługi konwergentne jest pojęciem bardzo pojemnym, używanym hasłowo, głównie w sensie potocznym, do charakteryzowania usług telekomunikacyjnych, w których funkcjonalności, sposobie implementacji, udostępniania i eksploatacji mamy do czynienia z przenikaniem się zbieżnością, różnych podejść, wcześniej zazwyczaj stosowanych oddzielnie i niezależnie od siebie. W wielu przypadkach wspomnianego terminu używa się w odniesieniu do usług, które mają charakter zintegrowany, kompleksowy bądź hybrydowy. Brak precyzyjnej, ścisłej w sensie technicznym, definicji pojęcia usług konwergentnych wynika z generyczności przymiotnika konwergentny, który może się odnosić do bardzo szerokiego spektrum jej charakterystycznych cech, takich jak: Sposób dostępu (przewodowy / bezprzewodowy, wąskopamowy / szerokopasmowy, miedziany / światłowodowy / radiowy). Typ wykorzystywanych sieci (stacjonarna / mobilna, pakietowa / z komutacją łączy, Internet / telefoniczna / teleinformatyczna). Tryb przekazu (głos, tekst, dane, obrazy i grafika, wideo, wielomodalny z możliwością płynnej zmiany trybu). Technika realizacji (analogowa, cyfrowa). Platformy usługowe (wspólna dla wszystkich typów sieci, oddzielne serwery aplikacji, platformy integrowane za pomocą znormalizowanego API). Architektura sieci (PSTN, GSM, NGN, UMTS, LTE). 22

23 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Adresacja i identyfikacja użytkowników sieci (numer telefoniczny komórkowy / stacjonarny wg E.164, adres , adres SIP, adres IP, adres WWW URL, identyfikator konkretnego komunikatora, adres ENUM). Domena (usługi telekomunikacyjne, usługi informatyczne, usługi nadawcze). Terminale i urządzenia służące do korzystania z usług (telefon stacjonarny, smartfon, PC, tablet, odbiornik RTV, STB). Modalność komunikacji (telefonia, widekonferencja, wymiana wiadomości natychmiastowych, SMS i MMS, poczta elektroniczna, interakcja w czasie rzeczywistym, wymiana informacji bez interakcji, telemetria). Uwzględnianie kontekstu komunikacji (identyfikacja stron, lokalizacja, czas pora dnia i typ dnia, przynależność do określonej grupy, preferencje użytkowników i charakterystyka, wyzwalanie określonych akcji wynikających ze zmiany kontekstu). Rozliczanie usług (taryfikacja usług mobilnych wg stawek takich samych lub zbliżonych do stawek w sieci stacjonarnej, wspólne rozliczanie usług sieci stacjonarnej, mobilnej, pakietyzacja usług, on-line /off-line, rozliczanie za treść bądź dostęp). Usługi konwergentne uzyskuje się wybierając dowolne dwie lub więcej kategorii atrybutów i łącząc wybrane cechy z poszczególnych kategorii. Z uwagi na wielość i różnorodność cech i atrybutów, które się przenikają w wynikowych usługach należy podjąć próbę uporządkowania i klasyfikacji usług, tak by móc poddać je analizie z punktu widzenia technicznego, a także biznesowego, organizacyjnego i prawnego. Proponuje się zatem rozważać usługi konwergetne w oddzielnych płaszczyznach, bądź aspektach zbieżności, wyznaczonych przez wybór pary lub kilku ich najważniejszych atrybutów, cech lub funkcji. W ten sposób, można np. mówić o kategorii usług konwergentnych FMC (Fixed Mobile Convergence), czyli o usługach, które łączą funkcjonalność sieci stacjonarnej i mobilnej, takich jak np. uniwersalny numer osobisty, usługa VPN obejmująca sieć stacjonarną i mobilną, czy możliwość wykorzystywania tego samego terminala do korzystania z usług w obu typach sieci. Realizacja konwergencji FMC polegającej na świadczeniu zbliżonego bądź tego samego pakietu usług w sieci stacjonarnej i mobilnej może być uzyskana przez wykorzystanie wspólnej platformy usługowej. Można to obecnie osiągnąć za pomocą serwerów aplikacji wykorzystujących poprzez Parlay/OSA API funkcjonalność sieci stacjonarnych, mobilnych i Internetu. Taką rolę wspólnej platformy usługowej pełni architektura IMS. Konwergencja multimedialna polega na przenikaniu się usług telefonicznych, dostępu do Internetu i telewizji i wideo (DSL TV, IP TV, VoD). Na przykład wykorzystanie dostępu szerokopasmowego xdsl umożliwia łączne świadczenie usług telefonicznych, dostępu do Internetu oraz udostępnianie TV, strumieniowanie audio i wideo, a także dostarczanie wideo na życzenie VoD. Konwergentny pakiet obejmujący wymienione usługi jest określany terminem triple-play trzy w jednym lub quadruple play cztery w jednym jeśli uwzględnia dodatkowo usługi telefonii komórkowej. Przyjmując nieco szersze spojrzenie na zagadnienie można stwierdzić, że usługi konwergentne są wynikiem zachodzącego od pewnego czasu procesu konwergencji sieci telekomunikacyjnych, teleinformatycznych i Internetu, technik stosowanych do 23

24 realizacji wymienionych sieci, a także, w szerszym sensie, konwergencji przenikania się, bądź zacierania granic, między telekomunikacją, informatyką i mediami elektronicznymi. Proces konwergencji wywiera wpływ na główne podmioty związane z realizacją i eksploatacją usług: operatorów, usługodawców, dostawców, użytkowników i instytucje regulujące rynek. Z tego względu należy także rozważać odpowiadające im następujące obszary lub wymiary konwergencji: konwergencja rynkowa, konwergencja usługowa, konwergencja techniczna, konwergencja regulacyjna. Konwergencja rynkowa polega na budowaniu przez operatorów i usługodawców pakietów usługowych obejmujących różnorodne usługi i funkcje usługowe i oferowaniu ich jako zintegrowany produkt komercyjny wspólnie rozliczany, typowo na zasadzie rabatowo-ryczałtowej. Nowym przejawem konwergencji rynkowej jest wspólne świadczenie, w zintegrowanym pakiecie oferowanym klientom końcowym, usług telekomunikacyjnych i informatycznych, czyli tzw. sieciowe usługi IT 5 (np. infrastruktura sieciowa z usługami komunikacyjnymi IP VPN + podstawowe oprogramowanie sieciowe do zarządzania firmą, ochrona antywirusowa, pakiety oprogramowania do handlu obsługi elektronicznego). Konwergencja usługowa przejawia się np. poprzez: Zastosowanie uniwersalnych środków, które pozwalają korzystać z usług bez względu na technikę dostępu. Służą do tego np. wielosystemowe terminale przystosowane do dostępu bezprzewodowego w technikach GSM/UMTS/WLAN (Wi-Fi, WiMAX i Bluetooth) i urządzenia pełniące rolę domowych bram komunikacyjnych obsługujących różne formy dostępu (modem xdsl + przełącznik/ruter Ethernet + punkt dostępowy WLAN). Migrację usług z sieci nadawczej nadawcy RTV do sieci szerokopasmowej operatora telekomunikacyjnego. Wiele rozgłośni i stacji telewizyjnych nadaje równolegle w Internecie 6. Oferowanie pakietów usług wspólnych polegające na oferowaniu nowych usług powstałych z połączenia usług już istniejących. Może do dotyczyć zarówno płaszczyzny funkcjonalnej (komunikacja głosowa + usługi IMP + usługi internetowe) jak i płaszczyzny komercyjnej (np. zbiorcze wspólne rozliczanie dla usług sieci komórkowej i stacjonarnej oraz wprowadzenie numeru osobistego obejmującego sieć stacjonarną i mobilną). Powstawanie usług ukierunkowanych na substytucję sieci. Przykładem takiej usługi jest np. specjalna taryfikacja połączeń w sieci komórkowej z wyróżnieniem stref (np. domowej i biurowej), grupy osób (lista przyjaciół lub współpracowników), dla których stawki za połączenia są tak obniżone by skłonić użytkowników do korzystania z usług sieci mobilnej zamiast sieci stacjonarnej 7. 5 Pionierami i liderami sieciowych usług IT są BT Global Systems, T-Systems i Orange Business Services. 6 Np. TVP udostępniała przez Internet relację z Igrzysk Olimpijskich w Pekinie. 7 Np. usługa Genion oferowana w Niemczech przez operatora komórkowego O2. 24

25 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Stosowanie w praktyce idei Web 2.0, której najważniejszymi elementami są: znakowanie treści i umożliwienie różnych sposobów jej prezentacji, zastosowanie nowych formatów umożliwiających dodanie semantyki, mieszanie treści pochodzących z różnych źródeł za pomocą wspólnego zintegrowanego interfejsu użytkownika. Konwergencja techniczna polega na zastosowaniu jednolitych wspólnych rozwiązań technicznych, które służą do realizacji zróżnicowanych funkcjonalnie usług. Na obecnym etapie rozwoju telekomunikacji podstawą rozwiązania są: technika komutacji pakietów IP i wykorzystujące ją zestawy elementów architektury NGN lub 3G, które stanowią kompletny funkcjonalnie zbiór środków niezbędnych do realizacji usług. Należą do nich: węzły softswitch, bramy medialne i sygnalizacyjne, sterowniki bram (call server, gatekeeper), bramy dostępowe, bramy Parlay/OSA API i Parlay X, serwery aplikacji, sieci szkieletowe IP z zapewnienieniem QoS, węzły architektury sieci IN i CAMEL, serwery architektury sieci SIP, bazy danych ENUM, elementy składowe bądź kompletna architektura IMS, punkty dostępu bezprzewodowego WLAN (publiczne, prywatne i domowe). IMS jako uniwersalna, neutralna dostępowo, architektura usługowa dla sieci mobilnych i stacjonarnych udostępnia szerokie spektrum możliwości w zakresie realizacji usług konwergentnych: np. usługi głosowe z wykorzystaniem informacji o obecności i lokalizacji, strumieniowanie wideo i audio, IPTV. Przejawem konwergencji w obszarze regulacji jest radykalna zmiana podejścia do prawa telekomunikacyjnego, w którym operuje się konwergentnym pojęciem komunikacji elektronicznej, do którego odnoszą się wszystkie przepisy prawne i przyjmuje zasadę neutralności technologicznej w odniesieniu do sposobu realizacji usług. Sankcjonuje to sytuację, w której nastąpiło zatarcie granic między sektorami telekomunikacji, IT i mediów elektronicznych. Usługi Telefonia Teleinformatyka Nadawanie RTV Sieci Internet IP GSM / UMTS PSTN / ISDN / IN WLAN WMAN Sieć nadawcza RTV Sieć satelitarna Terminale Ap.telefoniczny PC Odbiornik RTV Notebook, PDA VCR Rys Obszary i płaszczyzny konwergencji usług Uwarunkowania techniczne Czynnikiem sprawczym realizacji usług konwergentnych są Sieci Następnej Generacji - NGN (Next Generation Network) i sieci mobilne 3G i 4G/LTE. W najbliższej perspektywie czasowej, w związku z koncepcją Common IMS, oba obszary można już rozważać wspólnie. Sieć NGN jest siecią pakietową umożliwiającą świadczenie usług, w tym usług telekomunikacyjnych i przystosowaną do wykorzystania wielu szerokopasmowych 25

26 technik transportowych zapewniających QoS, w których funkcje związane z realizacją usług są niezależne od używanych technik transportowych. Sieć zapewnia użytkownikom nieograniczony dostęp do różnych usługodawców. Sieć obsługuje także mobilność, która pozwala na spójne i powszechne udostępnianie usług użytkownikom. Zakłada się, że sieć NGN zagwarantuje wszystkim potencjalnym użytkownikom możliwość korzystania zarówno z dotychczasowych usług sieci PSTN/ISDN/IN/GSM, jak i usług dostępnych w sieci IP/Internecie, z zachowaniem, właściwego dla klasycznych sieci, poziomu jakości i niezawodności oraz zapewnienie współpracy różnych typów sieci transportowych. Założenia te determinują podstawowy zbiór wymagań stawiany sieciom NGN: Oddzielenie funkcji sterowania od funkcji transportowych. Przystosowanie płaszczyzny sterowania do świadczenia szerokopasmowych usług multimedialnych dla użytkowników stacjonarnych i ruchomych z zapewnieniem właściwego poziomu niezawodności i dostępności usług. Udostępnianie standardowych styków programistycznych API, które mogą być wykorzystane przez niezależnych usługodawców (Parlay, JAIN). Wyposażenie węzłów sieci w standardowe styki komunikacyjne. Wykorzystanie w warstwie transportowej sieci techniki komutacji pakietów umożliwiającej transportowanie głosu, obrazu i danych z wymaganym poziomem jakości obsługi (QoS). Zapewnienie współpracy z tradycyjnymi sieciami opartymi na technice komutacji kanałów. Zapewnienia neutralności w warstwie dostępu. Przyjęte założenia zmieniają zasadniczo model architektoniczny sieci telekomunikacyjnej. Następuje przejście z tradycyjnego modelu wertykalnego, w którym usługi głosowe, transferu danych i nadawcze były realizowane w oddzielnych sieciach, do modelu horyzontalnego warstwowego NGN, w którym różne usługi wykorzystują wspólną infrastrukturę dostępową, transportową i aplikacyjną. Model horyzontalny stwarza naturalne środowisko do realizacji usług konwergentnych. 26

27 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 3 NGN - czyli telekomunikacja wynajdywana na nowo 3.1. Wprowadzenie Obserwacja rozwoju telekomunikacji w ostatnich kilku dekadach pozwala zauważyć nawroty wielu koncepcji i pomysłów. Stanowi ona dobry punkt wyjścia do rozważań nad bieżącymi trendami ewolucji komunikacji elektronicznej w kontekście powrotu niektórych starych idei w zmienionej formie oraz w związku z pojawianiem się nowych rozwiązań i pomysłów. Konwergencja telekomunikacji, informatyki, Internetu i mediów, w warunkach regulacji prawnych liberalizujących rynek, otworzyły nowe możliwości dla operatorów i usługodawców (również zewnętrznych spoza sektora ICT, nieposiadających infrastruktury sieciowej, takich jak MVNO), co sprawiło, że te same lub zbliżone usługi mogą być oferowane przez podmioty działające wcześniej w odrębnych domenach. Prowadzi to do zaostrzenia konkurencji, która stymuluje wyzwolenie innowacyjności i skutkuje zwiększeniem atrakcyjności oferty usługowej i obniżką cen z punktu widzenia użytkowników. Nawet przeciętny zjadacz chleba zauważa dynamikę zmian, kiedy porówna swój poprzedni telefon komórkowy sprzed 2-3 lat z nowymi, które właśnie pojawiły się na rynku. Wymienione spostrzeżenia zainspirowały powstanie niniejszego eseju i skłoniły autora do powrotu do podstawowego znaczenia terminu komunikacja i spojrzenia świeżym okiem na dzisiejszą telekomunikację, by przeanalizować, na ile jest ona wynajdywana na nowo, w sensie zarówno pragmatyczno-użytkowym jak i technicznym. Komunikacja, w potocznym rozumieniu, jest jednym z najważniejszych aspektów naszego życia, cywilizacji i gospodarki. Trudno sobie wyobrazić życie, czy funkcjonowanie jakiejkolwiek społeczności bez komunikacji. Najprościej i potocznie, komunikacja, to proces wymiany informacji między jej uczestnikami. Według Charlesa Cooleya przez komunikowanie rozumie się mechanizm, dzięki któremu ludzkie stosunki mogą istnieć i rozwijać się, tj. wszystkie symbole umysłu, łącznie z środkami przekazywania ich w przestrzeni i zachowania w czasie. Obejmuje ono wyraz twarzy, postawę i gestykulacje, tony głosu, słowa, pismo, druk, koleje żelazne, telegrafy, telefony, oraz to, co jeszcze może być osiągnięciem w podboju przestrzeni i czasu. Etymologicznie pojęcie komunikowanie wywodzi się z łacińskiego czasownika - communico, communicare, co oznacza: uczynić wspólnym, połączyć, udzielić komuś wiadomości, naradzać się i rzeczownika - communio, oznaczającego wspólność, poczucie łączności. Do XVI wieku pojęcie to oznaczało uczestnictwo, dzielenie się i dopiero wówczas wprowadzono drugie, nowe znaczenie transmisja, przekaz, co było związane się z rozwojem usług pocztowych i sieci dróg. Współcześnie rozróżnia się bardzo wiele definicji komunikowania. Klaus Marten przeprowadził analizę 160 definicji komunikowania różnych autorów. Wynika z niej, że termin komunikacja może być interpretowany następująco: Komunikowanie jako transmisja. Komunikowanie to przekaz informacji, idei, uczuć, umiejętności itp., za pośrednictwem symboli. Komunikowanie to także przepływ informacji lub wiadomości od nadawcy do odbiorcy. Komunikowanie jako rozumienie. Komunikowanie jest procesem, dzięki któremu rozumiemy innych i z kolei sami staramy się być zrozumianymi. Jeżeli komunikowanie ma dojść do skutku, muszą być spełnione m.in. następujące warunki: 1. Istnieje nadawca, 2. Następuje przekaz, 27

28 3. Dostępny jest kanał komunikacji, 4. Istnieje odbiorca i zapewniona jest uwaga ze strony odbiorcy, 5. Ustalono wspólny język, 6. Zaplanowano czas potrzebny na dokonanie się całego procesu oraz 7. Istnieje cel lub cele którym ma ono służyć. Komunikowanie jako oddziaływanie. Komunikowanie realizuje się za pomocą znaków, dzięki którym organizm oddziaływuje na zachowanie innego organizmu. Proces, w toku którego jednostka (nadawca) przekazuje bodźce (zazwyczaj symbole werbalne), aby spowodować zmianę w zachowaniu innych jednostek (odbiorców). Komunikowanie jako łączenie (tworzenie wspólnoty). Komunikować się to tworzyć mniej lub bardziej trwałe wspólnoty międzyludzkie. Komunikacja to wspólny wysiłek nadawcy i odbiorcy zmierzający do poszerzenia obszaru wspólnych im idei, wrażeń i doświadczeń. Komunikowanie jako interakcja. Interakcja społeczna za pośrednictwem symboli i komunikatów. Komunikacja oznacza kontakt człowieka z człowiekiem. Komunikowanie jako wymiana. Wymiana znaczeń między ludźmi jest możliwa w stopniu, w jakim jednostki mają wspólne postrzeżenia, pragnienia i postawy". Komunikacja istnieje, jeżeli symbol ma to samo znaczenie dla wszystkich jednostek wchodzących w grę. Komunikowanie jako składnik procesu społecznego. Akt komunikatywny jest środkiem, przez który są wyrażane normy grupowe, sprawowana kontrola społeczna, przydzielane role, osiągnięta koordynacja wysiłków, są ujawniane oczekiwania i przenoszony proces społeczny. Społeczeństwo nie tylko trwa dzięki komunikowaniu, ale w istocie można powiedzieć, że istnieje poprzez przekazywanie, poprzez komunikowanie. Rys.3.1 Komunikowanie - interpretacje Rozważając komunikację należy również wziąć pod uwagę model przepływu informacji. Typowo wyróżnia się następujące rodzaje przepływu informacji: Alokucja. Przekaz głównie jednokierunkowy, z niewielką możliwością sprzężenia zwrotnego (np. wykład akademicki, kazanie, przemowa). W modelu tym informacja rozchodzi się równocześnie od centrum do wielu odbiorców peryferyjnych. Nadawca zajmuje pozycję uprzywilejowaną. 28

29 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Konwersacja. Jednostki oddziałują bezpośrednio na siebie, pomijając centrum albo pośredników. Samodzielnie dokonują wyboru partnera, czasu, miejsca i tematu komunikowania i są równouprawnieni. Konsultacja. Uczestnik poszukuje informacji w centrum informacyjnym, np. bazie danych, bibliotece, encyklopedii. Czas miejsce oraz temat wybiera Odbiorca Rejestracja. Ośrodek centralny żąda od odbiorców (często bez ich zgody) podawania określonych informacji. Służy ona do tworzenia spisów, baz danych, kontroli itp. (np. rejestracja rozmów telefonicznych, pomiar liczności audytoriów telewizyjnych). 29

30 Rys.3.2 Telekomunikacja jako narzędzie komunikowania się próba taksonomii 30

31 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 3.2. Korzenie komunikacji i ewolucja ku NGN Przytoczona analiza dotycząca spektrum znaczeń i interpretacji pojęcia komunikacja przygotowały grunt do dalszych rozważań nad obecnym rozumieniem terminu telekomunikacja. Zwraca się uwagę, że coraz częściej, w związku z postępującym procesem konwergencji sieci telekomunikacyjnych, Internetu i mediów używa się terminu komunikacja elektroniczna zamiast telekomunikacja. W dalszym ciągu będziemy jednak posługiwać się terminem telekomunikacja w sposób rozszerzony, który obejmuje również zakresem zarówno szeroko rozumianą klasyczną telekomunikację jak i komunikację elektroniczną. Według wąskiej definicji, telekomunikacja, to dziedzina techniki i nauki, zajmująca się transmisją wszelkiego rodzaju informacji na odległość. Telekomunikacja to także termin prawny, którego definicja zawarta jest w prawie telekomunikacyjnym. Według tej definicji telekomunikacja to nadawanie, odbiór lub transmisja informacji, niezależnie od ich rodzaju, za pomocą przewodów, fal radiowych bądź optycznych lub innych środków wykorzystujących energię elektromagnetyczną. Biorąc pod uwagę rozważania dotyczące terminu komunikacja przyjmiemy roboczą definicję telekomunikacji, jako komunikacji na odległość, w szerokim, opisanym wcześniej sensie. Dzięki temu, tak rozumiana telekomunikacja, uwzględnia aspekt społecznościowy, semantyczny i kontekstowy, które pojawiły się w związku z łączeniem koncepcji Web 2.0 i Web 3.0 z usługami telekomunikacyjnymi. Uwzględnia ona także znaczenie intuicyjnego interfejsu użytkownika (np. ekrany dotykowe) oraz łączenie rozproszonych treści z różnych źródeł w jednej aplikacji (ang. mash-up). Można, zatem uważać, że nowe koncepcje związane z rozwojem nowej generacji Internetu i sieci NGN realizują ideę powrotu do źródeł komunikowania się w pierwotnym sensie tego pojęcia, z tą różnicą, w stosunku do klasycznej definicji, że obejmują również sferę wirtualną. Niniejsze spostrzeżenie może stanowić wartościową wskazówkę przy projektowaniu nowych usług telekomunikacyjnych i stanowić stymulator innowacyjności. Analizując wizję uniwersalnej sieci NGN opartą na adaptacji architektury usługowej Common IMS można zauważyć, że pewne zręby tej koncepcji powstały w latach 70., 80. i 90. Tymi kluczowymi czynnikami sprawczymi budującymi przyszłość sieci i usług telekomunikacyjnych były: Pełna cyfryzacja sieci Mobilność Szerokopasmowość Integracja sieci i usług Elastyczność scenariuszy usług Stopniowe otwieranie sieci i platform usługowych Ewolucja Internetu Liberalizacja rynku telekomunikacyjnego Idea integracji usług, w pełni cyfrowej sieci i konwergencji trybu komutacji łączy i trybu pakietowego pojawiła się w koncepcji sieci ISDN, której założenia i rozwiązania konstrukcyjne zostały opracowane w pierwszej połowie lat osiemdziesiątych. Stanowiła ona pierwszą udaną całościową próbę integracji usług przekazywania głosu i danych. Początkowo rozwój sieci ISDN przebiegał w sposób znacznie wolniejszy od oczekiwań. Zasadność rozwiązania technicznego podważano przez rozpowszechnianie ironicznej 31

32 interpretacji akronimu ISDN, jako Integration Subcribers Don t Need czy It Still Does Nothing. Dopiero od połowy lat dziewięćdziesiątych można zaobserwować znaczący wzrost liczby abonentów ISDN, przede wszystkim w krajach europejskich. Rozwojowi ISDN w Europie sprzyjała stabilna i precyzyjna normalizacja (normy ETSI i zalecenia ITU-T) oraz współdziałanie operatorów w ramach IMIMG, które doprowadziło do uzgodnienia, na poziomie międzynarodowym, podstawowego profilu usług określanego potocznie jako Euro-ISDN. Dzięki temu został stworzony rynek usług, terminali i aplikacji ISDN oraz podstawy dla współpracy operatorów na poziomie krajowym i międzynarodowym. Koncepcja ISDN stanowiła etap ewolucji sieci telefonicznej stymulowany postępem technicznym, przede wszystkim, w dziedzinie cyfryzacji sieci (komutacja, transmisja cyfrowa obejmująca także dostęp abonencki, wspólnokanałowy system sygnalizacji SS7) i urządzeń końcowych. Sygnalizacja, model usług i wiele rozwiązań technicznych zostało wykorzystanych w normalizacji sieci GSM, którą można w pewnym sensie traktować jako mobilny ISDN. Na przykład, mechanizm przesyłania krótkich wiadomości tekstowych, który w GSM zyskał wielką popularność jako usługa SMS, został wprowadzony w ISDN. Kolejnym etapem rozwoju ISDN była wizja szerokopasmowej sieci ISDN, czyli B-ISDN (ang. Broadband Integrated Services Digital Network) opartej na protokole ATM, która była uważana za uniwersalną architekturę przyszłych sieci multimedialnych. Jednak z uwagi na wiele wad protokołu ATM, w tym ukierunkowanie przede wszystkim na tryb połączeniowy i zbyt ograniczony model, w kontekście ewolucji sieci i rosnącej popularności i łatwości implementacji aplikacji wykorzystujących Internet i stos protokołów TCP/IP, koncepcja B-ISDN została zarzucona. Zapoczątkowana w 1984 roku w Stanach Zjednoczonych liberalizacja rynku telekomunikacyjnego była jednym z istotnych czynników opracowania przez firmę Bellcore koncepcji Sieci Inteligentnej IN (ang. Intelligent Network), która stała się kamieniem milowym w rozwoju usług. Koncepcja IN wprowadziła nową jakość otwarty elastyczny zbiór usług i funkcji usługowych, które uwzględniają kontekst komunikacji i mogą być indywidualnie dostosowywane do wymagań poszczególnych abonentów, oraz nowy model ich implementacji i udostępniania. Kluczową innowacyjną ideą IN była separacja funkcji sterowania elastycznymi scenariuszami zgłoszeń, realizowanymi przez platformę usługową IN - SCP (ang. Service Control Point), od funkcji komutacyjnych wykonywanych przez centrale węzły SSP (ang. Service Switching Points) tworzące wspólnie infrastrukturę sieci IN. Wprowadzono w ten sposób rozproszoną realizację usług, która polegała na mechanizmie transakcyjnego zawieszania i wznawiania podstawowego procesu obsługi połączenia, który komunikował się za pomocą wiadomości sygnalizacyjnych protokołu INAP z zewnętrznym scenariuszem usługi, zlokalizowanym w SCP. Bardzo ważną cechą modelu koncepcyjnego IN, było wyróżnienie płaszczyzn reprezentujących sieć inteligentną w postaci hierarchii płaszczyzn abstrakcji i rozróżnienie architektury funkcjonalnej od architektury fizycznej. Globalna Płaszczyzna Funkcjonalna GFP (ang. Global Functional Plane), reprezentująca IN w modelu koncepcyjnym z punktu widzenia projektanta usług, wprowadziła poziom abstrakcji pozwalający rozważać scenariusze usług w oderwaniu od fizycznej architektury sieciowej, w której są one realizowane. Ponieważ styk między klasyczną siecią telekomunikacyjną a platformą usługową jest realizowany za pomocą części aplikacyjnych systemu sygnalizacji SS7 stworzyło to możliwość zastosowania filozofii IN nie tylko w sieci stacjonarnej, ale również w sieciach mobilnych. W obu przypadkach podejście do projektowania usług jest takie samo wykorzystywane jest wspomagające graficzne środowisko programistyczne SCE (ang. Service Creation Environment), w którym scenariusze nowych usług są konstruowane z odpowiedniego 32

33 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS zestawu uniwersalnych modułów usługowych - SIB (ang. Service Independent building Blocks), a następnie poddawane symulacji, testowaniu i weryfikacji, aby finalnie wygenerować kod i udostępnić usługi na platformie usługowej SCP. Koncepcja IN była na tyle atrakcyjna, że została zaadoptowana do potrzeb sieci mobilnej GSM i UMTS jako znormalizowane rozwiązanie określane akronimem CAMEL (ang. Customized Applications for Mobile Network Enhanced Logic). W ten sposób został osiągnięty etap rozwoju, na którym usługi telekomunikacyjne były już projektowane i implementowane tak jak aplikacje informatyczne i operator, posiadający SCE, mógł potencjalnie samodzielnie opracowywać scenariusze nowych usług. Fakt ten był podkreślany przez dostawców jako jedna z wielu zalet rozwiązań IN. Jednak, w rzeczywistości, możliwość ta była dość iluzoryczna z uwagi na uwarunkowania techniczne i kwestię wzięcia odpowiedzialności za prawidłowe działanie usług. Ponadto istotnym ograniczeniem IN było związanie SCE z platformą SCP dostawcy i wynikająca stąd nieprzenaszalność scenariuszy usług pomiędzy platformami usługowymi pochodzącymi od różnych producentów. Konsekwencją tego stanu rzeczy było utrzymywanie modelu rynku, w którym operator właściciel infrastruktury sieciowej i platform usługowych występuje jednocześnie w roli usługodawcy. Brak otwartego interfejsu programistycznego API (ang. Application Programming Interface) stanowił główną techniczną przeszkodę oddzielenia ról usługodawcy i operatora dla usług zaawansowanych, wykraczających poza podstawowe usługi telefoniczne i klasyczne usługi audioteksowe. Czynnikiem sprzyjającym różnorodności i bogactwu aplikacji i usług był nowy kształt regulacji prawnych liberalizujących rynek łączności elektronicznej (por. dyrektywy UE z 2002 roku). Tworzą one otwarty model rynku, który pozwala na świadczenie usług bez konieczności posiadania pełnej infrastruktury sieciowej model operatora sieci wirtualnej - VNO (ang. Virtual Network Operator) i MVNO (ang. Mobile Virtual Network Operator). Otwarcie rynku zostało wymuszone na poziomie fizycznym. Towarzyszyło temu równoległe otwarcie rynku na poziomie logicznym dzięki technicznej koncepcji znormalizowanych API eksponujących w bezpieczny i strukturalny sposób funkcjonalność platform usługowych zainstalowanych w sieci operatora. Ekspozycja poprzez API mogła być wykorzystana zarówno przez usługodawców trzecich jak i samego operatora. Parlay/OSA API definiuje architekturę, która umożliwia twórcom usług i aplikacji dostęp do zasobów i funkcjonalności sieci telekomunikacyjnej operatora poprzez znormalizowany zestaw interfejsów programistycznych. Parlay/OSA API przedstawia abstrakcję dla zbioru protokołów. Celem Parlay/OSA API było przesłonięcie złożoności sieci, stosowanych w nich protokołów zawierających specyficzne dla dostawców rozwiązania implementacyjne, przed zewnętrznymi aplikacjami. Oznacza to, że aplikacje nie muszą znać struktury sieci wykorzystywanej przez serwer usług zapewniający wymaganą przez nie funkcjonalność. W ten sposób sieć i stosowane w niej protokoły mogą być w dużym stopniu przezroczyste dla aplikacji. Sposób myślenia związany z prezentacją możliwości i funkcjonalności sieci po przez API jest znany doskonale programistom. Propagowanie opisanego modelu programistycznego zwiększa rzeszę potencjalnych twórców usług telekomunikacyjnych. Pojawienie się techniki Usług Sieciowych (ang. Web Services) stanowiło inspirację dla uproszczenia Parlay/OSA API i powstania zmodyfikowanego interfejsu Parlay X, który pozwala implementować usługi telekomunikacyjne i integrować je z aplikacjami informatycznymi za pomocą rozpowszechnionych w świecie IT typowych środowisk programistycznych wykorzystujących język Java (np.: Borland JBuilder, IBM Websphere czy BEA Weblogic). Interfejs Parlay X pozwala operatorom eksponować funkcjonalność sieci telekomunikacyjnych stacjonarnych i mobilnych, co pozwala na 33

34 jej wykorzystanie do tworzenia nowych usług bądź integracji z własnymi aplikacjami przez strony trzecie niezależnych usługodawców i integratorów systemów. Sprawiło to, że projektowanie i implementacja usług telekomunikacyjnych stały się dostępne na masową skalę dla zwykłych programistów NGN, IMS i Internet Bardzo ważnym zdarzeniem, które miało przełomowe znaczenie dla rozwoju innowacyjnych usług telekomunikacyjnych, podobne do tego, które spowodował protokół HTTP i idea WWW, było opracowanie protokołu SIP (ang. Session Initiation Protocol). Protokół ten stanowiący, w pewnym sensie, rozwinięcie HTTP definiuje znormalizowane mechanizmy służące do organizowania sesji multimedialnych w Internecie i sieciach IP, a także implementacji usług hybrydowych obejmujących sieci IP/Internet, sieci PSTN/IN i sieci mobilne. Zwięźle charakteryzując możliwości protokołu SIP można powiedzieć, że pozwala implementować nowe usługi telekomunikacyjne, dla których dostępna jest pełna funkcjonalność Internetu i które pozwalają wykorzystać takie atrybuty sieci IP jak stałe dołączenie do sieci i możliwość dystrybucji informacji o obecności i statusie dostępności użytkowników. Dzięki temu możliwe są takie usługi jak inicjowanie komunikacji przez wybranie odsyłacza (ang. Click-to-Call,) w trybie, np. głosowym lub wiadomości natychmiastowych, wynikającym z informacji o bieżącym statusie dostępności użytkownika. Zaadaptowana wersja protokołu SIP stała się podstawą dla architektury usługowej IMS jako mechanizmu sterowania multimedialnymi sesjami komunikacyjnymi. Architektura IMS została zdefiniowana przez 3GPP jako nakładkowa architektura usługowa, która umożliwia implementację i udostępnianie otwartego zestawu zintegrowanych usług multimedialnych łączących telefonię, VoIP, dostarczanie multimedialnych treści, korzystanie z Internetu, audio i wideokonferencję, pocztę elektroniczną, wymianę wiadomości natychmiastowych, IPTV w oparciu różne techniki sieci telekomunikacyjnych NGN a w szczególności UMTS. Przy opracowywaniu IMS wykorzystano głównie sprawdzone protokoły internetowe, zdefiniowane przez IETF (SIP, DIAMETER, COPS), które w ramach prac normalizacyjnych prowadzonych przez 3GPP rozszerzono o funkcje związane z wymaganiami telekomunikacyjnymi mechanizmy taryfikacji, realizacji polityk QoS i zapewnienia bezpieczeństwa. Zdefiniowano także architekturę funkcjonalną złożoną z serwerów SIP, serwerów aplikacji, bazy danych użytkowników HSS, serwerów medialnych z sterownikami oraz bram, które umożliwiają nawiązywanie, modyfikację i kończenie sesji multimedialnych w środowisku sieci mobilnej. Podstawowa architektura IMS została przedstawiona na Rys.3.3. Serwery SIP CSCF (ang. Call State Control Function) są rozróżniane przez przypisane im funkcje, odpowiednio: P-CSCF (ang. Proxy CSCF), I-CSCF (ang. Interrogating CSCF), S-CSCF (ang. Serving CSCF) i odpowiadają za sterowanie sesjami i współpracują z HSS przy realizacji funkcji identyfikacji, uwierzytelniania i rozliczania (AAA). Serwery aplikacji są miejscem, w którym zlokalizowane są scenariusze usług i aplikacji. Serwery aplikacyjne mogą być implementowane jako serwery aplikacji SIP, jak również, w celu zachowania ciągłości dotychczasowych usług, jako serwery Parlay OSA API i platformy CAMEL CSE, za pośrednictwem odpowiedniego elementu adaptującego do interfejsu sterującego ISC operującego protokołem SIP. Zwraca się uwagę, że z technicznego punktu widzenia architektura IMS jest otwarta i usługi mogą być świadczone przez serwery aplikacji zlokalizowane w sieci macierzystej, sieci wizytowanej lub w innej domenie, np. zewnętrznego usługodawcy. Stanowi to rozszerzenie możliwości dotychczas dostępnych dla stron trzecich świadczących usługi telekomunikacyjne. W szczególności stanowi to techniczną podstawę znacznego wzbogacenia możliwości modeli MVNO i MVNE. 34

35 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Usługi IMS nie są ograniczone do usług opartych na bezpośrednich wykorzystaniu funkcjonalności protokołu SIP. Możliwe jest także świadczenie usług wykorzystujących rozwiązania już stosowane przez operatorów telekomunikacyjnych. Alternatywnymi sposobami realizacji serwerów aplikacyjnych w architekturze IMS (por. Rys.3.3) są: platforma sieci inteligentnej CSE i architektura CAMEL oparta na protokołach SS7 MAP i CAP CAMEL oraz architektura OSA (ang. Open Service Architecture) wykorzystująca znormalizowane interfejsy Parlay OSA API. Płaszczyzna Aplikacji SIP AS SIP AS Parlay API Parlay AS OSA GW CAMEL CSE CAP API IM SSF Płaszczyzna sterowania HSS P-CSCF I-CSCF S-CSCF MRFC Płaszczyzna użytkownika RTP MRFP RTP B-GW SIP H.248 / MEGACO Diameter RTP PSTN Rys.3.3. Architektura funkcjonalna IMS z uwzględnieniem różnych wariantów implementacji AS Wyróżniono trzy typy serwerów aplikacji, przy czym z punktu widzenia architektury IMS, wszystkie zachowują się tak jak serwer SIP AS i wykorzystują interfejs ISC i protokół SIP w wersji 3GPP. o o Serwer aplikacyjny SIP (SIP AS). SIP AS jest podstawowym rodzajem serwera w architekturze IMS świadczącym usługi SIP, takie jak: obecność, konferencje, wymiana wiadomości. Opcjonalnie serwer ten może posiadać interfejs Sh z bazą danych HSS, pod warunkiem, że AS znajduje się w sieci operatora macierzystego. Interfejs Sh oparty jest na protokole DIAMETER i pełni funkcje uwierzytelniania, autoryzacji i taryfikacji. Serwer Parlay/OSA API. Open Service Architecture Service Capability Server (OSA-SCS). OSA-SCS stanowi bramę dla usług Parlay/OSA w IMS. Z jednej strony OSA-SCS posiada interfejs do serwera OSA Application Server, a z drugiej interfejs SIP ISC do S-CSCF. Opcjonalnie OSA-SCS może mieć interfejs Sh z bazą danych HSS. OSA-SCS znajduje się w sieci operatora, jednak serwer OSA AS może znajdować się u strony trzeciej. 35

36 o Serwer IN CAMEL (IP Multimedia Service Switching Function (IM-SSF). Serwer pozwala na przeniesienie do IMS wielu usług zaimplementowanych w środowisku CAMEL i działających w systemie GSM. IM-SSF po stronie IMS dostępny jest przez interfejs SIP, czyli ISC, natomiast z zewnątrz współpracuje przez interfejs CAP. IM-SSF posiada także interfejs z HSS - Si, oparty na protokole MAP. Jak wiadomo, początkowa wersja architektury usługowej IMS została zdefiniowana dla sieci mobilnej 3G i pojawiła się jako część normalizacji UMTS, począwszy od Release 5. W UMTS Release 6, która stała się podstawą prac ETSI i ITU-T nad adaptacją IMS do potrzeb sieci NGN obejmującej użytkowników stacjonarnych z dostępem przewodowym (xdsl, FTTx, CATV) i bezprzewodowym (WiFi, WiMax), wprowadzono kolejne zmiany i rozszerzenia, przede wszystkim, z punktu widzenia wymagań sieci mobilnej 3G. Równolegle 3GPP rozszerzyła zakres UMTS IMS o kwestię uniwersalności dostępowej (WiFi, WiMax, xdsl, FTTx, itd.). W kolejnych wersjach UMTS, sfinalizowanej w 2007 roku Release 7 i będącej w trakcie opracowywania Release 8, 3GPP i ETSI uzgodniły przyjęcie wspólnej definicji IMS i przeniesienie prac z ETSI TISPAN do 3GPP. Docelowo wspólna norma Common IMS zostanie zdefiniowana przez 3GPP, we współpracy z ETSI TISPAN i ITU-T NGN GSI jako część UMTS Release 8. Na Rys.2.4 przedstawiono architekturę Common IMS. Jednocześnie też podjęto w ETSI ITU-T nad poszerzeniem zakresu zastosowań architektury usługowej IMS o usługi IPTV i sterowania elektronicznym wyposażeniem domu idea Bramy Domowej (ang. Home Gateway). Typowa lista usług IPTV oferowana za pomocą platformy IMS wprowadza możliwość łączenia cyfrowej telewizji z usługami telekomunikacyjnymi i dostępem do Internetu, co wnosi nową wartość. Przykładowymi usługami tego typu są: o o o o o o o o o IPTV + VoIP: oglądanie TV z możliwością jednoczesnej rozmowy. IPTV + IMP: informacja o statusie znajomych czy są obecni i dostępni i co oglądają oraz możliwość wymiany wiadomości natychmiastowych. Możliwość wyboru programu lub treści oglądanych przez znajomego. Możliwość zaproponowania znajomemu programu lub treści. Click-to-dial z TV: reakcja w grze lub odpowiedź na reklamę. Teległosowanie lub interakcja w trakcie trwania programu TV. Identyfikacja wywołującego na ekranie TV: akceptacja bądź odrzucenie połączenia. Przekazywanie połączeń w trakcie oglądania TV. Dostęp do treści wytworzonych przez użytkowników (np. YouTube). Na Rys. 3.4 przedstawiono wizję sieci NGN opartej na architekturze Common IMS. W pierwotnym zamierzeniu oparcie IMS i później docelowej NGN, w dużym stopniu, na normach internetowych IETF miało być krokiem w kierunku uproszczenia architektury i protokołów. Jednak rzeczywistość ujawnia niepokojący obraz. Liczba dokumentów normalizacyjnych ich objętość i wzajemne powiązania i uwikłania sprawiają, że coraz trudniej panować nad całością. Zjawisko to ilustruje diagram pokazujący objętość dokumentów normalizacyjnych IETF dotyczących VoIP i protokołu SIP (por. Rys.3.5). 36

37 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Common IMS 3GPP Sieć szkieletowa WiMax Sieć szkieletowa DSL Sieć szkieletowa Kablowa sieć pakietowa Funkcje dostępu brzegowego UTRAN LTE I-WLAN Sieć dostępowa Sieć dostępowa Sieć dostępowa xdsl Sieć dostępowa FTTH Sieć dostępowa DOCSIS Sieć dostępowa Rys. 3.4 Wizja Common IMS jako docelowej uniwersalnej architektury sieci NGN Rys.3.5 Przyrost objętości (liczba stron) dokumentów normalizacyjnych IETF dotyczących protokołu SIP i VoIP (źródło: 37

38 Telekomunikacja Internet API funkcjonalne: Idea wzbogacania i konwergencji sieci i usług: Parlay OSA API Parlay X JAIN API API aplikacyjne: Idea wbudowania funkcji telekomunikacyjnych w aplikacje konwergencja Rys.3.6 Telekomunikacja i Internet zderzenie paradygmatów usługowych PDA PC TV Komunikacja Osoba-Obiekt Pojazdy Urządzenia domowe Znaczniki RFID Czujniki Kamery NGN Bazy danych, Internet, serwery aplikacyjne Komunikacja Obiekt-Obiekt PC jako część odzieży Serwer domowy, brama telefon komórkowy Komunikacja Osoba-Obiekt Smart Card Telematyka, urządzenia nawigacyjne Urządzenia medyczne Ludzie z urządzeniami komunikacyjnymi Powszechna komunikacja sieciowa Obiekty (zdalny monitoring i urządzenia informacyjne) Rys.3.7 Wizja powszechnej komunikacji w NGN 38

39 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 3.4. NGN i Web x.0 Architektura usługowa IMS jest wykorzystywana przez wielu operatorów do wdrażania nowej generacji usług łączących funkcjonalność Internetu i sieci telekomunikacyjnych. W przypadku sieci stacjonarnych są to bogate usługi VoIP uwzględniające kontekst komunikacji, a w sieciach mobilnych usługi wykorzystujące lokalizację i wymiar społecznościowy. W praktyce prowadzi do potrzeby integracji aplikacji internetowych, takich jak np. Facebook i Google Maps z usługami telekomunikacyjnymi. Rodzi to potrzebę uwzględnienia w projektowaniu i implementacji usług nie tylko API udostępnianych przez telekomunikacyjne platformy usługowe, ale i aplikacje sieciowe z domeny internetowej. W ten sposób pojawiła się potrzeba integracji aplikacji kategorii Web 2.0 z usługami telekomunikacyjnymi. Reprezentuje ona dwa różne podejścia: o o Internetowe, które polega na idei wbudowywania funkcjonalności telekomunikacyjnej (np. komunikacji głosowej, SMS, wymiany wiadomości natychmiastowych, obecności) w aplikacje internetowe Web 2.0, takie jak np. Facebook. Tradycyjne, które polega na dodawaniu do usług telekomunikacyjnych mechanizmów internetowych. Opisane podejścia mają charakter komplementarny, ale operatorzy telekomunikacyjni dostrzegli i docenili znaczenie podejścia internetowego. Jego konsekwencją było udostępnienie przez wielu operatorów swoich zasobów sieciowych zewnętrznym projektantom usług za pomocą nowych API. Przykładem tego typu działań są następujące programy: BT Ribbit, O2 Litmus, Vodafone Betavine, Orange Partner, DT Developer Garden, Telefonica WIMS 2.0. Na przykład DT, w ramach programu Developer Garden udostępnia następujące możliwości swoich sieci stacjonarnej i mobilnej: o o o o o Sterowanie połączeniami głosowymi. Wysyłanie wiadomości SMS. Planowanie i sterowanie połączeniami konferencyjnymi Przybliżona lokalizacja geograficzna adresów IP Lokalne wyszukiwanie możliwość integracji z własną stroną internetową. Interfejsy API w programie DT Developer Garden mogą być używane za pomocą technik REST i SOAP. Dostępne są również środowiska projektowe SDK (ang. Service Development Kit) dla najpopularniejszych języków programowania (Java) oraz bieżący dostęp do pomocy techniczneji i forum projektantów Podsumowanie Perspektywa wdrażania usług NGN opiera się na łączeniu doświadczenia tradycyjnej telekomunikacji z aplikacjami internetowymi reprezentującymi ciągle pojawiające się nowe idee, z których największe znaczenie mają uwzględnienie szeroko rozumianego kontekstu komunikacji obejmującego: obecność, dostępność, gotowość do komunikacji, lokalizację, aspekt społecznościowy (m.in. komunikacja grupowa, współdzielenie i tworzenie treści, własna taksonomia folksonomia). Widoczna jest także tendencja do mobilnego i jednolitego modelu korzystania ze wszystkich usług, niezależnie od lokalizacji i rodzaju dostępu oraz konwergencji usług, która ma różne oblicza (por. Rys.2.6 i 2.7). W związku nową wizją usług pojawia się naturalna potrzeba do sięgnięcia do korzeni pojęcia komunikacja, ponieważ dzięki postępowi technicznemu i konkurencji na rynku jesteśmy świadkami wynajdywania 39

40 telekomunikacji na nowo, jako komunikowania w szerokim sensie, w wymiarze wirtualnym. Można też powiedzieć, że w pewnym sensie techniczna strona komunikacji staje się przezroczysta dzięki powszechnej dostępności usług i coraz częstszym wbudowaniu ( ukrywaniu ) funkcjonalności telekomunikacyjnej w aplikacjach służących szeroko rozumianemu komunikowaniu się, z uwzględnieniem wymiaru społecznego, którego krótką analizę przedstawiono na wstępie. 40

41 4 Normalizacja usług, protokołów i architektury NGN 4.1. Wprowadzenie Z uwagi na szeroki zakres tematyczny, uwarunkowania historyczne i współzależność problematyki sieci stacjonarnych i mobilnych prace normalizacyjne dotyczące NGN są prowadzone zarówno przez oficjalne instytucje normalizacyjne jak również przez organizacje i stowarzyszenia operatorów, usługodawców i dostawców rozwiązań. Prace te są często koordynowane wzajemnie, ale również zdarza się, że sie dublują czy idą w różnych kierunkach. Na Rys. 4.1 przedstawiono mapę drogową normalizacji i relacje pomiędzy obszarami działań poszczególnych organizacji normalizacyjnych.. Szczególne znaczenie mają uzgodnienia między 3GPP, ETSI i ITU-T w zakresie architektury usługowej IMS i przyjęcia wspólnego modelu architektonicznego, protokołów i realizacji usług dla docelowej uniwersalnej sieci NGN. Jak wiadomo, początkowa wersja architektury usługowej IMS została zdefiniowana dla sieci mobilnej 3G i pojawiła się jako część normalizacji UMTS, począwszy od Release 5. W UMTS Release 6, która stała się podstawą prac ETSI i ITU-T nad adaptacją IMS do potrzeb sieci NGN obejmującej użytkowników stacjonarnych z dostępem przewodowym (xdsl, FTTx, CATV) i bezprzewodowym (WiFi, WiMax), wprowadzono kolejne zmiany i rozszerzenia, przede wszystkim, z punktu widzenia wymagań sieci mobilnej 3G. Równolegle 3GPP rozszerzyła zakres UMTS IMS o kwestię uniwersalności dostępowej (WiFi, WiMax, xdsl, FTTx, itd.). W kolejnych wersjach UMTS, sfinalizowanej w 2007 roku Release 7 i Release 8, 3GPP i ETSI uzgodniły przyjęcie wspólnej definicji IMS i przeniesienie prac z ETSI TISPAN do 3GPP. Docelowo wspólna norma Common IMS została zdefiniowana przez 3GPP, we współpracy z ETSI TISPAN i ITU-T NGN GSI jako część UMTS Release 8. Rys.4.1 Mapa drogowa normalizacji NGN

42 R 99 R 4 R 5 R 6 R 7 R 8 Definicja UTRAN Podstawowe funkcje usługowe 3G Podstawa dla wczesnych wdrożeń sieci 3G Separacja płaszczyzn sterowania i użytkownika w sieci szkieletowej Pierwsze kroki ku oparciu działania na IP Architektura IMS Usługi multimedialne wykorzystujące IP Dostęp HSDPA Druga faza IMS Dostęp HSUPA Wiele nowych funkcji usługowych realizujących w pełni założenia sieci 3G Uwzględnienie przewodowego dost. szerokopasmowego Zachowanie ciagłości połączenia (Voice Call Continuity) Usługi multimedialne wykorzystujące IMS Common IMS 12/1999 3/2001 3/ / Wprowadzenie IMS Rok R Szczegółowa definicja architektury Podstawowe usługi OSS, dane użytk.ngn, kontrola przeciążeń, QoS, bezpieczeństwo R 2 12/2007 Emulacja PSTN/ISDN Usługi dostarczania treści: IPTV, strumieniowanie,.. Optymalizacja wykorzystania zasobów Konsolidacja VoIP Ewolucja usług IPTV,.. Ultra szerokopasmowy dostęp do NGN Współpraca z sieciami NGN - IMS i nie-ims R 3 Rys.4.2 Współzależność wersji architektur 3GPP IMS i ETSI TISPAN NGN 4.2. Standaryzacja architektury NGN w ITU-T ITU-T rozpoczęła prace standaryzacyjne nad koncepcją NGN w 2002 r. Od połowy 2004 do końca 2005 r koordynowała je grupa NGN Focus Group (FG NGN) w ramach Grupy Studiów SG13 (Study Group 13), która składała się z 7 grup roboczych WG (Working Group) i stworzyła szereg dokumentów, włączonych później do dalszych prac odpowiednich zespołów SG. Następnie, prace te były kontynuowane od listopada 2005 w ramach nowej grupy pod nazwą NGN-GSI (NGN Global Standard Initiative) obejmującej Grupy Studiów SG 11 (Signalling requirements and protocols), SG 13 ( NGN) i SG 19 (Mobile telecom networks). W połowie 2007 roku podjęto decyzję o koordynacji prac dotyczących NGN z 3GPP i wyynikające z niej działania dotyczące specyfikacji wspólnego modelu architektury IMS Common IMS. Wspólna architektura IMS została włączona do 3GPP UMTS Release 8. Na koniec 2007 roku sformułowano wymagania i zaplanowano na 2009 rok, publikację finalnego standardu. Podstawowe koncepcje sieci NGN według ITU, to: wyraźna separacja warstwy usługowej i transportowej obsługa mobilności użytkowników zdolność sieci do zarządzania zasobami i ich przydziałem do sesji wg zdefiniowanych parametrów QoS obsługa klasycznych terminali i systemów współdziałanie z istniejącymi sieciami przez otwarte interfejsy. 42

43 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Zakres prac standaryzacyjnych, objętych dokumentami FGN GN i później NGN GSI (NGN Release 1), obejmuje: wymagania ogólne na sieć NGN (WG1) wymagania funkcjonalne i architekturę NGN, wymagania na obsługę mobilności użytkowników, system IMS, architekturę podsystemu emulacji usług PSTN/ISDN (WG2) rozwiązania w zakresie QoS dla sieci dostępowych Ethernet/IP (WG3) wymagania sygnalizacyjne dla rozwiązań IP QoS (WG4) wymagania i wskazówki dla implementacji rozwiązań w zakresie bezpieczeństwa i ochrony informacji (WG 5) aspekty ewolucji sieci tradycyjnych do architektury NGN, podsystemy emulacji i symulacji usług PSTN/ISDN w NGN (WG6) Od stycznia 2006 prace nad NGN sa prowadzone pod egidą NGN GSI, wspólnie przez kilka zespołów SG. Ich zakres obejmuje m.in.: usługi i funkcje Release 2 architekturę funkcjonalną i wymagania ogólne zarządzanie mobilnością i konwergencję usług (Fixed/Mobile Convergence) zastosowanie IPv6 w NGN end-to-end QoS sygnalizację NGN wraz z procedurami RAC (Resource Admission Control) aspekty migracji i współdziałania sieci bezpieczeństwo IPTV, sieci domowe, usługi identyfikacji użytkownika, inne. W pierwszej fazie standaryzacji, NGN Release 1 zdefiniowane są głównie wymagania na zaawansowane środowisko usług i infrastruktury NGN, które można podzielić na kilka podstawowych zakresów: architektura i podział funkcjonalny realizacja funkcji QoS zarządzanie siecią NGN obsługa mobilności użytkowników (nomadic services) aplikacje i usługi (obsługa platform usługowych opartych na IN, SIP, OSA/PARLAY itp.) obsługa sieci dostępowych (stacjonarnych: xdsl, linie dzierżawione, optyczne, sieci kablowe, LAN, PLC itp., oraz radiowych: 802.X, 3G - tylko domena PS) wpółdziałanie sieci (NGN między różnymi domenami administracyjnymi oraz NGN z sieciami tradycyjnymi: PSTN/ISDN, PLMN (2G)). 43

44 W zakresie architektury i podziału funkcjonalnego można wyróżnić wymagania odnoszące się do dwóch podstawowych podsystemów: IP Multimedia Service Component szkieletowego systemu sterującego, opartego na rozszerzonej architekturze IMS (IP Multimedia Subsystem), oryginalnie zdefiniowanej dla sieci mobilnych w standardach 3GPP emulacji usług PSTN/ISDN komponentu obsługującego interfejsy dostępowe PSTN/ISDN i zapewniającego realizację (podzbioru) usług PSTN/ISDN w ramach sieci NGN. Usługi zdefiniowane w ramach NGN Release 1 to m.in.: szeroko pojęte usługi multimedialne o o o o o o o o o przekazywanie wiadomości: IM, SMS, MMS push-to-talk sesje multimedialne punkt-punkt: wideotelefonia itp. usługi wsparcia grup roboczych: konferencje multimedialne, praca nad dokumentami, gry sieciowe, nauka sieciowa itp. streaming (audio, video, TV) i dostęp do inych treści (informacje, obrazy itp.) transmisja rozsiewcza (broadcast, multicast) usługi dla biznesu (IP Centrex) usługi informowania o statusie i dostępności abonenta inne emulacja usług PSTN/ISDN (obsługa tradycyjnych terminali i usług w sieci NGN) symulacja usług PSTN/ISDN (odtworzenie usług PSTN/ISDN dla terminali NGN) usługi publiczne (Lawful Call Interception - uprawniony przechwyt), identyfikacja uzytkownika, połączenia alarmowe, wybór operatora, przenoszenie numeru itp.) inne usługi typowe dla sieci pakietowych ( , transfer plików, www, handel elektroniczny, sieci sensorów, telemetria itp.). zachowanie ciągłości sesji usługowych i usług przy przejściu między różnymi typami sieci dostępowych. W Tabeli 4.1 zestawiono główne normy ITU-T dotyczące NGN. Tabela 4.1 Normalizacja NGN w ITU-T Zalecenie Tytuł - przedmiot Y.1910 IPTV architecture Y.2001 General overview of NGN Y.2006 Description of capability set 1 of NGN release 1 44

45 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Y.2011 General principles and general reference model for Next Generation Networks Y.2012 Functional requirements and architecture of the NGN Y.2013 Converged services framework functional requirements and architecture Y.2014 Network attachment control functions in next generation networks Y.2021 IMS for Next Generation Networks Y.2031 PSTN/ISDN emulation architecture Y.2051 General overview of IPv6-based NGN Y.2052 Framework of multi-homing in IPv6-based NGN Y.2053 Functional requirements for IPv6 migration in NGN Y.2054 Framework to support signalling for IPv6-based NGN Y.2091 Terms and definitions for Next Generation Networks Y.2111 Resource and admission control functions in Next Generation Networks Y.2111 Resource and admission control functions in Next Generation Networks Y.2112 A QoS control architecture for Ethernet-based IP access networks Y.2121 Requirements for the support of flow state aware transport technology in an NGN Y.2171 Admission control priority levels in Next Generation Networks Y.2171 Admission control priority levels in Next Generation Networks Y.2172 Service restoration priority levels in Next Generation networks Y.2173 Management of performance measurement for NGN Y.2174 Distributed RACF architecture for MPLS networks Y.2201 NGN release 1 requirements Y.2205 NGN Emergency telecommunications Technical issues Y.2211 IMS-based real time conversational multimedia services over NGN Y.2211 IMS based real-time conversational multimedia services over NGN Y.2212 Requirements of managed delivery services Y.2213 NGN service requirements and capabilities for network aspects of applications and services using tag-based identification Y.2232 NGN convergence service model and scenario using Web Services Y.2233 Requirements and framework allowing accounting and charging capabilities in NGN Y.2234 Open service environment capabilities for NGN Y.2261 PSTN/ISDN evolution to NGN Y.2262 PSTN/ISDN emulation and simulation Y.2271 Call server based PSTN/ISDN emulation Y.2401 Principles for the Management of the Next Generation Networks 45

46 Y.2601 Fundamental characteristics and requirements of future packet based networks Y.2601 Fundamental characteristics and requirements of future packet based networks Y.2611 High level architecture of future packet based networks Y.2701 Security requirements for NGN release 1 Y.2801 Mobility management requirements for NGN Y.2802 / Q.2802 Fixed-mobile convergence general requirements Y.2803 FMC service using legacy PSTN or ISDN as the fixed access network for mobile network users Y.2804 Generic framework of mobility management for next generation networks Y.2901 The carrier grade open environment reference model Y.2902 Carrier grade open environment components Architektura i podział funkcjonalny Zalecenie Y.2001: General overview of NGN Zalecenie to zawiera ogólny przegląd wszystkich aspektów składających się na definicję sieci NGN (Next Generation Network). Identyfikuje podstawowe charakterystki i funkcje NGN, w szczególności dotyczące architektury, funkcji QoS, platform usługowych, zarządzania, bezpieczeństwa, mobilności, sygnalizacji, usług, numeracji i adresowania oraz komunikacji alarmowej. Rys. 4.3 Architektura funkcjonalna NGN wg Zalecenia ITU-T Y

47 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Zalecenie Y.2013 (12/2006): Converged services framework functional requirements and architecture (Prepub.) W zaleceniu opisano wymagania i architekturę CSF (Converged Services Framework) jako węzła koordynującego dostarczanie usług, aspekty mobilności, preferencje użytkownika, dostęp do zasobów sieci i status użytkownika w sieci. Omówiono jednostki funkcjonalne składające się na CSF oraz umiejscowienie CSF w architekturze funkcjonalnej NGN. Załącznik I zawiera przykłady zastosowań opisywanej architektury (tzw. use cases). Załącznik II wskazuje standardy związane z CSF (w szczególności związki CSF z OSA/Parlay i OMA OSE 2). Zalecenie Y.2021 (09/2006): IMS for Next Generation Networks Zalecenie to dotyczy adaptacji standardu IMS (IP multimedia subsystem), stworzonego przez 3GPP i 3GPP2, do realizacji usług SIP w kontekście sieci NGN, zdefiniowanej w zaleceniach ITU-T Y.2001 i Y Omówiono wykorzystanie standardu IMS do realizacji podsystemu usług multimedialnych IP w architekturze NGN oraz jego związki i punkty styku z pozostałymi elementami architektury funkcjonalnej NGN. W Załączniku I wskazano dokumenty dotyczące standardu IMS, które są istotne z punktu widzenia wykorzystania IMS w kontekście NGN. Zalecenie Y.2031 (09/2006): PSTN/ISDN emulation architecture Specyfikuje architekturę funkcjonalną oraz interfejsy podsystemu umożliwiającego emulację usług PSTN/ISDN w środowisku NGN (obsługę terminali PSTN/ISDN przyłączonych do NGN za pośrednictwem odpowiednich bram). Omawia dwa rozwiązania: emulację opartą na zastosowaniu serwera obsługi połączeń PSTN/ISDN (Call Server) oraz emulację opartą o architekturę funkcjonalną i możliwości systemu szkieletowego IMS. Architektura usługowa dla modeli IMS-PES i IMS jest taka sama. Zachowanie serwerów aplikacji jest, w zasadzie, identyczne w odniesieniu składnika emulacji usług PSTN/ISDN i składnika IMS. Jednak, w zależności od typu usługi, która ma być emulowana, od pewnych serwerów aplikacji moze być wymagana realizacja usług tradycyjnych. S-CSCF ma dostęp do trzech rodzajów serwerów aplikacji ASF (Application Server Functions), przez styk ISC (por.rys 3.10): Serwery aplikacji SIP - (SIP AS). Serwer aplikacji IM-SSF. Serwer aplikacji OSA SCS. Serwer aplikacji SIP może wykorzystywać funkcjonalność SCIM (Service Capability Interaction Manager), który spełnia rolę zarządzania interakcjami, oraz inne serwery aplikacji. IM-SSF służy do zapewnienia dostępu do scenariuszy usług sieci inteligentnej IN (Intelligent Network) w SCF (Service Control Function) tradycyjnych elementach architektury sieci IN. Funkkcjonalność IM-SSF functionality obejmuje emulację modelu podstawowego procesu połączenia IN, czyli BCSM (Basic Call State Model) za pomocą sygnalizacji wykorzystującej protokół SIP, mechanizmy wyzwalania właściwe dla IN i zarządzania funkcjami usługgowymi, emulację IN SSF (Service Switching Function), oraz obsługę protokołu INAP (Intelligent Network Application Part) zapewniając współpracę z SCF. 47

48 Celem wprowadzenia w architekturze IMS serwera OSA SCS zapewnienie dostępu do aplikacji OSA z wykorzystaniem znormalizowanego interfejsu OSA/Parlay API. Styk ISC między S-CSCF i AS jest wykorzystywany przekazywania żądań sterowania sesją do właściwego serwera aplikacji, w oparciu kryteria filtrowania związane z inicjującym sesję bądź przyjmującym sesję użytkownikiem. Rys. 4.4 Ogólna architektura funkcjonalna emulacji usług PSTN/ISDN wg Y.2031 SIP -AS IN SCF OSA AS Sh INAP OSA API Si IM -SSF Sh OSA SCS SUP-FE/ SAA-FE ISC Dh Cx Dx SL-FE S -CSCF PSTN/ISDN Emulation Service component Transport Stratum Rys. 4.5 Architektura usługowa NGN oparta na IMS wg Y

49 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Wizja konwergencji usług NGN wg ITU-T - CSF Jednym z najnowszych zaleceń ITU-T w zakresie NGN jest Zalecenie Y.2013: Converged services framework functional requirements and architecture. Zalecenie to stanowi próbę systemowego podejścia do zagadnień konwergencji usługowej w ramach standardów NGN i otwiera drogę do rozwoju szczegółowych zaleceń umożliwiających implementację przedstawionych tam idei. W rozumieniu Zalecenia Y.2013 konwergencja jest częściowo utożsamiana z mobilnością i związana z pojęciem tzw. seamless mobility, czyli dostępu do usług i zapewnienia ich ciągłości niezależnie od techniki dostępu do sieci i używanego terminala. Abonenci usług telekomunikacyjnych otrzymują dostęp do usług oferowanych przez operatorów za pośrednictwem różnych mediów, technik dostępu oraz urządzeń końcowych (telefon stacjonarny, mobilny, PDA, set top box itp.). W tradycyjnych sieciach usługi dostępne za pośrednictwem różnych sieci i urządzeń dostępowych różnią się między sobą. Dodatkowo, gdy użytkownik wybiera określone urządzenie (zależne od środowiska sieciowego, w którym przebywa), nie ma możliwości kontynuowania rozpoczętej sesji w przypadku zmiany tego środowiska (np. przeniesienia rozmowy z telefonu stacjonarnego do mobilnego). Standardy NGN dążą w kierunku zmiany tego stanu rzeczy. Standardy 3GPP Release 7 definiują nowe elementy architektury oraz procedury, umożliwiające realizację tzw. Fixed-Mobile Convergence (FMC). FMC oznacza dostęp do usług IMS przy wykorzystaniu terminali mobilnych, obsługujących zarówno kanały radiowe 2G/3G, jak i technikę WiFi (tzw. dual mode terminals) oraz utrzymanie ciągłości sesji przy przechodzeniu między tymi domenami. Standardy te wprowadzają do architektury IMS nowe elementy, takie jak NeDS (Network Domain Selection) czy VCC (Voice Call Continuity), które nadzorują status użytkownika w obu domenach, decydują o sposobie dostarczenia usługi oraz zapewniają jej ciągłość w przypadku utraty połączenia w jednej z domen. Tego typu rozwiązania nie były jednak szczegółowo rozważane w ramach prac żadnej z organizacji standaryzacyjnych, tworzących zalecenia NGN dla sieci stacjonarnych. Tymczasem realizacja usług takich, jak Find me, zapewniających dostęp do użytkownika przez pojedynczy numer w wielu różnych sieciach czy Follow me, umożliwiających użytkownikowi przemieszczanie się między różnymi sieciami, z uwzględnieniem preferencji użytkownika (np. kosztu realizacji usługi w danej domenie, wyboru terminala, dostępnych funkcji itp.) wymaga zdefiniowania nowych rozwiązań i standardów także dla sieci stacjonarnych NGN. W Zaleceniu Y.2013, ITU-T definiuje specyficzną architekturę usługową, nazwaną CSF (Converged Service Framework). Ma ona wspierać integrację sieci i technik dostępu w zakresie koordynacji sesji użytkownika, jego identyfikacji przez sieć oraz polityk przydziału zasobów i dostępu do funkcji. W założeniu, CSF ma realizować szereg funkcji wspólnych dla aplikacji konwergentnych, takich jak: śledzenie obecności użytkownika w sieciach oraz jego lokalizacji zapis i przetwarzanie preferencji użytkownika oraz informacji związanej z usługami, obecnością użytkownika w określonych sieciach dostępowych i szkieletowych, jego terminalami i aplikacjami udostępnianie informacji o użytkowniku usługom, systemom sieciowym, urządzeniom i aplikacjom (np. serwerom obsługującym podawanie lokalizacji użytkownika, obecności w danej sieci, stanu rejestracji w określonych domenach itp.) 49

50 translacja uogólnionych żądań realizacji usługi lub zmiany jej stanu na zapytania zależne od konkretnej sieci, urządzenia czy systemu obsługa ciągłości sesji wg preferencji użytkownika. Na architekturę CSF składają się następujące elementy funkcjonalne: CC-FE (Convergence Coordination Functional Entity): zapewnia koordynację w dostępie do informacji dotyczącej użytkownika, jego terminali, usług, zasobów, lokalizacji itp.; integruje dane z różnych baz danych operatora, plików konfiguracyjnych, danych z sieci, aplikacji itp. NS-FE (Network Support Functional Entity): stanowi warstwę mediacji w dostępie do informacji z CC-FE. ES-FE (Edge Support Functional Entity): jest to klient CSF w urządzeniu brzegowym (takim jak set top box), zapewniający urządzeniu dostęp do funkcji CSF (np. w postaci interfejsu API). CLS-FE (Client Support Functional Entity): rezyduje w urządzeniach użytkownika; zapewnia CSF informacje o zasobach i aplikacjach użytkownika oraz identyfikację urządzenia i użytkownika CP-FE (Convergence Policy Functional Entity): zapewnia zarządzanie politykami i ich realizację. CSF jest rozwiązaniem nakładkowym, które w zamierzeniu standardu ma współpracować z architekturą NGN tworzoną przez odpowiednie zalecenia ITU-T oraz z różnymi istniejącymi sieciami (komórkowymi, kablowymi itp.). Z punktu widzenia architektury IMS, która (z określonymi modyfikacjami dla sieci stacjonarnych) jest podstawą standardu NGN ITU-T, CSF może funkcjonować w warstwie aplikacji jako serwer usługowy (AS) i wykorzystywać interfejsy zdefiniowane w IMS dla AS. W szczególności, funkcja NS-FE może korzystać z interfejsu ISC (opartego na protokole SIP) do wymiany informacji z centralnym elementem sterującym S-CSCF, interfejsu S h do interakcji z HSS oraz U t do interakcji z terminalem użytkownika. Alternatywnie, NS-FE może być zintegrowane z S-CSCF. Należy podkreślić, że wybór odpowiedniego serwera usługowego (bądź sekwencji serwerów) do realizacji określonej usługi w IMS jest oparty na tzw. filtrach ifc (Initial Filter Criteria), przechowywanych w centralnym rejestrze HSS. Niestety, standardowy mechanizm nie obejmuje możliwości tworzenia elastycznych reguł, określających przekazywanie sterowania usługą do określonych AS w zależności od stanu realizacji usługi czy jej interakcji z innymi usługami (np. wyzwalanymi przez te same wyzwalacze SPT). Włączenie w ten proces funkcji CSF, która z założenia dysponuje informacją o stanie sesji użytkownika, wykorzystaniu zasobów itp., przy odpowiednim zdefiniowaniu dodatkowych funkcjonalności w zakresie koordynacji między realizowanymi usługami mogłoby w znacznym stopniu ograniczyć ułomność standardu IMS w zakresie mediacji między elementami logiki usługowej, realizowanej przez różne serwery AS ETSI TISPAN NGN TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) jest to jednostka ETSI, zajmująca się technicznymi aspektami realizacji NGN w sieciach stacjonarnych oraz migracji systemów z komutacją kanałów w kierunku architektury NGN. TISPAN tworzy szczegółowe specyfikacje techniczne, raporty techniczne i normy, obejmujące m.in. usługi, architektury, protokoły, aspekty 50

51 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS QoS, bezpieczeństwo oraz mobilność użytkowników w systemach NGN opartych na sieciach stacjonarnych. Podstawą architektury NGN TISPAN jest IMS oparty na normach 3GPP. Specyfikacje TISPAN są z kolei podstawą rekomendacji ATIS (Alliance for Telecommunications Industry Solutions) oraz ITU (International Telecommunication Union). TISPAN wykorzystuje IMS do realizacji tzw. usług konwersacyjnych (conversational services), obejmujących w zasadzie dowolne sesje oparte na protokole SIP (Session Initiation Protocol). TISPAN definiuje jednak szereg podsystemów, umożliwiających adaptację klasycznych systemów dostępu (PSTN, ISDN) do części szkieletowej sieci NGN. Dokumenty normalizacyjne TISPAN NGN Release 1 są oparte na wersji 7 3GPP IMS. Release 1 obejmuje usługi konwersacyjne i standaryzuje aspekty takie, jak: terminologia, strategia, QoS, bezpieczeństwo, identyfikacja, adresowanie wymagania sieciowe, architekturę systemu i podsystemów, niektóre usługi i protokoły aspekty związane z sytemami OSS, sterowaniem przeciążeniami, przechowywaniem profili użytkownika emulacja usług PSTN/ISDN mobilność użytkownika (ograniczona). W aspekcie migracji i współdziałania sieci PSTN/ISDN z siecią NGN, TISPAN definiuje dwa istotne podsystemy usługowe: podsystem emulacji usług PSTN/ISDN, który ma zapewnić adaptację terminali i usług PSTN/ISDN do opartej na IP infrastruktury NGN w celu jak najwierniejszego odwzorowania usług PSTN/ISDN w sieci NGN podsystem symulacji usług PSTN/ISDN, który ma zapewnić realizację odpowiedników funkcjonalnych usług PSTN/ISDN przy wykorzystaniu dostępnych funkcji sterowania sesjami oraz interfejsów i infrastruktury IP. TISPAN zajmuje się też aspektami komunikacji, które są istotne dla sieci stacjonarnych, a nie są objęte standardami 3GPP (przeznaczonymi z zasady dla sieci mobilnych), np. takimi, jak usługi alarmowe (Emergency Services) czy ochrona dostępu do sieci przez kontrolery SBC (Session Border Controllers) NGN Release 2 i Release 3 ETSI TISPAN kontynuował prace nad NGN Release 2. Publikacja norm nastąpiła w 2007 i 2008 roku. Główne nowe obszary prac nad NGN Release 2 dotyczyły: Analizy wymagań na realizację usług konwergentnych FMC (we współpracy z FMCA). Analiza wymagań na sieci domowe (we współpracy z HGI). Wymagania na funkcje sieciowe do realizacji usług IPTV (we współpracy z ITU-T FG, ATIS IIF i DVB). Integracji IPTV z usługami NGN z wykorzystaniem architektury IMS. Wsparcie dla usług biznesowych i współpracy NGN z firmowymi sieciami wydzielonymi (współpraca głównie z ECMA International). 51

52 Główne nowe elementy wprowadzone w NGN Release 3, to: Konsolidacja VoIP z uwzględnieniem aspektów QoS, bezpieczeństwa, współpracy i interoperacyjności. Ewolucja usług IPTV (usługi mieszane łączenie IPTV z Internetem i usługami telekomunikacyjnymi i dalsze perspektywy). Dostęp ultraszerokopasmowy (stacjonarny i bezprzewodowy) do sieci NGN. Współpracy i połączeniu z domenami IMS i nie-ims). Harmonizacja sieci zwiększenie zakresu interoperacyjności z innymi sieciami NGN oraz innymi sieciami nie-ims. Współpraca z pozostałymi organizacjami normalizacyjnymi ITU-T, 3GPP i GSMA Standaryzacja protokołów NGN w IETF Wprowadzenie Protokół SIP i definiująca go norma IETF RFC 3261 stanowią główny element szerokiego zestawu dokumentów normalizacyjnych związanych z komunikacją multimedialną w sieciach IP. Obejmują one rozszerzenia protokołu SIP związane np. z obecnością i wymianą wiadomości natychmiastowych oraz definicje protokołów (np. SDP), modeli i rozwiązań pozwalających implementować zaawansowane usługi multimedialne. Z kolei, podstawowe normy dotyczące protokołów SIP i SDP stanowiły dla 3GPP podstawę do definicji protokołu sterowania sesjami multimedialnymi w architekturze usługowej IMS. W ramach IETF działa szereg grup roboczych, których obszar działania dotyczy problematyki NGN. Ich trzon stanowi 15 grup roboczych zajmujących się różnymi aspektami wykorzystania protokołu SIP. W Tabeli 4.2 przedstawiono w sposób zagregowany informację o normalizacji NGN w IETF. Tabela 4.2 Grupy robocze IETF zajmujące się normalizacją związaną z NGN Nazwa grupy roboczej Data utworzenia Obszar normalizacji AVT (Audio/Video Transport) 12/1992 Transport Audio/Wideo BEHAVE (Behavior Engineering for Hindrance Avoidance) ECRIT (Emergency Context Resolution with Internet Technologies) 09/2004 Behavior Engineering for Hindrance Avoidance 02/2005 Emergency Context Resolution with Internet Technologies ENUM (Telephone Number Mapping ) 10/1999 Odwzorowanie planu numeracji telefonicznej GEOPRIV Location/Privacy) (Geographic IEPREP (Internet Emergency Preparedness) 06/2001 Geographic Location/Privacy 02/2002 Internet Emergency Preparedness IPTEL (IP Telephony) 08/1998 Telefonia IP MMUSIC (Multiparty MUltimedia SessIon Control) 07/1995 Multiparty Multimedia Session Control SIGTRAN (Signaling Transport) 11/1998 Transport sygnalizacji SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) 03/2001 SIP for Instant Messaging and Presence Leveraging Extensions 52

53 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS SIP (Session Initiation Protocol) 09/1999 Protokół SIP SIPPING (Session Initiation Protocol Project INvestiGation) 11/2001 Session Initiation Proposal Investigation SPEECHSC (Speech Services Control) 06/2002 Sterowanie usługami głosowymi SPEERMINT (Session PEERing for Multimedia INTerconnect) 02/2006 Session PEERing for Multimedia INTerconnect XCON (Centralized Conferencing) 10/2003 Usługi konferencyjne Rys.4.6 Mapa grup roboczych IETF zajmujących się normalizacją NGN 53

54 5 H.323 i SIP główne protokoły aplikacyjne NGN 5.1. H.323 Zalecenie H.323 normalizujące protokół zostało opublikowane przez ITU-T (International Telecommunication Union Telecommunication Standarization Sector) w 1996 roku i stało się podstawowym oficjalnym standardem sterowania połączeniami multimedialnymi w sieci IP i w szczególności realizacji usług VoIP zarówno w sieciach publicznych jak i w sieciach wydzielonych prywatnych. W związku z normalizacją UMTS i architektury IMS standard H.323 jest zastępowany przez protokół SIP, ale nadal jest wykorzystywany, głównie w środowisku sieci korporacyjnych. W początkowych założeniach H.323 było rozwiązaniem technicznym umożliwiającym realizację połączeń wideokonferencyjnych w sieciach LAN, lecz z czasem przystosowano go do realizacji m.in. połączeń głosowych w sieciach rozległych WAN i w kolejnych wersjach rozszerzono funkcjonalność oraz poprawiono efektywność Elementy architektury H.323 W sieci wykorzystującej zalecenie ITU-T H.323 wyróżniono następujące elementy funkcjonalne: Terminale H.323: mogą to być wideoterminale, telefony IP, aplikacje VoIP. Mostki, czyli MCU (Multipoint Control Units): umożliwiają realizację połączeń konferencyjnych. Bramy (Gateways): umożliwiają połączenie z innymi sieciami. Serwer sterujący (Gatekeeper): umożliwia translację adresów użytkowników na adresy IP oraz kontrolują dostęp terminali, mostków i bram do sieci. Mogą one pracować w dwóch różnych trybach w zależności od sposobu obsługi połączeń: o o Bezpośrednim (Direct-routed): sytuacja w której sterownik bramy jedynie przekazuje informacje protokołu H.225 pomiędzy uczestniczącymi w rozmowie terminalami. Nadzorowany przez serwer sterujący (Gatekeeper-routed): Serwer sterujący oprócz zwykłego przekazywania wiadomości może je także modyfikować, co umożliwia większą kontrolę nad połączeniem oraz pozwala wykorzystać usługi dodatkowe. Sygnalizacja w systemach H.323 jest złożona i obejmuje trzy umowne kanały sygnalizacyjne o różnym przeznaczeniu: kanał RAS (terminale-gatekeeper), kanał H.225/Q.931 (zestawianie połączeń) i kanał H.245 (zarządzanie strumieniami mediów). Protokół RAS (Registration, Admission and Status) RAS jest protokołem służącym do komunikacji między terminalem H.323 a serwerem sterującym. Główne funkcje realizowane przez protokół RAS to: Odkrywanie serwera sterującego (Gatekeeper Discovery). Rejestracja terminali H.323 w serwerze sterującym (Gatekeeper Registration). Zarządzanie zgłoszeniami (Call Admission). Na Rys.5.1 przedstawiono wymianę wiadomości podczas realizacji wymienionych procedur. 54

55 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Terminal H.323 Gatekeeper GRQ GCF Gatekeeper Request Gatekeeper Confirmation Gatekeeper Discovery RRQ RCF Registration Request Registration Confirmation Gatekeeper Registration ARQ ACF Admission Request Admission Confirmation Gatekeeper Admission Rys.5.1 Wymiana wiadomości protokołu RAS w ramach procedur Gatekeeper Discovery/Registration/Admission Protokół H.225 Protokół H.225 inspirowany standardem sygnalizacji abonenckiej DSS1 wykorzystywanej w sieciach ISDN odpowiada za obsługę połączeń H.323. Na Rys.5.2 przedstawiono wymianę wiadomości protokołu H.225 w połączeniu H.323: Terminal H.323 Gatekeeper Terminal H.323 Setup Setup acknowledge Setup Alerting Connect Alerting Connect Połączenie Release Complete Release Complete Rys.5.2 Wymiana wiadomości protokołu H.225 w połączeniu H

56 Protokół H.245 Podstawowe funkcje realizowane przez H.245 to: negocjacja parametrów połączenia przez wiadomości TCS (Terminal Capability Set), ustalenia relacji master/slave wiadomości MSD (Master/Slave Determination), zestawianie, kontrola i zamykanie kanałów logicznych (sterowanie przesyłaniem pakietów RTP) wiadomości OLC/CLC (Open Logical Channel/Close Logical Channel). Wiadomość TCS zawiera listę wspieranych kodeków audio i wideo przez dany terminal H.323. Mechanizm MSD służy do wyboru terminala negocjującego parametry połączenia na podstawie TCS. Sterowanie przepływem danych audio i wideo jest realizowane przez wykorzystanie tzw. kanałów logicznych, otwieranych i zamykanych przez wiadomości OLC i CLC Charakterystyka i zastosowania H.323 Protokół H.323 pozwala elastycznie konfigurować aplikacje VoIP i znajduje się w ofercie produktów oferowanych przez czołowych producentów sprzętu i oprogramowania takich jak np. Cisco, Microsoft i Intel. Jest rozwiązaniem neutralnym technicznie, co w praktyce oznacza, że wdrażając H.323, nie trzeba stosować konkretnego systemu operacyjnego czy ściśle określonego sprzętu. Opcje zarządzające przepustowością pozwalają unikać bądź likwidować przeciążenia, gdyż administrator może przypisywać poszczególnym sesjom H.323 określone przepustowości, zapewniając w ten sposób wystarczającą przepływność innym aplikacjom uruchamianym w tym samym środowisku sieciowym. Administrator może konfigurować punkty końcowe, które realizują różne zadania. Przykładowo, terminal wspierający tylko dane audio może brać udział w konferencji, którą obsługują terminale przesyłające zwykłe dane i wspierające dane wideo. Multimedialny terminal zgodny z H.323 może współdzielić tę część konferencji wideo, która dotyczy zwykłych danych, z terminalem wspierającym tylko przesyłanie danych (standard T.120) i jednocześnie współdzielić zwykłe dane i dane audio-wideo z innymi terminalami H SIP SIP (Session Initiation Protocol) jest tekstowym protokołem aplikacyjnym, typu klientserwer, przeznaczonym do realizacji interaktywnych multimedialnych sesji komunikacyjnych dla dwóch lub więcej uczestników. W trakcie sesji jej uczestnicy (osoby i aplikacje) mogą się komunikować wykorzystując różne media (głos, wideo, obrazy, tekst, pliki), z możliwością ich płynnej zmiany w trakcie (np. zmiana kodeka), jak również współużytkować zdalnie aplikacje (gry sieciowe, wspólne przeglądanie witryn WWW). SIP zapewnia podstawowe mechanizmy obsługi komunikacji, takie jak: Lokalizacja terminala użytkownika 8. Określenie dostępności użytkownika. Negocjacja parametrów połączenia. Ustanowienie i zarządzanie sesjami multimedialnymi. 8 Możliwość określenia adresu sieciowego terminala użytkownika. 56

57 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Pierwowzorem dla protokołu SIP był HTTP, dzięki czemu zachowano łatwość tworzenia i udostępniania bogatych funkcjonalnie i innowacyjnych usług wynikającą z przemieszczenia sterowania aplikacjami do terminali. Jedną z najistotniejszych idei Internetu jest możliwość współdziałania aplikacji z serwerem i przeglądarką w sposób niezależny od wykorzystywanej sieci IP. Podobne zasady dotyczą sesji używających protokołu SIP, co w praktyce oznacza, że serwer i klient SIP mają pełną kontrolę nad sesją. Jest to model zasadniczo odmienny od scentralizowanego sterowania usługą przez węzeł komutacyjny i platformę usługową (np. IN) w sieci telefonicznej. SIP jest protokołem sygnalizacyjnym neutralnym w odniesieniu do sesji i wiadomości, udostępniając mechanizmy ustanawiania sesji wykorzystujących różne rodzaje mediów (głos, wideo, wiadomości, gry) nie wnika w ich przeznaczenie. Obsługuje transport dowolnych wiadomości przenoszących treści typu MIME (Multipurpose Internet Mail Extensions). Daje to bardzo szerokie możliwości projektowania nowych usług. Internetowy rodowód SIP sprawia, że dziedziczy on wiele mechanizmów i cech protokołu HTTP (np. składnię i tekstową formę zapisu). 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 - hiperłączy umieszczanych na stronach WWW (oraz w innych dokumentach elektronicznych) i informować, że użytkownik jest dostępny poprzez adres SIP. Identyfikator SIP URL uwzględnia także możliwość użycia zwykłego numeru telefonicznego (zgodnego z zaleceniem E.164) jako adresu SIP użytkownika. Protokół SIP znajduje również zastosowanie do realizacji usług IMP z możliwością wymiany na bieżąco wiadomości w formacie MIME. Rozważa się także inne obszary zastosowań SIP, takich jak: Internet rzeczy IoT, zdalne sterowanie urządzeniami i wyposażeniem domowym (sprzęt RTV, klimatyzacja, systemy alarmowe, itp.). Dzięki jego otwartości protokół SIP można łatwo rozszerzyć o nowe typy wiadomości i mechanizmy realizacji nowych usług, w miarę pojawiania się dodatkowych wymagań. Dobrym przykładem jest rozszerzenie SIP do potrzeb usług natychmiastowej komunikacji i obecności - SIP for Instant Messaging and Presence (SIMPLE). Zachowuje się przy tym zasadę zgodności wstecz dzięki czemu można realizować komunikację między terminalami korzystającymi z różnych wersji implementacji protokołu SIP. Pierwsza wersja protokołu SIP została opracowana przez Henninga Schulzrinna i Marka Handlera w 1996 roku. Obecnie stosowaną njanowszą normą IETF definiującą podstawowe mechanizmy protokołu jest RFC W roku 2000, w ramach prac nad standardem IMS, 3GPP adaptując SIP wprowadziła liczne zmiany i rozszerzenia funkcjonalności protokołu SIP i włączyła go do grupy norm dla sieci UMTS poczynając od wersji 5 (Release 5). Protokół SIP dostarcza środków, wraz z innymi protokołami, takimi jak SDP (opis parametrów sesji) i RTP (protokół transportu strumieni medialnych), służących do budowy usług i aplikacji multimedialnych łączących funkcjonalność telekomunikacyjną z możliwościami Internetu Budowa protokołu oraz model sesji SIP jest protokołem tekstowym o składni zbliżonej do HTTP. W warstwie transportowej wykorzystuje protokoły UDP i TCP/TLS. Podobnie jak HTTP, realizuje model transakcyjny - żądanie/odpowiedź. Każda transakcja składa się z żądania, które jest 57

58 wywołaniem określonej metody na serwerze oraz z przynajmniej jednej odpowiedzi. Podstawowy zestaw żądań - wiadomości sygnalizacyjnych obejmuje: INVITE pierwsza wiadomość inicjująca sesję. ACK potwierdzenie zgody na przyjęcie sesji od wywoływanej strony. BYE powoduje zakończenie trwającej sesji. CANCEL kończy proces nawiązywania sesji. OPTIONS umożliwia poznanie obsługiwanych mechanizmów terminala, do której jest adresowana. REGISTER umożliwia rejestrację lokalizacji sieciowej terminala użytkownika 9. Rys. 5.3 Mapa protokołu SIP i protokołów stowarzyszonych wykorzystywanych w kontekście realizacji usług komunikacji multimedialnej [źródło: Odpowiedzi, podobnie jak w HTTP, są podzielone na kategorie określające rodzaj przenoszonych informacji: 9 Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem użytkownika (np. sip:ala@eims.local). 58

59 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS 1xx (np. 180 Ringing ) odpowiedzi informacyjne (wskazują na postęp w realizacji zgłoszenia). 2xx (np. 200 OK ) pozytywne potwierdzenia (wskazują na pomyślne zakończenie transakcji). 3xx (np. 302 Moved Temporarily ) przekierowania (wskazują na potrzebę wykonania innych akcji w celu dokończenia realizacji zgłoszenia). 4xx (np. 404 Not Found ) błędy strony klienckiej (np. wiadomość jest niepoprawna, albo niemożliwa do obsługi przez serwer). 5xx (np. 501 Not Implemented ) błędy serwera. 6xx (np. 604 Does Not Exist Anywhere ) błędy ogólnego typu. Na Rys.5.4 przedstawiono przykładową wiadomość SIP. Wiadomość złożona jest z tzw. wiersza początkowego, który określa rodzaj i adres systemu, do którego jest kierowane zaproszenie do sesji (tzw. Request-URI albo R-URI) oraz z nagłówków określających różne parametry sesji. Przykładowo nagłówki Via wskazują na drogę w sieci tj., przez jakie elementy była obsługiwana wiadomość, nagłówek From określa, kto jest nadawcą a Allow wskazuje, jakie rodzaje wiadomości są obsługiwane przez inicjatora sesji. rodzaj wiadomości R-URI,czyli adres określający system do którego jest adresowana wiadomość tzw. pierwsza linia nagłówki Via, określające drogę wiadomości w sieci nagłówek Contact zawierający adres IP inicjatora tej wiadomości identyfikator transakcji INVITE sip:ala@eims.local SIP/2.0 Date: Sun, 01 Apr :53:57 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP pcscf.eims.local;branch=z9hg4bkcaf e3.0 Via: SIP/2.0/UDP :63715;branch=z9hG4bK30779c7c-cede User-Agent: Ekiga/2.0.3 To: <sip:ula@eims.local>;tag=983435as From: <sip:ala@eims.local>;tag= c Call-ID: de40707c-cede-db @rubi Contact: <sip:a@ :63715;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 67 Rys. 5.4 Przykładowa wiadomość INVITE protokołu SIP Na Rys.5.5 przedstawiono przykładowy scenariusz nawiązania sesji oraz jej zakończenia. 59

60 Serwer lokalizacji alfa 1 INVITE foto.wro.com From: To: Call-ID: @alfa.pw OK From: To: Call-ID: @alfa.pw 7 ACK wro.com From: To: Call-ID: @alfa.pw 2 ala.b 3 alicja@beta gamma 4 INVITE beta From: To: Call-ID: @alfa.pw OK From: To: Call-ID: @alfa.pw Serwer Proxy 8 ACK beta From: To: Call-ID: @alfa.pw beta alicja Domena pw.waw.pl Domena foto.wro.com Rys. 5.5 Przykładowa sesja komunikacyjna SIP Architektura funkcjonalna sieci IP wykorzystującej protokół SIP składa się z połączonych ze sobą węzłów dwóch typów: 1. agentów użytkowników UA (User Agent) i 2. serwerów logicznych o różnym przeznaczeniu i sposobach działania: pośredniczących (Proxy Server) przekazujących (Redirect Server) lokalizacji (Location Server) rejestrowych (Registrar) aplikacyjnych (Application Server) związane z konkretnymi usługami (np. serwer statusu obecności i dostępności użytkowników Presence Server). Agent użytkownika - UA jest elementem pośredniczącym w komunikacji między użytkownikiem a siecią. UA łączy w sobie funkcje klienta UAC (UA Client) i serwera UAS (UA Server). Dzięki temu każdy terminal sieci SIP pełni rolę UA (UAC+UAS) będąc jednocześnie węzłem typu host w znaczeniu internetowym. Umożliwia to wysyłanie przez użytkownika zarówno żądań (np. inicjowanie sesji) jak i odpowiadanie na żądania przychodzące (np. przyjęcie zaproszenia do sesji). Węzły pełniące rolę fizycznych serwerów sieciowych mogą jednocześnie realizować funkcje wielu typów serwerów logicznych zdefiniowanych na poziomie architektury funkcjonalnej. Zazwyczaj serwer Registrar jest implementowany wspólnie z serwerem Proxy lub Redirect, a ponadto może dodatkowo realizować funkcje serwera aplikacyjnego. Węzły sieci SIP komunikują się między sobą za pomocą wiadomości-metod zgodnie z przyjętymi w protokole regułami dotyczącymi ich wymiany i adresacji oraz zasadami działania poszczególnych typów serwerów i klientów. W architekturze funkcjonalnej protokołu można wyróżnić elementy pełniące określone funkcje, które są realizowane przez systemy uczestniczące w procedurach wykorzystujących SIP. Te funkcje to: 60

61 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Funkcja agenta użytkownika (User Agent, UA) polega na możliwości inicjowania i odbierania sesji. Zazwyczaj implementowana jest w terminalach użytkownika. Funkcja serwera pośredniczącego (Proxy) polega na odbieraniu i podejmowaniu decyzji związanych z właściwym kierowaniem wiadomości do agentów użytkownika bądź innych serwerów Proxy. Funkcja serwera rejestru (Registrar) polega na gromadzeniu i udostępnianiu informacji o lokalizacji sieciowej tj. skojarzenia pomiędzy identyfikatorem użytkownika Sip-URI (np. sip:ala@eims.local) a adresem sieciowym terminala danego użytkownika. Funkcja B2BUA (Back-To-Back User Agent) jest to połączenie funkcji agenta użytkownika z funkcją serwera pośredniczącego. Wiadomości, w których wymianie pośredniczy serwer implementujący funkcje B2BUA, są widziane dla elementów sieci SIP, tak jakby były zainicjowane właśnie z serwera B2BUA, a nie z faktycznego agenta użytkownika, który jest inicjatorem sesji 10. System serwerów Proxy, Registrar i agentów użytkownika (UA) tworzy model sesji, który jest określany jako trapez SIPowy (por. Rys.5.6). Registrar Registrar Proxy SIP Proxy SIP SIP UA SIP przepływ mediów (strumienie RTP) UA Rys.5.6 Model sesji SIP ("trapez SIP") UA ustanawiają sesję wykorzystując serwery Proxy, które dysponują informacją o adresacji terminali (funkcja lokalizacji). Po nawiązaniu sesji dalsza wymiana wiadomości może następować z pominięciem serwerów Proxy, ponieważ UA znają już nawzajem swoje adresy IP. Uzgadnianie parametrów połączenia pomiędzy stronami odbywa się za pomocą protokołu SDP, który jest wykorzystywany do przenoszenia treści wewnątrz wiadomości SIP. Mechanizm jest oparty o model negocjacji zdefiniowany w RFC Szczegółowa definicja mechanizmów protokołu SIP jest zawarta w normie RFC Opisany mechanizm jest zbliżony do NAT w sieci TCP/IP, tylko jest przeprowadzany w warstwie aplikacyjnej. 61

62 Adresacja Rys.5.7 Struktura i warstwy protokołu SIP Adresacja w protokole SIP jest zbliżona w formie do internetowej poczty elektronicznej. Adres składa się z nazwy użytkownika i nazwy węzła sieci (lub bramy) pełniącego rolę serwera SIP. Adresy SIP uwzględniają plan numeracji E.164. W związku z tym przykładowi użytkownicy mogą mieć następujące adresy: sip:mareks@tele.pw.edu.pl sip: @gateway.com; user=phone Negocjacja parametrów sesji SIP Protokół SIP służy do nawiązywania sesji multimedialnych między klientami aplikacji usługowych UA zainstalowanych w urządzeniach użytkowników. Sesję charakteryzuje rodzaj mediów (i właściwy dla nich kodek) oraz inne parametry (adresy, nr portów, protokół transportowy, preferencje użytkowników). Z uwagi na zróżnicowanie urządzeń, aplikacji i preferencji użytkowników realizacja sesji wymaga uprzedniego uzgodnienia jej parametrów między komunikującymi się stronami. dozwolonej formy. W protokole SIP uwzględniono to w formie możliwości negocjacji ustanawianej sesji komunikacyjnej oraz możliwości zmiany parametrów sesji już trwającej (renegocjacja). Do opisu strumieni mediów dla sesji wykorzystuje się notację SDP (ang. Session Description Protocol). Negocjacja odbywa się na zasadzie wymiany opisów mediów: propozycja-odpowiedź, w której jedna ze stron z wykorzystaniem notacji SDP proponuje formę sesji, opisując poszczególne proponowane strumienie, zaś druga strona odpowiada powierdzając zaakceptowaną wersję jako podzbiór opisu zawartego w propozycji. Opisy SDP są przesyłane w treści wiadomości SIP Model obecności Obecność, w kontekście wykorzystania protokołu SIP do realizacji usług, to wola, zdolność i chęć do komunikacji z wykorzystaniem różnych urządzeń, trybów i form wymiany informacji oraz rodzajów mediów. Usługa obecności, w swej podstawowej wersji, pozwala określić, czy użytkownik jest w danym momencie obecny w sieci, a jeśli tak, jaki jest jego status (np. dostępny/niedostępny). Usługa obecności, pozwala 62

63 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS też użytkownikom określać preferowane bądź dostępne tryby komunikacji (np. czy terminal, z którego korzystają, obsługuje połączenia wideo, audio lub przesyłanie wiadomości natychmiastowych), a także, w zaawansowanym modelu, uwzględniać lokalizację, charakter otoczenia, strefę czasową, nastrój, wykonywane czynności, itp. Model obecności zakłada, że użytkownicy mogą decydować o tym, jakie informacje związane z ich statusem obecności mogą być udostępniane innym, upoważnionym użytkownikom (tzw. Obserwatorom - watchers), którzy powiadamiani są o zmianach statusu dostępności danego użytkownika na bieżąco. Obecność i status dostępności jest funkcją usługową dostępną nie tylko bezpośrednio dla użytkowników w sieci, ale także komponentem do wykorzystania przez inne usługi. Np. serwer usługi konferencji ad-hoc może wykorzystywać informacje dostarczane przez serwer obecności w celu podjęcia propozycji zorganizowania sesji konferencyjnej gdy wszyscy lub większość potencjalnych uczestników jest dostępna lub np. serwer poczty głosowej może wykorzystywać status dostępności użytkownika i w chwili gdy się on zarejestruje się w sieci, wysyła powiadomienie informujące o oczekujących na odsłuchanie wiadomościach w poczcie głosowej. W związku z usługą obecności uzywa się następujących pojęć: Obserwowany - terminem tym (presentity) zostanie nazwany użytkownik, grupa użytkowników, urządzenie lub usługa, której stan obecności jest śledzony. Obserwowany podmiot może być ogólnie rozumiany jako źródło informacji o swoim statusie obecności. Obserwator (watcher) - użytkownik żądający informacji o zmianach statusu obecności Obserwowanego. Subskrypcja żądanie wysyłane przez Obserwatora w celu otrzymywania powiadomień z informacją o statusie dostępności Obserwowanego. Wymagana jest akceptacja ze strony Obserwowanego i uwierzytelnienie Obserwatora. Obserwator może określić profil subskrypcji, (np. rodzaj zdarzeń, o których pragnie być informowany, szczegółowość informacji, itd.). Notyfikacja powiadomienie z informacją o zmianie statusu obecności Obserwowanego lub pełna informacja o obecności. Publikacja informacja umieszczana przez Obserwowanego na serwerze obecności w celu jej przekazywania Obserwatorom. Informacje o obecności Obserwatora mogą być dostarczane z różnych źródeł. Obserwowany może publikować szczegółowy dokument o obecności lub pojedyncze uaktualnienia. Wykorzystanie dodatkowych wiadomości protokołu SIP związanych z usługą obecności zostało przedstawione na Rys.5.8. Do rejestracji użytkownika jako Obserwatora służy wiadomość SUBSCRIBE. Powiadomienia o zmianie statusu obecności są przesyłane asynchronicznie za pomocą wiadomości NOTIFY. Jednostka funkcjonalna PA (Presence Agent agent obecności) jest odpowiedzialna za scenariusz usługi, obsługę żądań PUBLISH i SUBSCRIBE oraz za przesyłanie powiadomień do Obserwatorów. 63

64 Obserwator SUBSCRIBE NOTIFY PA PUBLISH NOTIFY Obserwowany SIP Proxy/ Rysunek 5.8 Podstawowy model usługi obecności REGISTER Podstawowy model obecności zaproponowany przez IETF (RFC 2778, 2000r.) dążył do oddzielenia architektury realizacji usługi od protokołów przenoszących subskrypcje i powiadomienia. Spośród zaproponowanych koncepcji tylko dwie zostały w pełni rozwinięte SIMPLE (ang. Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) i XMPP (ang. Extensible Messaging and Presence Protocol, opracowany na podstawie standardu Jabber). Architektura SIMPLE jest szczególnym przypadkiem zastosowania generycznego modelu powiadamiania o zdarzeniach z użyciem protokołu SIP. Jabber jest natomiast otwartym, opartym na XML protokołem, służącym do komunikacji oraz powiadamiania o obecności w czasie rzeczywistym. Pełny model usługi obecności z wykorzystaniem protokołu SIP został przedstawiony znacznie później w normie IETF RFC Określa on, w jaki sposób informacja o obecności powinna być publikowana za pomocą metody PUBLISH, komponowana na podstawie informacji pochodzących z wielu źródeł, filtrowana z uwzględnieniem wymagań prywatności i rozsyłana do Obserwatorów, którzy także mają możliwość filtrowania treści, które do nich są przekazywane. Implementacja w pełni funkcjonalnego rozwiązania usługi obecności wymaga dodatkowych mechanizmów (oprócz wiadomości sygnalizacyjnych SUBSCRIBE, NOTIFY i PUBLISH) służących do konfiguracji usługi i określania uprawnień Obserwatorów do śledzenia informacji o statusie obecności Obserwowanych. Na Rys.5.9 przedstawiono szczegółowy schemat realizacji usługi obecności. 64

65 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS XCAP (HTTP + XPath) Obserwowany Serwer XCAP Obserwator NOTIFY [Watcher-Info] PUBLISH SUBSCRIBE [presence] [Watcher-Info] polityki dostępu, zarządzanie grupami Serwer obecności (grupy, składnia dokumentu, filtrowanie) NOTIFY [presence] SUBSCRIBE [presence] REGISTER SUBSCRIBE [reg] NOTIFY [reg] SIP Proxy / Registrar Rysunek 5.9 Pełny model realizacji usługi obecności Informacja o statusie obecności Format PIDF, czyli Presence Information Data Format, definiuje jednolity sposób odwzorowania informacji o obecności w różnorodnych systemach komunikacyjnych. Znaczenie dokumentu w postaci PIDF jest niezależne od miejsca, w którym się znajduje i od sposobu, w jaki jest przekazywany. Podstawowe pojęcia związane z obecnością, wykorzystywane w dokumentach PIDF, to: Urządzenie (Device) model fizycznego środowiska, w którym usługi są dostępne dla użytkownika, użytkownik ma możliwość konfiguracji urządzenia w celu wybrania usług; usługa (Service) forma komunikacji / interakcji z użytkownikiem; osoba (Person) użytkownik i jego stany związane z statusem obecności; Presentity (Obserwowany) - pełen opis użytkownika w sensie wartości atrybutów jego statusu obecności w sieci. 65

66 Informacja o obecnym to komplet informacji o urządzeniu, usłudze i osobie, jest ona identyfikowana poprzez tzw. Presentity URI: Rysunek 5.10 Model Obserwowanego (Presentity) Dla każdego unikalnego Obserwowanego w sieci istnieje jeden lub więcej URI. Presentity to nie tylko nazwa, ale i zasób, do którego można kierować zapytania o status dostępności. Przykładowym sposobem adresowania w protokole SIP jest użycie identyfikacji Address of Record Format RPID bogata obecność Podstawowa usługa obecności opiera się jedynie na dwóch informacjach dostępności i ewentualnych powodach nieosiągalności ( zajęty, zaraz wracam, itd.). Dodatkowo możliwe jest wprowadzenie komentarza do elementu <note> w części <person>. Dla formatu PIDF zdefiniowano liczne rozszerzenia. XMLowa składni umożliwiające łatwe rozszerzanie przestrzeni znaczników. Jednym z ważniejszych rozszerzeń formatu PIDF jest RPID (Rich Presence Information Data Format). Oprócz podstawowego statusu dostępności zostały zdefiniowane pola zawierające informacje charakteryzujące wiele innych atrybutów szeroko rozumianego statusu obecności i dostępności, m.in. o nastroju, wykonywanych czynnościach, lokalizacji i otoczeniu, w którym znajduje się użytkownik. Place-is określa miejsce, w którym użytkownik aktualnie przebywa. Zawiera także informacje o środkach komunikacji odpowiednich dla owego miejsca. Komunikacja za pomocą wiadomości tekstowych może być niewygodna podczas jazdy samochodem, nie wszędzie wygodna jest transmisja wideo, a rozmowy głosowe nie są możliwe lub są utrudnione w miejscach, gdzie jest bardzo głośno lub wymagana jest zachowanie ciszy. Pole Place-is umożliwia użytkownikowi określenie preferencji komunikacji dogodnych dla miejsca, w którym aktualnie się znajduje. Pole to może być też automatycznie definiowane na podstawie innych dostępnych informacji dotyczących obecności. Place-type typ miejsca, w który znajduje się użytkownik, wybierany z predefiniowanej listy możliwości. Podobnie jak własność Place-is, Placetype pozwala określić odpowiedni typ komunikacji. Przykładem wartości własności Place-type mogą być np.: sala wykładowa, biuro, środek komunikacji miejskiej. 66

67 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Privacy określa takie typy komunikacji, które nie powodują zwrócenia uwagi przez inne osoby w otoczeniu. Umożliwia to dobranie odpowiednich środków komunikacji do celów prywatnych. Mood zawiera informacje o nastroju użytkownika. Atrybut ten umożliwia przewidzenie reakcji użytkownika na próbę skontaktowania się z nim. Przykładowo osoba, która określiła swój nastrój jako Nudzę się, najprawdopodobniej nie będzie miała nic przeciwko temu, żeby do niej zadzwonić. Inaczej może być, gdy użytkownik zdefiniował swój nastrój jako Zdenerwowany. Relationship przechowuje informacje o tym, z kim skontaktujemy się pod adresem danego użytkownika, jeśli nie jest w danej chwili bezpośrednim odbiorcą. Jeśli np. w danym momencie jeden z domowników korzysta z naszego komputera, pole to może być ustawione na Rodzina lub Znajomi. Dzięki temu prywatne wiadomości nie będą rozsyłane do niepożądanych odbiorców. Activities informacja o czynnościach, które użytkownik wykonuje w danym momencie. Lista jest zazwyczaj predefiniowana z możliwością wyboru wartości Inne i dobrania odpowiedniego opisu. Zwykle tego typu informacje są bezpośrednio pobierane z terminarza danego użytkownika. Sphere umożliwia użytkownikowi podzielenie swojego życia na odrębne sfery i zdefiniowanie zasad związanych z komunikacją dla każdej z nich. W danej chwili użytkownik określa sferę, w której się znajduje np. praca, czy osobiste, co pozwala odpowiednim grupom osób na dobranie sposobu komunikacji właściwego dla danej sytuacji. User-input to informacja o tym, ile czasu upłynęło odkąd użytkownik ostatni raz korzystał z danej usługi. Określa to prawdopodobieństwo, z jakim użytkownik będzie dostępny dla danej formy komunikacji Standard obecności i wymiany wiadomości natychmiastowych OMA (Open Mobile Alliance) jest organizacją współpracującą z 3GPP, której celem jest tworzenie jednolitych standardów w zakresie usług dla sieci mobilnych. W ramach działań normalizacyjnych została opracowany zestaw specyfikacji IMPS (Instant Messaging and Presence Service) dotyczących wiadomości natychmiastowych i usługi obecności. W Tabeli 5.1 przedstawiono zalecaną przez OMA przestrzeń atrybutów obecności. Tabela 5.1 Przestrzeń statusów obecności wg OMA Nazwa atrybutu Opis Zalecany OnlineStatus(S) Wskazuje, czy terminal klienta jest zalogowany na serwerze obecności. Tak Registration Wskazuje, czy terminal klienta jest zarejestrowany w sieci mobilnej. Nie ClientInfo Informacja o kliencie. Nie TimeZone Strefa czasowa, w której znajduje się terminal klienta. Nie GeoLocation Geograficzne położenie terminala użytkownika. Nie Address Adres, pod którym znajduje się terminal użytkownika. Nie FreeTextLocation Tekstowy opis lokalizacji, w której przebywa użytkownik. Nie PLMN Kod PLMN (Public Land Mobile Network) sieci, w której zarejestrowany jest terminal użytkownika. Nie 67

68 CommCap Możliwości komunikacyjne użytkownika. Nie UserAvailability(S) Dostępność użytkownika do komunikacji. Tak PreferredContacts Preferencje kontaktowe użytkownika. Nie PreferredLanguage Preferowany język. Nie StatusText(S) Tekst statusu użytkownika (notka). Tak StatusMood Nastrój użytkownika. Nie Alias Nazwa aliasu użytkownika. Nie StatusContent Informacja o mediach w statusie użytkownika. Nie ContactInfo Wirtualna wizytówka (vcard) użytkownika. Nie InfoLink Jeden lub kilka odsyłaczy do dodatkowych informacji. Nie Specyfikacje OMA stanowią ważny krok w kierunku normalizacji modelu obecności, zapewniającego harmonijne współdziałanie usług i aplikacji wykorzystujących informację o statusie obecności i dostępności użytkowników jako katalizator komunikacji Przetwarzanie informacji o obecności Informacja o obecności Obserowanego przechodzi przez kilka etapów od momentu publikacji do momentu ujawnienia jej obserwatorowi. Przebieg przetwarzania informacji o statusie obecności został przedstawiony na Rys Źródła obecności Telefon PSTN, PUBLISH Telefon komórkowy, Klient aplikacji (np. VOIP) Kompozycja Roboczy dokument obecności filtrowanie prywatności NOTIFY Polityka kompozycji Uwierzytelnienie obecności Filtr zdefiniowany przez obserwowanego Roboczy dokument obecności Obserwatorzy finalny NOTIFY dokument obecności Kompozycja finalna dok. obecności Przefiltrowany dokument obecności Filtr obserwatora NOTIFY SUBSCRIBE określenie filtru obserwatora Rysunek 5.11 Przetwarzanie informacji o obecności i statusie dostępności Kierunki rozwoju protokołu SIP oraz jego rola w IMS Protokół SIP zdefiniowany w RFC 3261 służy do nawiązywania sesji multimedialnych w sieci IP. Cechuje się on przejrzystością składni (jest tekstowy i przypomina HTTP) i stosunkowo prostą budową (sześć podstawowych wiadomości: INVITE, ACK, 68

69 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS CANCEL, BYE, REGISTER, OPTIONS). Te cechy wpłynęły na to, że SIP jest najczęściej wybieranym protokołem w implementowaniu systemów komunikacji multimedialnej w sieci Internet. Warto zauważyć, że właśnie zastosowanie SIP w Internecie jest wyróżnione w specyfikacji definiującej protokół. Dzięki modularnej budowie i wbudowanych mechanizmach pozwalających na rozszerzanie funkcji, powstało wiele inicjatyw, których celem było rozszerzenie podstawowej definicji protokołu SIP o nowe mechanizmy, takie jak na przykład realizacja usługi wymiany wiadomości natychmiastowych (Instant Messaging, IM) i usługi obecności użytkownika (Presence). Dotychczas opublikowano ponad 50 różnego rodzaju propozycji rozszerzeń protokołu SIP, które otrzymały status norm IETF RFC 11. SIP został wybrany jako podstawowy protokół sterowania połączeniami i zgłoszeniami w systemie IMS dla sieci UMTS. Prace ETSI i ITU wykorzystują IMS jako rdzeniową część w nowym modelu sieci telekomunikacyjnej - NGN. W związku z tym, SIP został protokołem służącym do sterowania połączeniami i zgłoszeniami w projektowanej publicznej sieci telekomunikacyjnej następnej generacji. Do zastosowań telekomunikacyjnych definicja protokołu zawarta w RFC 3261 nie jest wystarczająca. Przykładowo brakuje w niej mechanizmów umożliwiających interakcje z sieciami PSTN bez utraty określonych informacji o realizowanym połączeniu, mechanizmów pozwalających na kontrolę przez operatora negocjowanych parametrów połączenia potrzebnych do QoS oraz funkcji związanych z taryfikacją. Ze względu na to, standardy 3GPP wprowadzają szereg rozszerzeń i definiują, na potrzeby IMS, tzw. profil protokołu SIP, który jest złożony z bazowego standardu oraz listy rozszerzeń. Tak określony profil stanowi minimalny zestaw mechanizmów, jakie są wymagane w odniesieniu do wszystkich uczestników (terminali, elementów sieci) pracujących w środowisku systemu IMS. Wymagane rozszerzenia SIP wprowadzone w IMS to: Tel-URI - RFC 3966 określa specjalny format adresu używany w SIP dla identyfikacji użytkowników sieci PSTN. wiadomość INFO - RFC 2976 umożliwia przenoszenie sygnalizacji tonowej DTMF. wiadomość 183 Session Progress i PRACK RFC 3262 umożliwiają bardziej szczegółową wymianę informacji dotyczącą procesu zestawiania sesji, co jest wymagane w celu zachowania zgodności z siecią PSTN (współpraca SIP-ISUP). Rekordy NAPTR w systemie DNS dla protokołu SIP - RFC system DNS jest wykorzystywany do lokalizacji serwerów Proxy. wiadomości SUBSCRIBE i NOTIFY - RFC 3265 wprowadzają mechanizm umożliwiający elementom sieci SIP śledzenie rożnego typu zdarzeń. Jest to wykorzystywane między innymi w realizacji usługi obecności, w której terminal subskrybuje status obecności innego użytkownika. wiadomość UPDATE - RFC 3311 rolą tej wiadomości jest umożliwienie zmiany wynegocjowanych parametrów połączenia przed faktycznym rozpoczęciem się sesji. Bez wiadomości UPDATE zmiany takiego typu mogą odbywać się tylko po rozpoczęciu sesji (poprzez mechanizm re-invite). 11 Dane na podstawie IETF WG-SIP ( 69

70 Nagłówek P-Media-Authorization - RFC 3313 przenosi informacje dotyczącą uwierzytelnionych parametrów połączenia. Jest to potrzebne w realizacji przez sieć mechanizmów związanych z QoS. W IMS, każda sesja jest kontrolowana przez element P-CSCF, którego zadaniem jest sprawdzanie czy negocjowane przez użytkowników parametry połączenia (w tym parametry QoS) są możliwe do zagwarantowania. Kompresja SIP - RFC 3320 w celu optymalizacji wykorzystania zasobów w łączach radiowych w IMS stosuje się kompresję wiadomości. Nagłówek Privacy - RFC 3323 umożliwia określanie poziomów prywatności dla sesji. Nagłówki P-Asserted-Identity i P-Preferred-Identity - RFC 3325 nagłówki przenoszą informacje dotyczącą strony inicjującej połączenie. Zgodnie z RFC 3261 taka informacja zawarta jest w nagłówku From, ale ze względu na wymogi związane z taryfikacją (From jest definiowane przez terminal użytkownika) w IMS stosuje się dodatkową informację, która jest wstawiana do wiadomości przez elementy systemu IMS. Nagłówek Reason - RFC 3326 przenosi dodatkowe informacje dotyczące przyczyny określonych zdarzeń w sieci. Wymagany jest w celu zachowania kompatybilności IMS z siecią PSTN. Nagłówek Path - RFC 3327 umożliwia kierowanie wiadomości do użytkownika w sytuacji, w której pomiędzy serwerem rejestrującym (Registrar), a terminalem użytkownika jest serwer Proxy. Nagłówki kategorii P-Headers - RFC 3455 dodatkowe nagłówki takie jak: P-Associated-URI, P-Called-Party-ID, P-Visited-Network-ID, P-Access- Network-Info, P-Charging-Function-Addresses, P-Charging-Vector. Przenoszą informacje związane z siecią dostępową i informacje wykorzystywane do taryfikacji. Wiadomość REFER - RFC 3515 wspomaga realizacje takich usług jak przekazywanie i przekierowywanie połączeń (call transfer) i usług konferencyjnych. Nagłówek Service Route - RFC 3608 umożliwia poprawne kierowanie wiadomości pomiędzy serwerami IMS a terminalami użytkowników. Subskrypcja stanu rejestracji - RFC 3680 umożliwia terminalowi użytkownika pobieranie informacji o stanie rejestracji różnych identyfikatorów Sip-URI, którymi dysponuje. Odbywa się to za pomocą wiadomości SUBSCRIBE i NOTIFY. Większość powyżej opisanych rozszerzeń powstała w wyniku prac 3GPP i ma praktyczne zastosowanie jedynie w systemie IMS. Niektóre dodane mechanizmy mają charakter bardzo szczegółowy i są wynikiem dostosowania protokołu SIP, który pierwotnie był projektowany dla sieci Internet, do wymogów stawianych sieci telekomunikacyjnej. 70

71 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS A B A B INVITE 180 Trying 180 Ringing 200 OK ACK transmisja mediów INVITE 180 Trying 183 Session Progress PRACK 200 OK UPDATE 200 OK 180 Ringing PRACK 200 OK 200 OK ACK transmisja mediów SIP zgodny z RFC 3261 SIP zgodny z IMS Rys.5.12 Scenariusze nawiązania sesji: SIP podstawowy i SIP IMS 12 Jedną z podkreślanych cech protokołu SIP jest jego prostota 13. Aby umożliwić świadczenie usług telekomunikacyjnych, 3GPP wprowadziło szereg rozszerzeń, które mają zastosowanie w systemie IMS. Protokół SIP zaadaptowany do potrzeb IMS cechuje się większą ilością wiadomości, kilkunastoma dodatkowymi nagłówkami i specyficznymi, względem standardu pierwotnego, mechanizmami zdefiniowany w sposób różnicowy w stosunku do RFC Rys.5.12 przedstawia scenariusz nawiązania sesji wykorzystujący podstawową wersję protokołu SIP oraz wersję zgodną z IMS. Aby ustanowić sesję w sieci Internet (SIP zgodny z RFC 3261) wystarczy wymiana 5 wiadomości sygnalizacyjnych, a w IMS niezbędne jest użycie 12 wiadomości. 12 Serwery pośredniczące zostały pominięte. 13 SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń. 71

72 6 Architektura TISPAN NGN usługi FMC 6.1. Wprowadzenie Usługi konwergentne FMC (Fixed Mobile Convergence), to usługi, które łączą funkcjonalność sieci stacjonarnej i mobilnej, takich jak np. uniwersalny numer osobisty, usługa VPN obejmująca sieć stacjonarną i mobilną, czy możliwość wykorzystywania tego samego terminala do korzystania z usług w obu typach sieci. Realizacja konwergencji FMC polegającej na świadczeniu zbliżonego bądź tego samego pakietu usług w sieci stacjonarnej i mobilnej może być uzyskana przez wykorzystanie wspólnej platformy usługowej. Można to obecnie osiągnąć za pomocą serwerów aplikacji wykorzystujących poprzez Parlay/OSA API funkcjonalność sieci stacjonarnych, mobilnych i Internetu. W docelowej architekturze sieci NGN rolę wspólnej platformy usługowej pełni architektura IMS normalizowana przez 3GPP. Konwergencja FMC może być realizowana na wielu poziomach i w wielu obszarach. W dalszym ciągu wyróżnione zostaną przykładowe obszary konwergencji: FMC na poziomie rozliczania usług (One Bill FMC) zapewnia użytkownikowi jeden wspólny rachunek za usługi mobilne i stacjonarne. Ten poziom konwergencji nie ma wpływu na sieć szkieletową. FMC na poziomie sieci (One Core Network FMC) umożliwia wykorzystanie wspólnej sieci szkieletowej z interfejsem do mobilnej i stacjonarnej sieci szerokopasmowej. Opisany poziom konwergencji wymaga realizacji funkcjonalności zapewniającej obsługę użytkowników zarówno w sieci stacjonarnej jak i mobilnej. FMC na poziomie terminala (One Terminal FMC) polega na wykorzystaniu wielosystemowych urządzeń końcowych przystosowanych do współpracy z wieloma sieciami dostępowymi mobilnymi i stacjonarnymi: GSM/UMTS, WiFi, WiMax, Bluetooth, LAN. Dzięki temu użytkownik za pomocą tego samego terminala może uzyskiwać optymalny dostęp do usług za pomocą właściwej w danej chwili i miejscu sieci dostępowej z ewentualnym zapewnieniem ciągłości sesji jeśli przemieszczanie się użytkownika lub inne warunki wymagały zmiany wykorzystywanej sieci dostępowej w trakcie trwającej sesji. FMC na poziomie identyfikacji użytkownika (One Number FMC) umożliwia użytkownikowi posługiwanie się jedną uniwersalną identyfikacją publiczną bez względu na sieci dostępowe za pomocą których użytkownik jest w danej chwili dołączony do sieci. Możliwe jest połączenie opisanych poziomów konwergencji, ale nie jest to konieczne w kontekście usług FMC. W FMC bierze się pod uwagę różne role usługodawcy/operatora, które mogą być realizowane przez pojedynczego usługodawcę/operatora lub różnych usługodawców/operatorów. Prowadzi to do wyróżnienia następujących ról: Dostawca dostępu mobilnego w trybie komutacji łączy (CS). W tej roli operator zapewnia standardowy dostęp radiowy w sieci komórkowej (np. GSM CS: interfejs radiowy, stacja bazowa (BS)/sterownik stacji bazowej (BSC)/MSC). Dostawca dostępu mobilnego w trybie komutacji pakietów (PS). W tej roli operator zapewnia standardowy dostęp radiowy w sieci komórkowej wtrybie pakietowym (np. GSM PS: interfejs radiowy, stacja bazowa (BS), sterownik stacji bazowej (BSC), SGSN/GGSN). 72

73 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Usługodawca IMS oferujący usługi za pomocą własnej platform IMS. Dostawca zarządzanego dostępu WiFi. Usługodawca występujący w tej roli zapewnia możliwość dołączenia do swojej sieci szkieletowej sieci dostępowych WiFi łączonych ewentualnie z dostępem stacjonarnym (np. xdsl, CATV, Ethernet). Usługodawca zapewnia zarządzany stacjonarny interfejs szerokopasmowy do swojej sieci szkieletowej dla punktów dostępowych WLAN (np. WiFi). Punkty dostępowe WLAN mogą, ale niemuszą należeć do usługodawcy i możliwe są następujące przykładowe przypadki. - Domowe sieci WLAN (WiFi). Sieć należy do osoby prywatnej i jest dołączona do sieci szkieletowej za pośrednictwem zarządzanego interfejsu szerokopasmowego (np. xdsl) usługodawcy. - Firmowe sieci WLAN (WiFi). Sieci należące do instytucji lub przedsiębiorstwa dołączone do sieci szkieletowej usługodawcy za pomocą zarządzanego szerokopamowego interfejsu (np. Fast Ethernet). - Publiczne punkty dostępowe WLAN (WiFi hotspots) należące do usługodawcy. Są one dołączone do sieci szkieletowej usługodawcy za pomocą zarządzanego szerokopamowego interfejsu (np. Fast Ethernet). Typowe przypadki, to dostęp w centrach handlowych, hotelach, lotniskach, itp. W kolejnych wersjach UMTS po Release 5 do architektury IMS były wprowadzane następujące elementy wspierające realizację idei FMC: Koncepcja UMA i wsparcie dla I-WLAN jako część Release 6. Uwzględnienie dostępu szerokopasmowego z sieci stacjonarnej oraz zachowywanie ciągłości sesji głosowych i usługi multimedialne w Release 7. Wielosystemowy terminal UMA Komórkowa sieć dostępowa GSM/UMTS Sieć prywatna BSC Mobilna sieć szkieletowa Sieć dostępowaip GANC Generyczna sieć dostępowa Rys. 6.1 Architektura UMA (Unlicensed Mobile Alliance) Równolegle rozwijaną koncepcją realizacji usług FMC była adaptacja przez ETSI TISPAN architektury IMS jako uniwersalnej architektury sieci NGN integrującej domenę mobilną i stacjonarną. Docelową ideą jest tzw. architektura Common IMS opracowywana wspólnie przez 3GPP, ETSI i ITU-T. 73

74 Common IMS 3GPP Sieć szkieletowa WiMaxF Sieć szkieletowa DSLF Sieć szkieletowa Kablowa sieć pakietowa Funkcje dostępu brzegowego UTRAN LTE I-WLAN Sieć dostępowa Sieć dostępowa Sieć dostępowa xdsl Sieć dostępowa FTTH Sieć dostępowa DOCSIS Sieć dostępowa Rys. 6.2 Wizja Common IMS jako docelowej uniwersalnej architektury sieci NGN 6.2. Architektura TISPAN NGN ETSI TISPAN opisuje heterogeniczną architekturę sieciową stanowiącą połączenie różnych podsystemów, w której IMS stanowi rdzeń. ETSI TISPAN opracował model sieci NGN wykorzystującej wiele szerokopasmowych technik dostępu przewodowych i bezprzewodowych. Podsystem NASS umożliwia emulację usług PSTN/ISDN, usług IMS i realizację innych podsystemów takich jak np. IPTV. Współdzielone repozytorium danych stanowi ważny element architektury NGN, ponieważ jest wykorzystywane przez wszystkie podsystemy i działające w nich aplikacje. Model uwzględnia również szereg różnych typów terminali, w tym bramy dostępowe, terminale nomadyczne i terminale mobilne przystosowane do wielu sieci dostępowych IP-CAN (IP- Connectivity Access Network). IMS system jest w kontekście NGN traktowany jako podsystem, a nie wyższa warstwa sterowania, dołączona do domeny Emulacji CS PSTN/ISDN. W IMS jako podstawie architektury NGN wyróżnia się wspólną warstwę aplikacyjną i wspólną warstwę transportową IP. Inne podsystemy, takie jak IPTV i PES (PSTN/ISDN Emulation), są traktowane jako oddzielne autonomiczne systemy z własnym sterowaniem. Pojawienie się systemów PES i IPTV opartych na IMS zmieniło tę sytuację, ponieważ podsystem IMS stał się sterownikiem sesji dla wielu usług w innych podsystemach. Podsystemy NASS i RACS mogą być wykorzystywane wspólnie z innymi podsystemami. NASS odpowiada za umożliwienie dostępu do sieci dla terminali stacjonarnych z przydzielonym adresem IP i zalogowaną lokalizacją. RACS pełni rolę elementu odpowiedzialnego za przydział zasobów w sposób zgodny z regułami polityk sieciowych i wymaganiami usług, zarówno dla sieci dostępowej jak i sieci szkieletowej. W opisywanym modelu rozróżnia się sieć dostępową IP-CAN od szkieletowej sieci transportowej, co umożliwia tym sieciom dostępowym współistnieć mimo różnych wymagań i uwarunkowań. Zwraca się uwagę na funkcję rozproszonej bazy danych między podsystemami, która nadal pełni rolę centralnego repozytorium danych. W tym celu TISPAN NGN definiuje rdzeniowe funkcje IMS, które pozostały w formie przyjętej przez 3GPP, natomiast inne funkcje zostały dodane bądź 74

75 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS zmodyfikowane przez opracowane przez ETSI TISPAN definicje, punkty odniesienia i profile protokołów. W skład architektury TISPAN NGN wchodzą następujące komponenty: UPSF (User Profile Server Function) jako baza danych użytkowników - odpowiednik HSS ale bez funcjonalności HLR (Home Location Register). UAAF (User Access Authorization Function), NACF (Network Access Configuration Function), i CLF (Connectivity session and Location repository Function) wykorzystywane w NASS przy dołączeniu użytkowników do sieci. AGCF (Access Gateway Control Function) służy do dołączenia IMS do lokalnej bramy H.248. Na Rys.4.3 przedstawiono model odniesienia IMS, w którym ukazano interakcję elementów IMS z elementami TISPAN NGN, przez zdefiniowane w modelu ETSI TISPAN punkty odniesienia. Rys. 6.3 Architektura odniesienia ETSI TISPAN NGN oparta na IMS 6.3. Zachowanie ciągłości sesji głosowych - VCC Usługa VCC (Voice Call Continuity) polega na możliwości przekazywania sterowania sesją między domeną komutacji łączy i domeną komutacji pakietów, lub innymi sieciami dostępowymi, bez przerywania bądź pogorszenia jakości czy innego zauważalnego wpływu na dostarczaną usługę. Przekazanie w ramach usługi VCC może mieć miejsce zarówno między dwoma domenami jednego operatora jak również między domenami należącymi do różnych operatorów. Scenariusze usługowe VCC function są sterowane przez aplikacje zlokalizowane w serwerze aplikacyjnym AS IMS. Scenariusze te obejmują następujące funkcje: 75

76 Funkcję selekcji domeny DSF (Domain Selection Function) Funkcję transferu domeny - DTF (Domain Transfer Function) Funkcję adaptacji do sieci z komutacją kanałów (CS Adaptation Function) Funkcję usługową CAMEL (CAMEL Service Function). DSF i DTF odpowiadają za funkcje transferu w trakcie trwającej sesji głosowej. Decyzja o transferze jest podejmowana na podstawie różnych polityk sieciowych i bieżącego status terminala użytkownika UE, i zależy od tego gdzie terminal jest zarejestrowany i czy dysponuje odpowiednią funkcjonalnością. Gdy decyzja zostanie podjęta, to DTF realizuje transfer sesji. Aplikacja VCC z macierzystego IMS generuje informację taryfikacyjną dla wszystkich transferów między domenami dla użytkownika usługi. Scenariusz usługi VCC działają na serwerze aplikacyjnym (AS) zlokalizowanym w domenie sieci macierzystej użytkownika. Usługa wymaga dwusystemowego lub wielosystemowego urządzenia użytkownika współpracującego z sieciami GSM, UMTS i WLAN. Połączenie inicjowane z sieci działającej w trybie komutacji łączy musi zostać zakotwiczone w IMS w celu umożliwienia realizacji transferu międzydomenowego i mechanizmy sterowania sesją odpowiedzialne za transfer są zlokalizowane w IMS. Standard CS Domain techniques are used for rerouting call initiations to IMS. Aplikacja VCC wykorzystuje koncepcję sterowania połączeniem/sesją przez strone trzecią - 3PCC (3rd Party Call Control) do realizacji mobilności międzydomenowej i transferów między domenami. Polega to na inicjowaniu dwóch oddzielnych odnóg połączenia od strony serwera aplikacji AS (nie terminala - UE), a następnie ich połączeniu. Gdy ma nastąpić przekazanie terminal użytkownika - UE musi być zarejestrowany w obu domenach objętych transferem. Następnie tworzony jest nowy kontekst połączenia przez terminal korzystający z VCC do aplikacji VCC w macierzystym IMS. Tworzona jest nowa sesja medialna z zasobami transportowymi przydzielanymi w domenie do której następuje transfer. Aplikacja VCC z macierzystego IMS realizuje transfer między domenami. Gdy transfer sesji już nastąpi zwalniane są zasoby związane z funkcjami przenoszenia wykorzytsywane w domenie źródłowej, z której nastąpił transfer. Zachowanie ciągłości połączeń głosowych VCC (Voice Call Continuity) jest jednym z najważniejszych praktycznych aspektów dotyczących heterogenicznego środowiska NGN/CSN. Zasady VCC zostały zdefiniowane w normach 3GPP, odpowiednio TS i Wymienione normy opisują w jaki sposób jest realizowane przekazywanie obsługi połączeń głosowych między domenami IMS NGN a CSN, czyli IMS NGN CSN i CSN IMS NGN, tak aby zapewnić ciągłość sesji komunikacyjnej. VCC pozwala na to aby użytkownicy dwusystemowych terminali NGN/CSN mogli inicjować i przyjmować połączenia głosowe zarówno w domenie NGN jak i CSN, a także w trakcie trwania połączenia zmieniać domenę, przez którą połączenie jest realizowane z zachowaniem jego ciągłości. Funkcja usługowa VCC została, na razie, zdefiniowana i znormalizowana wyłącznie dla połączeń głosowych. W 3GPP trwają obecnie prace normalizacyjne nad rozszerzeniem VCC o inne strumienie medialne, oprócz głosu, których celem jest zdefiniowanie zasad zachowania ciągłości multimedialnych sesji komunikacyjnych - MMSC (Multimedia Session Continuity). Normalizacja funkcji usługowej VCC ma duże znaczenie praktyczne dla operatorów realizujących proces migracji do sieci NGN, ponieważ jeszcze przez długi jeszcze czas będzie zachodziła potrzeba zapewnienia prawidłowego i niezauważalnego dla użytkowników współdziałania domen NGN i CSN. Obszar współdziałania obejmuje 76

77 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS zarówno terminale użytkowników jak i sieci transportowe w płaszczyznach dostępowej i szkieletowej. Można przedstawić wiele przypadków użycia dla VCC. Przykład użycia. Użytkownik łączy się z IMS przez wąskopasmowy kanał pakietowy, np. używając dostępu GPRS w GSM. Kanał GPRS jest wykorzystywany do celów sygnalizacyjnych, w tym do obsługi sygnalizacji za pomocą protokołu SIP z IMS. W związku z typem wykorzystywanego dostępu usługa VoIP (pakiety RTP) nie będzie zapewniała odpowiedniej jakości, ze względu na opóźnienia pakietów i zbyt wąskie pasmo. Jeśli w opisanej sytuacji będzie też dostępne połączenie w trybie CS, to dzięki implementacji funkcji usługowej VCC, użytkownik będzie mógł uzyskać połączenie głosowe zadowalającej jakości używając trybu łączowego. Sterowanie sesją jest realizowane za pomocą protokołu SIP w IMS. Jeśli później użytkownik zainicjuje kolejne połączenie pakietowe udostępniające szersze pasmo, np. korzystając z punktu dostępowego WLAN lub dostępu 3G HSPA, to może przenieść realizację połączenia głosowego do domeny pakietowej i być może wzbogacić sesję komunikacyjną o wideo i transfer danych w tle. Generalnie, celem VCC jest podjęcie wszelkich działań aby zachować trwające sesje głosowe, w sytuacji gdy użytkownik się przemieszcza między obszarami różniącymi się charakterystyką dostępu. Funkcja usługowa VCC jest realizowana przez gładkie przezroczyste dla użytkownika, przenoszenie, w trakcie trwającej sesji, obsługi strumieni audio między domenami NGN i CS. Wymaga to oczywiście odpowiedniego wsparcia zarówno po stronie terminala jak i sieci. 77

78 7 Model sterowania sesją i realizacja usług w IMS 7.1. Serwery aplikacji i realizacja usług Realizacja scenariuszy usług i aplikacji w środowisku IMS opiera się na wykorzystaniu mechanizmów współpracy z serwerami aplikacyjnymi. Gdy w płaszczyźnie sterowania i sygnalizacji siecią NGN wykorzystującą architekturę IMS wystąpi zdarzenie, które spełnia wcześniej zdefiniowane kryteria, to sterowanie sesją przekazywane jest do właściwych serwerów aplikacyjnych. W architekturze IMS zazwyczaj wykorzystuje się wiele serwerów aplikacyjnych, z których każdy specjalizuje się w dostarczaniu określonych funkcji usługowych i usług lub ich zestawu, np. serwer obecności, serwer aplikacyjny usług głosowych, serwer wideokonferencyjny, serwer usług telefonii multimedialnej MMTel. Użytkownicy korzystają z serwerów aplikacyjnych za pośrednictwem przydzielonego im do obsługi węzła S-CSCF, komunikując się z nim za pomocą protokołu SIP. Zdefiniowano interfejs ISC (IMS Service Control), który definiuje styk sygnalizacyjny dla wszystkich wariantów realizacji serwerów aplikacyjnych. Serwery aplikacyjne mogą być zlokalizowane zarówno w sieci macierzystej jak i w sieciach zewnętrznych zarówno wizytowanych przez użytkownika jak i należących do innych podmiotów. Oznacza to w szczególności, że usługi mogą być oferowane przez niezależnego usługodawcę, który podpisze umowę z operatorami sieci UMTS. W tym sensie, z technicznego punktu widzenia, architektura usługowa IMS jest otwarta. Podczas realizacji usług AS może wykorzystywać interfejs Sh, poprzez który komunikuje się z węzłem HSS za pomocą protokołu Diameter. Począwszy od wersji 6 w specyfikacji IMS zdefiniowano interfejs Ut, między terminalem IMS a serwerem aplikacyjnym, który umożliwia użytkownikowi dodatkowo zarządzać danymi w związku z realizowanymi usługami. Interfejs Ut wykorzystuje protokół XCAP (XML Configuration Access Protocol) umożliwiając użytkownikowi odczytywać, zapisywać oraz modyfikować dane specyficzne dla danej usługi składowane w formacie XML Warianty realizacji serwerów aplikacyjnych Usługi IMS nie są ograniczone do usług opartych na bezpośrednich wykorzystaniu funkcjonalności protokołu SIP. Możliwe jest także świadczenie usług wykorzystujących rozwiązania już stosowane przez operatorów telekomunikacyjnych. Alternatywnymi sposobami realizacji serwerów aplikacyjnych w architekturze IMS są: platforma sieci inteligentnej CSE i architektura CAMEL oparta na protokołach SS7 MAP i CAP CAMEL (Customized Applications for Mobile network Enhanced Logic) oraz architektura OSA (Open Service Architecture) wykorzystująca znormalizowane interfejsy Parlay OSA API. Wyróżnia się, zatem trzy typy serwerów aplikacji, przy czym z punktu widzenia architektury IMS, wszystkie zachowują się tak jak serwer SIP AS i wykorzystują interfejs ISC. Serwer aplikacyjny SIP (SIP AS). SIP AS jest podstawowym rodzajem serwera w architekturze IMS świadczącym usługi SIP, takie jak: obecność, konferencje, wymiana wiadomości. Opcjonalnie serwer ten może posiadać interfejs Sh z bazą danych HSS, pod warunkiem, że AS znajduje się w sieci operatora macierzystego. Interfejs Sh oparty jest na protokole Diameter i pełni funkcje uwierzytelniania, autoryzacji i taryfikacji. Open Service Architecture Service Capability Server (OSA-SCS). OSA-SCS stanowi bramę dla usług Parlay/OSA w IMS. Z jednej strony OSA-SCS posiada interfejs do serwera OSA Application Server, a z drugiej interfejs SIP ISC do S-CSCF. Opcjonalnie OSA-SCS może mieć interfejs Sh z bazą danych HSS. OSA-SCS znajduje się w sieci operatora, jednak serwer OSA AS może znajdować się u strony trzeciej. 78

79 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS IP Multimedia Switching Function (IM-SSF). Ten serwer pozwala na przeniesienie do IMS wielu usług zaimplementowanych w środowisku CAMEL i działających w systemie GSM. IM-SSF po stronie IMS dostępny jest przez interfejs SIP, czyli ISC, natomiast z zewnątrz współpracuje przez interfejs CAP. IM-SSF posiada także interfejs z HSS: Si, oparty na protokole MAP. W zależności od charakteru usługi AS może działać w czterech trybach: SIP Proxy AS przetwarza otrzymane żądanie i odsyła je z powrotem do S- CSCF. W czasie przetwarzania AS może dodać, usunąć lub zmodyfikować zawartość nagłówka SIP zgodnie z zasadami dotyczącymi serwera proxy. Przekierowywanie połączeń to przykładowe zastosowanie tego trybu. Serwer aplikacyjny From: X To: Y Call -ID: Z SIP dialog #1 SIP dialog #1 From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z S -CSCF SIP dialog #1 From: X To: Y Call -ID: Z SIP User Agent w tym trybie AS może inicjować sesję bądź być jej odbiorcą. Przykładowe usługi to poczta głosowa lub budzenie na żądanie. Serwer aplikacyjny SIP dialog #1 From: X To: Y Call -ID: Z S -CSCF SIP dialog #1 From: X To: Y Call -ID: Z SIP Redirect Server AS informuje użytkownika o nowej lokalizacji strony wywoływanej lub alternatywnej usłudze. Ten tryb może być wykorzystany do 79

80 różnego rodzaju przekierowywania połączeń, tym różni się od trybu proxy, że operator może nie brać udziału w sesji, jeżeli nowy adres znajduje się w innej sieci. Typowym zastosowaniem jest usługa przenoszalność numerów. Serwer aplikacyjny From: X To: Y Call -ID: Z SIP dialog #1 SIP dialog #1 S -CSCF From: X To: Y Call -ID: Z SIP Back-to-Back User Agent (B2BUA) B2BUA to dwóch połączonych agentów użytkownika. Pełni funkcję podobną do serwera SIP Proxy, otrzymując żądania i przesyłając je dalej. Różnica polega ta tym, że proxy ma ograniczenia dotyczące modyfikacji pól nagłówka, natomiast B2BUA może wygenerować zupełnie nowe żądania, inicjując nowy dialog SIP. Aplikacją AS B2BUA może być zastrzeganie tożsamości strony nawiązującej połączenie. Serwer aplikacyjny From: X To: Y Call -ID: Z SIP dialog #1 SIP dialog #1 S -CSCF From: X To: Y Call -ID: Z 7.3. Mechanizm wyzwalania usług w serwerach aplikacyjnych Mechanizm odwoływania się do usług zaimplementowanych w serwerach aplikacyjnych wykorzystuje informacje zapisane w profilach użytkownika przechowywanych na stałe w węźle HSS. Podstawową informacją przechowywaną w profilu użytkownika IMS są tak zwane kryteria filtrowania (Filter Criteria). Kryteria filtrowania zawierają specyficzne dla danego użytkownika informacje definiujące kiedy 80

81 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS i w jakich okolicznościach przekierować daną sesję sygnalizacyjną do określonego serwera aplikacyjnego Profil Użytkownika Wszystkie informacje dotyczące użytkownika są na stałe przechowywane w węźle sieciowym HSS. Na Rys. 7.1 przedstawiono uproszczony schemat struktury profilu użytkownika. Profil użytkownika jest przechowywany w formacie XML Schema. Profil Użytkownika Prywatny Identyfikator Użytkownika Profil Usługowy n 1 do n Profil Usługowy 2 Profil Usługowy 1 1 do n Publiczny Identyfikator Użytkownika n Publiczny Identyfikator Użytkownika 2 Publiczny Identyfikator Użytkownika 1 1 do n Kryteria Filtrowania n Kryteria Filtrowania 2 Kryteria Filtrowania Rys.7.1 Struktura profilu użytkownika przechowywana w HSS Podstawową informacją zawartą w profilu jest prywatny identyfikator użytkownika PUI (Private User Identity), do którego przypisany jest dany profil. Każdy profil użytkownika zawiera w sobie jeden lub więcej profili usługowych (Service Profile). Każdy profil usługowy posiada jeden lub więcej publicznych identyfikatorów użytkownika (Public User Identity), dla których dany profil jest aktywny oraz kryteria filtrowania. Kiedy użytkownik rejestruje się w sieci IMS S-CSCF komunikuje się z HSS i pobiera profil użytkownika zawierający kryteria filtrowania. Zarówno profil jak i kryteria filtrowania są dostępne od momentu rejestracji użytkownika Kryteria Filtrowania Kryteria filtrowania określają, które usługi są aktywne dla poszczególnych publicznych identyfikatorów użytkownika. Rys.7.2 przedstawia schemat struktury kryteriów filtrowania. 81

82 Kryteria Filtrowania Priorytet 1 do n Punkt Wyzwalania n 1 do n Punkt Wyzwalania 1 Punkt Wyzwalania Uslugi 2 Punkt Wyzwalania Uslugi 1 Request URI Metoda SIP Nagłówek SIP Przypadek Usługowy Opis Sesji Punkt Wyzwalania Uslugi n Serwer Aplikacyjny SIP URI Obsługa Domyślna Informacja Usługowa Rys.7.2 Struktura kryteriów filtrowania Pierwszym elementem w kryterium filtrowania jest unikatowe pole priorytetu. Określa ono kolejność w jakiej poszczególne kryteria filtrowania będą przetwarzane w ramach tego samego profilu usługowego. S-CSCF w pierwszej kolejności będzie przetwarzał te kryteria które posiadają najwyższy priorytet (1 wskazuje na najwyższy priorytet). Kryteria filtrowania definiują tzw. punkty wyzwalania (Trigger Point). Punkt wyzwalania jest to wyrażenie logiczne determinujące czy dana wiadomość sygnalizacyjna ma zostać przekierowana do serwera aplikacyjnego. Punkt wyzwalania stanowi zbiór niezależnych punktów wyzwalania usługi (Service Point Trigger) stanowiących składowe iloczynu wyrażenia logicznego określającego punkt wyzwalania. Punkty wyzwalania usługi pozwalają odwoływać wielu różnych pól i aspektów wiadomości sygnalizacyjnej SIP. W przypadku gdy nie zostanie zdefiniowany co najmniej jeden punkt wyzwalania usługi wiadomość SIP jest bezwarunkowo przekierowywana do serwera aplikacyjnego. Mechanizm wyzwalania przedstawiono na Rys.7.3. IFC zawiera także informacje o rodzaju sesji (SessionCase), której dotyczy dana reguła IFC. Rodzaj sesji określa czy IFC ma być stosowane do zgłoszeń wychodzących 82

83 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS (Originating Service Control), zgłoszeń przychodzących (Terminating Service Control) lub zgłoszeń przychodzących do użytkownika, który nie jest zarejestrowany w systemie IMS (Terminating Service Control for Unregistered User State). Rys.7.3 Mechanizm wyzwalania w IMS Oprócz zbioru punktów wyzwalania kryteria filtrowania zawierają także zestaw informacji dotyczący serwera aplikacyjnego. Pole SIP URI określa adres serwera aplikacyjnego, do którego zostaną skierowane wiadomości SIP w przypadku spełnienia warunków zdefiniowanych w punktach wyzwalania. W dodatkowym polu Default Handling opisane jest działanie, które podejmie S-CSCF w przypadku gdy komunikacja z serwerem aplikacyjnym będzie nie możliwa. Pole Service Information zawiera przezroczyste w punktu widzenia HSS lub S-CSCF dane, które mogą być niezbędne dla serwera aplikacyjnego by obsłużyć daną wiadomość. Ma to miejsce w przypadku wiadomości, dla których S-CSCF zachowuję się jako klient agenta użytkownika SIP. Informacje zawarte w polu informacja usługowa są dołączane do pola danych wiadomości SIP. Pole to używane jest w przypadku gdy S-CSCF w wyniku przetwarzania kryteriów filtrowania generuje wiadomość rejestracyjną REGISTER i kieruje ją do serwera aplikacyjnego IM-SSF. W takim przypadku wiadomość może zawierać dodatkowe informacje, które mogą zostać użyte przez serwer aplikacji. W tym przypadku mamy do czynienia z przesłaniem wartości IMSI (International Mobile Subscriber Identity) Modele implementacji aplikacji NGN w architekturze usługowej IMS Wprowadzenie W kontekście NGN powstał nowy warstwowy wielopłaszczyznowy model implementacji aplikacji, który obejmuje następujące domeny: Płaszczyznę aplikacji, w której jest możliwe łączenie funkcji usługowych telekomunikacyjnych i internetowych (w szerokim sensie). Zawiera ona 83

84 platformy usługowe z scenariuszami usług, które implementują stronę sieciową usług o wartości dodanej i aplikacji. Kontenery usługowe mogą być implementowane i eksploatowane przez operatora lub przez strony trzecie. Płaszczyznę integracji usług. W celu ułatwienia i przyspieszenia wdrażania usług platformy usługowe wykorzystują rozproszoną infrastrukturę informatyczną złożoną zazwyczaj z wysokowydajnych serwerów, zgodną z koncepcją SOA (Service Oriented Architecture). Płaszczyzna integracyjna ułatwia łączenie kontenerów usługowych z uniwersalnymi funkcjami usługowymi udostępnianymi przez płaszczyznę ekspozycji usług, która jest implementowana przez płaszczyznę czynników sprawczych i mechanizmów usługowych. Płaszczyzna zapewnia bezpieczny i kontrolowany dostęp do funkcji i mechanizmów usługowych udostępnianych przez operatora dla zewnętrznych usługodawców stron trzecich. Płaszczyznę ekspozycji usług i funkcji usługowych z wykorzystaniem API. Płaszczyzna służy do realizacji dostępu do kontenerów usługowych dla płaszczyzny czynników sprawczych. Udostępnia ona zestaw wielu API, które mogą być zdalnie wykorzystywane przez zewnętrzne serwery aplikacyjne przesłaniając szczegóły implementacyjne wykorzystywanych protokołów (typowym elementem właściwym dla tej warstwy jest brama Parlay X). Płaszczyznę czynników sprawczych i mechanizmów usługowych. Zawiera ona czynniki sprawcze właściwe dla architektury usługowej IMS, takie jak obecność, wymiana wiadomości natychmiastowych, konferencja, push-to-talk, xdm, a także czynniki nie-ims, takie jak: lokalizacja, katalogi, profile użytkownika, strumieniowanie treści multimedialnych, synchronizacja urządzeń, książka adresowa. Płaszczyznę koordynacji usług i aplikacji. Typowo reprezentuje ona funkcje SCIM IMS, które służą np. do realizacji tradycyjnych usług IN w sposób wykorzystujący teleusługi IMS, np. usługę VPN obejmującą sieć mobilną i stacjonarną. Plaszczyznę sterowania usługami. Płaszczyznę transportową. Na Rys.7.4 przedstawiono model realizacji usług i aplikacji NGN oparty na architekturze IMS typowo przyjmowany przez operatorów. Uwzględnia on ekspozycję IMS na integrację z aplikacjami typu Web

85 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Rys.7.4 Model realizacji usług i aplikacji NGN oparty na architekturze IMS Źródło: Khalid Al-Begain, Chitra Balakrishna, Luis Angel Galindo, Davide Moro - IMS: A Development and Deployment Perspective Overview, Features, and Description, Wiley & Sons,

86 IMS i Web Architektura usługowa IMS została przyjęta jako podstawa do realizacji usług następnej generacji zarówno w sieciach mobilnych i stacjonarnych. Jedną z kluczowych idei IMS jest zapewnienie środków technicznych realizacji usług konwergentnych łączących funkcjonalność tradycyjnej telekomunikacji, takich jak usługi głosowe i lokalizacyjne, z możliwościami ewoluującego Internetu, charakteryzowanymi hasłem Web 2.0. Na pierwszy rzut oka usługi Web 2.0 i usługi IMS są do siebie bardzo podobne, jednak w kilku zasadniczych kwestiach, bardzo się różnią. W modelu internetowym oferuje się otwarte, dostępne bez opłat, ale bez gwarancji jakości. W modelu IMS przyjęto model zamknięty - walled garden, w którym operator zachowuje ścisłą kontrolę nad oferowanymi usługami. W efekcie obserwowany jest żywiołowy rozwój usług internetowych Web 2.0 i znacznie wolniejszy usług IMS. W tym kontekście pojawia się pytanie w jaki sposób zaadaptować IMS by wykorzystać możliwości koncepcji Web 2.0. Głównym problemem jest otwarcie architektury IMS, które umożliwiałoby tworzenie nowych usług przez strony trzecie tworzące aplikacje typu Web 2.0. Sukces i popularność idei Web 2.0 opiera się na znalezieniu środków technicznych umożliwiających realizację idei długiego ogona (ang. long tail), która pozwala spełnić bardzo zróżnicowane wymagania licznych, ale niszowych grup użytkowników. Operatorom trudno jest samodzielnie spełnić takie wymagania i jedynym praktycznym rozwiązaniem jest udostępnienie usług telekomunikacyjnych, jako jednego ze źródeł danych w modelu mashup-up - mieszanki treści i funkcji z wielu rozproszonych źródeł udostępnianych za pomocą zintegrowanego interfejsu użytkownika. Terminem mieszanka treść określa się serwisy internetowe wykorzystujące wiele źródeł informacji i usług. Charakterystyczne dla mieszanek treści jest to, że łączenie danych następuje w przeglądarce internetowej. Do łączenia tych komponentów nie wykorzystuje się technik znanych z przemysłowych rozwiązań informatycznych, takich jak: CORBA, czy usługi sieciowe SOAP. Zamiast tego, stosuje się proste interfejsy programistyczne API oparte na wymianie dokumentów XML za pomocą protokołu HTTP. Przykładem tego rodzaju API jest interfejs Google Data, używany między innymi przez aplikację Google Calendar. Z technicznego punktu widzenia, Google Data, podobnie jak większość interfejsów serwisów Web 2.0, zaprojektowany jest zgodnie koncepcją REST (REpresentational State Transfer) [38]. W związku z tym proponuje się otwarty interfejs do usług telekomunikacyjnych REST IMS API, opracowany według zasad koncepcji REST. W realizacji praktycznej platformę stanowi serwer lub grupa serwerów aplikacji SIP, obsługujących interfejsy ISC oraz Sh do systemu IMS. Protokołu XCAP używa do zarządzania grupami na serwerze XDMS (XML Data Management Server). Serwer obecności wykorzystywany jest do przekazania klientom Web 2.0 informacji o stanie obecności. Z punktu widzenia usługi obecności, platforma zachowuje się jak obserwator. Docelowymi klientami zaproponowanej platformy usługowej mają być przede wszystkim mieszanki treści oraz inne aplikacje Web 2.0. Po stronie interfejsu HTTP użytkownicy interfejsu identyfikowalni są poprzez adres URI, w ten sposób mają dostęp do swoich zasobów. W systemie IMS traktowani są jak użytkownicy aplikacyjni z adresem PSI (Public Service Identity). Przykładowej aplikacji o nazwie mashup, po zarejestrowaniu się, zostanie przydzielony adres Jednocześnie w systemie IMS zostanie zarejestrowany użytkownik usługowy z adresem PSI sip:mashup@operator.com, wykorzystywany do komunikacji z agentami użytkowników SIP oraz innymi serwerami aplikacji. 15 W rozdziale wykorzystano wyniki pracy dyplomowej Bartłomieja Kołakowskiego [28]. 86

87 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS REST IMS API eksponuje podstawowe funkcjonalności telekomunikacyjne, czyli sterowanie sesją, wysłanie i odbieranie wiadomości tekstowych i multimedialnych, obserwację stanu obecności oraz dodano funkcję wyzwalaczy. Oprócz wymienionych funkcji usługowych, interfejs umożliwia administrację platformą. Eksponowany interfejs opiera się na protokole HTTP, będącym protokołem synchronicznym (żądanie odpowiedź), w którym role klienta i serwera są wyraźnie rozdzielone. Uniemożliwia to zastosowanie mechanizmu notyfikacji, a co za tym idzie obserwacji zdarzeń. Zaproponowano dwa rozwiązania tego ograniczenia, pierwszy to mechanizmy odświeżania informacji o zasobach. Drugim są wyzwalacze, dające możliwości zdefiniowania reakcji na skończony zbiór zdarzeń w sieci. Pozwalają ona klientowi określać akcje, do których należą dołączenie do grupy, wysłanie wiadomości, bądź ustanawianie sesji, które mają zostać wywołane, w przypadku spełnienia określonych warunków związanych ze zamianą stanu obecności oraz lokalizacji. W tej usłudze platforma, poinstruowana przez klienta HTTP, przejmuje funkcję monitorowania zdarzeń w IMS. Telekomunikacyjne usługi sieciowe REST pokazują, że otwarcie sieci telekomunikacyjnych NGN, zgodne ze specyfiką środowiska Web 2.0, jest technicznie możliwe. Przedstawioną propozycję należy traktować jako szkielet interfejsu, zawierający podstawowe funkcjonalności, z możliwością ich rozszerzania o nowe, w miarę bieżących potrzeb. Kluczową sprawą w stosowaniu REST jest: przestrzeganie podstawowych reguł architektury zasobowej: eksponować bogatego zbióru zasobów prawidłowo identyfikowanych za pomocą adresów URI, zdefiniować operacje na tych zasobach na podstawie jednolitego interfejsu, przypisać zasobom reprezentacje, łatwe do przetworzenia przez klientów, a także zawierające odsyłacze do innych zasobów. Prawdopodobnie różne rodzaje zewnętrznych interfejsów będą współistnieć dla różnych zastosowań. Parlay-OSA oraz Parlay-X mogą być wykorzystywane przez większych partnerów, posiadających rozbudowaną infrastrukturę informatyczną oraz wymagających komunikacji przy pomocy dobrze wyspecyfikowanych protokołów, jakim jest SOAP. Usługi sieciowe REST mogą znaleźć zastosowanie w przypadkach, w których ważniejsza będzie prostota interfejsu i łatwość wkomponowania w inne usługi. Model REST jako zgodny z architekturą sieci Web, powinien szczególnie nadawać się dla serwisów internetowych zintegrowanych z usługami telekomunikacyjnymi Model realizacji usług - dyskusja Mechanizm kierowania wiadomości związanych z sesją do serwerów aplikacyjnych, oparty o syntaktyczną analizę wiadomości SIP, w zależności od warunków zdefiniowanych przez IFC i zawartych w profilu użytkownika, jest podstawą modelu sterowania sesją i realizacji usług w architekturze usługowej IMS. Daje on dużą elastyczność w budowaniu usług w środowisku wielu serwerów aplikacyjnych. Ta elastyczność wynika głównie z tego, że analiza wiadomości jest niskiego poziomu (syntaktyczna). Takie podejście pociąga za sobą brak bezpośredniego związku pomiędzy scenariuszem usługi (semantyką usługi), a regułami kierowania zgłoszeń, które wyzwalają wykonanie tej usługi. Ze względu na to definicje IFC powinny być tworzone z uwzględnieniem wieloznaczności protokołu SIP, co może rodzić dużą złożoność tego procesu i wymaga opracowania odpowiednich narzędzi, których obecnie brak. 87

88 Potrzeba dokładnych definicji reguł IFC jest też także wymagana ze względu na znaczny wzrost ruchu sygnalizacyjnego przy stosowaniu przekierowania wiadomości SIP na serwery aplikacyjne. Dokładne definicje powinny uwzględniać charakter usługi, (co jest trudne) i minimalizować sytuacje, w których zgłoszenie jest kierowane do serwera aplikacyjnego, pomimo że scenariusz usługi tego nie wymaga. W środowisku, w którym wiele niezależnych usług jest realizowana na jednym serwerze aplikacyjnym, występują problemy związane z interakcjami pomiędzy scenariuszami usługowymi. W takich sytuacjach mechanizm IFC realizowany w serwerze S-CSCF nie ma zastosowania i wymagana jest implementacja komponentu odpowiedzialnego za właściwe kierowanie zgłoszeń w ramach serwera aplikacyjnego. To rozwiązanie zostało nazwane SCIM, lecz nie zostało ustandaryzowane i w praktyce jest realizowane na kilka różnych sposobów w zależności od implementacji serwera aplikacyjnego. Może to skutkować nieprzenaszalnością komponentów realizujących usługi pomiędzy różnymi serwerami aplikacyjnymi. 3GPP rozwijając architekturę usługową IMS wzbogaciła mechanizm wyzwalania aplikacji ATA (Application Triggering Architecture) w celu umożliwienia realizacji bogatych usług multimedialnych. Jednak zwiększenie elastyczności i funkcjonalności IMS wpływa na zmniejszenie wydajności systemu. W znormalizowanych obecnie wersjach IMS, 3GPP zdefiniował algorytm wyzwalania usług STA (Service Triggering algorithm) oparty na tzw. Początkowych kryteriach filtrowania - ifc (initial Filter Criteria). Mechanizm ten jest dosyć złożony i powoduje zwiększenie czasu ustanowienia sesji w IMS wpływając na przepustowość systemu. Decyzja czy dane zgłoszenie będzie skierowane do określonego serwera aplikacyjnego AS (Application Server) jest podejmowana w serwerze S-CSCF na podstawie profilu użytkownika. Reguły przekierowania zgłoszenia oparte są na analizie składniowej wiadomości SIP. Profil zawierający filtry IFC definiuje rodzaje wiadomości (nazwy wiadomości sygnalizacyjnych, np. INVITE, BYE, SUBSCRIBE, itd.), występowanie lub nie określonych nagłówków we wiadomościach SIP oraz elementy opisu sesji zawartej w SDP. IFC ma postać wyrażeń logicznych łączących poszczególne reguły. Opisana analiza wiadomości SIP, uwzględniająca reguły odwołujące się do atrybutów wszystkich poziomów w wiadomościach SIP i treści wiadomości opisanych w SDP, jest niestrukturalnym mechanizmem niskiego poziomu, odnoszącym się do składni przetwarzanych wiadomości. Takie rozwiązanie daje potencjalnie bardzo dużą elastyczność i swobodę projektantowi usług, ale jednocześnie, przez swoją niestrukturalność jest kłopotliwe w stosowaniu i stwarza niebezpieczeństwo błędów. Wynika to z braku jasnych reguł, które pozwoliłyby w jednoznaczny sposób odwzorowywać atrybuty i mechanizmy sygnalizacji SIPowej na funkcjonalność usługową. Innymi słowy, prowadzi do niejawnej semantyki projektowania usług. Projektowanie reguł filtracji wymaga, co najmniej, wypracowania dobrych praktyk, i na podstawie wnikliwej analizy doprowadzić do zdefiniowania, co najmniej, reguł cząstkowych, odnoszących się do wybranych kategorii usług i funkcji usługowych IMS i usługi IPTV Rozwój systemów telewizji cyfrowej jest obserwowany od wielu lat. Jego rezultatem jest powstanie systemów cyfrowej telewizji satelitarnej i naziemnej, a następnie rozwiązań technicznych umożliwiających dostarczanie usług telewizyjnych w sieciach szerokopasmowych przewodowych i bezprzewodowych. Udostępnianie usług telewizyjnych wykorzystujących protokół IP, określanych terminem IPTV (Internet Protocol-based Television) w sieciach szerokopasmowych stało się możliwe dzięki nowym typom sieci i opracowaniu ulepszonych algorytmów kodowania mediów. Przejawem konwergencji usług stało się włączenie IPTV przez operatorów 88

89 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS telekomunikacyjnych do pakietów usług trzy w jednym (triple play) i cztery w jednym (quadruple play) obejmujących szerokopasmowy dostęp do Internetu, usługi telefoniczne (stacjonarne i mobilne) i telewizję cyfrową IPTV wraz z towarzyszącymi udogodnieniami (np. wideo i treści na na życzenie). Mamy w tym przypadku do czynienia z konwergencją usługową opartą na uniwersalności protokołu IP stosowanego do jednolitej realizacji sieciowej usług głosowych, wideo, transmisji danych i udostępniania treści. Różne rozwiązania techniczne IPTV są wdrażane przez operatorów i jednocześnie trwaja intensywne prace normalizacyjne. Brak obecnie kompletnych norm dotyczących IPTV powoduje, że usługi są realizowane w oparciu o specyficzne firmowe rozwiązania, które nie są integrowane z architekturą NGN. Architektura usługowa IMS jest powszechnie uważana za jedno z głównych rozwiązań technicznych do kompozycji, orkiestracji i dostarczania usług NGN. Wykorzystanie IMS do implementacja usług IPTV otwiera wiele nowych możliwości, z których najważniejsze to: mobilny dostęp, integracja z usługami NGN, personalizacja profili usługowych, adaptacja mediów, a także łączenie usług głosowych, usług transmisji danych, wideo i usług mobilnych w pakiety usługowe cztery w jednym. Ponadto wykorzystanie uniwersalnej architektury usługowej IMS do realizacji usług IPTV ma następujące zalety: Zintegrowana i ujednolicona obsługa rejestracji i uwierzytelniania użytkowników (jeden wspólny mechanizm logowania, ujednolicona identyfikacja użytkownika wspólna dla wszystkich usług). Zarządzanie kontem użytkownika, centralizacja profilu użytkownika, elastyczne mechanizmy personalizacji i kształtowania cech usług. Zarządzanie sesją, ruting, mechanizmy wyzwalania usług, adresacja i numeracja. Interakcja z mechanizmami i komponentami wspomagającymi realizację usług w NGN, takimi jak np. obecność, wymiana wiadomości natychmaiastowych, zarządzanie grupami użytkowników. Wspomaganie przekazywania sesji między sieciami i nomadycznego wzorca korzystania z usług. Sterowanie QoS i funkcjami przenoszenia. Ujednolicenie mechanizmów taryfikacji i rozliczania. Neutralność dostępowa - obsługa wielu rodzajów sieci i technik dostępu. Uwzględnienie dostępu do treści generowanych przez użytkowników objęte pracami w TISPAN Release 3. Rozwiązanie IPTV oparte na IMS umożliwiają dostosowanie strumieni danych IPTV do dostępnych zasobów sieciowych i własności terminali użytkowników. Dzięki temu użytkownicy mają dostęp do usług IPTV nie tylko stacjonarnie w warunkach domowych, ale również w ruchu, za pomocą terminala mobilnego. W ten sposób wykorzystanie architektury IMS pozwala zrealizować konwergentną usługę IPTV dostępną zarówno w trybie stacjonarnym jak i mobilnym. Fakt, że w IMS do sterowania sesjami jest wykorzystywany protokół SIP umożliwia elastyczne sterowanie usługami IPTV (np. użytkownik może za pomocą swojego terminala IMS zdalnie sterować swoją nagrywarką IPTV). Innym przykładem jest 89

90 zachowanie ciągłości sesji IPTV przy przejściu między różnymi terminalami, np. między komputerem przenośnym a odbiornikiem TV lub terminalem mobilnym Przegląd normalizacji IPTV ETSI TISPAN IPTV W TISPAN NGN R2, wiele specyfikacji dotyczy wymagań na usługi IPTV i wariantów architektur, bez IMS oraz wykorzystujących IMS. W dalszym ciągu uwaga zostanie skupiona na wariancie wykorzystującym do realizacji usług IPTV architekturę usługową IMS. Na Rys.7.5 przedstawiono schemat normalizacji ETSI TISPAN w zakresie usług i architektury systemów IPTV. IPTV oparta na IMS Dedykowany podsystem IPTV Rys.7.5 Zakres normalizacji ETSI TISPAN dotyczącej IPTV ITU-T FG IPTV Dokumenty analizują różne aspekty IPT: usługi, architekturę, oprogramowania pośredniczące (IPTV middleware), bezpieczeństwo, itd. Planowane jest włączenie IPTV w kolejnej wersji zaleceń ITU-T dotyczących NGN GPP MBMS 3GPP specyfikuje usługę MBMS (Multimedia Multicast/Broadcast Service) głównie w celu zdefiniowania sprawnego sposobu dostarczania i sterowania usługami multicast i rozsiewczymi w sieciach mobilnych 3G. W obecnej chwili usługi MBMS są ograniczone do obsługi pasma dla kanałów telewizji mobilnej, tzn. zwykle do przepływności do 200 kb/s. Zaletą rozwiązania MBMS w porównaniu z DVB-H (DVBhandheld) jest to, że wykorzystywana jest ta sama wspólna infrastruktura sieci IP 3G co dla usług dostępu do Internetu i transmisji danych. 90

91 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS OMA BCAST The Open Mobile Alliance (OMA) wprowadza pojęcie mobile broadcast services enabler w celu podjęcia problemów funkcjonalnych, które są w dostatecznym stopniu generyczne aby stanowić wspólny element dla różnych usług rozsiewczych, które mogą zostać zdefiniowane i zaimplementowane w sposób niezależny od usług przenoszenia. Obejmują one następujące obszary funkcjonalne: przewodnik po usługach, dystrybucja plików, dystrybucja strumieni medialnych, zabezpieczenie i usług, ochronę treści, interakcję z usługą, udostępnianie usług, udostępnianie i konfigurację urządzeń końcowych, powiadomienia, itd. W ogólności, zakłada się, że mobilne usługi rozsiewcze powinny umożliwiać dystrybucję treści - bogatych, interaktywnych i wymagających szerokiego pasma dla mediów, dla dużej liczby mobilnych odbiorców IETF Standardy IPTV wykorzystują istniejące protokoły zdefiniowane przez IETF, takie jak SIP do sterowania sesjami, RTSP do sterowania mediami w usługach treści na żądanie CoD (Content on Demand), a także IGMP dla IPv4 i MLD (Multicast Listener Discovery) dla usług wykorzystujących multicast w IPv6. Do transportu mediów wykorzystywany jest protokół RTP. Pojawiły się także propozycje norm dotyczące opisu kanałów IPTV służące do jednoznacznej identyfikacji usług IPTV Ewolucja rozwiązań i architektury IPTV ku NGN Obserwując stan wdrożeń i proces normalizacji usług IPTV można je zilustrować diagramem wyróżniającym główne tendencje i kierunki ewolucji w kontekście sieci NGN i architektury IMS. Architektura IPTV nie-ngn reprezentuje bieżący stan wdrożeń oferowanych na świecie i Polsce usług IPTV. Z technicznego punktu widzenia jest możliwa implementacja pewnego zakresu współpracy rozwiązań IPTV nie-ngn z podsystemami NGN, ale generalnie wykorzystywane jest odrębne sterowanie i warstwa aplikacji dla usług IPTV oparte na specyficznych zamkniętych rozwiązaniach firmowych (własnym oprogramowaniu pośredniczącym middleware). Architektura IPTV NGN nie wykorzystująca IMS umożliwia interakcję i współpracę, przez zdefiniowane punkty odniesienia, między dedykowanymi funkcjami IPTV (np. funkcjami sterowania IPTV) i niektórymi istniejącymi elementami architektury NGN, takimi jak np. elementy sterowania transportem dla podsystemów RACS (Resource Admission and Control Subsystem) i NASS (Network Attachment Subsystem). W tego typu rozwiązaniu, dedykowany podsystem IPTV subsystem w architekturze NGN jest używany do realizacji całej wymaganej funkcjonalności usług (np. sterowanie IPTV, profile użytkowników, funkcje interfejsu z użytkownikiem, itp.) i integracji składników systemu IPTV w ramie architektonicznej NGN. Architektura IPTV wykorzystująca IMS specyfikuje funkcje IPTV odwołując się do podsystemu IMS i umożliwia uniwersalne wykorzystywanie funkcjonalności IMS i mechanizmów inicjowania usług i sterowania właściwych dla protokołu SIP. W dalszym ciągu opracowania zostanie to przedstawione bardziej szczegółowo. Architektura IPTV NGN nie-ims i konwergentna IMS stanowi połączenie architektur NGN IPTV wykorzystujących IMS i nie odwołujących się do IMS we wspólnej konfiguracji systemu świadczącego konwergentne usługi IPTV. 91

92 Każdy krok ewolucji wprowadza dodatkową funkcjonalność cechy systemu wzbogacające usługi IPTV. Na przykład, poprawę QoE dla użytkowników końcowych i konwergencję usług TV z usługami telekomunikacyjnymi i innymi interaktywnymi usługami multimedialnymi. Szybkie i łatwe wprowadzanie nowych usług oraz zmniejszenie kosztów eksploatacji mogą być dodatkowymi ważnymi przesłankami ewolucji systemów IPTV. Rys.7.6 IPTV dwie opcje w architekturze TISPAN NGN IMS i nie-ims W porównaniu z specyficznymi zamkniętymi rozwiązaniami IPTV, NGN-IPTV charakteryzuje się znormalizowanymi funkcjami sterowania i dostarczania mediów. Podsystem IPTV oparty na NGN umożliwia integrację z profilami użytkowników NGN i interfejsami do podsystemów RACS i NASS NGN, co pozwala na realizację spersonalizowanych dodatkowych funkcji usługowych IPTV i bardziej efektywne wykorzystanie zasobów sieci. Ewolucja ku IPTV opartego na IMS lub NGN IMS i nie-ims-konwergentną IPTV opiera się na spostrzeżeniu, że IMS stanowi zunifikowaną uniwersalną architekturę sterowania usługami o coraz większym znaczeniu dla przyszłych usług NGN. Dlatego IPTV wykorzystująca IMS może być wewnętrznie zintegrowana z platformami IMS NGN. Nie należy jednak oczekiwać, że w przyszłości wszystki usługi NGN będą wykorzystywać architekturę IMS. W tej sytuacji należy się spodziewać w przyszłości różnorodnych rozwiązań konwergentnych i stanowiących połączenie systemów z IMS i bez IMS Modele realizacji usług IPTV w NGN Rozważa się trzy następujące modele implementacji usług IPTV w architekturze TISPAN NGN: Architektura IPTV nieuwzględniająca wymagań sieci NGN początkowe podejście do realizacji platformy IPTV, które doczekało się licznych implementacji na całym świecie. Polega ono na użyciu specyficznej dedykowanej platformy, która nie jest zgodna z normami ETSI. Platforma taka zwykle wykorzystuje rozwiązania własne firmowe i niezgodne ze standardami oraz prototypowe protokoły. Docelowo zakłada się,, że platforma IPTV tego typu powinna za pomocą protokołu IP dostarczyć użytkownikowi końcowemu 92

93 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS zestaw usług obejmujący połączenia głosowe, szerokopasmowy dostęp do Internetu oraz telewizję cyfrową. Architektura IPTV zgodna z normami NGN ETSI TISPAN niewykorzystująca jednak podsystemu IMS. Usługi IPTV są realizowane przez specjalizowaną i dedykowaną platformę, która łączy się z pozostałymi podsystemami sieci NGN za pomocą otwartych standardowych interfejsów. Dzięki temu zarządzanie dostępem do zasobów usługi może być zintegrowane do modułu RACS a dostęp do usługi kontrolowany przez NASS. Architektura IPTV zgodna z normą NGN i zrealizowana na platformie IMS usługa telewizji cyfrowej IP zrealizowana w architekturze IMS, tzn. wykorzystuje wyłącznie mechanizmy i protokoły zdefiniowane dla tej architektury przy zachowaniu zgodności ze normami ETSI i 3GPP. Rozwiązanie to ma wiele zalet, ale jego realizacja jest skomplikowana, ponieważ podsystem IMS narzuca wymagania QoS, które przy obecnych rozwiązaniach sieciowych mogą być trudne do spełnienia przez usługę strumieniowania treści multimedialnych. Realizacja usługi IPTV w architekturze IMS umożliwia wykorzystanie jej wbudowanych funkcji usługowych, takich jak: obecność, wymiana wiadomości natychmiastowych i informacji lokalizacyjnej. Umożliwia to budowanie usług konwergentnych, które udostępniając możliwość komunikacji i dostęp do danych multimedialnych uwzględniają kontekst połączenia Realizacja usług IPTV z wykorzystaniem IMS Wykorzystanie IMS do implementacja usług IPTV otwiera wiele nowych możliwości, z których najważniejsze to: mobilny dostęp, integracja z usługami NGN, personalizacja profili usługowych, adaptacja mediów, a także łączenie usług głosowych, usług transmisji danych, wideo i usług mobilnych w pakiety usługowe cztery w jednym. Ponadto wykorzystanie uniwersalnej architektury usługowej IMS do realizacji usług IPTV ma następujące zalety: Zintegrowana i ujednolicona obsługa rejestracji i uwierzytelniania użytkowników (jeden wspólny mechanizm logowania, ujednolicona identyfikacja użytkownika wspólna dla wszystkich usług). Zarządzanie kontem użytkownika, centralizacja profilu użytkownika, elastyczne mechanizmy personalizacji i kształtowania cech usług. Zarządzanie sesją, ruting, mechanizmy wyzwalania usług, adresacja i numeracja. Interakcja z mechanizmami i komponentami wspomagającymi realizację usług w NGN, takimi jak np. obecność, wymiana wiadomości natychmaiastowych, zarządzanie grupami użytkowników. Wspomaganie przekazywania sesji między sieciami i nomadycznego wzorca korzystania z usług. Sterowanie QoS i funkcjami przenoszenia. Ujednolicenie mechanizmów taryfikacji i rozliczania. Neutralność dostępowa - obsługa wielu rodzajów sieci i technik dostępu. Uwzględnienie dostępu do treści generowanych przez użytkowników objęte pracami w TISPAN Release 3. 93

94 Rozwiązanie IPTV oparte na IMS umożliwiają dostosowanie strumieni danych IPTV do dostępnych zasobów sieciowych i własności terminali użytkowników. Dzięki temu użytkownicy mają dostęp do usług IPTV nie tylko stacjonarnie w warunkach domowych, ale również w ruchu, za pomocą terminala mobilnego. W ten sposób wykorzystanie architektury IMS pozwala zrealizować konwergentną usługę IPTV dostępną zarówno w trybie stacjonarnym jak i mobilnym. Fakt, że w IMS do sterowania sesjami jest wykorzystywany protokół SIP umożliwia elastyczne sterowanie usługami IPTV (np. użytkownik może za pomocą swojego terminala IMS zdalnie sterować swoją nagrywarką IPTV). Innym przykładem jest zachowanie ciągłości sesji IPTV przy przejściu między różnymi terminalami, np. między komputerem przenośnym a odbiornikiem TV lub terminalem mobilnym. Xa SSF SDF Sh Ut Sh IPTV Service Control Functions CoD-SCF BC-SCF N-PVR-SCF IPTV Media Control Functions CoD-MCF BC-MCF N-PVR-MCF UPSF Cx ISC Application and IPTV Service Functions Xp IPTV Media Functions UE ISC Gm Core IMS y2 IPTV Media Delivery Functions CoD-MDF e2 Gq' BC-MDF Xc Xd NASS e4 RACS Transport Control Functions Transport Functions Transport Processing Functions N-PVR-MDF Media Delivery, Distribution & Storage Rys.7.7 Architektura funkcjonalna IMS IPTV wg ETSI TS Do zarządzania sesjami IPTV (sygnalizacja SIP) wykorzystywana jest standardowa architektura rdzenia IMS. Strumienie medialne sesji ustanowionych dla usługi IPTV nie przechodzą przez rdzeń IMS. Zgodnie z architekturą IMS obsługę sesji realizują jednostki funkcjonalne CSCF (Call Session Control Functions), które są odpowiedzialne za ustanawianie sesji multimedialnych między abonentami i przygotowanie żądanych przez nich usług. Odkrywanie i selekcja usług (SDF i SSF) Składniki funkcjonalne SDF i SSF dostarczają informację, która jest niezbędna dla UE w celu wyboru usługi IPTV. Element funkcjonalny SDF odpowiada za dostarczanie informacji o usługach IPTV dostępnych dla danego użytkownika (spersonalizowane odkrywanie usług). W rozwiązaniu IPTV wykorzystującym IMS, jedne lub więcej składników funkcjonalnych SSF jest używanych do dostarczenia informacji o usługach oraz spersonalizowanych informacji o preferencjach użytkownika. Ponadto wymagana jest informacja z elektronicznego przewodnika po programach EPG (Electronic Program Guide) lub przewodnika po programach usługi zawierającego metadane, a także informacja o źródłach, z których są dostarczane. 94

95 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Funkcje sterowania usługami IPTV Jednostki SCF obsługują żądania związane z IPTV i realizują zadania sterowania usługami i sesjami dla wszystkich usług IPTV. Wymienione jednostki funkcjonalne realizują także współpracę z rdzeniem IMS na poziomie płaszczyzny sterowania usługami. Lista głównych zadań SCF obejmuje: Inicjowanie sesji i sterowanie usługami dla usług IPTV. Interakcja z rdzeniem IMS i jednostkami S-CSCF w celu odbioru, walidacji i realizacji żądań użytkowników dotyczących usług IPTV. Uwierzytelnienie usługi i walidacja żądań użytkowników dotyczących wybranych treści, w oparciu o informację zawartą w profilu użytkownika. Wybór właściwych funkcji sterowania mediami i dostarczania mediów w usłudze IPTV. Dopasowywanie usług do preferencji użytkownika, np. dobór listy prezentowanych kanałów TV w oparciu o profil użytkownika. Kontrolę stanu konta użytkownika Funkcje IPTV związane z obsługą mediów Jednostkami fukcjonalnymi zajmującymi się obsługą mediów w IPTV są MCF i MDF. Istotnym zalożeniem projektowym funkcji obsługi mediów jest realizacja hierarchicznej i elastycznej architektury systemu dostarczania mediów umożliwiającego sprawne dostarczanie treści w rozproszonym środowisku.. Do głównych zdań sterowania mediami MCF należą: Wybór właściwych funkcji dostarczania mediów MDF. Przekazywanie treści do sieci dystrybucyjnych i sterowanie dystrybucją zasobów (pakiety treści) do jednostek funkcjonalnych dystrybucji treści i terminali użytkownika. Egzekwowanie polityk dotyczących dystrybucji treści i zarządzania oferowanymi treściami. Zarządzanie zasobami pamięciowymi w sieci dystrybucyjnej i przy dostarczaniu treści. Odzworowanie identyfikacji treści lokalizacji treści na właściwy MDF realizujący dostarczanie tych treści. Interakcja z urządzeniami użytkownika, np. obsługa żądań strumieniowania wideo w celu zapisu za pomocą aplikacji nagrywarki cyfrowej do użytku osobistego później. Sterowanie sieciową nagrywarką wideo PVR (Personal Video Recorder) i obsługą przesunięcia czasowego dla programu TV. Zbieranie informacji statystycznych o sposobie korzystania z usług IPTV przez użytkowników. Generacja informacji taryfikacyjnej i rozliczeniowej. Jednostki fukcjonalne MDF głównie są odpowiedzialne za dostarczanie mediów wideo, głosu i danych do terminali użytkowników. Oprócz wymienionych wcześniej funkcji zdefiniowano dla MDF szereg funkcji dodatkowych: Obsługę dostarczania strumieni mediów. 95

96 Przechowywanie mediów, np. zasobów treści na żądanie - CoD assets, i informacji o usługach. Przechowywanie najbardziej popularnych treści lub treści specyficznych dla danego klienta, np. rejestrowanych za pomocą PVR, przesuniętych w czasie programów TV, usług rozsiewczych w trybie efektów specjalnych (trick mode), oraz treści wytworzonych przez użytkowników. Przetwarzanie, kodowanie i transkodowanie (jeśli jest wymagane) mediów z wykorzystaniem różnych formatów (np. rozdzielczości: standardowa - SD i wysoka HD) w celu uwzględnienia charakterystyki i możliwości terminali oraz preferencji użytkowników. Ochrona treści, np. szyfrowanie treści. Zasilanie treścią dla usług IPTV. Bezprzewodowe mobilne przekazywanie nadawanych w trybie rozsiewczym treści jako strumieni medialnych w trybie multicast. Funkcje dostarczania mediów mogą być realizowane w sposób rozproszony w zależności od typu usługi (BC, CoD, PVR) lub zależnie od specjalizowanych podfunkcji, które są żłożone z następujących elementów treści: Metadanych: opisujących treści/zasoby za pomocą danych SDS, EPG lub katalogów treści VoD, w znormalizowanym formacie. Zasobów: pakietów treści dostarczanych do terminali użytkownika. Wymienione zasoby są uprzednio przekazywane przez jednostki funkcjonalne SCF do jednostek funkcjonalnych SDF, w oparciu o kryteria dostępności, popularności i regionalizacji treści. Rys.7.8 Odkrywanie i selekcja usług IPTV i ustanowienie sesji IPTV 96

97 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Usługi IMS IPTV Usługi IPTV można podzielić na trzy główne grupy: Usługi rozsiewcze - BC (Broadcast): na przykład przekazywane na żywo kanały TV i radiowe. Treści na życzenie CoD (Content on Demand): zwykle usługi realizowane w trybie unicast, dostarczane na życzenie, np. określony film lub utwór muzyczny. Usługi personalnej rejestracji wideo - PVR: usługi rejestracji programów w celu ich późniejszego obejrzenia lub przesunięta w czasie prezentacja treści przekazywanych na żywo. W przyszłości można się spodziewać większej liczby usług, obejmujących szerokie spektrum, od rozrywki, przez edukację po usługi bogatej komunikacji wykorzystujące idee konwergencji. Dobrze ilustruje te tendencje prototypowa implementacja konwergentnych usług IPTV opracowana przez Instytut Fraunfofera w oparciu o Open Source Core IMS (por. Rys.7.9). Rys.7.9 Przykład implementacji konwergentnych usług IPTV z wykorzystaniem Open Source Core IMS (źródło: Lista przykładowych usług łączących usługi IPTV z usługami usługami telekomunikacyjnymi może wyglądać następująco: IPTV + VoIP: oglądanie TV z możliwością jednoczesnej rozmowy. IPTV + IMP: informacja o statusie znajomych czy są obecni i dostępni i co oglądają oraz możliwość wymiany wiadomości natychmiastowych. Możliwość wyboru programu lub treści oglądanych przez znajomego. Możliwość zaproponowania znajomemu programu lub treści. Ocena i rekomendacja treści. Elektroniczny przewodnik po programach i dostępnych treściach. Click-to-dial z TV: reakcja w grze lub odpowiedź na reklamę. Teległosowanie lub interakcja w trakcie trwania programu TV. Identyfikacja wywołującego na ekranie TV: akceptacja bądź odrzucenie połączenia. 97

98 Przekazywanie połączeń w trakcie oglądania TV. Spersonalizowana i ukierunkowana reklama. Zdalna kontrola rodzicielska. Zdalne zakupy. Dostęp do treści wytworzonych przez użytkowników (np. YouTube) Tryby usługi IPTV i scenariusze usługowe Głównym wyzwaniem stawianym przed usługą telewizji cyfrowej bazującej na protokole IP jest dostarczanie usługi elastycznej i w pełni konfigurowalnej przez użytkownika. Wyróżniono trzy zasadnicze fazy połączenia do usługi IPTV wraz z elementami architektury i interfejsami, które biorą udział w poszczególnych fazach: Odkrycie usługi (ang. Service Discovery) w tej fazie użytkownik rejestruje się w podsystemie IMS oraz następuje autoryzacja w usłudze IPTV. Następuje pobranie profilu użytkownika w usłudze i przygotowanie listy dostępnych danych multimedialnych do prezentacji użytkownikowi w kolejnej fazie. Wybór treści (ang. Service Selection) - faza polegająca na wyświetleniu dostępnych do strumieniowania danych multimedialnych w graficznym interfejsie użytkownika (prezentowanym w przeglądarce internetowej) i umożliwieniu użytkownikowi dokonania wyboru. Dostarczenie usługi (ang. Service Delivery) faza polegająca na strumieniowaniu danych do urządzenia końcowego użytkownika. Rys.7.10 Usługa IPTV fazy realizacji Usługi IPTV wg normy ETSI zakładają udostępnianie usług w trzech trybach: 98

99 IN, NGN, Telefonia IP: H.323 i SIP, Architektura usługowa IMS Tryb Rozsiewczy (BC Broadcast). Tryb Treści Na Żądanie (CoD Content on Demand). Tryb Sieciowego Osobistego Nagrywania Video (NPVR Network Personal Video Recorder). Pociąga to za sobą konieczność specjalizacji modułów odpowiedzialnych za dostarczanie usługi IPTV i wyróżnienie podsystemów w poszczególnych modułach odpowiedzialnych za obsługę każdego z trybów. Poniżej przedstawiono krótką charakterystykę poszczególnych trybów wraz ze scenariuszami usługowymi rozpoczęcia i zakończenia korzystania z usługi. Tryb Rozsiewczy strumienie telewizji internetowej są rozgłaszane w trybie połączeń punkt-wielopunkt (multicast). W tym trybie transmisja jest ciągła, a zawartość tematyczna dla każdego z użytkowników jest identyczna. Użytkownik nie ma możliwości spersonalizowanej modyfikacji strumienia (zatrzymanie, przewijanie, nagrywanie). Prezentowane treści są globalne i nie uwzględniają indywidualnych preferencji. Tryb Treści Na Żądanie w tym trybie usługa IPTV dostarcza dedykowany strumień multimediów na żądanie użytkownika. Strumieniowanie odbywa się w trybie połączeń unicast, czyli z jednego strumienia w danej chwili korzysta jeden użytkownik. Dzięki temu posiada on pełną kontrolę nad strumieniem, decyduje o rozpoczęciu, wstrzymaniu oraz zatrzymaniu strumieniowania. W tym trybie użytkownik ma możliwość personalizowanie usługi według własnych potrzeb. Tryb Sieciowego Osobistego Nagrywania Wideo ten tryb wprowadza modyfikację do poprzednich trybów w postaci udostępnienia użytkownikowi możliwości rejestrowania treści na żądanie. Każdy użytkownik korzystający z tego trybu IPTV posiada na serwerze aplikacyjnym dedykowaną przestrzeń dyskową, na której zapisywane są nagrane multimedia. Zapisane multimedia są dostępne w każdym momencie korzystania z usługi. Realizacja tego trybu polega na wykonaniu na żądanie użytkownika kopii pliku multimedialnego, który jest odgrywany, zapisaniu parametrów umożliwiających identyfikację danego fragmentu strumienia oraz umieszczeniu kopii w dedykowanej użytkownikowi strukturze katalogowej po stronie serwera aplikacyjnego. Użytkownik posiada pełną możliwość zarządzania kopiami wykonanymi na jego żądanie. 99

100 8 Migracja ku architekturze sieci NGN opartej na IMS 8.1. Wprowadzenie Przedmiotem zainteresowania są strategie i drogi migracji usług i aplikacji w środowisku wspólnej architektury usługowej Common IMS zdefiniowanej w 3GPP UMTS Release 8. Brana jest także pod uwagę dalsza ewolucja architektury i protokołów zdefiniowana w kolejnych wersjach UMTS Release 9, 10, 11 i 12 w zakresie wpływającym na kwestie implementacji i udostępniania usług Protokoły sterowania sesjami Protokoły sterowania sesjami i połączeniami odgrywają kluczową rolę zarówno w telekomunikacji tradycyjnej jak i w NGN/IMS a scenariusze współpracy na płaszczyźnie sygnalizacji mają zasadnicze znaczenie dla usług. Trendy w obszarze protokołów sterowania sesjami i połączeniami można scharakteryzować następująco: Sieci z komutacją łączy (CS) są nadal szeroko eksploatowane i powszechnie używany jest protokół ISUP (w różnych wersjach), w związku z czym współpraca z sieciami TDM/CS ma kluczowe znaczenie w scenariuszach migracji. W domenie sieci mobilnych coraz szerzej wykorzystywany jest protokół BICC dla architektur UMTS w wersji 4 i późniejszych (MSC Release 4 MSC R4). Protokół ITU-T H.323 przeznaczony do realizacji usług multimedialnych, w tym VoIP w sieciach NGN, jest stopniowo zastępowany przez protokół IETF SIP. Stopniowy rozwój i wykorzystywanie przez operatorów platform usługowych IMS zwiększa użycie protokołu SIP (w wersji 3GPP) i protokołów związanych (MEGACO/H.248, DIAMETER, COPS). Protokół SIP-I jest typowo implementowany w węzłach NGN softswitch i węzłach MSC R4. Domena: CS NGN IMS PSTN/ISDN/GSM Softswitch UMTS Rel.8,9,10.. Mobilna Stacjonarna Tranzyt < > 2010 Rys.8.1 Przewidywana ewolucja protokołów sterowania sesjami Operatorzy mobilni wykorzystują przede wszystkim protokół BICC znormalizowany w architekturze UMTS Release 4. Protokół ten jest wspierany przez wszystkie węzły MSC R4. Jednak protokół BICC jest ściśle związany z architekturą GSM/UMTS i nie jest 100