Author Archives: inzynier

Architektura funkcjonalna i interfejsy sieciowe modułu MS/MRF

Architektura funkcjonalna i interfejsy MRF wg ETSI

Rys. 6 Architektura funkcjonalna MRF wg ETSI.

1-1

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 V2OIP

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

2Na 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

3Jeż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

4

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

5MS 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

9

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

9-1

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.

Wnioski

System Joomla! okazał się przyjaznym w użytkowaniu systemem oraz w pełni potwierdził on swoją przynależność do zaawansowanych systemów CMS liczących się w Internecie. [niestety, coraz mniej]

Na podstawie opisanych wcześniej wybranych stron internetowych stwierdzam, że systemy CMS są rozpowszechnione i z powodzeniem wykorzystywane nawet przez amatorów.

Strona wykonana w systemie Joomla umożliwia równoczesne publikowanie treści prze wiele osób bez informatycznego doświadczenia.

Zaletą systemu Joomla jest fakt, że ciągle jest on rozwijany i ulepszany – nowe wersje pojawiają się średnio co dwa miesiące.

Systemy CMS należące do otwartego oprogramowania stosuje się w tworzeniu serwisów, gdzie niepożądana zmiana treści nie będzie miała istotnego wpływu na działanie danej instytucji, a więc przede wszystkim w portalach informacyjnych, komunikacyjnych i edukacyjnych.

W wielu wypadkach system CMS nie jest w stanie zastąpić profesjonalnych programów, również stworzenie nowych komponentów jest czasochłonne i kosztowne.

Często problemem oprogramowania open source jest brak pełnej dokumentacji. Użytkownik może skorzystać z wiedzy zawartej na stronach internetowych, forach dyskusyjnych lub zamówić płatne wsparcie techniczne. Należy zauważyć, że czas odpowiedzi na zadane na oficjalnym forum pytanie, to od kilkunastu minut do około godziny, co jednak nie gwarantuje rozwiązania problemu.

Wspieranie i upowszechnianie systemów open-source może dać realne korzyści finansowe.

Joomla! to ciekawe rozwiązanie dla osób prywatnych oraz instytucji pragnących mieć stronę internetową i warto przyjrzeć się temu systemowi bliżej.

Literatura

Boiko B., „Content Management Bible (2nd Edition)”, Wiley 2004 Danowski B., „Tworzenie stron WWW w praktyce.”, Helion, Gliwice 2007 Frankowski P., „CMS. Jak szybko i łatwo stworzyć stronę WWW i zarządzać nią.”, Helion, Gliwice 2007

Graf H., „Joomla! System zarządzania treścią.”, Helion, Gliwice 2007

Howil W., „CMS. Praktyczne projekty”, Helion, Gliwice 2007

Jarosz D., „Płatny hosting czyli gdzie się ulokować”, Magazyn Internet 2006

Kolbusz E., „Informatyka w zarządzaniu”, Zeszyt naukowy Instytutu Informatyki w Zarządzaniu, Uniwersytet Szczeciński, Szczecin 1999

Krug S., „Nie każ mi myśleć o życiowym podejściu do funkcjonalności stron internetowych”, Helion, Gliwice 2006

Linderman M., Fried J., “Przyjazne witryny WWW”, Helion, Gliwice 2005 Nielsen J., „Projektowanie funkcjonalnych serwisów internetowych”, Helion, Gliwice 2004

Rosenfeld L., Morville P., „Architektura informacji”, Helion, Gliwice 2003 Sosna Ł., „Drupal. CMS system zarządzania treścią”, Nakom, Poznań 2008 Ullman L., „Dynamiczne strony WWW. PHP i MySQL”, Helion, Gliwice 2004 Zeldman J., „Projektowanie serwisów WWW. Standardy sieciowe.”, Helion, Gliwice 2007

Niederst Robbins J., „HTML i XHTML. Leksykon kieszonkowy.”, Helion, Gliwice, 2006

Serwer mediów – definicja, funkcjonalność i architektura

Niniejszy rozdział zawiera definicję bloku funkcjonalnego serwera mediów (Media Server, MS). Przedstawiono zakres jego funkcjonalności, opisano architekturę funkcjonalną oraz interfejsy do innych elementów sieciowych. Zaproponowano wprowadzenie dwóch typów serwera w zależności od roli pełnionej w sieci i zbioru wspieranych funkcji.

