Sieci Następnej Generacji (wybrane zagadnienia)

Transkrypt

1 NGN Sieci Następnej Generacji (wybrane zagadnienia) Marek Średniawa INSTYTUT TELEKOMUNIKACJI POLITECHNIKA WARSZAWSKA Marzec

2 2

3 NGN Spis treści 1 WPROWADZENIE 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 ANALIZA STANU NORMALIZACJI 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 Zakres prac normalizacyjnych STANDARYZACJA PROTOKOŁÓW NGN W IETF Wprowadzenie CHARAKTERYSTYKA PROTOKOŁU SIP BUDOWA PROTOKOŁU ORAZ MODEL SESJI MODEL OBECNOŚCI Informacja o statusie obecności Format RPID bogata obecność Standard obecności i wymiany wiadomości natychmiastowych IMPS Przetwarzanie informacji o obecności KIERUNKI ROZWOJU PROTOKOŁU SIP ORAZ JEGO ROLA W IMS ANALIZA ARCHITEKTURY TISPAN NGN Z PUNKTU WIDZENIA MECHANIZMÓW REALIZACJI USŁUG KONWERGENTNYCH FMC WPROWADZENIE ARCHITEKTURA TISPAN NGN ZACHOWANIE CIĄGŁOŚCI SESJI GŁOSOWYCH - VCC WSPÓŁPRACA SIECI NGN Z SIECIĄ PSTN WPROWADZENIE

4 6.2. WSPÓŁPRACA SIP PSTN ZASADY EMULACJI I SYMULACJI USŁUG PSTN/ISDN W ARCHITEKTURZE TISPAN NGN PES Podsystem Emulacji PSTN/ISDN Podsystem symulacji PSTN/ISDN PSS MODELE WSPÓŁPRACY PROTOKOŁÓW SIP-ISUP 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 WPROWADZENIE 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 Odkrywanie i selekcja usług (SDF i SSF) Funkcje sterowania usługami IPTV Funkcje IPTV związane z obsługą mediów USŁUGI IMS IPTV INTERFEJSY ARCHITEKTURY IPTV OPARTEJ NA IMS TRYBY USŁUGI IPTV I SCENARIUSZE USŁUGOWE PROFIL UŻYTKOWNIKA W USŁUDZE IPTV PROBLEMY MIGRACJI KU WSPÓLNEJ ARCHITEKTURZE SIECI NGN OPARTEJ NA ARCHITEKTURZE USŁUGOWEJ IMS WPROWADZENIE

5 NGN 9.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 NGN 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 NGN 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 Wprowadzenie 1.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 1. 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, telefon komórkowy, telefon bezprzewodowy, PDA, 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 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 Parlay/OSA API i protokół SIP. Infrastrukturę sieciową stanowią sieci szkieletowe IP, 1 Np. TVP udostępniła przez Internet przekaz z Igrzysk Olimpijskich w Pekinie. TP 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. 10

11 NGN 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. 1.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). 11

12 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, telefon komórkowy, PC, PDA / MDA, 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 realizacji wymienionych sieci, a także, w szerszym sensie, konwergencji przenikania 12

13 NGN 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 2 (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 3. 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 4. 2 Pionierami i liderami sieciowych usług IT są BT Global Systems, T-Systems i Orange Business Services. 3 Np. TVP udostępniała przez Internet relację z Igrzysk Olimpijskich w Pekinie. 4 Np. usługa Genion oferowana w Niemczech przez operatora komórkowego O2. 13

14 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 14

15 NGN 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. 15

16 2 NGN - czyli telekomunikacja wynajdywana na nowo 2.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, 3. Dostępny jest kanał komunikacji, 16

17 NGN 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. 2.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ą. 17

18 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). 18

19 NGN Rys.2.2 Telekomunikacja jako narzędzie komunikowania się próba taksonomii 19

20 2.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 20

21 NGN 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 21

22 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 22

23 NGN 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.2.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. 23

24 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.2.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.2.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. 24

25 NGN 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. 2.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.2.5). 25

26 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. 2.4 Wizja Common IMS jako docelowej uniwersalnej architektury sieci NGN Rys.2.5 Przyrost objętości (liczba stron) dokumentów normalizacyjnych IETF dotyczących protokołu SIP i VoIP (źródło: 26

27 NGN 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.2.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.2.7 Wizja powszechnej komunikacji w NGN 27

28 2.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 telekomunikacji na nowo, jako komunikowania w szerokim sensie, w wymiarze 28

29 NGN 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. 29

30 3 Analiza stanu normalizacji usług, protokołów i architektury NGN 3.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. 3.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 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. Rys.3.1 Mapa drogowa normalizacji NGN

31 NGN 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.3.2 Współzależność wersji architektur 3GPP IMS i ETSI TISPAN NGN 3.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. Zakres prac standaryzacyjnych, objętych dokumentami FGN GN i później NGN GSI (NGN Release 1), obejmuje: 31

32 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)). 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 32

33 NGN 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 Tabeli3.1 zestawiono główne normy ITU-T dotyczące NGN. Zalecenie Y.1910 IPTV architecture Tabela 3.1 Normalizacja NGN w ITU-T Y.2001 General overview of NGN Tytuł - przedmiot Y.2006 Description of capability set 1 of NGN release 1 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 33

34 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 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 34

35 NGN 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. 3.3 Architektura funkcjonalna NGN wg Zalecenia ITU-T Y.2012 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 35

36 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. 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. 36

37 NGN Rys. 3.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. 3.5 Architektura usługowa NGN oparta na IMS wg Y

38 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.) 38

39 NGN 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 39

40 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). Lista podstawowych specyfikacji TISPAN NGN Release 1 jest następująca: Architektura: ES on the TISPAN NGN Overall Architecture ES on the IMS architecture for fixed broadband access TS on the endorsement of 3GPP TS (IMS Stage 2) ES on the Resource and Admission Control Subsystem ES on the Network Attachment Subsystem ES on the PSTN/ISDN Emulation Subsystem TS on IMS-based PSTN Emulation architecture TS on Emergency Calls Architecture Protokoły: ES on the H.248 profile for Access Gateways ES on the H.248 profile for Trunking gateways ES on the H.248 profile for Border gateways ES on the H.248 profile for media resource processors 40

