Sieć inteligentna

Sieci inteligentne – platforma, na której operatorzy wdrażają usługi bazujące na funkcjonalności zaimplementowanej w dostarczanych przez dostawców sprzętu elementach infrastruktury telekomunikacyjnej.

Przykładami takich usług (serwisów) są:

obsługa naliczania opłat za rozmowy abonentów rozliczających się w systemie przedpłaconym, tzw. prepaid.
Virtual Private Networks (VPN) – serwis oferujący dużym firmom i instytucjom oddzielne plany numeracyjne i taryfikacyjne, możliwość kształtowania struktury dozwolonych połączeń przychodzących i wychodzących pomiędzy różnymi grupami pracowników i zewnętrzną częścią sieci telekomunikacyjnej, itp.
obsługa numerów 800 związanych z darmową infolinią

Projektując architekturę sieci inteligentnych skupiono się na następujących wymaganiach:

platforma wraz z dostarczonymi do niej narzędziami developerskimi służącymi do tworzenia, testowania i integrowania nowych serwisów powinna umożliwiać ich tworzenie przez operatora lub inne firmy (niekoniecznie dostawcę platformy)
wdrażanie nowych serwisów powinno mieć jak najmniejszy wpływ na zmiany w istniejącej sieci telekomunikacyjnej, a ewentualne problemy z serwisami zaimplementowanymi na platformie nie powinny wpływać na funkcjonowanie sieci

Dzięki nowym serwisom operatorzy mogą zaoferować zbiór usług dodanych, który będzie wyróżniał ich ofertę na tle rynku.

Początki i rozwój standardu

Pierwsze udane wdrożenie sieci inteligentnych przeprowadziła w latach 80. firma Bellcore dla amerykańskich operatorów telefonii stacjonarnej. Zaproponowane rozwiązanie stało się standardem de facto, opiera się na nim rozwijany w Ameryce standard Advanced Intelligent Network (AIN).

Równolegle z rozwojem AIN, Sektor Normalizacji Telekomunikacji Międzynarodowego Związku Telekomunikacyjnego (ITU-T) rozwijał standard sieci inteligentnych, którego specyfikacje zawarto w Zaleceniach ITU-T serii Q.1200. Obejmuje on CS-1 (Capability Set – 1), a później kolejne warianty: CS-2, CS-3. Oprócz definicji architektury sieci inteligentnych, głównym celem specyfikacji był protokół sygnalizacyjny używany przez poszczególne jej elementy do komunikowania się z siecią telekomunikacyjną i ze sobą nawzajem – Intelligent Network Application Part (INAP) w ramach Systemu Sygnalizacji nr 7 (SS7). Obecnie rozwiązania AIN i proponowane przez ITU zbliżają się do siebie w sensie oferowanych możliwości i sposobów ich implementacji.

Europejski Instytut Norm Telekomunikacyjnych (ETSI) – rozpoczął rozwój własnej specyfikacji, bazującej na wytycznych ITU-T. Z powodu problemów z implementacją protokołu INAP ze specyfikacji ITU, ETSI opracował własny protokół będący podzbiorem tego pierwszego rozwiązania – ETSI Core INAP. Stał się on częścią specyfikacji ETSI CS-1, która była wykorzysta do tworzenia sieci inteligentnych przez operatorów sieci stacjonarnych. Specyfikacja ta jest najczęściej implementowaną wersją, wielu dostawców infrastruktury telekomunikacyjnej oferuje również jej rozszerzenie związane z obsługą telefonii mobilnej. Powstały nowsze wersje: CS-2 (obsługa sieci telefonii mobilnej) i CS-3 (obsługa sieci w środowisku IP), ale nie zyskały one popularności ze względu na wcześniejsze udane implementacje tego typu rozwiązań bazujące na rozszerzeniach CS-1, oraz na rozwój standardu CAMEL.

Implementacja protokołu INAP różniła się w zależności od oferującego ją dostawcy, dodatkowo uwzględniane były różnice związane ze specyficznymi wymaganiami konkretnych operatorów. Nie stanowiło to problemu, podczas wdrażania sieci inteligentnych w telefonii stacjonarnej, jednak w sieciach telefonii mobilnej zaowocowało to brakiem dostępu do wykupionych usług dla abonentów korzystających z roamingu. Aby temu zapobiec, ETSI rozpoczęło prace nad specyfikacją technologii CAMEL (opierając się na swoich wcześniejszych specyfikacjach CS-1, CS-2), która opisywała implementacje Sieci Inteligentnych na bazie elementów sieci GSM. Obecnie rozwijanie specyfikacji jest kontynuowane przez 3GPP, a bazująca na niej technologia umożliwia pełny roaming usług wykupionych przez abonenta u swojego macierzystego operatora.

Specyfikacja ETSI