Definicja pojęcia serwera mediów

Przyjmijmy, że:

Serwer mediów (Media Server, MS) to element funkcjonalny pracujący w sieci pakietowej typu VOIP [1], który dokonuje operacji na strumieniach audio i video oraz integruje funkcjonalności niezbędne do realizacji różnego typu usług multimedialnych. Źródłem strumieni mogą być inne elementy sieciowe jak również lokalne zasoby serwera mediów (np. pliki multimedialne, syntezatory mowy etc).

Odnosząc się do przedstawionej w rozdziale 4.1 definicji, serwer mediów wspiera realizację usługi multimedialnej poprzez udostępnienie swojej funkcjonalności. Inne elementy sieciowe mogą przesyłać do MS żądanie dokonania pewnej operacji na strumieniu multimedialnym.

MS to bierny moduł, który nie zawiera żadnej logiki usługowej, nie ma więc możliwości samodzielnego świadczenia usług. Jego zasoby są dostępne dla wielu aplikacji usługowych jednocześnie, wykorzystywane zgodnie ze zdefiniowaną w aplikacjach logiką. Innymi słowy, MS to pewnego rodzaju zaawansowany „procesor sygnałowy” w sieci VOIP.

Umiejscowienie w danej sieci VOIP modułu MS pozwala na zlokalizowanie wszelkich operacji na sygnałach w jednym elemencie, do którego mogą odwoływać się istniejące i nowo wprowadzane aplikacje usługowe. Eliminuje to konieczność dodawania osobnych, dedykowanych modułów.

[1]   Należy podkreślić, iż definicja nie określa styku pomiędzy MS a sieciami z komutacją kanałów. Ten styk jest realizowany poprzez bramy medialne (Media Gateways), które są modułami o innej funkcjonalności niż MS. MS pracuje tylko w sieci z komutacją pakietów.

Funkcjonalność MS

Funkcjonalność podstawowa

Podstawowa funkcjonalność serwera mediów obejmuje:

  • Przesyłanie strumieni danych cyfrowych audio/video do terminali użytkowników:

o Pochodzących z plików multimedialnych, silników syntezy mowy, audio lub video lub innych zasobów wewnętrznych serwera mediów

  • Rejestrowanie strumieni audio/video (do różnych formatów) i przechowywanie ich w ramach zasobów lokalnych
  • Operacje na strumieniach audio/video:

o Zmiana parametrów sygnałów cyfrowych (filtrowanie, zmiana głośności, zmiana rozdzielczości video etc.)

o Miksowanie strumieni audio/video (sumowanie sygnałów audio, łączenie strumieni video w jeden strumień)

o Transkodowanie pomiędzy strumieniami danych audio/video kodowanymi różnymi kodekami

■ W połączeniach dwustronnych, w konferencjach, przy nagrywaniu / odtwarzaniu (np. gdy dane w pliku są kodowane innym kodekiem niż wspierany przez terminal użytkownika) o Funkcjonalność Text-To-Video (TTV), Text-Insertion-In-Video – dodawanie tekstu do strumienia video, tak aby widoczny był na ekranie

  • Pobieranie cyfr i symboli od abonenta (DTMF collection)

o W paśmie – Inband

o Poza pasmem – Outband

  • Funkcjonalność IVR – wsparcie interakcji z abonentem poprzez interpretację skryptów języka VXML, odtwarzanie odpowiednich komunikatów audio/video, pobieranie cyfr i symboli DTMF (cyfry i symbole mogą zostać przekazane do innego elementu sieciowego).
  • Funkcjonalność TTS – synteza mowy z tekstu oraz przesyłanie zsyntetyzowanego strumienia audio
  • Funkcjonalność ASR – automatyczne rozpoznawanie mowy – wykorzystywane często w ramach IVR, rezultaty rozpoznania mowy mogą zostać przekazane do innego elementu sieciowego

Obsługa kodeków i transkodowania

Należy zapewnić, aby MS wspierał możliwie najszerszy zbiór kodeków audio/video stosowanych w sieciach V OIP (nie jest to niestety regułą w przypadku dostępnych implementacji serwerów mediów).