41 NGN ES on the DIAMETER profile for the e2 interface ES on the DIAMETER profile for the e4 interface ES on the DIAMETER profile for the Rq interface TS on the DIAMETER profile for the Gq' interface TS on the modification of the 3GPP Cx and Dx interfaces TS on interworking between IP networks ES (SIP/SDP profile) & ES (SIP / ISUP interworking) W niektórych specyfikacjach dotyczących usług używana jest trójfazowa struktura, zgodna z Zaleceniem ITU-T I.130 dla sieci ISDN. Faza 1 określa ogólny opis usługi z punktu widzenia użytkownika, faza 2 specyfikuje funkcjonalność oraz procedury wymagane do realizacji usługi, faza 3 definiuje protokoły sygnalizacyjne oraz transportowe, wymagane do jej implementacji NGN Release Zakres prac normalizacyjnych 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). Nadal trwają, rozpoczęte w czerwcu 2008 roku olanowane do końca 2009 roku, prace nad NGN Release 3, które skupiają się głównie na: Konsolidacji VoIP z uwzględnieniem aspektów QoS, bezpieczeństwa, współpracy i interoperacyjności. Ewolucji usług IPTV (usługi mieszane łączenie IPTV z Internetem i usługami telekomunikacyjnymi i dalsze perspektywy). Dostępie ultraszerokopasmowym (stacjonarny i wireless) do sieci NGN. Współpracy i połączeniu z domenami IMS i nie-ims). Harmonizacji sieci zwiększeniem zakresu interoperacyjności z innymi sieciami NGNs oraz innymi sieciami nie-ims. Współpracy z pozostałymi organizacjami normalizacyjnymi ITU-T, 3GPP i GSMA. 41

42 3.4. 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 3.2 przedstawiono w sposób zagregowany informację o normalizacji NGN w IETF. Tabela 3.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 (Session Initiation Protocol) 09/1999 Protokół SIP SIP for Instant Messaging and Presence Leveraging Extensions 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 42

43 NGN Rys.3.6. Mapa grup roboczych IETF zajmujących się normalizacją NGN 43

44 4 Charakterystyka protokołu SIP SIP jest tekstowym protokołem aplikacyjnym, typu klient-serwer, 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 5. Określenie dostępności użytkownika. Negocjacja parametrów połączenia. Ustanowienie i zarządzanie sesjami multimedialnymi. 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. Identyfikatory SIP URI (Universal Resource Indicator) 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 i informować, że użytkownik jest dostępny poprzez adres SIP. Koncepcja SIP URI uwzględnia także możliwość użycia numeru telefonicznego E.164 jako prawidłowego adresu. 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). 5 Możliwość określenia adresu sieciowego terminala użytkownika.

45 NGN Protokół SIP dostarcza środki, wraz z innymi protokołami, takimi jak SDP (opis parametrów sesji) i RTP (protokół transportu strumieni medialnych), służące do budowy usług i aplikacji multimedialnych łączących funkcjonalność telekomunikacyjną z możliwościami Internetu. Rys. 4.1 Mapa protokołu SIP i protokołów stowarzyszonych wykorzystywanych w kontekście realizacji usług komunikacji multimedialnej [źródło: 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 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. 45

46 REGISTER umożliwia rejestrację lokalizacji sieciowej terminala użytkownika 6. Odpowiedzi, podobnie jak w HTTP, są podzielone na kategorie określające rodzaj przenoszonych informacji: 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.4.2 przedstawiono przykładową wiadomość SIP. Wiadomość złożona jest z tzw. wierszapoczą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. 4.2 Przykładowa wiadomość INVITE protokołu SIP Na Rys.4.3 przedstawiono przykładowy scenariusz nawiązania sesji oraz jej zakończenia. 6 Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem użytkownika (np. sip:ala@eims.local). 46

47 NGN INVITE 180 RINGING 200 OK ACK transmisja mediów BYE 200 OK Rys. 4.3 Nawiązywanie i kończenie sesji 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: 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 7. System serwerów Proxy, Registrar i agentów użytkownika (UA) tworzy model sesji, który jest określany jako trapez SIPowy (por. Rys.4.4). 7 Opisany mechanizm jest zbliżony do NAT w sieci TCP/IP, tylko jest przeprowadzany w warstwie aplikacyjnej. 47

48 Registrar Registrar Proxy SIP Proxy SIP SIP UA SIP przepływ mediów (strumienie RTP) UA Rys. 4.4 Model sesji opartej o 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 analiza mechanizmów protokołu SIP jest zawarta w RFC Rys.4.5 Struktura i warstwy protokołu SIP 4.2. 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 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 48

49 NGN 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.4.6. 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. 49

50 Obserwator SUBSCRIBE NOTIFY PA PUBLISH NOTIFY Obserwowany SIP Proxy/ Rysunek 4.6 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.4.7 przedstawiono szczegółowy schemat realizacji usługi obecności. 50

51 NGN 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 4.7 Pełny model realizacji usługi obecności Proxy Server Presentity A Presence Server XCAP Watcher B SUBSCRIBE A [reg] NOTIFY [reg] A SUBSCRIBE A [winfo.presence] NOTIFY A [winfo.presence] XCAP policy XCAP update by A update PUBLISH A [presence] REGISTER A NOTIFY [reg] A SUBSCRIBE A [presence] NOTIFY B [presence] (closed) NOTIFY B (optional) [presence] (open) NOTIFY B [presence] (open) NOTIFY B [presence] (open) Rysunek 4.8 Wymiana wiadomości sygnalizacyjnych SIP w usłudze obecności 51

52 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. Informacja o obecnym to komplet informacji o urządzeniu, usłudze i osobie, jest ona identyfikowana poprzez tzw. Presentity URI: Rysunek 4.9 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 Adres of Record. Składnia PIDF ma swoją definicję wykorzystującą format XML. Podstawowe znaczniki to: <presence> - przechowuje informacje na temat statusu obecności, atrybut entity zawiera Presentity URI; <tuple> - krotka zawiera informacje na temat usługi, pole <contact> zawiera URI usługi, posiada także dodatkowe atrybuty (typu status lub characteristics ); <person> - znajduje się wewnątrz elementu <presence>, zawiera obowiązkowy element id, dowolną liczbę elementów z informacją o atrybutach (typu status bądź characteristics ) oraz opcjonalne elementy <note> i <timestamp>; 52

53 NGN <device> - znajduje się wewnątrz elementu <presence>, zawiera obowiązkowy element deviceid, dowolną liczbę elementów z informacją o atrybutach (typu status bądź characteristics ) oraz opcjonalne elementy <note> i <timestamp>. Status w dokumentach PIDF może przyjmować dwie wartości: open i closed (otwarty i zamknięty) 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. 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. 53

54 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 IMPS 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 4.1 przedstawiono zalecaną przez OMA przestrzeń atrybutów obecności. Tabela 4.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. 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 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 54

55 NGN 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 4.10 Przetwarzanie informacji o obecności i statusie dostępności 4.3. 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, 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 8. 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ł 8 Dane na podstawie IETF WG-SIP ( 55

56 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). 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. 56

57 NGN 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. 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.4.17 Scenariusze nawiązania sesji: SIP podstawowy i SIP IMS 9 9 Serwery pośredniczące zostały pominięte. 57

58 Jedną z podkreślanych cech protokołu SIP jest jego prostota 10. 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.4.17 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. 10 SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń. 58

59 NGN 5 Analiza architektury TISPAN NGN z punktu widzenia mechanizmów realizacji usług konwergentnych FMC 5.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). 59

