Architektura funkcjonalna i interfejsy MRF wg ETSI

Rys. 6 Architektura funkcjonalna MRF wg ETSI.

Powyższy rysunek przedstawia architekturę funkcjonalną bloku MRF wg ETSI ([39], [38];.

Wyróżnione na rysunku interfejsy zestawiono w poniższej tabeli:

Nazwa interfejsu	Protokół w ramach interfej su	Opis
Mr	SIP + dodatkowy protokół	Jest to interfejs pomiędzy MRF a serwerem S-CSCF. Służy do sterowania pracą MRFC za pomocą protokołu SIP, przez aplikację usługową zlokalizowaną na serwerze aplikacji (AS). S-CSCF pracuje tutaj jako element routujący wiadomości pomiędzy serwerem aplikacji a modułem MRF51. Funkcjonalność         multimedialna serwera mediów wykraczająca poza standardowe mechanizmy SIP jest kontrolowana poprzez dodatkowy protokół przenoszony w polu SDP.52
Mp	H.248 / Megaco	Interfejs do sterowania blokiem MRFP przez MRFC. Interfejs ten powinien wspierać w pełni standard H.248 ([39]), ponadto umożliwiać późniejsze wprowadzanie rozszerzeń,jeśli zostaną zdefiniowane. Styk Mp jest wykorzystywany tylko w przypadku, gdy implementacja MRF zakłada funkcjonalną separację bloków MRFP i MRFC. Wówczas możliwe jest aby jeden MRFC zarządzał pracą kilku bloków MRFP. W sytuacji, gdy MRF stanowi jeden moduł funkcjonalny, interfejs Mp nie jest implementowany i nie wyróżnia się bloków MRFP i MRFC. Szczegółowe wymagania funkcjonalne dla styku Mp (listę obowiązkowych i opcjonalnych funkcjonalności) zdefiniowano w [42], specyfikację protokołu na tym styku opisano w [43].

51  Patrz rozdział 6. 52  ETSI nie określiło jednoznacznie dodatkowego protokołu na styku Mr. W rozdziale 7 niniejszej pracy zawarto analizę protokołów możliwych do wprowadzenia na tym styku.

Mb	RTP	Zdefiniowany w [38]jako interfejs do usług sieciowych IPv6, w tym usług transportowych. W rzeczywistych implementacjach modułu MRF wykorzystywany jest transport w ramach sieci z adresacją IPv4. W ramach tego interfejsu w pakietach protokołu RTP transportowane są strumienie multimedialne.
Sr	HTTP	Interfejs zdefiniowany w [40]. Umożliwia pobieranie różnych dokumentów przez MRFC (np. pliki ze skryptami VXML) w ramach delegacyjnego modelu sterowania modułem MS.[1] W tym celu wykorzystuje się protokół HTTP.
Cr	HTTP TCP/SCP	Interfejs zdefiniowany w [40] na potrzeby protokolarnego modelu sterowania serwerem mediów z wykorzystaniemdedykowanego kanału sterowania. Przesyłane są tutaj wiadomości sterujące blokiem MRFC (Jako protokół transportowy ETSI zaleca TCP/SCTP). Interfejs umożliwia również pobieranie przez MRFC różnych dokumentów z sieci (np. pliki ze skryptami VXML)[2] – w tym celu wykorzystywany jest protokół HTTP.
Rf	DIAMETER	Interfejs do przesyłania informacji taryfikacyjnej w ramach off-line charging w architekturze IMS[3].
Ro	DIAMETER	Interfejs do przesyłania informacji taryfikacyjnej w ramach on-line charging w architekturze IMS[4].

Tabela 1 Interfejsy modułu MRF wg ETSI

Architektura funkcjonalna i interfejsy serwera mediów w architekturze V²OIP

Jeżeli blok MS nie jest rozpatrywany w kontekście sieci IMS, wówczas architekturę funkcjonalną oraz interfejsy można przedstawić następująco:

Rys. 7 Ogólna architektura funkcjonalna i interfejsy serwera mediów

Na rysunku wyróżniono następujące warstwy funkcjonalne:

• Warstwa sterowania

Do zadań tej warstwy należy:

o komunikacja z otoczeniem poprzez protokoły sieciowe

• SIP – komunikacja z serwerem aplikacji, który korzysta z zasobów MS na potrzeby aplikacji usługowych
• DIAMETER – przesyłanie danych taryfikacyjnych do systemów bilingowych na potrzeby mechanizmu chargingu
• HTTP – pobieranie dokumentów, plików audio/video na potrzeby konkretnych operacji niższych warstw MS
• TCP/SCTP – obsługa wymiany wiadomości protokołu sterowania serwerem mediów ^[5]

o Zarządzanie pracą dwóch niższych warstw na podstawie logiki usługi, która korzysta z zasobów MS

o Zarządzanie zasobami operacyjnymi MS – przydzielanie zasobów do poszczególnych operacji celem obsłużenia przychodzących żądań. Zasoby zależą od fizycznej implementacji MS. W razie braku zasobów na obsłużenie danego żądania, serwer mediów wysyła odpowiedź opisującą zaistniały problem.

• Warstwa przetwarzania sygnałów

W tej warstwie MS wykonuje wszelkie operacje na sygnałach cyfrowych (przetwarzanie sygnałów, syntetyzowanie, miksowanie etc)

• Warstwa transportowa

Jest to warstwa odpowiedzialna za wysyłanie/odbieranie strumieni multimedialnych z wykorzystaniem protokołu RTP.

Na rysunku pominięto interfejsy pomiędzy poszczególnymi warstwami. MS jest tutaj rozpatrywany jako jeden blok funkcjonalny . Wewnętrzne mechanizmy MS są nieistotne z punktu widzenia realizacji usług multimedialnych.

Istotne jest natomiast, aby interfejsy adresowały wszystkie funkcje MS. Protokoły wspierane w ramach przedstawionej na powyższym rysunku generycznej architektury serwera mediów dla sieci V OIP są identyczne z protokołami wymienionymi przez ETSI dla MRF. Zbieżność ta wynika z faktu, iż na rynku telekomunikacyjnym serwery oferujące funkcjonalność MS obecne były zanim wyklarowała się idea IMS. MRF stanowi zatem abstrakcję MS w ramach koncepcji IMS.

Porównanie architektury MS i MRF

Potwierdzeniem tezy, iż nie jest błędem zamienne stosowanie terminów MS i MRF na określenie tego samego bloku funkcjonalnego, jest porównanie przedstawionych wyżej architektur funkcjonalnych. Ilustruje to poniższy rysunek: ^[6]

Rys. 8 Zestawienie architektury MS i MRF

Jeżeli MS jest postrzegany jako blok MRF, wówczas można mówić o interfejsie pomiędzy warstwą sterującą a warstwami przetwarzania sygnałów i transportową, w postaci protokołu H.248 / MEGACO.

Serwer mediów typu I

W sytuacji gdy MS pełni następujący zbiór funkcji:

• Operacje na sygnałach cyfrowych audio/video
• Transkodowanie
• Odtwarzanie zapowiedzi, plików audio/video, pobieranie cyfr i symboli DTMF
• Rejestrowanie strumieni audio / video (nagrywanie głosu, obrazu, Lawful Interception)
• Miksowanie strumieni na potrzeby prostych konferencji (trójstronnych połączeń)

wówczas można mówić o tzw. serwerze mediów typu I (MS typu I). Jego architekturę przedstawia rysunek:

Rys. 9 Serwer mediów typu I

Jak widać, funkcjonalnie MS typu I odpowiada blokowi MRFP. Jego praca sterowana jest za pomocą protokołu H.248/Megaco, który adresuje wymienione funkcje. Warstwa sterowania, opisana w ramach architektury MS, jest w tej sytuacji zlokalizowana na serwerze aplikacji, wspierającym protokół H.248.

Serwer mediów typu II

Można mówić o serwerze mediów typu II w sytuacji, gdy MS wspiera wszystkie funkcje MS typu I oraz dodatkowo:

• W spomaga realizacj ę zaawansowanych usług konferencyj nych
• Zawiera funkcje IVR, ASR, TTS etc.
• Wspiera standard VXML oraz inne języki oparte na XML (CCXML, SCXML)
• Wspiera inne funkcjonalności MS wymienione w rozdziale
• Wspiera interfejs oparty na protokole SIP, poprzez który adresowane są wszystkie jego funkcjonalności

Architekturę MS typu II ilustruje rysunek:

Rys. 10 Serwer mediów typu II

MS typ II to serwer mediów o rozproszonej architekturze, w której warstwa sterowania funkcjonalnie odpowiada blokowi MRFC i jest oddzielona od pozostałych warstw poprzez interfejs oparty na protokole H.248. Pozostałe dwie warstwy tworzą blok odpowiadający blokowi MRFP.

Pracą całego MS steruje serwer aplikacji poprzez protokół SIP wzbogacony o dodatkowe funkcjonalności^[7].

Można zatem powiedzieć, że MS typu I to „podstawowy” typ serwera mediów, udostępniający proste operacje na strumieniach multimedialnych. MS typu II to „zaawansowany” MS udostępniający szeroki wachlarz funkcjonalności^[8].

Należy dodać, iż w sytuacji, w której nie rozpatruje się interfejsu opartego na H.248 i nie ma funkcjonalnej separacji pomiędzy warstwą sterowania a pozostałymi warstwami MS, również mówi się MS typu II.

Architektura MS/MRF a funkcje TTS, ASR, IVR.

W przypadku serwerów mediów dostępnych na rynku telekomunikacyjnym bardzo często zdarza się, że producenci nie implementują wszystkich funkcjonalności w ramach swojego produktu. Oferowana jest natomiast integracja MS z rozwiązaniami zewnętrznych firm, zapewniającymi określone funkcje. Dotyczy to najczęściej funkcjonalności ASR / TTS, nierzadko jednak bloki odpowiedzialne za interpretację skryptów VXML^[9], jak również repozytoria plików audio/video czy skryptów dla różnych języków opartych o XML, stanowią oddzielne moduły od innych dostawców. Pozostałe funkcje (takie jak przetwarzanie sygnałów odtwarzanie/nagrywanie multimediów) są zwykle wspierane przez producentów MS.

W związku z powyższym możliwe jest różne usytuowanie bloków odpowiadających za wymienione funkcje na tle opisanej powyżej architektury funkcjonalnej MS/MRF. Można wyróżnić dwa podejścia opisane w poniższych podrozdziałach.

Wsparcie wszystkich funkcjonalności w ramach bloków funkcjonalnych MS/MRF

To podejście ilustruje poniższy rysunek:

Rys. 11 Funkcjonalności MS/MRF wspierane przez wewnętrzne bloki funkcjonalne

Rysunek obrazuje serwer mediów, który nie wymaga dodatkowej integracji z zewnętrznymi blokami funkcjonalnymi. Taki MS jest „widziany” jako jednolite „czarne pudełko” o określonym zestawie funkcjonalności. Z punktu widzenia współpracy z innymi elementami sieci istotne jest jedynie, aby wspierane były określone interfejsy.

Rysunek ilustruje również logiczne usytuowanie wyróżnionych funkcji względem MRFP i MRFC. IVR, TTS i ASR są rozproszone pomiędzy MRFC i MRFP, ponieważ ich realizacja wymaga sterowania pracą MRFP (synteza sygnałów cyfrowych, transport strumieni) wg. skryptów interpretowanych przez MRFC. Repozytoria skryptów oraz interpretery języków skryptowych należy funkcjonalnie przypisać do MRFC. Z kolei repozytoria plików A/V mogą być logicznie zlokalizowane w ramach MRFC lub MRFP.

Takie podejście znajduje odzwierciedlenie w specyfikacji ETSI, w dokumencie [42]. Wymieniono w nim zestaw funkcjonalności wspieranych przez interfejs Mp. Zawarta tam lista obejmuje:

• Odgrywanie tonów rozmównych
• Odgrywanie komunikatów
• Nagrywanie strumieni audio
• Text to Speech
• Automatic Speech Recognition
• Pobieranie cyfr i symboli DMTF
• Odtwarzanie multimediów
• Nagrywanie multimediów
• Konferencja audio
• Konferencja multimedialna
• Transkodowanie strumieni
• Audio o Video

Wymienione funkcjonalności są podzielone pomiędzy MRFP i MRFC i w całości przez nie realizowane, przy czym dla każdej z nich wyróżniono zbiór obowiązkowych jak i opcjonalnych operacji.

Lokalizacja pewnych funkcjonalności w zewnętrznych blokach funkcjonalnych i ich integracja z MS/MRF.

Ten wariant został przedstawiony na poniższym rysunku:

Rys. 12 MS/MRF zintegrowany z zewnętrznymi blokami funkcjonalnymi

Na rysunku przedstawiono MS „w otoczeniu” zewnętrznych modułów o określonej funkcjonalności. Ich współpraca z serwerem mediów przebiega poprzez wyróżnione interfejsy, które podzielić można na dwie grupy:

• Interfejsy sterujące: A, B

Są to interfejsy pomiędzy modułami ASR/TTS a MRFC służące do sterowania pracą tych modułów. W rzeczywistych implementacjach wykorzystywanym tutaj protokołem jest zazwyczaj Media Resource Control Protocol (MRCP), zdefiniowany w [17]. Został on zaprojektowany specjalnie celem kontrolowania i wykorzystywania takich zasobów sieciowych jak syntezatory mowy, elementy rozpoznające mowę, faksy, detektory sygnałów etc.

• Interfej sy transportowe

o a, b – służą do pobierania plików audio/video na potrzeby odtwarzania treści multimedialnej dla abonentów. Wykorzystuje się tutaj protokół HTTP. Pliki mogą być pobierane przez MRFC (interfejs a) w sytuacji, gdy do ich dystrybucji z MRFC do MRFP nie jest konieczny osobny interfejs (bloki te zintegrowane są ze sobą). W przeciwnym razie MRFP pobiera pliki (interfejs b), po uprzednim wskazaniu właściwego pliku przez MRFC.

o c – służy do pobierania przez MRFC plików zawierających skrypty języków opartych na XML (VXML, SCXML, CCXML). Tutaj również wykorzystuje się protokół HTTP.

o 1, 2 – interfejsy do przesyłania strumieni multimedialnych do/z bloków ASR/TTS. Wykorzystuje się tutaj protokół RTP.

Należy podkreślić, iż w rzeczywistych implementacjach sieci telekomunikacyjnej serwer mediów oraz współpracujące z nim moduły (zilustrowane na powyższym rysunku) są najczęściej traktowane „całościowo” jako jeden blok funkcjonalny MS/MRF (mimo, iż moduły „składowe” pochodzą od różnych producentów i nie stanowią jednolitego elementu sieciowego). Upraszcza to sterowanie wszystkimi modułami, oczywiście przy spełnionym warunku, iż są one zintegrowane ze sobą oraz ich funkcjonalności zostają wyeksponowane poprzez standardowe interfejsy zdefiniowane dla serwera mediów.

Rzeczywiste implementacje zależą silnie od producentów i operatorów telekomunikacyjnych i mogą znacznie różnić się między sobą.

---

^[1]   Patrz rozdział 6.6.2.1

^[2]   Patrz rozdział 6.6.2.2.

^[3]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

^[4]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

^[5]   Patrz rozdział 6.6.2.1

^[6]    W rozdziałach 5.4.3.1 oraz 5.4.3.2 rozważono podział MS na bloki funkcjonalne odpowiadające architekturze MRF.

^[7]   Patrz rozdział 6.

^[8]   Możliwe jest oczywiście, aby MS typu II udostępniał jedynie zbiór funkcji MS typu I. Będą one dostępne poprzez protokół SIP.

^[9]   Można rozważać również interpretery innych języków skryptowych, przykładowo CCXML, SCXML etc. Patrz rozdział 6.6.4.