Obecnie większość wdrożeń sieci inteligentnych bazuje na specyfikacji ETSI. Opisuje ona poszczególne funkcjonalności, zależności między nimi oraz protokół, dzięki któremu komunikują się między sobą. Struktura rozwiązań opartych na innych specyfikacjach nie różni się na ogólnym poziomie od przedstawionej poniżej.

Architektura

CCF (Call Control Function) jest funkcjonalnością istniejącą w sieci telekomunikacyjnej odpowiedzialną za zestawianie połączenia (i nadzorowanie już zestawionych połączeń) pomiędzy abonentami. Dodatkowo, ma ona możliwość zdecydowania czy dana rozmowa powinna być obsłużona przez platformę sieci inteligentnych.

SCF (Service Control Function) jest „logiką” odpowiedzialną za zachowanie sieci telekomunikacyjnej. Na podstawie otrzymanych z sieci informacji, podejmuje decyzje co do dalszych działań CCF związanych z zestawianą (zestawioną) rozmową (na przykład przekierowanie rozmowy pod inny numer, zakończenie rozmowy, dołączenie do telekonferencji kolejnego rozmówcy itp.).

SSF (Service Switching Function) jest funkcjonalnością odpowiedzialną za przekazanie kontroli nad rozmową do odpowiedniego SCF, interpretowaniu przychodzących z SCF instrukcji i przekazywaniu ich w odpowiedniej formie do sieci (CCF). Również sieć telekomunikacyjna, może się za pomocą SSF komunikować z SCF przesyłając informacje związane z zestawianą (zestawioną) rozmową, np. abonent nie podnosi słuchawki.

SDF (Service Data Function) jest funkcjonalnością odpowiedzialną za przechowywanie informacji, związanych z poszczególnymi abonentami obsługiwanymi przez sieci inteligentne. SCF podczas podejmowania decyzji związanych z zestawianą (zestawioną) rozmową może skorzystać z SDF, lub uaktualnić przechowywane tam dane. Na przykład podczas zestawiania rozmowy przez użytkownika rozliczającego się w systemie prepaid, SCF sprawdza w SDF ilość minut, które pozostały użytkownikowi na rozmowę.

SRF (Specialized Resource Function) jest funkcjonalnością związaną z zasobami sieci telekomunikacyjnej wspomagającymi obustronną komunikacje pomiędzy użytkownikiem a logiką serwisu (SCF). Wspomaga ona odgrywanie komunikatów które abonent może usłyszeć, lub kolekcjonowanie i wysyłanie do SCF cyfr, które abonent wysyła do sieci za pomocą wybierania tonowego.

Protokół INAP

Specyfikacja protokołu INAP (Intelligent Networks Applicaton Part) obejmuje wszystkie aspekty komunikacji pomiędzy elementami platformy sieci inteligentnych.

Operacje przesyłane pomiędzy SCF i SSF
- żądanie rozpoczęcia obsługi rozmowy przez SCF (SSF→SCF)
- żądanie połączenia z danym numerem, zakończenia rozmowy (SCF→SSF)
- żądanie dołączenia do rozmowy kolejnego abonenta, odłączenia jednego z abonentów, zawieszenia połączenia z nim (SCF→SSF)
- interakcja związaną z naliczaniem opłat (SCF<→SSF)
- żądanie dodatkowych informacji o obsługiwanej rozmowie (np. abonent do którego jest przekierowana nie podnosi słuchawki, rozłączył się itp.) (SCF→SSF), oraz dostarczaniem ich (SSF→SCF).
Operacje przesyłane pomiędzy SCF i SRF
- żądanie odegrania informacji (ang. announcement) (SCF→SRF)
- żądanie kolekcjonowania (dzięki wybieraniu tonowemu) cyfr przychodzących od abonenta (SCF→SRF) i przesyłaniem ich do serwisu (SRF→SCF)
Operacje przesyłane pomiędzy SCF i SDF
- aktualizowanie informacji w bazie danych (SCF→SDF)
- zapytanie o dane związane z jednym z abonentów (SCF<→SDF)

Implementacja platformy sieci inteligentnych

Główne elementy

Specyfikacja sieci inteligentnych znalazła odzwierciedlenie w rzeczywistych implementacjach platformy.

CCF zaimplementowana jest w centralach telefonicznych jako podstawowa funkcjonalność sieci telekomunikacyjnej związana z zestawianiem i nadzorowaniem rozmowy pomiędzy abonentami. Jest to funkcjonalność występująca także w systemach niewspółpracujących z sieciami inteligentnymi.

Element sieci inteligentnych implementujący logikę serwisu (SCF) nazywa się Service Control Point (SCP). Zazwyczaj jest on serwerem aplikacji, na którym uruchomiony jest serwis. Dodatkowo posiada on karty SS7, przez które komunikuje się z resztą sieci.