60 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). 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. 5.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 60

61 NGN domenę mobilną i stacjonarną. Docelową ideą jest tzw. architektura Common IMS opracowywana wspólnie przez 3GPP, ETSI i ITU-T. 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. 5.2 Wizja Common IMS jako docelowej uniwersalnej architektury sieci NGN 5.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 61

62 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ź 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. 5.3 Architektura odniesienia ETSI TISPAN NGN oparta na IMS 5.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 62

63 NGN 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: 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 63

64 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 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. Na Rys.5.7 przedstawiono zarys architektury VCC z uwzględnieniem pary dwusystemowych terminali IMS NGN/CS, które mogą korzystać zarówno z trybu dostępu pakietowego prowadzącego do domeny IMS jak i z trybu łączowego prowadzącego do sieci transportowej CSN. Brama PSTN złożona z MGCF i MGW definiuje interfejs między domenami IMS NGN i CS. Funkcjonalność VCC odnosi się do każdego z terminali z osobna, czyli każdy z nich może realizować swoją odnogę połączenia głosowego w trybie NGN lub CS, nie zależnie i bez potrzeby wsparcia drugiego odległego terminala. Funkcja usługowa jest zawsze realizowana w sieci macierzystej obsługiwanego użytkownika. VCC wprowadza pojęcie zakotwiczenia, które obejmuje podział połączenia na dwie odnogi i określenie stałego punktu w sieci, którym te odnogi są zakotwiczone. Opisane podejście pozwala niezależnie obsługiwać każdą odnogę połączenia nie powodując niepożądanych interferencji w drugiej. 64

65 NGN Rys. 5.7 Zarys architektury dla usługi VCC i terminala (UE) działającego w dwóch trybach 65

66 6 Współpraca sieci NGN z siecią PSTN 6.1. Wprowadzenie Obecnie w dalszym ciągu większość użytkowników posługuje się tradycyjnymi terminalami działającymi w trybie komutacji kanałów (CS), zarówno w sieciach stacjonarnych jak i sieciach komórkowych. W związku z tym wymaga się od IMS współpracy z sieciami działającymi w trybie CS w zakresie podstawowych usług głosowych. W tym celu konieczna jest współpraca zarówno w płaszczyźnie sterowania jak i płaszczyźnie użytkownika z uwagi na to, że w obu płaszczyznach wykorzystywane są różne protokoły. Zadania współpracy w płaszczyźnie sterowania realizowane są przez MGCF, który dokonuje odwzorowania sygnalizacja SIP - sygnalizacja BICC lub ISUP, które są używane przez sieci z komutacją kanałów. Z kolei brama medialna IMS - IMS-MGW realizuje odwzorowanie protokołów transportowych w płaszczyźnie użytkownika. Brama terminuje podkładowe kanały transportowe z domeny sieci CS (PSTN/ISDN/GSM) oraz strumienie medialne z sieci pakietowych IP i ATM i zapewnia translację między tymi zakończeniami sieciowymi. Może ona także realizować fukcje dodatkowe, takie jak transkodowanie współpracę między różnymi typami kodeków, tłumienie echa i testy ciągłości. Zakończenia są sterowane przez MGCF. Współpraca IMS z innymi sieciami, w tym siecią PSTN/ISDN, została objęta normalizacją począwszy od Release 6 (3GPP TS i TS ) Współpraca SIP PSTN Mimo, że sieć ISDN oferuje oprócz usług głosowych usługi wideokomunikacji, to ze względu na dominujacą rolę głosu uwaga zostanie skupiona na współpracy SIP PSTN w odniesieniu do komunikacji głosowej. W tym celu zostanie opisany sposób ustanawiania sesji głosowych między SIPowymi agentami użytkownika a terminalami PSTN. Połączenia głosowe w PSTN są zestawiane za pomocą dwóch rodzajów sygnalizacji: sygnalizacji międzysieciowej (network-to-network, np. sygnalizacja międzycentralowa SS7) i sygnalizacji abonenckiej na styku użytkownika z siecią (user-to-network signaling, np. DSS1). Dwa poziomy współpracy między siecią PSTN a IMS siecią opartą na protokole SIP (por. RFC 3372), to poziomy sygnalizacji i mediów. Są one realizowane przez bramę o architekturze rozproszonej złożonej z 3 składników: brama sygnalizacyjna sterownik bramy medialnej brama medialna Brama sygnalizacyjna odbiera sygnalizację PSTN i wysyła ją do sterownika bramy medialnej przez sieć IP oraz działa analogicznie w odwrotnym kierunku. Sterownik bramy medialnej dokonuje odwzorowania sygnalizacji w relacji PSTN-SIP i steruje bramą medialną. Szczegółowe procedury współpracy SIP-ISUP zdefiniowano w normach RFC 3398 i RFC Brama medialna dokonuje procesu transkodowania mediów, jeżeli jest to wymagane, oraz przekształca media dostarczane ze strony sieci PSTN na pakiety RTP, które transportują media w sieci IP. Ruch między bramą sygnalizacyjną i sterownikiem bramy medialnej jest transportowany za pomocą protokołu SCTP zdefiniowanego w normie RFC Oddzielenie wymienionych składników pozwala na to aby pojedynczy sterownik bram medialnych mógł obsługować wiele bram sygnalizacyjnych, które są zwykle fizycznie rozproszone. Mogą one być także zaimplementowane w jednym fizycznie urządzeniu i wówczas nie jest konieczne wykorzystywanie specjalnego protokołu transportowego. Sterowniki bram 66

67 NGN medialnych w architekturze IMS używają do seterowania bramami medialnymi protokołu H.248. Sygnalizacja PSTN Brama sygnalizacyjna - SGW SCTP Mj BGCF Mg MGCF Sterownik bramy medialnej Mn CSCF Głos CS Mb Brama medialna - MGW Brama logiczna Rys.6.1 Architektura bramy realizującej współpracę IMS PSTN/CS 67

68 Rys.6.2 Konfiguracja współpracy IMS-CS w przypadku połaczenia inicjowanego przez użytkownika IMS do sieci z komutacją kanałów. Rys.6.3 Konfiguracja współpracy IMS-CS w przypadku połączenia inicjowanego przez użytkownika sieci z komutacją kanałów do użytkownika IMS. 68

