BSC3000

Technische Vorgaben

Inhaltsverzeichnis
1 Ziel des Dokumentes
2 Technische Vorgaben und Risiken fr die BSC 3000 Migration
2.1 Austausch der BSC 2G auf BSC 3000
2.1.1 Muss Anforderung
2.1.2 Kann_1 Anforderung
2.1.3 Kann_2 Anforderung
2.1.4 Risiken
2.2 Infrastruktur an BSC Standorten
2.2.1 Muss Anforderung
2.2.2 Kann_1 Anforderung
2.2.3 Kann_2 Anforderung
2.2.4 Im Projekt BSC 3000 nicht zu bercksichtigende Anforderungen
2.2.5 Risiken
2.3 Keine Vernderung der Ketten / Loop
2.3.1 Muss Anforderung
2.3.2 Kann_1 Anforderung
2.3.3 Kann_2 Anforderung
2.3.4 Risiken
2.4 Hauseinfhrung
2.4.1 Muss Anforderung
2.4.2 Kann_1 Anforderung
2.4.3 Kann_2 Anforderung
2.4.4 Risiken
2.5 TCU 3000 Standorte
2.5.1 Muss Anforderung
2.5.2 Kann_1 Anforderung
2.5.3 Kann_2 Anforderung

DB Systel

Version 1.0

Status: Freigegeben

Ersteller: T.SVN
Abgestimt mit I.NVT

2.5.4 Risiken
2.6 Recovery BSC
2.6.1 Muss Anforderung
2.6.2 Kann_1 Anforderung

2.6.3 Kann_2 Anforderung

2.6.4 Risiken
2.7 DCN Anbindung
2.7.1 Muss Anforderung
2.7.2 Kann_1 Anforderung
2.7.3 Kann_2 Anforderung
2.7.4 Risiken
3 Anlagen
3.1 Auszug aus dem Punkt-zu-Punkt Vertrag mit Vodafone zu Produkt 5
3.1.1 Mgliche SLA aus dem Punkt-zu-Punkt Vertrag
3.1.2 Produkt 5
3.1.3 Produkt 6
3.2 Verkehrsmodell
3.2.1 Verkehrsmodell
3.2.2 Auszug aus dem Verkehrsmodell

Bearbeitungsstatus
Version Status
(Dokume
nt)

Name
(Bearbeiter)

OE
(Bearbeiter)

Art der Bearbeitung

(in Stichworten)

Datum

V0.1

Entwurf

J. Schmidt

T.SVN13

Beschreibung Prmissen

25.03.2011

V0.2

Entwurf

M. Suck, Th.
Spitzbart,W. Hein

T.SVN13

Anpassung Prmissen

28.03.2011

V0.3

Entwurf

C. Maul

T.SVN25

Anpassung Prmissen

29.03.2011

V0.4

Entwurf

M.Suck, T.
Bachner, W.Hein,
C. Maul

T.SVN13; Anpassung Prmissen

T.SVN15;
T.SVN25

04.04.2011

V0.5

Entwurf

J. Schmidt,

T.SVN13

Ergnzungen

05.04.2011

W. Klein

T.SVN2

Review

C. Maul

T.SVN25

05.04.201111.04.2011

J. Schmidt

T.SVN13

T. Bachner

T.SVN15

C. Rentschler

T.CVS11

J. Schmidt

T.SVN13

Finalisierung des Review

11.04.2011

T. Spitzbart
V0.6

Review

V0.7

Review

V0.8

Durchspra A. Zolotnitski
che

T.SVN31

Gemeinsames Review mit DB Netz im

Meeting vom 14.04.2011

14.04.2011

V0.81

Umarbeitu J. Schmidt
ng

T.SVN13

Umarbeitung des Dokumentes

15.04.2011

V0.82

Reviewein J. Schmidt
arbeitung M. Suck

T.SVN13

Einarbeitung von Reviewergebnissen

18.04.2011

Gemeinsames Review im Meeting vom

19.04.2011

19.04.2011

berarbeitung des Dokumentes; Einfgen

der Anlagen

19.04.2011