Implementacja funkcjonalności SSF jest oprogramowaniem w istniejącej centrali w sieci stacjonarnej lub komórkowej. Czasami w sieciach stacjonarnych jest ona osobnym elementem – centralą z odpowiednim oprogramowaniem, do której kierowane będą rozmowy wymagające obsługi przez sieci inteligentne, nazywana jest wtedy ona Service Switching Point (SSP).

Implementacja SDF nazywana jest Service Data Point (SDP). Zazwyczaj jest to serwer hostujący jeden z komercyjnych systemów bazodanowych. Dodatkowo posiada on karty SS7, przez które komunikuje się z resztą sieci.

Funkcjonalność SRF jest implementowana jako dodatkowy sprzęt i oprogramowanie w centrali telefonicznej, który odpowiedzialny jest za odgrywanie prostych informacji. Inną spotykaną formą implementacji są tzw. Intelligent Peripheral (IP), serwery z odpowiednimi serwisami, kartami SS7 i dodatkowym sprzętem umożliwiające interakcję z użytkownikiem i przesyłanie jej wyników do SCP (np. „wciśnij 1 jeśli chcesz porozmawiać z konsultantem infolinii”) lub odgrywanie złożonych informacji (np. „na twoim koncie zostało <dwadzieścia sześć> <złotych> i <pięćdziesiąt> <groszy>”, gdzie frazy podane w nawiasach „< >” są zmienne).

SCP nie komunikuje się z funkcjonalnością SRF bezpośrednio, ale za pomocą SSP.

Serwisy

Serwisy (SCF) są kluczowym elementem Sieci Inteligentnych. Zawierają one logikę, która kontroluje zestawiane już (zestawione) połączenie, lub interakcje z abonentem. Dodatkowo interpretują docierające z sieci operacje zawarte w protokołach INAP/CAP i same komunikują się z siecią za pomocą tworzonych operacji (które zawierają ustawiane przez serwis parametry).

Serwisy implementuje się w SCP na dwa sposoby:

Używa się „Service Independent Building Blocks” (SIB). Są to programowe komponenty o pewnych parametryzowanych właściwościach. Z każdym rodzajem komponentu związana jest pewna funkcjonalność, którą można ustawić podczas definicji komponentu. Dostawcy tego typu rozwiązań oferują środowiska w których wszystkie komponenty mają swoje graficzne odpowiedniki, designer tworzy serwis umieszczając ikony symbolizujące komponenty i łącząc je nawzajem myszką oraz ustawiając związane z nimi parametry. Program wykonuje się w kolejności zdeterminowanej przez połączenia komponentów, kolejno uruchamiając powiązane funkcjonalności. Oczywiście możliwe są też warunkowe rozgałęzienia wykonania programu, lub pętle. Przykładowymi funkcjonalnościami mogą być działania na stringach (na przykład na numerze telefonu), wysłanie INAPowej operacji do Sieci, lub przejście serwisu w stan oczekiwania na informacje z sieci, oraz późniejszy wybór jednego z kilku połączeń do innego komponentu w zależności od parametrów w oczekiwanej operacji (o ile przyjdzie), lub w przypadku gdy nie zostanie otrzymana (w zdefiniowanym czasie). Specyfikacje SIBów są podane przez ITU-T i ETSI, ale każdy z dostawców platformy oferuje własne rozwiązania tylko z grubsza opierające się na wykładniach instytutów standaryzacyjnych. Większość obecnie działających serwisów jest stworzona właśnie w ten sposób.
Odpowiednia platforma wraz z dostarczonymi bibliotekami może stanowić środowisko do tworzenia serwisów w językach wysokiego poziomu, najczęściej C++ lub Java.

Przykładowe scenariusze

Przedstawione scenariusze zawierają pewne uproszczenia, co wpływa na przejrzystość opisu.

Serwis prepaid

Użytkownik systemu przedpłaconego rozmawia, aż do momentu, w którym wyczerpane zostają opłacone z góry środki.

