POLITECHNIKA WARSZAWSKA Rok akademicki Wydział Elektroniki i Technik Informacyjnych 2006/2007 Instytut Telekomunikacji PRACA DYPLOMOWA MAGISTERSKA Michał Jan Kościesza Michał Daniel Misiak Modele implementacji usług w architekturze IMS Praca wykonana pod kierunkiem dra inŝ. Marka Średniawy.. ocena pracy.. podpis Przewodniczącego Komisji Warszawa, 2007 r.
Models of service implementation in the IMS architecture Abstract IMS is an IP-based service architecture specified by 3GPP for UMTS. The architecture became main part of ETSI and ITU NGN reference model, which defines new public telecommunication network architecture. IMS offers broad set of functionalities, like multimedia sessions or context aware environment. These features open new service creation opportunities, which require suitable software development models and technologies. Parlay X is a set of technology-independent APIs which enable development of applications that operate across different telecommunication networks. APIs contain abstract methods (e.g. makecall) that describe basic network functionalities. Parlay APIs can be implemented on SIP application servers and thus can be adapted to the IMS service model. Jain-SLEE is a Java based service execution environment, which defines a component based model for structuring the application logic of communications. JSLEE represents a different approach in comparison to Parlay concept and defines both an execution environment and API. Using SIP resource adapter JSLEE implementation can be used as an IMS application server. The thesis focuses on analysis of IMS service architecture and different programming approaches that can be used in the service implementation process. Within the scope was also implementation of an IMS environment, based on open source software. This process was divided into 3 areas: - IMS service control model, which is responsible for session-handling transfer to specified application server based on subscriber profile. - Parlay X capability server that implements selected APIs in the IMS environment. - web-based application, which takes advantage of Parlay X APIs and implements enduser service with rich contacts management functionality. The environment became a playground for research on aspects of creating service applications in a multi-layered, real-time and asynchronous next generation telecommunication network.
Modele implementacji usług w architekturze IMS Streszczenie IMS jest architekturą usługową opracowaną przez 3GPP dla sieci UMTS. Referencyjny model sieci NGN, który jest definiowany przez ETSI oraz ITU wykorzystuje IMS w swojej rdzeniowej części. Nowa architektura oferuje szeroki zakres funkcjonalności, otwierający nowe moŝliwości kreacji usług. Wymaga to opracowania modeli programistycznych, które będą odpowiednie do nowego środowiska sieciowego. Parlay X jest zbiorem API umoŝliwiających tworzenie aplikacji w sposób niezaleŝny od rozwiązań technicznych zastosowanych w sieci. Zbiór ten złoŝony jest z abstrakcyjnych metod (np. makecall), które opisują podstawowe funkcjonalności sieci. Implementacja Parlay X API jako serwera aplikacyjnego wykorzystującego protokół SIP, umozliwia integracje z systemem IMS. Jain-SLEE jest środowiskiem programistycznym opartym o model komponentowy umoŝliwiający tworzenie aplikacji, realizujących usługi telekomunikacyjne. W odróŝnieniu od Parlay, definiuje zarówno API jak i środowisko wykonywania usług. Wykorzystując tzw. SIP resource adapter, aplikacje Jain-SLEE mogą być wykorzystywane do implementacji usług w IMS. Przedmiotem niniejszej pracy jest analiza architektury usługowej IMS oraz technik programistycznych, które mogą być wykorzystane w procesie implementacji. Zakres obejmuje takŝe implementacje środowiska IMS opartego o oprogramowanie open source. Ten proces moŝna podzielić na 3 obszary: - Model sterowania połączeniami w IMS, który polega na przekazywaniu obsługi zgłoszeń do serwerów aplikacyjnych w oparciu o profil uŝytkownika. - Serwery implementujące wybrane interfejsy Parlay X w środowisku IMS - Aplikacje wykorzystująca Parlay X API, do implementacji scenariusza usług. Powstałe środowisko zostało wykorzystane do badań związanych z róŝnymi aspektami kreacji usług w wielowarstwowej architekturze sieci następnej generacji.
śyciorysy Michał Jan Kościesza Urodziłem się w 29 października 1981 roku w Nowym Sączu. Ukończyłem Liceum Ogólnokształcące im. Jana Zamoyskiego w Warszawie i w roku 2002 rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych. Po dwóch latach wybrałem specjalność Teleinformatyka i Zarządzanie w Telekomunikacji. Od 2005 roku pracuję w Działe Rozwoju Sieci Rdzeniowej i Usług firmy Polkomtel S.A. Zdobytą na studiach wiedzę, a w szczególności tą podczas badań związanych z przedmiotem tej pracy, z sukcesem wykorzystuję w Ŝyciu zawodowym. Michał Daniel Misiak Urodziłem się w 11 grudnia 1982 roku w Płocku. Ukończyłem Liceum Ogólnokształcące im. Władysława Jagiełło w Płocku i w roku 2002 rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych. Po dwóch latach studiów wybrałem specjalność Teleinformatyka i Zarządzanie w Telekomunikacji. W 2006 roku odbyłem stypendium zagraniczne Sokrates-Erasmus w Niemczech na uczelni Hochschule Esslingen na wydziale informatyki. W połowie 2006 roku przyjąłem propozycję stworzenia własnego działu Rozwoju Produktu w etel Telecom Austria Group i do chwili obecnej piastuję stanowisko kierownika tegoŝ działu. Solidna wiedza zdobyta na studiach pozwala mi realizować się w Ŝyciu zawodowym. Prywatnie interesuje się fizyką teoretyczną oraz sportami motorowodnymi.
Autorzy pragną podziękować Panu dr inŝ. Markowi Średniawie za nieocenioną pomoc w trakcie pisania niniejszej pracy
Spis treści śyciorysy... 2 ABSTRACT... 2 SPIS TREŚCI... 5 1. WSTĘP... 9 2. SESSION INITIATION PROTOCOL... 15 2.1 WSTĘP... 15 2.2 BUDOWA PROTOKOŁU ORAZ MODEL SESJI... 15 2.3 KIERUNKI ROZWOJU I ROLA SIP W IMS... 19 3. IP MULTIMEDIA SUBSYSTEM... 23 3.1 WSTĘP... 23 3.2 IMS JAKO RDZENIOWA CZĘŚĆ ARCHITEKTURY NGN... 24 3.3 ARCHITEKTURA IMS... 27 3.4 PROFIL UśYTKOWNIKA... 33 3.5 MODEL STEROWANIA USŁUGAMI... 35 3.6 PROCES NAWIĄZYWANIA SESJI... 38 3.7 KIERUNKI ROZWOJU... 38 4. PARLAY/OSA ORAZ PARLAY X... 42 4.1 GENEZA PARLAY/OSA... 42 4.2 OPIS PARLAY/OSA... 43 4.3 ARCHITEKTURA PARLAY/OSA... 44 4.4 OGRANICZENIA PARLAY/OSA... 46 4.5 PARLAY X (PARLAY WEB SERVICES)... 46 4.6 MODELE BIZNESOWE... 47 4.7 FUNKCJONALNOŚĆ PARLAY X API... 48 4.8 ARCHITEKTURA PARLAY X... 50 4.9 OGRANICZENIA PARLAY X... 54 4.10 BEZPIECZEŃSTWO PARLAY X... 55 4.11 MIEJSCE PARLAY/OSA I PARLAY X W ARCHITEKTURZE IMS... 57 5. JAIN SERVICE LOGIC EXECUTION ENVIRONMENT... 60 5.1 INICJATYWA JAIN... 60 5.2 DEFINICJA JSLEE, WYMAGANIA DLA JSLEE... 62 5.3 PORÓWNANIE TECHNIK J2EE I JSLEE... 64 5.4 PORÓWNANIE TECHNIK JSLEE VS SIP SERVLET... 67 5.5 ARCHITEKTURA JSLEE... 71
Spis Treści 5.6 PRZYKŁADOWA USŁUGA BLOKOWANIE POŁĄCZEŃ... 83 6. ROLA WOLNEGO OPROGRAMOWANIA W TWORZENIU USŁUG TELEKOMUNIKACYJNYCH... 87 6.1 WSTĘP... 87 6.2 LINUX W ZASTOSOWANIACH TELEKOMUNIKACYJNYCH... 88 6.3 OPEN SOURCE JSLEE MOBICENTS... 89 6.4 OPEN SIP EXPRESS ROUTER... 90 6.5 ASTERISK... 92 6.6 OPEN IMS CORE... 96 7. SPECYFIKACJA PROBLEMU I CELE ANALIZY... 99 8. ARCHITEKTURA ŚRODOWISKA BADAWCZEGO... 103 9. IMPLEMENTACJA I ANALIZA MODELU STEROWANIA USŁUGAMI ZAPROPONOWANEGO W IP MULTIMEDIA SUBSYSTEM... 107 9.1 OPIS ZAIMPLEMENTOWANYCH MECHANIZMÓW... 108 9.2 PROCEDURA WSTAWIENIA INFORMACJI O IDENTYFIKACJI UśYTKOWNIKA (ASSERT IDENTITY). 108 9.3 PROCEDURA PRZYDZIELENIA SERWERA S-CSCF PODCZAS PIERWSZEJ REJESTRACJI AGENTA UśYTKOWNIKA (USER-REGISTRATION-QUERY)... 110 9.4 ZAIMPLEMENTOWANY PROCES REJESTRACJI UśYTKOWNIKA I REALIZACJA MOBILNOŚCI W SIECI... 123 9.5 MODEL STEROWANIA USŁUGAMI Z WYKORZYSTANIEM FEDERACJI SERWERÓW APLIKACYJNYCH... 127 9.6 INTERAKCJE POMIĘDZY USŁUGAMI I SERWERAMI APLIKACYJNYMI... 133 10. ANALIZA I IMPLEMENTACJA INTERFEJSÓW PARLAY X W MODELU USŁUGOWYM IMS... 137 10.1 STEROWANIE ZESTAWIANIEM POŁĄCZEŃ PRZEZ TRZECIĄ STRONĘ (INTERFEJS THIRD PARTY CALL)... 138 10.2 OBSŁUGA POŁĄCZEŃ (INTERFEJS CALL HANDLING)... 152 10.3 INFORMACJA O STATUSIE TERMINALA (INTERFEJS TERMINAL STATUS)... 160 10.4 ZARZĄDZANIE LISTĄ KONTAKTÓW (INTERFEJS ADDRESS LIST MANAGEMENT)... 164 10.5 INFORMACJA O STATUSIE OBECNOŚCI (INTERFEJS PRESENCE)... 167 11. CENTRUM KOMUNIKACJI OSOBISTEJ... 174 11.1 ZAŁOśENIA PROJEKTOWE DLA APLIKACJI... 174 11.2 ARCHITEKTURA APLIKACJI... 175 11.3 PROCES TWORZENIA APLIKACJI Z WYKORZYSTANIEM PARLAY X... 178 11.4 KOMPONENTY APLIKACJI... 179 11.5 OGRANICZENIA I PROPOZYCJE ICH ROZWIĄZANIA... 186 12. PODSUMOWANIE... 189 7
Spis Treści 13. BIBLIOGRAFIA... 194 14. WYKAZ STOSOWANYCH SKRÓTÓW... 198 ZAŁĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, STOSOWANE PODCZAS ANALIZY... 201 ZAŁĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, STOSOWANE PODCZAS ANALIZY... 201 ZAŁĄCZNIK B: INSTRUKCJA URUCHOMIENIA SERWERÓW CSCF I HSS... 204 ZAŁĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERÓW IMPLEMENTUJĄCYCH PARLAY X API... 206 ZAŁĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERA OBECNOŚCI... 209 ZAŁĄCZNIK D: INSTRUKCJA INSTALACJI APLIKACJI CENTRUM KOMUNIKACJI OSOBISTEJ... 210 ZAŁĄCZNIK E: KONFIGURACJA I URUCHOMIENIE BRAMY MEDIALNEJ... 212 8
1. Wstęp Ewolucja sieci telekomunikacyjnej spowodowana jest koniecznością tworzenia nowych usług i doskonalenia dotychczasowych. Aby to osiągnąć, stosuje się róŝne koncepcje i rozwiązania. Sieć inteligentną (Intelligent Network) moŝna uznać za jedną z pierwszych takich koncepcji. Architektura IN udostępniła funkcjonalność usługową sieci przez rozdzielenie funkcji związanych ze sterowaniem połączeniami i zgłoszeniami (SSP) od funkcji związanych z wykonywaniem usług o wartości dodanej (SCP). IN wprowadza model sterowania scenariuszem usługi oraz środowisko kreacji. Istotną wartością dodaną, jaką koncepcja sieci inteligentnej wniosła do świata telekomunikacyjnego, było dostrzeŝenie potrzeby standaryzacji tam, gdzie dotychczas jej nie było, czyli w obszarze usług 1. Pomimo tych udoskonaleń, oferowane aplikacje były jedynie nowymi wariacjami tradycyjnej usługi głosowej 2, polegającymi głównie na odpowiednim sterowaniu jej scenariuszem. Postrzeganie usług przez abonentów zmieniło się diametralnie w momencie pojawienia się Internetu. Stał się on kopalnią nowych usług w wyniku odwrócenia paradygmatu umiejscowienia inteligencji w sieci. Usługi stały się aplikacjami, a ich logika znajdowała się na obrzeŝach - w terminalach uŝytkowników 3, a Internet stanowił jedynie medium do transmisji danych. W związku z tym wiele usług mogło być realizowanych z pominięciem operatorów telekomunikacyjnych, a ich rola mogła zostać ograniczona głównie do zapewnienia szerokopasmowego dostępu do sieci. Szybki rozwój sieci pakietowych i coraz większa powszechność rozwiązań bazujących na IP spowodowała powstanie wielu koncepcji łączących moŝliwości Internetu i telekomunikacji. Początkowo były to proste próby przeniesienia usługi głosowej (tzw. Voice Over IP), jednak w miarę rozwoju pakietowej transmisji danych, zaczęto pracować nad zastąpieniem dotychczasowej architektury sieci telekomunikacyjnej przez architekturę opartą 1 Standaryzacji został poddany interfejs pomiędzy SSP a SCP. Środowisko uruchomieniowe i model programistyczny pozostały poza normalizacją, co spowodowało, Ŝe aplikacje realizujące usługi nie były przenośne pomiędzy rozwiązaniami róŝnych dostawców. Ze względu na to wprowadzenie IN doprowadziło do częściowego tylko otwarcia sieci na model realizacji usług przez trzecią stronę. 2 Oczywiście nie naleŝy zapominać, iŝ w tejŝe sieci oprócz usług głosowych moŝna było realizować usługę wideotelefonii. Jednak zainteresowanie tą usługą w śród uŝytkowników było marginalne. 3 W IN ma miejsce odwrotna sytuacja. Aplikacja realizująca usługę jest wykonywana po stronie sieci.
Wstęp o protokół IP. Model NGN 4 stał się urzeczywistnieniem tych prac i miał na celu opracowanie uniwersalnej sieci usługowej pozwalającej zarówno na komunikację głosową, jak i transmisję wideo oraz danych, z uwzględnieniem róŝnych wymagań jakościowych. IP Multimedia Subsystem jest architekturą usługową, która stanowi rdzeniowy element sieci NGN. IMS ma zapewnić neutralność dostępową (w załoŝeniu), ujednolicić sterowanie zgłoszeniami oraz zdefinować styk z warstwą aplikacyjną, tworząc tym samym spójne środowisko do kreacji usług konwergentnych 5. To środowisko dostarcza narzędzi pozwalających przyspieszyć proces budowy nowych usług oraz obniŝyć ich koszt 6. Protokołem wykorzystywanym w IMS jest rozszerzona wersja Session Initiation Protocol. Cechy SIP umoŝliwią realizację złoŝonych usług konwergentnych, które w jednej sesji komunikacyjnej mogą łączyć wideo, głos, przesyłanie danych (np., komunikaty natychmiastowe) oraz uwzględniać informację o obecności 7. Istotnym elementem środowiska IMS są serwery aplikacyjne, w których następuje wykonywanie aplikacji realizujących usługi. Wbrew pozorom, standard IMS pozostawia duŝą swobodę i elastyczność w ich tworzeniu, poniewaŝ nie definiuje modelu komponentów aplikacyjnych ani środowiska wykonywania usług. Takie podejście sprawia, Ŝe implementacja wymaga adaptacji odpowiednich technik programistycznych (np. Web Services, Servlety, etc..). Informatyka od połowy lat 60 XX wieku wpływa na kształt rozwiązań stosowanych w telekomunikacji (np. zastosowanie sterowania programowego w centralach 1 ESS). W miarę rozwoju techniki i koncepcji w informatyce konwergencja pomiędzy tymi dwoma dziedzinami staje się coraz głębsza. Szczególnie chętnie adoptowane są powszechnie stosowane techniki (np. Java, Web Services), które umoŝliwiają tworzenie usług szerszej grupie osób. W warstwie aplikacji projektant moŝe korzystać z wielu rozwiązań, choćby takich jak: SIP Servlet API, JAIN SIP API, JAIN SLEE, Parlay/OSA API, Parlay X. KaŜda z tych technik ma cechy, które sprawiają, Ŝe kaŝda z tych aplikacji lepiej się sprawdza w określonym zastosowaniu niŝ pozostałe. Przykładowo Parlay X moŝe być wykorzystany w sytuacji, gdy operator chciałby udostępnić funkcjonalność sieci w bezpieczny sposób jak najszerszej grupie 4 Patrz rozdział 3. 5 Usług, w których przenikają się róŝne formy komunikacji, jak np. głos, wideo, wiadomości natychmiastowe, lub szeroko rozumiana obecność. 6 Ze względu na brak dojrzałych implementacji w komercyjnych sieciach, postulat dotyczący optymalizacji pod względem kosztu i czasu wdroŝenia usług nie został jeszcze w praktyce sprawdzony. 7 Z ang. Presence 10
Wstęp potencjalnych twórców aplikacji. Jeśli natomiast pojawia się potrzeba udostępnienia bardziej zaawansowanej 8 funkcjonalności, ale wciąŝ dostępnej dla szerokiego kręgu dostawców, najlepiej w tym przypadku jest zastosować Parlay/OSA API. Zakładając, Ŝe aplikacja ma wykorzystywać niskopoziomową funkcjonalność sieci a jednocześnie charakteryzować się wysoką wydajnością, naleŝałoby zastanowić się na uŝyciem do tego celu JAIN SIP. Standard JAIN SLEE jest wynikiem dąŝenia do stworzenia jednolitego modelu programistycznego oraz środowiska wykonawczego dla usług 9. W architekturze JSLEE aplikacja zbudowana jest z mniejszych komponentów (Service Building Block), których moŝna ponownie uŝyć do budowy innych aplikacji. Jest to pewnego rodzaju rozszerzenie idei Service Independent Block z IN 10. Ponadto środowisko Java oraz zastosowana koncepcja kontenera sprawia, Ŝe aplikacje wykazują pełną przenośność pomiędzy róŝnymi implementacjami JSLEE 11. Te dwa główne aspekty pozwalają urzeczywistnić głoszone slogany marketingowe, takie jak optymalizacja time-to-market oraz usługa typu off-theshelf. Podsumowując dokonania w dziedzinie telekomunikacji moŝna stwierdzić, Ŝe na dzień dzisiejszy dysponujemy zestandaryzowanym pełnym modelem wykonywania i tworzenia usług konwergentnych. W skład tego modelu wchodzi architektura IMS 12, środowisko wykonywania aplikacji JSLEE, narzędzia wspomagające tworzenie aplikacji tzw. IDE 13 oraz interfejs Parlay X eksponujący funkcje sieci na wysokim poziomie abstrakcji. W niniejszej pracy zostało stworzone rzeczywiste środowisko składające się z wyŝej wymienionych elementów. Doświadczenia związane z implementacją tego środowiska oraz przykładowej usługi Centrum Komunikacji Osobistej stanowiły podstawę do szczegółowej analizy moŝliwości i cech przyjętego modelu. 8 Wymagającej dostępu do sieci na niŝszym poziomie abstrakcji. 9 Analogicznie jak J2EE w rozwiązaniach IT. 10 JSLEE zostały zdefiniowane jedynie reguły, według których SBB mają być tworzone, dlatego teŝ zbiór SBB nie jest z góry narzucony. 11 Okazało się to niemoŝliwe w przypadku IN. 12 Implementacje pełnej architektury IMS w komercyjnych sieciach są bardzo nieliczne. 13 Integrated Development Environment. 11
Wstęp Cele Pracy Analiza modelu sterowania usługami zaproponowanego w IMS. Określenie jak mechanizmy protokołu SIP są wykorzystywane do budowy modelu usługowego, jakie są korzyści i negatywne strony związane z jego zastosowaniem oraz jakie są moŝliwości optymalizacji. Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje procesu tworzenia usług. Określenie jak wygląda model implementacji usług w środowisku dwuwarstwowym (warstwa komponentów aplikacyjnych i warstwa aplikacji) na przykładzie Parlay X i JSLEE. Jakie są korzyści i jakie ograniczenia przy takim podejściu. Analiza implementacji usług w róŝnych modelach programistycznych. Określenie jak róŝne modele programistyczne wpływają na proces tworzenia. Analiza moŝliwości wykorzystania rozwiązań open-source w telekomunikacji. Układ pracy Ocena jak oprogramowanie typu open source wpływa na rozwój współczesnej telekomunikacji, jakie są kierunki zmian i potencjalne korzyści. Praca jest podzielona na dwie części. Pierwsza z nich obejmuje ogólną charakterystykę wszystkich obszarów, które zostały poddane analizie tj. architektura IMS, protokół SIP, koncepcja Parlay i Parlay X oraz architektura JAIN SLEE, która została omówiona bardziej szczegółowo ze względu na niewielką liczbę, obecnie dostępnych opracowań tego rozwiązania. Druga część jest poświęcona analizie realizacji usług w architekturze IMS. Zawiera ona opis zaimplementowanego, środowiska modelującego system IMS, które było podstawą do analizy zagadnień poruszanych w tej pracy. Poszczególne rozdziały zostały opracowane przez dwóch autorów. Podział przedstawia się następująco: 1. Wstęp Michał Misiak Część I 2. Session Initiation Protocol Michał Kościesza 3. IP Multimedia Subsystem Michał Kościesza 4. Parlay/OSA oraz Parlay X Michał Misiak 5. JAIN Service Logic Execution Environment Michał Misiak 6. Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych 6.1 Wstęp Michał Misiak 12
Wstęp 6.2 Linux w zastosowaniach telekomunikacyjnych Michał Misiak 6.3 Open Source JSLEE Mobicents Michał Misiak 6.4 Open SIP Express Router Michał Kościesza 6.5 Asterisk Michał Misiak 6.6 Open IMS Core Michał Kościesza Część II 7. Specyfikacja problemu i cele analizy Michał Kościesza 8. Architektura środowiska badawczego Michał Kościesza 9. Implementacja i analiza modelu sterowania usługami Michał Kościesza zaproponowanego w IP Multimedia Subsystem 10. Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS 10.1 Sterowanie zestawianiem połączeń przez trzecią stronę Michał Misiak (interfejs Third Party Call) 10.2 Obsługa połączeń (interfejs Call Handling) Michał Misiak 10.3 Informacja o statusie terminala (interfejs Terminal Status) Michał Misiak 10.4 Zarządzanie listą kontaktów (interfejs Address List Michał Kościesza Management) 10.5 Informacja o statusie obecności (interfejs Presence) Michał Kościesza 11. Centrum Komunikacji Osobistej Michał Misiak 12. Podsumowanie Michał Kościesza Michał Misiak Podział związany z implementacją elementów środowiska badawczego: Model sterowania usługami IMS (P-CSCF, S-CSCF, HSS) Serwery implementujące interfejsy Pralay X: Third Party Call Call Handling Terminal Status Address List Management Presence Aplikacja Centrum Komunikacji Osobistej Michał Kościesza Michał Misiak Michał Misiak Michał Misiak Michał Kościesza Michał Kościesza Michał Misiak 13
Część I Podstawy teoretyczne
2. Session Initiation Protocol 2.1 Wstęp SIP jest protokołem warstwy aplikacyjnej umoŝliwiającym sterowanie procesem zestawiania, modyfikacji oraz rozłączania sesji multimedialnych 14 [22]. SIP zapewnia takie elementarne mechanizmy jak: lokalizacja terminala uŝytkownika 15, określenie dostępności uŝytkownika, negocjacja parametrów połączenia oraz zestawianie i zarządzanie sesją multimedialną. Pierwsza wersja protokołu została zaprojektowana przez Henninga Schulzrinne a i Marka Handlera w 1996. Najbardziej aktualną normą IETF definiującą bazowe mechanizmy protokołu jest RFC 3261 [22]. W roku 2000, w ramach prac na standardem IMS, 3GPP znacznie rozszerzyła funkcje SIP i włączyła go do grupu norm dla sieci UMTS. Warto zaznaczyć, Ŝe SIP nie jest protokołem, który umoŝliwia realizację kompletnego systemu komunikacyjnego, jest raczej składnikiem, który razem z innymi protokołami takimi jak SDP (opis parametrów sesji) albo RTP (protokół transportu strumieni medialnych) moŝe być wykorzystany do takich celów. 2.2 Budowa protokołu oraz model sesji SIP jest protokołem tekstowym o składni zbliŝonej do HTTP. W warstwie transportowej moŝe być przenoszony zarówno za pomocą protokołu UDP jak i TCP/TLS. Podobnie jak HTTP, SIP jest oparty o 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. Wiadomości protokołu moŝna podzielić na Ŝądania i odpowiedzi. Podstawowymi rodzajami Ŝądań są: INVITE jest to pierwsza wiadomość rozpoczynająca proces inicjacji sesji. ACK wysyłana jest w celu potwierdzenia zgody na przyjęcie sesji od wywoływanej strony. BYE powoduje zakończenie trwającej sesji. 14 sesja multimedialna moŝe być przekazem wideo, audio, komunikatów tekstowych itd.. 15 moŝliwość określenia adresu sieciowego terminala uŝytkownika.
Session Initiation Protocol CANCEL kończy proces nawiązywania sesji. OPTIONS umoŝliwia poznanie obsługiwanych mechanizmów terminala, do której jest adresowana. REGISTER umoŝliwia rejestrację lokalizacji sieciowej terminala uŝytkownika 16. Odpowiedzi moŝna pogrupować na serie określające klasę przenoszonych informacji (podobnie jak w HTTP): 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 Fund ) 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 Rys. 1 przedstawia przykład wiadomości SIP (Ŝądanie). Wiadomość złoŝona jest z tzw. pierwszej linii określającej rodzaj i adres systemu, do którego jest kierowane zgłoszenie (tzw. Request-URI albo R-URI) oraz z nagłówków określających róŝne parametry zgłoszenia. 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 zgłoszenia. 16 Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem uŝytkownika (np. sip:ala@eims.local) 16
Session Initiation Protocol Rys. 1: Przykładowa wiadomość INVITE protokołu SIP Na Rys. 2 przedstawiono przykładowy scenariusz nawiązania sesji oraz jej zakończenia. Rys. 2: Nawiązywanie i rozłączanie sesji W architekturze 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 17
SIP Session Initiation Protocol 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 17. System serwerów Proxy, Registrar i agentów uŝytkownika (UA) tworzy model sesji, który jest określany jako trapez SIP (Rys. 3). Rys. 3: Model sesji opartej o SIP ("trapez SIP") UA nawiązują połączenie wykorzystując serwery Proxy, które dysponują informacją o adresacji terminali (funkcja lokalizacji). Po nawiązaniu połączenia 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ę przy pomocy protokołu SDP, który jest przenoszony wewnątrz wiadomości SIP. Ten mechanizm jest oparty o model negocjacji zdefiniowany w [23]. Szczegółowa analiza mechanizmów protokołu SIP jest zawarta w [12]. 17 Ten mechanizm jest zbliŝony do NAT w sieci TCP/IP, tylko jest przeprowadzany na warstwie protokołu SIP. 18
Session Initiation Protocol 2.3 Kierunki rozwoju i rola SIP w IMS Protokół SIP zdefiniowany w [22] 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 wzbogacenie bazowego SIP o nowe mechanizmy na przykład takie jak realizacja usługi natychmiastowych wiadomości (z ang. Instant Messaging, IM) albo publikacji statusu obecności uŝytkownika (z ang. Instant Presence). Do maja 2007 roku opublikowano około 50 róŝnego rodzaju rozszerzeń SIP względem bazowej normy, które otrzymały status norm IETF RFC 18. SIP został wybrany jako podstawowy protokół sterowania połączeniami i zgłoszeniami w systemie IMS (opis w rozdziale 3.) dla sieci UMTS. Prace ETSI [17] i ITU [35] wykorzystują IMS jako rdzeniową część w nowym modelu sieci telekomunikacyjnej - NGN. W związku z tym, SIP został protokołem słuŝącym do sterowania połączeniami i zgłoszeniami w projektowanej publicznej sieci telekomunikacyjnej następnej generacji. Do zastosowań telekomunikacyjnych definicja protokołu zawarta w RFC 3261 nie jest wystarczająca. Przykładowo brakuje w niej mechanizmów umoŝliwiających interakcje z sieciami PSTN bez utraty określonych informacji o realizowanym połączeniu, mechanizmów pozwalających na kontrolę przez operatora negocjowanych parametrów połączenia potrzebnych do QoS oraz funkcji związanych z taryfikacją. Ze względu na to, standardy 3GPP wprowadzają szereg rozszerzeń i definiują, na potrzeby IMS, tzw. profil protokołu SIP [7], który jest złoŝony z bazowego standardu [22] 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: 18 Dane na podstawie IETF WG-SIP (http://www.ietf.org/html.charters/sip-charter.html). 19
Session Initiation Protocol 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 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 kompatybilności z siecią PSTN (współpraca SIP- ISUP). rekordy NAPTR w systemie DNS dla protokołu SIP (RFC 3263) - 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 [22]). 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 na łączu radiowym w IMS stosuje się kompresję. nagłówek Privacy (RFC 3323) umoŝliwia określanie poziomów prywatności dla sesji. Ma to wpływ między innymi na taki aspekt jak prezentacja numeru. nagłówki P-Asserted-Identity i P-Preferred-Identity (RFC 3325) te dodatkowe nagłówki przenoszą informacje dotyczącą strony inicjującej połączenie. Zgodnie [22] taka informacja zawarta jest w nagłówku From, ale ze względu na wymogi związane z taryfikacją (From jest formowane przez terminal uŝytkownika) w IMS stosuje się 20
Session Initiation Protocol dodatkową informację, która jest wstawiana do wiadomości przez elementy systemu IMS. nagłówek Reason (RFC 3326) przenosi dodatkowe informacje dotyczące przyczyny określonych zdarzeń w sieci. Wymagany jest w celu zachowania kompatybilności IMS z siecią PSTN. nagłówek Path (RFC 3327) umoŝliwia kierowanie wiadomości do uŝytkownika w sytuacji, w której pomiędzy serwerem rejestrującym (Registrar), a terminalem uŝytkownika jest serwer Proxy. nagłówki P-Headers (RFC 3455) są to 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 potrzebne do taryfikacji. wiadomość REFER (RFC 3515) wspomaga realizacje takich usług jak przekazanie połączenia (call transfer) i konferencja. 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. 21
Session Initiation Protocol 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: Scenariusze nawiązania sesji: SIP podstawowy i SIP IMS 19 (na podstawie [6]) Jedną z podkreślanych cech protokołu SIP jest jego prostota 20. Aby umoŝliwić świadczenie usług telekomunikacyjnych, 3GPP wprowadziło szereg rozszerzeń, które mają zastosowanie w systemie IMS. SIP zgodny z IMS cechuje się dwukrotnie większą ilością wiadomości, kilkunastoma dodatkowymi nagłówkami i specyficznymi, względem standardu pierwotnego, mechanizmami. Rys. 4 przedstawia scenariusz nawiązania sesji wykorzystujący podstawową wersję protokołu SIP oraz wersję zgodną z IMS. Aby nawiązać połączenie VoIP 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. 19 Serwery pośredniczące zostały pominięte. 20 SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń. 22
3. IP Multimedia Subsystem 3.1 Wstęp IP Multimedia Subsystem (IMS) po raz pierwszy pojawia się w piątej wersji norm 3GPP definiujących UMTS (3GPP UMTS Release 5) [3], gdzie stanowi dodatkowy komponent (podsystem) w architekturze sieci. Główną jego funkcja jest prawie wyłącznie realizacja dodatkowych usług multimedialnych w dziedzinie pakietowej (np. Video-sharing, Push-To-Talk 21 ). Wraz z rozwojem koncepcji Sieci Następnej Generacji (Next Generation Network, NGN), IMS staje się (3GPP Release 6) kluczowym systemem rdzeniowej części UMTS, realizującym zarówno klasyczne usługi telefoniczne jak i nowe, tzw. usługi konwergentne, które łączą moŝliwości sieci pakietowych i sieci z komutacją łączy. IMS umoŝliwia tworzenie róŝnorodnych usług wykorzystujących: multimedia (w tym tradycyjne połączenie głosowe), transmisje danych oraz szeroko rozumiany kontekst komunikacji. Wszystkie te składowe mogą się wzajemnie przenikać w budowanych scenariuszach usługowych. Aktualne prace standaryzacyjne nad 3GPP Release 7 i 8 są wykorzystywane przez ETSI i ITU do stworzenia architektury sieci NGN, czyli sieci pakietowej, zdolnej do świadczenia usług telekomunikacyjnych, która jest niezaleŝna od rodzaju techniki dostępowej [33]. ETSI rozszerza funkcje IMS o konwergencje z sieciami stacjonarnymi i w ten sposób IMS staje się systemem, który stanowi rdzeń w nowej uniwersalnej, publicznej sieci telekomunikacyjnej. Integrująca i unifikująca rola IMS jest wielopłaszczyznowa, dotyka warstwy dostępowej, sterowania połączeniami i warstwy aplikacyjnej, czyli miejsca realizacji usług. Usługi o wartości dodanej 22 są postrzegane jako waŝny wyróŝnik atrakcyjności sieci telekomunikacyjnej, aby sprostać temu wymaganiu, niezbędna jest zmiana paradygmatu wprowadzania nowych aplikacji. IMS zawiera w sobie mechanizmy, których celem jest umoŝliwienie budowy aplikacji o bogatej funkcjonalności oraz optymalizacja tego procesu zarówno pod względem kosztowym jak i czasowym. 21 Usługa Push-to-Talk zdefiniowana jest w OMA, Push to talk Over Cellular v1.0 (http://www.openmobilealliance.org/) 22 Usługi o wartości dodanej są to usługi, których funkcje wykraczają poza podstawową funkcje sieci, jaką jest zestawienie połączenia pomiędzy dwoma uŝytkownikami.
IP Multimedia Subsystem 3.2 IMS jako rdzeniowa część architektury NGN Terminem Sieć Następnej Generacji określa się architekturę sieci opartą o komutacje pakietów, zdolną do realizacji usług telekomunikacyjnych wykorzystujących róŝne przepływności dostarczane przez róŝne techniki dostępowe. Zgodnie z [33] najwaŝniejszymi cechami sieci w architekturze NGN są: komutacja pakietów; separacja funkcji sterowania połączeniami i zgłoszeniami od funkcji transportowych i funkcji związanych z usługami; otwarte interfejsy; zdolność do realizacji szerokiego zakresu usług; szerokopasmowa transmisja z zaimplementowanymi mechanizmami QoS; współpraca z sieciami tradycyjnymi (z siecią PSTN); konwergencja pomiędzy usługami sieci stacjonarnej i mobilnej; niezaleŝność usług od technik dostępowych; otwartość dla róŝnych technik realizacji dostępu. Rys. 5: Referencyjna funkcjonalna architektura NGN (źródło [17]) Zgodnie z referencyjną funkcjonalną architekturą ETSI (patrz Rys. 5) sieć NGN moŝna podzielić na: 24
IP Multimedia Subsystem warstwę funkcji transportowych (Transfer Functions) grupuje wszystkie mechanizmy odpowiedzialne za udostępnienie łącza danych, które często nazywane jest określeniem IP-CAN (IP Connectivity Access Network). Realizacja łącza IP moŝe odbywać się za pomocą dowolnych technik dostępowych. podsystem sterowania zasobami i dostępem (Resorce and Admission Control Subsystem, RACS) steruje przyznawaniem zasobów dla konkretnego ruchu generowanego przez uŝytkownika. Systemy z wyŝszych warstw (np. Core-IMS) instruują ten podsystem do stosowania odpowiednich polityk kontroli dostępu i QoS. podsystem powiązania sieciowego (Network Attachment Subsystem, NAS) jego głównym zadaniem jest uwierzytelnienie uŝytkownika w warstwie transportowej (np. PPP) oraz przyznanie adresacji IP. podsystem emulacji PSTN/ISDN (PSTN/ISDN Emulation subsystem) pozwala na obsługę sieci dostępowych opartych o komutacje łączy. Głównym zadaniem tego podsystemu jest emulacja PSTN/ISDN w sieci pakietowej. podsystem IMS (Core IMS 23 ) jest odpowiedzialny za sterowanie połączeniami i zgłoszeniami. warstwę aplikacji (Applications) zawiera funkcje realizujące usługi. Sieć UMTS 24 jest zgodna z modelem NGN ogólnie zdefiniowanym w [17] i [33]. Rys. 6 pokazuje architekturę UMTS, która jest połączeniem tradycyjnej sieci z komutacją łączy oraz sieci pakietowej. Część pakietowa UMTS razem z podsystemem IMS tworzy pełną sieć w modelu NGN. 23 W architekturze ETSI-NGN podsystem IMS nosi nazwę Core IMS. Jest spowodowane tym, Ŝe zgodnie z definicją 3GPP, IMS zawiera elementy realizujące sterowanie połączeniami i zgłoszeniami oraz warstwę serwerów aplikacyjnych, a definicja ETSI zawęŝa rolę IMS tylko do sterowania połączeniami i zgłoszeniami. 24 Dokładnie sieć UMTS w architekturze, co najmniej 3GPP Release 5. 25
IP Multimedia Subsystem Rys. 6: Dualna architektura sieci UMTS (źródło [3]) Jedną z waŝnych cech IMS, która zadecydowała o wykorzystaniu go w NGN, jest niezaleŝność warstwy usługowej od techniki dostępowej. KaŜdy terminal, który jest zdolny do nawiązania łączności IP z elementami IMS, moŝe korzystać z funkcji usługowych sieci telekomunikacyjnej, poniewaŝ wszystkie mechanizmy niezbędne do obsługi zgłoszeń są niezaleŝne od technik dostępowych. Przykładem tej neutralności dostępowej jest identyfikacja uŝytkownika, która w IMS odbywa się przy pomocy adresacji protokołu SIP, tzw. SIP-uri, który jest niezaleŝny od adresacji IP przyznawanej w podsystemach NAS, specyficznych dla danej sieci dostępowej. Podobnie jest w przypadku procedury uwierzytelnienia uŝytkownika, która moŝe być przeprowadzana w kaŝdej sieci dostępowej w specyficzny sposób, ale zawsze terminal uŝytkownika po uzyskaniu łączności IP z IMS jest poddawany powtórnemu uwierzytelnieniu poprzez protokół SIP. 26
IP Multimedia Subsystem Rys. 7: Model uniwersalnej sieci NGN Rys. 7 pokazuje model sieci NGN, w której IMS jest niezaleŝny od róŝnych technik dostępowych. 3.3 Architektura IMS IMS jest rdzeniowym elementem sieci NGN realizującym funkcje zwiane ze sterowaniem połączeniami i zgłoszeniami. W tym rozdziale zostanie omówiona architektura IMS zgodna ze specyfikacjami 3GPP 25, które określają funkcje IMS szerzej tj. oprócz funkcji sterowania połączeniami i zgłoszeniami, wyróŝniają takŝe funkcje związane z aplikacjami realizującymi usługi i funkcje bram medialnych. 25 Dokładnie z wersją 6 tj. 3GPP Release 6. 27
IP Multimedia Subsystem Rys. 8: Architektura IMS Elementy funkcjonalne systemu IMS oraz protokoły stosowane na interfejsach są pokazane na Rys. 8. Jak moŝna zauwaŝyć, wykorzystywane są cztery protokoły sygnalizacyjne: SIP do sterowania połączeniami i zgłoszeniami, H.248/MEGACO jako protokół słuŝący do sterowania bramami medialnymi, DIAMETER wykorzystywany do autoryzacji zgłoszeń oraz parametrów QoS oraz SCTP, który stanowi protokół transportowy do wyŝszych warstw stosu SS7 po sieci IP. W architekturze funkcjonalnej IMS (Rys. 8) moŝna wyróŝnić 3 warstwy: warstwa urządzeń końcowych i bram obejmuje elementy odpowiedzialne za obsługę ruchu uŝytkowego. NaleŜą do niej takie elementy jak: bramy medialne (IM- MGW), serwery zajmujące się generowaniem treści (MRFP) oraz urządzenia końcowe odpowiedzialne za odbiór i nadawanie ruchu uŝytkowego. warstwa sterowania połączeniami i zgłoszeniami obejmuje wszystkie elementy odpowiedzialne za sterowanie połączeniami i zgłoszeniami. NaleŜą do niej elementy takie jak: S-CSCF, I-CSCF, P-CSCF, HSS, SLF, BGCF, MGCF, MRFC, PDF, SGW. 28
IP Multimedia Subsystem warstwa aplikacyjna jest złoŝona z serwerów aplikacyjnych (AS) realizujących scenariusze usług Element funkcjonalne architektury IMS to: Serving-Call/Session Control Function (S-CSCF) Jest właściwym elementem systemu IMS odpowiedzialny za odpowiednie kierowanie zgłoszeń (w postaci wiadomości SIP). NajwaŜniejsze funkcje S-CSCF to: sterowanie sesją multimedialną, uwierzytelnienie uŝytkownika i sterowanie połączeniami. Dla kaŝdego zgłoszenia analizowanego w S-CSCF wybierany jest właściwy sposób obsługi tj: a. zgłoszenie moŝe być skierowane do terminala innego uŝytkownika; b. zgłoszenie moŝe być skierowane do serwera I-CSCF jeśli odbiorca jest obsługiwany w obcej sieci; c. zgłoszenie moŝe być skierowane do serwera aplikacyjnego jeśli profil uŝytkownika wskazuje na potrzebę realizacji usług. Rys. 9 pokazuje przykładowy scenariusz obsługi w S-CSCF. Na podstawie profilu uŝytkownika A, zgłoszenie zostaje skierowane do serwera aplikacyjnego (AS1) a następnie do innego (AS2). Po zakończeniu obsługi związanej z usługami, zgłoszenie jest kierowane do uŝytkownika B. 2. INVITE B 3. INVITE B 4. INVITE B 5. INVITE B Rys. 9: Analiza profilu w S-CSCF Z punktu widzenia modelu protokołu SIP, S-CSCF pełni funkcję serwera SIP-proxy i serwera Registrar. 29
IP Multimedia Subsystem Home Subscriber Server (HSS) Element HSS pełni funkcję uniwersalnego repozytorium danych skojarzonych z uŝytkownikiem. Dane te są to zarówno informacje potrzebne do spersonalizowanej realizacji usług w serwerach aplikacyjnych, jak i informacje niezbędne do realizacji podstawowych funkcji związanych ze sterowaniem połączeniami i zgłoszeniami bądź zarządzaniem mobilnością. HSS uczestniczy takŝe w procedurach uwierzytelnienia uŝytkownika (udostępnia wektory kryptograficzne) oraz przechowuje reguły obsługi zgłoszeń w określonych serwerach aplikacyjnych (tzw. reguły filtracji IFC). HSS Mobility Management User security info. generation User security support Identification handling Service authorization support Access authorization Service Provisioning support Call / Session establishment support Application Services Support CAMEL Services Support GUP Data Repository Wx C D Gr Gc Rp Sh Si Cx gsmscf SIP Application Server GMSC MSC / VLR SGSN GGSN OSA SCS IM-SSF CSCF CS Domain PS Domain IM CN subsystem 3GPP AAA Server Applications GUP Server Rys. 10: Logiczna architektura HSS (źródło [3]) HSS jest uniwersalnym repozytorium, oznacza to, Ŝe gromadzi dane wykorzystywane przez wszystkie elementy sieci komórkowej (nie tylko IMS). Rys. 10 pokazuje wszystkie logiczne funkcje i interfejsy HSS. Subscriber Location Function (SLF) Rola SLF w sieci IMS polega na informowaniu, w którym HSS znajduje się profil uŝytkownika. Funkcja SLF jest implementowana w sytuacji, kiedy w sieci znajduję się kilka serwerów HSS. Proxy-Call/Session Control Function (P-CSCF) Jest to serwer SIP-proxy, który pośredniczy pomiędzy terminalem uŝytkownika a S- CSCF. Jego główną funkcją jest kontrola dostępu, kontrola sesji w kontekście parametrów QoS oraz kompresja/dekompresja protokołu SIP. 30
IP Multimedia Subsystem Rys. 11: Rola P-CSCF Rys. 11 pokazuje rolę P-CSCF we współpracy z PDF i GGSN. Wiadomości inicjujące sesje są analizowane w P-CSCF i na ich podstawie P-CSCF razem z PDF otwiera moŝliwość transmisji ruchu uŝytkowego w GGSN oraz rezerwuje niezbędne zasoby zgodnie z profilem QoS 26. Policy Decision Function (PDF) Funkcja ta jest opowiedzialna za zcentralizowaną kontrolę wykorzystania i rezerwacji zasobów transmisyjnych. PDF otrzymuje od P-CSCF Ŝądane przez uŝytkowników parametry QoS dla danej sesji na podstawie, których podejmuje decyzje o zezwoleniu na połączenie. Funkcje PDF jest szczegółowo opisane w specyfikacji 3GPP TS 29.207 (Policy control over Go interface). Interrogating-Call/Session Control Function (I-CSCF) Pośredniczy w wymianie sygnalizacji (SIP) pomiędzy S-CSCF, a innymi sieciami (implementuje funkcje ukrywania topologii sieci). I-CSCF uczestniczy takŝe w procedurze rejestracji uŝytkownika, co jest szczegółowo opisane w rozdziale 9.3. Z punktu widzenia modelu protokołu SIP, I-CSCF jest serwerem SIP-proxy oraz implementuje funkcje B2BUA. Breakout Gateway Control Function (BGCF) 26 Sposób definicji Ŝądanych parametrów QoS za pomocą protokołu SIP/SDP definiuje RFC3312. 31
IP Multimedia Subsystem Bierze udział w zestawianiu połączenia, które ma się zakończyć w sieci PSTN. Główną funkcją BGCF jest określenie odpowiedniego serwera MGCF (w przypadku, gdy w sieci jest wiele serwerów MGCF) i przekazanie do niego zgłoszenia. Media Gateway Control Function, Media Gateway (MGCF, IM-MGW) Brama medialna i kontroler bramy medialnej łączą sieć IMS z siecią PSTN. MGCF odpowiedzialny jest za konwersje sygnalizacji pomiędzy SIP a ISUP (albo Q.931 w przypadku ISDN) oraz odpowiednie wysterowanie MGW, który odpowiedzialny jest za konwersję ruchu uŝytkowego pomiędzy łączami komutowanymi a strumieniami RTP 27. Signalling Gateway (SGW) Odpowiedzialny jest za przeniesienie protokołów wyŝszych warstw SS7 (np. ISUP) do sieci IP za pomocą protokołu SCTP 28. Multimedia Resource Function Controller, Multimedia Resource Function Processor (MRFC, MRFC) MRFC i MRFP są elementami realizującymi funkcje tzw. serwera mediów. Główną ich rolą jest udostępnianie i przetwarzanie treści multimedialnych. MRFC odpowiada za sygnalizacje, a MRFP za ruch uŝytkowy (strumienie medialne) 29. Przykładem wykorzystania tych elementów moŝe być implementacja mostka konferencyjnego, albo serwera poczty głosowej. Application Server (AS) Serwer aplikacyjny jest miejscem implementacji usług w sieci IMS. AS uczestniczy w realizacji połączeń w na kilka sposobów, tj. moŝe: a. odbierać i przetwarzać zgłoszenia (sekwencje wiadomości protokołu SIP) z S- CSCF, które wymagają obsługi związanej z usługami (rola 3 z Rys. 12); b. przyjmować połączenia (rola 1 z Rys. 12); c. inicjować połączenia (rola 2 z Rys. 12); 27 RTP jest protokołem transportowym strumieni medialnych w sieci IP (RFC 3550). 28 Protokół SCTP zdefiniowany jest w RFC 2960. 29 MRFC i MRFP są jednymi z najmniej dokładnie zdefiniowanymi elementami IMS. 32
IP Multimedia Subsystem d. realizować zestawienie połączenia w modelu trzeciej strony tzw. 3rd-Party- Call-Control (rola 4 z Rys. 12). Application Server Application Server SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 S-CSCF S-CSCF SIP leg #1 From: X To: Y Call-ID: Z From: X To: Y Call-ID: Z Application Server Application Server SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 From: X To: Y Call-ID: Z SIP leg #2 From: P To: Q Call-ID: R SIP leg #1 S-CSCF SIP leg #1 SIP leg #1 S-CSCF SIP leg #2 From: X To: Y Call-ID: Z From: X To: Y Call-ID: Z From: X To: Y Call-ID: Z From: P To: Q Call-ID: R Rys. 12: Role jakie moŝe przyjmować serwer aplikacyjny w obsłudze połączeń (źródło [4]) Z punktu widzenia modelu protokołu SIP, serwer aplikacyjny implementuje funkcje SIP-proxy, UA oraz B2BUA. 3.4 Profil uŝytkownika HSS przechowuje i udostępnia profile uŝytkowników, które zawierają dane wykorzystywane przez elementy IMS do świadczenia usług. Profil moŝe być pobierany z HSS przez serwery aplikacyjne, które przechowują w nim informacje potrzebne do personalizacji wykonywanych usług albo przez S-CSCF w celu realizacji procedur związanych ze sterowaniem usługami. KaŜdy profil składa się z informacji, która opisuje, w jakich sytuacjach i na jakie serwery aplikacyjne maja być kierowane zgłoszenia trafiające do S-CSCF. Stanowi to podstawę modelu sterowania usługami opisanego w rozdziale 3.5. 33
IP Multimedia Subsystem Struktura profilu jest definiowana przy pomocy języka UML 30. Rys. 13 przedstawia budowę profilu abonenta w HSS. Rys. 13: Struktura profilu w HSS W skład profilu uŝytkownika wchodzą takie informacje jak: Public Identification - jest to grupa publicznych identyfikatorów, którymi posługuje się uŝytkownik. Dany profil jest stosowany tylko, jeśli abonent posługuje się identyfikatorem wymienionym w tej grupie. 30 Unified Modeling Language (http://www.ogm.org/uml). 34
IP Multimedia Subsystem Core Network Service Authorization - są to informacje uwierzytelniające. Initial Filter Criteria - zawiera kryteria filtracji wiadomości na określony serwer aplikacyjny (szczegółowo jest to omówione poniŝej). Shared ifc Set - jest to wskazanie na kryteria filtracji współdzielone przez róŝnych uŝytkowników. Dla modelu sterowania usługami istotnym elementem profilu są kryteria filtracji (Initial Filter Criteria, IFC), które są analizowane w S-CSCF, gdy przychodzi wiadomość sygnalizacyjna SIP. Na podstawie tych danych, zostaje podjęta decyzja czy wiadomość (zgłoszenie) ma być skierowana na właściwy serwer aplikacyjny. MoŜliwości analizy wiadomości SIP są bardzo szerokie. Definicja IFC składa się z wyraŝenia przedstawiającego sumę lub negacje logiczną, warunków dotyczących części składowych wiadomości. Analizie mogą podlegać wszystkie nagłówki i pole SDP 31, do którego takŝe mogą być stosowane wyraŝenia regularne 32 (szerzej jest to omówione w rozdziale 1). Profil uŝytkownika jest przesyłany w postaci dokumentu XML o określonej składni. Definicja składni jest specyfikowana przy pomocy specjalnego XML-Schema 33. Szczegółowy opis budowy profilu zawarty jest w [9]. 3.5 Model sterowania usługami W IMS miejsce realizacji usługi o wartości dodanej jest precyzyjnie zdefiniowane i tym miejscem jest serwer aplikacyjny. Takie rozgraniczenie wprowadza klarowny podział pomiędzy elementarnymi funkcjami (np. zapewnienie przezroczystego kanału danych, zarządzanie mobilnością itd.) a cała gamą dodanych funkcjonalności. Podstawowymi elementami biorącymi udział w sterowaniu usługami IMS są: serwery aplikacyjne (AS), element zarządzający sterowaniem połączeniami i zgłoszeniami (S-CSCF) oraz repozytorium profili uŝytkownika (HSS). Rys. 14 przedstawia interfejsy i protokoły 31 Protokół słuŝący do opisu parametrów sesji. 32 MoŜliwości tworzenia kryteriów są elastyczne, przykładowo moŝna zdefiniować taką regułę: (Method= INVITE OR Method = MESSAGE OR Method= SUBSCRIBE ) AND (Method= INVITE OR Method = MESSAGE OR (NOT Header = from Content = ala@eims.local )). PowyŜsze wyraŝenie opisuje regułę definiującą, Ŝe kierowane do AS będą wiadomości: INVITE, MESSAGE oraz takie wiadomości SUBSCRIBE, które nie zostały wysłane przez uŝytkownika posługującego się publicznym identyfikatorem ala@eims.local. 33 XML-Schema jest językiem opisu składni dokumentów XML (patrz http://www.w3.org/xml/schema). 35