69 NGN BGCF Mj CSCF Mg MGCF BICC/ISUP over SCTP/IP SGW Mn BICC over SCTP/IP BICC/ISUP over MTP (Note 3) Mb IM- MGW CS channels e.g. PCM CS network User Plane Control Plane Rys.6.4 Architektura współpracy IMS PSTN/CS 6.3. Zasady emulacji i symulacji usług PSTN/ISDN w architekturze TISPAN NGN PES Podsystem Emulacji PSTN/ISDN Jednym z celów modelu emulacji z NGN jest zastąpienie istniejącej infrastruktury PSTN/ISDN przy jednoczesnym zachowaniu przezroczystości usługowej. Mimo wymiany infrastruktury sieciowej użytkownicy powinni zachować swoją perspektywę postrzegania i korzystania z usług. Podsystem emulacji PSTN/ISDN w NGN może być zrealizowany, za pomocą sieci pakietowej wykorzystującej protokół SIP, w dwóch modelach architektonicznych: IMS. Softswitch. Rozwiązanie wykorzystujące architekturę IMS (por. Rys.6.5) dziedziczy cechy architektury 3GPP IMS i wprowadza szereg modyfikacji. Interfejs do podsystemu PES został zmodyfikowany w celu przystosowania do obsługi terminali analogowych PSTN, terminali ISDN i central abonenckich. Interfejs NNI między składnikami PES i serwerami aplikacji, które realizują usługi dla abonentów i usługi sieciowe, wykorzystuje tunelowanie wiadomości sygnalizacyjnych ISUP w celu przekazywania informacji sygnalizacyjnej związanej z usługami dodatkowymi. Wykorzystanie tunelowanych wiadomości ISUP umożliwia elementom sieci przystosowanym do operowania sygnalizacją ISUP, takim jak serwery aplikacji realizujące scenariusze usługowe emulacji PSTN/ISDN, zapewnić 69

70 Rys. 6.5 Emulacja PSTN/ISDN (PES) model IMS przezroczystość dla funkcji usługowych (m.in. usług dodatkowych) dla terminali w domenie CSN w zakresie sygnalizacji między serwerami aplikacji a bramami PSTN. Interfejs UNI nie wymaga tunelowania wiadomości sygnalizacyjnych ISUP, ale wymaga innych rozszerzeń, których omówienie tu pomijamy, służących do sterowania interakcjami z terminalami użytkownika końcowego. Rys.6.6 Emulacja PSTN/ISDN (PES) model softswitch W architekturze opartej na węźle softswitch (por. Rys.6.6) sterownik bramy MGC (Media Gateway Controller) implementujący jednostki funkcjonalne PES wraz z bramami dostępowymi AG (Access Gateway) i bramami abonenckimi RG (Residential Gateway) są wykorzystywane aby zastąpić istniejące centrale końcowe. Bramy RG i AG obsługują istniejące zakończenia łączy i są kontrolowane przez sterownik bram stosujący protokół H.248/MEGACO. Sterownik w węźle softwitch 70

71 NGN obsługujący PES zapewnia realizację dotychczasowych usług PSTN/ISDN i ponadto pozwala na wprowadzanie nowych usług, które są implementowane za pomocą dodatkowych serwerów aplikacyjnych. W celu uzyskania przezroczystości dla usług dodatkowych, sterownik węzła softswitch, a także serwery aplikacji muszą być przystosowane do współpracy z protokołem ISUP. Element funkcjonalny SGCF zapewnia interfejs do PSTN/ISDN oraz obsługę sygnalizacji do sieci NGN za pomocą SIP-I. W ten sposób zachowuje się dotychczasowa perspektywę postrzegania usług przez użytkowników Podsystem symulacji PSTN/ISDN PSS Podsystem NGN symulacji PSTN/ISDN PSS przedstawiony na Rys.6.7 różni się od modelu PES, ponieważ w całości jest oparty na architekturze IMS obsługującej terminale SIPowe, w których za pomocą rozszerzeń uzyskuje się symulowane usługi dodatkowe PSTN/ISDN. Rys. 6.7 Symulacja PSTN/ISDN (PSS) model IMS W tym przypadku, ponieważ nie stosuje się tunelowanej sygnalizacji ISUP w interfejsie UNI terminali użytkowników końcowych, to realizacja usług dodatkowych wymaga skorzystania z wprowadzanych rozszerzeń protokołu SIP. W interfejsie NNI też jest prawdopodobne wykorzystanie części tych rozszerzeń, ale są one nadal przedmiotem prac normalizacyjnych i uzgodnień w środowisku telekomunikacyjnym. Sprawa nie jest prosta, ponieważ mamy do czynienia ze sprzecznym wymaganiami z jednej strony pełnej przezroczystości usługowej, a z drugiej z uniknięcia obsługi wiadomości protokołu ISUP w całej sieci NGN. 71

72 Rys.6.8 Połączenie AGCF i PES AS z IMS Rys.6.9 Ruting między użytkownikami system PES opartego na IMS 72

73 NGN Rys.6.10 Wewnętrzna struktura AGCF 6.4. Modele współpracy protokołów SIP-ISUP Wymaganie współpracy sieci PSTN/ISDN z sieciami NGN oraz realizowanie przez nie emulowanych usług PSTN/ISDN było na tyle ważne z punktu widzenia operatorów i usługodawców, że kwestia współdziałania protokołów SIP i ISUP została podjęta przez instytucje normalizacyjne. Pierwsze standardy zostały opracowane przez IETF. RFC 3372 definiuje wariant protokołu SIP określany jako SIP-T (SIP for Telephony), który pozwala na tunelowanie wiadomości ISUP. Z uwagi na bezpieczeństwo norma zaleca szyfrowanie treści wiadomości ISUP. Powiązana norma RFC 3398 specyfikuje odwzorowanie SIP-ISUP na poziomie wiadomości sygnalizacyjnych i ich parametrów. W RFC 3666 przedstawiono zbiór przykładowych diagramów wymiany wiadomości ilustrujący zasady odwzorowania protokołów SIP-ISUP przy współpracy NGN- PSTN/ISDN. W RFC 3959 i RFC 3960 opisano problematykę tzw. wczesnych mediów, związaną z wymaganiem transportu sygnałów tonowych i zapowiedzi używanych w sygnalizacji PSTN. Wreszcie w RFC 3578 opisano metody obsługi sygnalizacji ISUP na zakładkę (overlap signalling). ITU-T opracowało własną normę Zalecenie Q nie odwołując się do opisanych wcześniej przez IETF norm RFC. Zalecenie to obejmuje ten sam obszar co łącznie normy RFC 3372, RFC 3398 i RFC 3578 i definiuje 3 profile: A, B i C. Profile A i B są typowymi profilami współpracy międzysieciowej SIP-ISUP. Profil A jest zdefiniowany pod kątem spełnienia wymagań głównie sieci mobilnych 3G, natomiast profil B jest bardziej uniwersalny (w szczególności uwzględnia obsługę sygnalizacji na zakładkę, która nie jest potrzebna w sieci mobilnej). Profil C, nazywany także SIP-I (SIP plus ISUP) definiuje zasady tunelowania wiadomości ISUP w wiadomościach SIP. Procedury ITU-T opierają się na pojęciu zaufania między punktami sygnalizacyjnymi i właśnie to zaufane środowisko najbardziej odróżnia Q od norm RFC. Tunelowane wiadomości ISUP mogą być wysyłane tylko do zaufanych elementów sieci, które potrafią je właściwie zinterpretować. Jest to jedna z możliwości ujętych w normie RFC Idąc dalej, w Q wykorzystuje się nagłówek P-Asserted- 73