Ponadto należy podkreślić, iż wsparcie jak najszerszego zbioru kodeków oraz wsparcie transkodowania pomiędzy każdą ich parą to funkcjonalności, które są obowiązkowe dla każdego serwera mediów (nawet jeżeli nie jest on w sieci wykorzystywany do transkodowania strumieni w dwustronnych połączeniach).

Wymaganie to można uzasadnić następująco: rozważmy sytuację, w której dla terminala obsługującego jedynie kodek A zażądano od serwera mediów odegrania pewnej zapowiedzi. Zapowiedź jest zapisana w pliku, w którym dane audio zakodowano kodekiem B. Jeśli MS wspiera zarówno kodek A jak i B w ramach sesji RTP zestawianych z terminalami, ale nie wspiera transkodowania kodeka B (dane audio w pliku) na A, nie będzie mógł odegrać zapowiedzi dla terminala.

Inny przykład to usługa konferencji/miksowanie strumieni. Załóżmy, że serwer mediów wykorzystywany jest do miksowania strumieni audio dla trzech terminali, z których każdy wspiera tylko jeden kodek, różny od dwóch pozostałych. Jeżeli MS wspiera wszystkie trzy kodeki dla sesji RTP z terminalami, ale nie wspiera transkodowania pomiędzy każdą parą spośród nich, wówczas nie będzie możliwe poprawne miksowanie strumieni.

Funkcjonalność konferencyjna

Serwer mediów uczestniczy w realizacji usługi konferencji poprzez miksowanie strumieni i ich przetwarzanie. Zgodnie z rozważaniami w rozdziale 4.2, w generycznym funkcjonalnym modelu systemu konferencyjnego opartego na sygnalizacji SIP serwer mediów pełni funkcję miksera [14].

Z tego względu do funkcji serwera mediów zaliczyć można także:

  • Tworzenie „miksu” konferencyjnego – miksowanie strumieni audio i video od uczestników konferencji i przesyłanie do nich strumienia zmiksowanego audio i video
  • Rezerwację zasobów miksujących strumienie i aktywację miksowania (czyli utworzenie instancji konferencji) np. o wskazanej wcześniej porze, na wskazany okres czasu
  • Włączanie w zmiksowane strumienie a/v wysyłane do wskazanego użytkownika o dodatkowych zapowiedzi/danych audio/video o dialogu IVR[1]
  • Operowanie na sygnałach cyfrowych pochodzących od uczestników konferencji przed włączeniem ich w zmiksowany strumień

o Zwiększanie/zmniejszanie siły głosu poszczególnych uczestników konferencji

o Transkodowanie pomiędzy różnymi kodekami audio/video

  • Elastyczne modyfikowanie strumienia zmiksowanego:

o Przesyłanie w „miksie” sygnałów tylko od jednego uczestnika (tryb wykładu) do kilku wybranych uczestników, dla których poziom sygnału audio przekracza określony poziom (określany w ramach aplikacji usługowej)

o Dla danego uczestnika włączanie/eliminowanie do/ze konferencji pochodzącego od niego strumienia audio (np. dla trybu secret participating czy dla uczestnika bez prawa głosu). o Modyfikacja zmiksowanego strumienia video odpowiednio dla trybów VAS – Voice Activated Switching, Continous Presence, lecture mode o Tworzenie subkonferencji – czyli przesyłanie kilku sygnałów zmiksowanych do grup użytkowników wyróżnionych logicznie w ramach konferencji

o Łączenie dwóch lub więcej konferencji w jedną konferencję.

Wsparcie mechanizmu uprawnionego przechwytu (Lawful Interception)

Jednym ze sposobów implementacji mechanizmu przechwytywania treści w sieciach typu V OIP jest wykorzystanie serwera mediów. W tym przypadku dla wskazanych połączeń/sesji/użytkowników kopiowane są strumienie multimedialne wysyłane/odbierane przez MS. Skopiowane dane mogą być przechowywane w ramach MS lub zapisywane w osobnej lokalizacji w sieci. Do kopiowania strumieni MS może wykorzystywać funkcjonalność agenta SIP typu Back To Back User Agent (B2BUA) – kopiowane strumienie przesyłane są do innej lokalizacji w ramach ustanowionej sesji SIP, powiązanej z „kopiowaną” sesją.

Uprawniony przechwyt (Lawful Interception) wymaga zdefiniowania dodatkowych mechanizmów służących do wskazywania źródła przechwytywanej treści oraz do zarządzania nią. Funkcjonalność ta nie wchodzi jednak w zakres funkcji serwera mediów i nie jest rozpatrywana w niniejszej pracy.