Gemeinsames Review im Meeting vom

21.04.2011

21.04.2011

V0.83/0.84 Review

T.SVN13

C. Maul

T.SVN25

W. Ziebs

T.SVN15

M. Bergmann

T.SVN31

T. Spitzbart

T.SVN13

DB Netz/DB Systel

V0.85

berarbeit J. Schmidt
ung

T.SVN13

V0.86

Review

V0.90

berarbeit J. Schmidt
ung

T.SVN13

berarbeitung des Dokumentes

26.04.2011

V0.91

berarbeit A. Zolotnitski
ung

T.SVN31

Nummerierungsnderung

27.04.2011

V0.92

berarbeit J. Schmidt
ung

T.SVN13

nderungsakzeptierung

27.04.2011

V1.0

Freigabe

DB Netz/DB Systel

DB Netz
Steuerkreis, Mail
D.Peters

Freigabe der Version 0.92 im Steuerkreis

24.05.2011
24.05.2011 als finale version zwischen DB
Netz und DB Systel

Abkrzungen
Abkrzung

Bedeutung

A-Schnittstelle

Schnittstelle zwischen MSC-TCU

AterSchnittstelle

Schnittstelle zwischen TCU-BSC

AbisSchnittstelle

Schnittstelle zwischen BSC-BTS

BSC

Base Station Controller

BSS

Base Station Subsystem

DCN

Data Communication Network

MSC

Mobile Switching Center

NEA

Netz Ersatz Anlage

OBG

Ortsbegehungsprotokoll

PzP

Punkt-zu-Punkt

SLA

Service Level Agreement

TANV

Trassen Anlagen Nutzungs Vertrag

TCU

Transcoder Unit

bertragungstechnik

USV

Unterbrechungsfreie Stromversorgung

1 Ziel des Dokumentes

Ziel dieses Dokumentes ist es, die technischen Vorgaben fr das BSC 3000
Migrationsprojekt zu definieren.
Auf dieser Grundlage knnen die entsprechenden Planungshandbcher angepasst werden,
um darauf aufbauend die Planungen durchfhren zu knnen.
Ziel ist es, fr den Auftraggeber und Auftragnehmer die gewnschten Funktionalitten im
Rahmen des Migrationsprojektes zur Verfgung zu stellen.
Die Przisierung der technischen Vorgaben basieren auf dem Kenntnisstand vom
19.04.2011, die in einem gemeinsamem Meeting mit DB Netz festgelegt wurden.
Weiterhin wurden verschiedene Kriterien fr eine Anforderungsmatrix definiert:
Alle technischen Anforderungen werden im Nachgang in eine Matrix (Muss- und KannAnforderung) aufgenommen und festgelegt wann die Anforderung umgesetzt werden:
1. Muss Anforderung
- im BSC 3G Projekt zwingend umzusetzen
2. Kann_1 Anforderung relativ wichtig
- mgliche Integration ins BSC 3G Projekt wird bei freien Budget-Mitteln geprft;
ansonsten sollte kurzfristig bis mittelfristig ein neues Projekt diese Anforderung
umsetzten
3. Kann_2 Anforderung relativ unwichtig
- Anforderung sollte mittel bis langfristig durch ein geeignetes Projekt umgesetzt
werden
Die im Dokument genannten Risiken beziehen sich auf alle Anforderungen Muss,
Kann_1 und Kann_2.

2 Technische Vorgaben und Risiken fr die BSC 3000

Migration
Im nachfolgenden sind die hergeleiteten Prmissen fr die BSC 3000 Migration mit Stand
14.04.2011 aufgelistet.

2.1 Austausch der BSC 2G auf BSC 3000