74 Identity do reprezentacji numeru abonenta wywołującego. Przedstawiony sposób użycia narzuca wymagania dotyczące bezpieczeństwa opisane w RFC Jedna z różnic między RFC 3398 i Q może dobrze zilustrować różnicę nastawienia IETF i ITU-T. W protokole SIP zdefiniowano kody statusów (status code) w celu wskazania powodu odrzucenia żądania. Są one odpowiednikiem kodów przyczyn (cause code) z protokołu ISUP. Początkowo, zarówno w IETF jak i w ITU-T próbowano zdefiniować takie odwzorowanie między kodami statusów i kodami przyczyn, które by odzwierciedlało ich semantykę. Jednak, w końcu ITU-T, z dwóch powodów bardzo uprościła odwzorowanie. Pierwsza polegała na tym, że odwzorowanie semantyczne w sposób ukryty traktuje całą ścieżkę połączenia jako pojedynczy system, podczas gdy operatorzy reprezentowani w ITU-T sądzili, że reprezentowanie usterek sieciowych SIPowych, tak jakby to były kody przyczyn ISUPowe, spowoduje, że staną się one bezużyteczne jako wskaźniki diagnostyczne. Postępowanie odwrotne również prowadziłoby do podobnej sytuacji. Drugą przyczyną była świadomość, że kody statusów protokołu SIP będą docierały do użytkowników końcowych, a operatorzy uważali, że przekazywanie szczegółów może być mylące dla użytkowników. Tak więc, oprócz oczywistych odwzorowań, takich jak Busy wiele innych odwzorowań zostało sprowadzonych do 480 Temporarily Unavailable, co znaczyło Proszę spróbować później lub 500 Server Internal Error, Proszę zrezygnować. W praktyce dostawcy implementują możliwość konfigurowania odwzorowania w sposób zgodny z preferencjami operatora. 74

75 NGN 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. 75

76 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 S -CSCF SIP dialog #1 From: X To: Y Call -ID: Z 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 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. 76

77 NGN 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 i w jakich okolicznościach przekierować daną sesję sygnalizacyjną do określonego serwera aplikacyjnego. 77

78 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. 78

79 NGN 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 79