Oczywiście aby przechwytywanie treści z wykorzystaniem MS było optymalnym rozwiązaniem dla danej sieci, należy zapewnić, aby wszystkie strumienie multimedialne w tej sieci „przechodziły” przez ten moduł. Nie jest to jednak optymalne podejście z punktu widzenia zarządzania ruchem w sieci.

Mechanizmy naliczania opłat – charging/billing

Strumienie multimedialne RTP przesyłane do/z modułu MS opisać można pewnym zbiorem informacji, do których zaliczyć można:

  • objętość (w bajtach) danych multimedialnych wysyłanych/odbieranych przez MS w ramach danego strumienia
  • data i godzina rozpoczęcia i zakończenia odbierania/wysyłania strumieni przez MS, czas trwania tej sesji RTP (np. w sekundach)
  • ilość otwartych strumieni RTP
  • pasmo zarezerwowane w ramach danego strumienia RTP
  • typ kodeka zastosowany w przesyłanych danych

Informacje te mogą zostać udostępnione przez MS i wykorzystane przez systemy billingowe do naliczania opłat za korzystanie z sieci (charging). Możliwe jest wsparcie dwóch typów mechanizmów:

  • on-line charging – obciążanie użytkownika „na bieżąco” – w trakcie trwania połączenia/sesji
  • off-line charging – tworzenie informacji taryfikacyjnej po zakończeniu połączenia sesji i na jej podstawie obciążanie użytkownika.

Mechanizmy te wymagają wzbogacenia funkcjonalności MS o generowanie rekordów CDR[2] oraz obsługę interfejsu do systemów bilingowych danej sieci, celem przesyłania wygenerowanych danych. W rzeczywistych implementacjach MS wykorzystuje się w tym celu protokół DIAMETER[3].

Bardziej wnikliwa analiza funkcjonalności taryfikacyjnej MS nie jest celem niniejszej pracy magisterskiej.

[1]    Dialog IVR to określenie przebiegu interakcji z abonentem, np. przejścia przez menu głosowe i dokonanie wyboru poprzez DTMF etc. Dialogi mogą być definiowane np. poprzez skrypty VXML.

[2]   CallDetailRecord- rekord danych z informacjami na temat danego połączenia takimi jak: czas trwania połączenia, adresy źródłowe i docelowe, pora dnia, kiedy nawiązano połączenie, dodatkowe parametry połączenia etc. Może reprezentować różne typy połączenia: np. połączenie PSTN/3G, sesję VoIP, sesję GPRS etc. Rekordy CDR są wykorzystywane przez systemy bilingowe w procesie taryfikacji rozmów.

[3]    DIAMETER to zdefiniowany w [10] protokół sieciowy realizujący funkcje AAA (Authentication, Authorization andAccounting- Uwierzytelnianie, Autoryzacja i Obsługa Konta Użytkownika).

Protokół SIP i jego zastosowanie dla usług multimedialnych

Protokół SIP (Session Initiation Protocol) został zdefiniowany przez organizację IETF w dokumencie [2] w roku 1996. Dokument ten zaktualizowano w roku 2002 przez publikację [1], gdzie zawarto obecnie obowiązującą specyfikację SIP.

Protokół zyskał akceptację wielu ciał standaryzacyjnych, m.in. ETSI oraz 3GPP. Jego specyfikację włączono w zbiór standardów opisujących takie architektury sieciowe jak IMS, UMTS[1], NGN[2] [3] [4].

  • Mechanizm protokołu i architektura sieci SIP

SIP jest protokołem warstwy aplikacji przeznaczonym do sterowania zestawianiem sesji multimedialnych pomiędzy różnymi elementami sieci. Samodzielnie nie stanowi jednak mechanizmu realizacji połączeń – w tym celu musi być wykorzystywany wraz z innymi protokołami sieciowymi (SDP , RTP etc).

Jest to protokół tekstowy, który do transportu wiadomości wykorzystuje protokoły TCP lub UDP. Opiera się na transakcyjnym modelu wymiany wiadomości (podobnie jako protokół HTTP, z którym wykazuje wiele innych podobieństw). Transakcje są przeprowadzane wg zasady „żądanie-odpowiedź”, co implikuje podział wiadomości protokołu na żądania (Requests) oraz odpowiedzi (Responses).