Das Ergebnis einer Untersuchung der Netzinfrastruktur war, dass die bisherige BSC Anzahl
von 63 BSC 2G auf ca. 40 BSC 3000 reduziert werden kann und dies eine fr DB Netz
wirtschaftlich sinnvolle Lsung darstellt. Als Planungsergebnis wurden 39 BSC 3000
bestimmt. Die Reduktion der Anzahl der Standorte stellt kein Risiko dar, da die Standorte
knftig zwingend knotendisjunkt mit Zweiwegefhrungt aufgebaut werden. Falls baulich
vorhanden, wird die kantendisjunktheit ebenfalls hergestellt; anderenfalls wird die
kantendisjunktheit in spteren Projekten (IKI) zwingend hergestellt.
An 39 bisher vorhandenen BSC 2G Standorten wird eine neue BSC 3000 aufgebaut. An
diesen Standorten soll die bestehende Infrastruktur unter Beibehaltung des Status Quo
verwendet werden.
An 20 BSC 2G Standorten, die als T-Standorte verbleiben, wird die GSM-R
bertragungstechnik belassen. ber das bertragungsnetz wird eine Verbindung zur
zugewiesenen BSC 3000 aufgebaut, um die am BSC 2G Standort auflaufenden Abis
bertragungsstrecken zur BSC 3000 abzufhren.
2.1.1 Muss Anforderung
Folgende Prmissen mssen bei der Planung innerhalb des BSC 3000 Projektes
bercksichtigt werden:
2.1.1.1 Es ist zwingend eine knotendisjunkte A-ter (TCU BSC) Anschaltung mit
Zweiwegefhrung der BSC 3000 Standorten zu realisieren. Ist eine kantendisjunkte
Anschaltung ber vorhandene Wege mglich, so ist diese zwingend durchzufhren.
2.1.1.2 Die bahneigenen Wege sind mglichst fr A (MSC-TCU), A-ter (TCU-BSC)
und A-bis Verlngerung (BSC 3000 T Standort (ehemalige BSC 2G)) zu verwenden.
Unter bahneigene Wege fallen auch TANV LWL Kabel und Fasern. Vermeidung der Nutzung
vorhandener TANV-Verbindungen
2.1.1.3 Bei abgesetzter TCU ist zwingend eine knotendisjunkte Anschaltung mit
Zweiwegefhrung der A-Schnittstelle (MSC-TCU) vorzusehen. Ist eine kantendisjunkte
Anschaltung ber vorhandene Wege mglich, so ist diese zwingend durchzufhren.
2.1.1.4 Umheben der noch vorhandenen, zuknftig noch notwendigen
Mietleitungen auf den neuen Rahmenvertrag PzP-Verbindungen mit Vodafone, um die im
Rahmenvertrag vereinbarten verbesserten SLA und Anbindungen sowie betriebliche
berwachungsmglichkeiten zu erhalten.
Aus dem Punkt-zu-Punkt Vertrag mit der Vodafone wird das Produkt:

getrennter Erstweg Produkt 5

mit einer Entstrzeit 4h (Los 2)
mit einer Verfgbarkeit 99,5% SLA B

bestellt.
2.1.1.5 Es ist zwingend eine knotendisjunkte Abis Anbindung mit
Zweiwegefhrung zwischen T-Standort (ehem. BSC2G- Standort) und neuem BSC 3000
Standort vorzusehen. Ist eine kantendisjunkte Anschaltung ber vorhandene Wege mglich,
so ist diese zwingend durchzufhren.
2.1.1.6 Zwingende Erweiterung der verwendeten UMUX Knoten mit zweiter,
redundanter CPU Einheit (COBUX Karte).
2.1.1.7 Die Dimensionierung der Schnittstellen erfolgt nach dem aktuellen
Verkehrsmodell.(NSS Ausschreibung: 20101119 Verkehrsmodell GSM-R BFMA.xls)
2.1.2 Kann_1 Anforderung
Es wurden keine Kann_1 Anforderungen definiert.
2.1.3 Kann_2 Anforderung
Die A, Ater und Abis Verlngerung sind kantendisjunkt auszufhren.
2.1.4 Risiken
Die im nachfolgenden aufgefhrten Risiken entstehen bei Nichtbeachtung der
o.g.technischer Vorgaben.
Alle bisher aktuellen Risiken bleiben bestehen z.B.:
Keine knotendisjunkte A-ter Anschaltung bei den bestehenden bestehenden
BSC 2 G Standorten => Ausfall des Knotens fhrt zu einem Ausfall des
gesamten angeschlossenen BSC Bereiches.
Nutzung vorhandener TANV-Verbindungen und Mietleitungen (mit den
entsprechenden Verfgbarkeiten und Entstrzeiten) -Bsp. Ausfall ber
mehrere Stunden BSC Kln in KW 13/2011, BSC Fulda in KW 11/2011 bei
verwendeten TANV Verbindungen
Keine knotendisjunkte Abis-Verlngerung => Ausfall des Knotens fhrt zu
einem Ausfall des gesamten ehem. BSC2G-Bereiches
Knoten (Multiplexer) in sich hat keine redundante Hardware (z.B. redundantes
Mainboard) => Ausfall des Knotens bei Kartendefekt mglich
Keine knotendisjunkte A- und A-ter-Anbindung => Ausfall des Knotens fhrt
zu einem Ausfall des gesamten BSC3000-Bereiches