80 (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 platformy usługowe z scenariuszami usług, które implementują stronę 80

81 NGN 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

82 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,

83 NGN 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 12 W rozdziale wykorzystano wyniki pracy dyplomowej Bartłomieja Kołakowskiego [28]. 83

84 PSI wykorzystywany do komunikacji z agentami użytkowników SIP oraz innymi serwerami aplikacji. 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żą 84

85 NGN złożoność tego procesu i wymaga opracowania odpowiednich narzędzi, których obecnie brak. 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. 8 IMS i usługi IPTV 8.1. Wprowadzenie 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 85

86 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 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. 86

87 NGN 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 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.8.1 przedstawiono schemat normalizacji ETSI TISPAN w zakresie usług i architektury systemów IPTV. IPTV oparta na IMS Dedykowany podsystem IPTV Rys. 8.1 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 (DVB- 87

88 handheld) jest to, że wykorzystywana jest ta sama wspólna infrastruktura sieci IP 3G co dla usług dostępu do Internetu i transmisji danych 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 88

89 NGN się do IMS we wspólnej konfiguracji systemu świadczącego konwergentne usługi IPTV. 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. 8.2 IPTV dwie opcje w architekturze TISPAN NGN IMS i nie-ims W porównaniu z specyficznymi zamkniętymi rozwiązaniami IPTV (Typ 1), NGN-IPTV (Typ 2) 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 (Typ 3) 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. (Typ 4) 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 89

90 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 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. W zintegrowanej platformie IMS IPTV wprowadzono następujące dodatkowe moduły funkcjonalne: SDF (Service Discovery Functions) moduł dostarczający użytkownikowi usługi informacje niezbędne do skorzystania z usługi cyfrowej telewizji IP. Główne funkcje tego modułu to: o Tworzenie i dostarczanie informacji koniecznych do dowiązania do usługi (rozpoczęcia korzystania). Na dane składają się adresy SIP URI serwerów aplikacyjnych, na których jest uruchomiona usługa IPTV i które są odpowiedzialne za sterowanie połączeniem z usługą IPTV. W przypadku, kiedy w sieci jest zainstalowany system DNS (Domain Name System) może być to także lista adresów IP. o Dostarczanie spersonalizowanych informacji umożliwiających korzystanie z usługi (bazujące na profilu użytkownika, jego aktywności w usłudze lub historycznych wyborów). Efektywny algorytm proponowania treści w IPTV jest niezbędny, żeby zainteresować użytkownika usługą i jest wymagany w komercyjnych wdrożeniach usług telewizji IPTV. SSF (Service Selection Function) moduł odpowiedzialny za dostarczenie użytkownikowi listy dostępnych strumieni multimedialnych wraz z krótkim opisem, umożliwiających zorientowanie się w tematyce oferowanych w ramach usługi treści. Dostępną listę wyboru moduł SSF może generować na podstawie posiadanych predefiniowanych danych lub pobierać ją z bazy danych UPSF lub zewnętrznej bazy danych. Moduł ten może rozgłaszać listę dostępnych danych multimedialnych do wszystkich użytkowników w trybie rozsiewczym (broadcast) lub indywidualnym (unicast). Podobnie jak w przypadku modułu SDF, moduł SSF w przypadku dostarczanie w trybie indywidualnym powinien 90

91 NGN personalizować dostarczaną informację. Zwiększa to atrakcyjność usługi i sprawia, że użytkownik otrzymuje interesującą go zawartość tematyczną usługi. Taką personalizację otrzymuje się poprzez dokładne skatalogowanie przez dostawcę usługi dostarczanych treści oraz zdefiniowania zależności między poszczególnymi treściami. Opcjonalnie moduł oprócz dostępnych tytułów powinien prezentować opis tematyki prezentowanych treści. Informacje te mają na celu ułatwić użytkownikowi trafny wybór treści. Normy ETSI zalecają, żeby każdy strumień multimedialny dostępny do wyboru miał nadany unikalny identyfikator przechowywany po stronie usługi IPTV i jednoznacznie identyfikuje strumień. Dzięki temu w sygnalizacji przesyłany jest jedynie ten identyfikator a serwer IPTV odwzorowuje go na konkretny adres rtsp://. Dodatkowo, jeśli charakter strumienia ma dodatkowe wymagania, które użytkownik powinien spełniać wybierając dany strumień, zadaniem modułu SSF jest informacja dotycząca tego ograniczenia. SCF (Service Control Function) moduł realizujący logikę usługi telewizji internetowej IPTV. Norma ETSI zaleca, żeby w przypadku realizacji platformy IPTV zintegrowanej z IMS używał protokołu SIP do komunikacji z pozostałymi modułami sterującymi połączeniem (narzuca to jego realizacje z wykorzystaniem serwera aplikacyjnego SIP). Kiedy aplikacja IPTV nie jest utrzymywana przez operatora, zaleca się, żeby moduł ten nie miał dostępu do wszystkich danych dotyczących użytkownika, które są przechowywane w HSS, a tylko do perspektywy zawierającej dane niezbędne do świadczenia usługi. Głównym zadaniem modułu SCF jest kontrolowanie treści wyświetlanych użytkownikowi w ramach usługi. W praktyce rola ta polega na odbieraniu zleceń od użytkownika i odpowiednim wysterowaniu modułu MCF sterującego bramą strumieni multimedialnych. Dodatkowo powinien obsługiwać logikę gromadzenia historii aktywności użytkownika w usłudze w celu lepszego personalizowania kształtu usługi dla danego użytkownika. Pozostałe zadania tego modułu to: o o o Identyfikacja i uwierzytelnienie użytkowników, chcących korzystać z usługi IPTV oraz podjęcie decyzji o nadaniu dostępu. Obsługa danych taryfikacyjnych oraz rozliczanie użytkowników za korzystanie z usługi. Zaleca się wykorzystanie systemu rozliczeniowego czasu rzeczywistego z rezerwacją i limitowaniem dostępu do treści. Wybór serwera medialnego i przypisanie go danemu użytkownikowi na czas trwania sesji. W tym celu moduł SCF musi posiadać informację o dostępnych serwerach medialnych, ich lokalizacji, możliwościach oraz posiadanych zasobach multimedialnych. MCF (Media Control Functions) moduł odpowiedzialny za sterowanie dostarczaniem strumieni multimedialnych do użytkownika. Moduł ten jest wysterowany protokołem SIP przez moduł SCF. Do głównych zadań MCF zalicza się: o o sterowanie strumieniami multimedialnymi udostępnianymi przez MDF. Zarządzanie przetwarzaniem multimediów wykonywanym przez MDF. 91

92 o o o Monitorowanie statusu MDF, wykrycie nieprawidłowości i uszkodzeń w dostarczaniu strumieni i wysłanie notyfikacji do modułu SCF informujących o wystąpieniu sytuacji awaryjnej. Zarządzanie interakcją z terminalem użytkownika wymiana i wykonywanie komend RTSP. Funkcja ta jest realizowana w trybie spersonalizowanego nagrywania PVR. Charakterystyka trybów usługi IPTV zostanie przedstawiona w dalszej części tego rozdziału. Generacja danych taryfikacyjnych MDF (Media Delivery Functions) moduł fizycznie dostarczający i obsługujący strumienie multimedialne. Do głównych jego zadań należy: o o Dostarczanie strumieni multimedialnych do użytkownika. Powiadamianie o własnym statusie i jego zmianach modułu MCF. o Przechowywanie treści multimedialnych oraz informacji je opisujących (np. format, czas trwania, gatunek). o Przechowywanie spersonalizowanych treści użytkownika (np. nagrane fragmenty multimedialne, multimedia dostarczane do usługi przez użytkowników). o Przetwarzanie, transkodowanie i konwersja strumieni multimedialnych. o o o o Szyfrowanie danych przesyłanych w ramach strumienia Realizacja usług TV w trybie rozsiewczym, jeśli usługa jest uruchomiona w tym trybie. Generacja raportów dotyczących jakości oferowanych strumieni. Zbieranie danych dotyczących zachowania gwarancji jakości obsługi (QoS) w usłudze UPSF (User Profile Selection Function) moduł przechowujący profil użytkownika w usłudze IPTV. Profil powinien zawierać dane niezbędne do identyfikacji i autoryzacji użytkownika, dane konfiguracyjne danego użytkownika oraz zawierać informacje dotyczące preferencji użytkownika w usłudze IPTV. Szczegółowy opis profilu użytkownika w usłudze zostanie przedstawiony w dalszej części tego rozdziału. Według norm ETSI baza danych UPSF może być zintegrowana z bazą danych HSS lub być oddzielną autonomiczną bazą danych, jednak w tym przypadku dostęp do niej powinny mieć poszczególne moduły CSCF (w celu autoryzacji użytkownika i weryfikacji jego uprawnień dostępu do usługi) 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). 92

93 NGN 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 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. Terminal użytkownika UE może się komunikować z serwerami aplikacji IPTV poprzez różne interfejsy (por. Rys.6.3): Gm zarządzanie sesją pośrednio, poprzez rdzeń IMS, Ut konfiguracja profilu usługi Xa interakcja z funkcjami wyboru usług. Każdy terminal użytkownika UE ma, co najmniej, cztery interfejsy do sterowania mediami poprzez Xc i dostarczania mediów przez Xd, a także interfejs Gm z IMS i wirtualny interfejs Xt z serwerami aplikacyjnymi IPTV W implementacjach IMS IPTV funkcje selekcji usług SSF (Service Selection Function), wykrywania usług - SDF (Service Discovery Function) i funkcje sterowania usługą - SCF (Service Control Function) są zwykle realizowane wspólnie w serwerze aplikacyjnym IPTV, co umożliwia połączenie wyróżnionych w specyfikacji interfejsów Ut i Xa w jeden wirtualny interfejs Xt. 93

94 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. 8.3 Architektura funkcjonalna IMS IPTV wg ETSI TS Interfejsy Ut i Gm powinny być w pełni zgodne z normami 3GPP dla IMS. Serwer aplikacji IPTV wykorzystuje do komunikowania się z funkcjami sterowania usługami IMS NGN za pomocą standardowego interfejsu sterowania usługami w architekturze usługowej IMS, tzn. interfejsu ISC. Funkcje sterowania mediami MCF (Media Control Functions) sterują funkcjami dostarczania mediów MDF (Media Delivery Functions) przez punkt odniesienia Xp, który umożliwia budowanie skalowalnej i rozproszonej infrastruktury dostarczania mediów. Zewnętrzne treści mogą być importowane do z zewnętrznych źródeł medialnych (przez dostawców treści lub za pomocą stacji czołowej IPTV) przez zewnętrzny interfejs do MDF. 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. W architekturze IMS zdefiniowano trzy typy jednostek funkcjonalnych CSCF: Proxy-CSCF (P-CSCF) pierwszy punkt kontaktu dla użytkowników IMS. Głównymi zadaniami P-CSCF są przekazywanie wiadomości sygnalizacyjnych między sieciami a użytkownikiem i przydział zasobów dla strumieni mediów realizowany w interakcji z podsystemem sterowania zasobami i dostępem RACS (Resource and Admission Control Subsystem) zdefiniowanym przez normy TISPAN. Serving-CSCF (S-CSCF) stanowi główny element sterujący w IMS. Przetwarza on rejestrację użytkowników (spełnia rolę serwera SIP Registrar) i przechowuje informację o bieżącej lokalizacji oraz odpowiada za uwierzytelnienie użytkownika i zarządzanie sesją. Profile użytkownika 94

