Załącznik nr 1 do siwz


Wymagania na terminale GSM-R



Pobieranie 0.63 Mb.
Strona9/18
Data29.04.2016
Rozmiar0.63 Mb.
1   ...   5   6   7   8   9   10   11   12   ...   18

Wymagania na terminale GSM-R

  1. Radia Kabinowe


Dla radiotelefonów pociągowych (Radia Kabinowe) obowiązują identyczne wymagania jak przedstawione w rozdziale 4.3.1.

  1. Terminale OPH


Dla terminali OPH obowiązują identyczne wymagania jak przedstawione w rozdziale 4.3.2.

  1. Terminale GPH


Dla terminali GPH obowiązują identyczne wymagania jak przedstawione w rozdziale 4.3.3.

  1. Terminale dyspozytorskie

    1. System stacjonarnych terminali dyspozytorskich


Dla systemu terminali dyspozytorskich obowiązują wymagania przedstawione w rozdziale 4.3.4.1. Lokalizacja centrali terminali dyspozytorskich przewidziana jest w Warszawie, ul. Kijowska 10/12.

        1. Dyspozytorskie terminale radiowe


Dla dyspozytorskich terminali radiowych z interfejsem radiowym Um obowiązują wymagania przedstawione w rozdziale 4.3.4.2.

  1. Terminale Diagnostyczne


Dla terminali diagnostycznych obowiązują wymagania przedstawione w rozdziale 4.3.5.

  1. Wymagania na OSS2 (OMC2-S, OMC2-R)


Dla systemu OSS2 obowiązują wymagania przedstawione w rozdziale 4.4.


  1. WYMAGANIA SZCZEGÓŁOWE – CZĘŚĆ C PRZEDMIOTU ZAMÓWIENIA

  1. Wymagania na system BSS3


System BSS3 powinien obejmować wydzielony fizycznie i funkcjonalnie sterownik stacji bazowych BSC3 (lokalizacja Warszawa) i cztery stacje bazowe BTS1, BTS8, BTS9 i BTS10 zlokalizowane odpowiednio w Studziankach, Ciechanowie, Czeruchach (linia E-65) i na dworcu Warszawa Centralna.

  1. Sterownik stacji bazowych


Dla sterownika stacji bazowej BSC3 (lokalizacja Warszawa) obowiązują identyczne wymagania jak dla sterownika BSC1 przedstawione w rozdziale 4.2.1.

  1. Stacje bazowe BTS1, BTS8, BTS9, BTS10


  1. Dla stacji bazowej BTS8 w podsystemie BSS3 obowiązują identyczne wymagania jak dla stacji bazowych BTS2, BTS3 i BTS4 w podsystemie BSS1 przedstawione w rozdziale 4.2.2. Dla stacji BTS10 Warszawa Dworzec Centralny będą wykorzystane pomieszczenia obiektu.

  2. Dla stacji BTS1 (Studzianki) przewidziano podłączenie do sieci teletransmisyjnej Zamawiającego za pomocą radiolinii pomiędzy stacjami bazowymi BTS1 (Studzianki) a BTS2 (Nasielsk). W lokalizacji Nasielsk Wykonawca zamontuje antenę i urządzenia radioliniowe w budynku administracyjnym przy stacji PKP Nasielsk.

  3. Dla stacji BTS9 (Czeruchy) przewidziano podłączenie do sieci teletransmisyjnej Zamawiającego za pomocą radiolinii pomiędzy stacjami bazowymi BTS9 (Czeruchy) a BTS8 (Ciechanów). Urządzenia radioliniowe należy zamontować w przewidzianych dla BTS8 i BTS9 kontenerach telekomunikacyjnych i masztach radiowych dla tych lokalizacji.

  4. Dla stacji bazowej BTS10 (Warszawa – Dworzec Centralny) należy zastosować rozwiązanie umożliwiające pokrycie radiowe hali kasowej Dworca z poziomem -95 dBm i peronów pasażerskich (peron 1, 2, 3 i 4) z poziomem -92dBm.

  5. Przewidywane radiolinie muszą zapewnić retransmisję sygnałów E1 ze stacji bazowych: Studzianki, Jackowo, Świercze i Gąsocin do systemu teletransmisji TK w Nasielsku a ze stacji bazowych: Bieńki, Gołotczyzna, Gąsocin i Czeruchy do systemu teletransmisji TK w Ciechanowie.
  1. Maszty antenowe, anteny


Dla masztów antenowych i anten stacji bazowych BTS1, BTS8 i BTS9 obowiązują identyczne wymagania jak przedstawione w rozdziale 4.2.3. Dla stacji bazowej BTS10 (Dworzec Warszawa Centralna) Wykonawca zaproponuje system antenowy pozwalający na pokrycie hali kasowej Dworca i czterech peronów pasażerskich i dwóch tuneli.

  1. Kontener telekomunikacyjny