W ramach podstawowego zbioru wiadomości SIP można wymienić:

  • Żądania:

o INVITE – wiadomość oznaczająca żądanie zestawienia sesji. Innymi słowy – jest to zaproszenie adresata do zestawienia połączenia. o BYE – wiadomość kończąca ustanowioną sesję.

o CANCEL – umożliwia anulowanie rozpoczętego procesu zestawiania sesji

o REGISTER – pozwala na zarejestrowanie adresu SIP, który reprezentuje terminal użytkownika lub inny element sieci. Rejestracja powoduje, że dany adres staje się „osiągalny” w danej sieci, a wiadomości na ten adres wysyłane trafią do skojarzonej z nim lokalizacji. o ACK – wiadomość wykorzystywana do potwierdzenia otrzymanej przez stronę wywołującą zgody na połączenie przesłanej przez stronę wywoływaną

o OPTIONS – żądanie przesłania przed odbiorcę jego funkcjonalności i cech (capabilities)

  • Odpowiedzi – analogicznie jak dla HTTP, podzielone na klasy związane z typem przenoszonej informacji:

o 1xx – odpowiedzi informacyjne (np. 180 RINGING). Oznajmiają, iż realizacja żądania (Request) jest w toku o 2xx – potwierdzają pozytywne zakończenie transakcji (np. 200 OK. – oznacza akceptację sesji przez wywoływaną stronę) o 3xx – odpowiedzi opisujące przekierowania, czy też wskazujące zmianę lokalizacji adresu wywoływanego (np. 301 MOVED PERMANENTLY – strona docelowa na stałe zmieniła swoją lokalizację) o 4xx – opisują zaistniały po stronie wywoływanej błąd (np. 486 BUSY HERE – strona wywoływana jest zajęta i nie może zaakceptować wywołania)

o 5xx – błąd serwera – np. (503 SERVICE UNAVAILABLE – serwer niedostępny)

Dla protokołu SIP zdefiniowano architekturę funkcjonalną, która obejmuje następujące elementy :

  • Agent Użytkownika (User Agent, UA) – blok funkcjonalny umożliwiający inicjowanie i odbieranie sesji. Jest częścią terminala abonenta sieci (SIP UE – User Equipment). Może również stanowić część innych elementów sieci (np. serwera aplikacji, serwera mediów, Media Gatewaya, etc).
  • Serwer Proxy – serwer pośredniczący w połączeniach. Odbiera wiadomości od SIP UA i kieruje je pod właściwy adres w sieci (np. do kolejnego serwera Proxy).
  • Serwer Registrar – rejestruje adresy SIP (identyfikatory zapisywane w formie URI, np. „user@domena.com”) agenta użytkownika i przypisuje je do
    określonej lokalizacji sieciowej agenta. Udostępnia informacje o lokalizacji danego agenta na potrzeby procesu realizacji połączenia.
  • Serwer Redirect – serwer, który generuje dla klienta odpowiedzi typu 3xx, wskazujące adres, z którym klient powinien się skontaktować.

Można powiedzieć, że zarówno serwer Proxy jak i Registrar stanowią realizację usługi lokalizacyjnej dla protokołu SIP, czyli umożliwiają uzyskanie informacji o lokalizacji danego agenta SIP.

  • Back-To-Back User Agent – agent użytkownika SIP, który logicznie składa się z dwóch agentów SIP UA. Każdy z nich może inicjować lub terminować jedną sesję SIP[8]. Pomiędzy sesjami może istnieć pewna relacja logiczna i może polegać np. na nawiązywaniu drugiej sesji na podstawie parametrów pierwszej z nich Przykładowe zastosowanie B2BUA to np. transfer połączeń (call transfer) oraz 3rd Party Call Control (zestawianie połączenia pomiędzy dwiema stronami i inicjowanego przez trzecią stronę, która tym połączeniem następnie steruje).

Architekturę SIP można zilustrować w następujący sposób:

Rys. 2 Podstawowa architektura funkcjonalna SIP wg [1]

rysunek

Na rysunku przedstawiono agentów SIP UA zarejestrowanych w dwóch domenach SIP. Domeny są ustanawiane przez adresy serwerów Proxy i Registrar. Bardzo często w rzeczywistych implementacjach oba te serwery stanowią jeden blok funkcjonalny.