2.2 Infrastruktur an BSC Standorten

An 39 bisher vorhandenen BSC 2G Standorten wird eine neue BSC 3000 aufgebaut.
An diesen Standorten soll die bestehende Infrastruktur unter Beibehaltung des Status
Quo verwendet werden.

2.2.1 Muss Anforderung

Folgende Prmissen mssen bei der Planung innerhalb des BSC 3000 Projektes
bercksichtigt werden:
2.2.1.1 Die Bestandsstromversorgung an allen TCU- und BSC3000-Standorten ist
gegen die geltenden Richtlichtlinien, Normen und Vorschriften zu prfen. Bei Ersatz der
Technik ist hauptschlich die Schnittstelle Bestandsstromversorgung/ neue BSC-Einspeisung
zu betrachten.
2.2.1.2 Die Hauseinspeiseversorgung muss fr den Parallelbetrieb ausreichend
dimensioniert sein.
2.2.1.3 Die Gleichrichter (BSC/TCU) mssen fr den Parallelbetrieb ausreichend
dimensioniert sein.
2.2.1.4 Die berprfung der Tragfhigkeit der Decken und des Doppelbodens ist
zwingend durchzufhren.
2.2.1.5 Es muss die elektrotechnische Freigabe pro TCU und BSC3000-Typ
durchgefhrt werden.
2.2.1.6 Es ist zwingend berprfung der aktuellen Klimatisierung auf den
aktuellen Stand der Technik und dem Bedarf durchzufhren.
2.2.1.7 Es ist ein Monitoringsystem vorzusehen, wobei hier die ALCAR Karte
eingesetzt werden muss und die bisher an der BSC 2G (59 Standorten) angeschlossenen
Alarme abzufhren.
2.2.2 Kann_1 Anforderung
2.2.2.1 Prfung, ob die verwendeten T Netzelemente an unterschiedlichen
Stromkreisen angeschlossen sind; ggf. Herbeifhrung der notwendigen Anschaltung.
2.2.3 Kann_2 Anforderung
2.2.3.1 Es soll der Aufbau eines bertragungstechnisch redundant
angebundenen Monitoringsystems fr Alarme (z.B. Klima, USV, Leckage,
Temperaturberwachung..) durchgefhrt werden.
2.2.3.2 Ausrstung der BSC-Standorte mit einer Brandfrhesterkennung.
2.2.3.3 Austausch der USV Batterien inkl. Gleichrichter wegen berschreitung der
Garantiezeit bzw. nicht mehr ausreichender Kapazitt und erhhtem Ausfallrisiko.
2.2.4 Im Projekt BSC 3000 nicht zu bercksichtigende Anforderungen
Weitere Empfehlungen, die im Rahmen des Projektes BSC 3000 Migration nicht
betrachtet und dort nicht bercksichtigt werden:

 Umsetzung der Ergebnisse aus den Ortsbegehungsprotokollen (OBG) der