Dla kontenerów telekomunikacyjnych na wyposażenie stacji bazowych BTS1, BTS8 i BTS9 obowiązują identyczne wymagania jak przedstawione w rozdziale 4.2.4. Stacja bazowa BTS10 (lokalizacji Dworzec Centralny – Warszawa), będzie umieszczona we wskazanym pomieszczeniu Zamawiającego na terenie Dworca.

  1. Podsystem teletransmisyjny (backhaul)


Dla podsystemu teletransmisyjnego obowiązują identyczne wymagania jak przedstawione w rozdziale 4.2.5.


  1. Wymagania na terminale GSM-R

  1. Terminale OPH


Dla terminali OPH obowiązują identyczne wymagania jak przedstawione w rozdziale 4.3.2.


  1. Terminale GPH


Dla terminali GPH obowiązują identyczne wymagania jak przedstawione w rozdziale 4.3.3.


  1. Wymagania na OSS3 (OMC3-R)


Dla systemu OSS3 obowiązują wymagania przedstawione w rozdziale 4.4. w zakresie dla OSS1/OMC3-R.


  1. WYMAGANIA SZCZEGÓŁOWE – CZĘŚĆ D PRZEDMIOTU ZAMÓWIENIA

  1. Wymagania na platformę IN/SCP


  1. Wykonawca powinien zaproponować funkcjonalność węzła sieci inteligentnej (Service Control Point). Wykonawca dokona implementacji na dostarczonym SCP funkcjonalności przenośności numeru dla abonentów sieci stacjonarnych i mobilnych (Number Portability) oraz zapewni w przyszłości możliwość implementacji funkcjonalności specyficznej dla GSM-R zgodnie z standardami EIRENE, realizację rozliczeń z bilingiem czas rzeczywistego, usługi Functional Numbering (FN), Location Depending Addressing (LDA) oraz Voice Group Calls Services (VGCS).

  2. Funkcja przenośności numerów musi współpracować z pozostałymi serwisami zaimplementowanymi na SCP, tak, że dla jednego połączenia realizowane będą funkcjonalność specyficzne dla EIRENE, wraz z modyfikacją numeru wynikającą z bazy danych przenośności numerów.

  3. Wykonawca zapewni przygotowanie do przenoszalności numeru (NP Number Portability) metodą ACQ (All Call Query). Baza przenoszonych numerów jest scentralizowana i dostępna w instytucji wskazanej przez Regulatora, a kopia lokalna bazy znajduje się u operatora. Uaktualnienie lokalnej bazy danych dokonuje się okresowo wg ustalonego harmonogramu.

  4. Lokalna baza danych przenośności numerów powinna być zaimplementowana na centralnej, relacyjnej bazie danych z standardowym interfejsem PL/SQL zgodny z Oracle 9i oraz automatycznie synchronizowana do węzła/ów SCP.

  5. Wykonawca sprawdzi wszystkie odnośne informacje wymagane do wdrożenia NP.

  6. Wdrożenie NP obejmować będzie następujące pozycje:

  1. wdrożenie centralnej, relacyjnej bazy danych,

  2. udostępnienie interfejsu zaopatrywania w dane zgodne z PL/SQL wraz z dokumentacją struktury danych,

  3. integracja lokalnej scentralizowanej bazy danych z węzłami SCP w celu zapewnienia automatycznej synchronizacji z węzłami,

  4. integracja lokalnej scentralizowanej bazy danych z centralną bazą danych dostępna w instytucji wskazanej przez Regulatora,

  5. konfiguracja warstwy sygnalizacyjnej w celu podłączenia do pozostałych operatorów oraz do głównego regionalnego punktu styku sieci,

  6. konfiguracja węzła/ów SCP dla zapewnienia poprawnej komunikacji z centralami Zamawiającego. Wyzwalanie aplikacji NP dla ruchu komórkowego wyzwalane będzie przez dwie centrale MSC opisane w pkt. 1.2.3 i 1.2.4 OPZ po ich unowocześnieniu sprzętowym i programowym a dla ruchu do sieci stacjonarnych – dwie centrale o protokołach opisanych w pkt. 7.1.15 OPZ i interfejsach opisanych w pkt. 7.1.16 OPZ.

  1. Jeśli proponowana funkcjonalność IN obejmuje dodatkowe funkcje systemu, które nie są przedmiotem oferty, funkcje te należy opisać szczegółowo, określając ich zalety, wady i możliwe zastosowanie w polskiej sieci kolejowej GSM-R. Wykonawca musi opisać proponowane rozwiązanie pod kątem możliwości przyszłego wdrożenia usług EIRENE.

  2. Wszystkie oferowane funkcje proponowanego rozwiązania funkcjonalności IN powinny zostać w przyszłości w pełni przetestowane w zastosowaniach operacyjnych i zostać zaakceptowane przez odpowiedzialny w tym zakresie urząd. Należy również podać szczegółowy opis funkcji.

  3. Wykonawca opisze wszelkie specjalne usługi EIRENE możliwe do zrealizowania w oparciu o podane rozwiązanie funkcjonalności IN. Opis ten powinien nawiązywać do stosownych wymagań EIRENE SRS i FRS.

  4. SCP powinno umożliwiać rozliczanie połączeń przy współpracy z konwergentnym bilingiem czasu rzeczywistego.

  5. Do rozliczania w czasie rzeczywistym SCP powinno wykorzystywać interfejs DIAMETER lub równoważny.

  6. Podczas tymczasowej niedostępności bilingu czasu rzeczywistego (np. wynikającego z awarii), SCP powinno generować rekordy UDR w celu późniejszego przetworzenia przez system bilingowy.

  7. Węzeł SCP powinien być wyposażona w protokoły: CAMEL Phase 1, Phase 2, Phase 3 zgodne z:

  1. 3GPP TS 03.78 „Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 2“;

  2. 3GPP TS 09.78: "Digital cellular telecommunications system (Phase 2+); CAMEL Application Part (CAP) specification - Phase 2".

  3. 3GPP TS 23.078: „Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 - Stage 2“

  4. 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"

  1. Dodanie nowszych wersji protokołu CAMEL nie może nieść za sobą dodatkowych opłat licencyjnych.

  2. Węzeł SCP powinien być wyposażony w protokoły INAP zgodne ze standardami.

  1. ITU-T REC. Q.1211 Introduction to IN Capability Set 1

  2. ITU-T REC. Q.1213 Global Functional Plane for IN Capability Set 1

  3. ITU-T REC. Q.1214 Distributed Functional Plane for IN Capability Set 1

  4. ITU-T REC. Q.1215 Physical Plane for IN Capability Set 1

  5. ITU-T REC. Q.1218 Interface Recommendation for IN Capability Set 1

  6. ETSI ETS 300 374-1 Intelligent Network (IN); IN Capability Set 1 (CS1); Core Intelligent Network Application Protocol (INAP) Part 1: Protocol specification.

  7. ETSI ETS 300 374-5 Intelligent Network (IN); IN Capability Set 1 (CS1); Core Intelligent

  1. SCP powinien umożliwiać podłączenie do centralnego węzła sieci sygnalizacyjnej i innych operatorów poprzez:

  1. SIGTRAN

  1. MTP3-User Adaptation Layer (M3UA) RFC 3332,

  1. Stream Control Transmission Protocol (SCTP) RFC 2960, RFC 3309 SCTP checksum change.

  1. Dodanie nowej, zmodyfikowanie wersji protokołu INAP lub CAMEL powinno odbywać się przez kompilacje pliku źródłowego ASN.1 oraz instalacje na platformie.

  2. Dodanie nowszych wersji protokołu INAP nie może nieść za sobą dodatkowych opłat licencyjnych.

  3. Na etapie realizacji instalacji projektu GSM-R/Pilotaż nie jest istotna wydajność systemu IN, jednak rozwiązanie sprzętowe powinno zapewnić obsługę do 200 CAPS (Call Per Second) oraz być przygotowane do przyszłej rozbudowy umożliwiającej świadczenie usługi dla docelowej sieci GSM-R. Wykonawca określi wymiarowanie systemu pod kątem przyszłych zastosowań a także możliwości świadczenia przy pomocy SCP innych usług. Zostanie podany również sposób i cena przyszłej rozbudowy.

  4. Węzeł SCP powinien posiadać narzędzia do modyfikacji i kompilacji protokołów opartych o standard TCAP. Modyfikacje protokołów nie mogą nieść za sobą dodatkowych opłat licencyjnych.

  5. Do monitorowania SCP powinno udostępniać interfejs SNMP.

  6. SCP powinno umożliwiać redystrybucję licencji pojemnościowej pomiędzy wiele fizycznych węzłów SCP, tak, żeby umożliwiać przelanie ruchu na jeden z fizycznych węzłów.

  7. SCP (SCE) powinno umożliwiać tworzenie plug-inów do wymiany informacji po protokole TCP/IP w dowolnym formacie warstw wyższych. Wykonawca zapewni możliwość stworzenia tzw. plug-inu przez Zleceniodawcę lub firmy trzecie bez konieczności autoryzacji kodu lub innych opłat.

  8. SCP powinno umożliwiać dostęp do zewnętrznych baz danych poprzez SQL z poziomu logiki usług.






1   ...   5   6   7   8   9   10   11   12   ...   18


©absta.pl 2019
wyślij wiadomość

    Strona główna