[1]   UniversalMobile Telecommunications System – system komórkowy trzeciej generacji (3G).

[2]     Next Generation Network – sieć następnej generacji. Sieć pakietowa, w której z usług telekomunikacyjnych abonenci korzystają niezależnie od rodzaju technologii dostępowej ich terminali.

[3]   Przez sesje multimedialne można rozumieć połączenie, w ramach którego strony połączenia przesyłają strumienie multimedialne, dane tekstowe etc.

[4]    Session Description Protocol ([3])- protokół wykorzystywany do opisu sesji multimedialnych w sieciach opartych o protokół IP.

[8]    Przez sesję SIP rozumiemy tutaj zbiór transakcji SIP skojarzonych z danym połączeniem (sesją multimedialną).

Congestion Avoidance Using Proportional Control (CAPC)

[1, 3, 4, 11]

Algorytm został zaproponowany przez Andy Barnhart’a z Hughes Systems. W algorytmie, podobnie jak w ERICA, przełącznik stara się utrzymać współczynnik wykorzystania pasma z blisko jedności. Przełącznik mierzy prędkość wejściową danych, oblicza z i na podstawie tych danych aktualizuje fairshare-maksymalną prędkością z jaką może pracować dany kanał wirtualny.

04

Algorytm rozróżnia dwie sytuacje:

  1. Jeżeli stopień wykorzystania pasma jest mniejszy od zakładanego: z<1, współczynnik fairshare jest zwiększany:

Faishare=Faishare*Min(ERU, 1+(1-z)*Rup),

gdzie Rup jest parametrem pomiędzy (0.0.25 a 0.1), ERU określa maksymalne jednorazowe zwiększenie pasma i standardowo wynosi 1,5.

  1. Jeżeli stopień wykorzystania pasma jest większy od zakładanego: z>1, współczynnik fairshare jest zmniejszany:

Faishare=Faishare*Max(ERF, 1-(1-z)*Rdn),

gdzie Rdn jest parametrem pomiędzy (0.2 a 0.8), ERF określa minimalne jednorazowe zmniejszenie pasma i standardowo wynosi 1,5.

Źródło nie może nigdy transmitować z większą prędkością niż obliczony współczynnik fairshare.

Dodatkowo, oprócz obliczanego współczynnika z, algorytm pozwala na ustawienia progu kolejki w przełączniku. Jeżeli długość kolejki przekroczy ustalony próg, przełącznik ustawia bit wystąpienia przeciążenia CI (Congestion Indication) we wszystkich komórkach zarządzających RM. Zapobiega to przed zwiększaniem prędkości transmisji przez urządzenia nadawcze  i pozwala na zmniejszenie długości kolejek w buforze.

Porównanie metod kontroli przeciążenia

[1, 3, 10]

W rozdziale tym porównam trzy algorytmy kontroli przeciążenia. W celu porównania algorytmów skorzystam z symulacji przeprowadzonych przez niezależne organizacje. Symulacje zostały przeprowadzone za pomocą własnych pakietów symulacyjnych. Chcąc powtórzyć podobne symulacje lub chcąc rozszerzyć zakres symulacji należałoby albo napisać do tego celu program albo zakupić odpowiedni pakiet symulacyjny. Jednym z takich komercyjnych programów umożliwiających przeprowadzenie symulacji metod kontroli przeciążenia jest pakiet OPNET firmy MIL3. Inne znane dostępne pakiet nie pozwalają na zbyt dużą ingerencję w mechanizmy kontroli przeciążenia.

Do symulacji trzech algorytmów zostanie użyta konfiguracja sieci składająca się z pięciu przełączników i z siedmiu par: nadawca-odbiorca. Odległość pomiędzy dwoma sąsiednimi przełącznikami wynosi 1000km a między przełącznikiem a węzłem sieci 100m. Wszystkie łącza mają przepustowość równą 45Mb/s.

Uwzględniając odległość połączenia w symulacji możemy wyróżnić trzy rodzaj połączeń:

Długodystansowe: połączenie od nadawcy 0 przechodzi przez cztery przełączniki. Połączenie to oznaczymy jaki VC0.