Konzernsicherheit von 2006 fr die BSC 2G Standorte; dies wird zwingend fr
erforderlich gehalten, muss im Rahmen des BSS-Reinvest betrachtet werden.
Umsetzung der Konzernrichtlinie 135.0401; dies wird zwingend fr erforderlich
gehalten, muss im Rahmen des BSS-Reinvest betrachtet werden.
Selektivittsanforderungen berprfen, das betrifft u.a. Elemente des
Leitungsschutzes, berspannungsschutzes und der Fehlerstromberwachung. Dies
wird zwingend fr erforderlich gehalten, muss im Rahmen des BSS-Reinvest
betrachtet werden.
Verwendung einer Notstromeinspeisung mit Dieselaggregat oder alternativ der
Einsatz von Brennstoffzellen als USV/NEA. Dies ist ein Risiko.
Trennung von Dritten (z.B. Zutritt, Spannungsversorgung, Klimatisierung,
bertragungstechnik, Alarmberwachung.....). Dies ist ein Risiko.
Die Alarme werden auf eine ALCAR-Karte aufgelegt und stellen somit einen Single
Point of Failure dar.
2.2.5 Risiken
Die im nachfolgenden aufgefhrten Risiken entstehen bei Nichtbeachtung der o.g.
Empfehlungen.
Alle bisher aktuellen Risiken bleiben bestehen z.B.:
Veraltete Infrastruktur (Strom (tlw. nur 1 Stromkreis), Klima........)
Keine Trennung von Dritten (z.B. Zutritt, Spannungsversorgung,
Klimatisierung, bertragungstechnik, Alarmberwachung.....)
Beispiel: BSC FFT (Karlsstrae) Spannungsausfall 10/2010
Ausfall der veralteten Batterien
Beispiel: MSC Mnchen Ausfall Batteriebackup 48V inkl. defekter
Wechselrichter
Ersatzteilverfgbarkeit verringert sich wegen Produktnderungen
Alarmkonzept: Bei berwachung der Standorte durch BSC T knnen ggf.
bei Verbindungsausfall keine Alarme bertragen werden. Vorteile sind die
Mglichkeit eines zweiten Alarmweges bei Anschluss ber ein IP-Netz, die
grere Vielfalt an gnstigen Sensoren, die Mglichkeit der bertragung
analoger Sensordaten (z.B. Temperatursensoren).

2.3 Keine Vernderung der Ketten / Loop

Im Rahmen der BSC 3000 Migration werden keine Abis Ketten verndert; d.h. die bisher
bestehende Anbindung an die BSC 2G bleibt bertragungstechnisch weiterhin bestehen.
2.3.1 Muss Anforderung
Es wurden keine Muss Anforderungen definiert.
2.3.2 Kann_1 Anforderung
Es wurden keine Kann_1 Anforderungen definiert.

2.3.3 Kann_2 Anforderung

2.3.3.1 Knoten- und kantendisjunkte Abis Anschaltung; Kette und Loop drfen
nicht ber den gleichen BSC T Multiplexer (UMUX) laufen. Optimierung und Herstellung
der knotendisjunkten Anbindungen bei Loopanschaltungen auf unterschiedlichen BSC
UMUXe.
2.3.4 Risiken
Die im nachfolgenden aufgefhrten Risiken entstehen bei Nichtbeachtung der o.g.
Empfehlungen.
Tlw. keine knoten- und kantendisjunkte Abis Anschaltung; Kette und Loop laufen tlw.
ber den gleichen BSC T Multiplexer => bei Ausfall dieses UMUXes fallen GSM-R
Ketten aus, die auch in Loop angebunden sind.

2.4 Hauseinfhrung
2.4.1 Muss Anforderung
Es wurden keine Muss Anforderungen definiert.
2.4.2 Kann_1 Anforderung
Es wurden keine Kann_1 Anforderungen definiert.
2.4.3 Kann_2 Anforderung
2.4.3.1 Es ist grundstzlich eine 2. Hauseinfhrung vorzusehen. Diese wird, falls
notwendig, nicht innerhalb des Projektes BSC 3000 realisiert sondern in weiteren Projektes
(u.a. IKI)
2.4.4 Risiken
Die im nachfolgenden aufgefhrten Risiken entstehen bei Nichtbeachtung der o.g.
Empfehlungen.
Tlw. sind alte BSC-Standorte nur ber 1 Hauseinfhrung angebunden; ein Ausfall
dieser Hauseinfhrung kann zu einem Kompletausfall eines BSC Bereiches fhren.