95 NGN przechowywane w HSS determinują operacje wykonywane przez S-CSCF na rzecz danego użytkownika. Interrogating-CSCF (I-CSCF) skierowuje zapytania do HSS w celu wyznaczenia właściwego S-CSCF dla użytkownika 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 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. 95

96 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. 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. 96

97 NGN 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. 8.4 Odkrywanie i selekcja usług IPTV i ustanowienie sesji IPTV 8.6. 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. 8.5). 97

98 Rys. 8.5 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. 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). 98

99 NGN 8.7. Interfejsy architektury IPTV opartej na IMS W architekturze funkcjonalnej IPTV IMS wyróżniono następujące interfejsy: Interfejs Xa - interfejs na styku między terminalem użytkownika UE i modułem wyboru usługi SSF, za pomocą którego użytkownik może wybrać interesujące go treści multimedialne. Oprócz udostępnienia listy multimediów interfejs powinien posiadać mechanizmy ułatwiające przeszukiwanie indeksu danych (poprzez skatalogowanie, podział na kategorie lub wykorzystanie znaczników) W praktycznych realizacjach jest to interfejs zrealizowany: o o Za pomocą strony internetowej, na którą użytkownik loguje się za pomocą przeglądarki i ma możliwość wyboru interesujących danych multimedialnych spośród wszystkich dostępnych w ramach usługi IPTV. Za pomocą modułu wbudowanego w klienta IMS użytkownika końcowego, w przypadku zaimplementowania usługi dodatkowej IPTV Elektronicznego Przewodnika po Programach (EPG Electronic Program Guide). Interfejs Ut - interfejs na styku między terminalem użytkownika UE i serwerem aplikacyjnym realizującym funkcję SCF (przechowujący i wykonujący logikę aplikacji IPTV). Interfejs ten służy użytkownikowi do konfiguracji swojego profilu w usłudze IPTV. Perspektywa danych użytkownika widoczna i dostępna przez ten interfejs powinna ograniczać się do danych ściśle związanych z usługą. W praktycznej realizacji podobnie jak interfejs Xa jest to strona internetowa, do której użytkownik otrzymuje dostęp po autoryzacji i ma dostęp w trybie odczytu i zapisu do parametrów konfiguracyjnych. Po wysłaniu żądania, w przypadku wprowadzonych modyfikacji, zmiany powinny być wykonane w bazie danych realizującej funkcjonalność UPSF (po wcześniejszej walidacji z poziomu aplikacji). Interfejs Gm - interfejs w architekturze IMS między terminalem użytkownika a węzłami odpowiedzialnymi za obsługę sesji (zgłoszeń), czyli serwerami CSCF. Na tym interfejsie wykorzystywany jest protokół SIP, jako główny protokół sygnalizacyjny w IMS. Interfejs Xc - interfejs w relacji end-to-end między terminalem użytkownika UE a sterownikiem bramy medialnej, który steruje bramą medialną przy strumieniowaniu multimediów (realizującej funkcję MCF). W interfejsie tym możliwa jest wymiana wiadomość sterujących mających na celu określenie charakterystyki dostarczanych użytkownikowi strumieni danych oraz sterowanie strumieniem za pomocą komend protokołu RTSP (możliwość zatrzymania, wznowienia, przeskoczenia do danego momentu w strumieniu). Interfejs Xc jest interfejsem logicznym zbudowanym według schematu przedstawionego na Rys.8.6: Rys.8.6 Schemat interfejsu Xc IMS IPTV 99

100 i tworzony przez następujące interfejsy warstwie transportowej: o o o interfejs Dj, łączący terminal UE z siecią dostępową, przez którą łączy się on z platformą IMS. interfejs Di, łączący sieć dostępową z siecią rdzeniową systemu opartego na architekturze IMS (realizującą moduły NASS Network Attachment Subsystem oraz RACS Resource Admission Control System). Interfejs Ds, którym transportowa sieć rdzeniowa komunikuje się ze sterownikiem bramy medialnej. Interfejs Xd - interfejs w relacji między terminalem użytkownika UE i bramą medialną, realizującą funkcję MDF (Media Delivery Function). Interfejs Xd jest przeznaczony do raportowania faktycznych parametrów QoS (Quality of Service) oraz QoE (Quality of Experience) postrzeganych przez użytkownika z terminala użytkownika UE do bramy multimedialnej. W przypadku niezgodności z wynegocjowanymi parametrami przy zestawianiu sesji interfejs ten umożliwia wymuszenie ich walidacji. Poza tym terminal użytkownika UE może przesyłać tym interfejsem szereg statystyk do bramy multimedialnej, na podstawie których operator może się elastycznie dostosować do wymagań użytkownika. Podobnie jak interfejs Xc, interfejs Xd jest interfejsem logicznym, zrealizowanym za pomocą tych samych fizycznych interfejsów transportowych. Interfejs Cx - interfejs w relacji między serwerami CSCF a bazą danych HSS, udostępniający profil użytkowników i usług przechowywany w HSS. Interfejs Cx nie był modyfikowany w ramach integracji usługi IPTV z platformą IMS, więc pominąłem opis tego interfejsu Interfejs Sh - interfejs komunikacji serwerów aplikacyjnych z serwerem HSS przechowującym dane dotyczące profilu abonenta oraz szeregu jego profili usługowych. Styk umożliwia odczyt i modyfikację parametrów w bazie danych HSS. W przypadku integracji modułu UPSF z HSS jest to interfejs, którym serwer aplikacyjny usługi IPTV pobiera profil użytkownika usługi. Interfejs ISC - interfejs w relacji między serwerami aplikacyjnymi AS a serwerem S-CSCF, służący do wymiany sygnalizacji za pomocą wiadomości protokołu SIP. Interfejs y2 - interfejs zdefiniowany w relacji między modułem S-CSCF a MCF. Alternatywą jest implementacja bezpośredniego interfejsu między serwerem aplikacyjnym, na którym jest uruchomiona usługa IPTV a modułem MCF, jednak, kiedy takie rozwiązanie nie jest możliwe MCF jest wysterowany za pośrednictwem S-CSCF 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 100