Średniodystansowe: połączenia od nadawcy 1 i 4 składają się z dwóch przełączników. Połączenia oznaczamy odpowiedni VC1 i VC4.

Krótkodystansowe: połączenia od nadawcy 2, 3, 5 i 6 przechodzą tylko przez jeden przełącznik. Połączenia oznaczamy odpowiedni VC2, VC3, VC5  i VC6.

Konfigurację testową przedstawia Rysunek 12.

Symulacja dotyczyć się będzie jednego z ważniejszych aspektów  działania algorytmu, tzn. „sprawiedliwego” rozdziału dostępnego pasma pomiędzy poszczególne kanały wirtualne. Używając metody sugerowanej przez ATM Forum możemy obliczyć optymalne teoretyczne pasmo dla każdego połączenia (współczynnik fairshare). Obliczenia te zostały przedstawione w Tabela 3

VC0 VC1 VC2 VC3 VC4 VC5 VC6
3.75 3.75 7.5 3.75 3.75 7.5 11.25

Tabela 3 Oczekiwane pasma przepustowe dla każdego połączenia w Mb/s

Symulacje zostały przeprowadzone dla dwóch parametrów ICR (initial cell rate), czyli początkowej prędkości nadawania, równych PCR i PCR/20.

 Rysunek 12. Testowa konfiguracja sieci05

Explicit Rate Indication for Congestion Aviodance (ERICA)

[1, 3, 4]

Algorytm ERICA stara się maksymalnie wykorzystać dostępne pasmo łącza, zachowując jednocześnie sprawiedliwy przedział pasma. Algorytm pozwala źródłom, transmitującym z prędkością równą lub większą z obliczonym współczynnikiem fairshare, na zwiększenie prędkości transmisji w kanale wirtualnym, jeżeli dany kanał wymaga większej przepustowości a łącze nie jest w pełni wykorzystane.

Dla algorytmu tego, definiujemy prędkość wyjściową większą niż dla poprzednio omówionego algorytm, 90-95% przepustowości łącza. Przełącznik oblicza współczynnik fairshare:

01

Prędkość, którą dodatkowa źródło może użyć:

0203

Przełącznik ustawia prędkość źródła na prędkość największą (Fairshare lub Vcshare)

Informacje wykorzystywane przy obliczeniach w algorytmie, dostarczane są komórkami RM z urządzenia nadawczego i odbiorczego.

Zaletą tego algorytmu jest prostota i łatwość przeprowadzanych obliczeń.

Niezawodność strukturalna szlifierki

Niezawodność strukturalna szlifierki jest określona wzorem:

08

R0(t) – niezawodność strukturalna (prawdopodobieństwo poprawnej pracy)

wiertarki

Ri(t) – niezawodność i-tego elementu

3a. Zebranie danych niezawodnościowych o elementach wiertarki.

Uzyskane z literatury dane o rozkładach [11, 17] i parametrach funkcji rozkładu [3, 4, 5] dla elementów wiertarki zestawiono w tabeli 2.

3b. Zebranie danych o uszkodzeniach powstałych w trakcie eksploatacji

Dane o uszkodzeniach lin stalowych obciążonych podobnie jak lina wiertarki zestawiono w tabeli 3.

 Zestawienie danych o uszkodzeniach lin stalowych (tabela 3)

Czas poprawnej pracy liny

ti

 Liczba uszkodzeń w zadanym przedziale czasu

ni

 Liczba uszkodzeń do czasu ti

Ni

 Ni/åni
400

800

1200

1600

1880

2280

2800

3600

4000

4100

6200

6400

 4

2

3

2

2

1

1

1

1

1

1

1

 4

6

9

11

13

14

15

16

17

18

19

20

 0,20

0,30

0,45

0,54

0,64

0,70

0,76

0,83

0,85

0,90

0,95

1,00
å ni 20
  1. Wyznaczenie modelu matematycznego rzeczywistego rozkładu uszkodzeń.

Do wyznaczenia modelu rozkładu zastosowano metodę graficzną. Sporządzoną siatkę funkcyjna rozkładu wykładniczego [5].

Dla liniowej interpolacji danych eksploatacyjnych punkty o współrzędnych (tab. 3) naniesiono na siatkę i poprowadzono linię prostą tak, aby odchylenia punktów od prostej były najmniejsze (rys. 11).