2.5 TCU 3000 Standorte

2.5.1 Muss Anforderung
Es wurden keine Muss Anforderungen definiert.

2.5.2 Kann_1 Anforderung

2.5.2.1 TCU3000 Standorte sind uneingeschrnkt MSC-Standorte.
2.5.3 Kann_2 Anforderung
Es wurden keine Kann_2 Anforderungen definiert.
2.5.4 Risiken
Eine Auslagerung der TCU 3000 fhrt zu einer Reduzierung der Verfgbarkeit, da
zustzliche bertragunsgwege zwischen MSC und TCU geschaltet werden, gem
Zulassung des GSM-R-Mobilfunksystems (27.01.99)
Eine Auslagerung der TCU 3000 fhrt zu einer Erhhung des Round-Trip-Delays. Bei
ber 100ms kann dies zu Synchronisationsproblemen fhren.
2.6 Recovery BSC
In dem BSC 3000 Projekt ist keine Recovery BSC und keine Recovery TCU vorgesehen
2.6.1 Muss Anforderung
Es wurden keine Muss Anforderungen definiert.
2.6.2 Kann_1 Anforderung
Es wurden keine Kann_1 Anforderungen definiert.
2.6.3 Kann_2 Anforderung
2.6.3.1 Es ist eine Recovery BSC 3000 vorzusehen.
2.6.3.2 Es ist eine Recovery TCU 3000 (als Ersatzteil) vorzusehen.
2.6.4 Risiken
Bei einem gravierenden Ausfall einer BSC 3000 oder einer TCU 3000 droht fr
lngere Zeit ein kompletter Ausfall eines BSC 3000 Bereiches.
Es gibt bei komplexen Strungsszenarien wie z.B. Fehlern auf der Backplane oder
dem Untergang eines BSCs kaum Mglichkeiten, diese zeitnah zu lsen. Als letztes
Mittel mu ein neues Netzelement eingesetzt werden. Redundanz streben wir in
Analogie auch im neuen MSC-Architektur Szenario an, wo im Zweifel innerhalb des
Netzwerkes ein Ersatzknoten bereitsteht.

2.7 DCN Anbindung

Aktuell wird die DCN Anbindung der TCU2G und BSC2G ber X25 Links der A/Ater Interface
(Inband) realisiert.
Bei der TCU3000/BSC3000 wird die TCU/BSC an die GSM-R DCN Router angeschlossen
und ber IP Anschlsse gemanaged.

2.7.1 Muss Anforderung

Die DCN Anbindung muss redundant ausgefhrt werden. Dazu gehrt eine redundante
Anbindung der Router an dem betrachteten Standort, es werden 2 Router & Switche am
Standort bentigt und die NEs mssen an beide Router angeschlossen werden. Die Router
mssen an unterschiedliche T Netzelemente (knotendisjunkt) angebunden werden.
2.7.2 Kann_1 Anforderung
Es wurden keine Kann_1 Anforderungen definiert.
2.7.3 Kann_2 Anforderung
Es wurden keine Kann_2 Anforderungen definiert.
2.7.4 Risiken
Bei Ausfall der DCN Anbindung ist weder die TCU3000/BSC3000 noch das
bertragungsnetz UMUX zu erreichen.
Beispiel: T-Netz Hagen nicht managebar KW11/2011 DCN Ausfall (Kabelschaden
Vodafone)

3 Anlagen
3.1 Auszug aus dem Punkt-zu-Punkt Vertrag mit Vodafone zu Produkt 5
3.1.1 Mgliche SLA aus dem Punkt-zu-Punkt Vertrag

3.1.2 Produkt 5

3.1.3 Produkt 6

3.2 Verkehrsmodell
NSS Ausschreibung: 20101119 Verkehrsmodell GSM-R BFMA.xls
3.2.1 Verkehrsmodell

20101119
Verkehrsmodell GSM-R BFMA.xls

3.2.2 Auszug aus dem Verkehrsmodell