101 NGN 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. 8.7 Usługa IPTV fazy realizacji Normy ETSI narzucają wymaganie dostępności usług w trzech trybach: 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. Specjalizację poszczególnych modułów przedstawia schemat architektury przedstawiony na Rys.8.8: 101

102 Rys.8.8 Architektura IMS IPTV - specjalizacja modułów Różna logika usługi w poszczególnych trybach wymusza realizację różnymi mechanizmami sygnalizacyjnymi. 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. W przypadku, kiedy platforma IPTV dysponuje tylko tym trybem usługi nie jest konieczna implementacja interfejsu Xc, dającemu użytkownikowi możliwość kontrolowania odtwarzania multimediów w strumieniu. Scenariusz rozpoczęcia korzystania z usługi w trybie rozsiewczym przedstawiono na Rys.8.9: 102

103 NGN Rys.8.9 Inicjalizacja sesji w trybie rozsiewczym usługi IPTV Rys.8.10 Zakończenie sesji w trybie rozsiewczym usługi IPTV 103

104 Tryb ten wymaga implementacji protokołu zarządzającymi grupami multicast w sieci opartej na protokole IP. W przypadku architektury IMS IPTV zalecanym jest protokół IGMP (Internet Group Management Protocol). 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. Zgodnie z zaleceniami, dotyczącymi cyfrowej telewizji szerokopasmowej w przypadku tego trybu konieczna jest implementacja interfejsu Xc i udostępnienie użytkownika metod sterowania strumieniem (udostępnianych przez RTSP). 104

105 NGN Rys.8.11 Rozpoczęcie sesji w trybie na żądanie usługi IPTV 105

106 Rys.8.12 Rozłączenie sesji w trybie "na żądanie" usługi IPTV Tryb Sieciowego Osobistego Nagrywania Video 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. 106

107 NGN 8.9. Profil użytkownika w usłudze IPTV Jak wspomniano przy omawianiu poszczególnych modułów architektury IMS IPTV profil użytkownika w usłudze IPTV jest przechowywany w UPSF. Implementacja tego modułu może być zintegrowana z bazą danych HSS lub być dedykowaną bazą danych po stronie serwera aplikacyjnego IPTV. Na profil użytkownika w usłudze IPTV składają się następujące elementy: Profil IMS użytkownika zawiera wszystkie wymagane dane z punktu widzenia IMS do zestawienia sesji multimedialnych przez danego użytkownika. Poza tym zawiera dane o wszystkich zasubskrybowanych przez użytkownika usługach, więc także o fakcie korzystania z usługi IPTV. Wraz z nazwami usług znajdują się informacje, czy użytkownik jest uprawniony do korzystania z nich. Podstawowy profil użytkownika ma wpływ na możliwość korzystania z usługi IPTV, ale wprowadzenie tej usługi nie powoduje modyfikacji tego profilu. Profil użytkownika w zasubskrybowanych usługach określa parametry konfiguracyjne wykorzystywane przez poszczególny funkcje usługowe w IMS (obecność, wysyłanie wiadomości natychmiastowych, komunikacja z sieciami PSTN/ISDN). Wymienione powyżej funkcje usługowe mogą być wykorzystane do zwiększenia atrakcyjności usługi IPTV. Profil użytkownika w usłudze IPTV zawiera wszystkie parametry konfiguracyjne konieczne do korzystania z usługi IPTV. Podstawowy model został przedstawiony na schemacie na Rys Rys.8.13 Model danych profilu użytkownika usługi IPTV Zgodnie ze schematem profil ten powinien zawierać: Ustawienia globalne preferencje językowe, alias użytkownika w usłudze, określenie, czy aktywność użytkownika w usłudze będzie rejestrowana. Ustawienia dotyczące urządzeń końcowych możliwości sprzętowe i programowe posiadanych terminali końcowych. Informacja ta pozwoli dostosować usłudze IPTV jakość prezentowanych treści multimedialnych do specyficznych cech urządzenia (przepływność, rodzaj kodowania). W przypadku wykorzystywania wielu różnych terminali, użytkownik ma 107

108 możliwość konfiguracji parametrów dla każdego z nich. Lista parametrów konfiguracyjnych terminali może bardzo rozbudowana, dlatego w profilu użytkownika może być zawarty jedynie identyfikator dla tych ustawień, odnoszący się do danych przechowywane w innym miejscu. Dane dotyczące konfiguracji trybu BC użytkownik może korzystać z wielu pakietów usługowych w trybie rozgłaszania. Termin pakiet oznacza zgrupowany zestaw strumieni multimedialnych (programów) i umożliwia dostawcy usługi stworzeniu kilku zestawów programów użytkownik wykupując dostęp do danego pakietu posiada dostęp do wszystkich strumieni w nim zawartych. Umożliwia to dostawcy usługi profilowanie oferty pod względem oferowanej tematyki lub jakości oferowanych strumieni. Norma ETSI zaleca, żeby w przypadku implementacji usługi w trybie rozgłoszeniowym, każdy jej użytkownik miał przypisany minimum jeden pakiet. Dany pakiet składa się z wielu Programów (strumieni) dostępnych w trybie multicast. Profil użytkownika zawiera tylko identyfikatory programów, natomiast pełny ich opis przechowywany jest w oddzielnej tabeli bazy danych. Ustawienia dotyczące trybu CoD przykładowe parametry to poziom blokady rodzicielskiej i limity wielkości pobieranych treści. Ustawienia dotyczące trybu NPVR - umożliwiającego nagrywanie fragmentów, które użytkownik chciałby mieć zawsze dostępne. Ustawienia te dotyczą limitów dostępnej przestrzeni dyskowej na przechowanie nagranych treści, restrykcje dotyczące nagrywania i udostępniania nagranych treści. Oprócz danych wymienionych na schemacie mogą być przechowywane liczne opcjonalne parametry, m.in.: o Identyfikator do oryginalnych treści, z których pochodzi nagrany fragment. o Data wykonania nagrania (data rozpoczęcia i zakończenia nagrywania). o o o o o o Opis nagranego fragmentu wykonany przez użytkownika w celu sklasyfikowania nagranych treści. Status nagrania (zaplanowane. zakończone, przerwane z powodu błędu). Data wygaśnięcia wpisu w historii. Wskaźnik na miejsce w multimediach przeglądanych w trybie bez nagrywania treści, w którym użytkownik przerwał strumieniowanie umożliwia wznowienie transmisji od tego miejsca. Data wygaśnięcia wskaźnika z poprzedniego punktu. Flagę, określającą, czy historia ma być dla użytkownika zbierana i przechowywana (archiwizowana). 108

109 NGN 9 Problemy migracji ku wspólnej architekturze sieci NGN opartej na architekturze usługowej IMS 9.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 i 11 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.9.1 Przewidywana ewolucja protokołów sterowania sesjami 109