Mała odległość punktów od prostej stanowi podstawę do wstępnego stwierdzenia zgodności rzeczywistego rozkładu uszkodzeń z rozkładem wykładniczym.

  1. Wyznaczenie parametrów otrzymanego rozkładu

Intensywność uszkodzeń l dla rozkładu wykładniczego obliczono na podstawie wykresu

w funkcji t (rys. 11) przy wykorzystaniu tabel siatki prawdopodobieństwa rozkładu [5].

gdzie:

a – kąt zawarty między prostą interpolacyjną a osią odciętych (rys. 11)

L – długość odcinka odpowiadającego obszarowi zmienności zmiennej niezależnej

t [mm],

Dt – obszar zmienności zmiennej t, [h]

Kt – współczynnik skali na osi odciętych [mm/h].

Zestawienie danych i wyników obliczeń do wyznaczenia parametru l(t) (tabela 4)

Wielkości odczytane z rysunku Wyniki obliczeń
a[°] L[mm] tmax[h] tmin[h] Dt[h] tga Kt[mm/h] l[10-6h-1]
41°36’ 160 6400 0 6400 0,8875 0,025 500
  1. Weryfikacja przyjętego modelu matematycznego rzeczywistego rozkładu uszkodzeń elementów.

Zgodność rozkładu doświadczalnego z wykładniczym stwierdzono przy pomocy testu Kołmogorowa; polegającego na sprawdzeniu warunku zgodności:

gdzie:

D – maksymalna odległość punktów doświadczalnych od prostej interpolacyjnej, liczona według osi rzędnych siatki funkcyjnej,

n – liczba doświadczalnie otrzymanych punktów.

Jeżeli to istnieje zgodność rozkładu doświadczalnego z założonym rozkładem teoretycznym.

Z rysunku 11 odczytano D = 0,003, przy n = 20. a więc rozkład doświadczalny odpowiada rozkładowi wykładniczemu.

  1. Obliczenie wartości funkcji niezawodności poszczególnych elementów urządzenia:

Wartości funkcji niezawodności Ri(t) w przedziale czasowym 500-5000 [h] wyzna­czono z tabel 2.1; 3.1; 4.2 [23], opierając się na parametrach rozkładu uszkodzeń elemen­tów i zestawiono w tabeli 5.

Parametr a dla bębna, obliczono z zależności analitycznej [23]

Przebiegi funkcji niezawodności Ri(t) przedstawiono na rysunku 12.

  1. Obliczenie niezawodności strukturalnej wiertarki:

Niezawodność strukturalną wiertarki R0(t) określoną wzorem w punkcie 2, obliczono na podstawie wyników zestawionych w tabeli 5.

Wartości niezawodności strukturalnej w przedziale czasowym 500-5000 [h] zestawio­no w tabeli 6.

Niezawodność strukturalna wiertarki w przedziale czasowym 500 – 5000 h

 Czas pracy t [h] 500 1000 1500 3000 5000
Niezawodność strukturalna R0(t) 0,5686 0,2680 0,1203 0,0082 0

Obliczenia niezawodnościowe prowadzone w toku projektowania dają możliwość ko­rygowania projektu na poszczególnych jego etapach w aspekcie wymaganej niezawodności a więc zmniejszają ryzyko zaprojektowania urządzenia którego niezawodność jest nie­wystarczająca. Na schemacie rysunku 14 przedstawiono kolejność czynności projektowych i towarzyszące im obliczenia niezawodności. W procesie projektowania wyodrębniono trzy stopnie: pierwszy, obejmujący etapy I, II, III oraz drugi i trzeci odpowiadające eta­pom IV i V.

Każdy stopień zamyka porównanie niezawodności obliczonej R0(t) niezawodnością wymaganą Rw(t). W przypadku, gdy oszacowana niezawodność urządzenia jest nie mniej­sza od wymaganej, należy podjąć działania objęte następnym stopniem projektowania. Jeżeli natomiast niezawodność obliczona jest niewystarczająca, należy: w ramach nie­zmienionej konstrukcji zastosować elementy o wyższych wskaźnikach lub, o ile znajdzie potrzeba, wyeliminować słabe ogniwa. O wyborze kolejności wykorzystania środków zmierzających do podwyższenia niezawodności decyduje wartość wskaźnika kolejności przejścia k, przypisana liniom obrazującym następstwa czasowe działań projektowych.