Abonent telefonu w systemie przepłaconym postanawia wykonać połączenie. W centrali (MSC) która go obsługuje sprawdzane są jego subskrypcje (które umieszczone są w bazie danych (VLR)). (Zobacz artykuł o architekturze sieci GSM).
Okazuje się, że abonent ma subskrypcję na serwis działający na platformie sieci inteligentnych. Zestawianie rozmowy przekazane jest wtedy do SSF.
SSF wstrzymuje zestawianie rozmowy i otwiera dialog do SCP. Na podstawie informacji przekazanych z VLR, oraz własnych ustawień buduje INAPową operacje (ustawiając odpowiednie parametry) InitialDP (IDP), którą wysyła do SCP. Operacja ta zawiera między innymi Service Key (wskazuje serwis, który powinien być uruchomiony dla tego abonenta), numer abonenta i numer pod który abonent chce się dodzwonić.
SCP po otrzymaniu IDP, na podstawie parametru Service Key wybiera odpowiedni serwis, który będzie obsługiwał rozmowę. W naszym wypadku, będzie to serwis prepaid.
Serwis wysyła zapytanie do SDP o ilość sekund, które może rozmawiać abonent (jego numer, który go identyfikuje, również przychodzi w operacji IDP).
SDP zwraca tę informację (załóżmy, że jest to 150 s).
Serwis wysyła do Sieci operację RequestReportBCSM (RRB), która jest żądaniem monitorowania zdarzeń związanych z połączeniem (ustawione w niej parametry będą wskazywały, że chodzi o zdarzenia typu: odrzucenie połączenia przez abonenta do którego ono jest zestawiane, zestawienie połączenia, lub jego zakończenie). Następnie wysyła operację Connect (CON), z numerem do którego połączenie powinno zostać zestawione.
Sieć za pomocą swojej podstawowej funkcjonalności realizuje to połączenie. Jeśli drugi abonent odbierze rozmowę, SSF wyśle do SCP odpowiednią operację EventReportBCSM (ERB) z ustawionym parametrem informującym o tym fakcie.
W tym momencie Serwis wysyła operacje ApplyCharging (ACH) wraz z parametrem 150, który informuje, po jakim czasie SSF ma oddać kontrolę nad rozmową do Serwisu.
Jeśli rozmowa zakończyłaby się przed czasem, SSF odesłałby operację ApplyChargingReport (ACR) z liczbą wykorzystanych sekund. Serwis za pomocą operacji Update zmieniłby ilość dostępnych sekund w SDP. W naszym przykładzie Abonent wykorzystuje całe 150 s, SSF zwraca kontrolę do SCP za pomocą ApplyChargingReport z odpowiednim parametrem informującym o wykorzystaniu wszystkich wolnych środków. Serwis wysyła do SSFu żądanie zakończenia rozmowy (operacja ReleaseCall (RC)), a do SDP operację Update w celu wyzerowania konta tego abonenta.

Technologia CAMEL

Sieci inteligentne zostały z powodzeniem zaimplementowane w technologii GSM. Każdy z dostawców infrastruktury telekomunikacyjnej na bazie specyfikacji ETSI opracował własne rozwiązania dostosowane do specyfiki tego rodzaju sieci. Rozwiązania te świetnie sprawdzają się do budowania serwisów, które kontrolują połączenia głosowe wykonywane przez abonenta w macierzystej sieci, ale nie umożliwiają roamingu usług dla abonenta korzystającego z obcej sieci, ani kontrolowania funkcjonalności specyficznych tylko dla GSM.

Aby rozwiązać opisane powyżej problemy, powstał standard „Customised Application for Mobile network Enhanced Logic” (CAMEL), który opisuje funkcjonalność sieci GSM wspomagającą budowę działających w tym środowisku sieci inteligentnych. Umożliwia on roaming usług wykupionych w macierzystej sieci dla abonenta przebywającego za granicą, oraz współpracę serwisów z usługami specyficznymi dla GSM, takimi jak SMS i GPRS.

Z technologią CAMEL związany jest też protokół CAP (CAMEL Application Part) używany do komunikacji pomiędzy SSF a SCF.

Przyszłość sieci inteligentnych

Sieci Inteligentne rozwijają się wraz z usługami oferowanymi przez telekomunikację. Nowe specyfikacje technologii CAMEL (rozwijanej obecnie przez 3GPP) uwzględniają możliwości sieci GSM, WCDMA i Internetu (współpraca CAMEL i IP Multimedia Subsystem). Standardy współpracy pomiędzy sieciami inteligentnymi a sieciami IP rozwija także ETSI.

Poza protokołami SS7 (INAP, CAP) używane są też coraz częściej protokoły bazujące na sieciach TCP/IP. Jednym z przykładów jest Diameter, protokół używany do naliczania opłat za połączenia GPRS w telefonach w systemie przepłaconym (innym stosowanym tu rozwiązaniem jest technologia CAMEL v.3).

Innym ciekawym, stosunkowo nowym rozwiązaniem jest technologia Parlay. Węzły SCP zastąpione są Serwerami Aplikacyjnymi w Internecie. Specyfikacje z nią związane rozwijane są przez konsorcjum Parlay, utworzone przez największych dostawców sprzętu telekomunikacyjnego i operatorów. Serwery Aplikacyjne mogą należeć do operatora, lub do innych firm, które wykupią możliwość korzystania z jego sieci i oferowania usług jego abonentom.

Zobacz też

CAMEL

Linki zewnętrzne