Wymagania na system NSS1 (centrala D900 wraz z rejestrami) -
System NSS1 w części komutacyjno-sieciowej powinien obejmować funkcjonalności:
-
centrali (MSC1),
-
bazy danych przechowujących informacje o zarejestrowanych użytkownikach systemu GSM-R,
-
bazy danych przechowujące informacje niezbędne do zarządzania „ruchomością” abonentów (mobility management),
-
rejestr danych niezbędny do sprawdzania identyfikacji i kontroli uprawnień użytkowników.
-
Część komutacyjno-sieciowa systemu NSS1 powinna być wyposażona w funkcje niezbędne do współpracy z innymi sieciami telekomunikacyjnymi w tym SSF.
Zmodernizowana centrala MSC1 (D900) -
Funkcje zmodernizowanej centrali MSC1 D900 systemu NSS1 powinny obejmować:
-
realizację połączeń (komutacja) oraz kierowanie połączeń (routing),
-
sterowanie połączeniami i nadzorowanie w czasie ich trwania, również z wykorzystaniem zewnętrznych mechanizmów (IN) realizowanych poprzez SSF,
-
tworzenie rekordów bilingowych, współpraca z zewnętrznym systemem billingowym,
-
zapewnianie usług telekomunikacyjnych dla abonentów ruchomych,
-
zarządzanie położeniem (aktualizacja pozycji stacji ruchomej w sieci w bazach rejestrów VLR i HLR),
-
kontrolę identyfikacji abonenta (sprawdzenie tożsamości),
-
weryfikację terminala (sprawdzenie numeru seryjnego),
-
centrala MCS1 powinna być zwymiarowana zgodnie z wymogami zawartymi w pkt. 10.2.
-
Centrala MSC1 powinna, od strony funkcjonalnej posiadać następujące moduły:
-
moduł sterowania ruchem,
-
moduł łączy i sygnalizacji,
-
pole komutacyjne,
-
moduł billingowy
-
moduł eksploatacji i utrzymania.
-
Moduł sterowania ruchem powinien obejmować funkcje zestawiania, nadzorowania i likwidacji połączeń oraz analizę przychodzących cyfr, kierowanie połączeń wychodzących oraz nadzór.
4. Funkcja SSF powinna być wyposażona w protokoły: CAMEL Phase 1, Phase 2, Phase 3 zgodne z:
- 3GPP TS 03.78 „Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 2“;
- 3GPP TS 09.78: "Digital cellular telecommunications system (Phase 2+); CAMEL Application Part (CAP) specification - Phase 2".
- 3GPP TS 23.078: „Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 - Stage 2“
- 3GPP TS 29.078: "3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification"
4.1 Dodanie nowszych wersji protokołu CAMEL nie może nieść za sobą dodatkowych opłat licencyjnych.
4.2 Węzeł SSF powinien być wyposażony w protokoły INAP zgodne ze standardami:
- ITU-T REC. Q.1211 Introduction to IN Capability Set 1,
- ITU-T REC. Q.1213 Global Functional Plane for IN Capability Set 1,
- ITU-T REC. Q.1214 Distributed Functional Plane for IN Capability Set 1,
- ITU-T REC. Q.1215 Physical Plane for IN Capability Set 1,
- ITU-T REC. Q.1218 Interface Recommendation for IN Capability Set 1,
- ETSI ETS 300 374-1 Intelligent Network (IN); IN Capability Set 1 (CS1); Core Intelligent Network Application Protocol (INAP) Part 1: Protocol specification,
- ETSI ETS 300 374-5 Intelligent Network (IN); IN Capability Set 1 (CS1); Core Intelligent.
4.3 Dodanie nowszych wersji protokołu INAP nie może nieść za sobą dodatkowych opłat licencyjnych Dostawca zapewni Zamawiającemu prawo do bezpłatnego użytkowana protokołów sieciowych INAP/CAMEL bez konieczności uzyskiwania specjalnej zgody dostawcy do celów projektowych do użycia w ramach projektów obecnych i przyszłych prowadzonych przez Zamawiającego. Dostawca udostępni Zamawiającemu specyfikację protokołów INAP/CAMEL w formacie ASN1.
-
Moduł łączy i sygnalizacji powinien obejmować funkcje nadzoru połączeń z innymi centralami MSC oraz funkcje nadzoru nad sygnalizacją w systemie SS N7 oraz właściwego kierowania wiadomości sygnalizacyjnych SS N7 (funkcja STP – Signalling Transfer Point).
-
Obowiązujący system sygnalizacji dla łączy międzycentralowych – SS N7 ISUP w wersji krajowej V2, pożądana możliwość realizacji również starszej wersji V1.
-
Obowiązujący interfejs do central PABX Zamawiającego oraz systemu FDS – ISDN PRA DSS1.
-
Pole komutacyjne powinno realizować funkcje wyboru, zestawiania i likwidacji dróg połączeniowych dla sygnałów mowy lub danych.
-
Moduł billingowy powinien realizować funkcje zapisu i przechowywania informacji o każdej rozmowie abonentów (numer abonenta A, numer abonenta B, czas trwania rozmowy itd.) lub wymiany danych miedzy nimi a także udostępnienie powyższych informacji dla zewnętrznych systemów przetwarzania danych.
-
Moduł eksploatacji i utrzymania powinien obejmować funkcje zbierania, przechowywania, przetwarzania i prezentacji wszelkiego rodzaju danych statystycznych obrazujących pracę centrali. Moduł powinien też realizować funkcje bieżącej kontroli i prawidłowej pracy łączy, przeprowadzania połączeń testowych oraz pomiarów natężenia ruchu telekomunikacyjnego.
-
Centrala MSC1 powinna, dla wszystkich stanów terminali ruchomych (terminal wyłączony, stan czuwania, stan aktywny) realizować następujące procedury:
-
uaktualniania informacji o położeniu stacji ruchomej,
-
okresowego potwierdzania stanu czuwania,
-
zestawiania połączenia przychodzącego do stacji ruchomej,
-
zestawiania połączenia wychodzącego od stacji ruchomej,
-
zapewnienia ciągłości połączenia pomimo ruchu abonenta poprzez:
-
przełączanie kanałów w ramach tego samego sterownika stacji bazowych BSC,
-
przełączanie kanałów pomiędzy dwoma różnymi sterownikami BSC w ramach jednego obszaru centralowego,
-
przełączanie pomiędzy dwoma różnymi obszarami centralowymi,
-
przełączanie pomiędzy dwoma systemami GSM.
-
Wykonawca zintegruje centralę MSC1 z będącym w posiadaniu Zamawiającego SMSC opisany w ust 21 p.12.
-
Ilość interfejsów do innych elementów sieciowych, w szczególności łączy sygnalizacyjnych, musi być nie mniejsza niż:
- do BSC 3 szt.
- do PSTN (ISUP) 1 szt.
- do PBX (DSS1) 2 szt.
- do SMS-C 1 szt.
- do platformy OTA 1 szt.
- do platformy IN 1 szt.
- do SGSN 1 szt.
- do MSC2 1 szt.
co wynika ze schematu proponowanych w dalszej części niniejszego OPZ prób integracyjnych.
-
Dla celów analizy powypadkowej, MSC1 musi zapewniać możliwość rejestracji treści wszystkich połączeń głosowych przez niego realizowanych. Dane w postaci cyfrowych plików dźwiękowych, muszą zawierać również informację o podstawowych danych połączenia (identyfikacja uczestników połączenia, data i czas rozpoczęcia połączenia, opcjonalnie – wykorzystywane usługi). Pożądane jest udostępnienie zewnętrznego systemu do prostego przeglądania i wyszukiwania poszczególnych plików według zadanych kryteriów. Czas przechowywania plików – minimum 4 dni.
Rejestry -
Funkcje rejestru HLR1 centrali D900 powinny obejmować:
-
przechowywanie numerów MSISDN i IMSI abonenta danej sieci GSM,
-
przechowywanie informacji o kategorii abonenta (zwykły użytkownik, użytkownik z priorytetami, automat telefoniczny, aparat testowy itp.) oraz o jego statusie np. zablokowany przez operatora,
-
przechowywanie adresu MSC/VLR aktualnie obsługującego abonenta,
-
przechowywanie informacji o procedurach bezpieczeństwa (tryplet: RAND, SRES, Kc),
-
przechowywanie informacji o usługach dodatkowych z których korzysta abonent (lista usług przenoszenia, lista teleusług).
-
Rejestr HLR powinien stanowić centralną bazę danych zawierającą informacje o abonentach systemu GSM-R zarejestrowanych niezależnie od ich aktualnego położenia.
-
Rejestr HLR powinien znać położenie abonenta w sieci GSM-R z dokładnością do obszaru centralowego.
-
W przypadku, gdy abonent systemu GSM-R będzie zmieniał obszar centralowy, rejestr HLR powinien otrzymać identyfikator rejestru VLR skojarzonego z nowym obszarem centralowym.
-
Rejestr HLR dla każdego abonenta zarejestrowanego w systemie GSM-R powinien przechowywać następujące informacje:
-
wpisywany na stałe przez operatora międzynarodowy numer abonenta w sieci ISDN: MSISDN,
-
wpisywany na stałe przez operatora międzynarodowy numer abonenta ruchomego IMSI,
-
wpisywaną na stałe przez operatora kategorię abonenta (zwykły użytkownik, użytkownik z priorytetami, automat telefoniczny, aparat testowy itp.),
-
wpisywany na stałe przez operatora klucz identyfikacyjny Ki,
-
możliwy do zmiany przez operatora status abonenta (np. zablokowany przez operatora),
-
możliwą do zmiany przez operatora listę usług przenoszenia (bearer services),
-
możliwą do zmiany przez operatora listę teleusług (teleservices),
-
zmieniane na bieżąco (bez udziału operatora) aktualne położenie abonenta (identyfikator rejestru VLR, w którego obszarze centralowym aktualnie przebywa dany abonent).
-
Oprócz funkcjonalności bazy danych (wymienionej w poprzednim punkcie) rejestr HLR1 powinien mieć funkcjonalność modułu administracyjnego (interfejs z operatorem systemu), modułu analizy numerów (zamiana numeru IMSI na numer MSISDN i odwrotnie), modułu sygnalizacyjnego (odpowiednik bloku MAP-Mobile Application Part - odbiór i wysyłanie komunikatów w systemie sygnalizacji SS7 oraz podejmowanie innych działań, np. uaktualnianie zapisu o położeniu danej stacji ruchomej lub wydanie polecenia wymazania informacji o stacji ruchomej z rejestru VLR).
-
Centrum AuC1 powinno realizować funkcje bezpieczeństwa dla obszaru centralowego MSC1.
-
Centrum Identyfikacji (AuC) powinno być funkcjonalnie wydzielonym modułem, połączonym z rejestrem HLR, realizującym funkcje związane z zabezpieczeniem systemu GSM przed niepowołanym dostępem.
-
Centrum AuC powinno przeciwdziałać próbom realizacji połączeń na koszt innych abonentów oraz uniemożliwiać podsłuchiwanie rozmów przesyłanych w kanale radiowym.
-
Moduł AuC powinien zawierać parametry konieczne do identyfikacji abonentów, tzw. klucze szyfrujące oraz algorytmy szyfrowania i generator liczb losowych.
-
Centrum AuC powinno realizować zabezpieczenia na 3. poziomach:
-
poziomie dostępu użytkownika do usług realizowanych w systemie poprzez procedurę identyfikacji abonentów uniemożliwiającą korzystanie z systemu przez nieuprawnionych użytkowników,
-
poziomie zabezpieczenia sygnałów przesyłanych w kanale radiowym poprzez algorytmy szyfrowania zabezpieczające abonentów przed podsłuchem,
-
poziomie identyfikacji sprzętu, poprzez sprawdzanie, czy sprzęt wykorzystywany przez abonenta jest dopuszczony do użytkowania oraz czy nie znajduje się na liście sprzętu skradzionego.
-
Centrum AuC powinno generować, przy użyciu klucza Ki, trzy parametry (RAND, SRES i Kc) wykorzystywane przez procedury kryptograficzne, wg następującego porządku:
-
centrala MSC1 powinna wysyłać do Centrum AuC polecenie wygenerowania parametrów kryptograficznych,
-
w rejestrze modułu AuC powinien być odszukany klucz identyfikacyjny Ki, danego abonenta, a generator liczb pseudolosowych Au powinien wygenerować liczbę pseudolosową RAND (RANDom number),
-
na podstawie liczby RAND oraz klucza identyfikacyjnego Ki, powinny być obliczone dwa następne parametry: liczba SRES (Signal RESponse) oraz klucz szyfrujący połączenie Kc.
-
Dla danego abonenta, parametry RAND, SRES oraz Kc powinny być automatycznie zapamiętane w rejestrze HLR i stamtąd przekazywane na żądanie do rejestru VLR.
-
Funkcje rejestru VLR1 powinny obejmować czasowe przechowywanie informacji o abonentach znajdujących się aktualnie w zasięgu centrali MSC1.
-
Najważniejsze informacje przechowywane w rejestrze VLR powinny dotyczyć:
-
stanu terminala (wyłączony, w stanie czuwania, aktywny),
-
identyfikatora numeru przywołań LAI, w którym znajduje się stacja ruchoma,
-
numeru MSISDN abonenta,
-
adresu macierzystego HLR abonenta,
-
kategorii abonenta,
-
parametrów bezpieczeństwa związanych z abonentem.
-
Rejestr VLR powinien uczestniczyć w procesie śledzenia zmian położenia stacji ruchomej.
-
Rejestr VLR powinien zawierać, uaktualniane na bieżąco, informacje o abonentach aktualnie znajdujących się w obszarze obsługiwanym przez skojarzoną z nim centralą MSC1.
-
Rejestr VLR powinien współpracować z rejestrem HLR w następujący sposób:
-
żądać od rejestru HLR, w którym obca stacja jest zarejestrowana na stałe, danych o nowym dla siebie użytkowniku,
-
przekazywać rejestrowi HLR informacje i dane o nowym położeniu stacji ruchomej.
-
Kartoteka każdego abonenta w rejestrze VLR zawiera następujące informacje:
-
stan terminala (wyłączony, w stanie czuwania, aktywny),
-
identyfikator obszaru przywołań, w którym aktualnie znajduje się stacja ruchoma,
-
numer katalogowy MSISDN,
-
adres macierzystego rejestru HLR abonenta,
-
kategorię abonenta,
-
parametry procedur identyfikacji abonenta i szyfrowania transmisji radiowej (authentication triplet).
-
Wskaźnikiem kartoteki każdego abonenta powinien być jego numer IMSI.
-
Rejestr EIR1 powinien być bazą danych służącą do identyfikacji stacji ruchomych, poprzez numery seryjne używanych stacji (numery IMEI).
-
Rejestr EIR powinien być administrowany przez operatora.
-
W rejestrze EIR powinno następować porównanie numeru IMEI (przekazywanego przez MSC1 po odpowiedzi ze stacji ruchomej) z przechowywanymi tam listami.
-
W rejestrze EIR powinny być przechowywane 3 listy terminali:
-
lista biała – zawierająca numery wszystkich terminali zarejestrowanych w krajach objętych systemem GSM,
-
lista szara – zawierająca numery seryjne terminali, wobec których Zamawiający rozważa możliwość zablokowania,
-
lista czarna – zawierająca numery seryjne terminali zablokowanych np. terminali skradzionych.
-
Rejestr EIR powinien przesyłać do centrali MSC1 potwierdzenia identyfikacji terminalu.
-
Procedura identyfikacji w EIR nie powinna blokować połączeń alarmowych (emergency call) z terminali znajdujących się na wszystkich wymienionych listach.
-
Rejestr EIR powinien być połączony z centralą MSC poprzez łącze sygnalizacyjne.
-
Rejestr Połączeń Grupowych GCR1 dostarczony z centralą MSC1 powinien być zgodny z aktualnymi wersjami standardów FRS i SRS EIRENE.
-
Rejestr GCR powinien zapamiętywać atrybuty odnośnie usług VGCS, VBS i eMLPP dla poszczególnych grup oraz adresy dyspozytorów w poszczególnych komórkach należących do strefy MSC1. W rejestrze powinny być również zapisywana matryca dostępu (Matrix Access).
-
System MSC1 musi umożliwiać realizację roamingu międzysieciowego i międzynarodowego.
|