Anhang 1 Technische Leistungsbeschreibung Layer2 Bitstream Vorleistungsprodukt im DNS:NET NGA Netz „Virtual Unbundled Local Assess – VULA“

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 1

Revision History Datum 20.07.2015 18.01.2016 22.01.2016 31.01.2016

Autor Alexander Lucke Peter-Paul Poch Dto. Dto.

Version 0.1 0.2 1 1.1

29.02.2016

Volker Huber

1.2

Änderungen Inital Draft Sonderbauformen/Management Sum. TAL-Vertrag Telekom Zufügen Anhänge / Sonderleistungen Pkt. 5.3 quality control

08.03.2016 20.04.2016

Peter-Paul Poch dto

1.3 1.4

Einfügen Anlage 9 Einfügen BuGG und begründen

Version ohne BuGG Alle technischen Details werden nur bei Bedarf dem KUNDEN bereitgestellt. Sie sind nicht für eine Veröffentlichung freigeben. Die nachfolgenden Anlagen sind nur für Nachfrager, die besondere Anforderungen an die VULA oder das Netz haben. Ein berechtigtes Interesse muss nachgewiesen werden. Sie unterliegen einem strikten NDA. Diese Informationen gewähren einen tiefen Einblick in die Fähigkeiten und Prozesse des Netzbetreibers. Es ist bis dato unüblich, Dritten solchen Informationen bereitzustellen! Will man aber die VULA oder Teilnetze für Innovation und Qualitätssicherung öffnen, dann werden diese Informationen fallweise vom Nachfrager benötigt. Dies gilt ebenso für das Nachweisverfahren. Anlage 2: Ausbaustand / HW/SW (ggf. Qualitätsparameter der Netzkomponenten) Anlage 4: vorhandene DSL Profile auf den DSLAM’s Anlage 5: Einsetzbare und freigegebene VDSL Vectoringneutrale oder-fähige CPE’en Anlage 8: Mitnutzung Aggregationsnetz (Quality of Service Concept) Die Anlage 3 wird aus Sicherheitsgründen nicht öffentlich gestellt Die nachfolgenden Anlagen werden individuell bedarfsgerecht erstellt. Daher gibt es keine formale Vorlage. Die Anlage 1 ist im Übrigen vom Kunden zu erstellen, wenn es um Anforderungen jenseits üblicher Standardanwendungen (z.B. 50 Mbit/s) geht. Anlage 1: Anforderungsprofile von [KUNDE] an die Plattform Anlage 6: Forecast-Vereinbarung Anlage 7: Mitnutzung TAL-Vertrag der DNS:NET

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 2

Inhalt Revision History .................................................................................................................... 2 Inhalt..................................................................................................................................... 3 Management Summary ........................................................................................................ 4 1.

Anbindungspunkte für VULA-Nachfrager im DNS:NET NGN Netz ................................. 6

2.

Technische Spezifikationen des DNS:NET Layer2 Vorleistungsproduktes ..................... 7

3.

Abgrenzung der Netzressourcen unterschiedlicher Nachfrager .................................... 8

4.

Der Order-Prozess ......................................................................................................... 9

5.

API zur Steuerung der eigenen Netzressourcen .......................................................... 11

Vorfall „Bestellung“ (neuen Port belegen) .................................................................................................................... 9 Aufruf: ......................................................................................................................................................................................... 9 Rückmeldung: .......................................................................................................................................................................... 9 Vorfall „Kündigung“ (Port kündigen) ........................................................................................................................... 10 Aufruf: .......................................................................................................................................................................................10 Rückmeldung: ........................................................................................................................................................................10 5.1 Provisionieren eines Ports (Profil einstellen) .................................................................................................. 11 Aufruf: .......................................................................................................................................................................................11 Rückmeldung: ........................................................................................................................................................................11 5.2 Aktivieren eines Ports ................................................................................................................................................... 12 Aufruf: .......................................................................................................................................................................................12 Rückmeldung: ........................................................................................................................................................................12 5.3 Deaktivieren eines Ports .............................................................................................................................................. 12 Aufruf: .......................................................................................................................................................................................12 Rückmeldung: ........................................................................................................................................................................13 5.4. Abfragen der Portstatistik ......................................................................................................................................... 13 Aufruf: .......................................................................................................................................................................................13 Rückmeldung: ........................................................................................................................................................................13

6. Sonderbauformen für Kollokation und dezentrale/zentrale Zuführung von Verkehren mit oder ohne Aggregation ................................................................................................. 15

6.1 Angebot über Kollokation ........................................................................................................................................... 15 Preise Entgelte für die Angebotserstellung für die Bereitstellung von Kollokation und RLT ..........16 Annahme des Angebotes ...................................................................................................................................................16 Kündigung durch den Kunden .......................................................................................................................................16 6.2 Angebot über dezentrale/zentrale Zuführung von Verkehren mit oder ohne Aggregation über das TK-Netz der DNS:NET ....................................................................................................................................... 16 Annahme des Angebotes ...................................................................................................................................................17 Mindestlaufzeit und Kündigung durch den Kunden ............................................................................................17 6.3 Angebot über weitergehende Leistungsmerkmale des DNS:NET Netzes bei Mitnutzung ........ 17

7.

Nachweisverfahren ..................................................................................................... 18

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 3

Management Summary Aufgrund der überarbeiteten EU-Märkteempfehlung (2014/710/EU), veröffentlicht am 11. Oktober 2014 im Amtsblatt der Europäischen Union, umfasst die Definition für den Markt 3a, „Markt für den auf der Vorleistungsebene an festen Standorten lokal bereitgestellten Zugang zu Teilnehmeranschlüssen“ neben dem physisch entbündelten Zugang erstmals auch einen virtuell entbündelten Zugang zur TAL. Die EU-Kommission hat in ihren Erläuterungen zur Empfehlung über relevante Produktund Dienstmärkte des elektronischen Kommunikationssektors die für eine VorabRegulierung in Betracht kommen, dargelegt, unter welchen Voraussetzungen ein virtuelles Zugangsprodukt als den physischen Zugang funktional gleichwertig erachtet werden kann. Demzufolge werden folgende drei Eigenschaften als erforderlich angesehen: 1. Lokaler Zugang: Dies bedeutet, dass die Übergabe des Verkehrs näher beim Endkunden erfolgen muss als beim Zugang auf nationaler oder regionaler Ebene wie dies für den traditionellen Bitstromzugang der Fall ist. Die Kommission merkt aber auch an, dass die Anzahl der Übergabepunkte nicht zwingend der Anzahl der Übergabepunkte für den physikalisch entbündelten Zugang entsprechen muss. 2. Generischer Zugang: Zugangsnachfragern werden service-agnostische Übertragungskapazitäten, d.h. garantierte Bandbreiten entsprechend ihren Bedürfnissen zur Verfügung gestellt. 3. Kontrolle über das Übertragungsnetz: Diese Kontrolle muss ausreichend sein, so dass die Zugangsnachfrager das Zugangsprodukt als funktionalen Ersatz für den entbündelten Zugang zur Teilnehmeranschlussleitung betrachten können und das Produkt in ähnlichem Maß Produktdifferenzierungen und Innovationen ermöglicht wie der entbündelte Zugang zur Teilnehmeranschlussleitung. Der Nachfrager soll außerdem in die Lage versetzt werden, Kontrolle über die Spezifika der Endkundenprodukte sowie die Gestaltung der unterschiedlichen Quality-of-Service Parameter auszuüben. Das Pflichtangebot der DNS:NET erfüllt diese Eigenschaften 1. Als lokaler Zugang dient die jeweils vorhandene zweite Schnittstelle am DSLAM mit 1Gbit/s oder 10Gbit/s. Bei mehr als einem Nachfrager wird dieser Schnittstelle ein Gateway nachgeschaltet, das die Verkehre entsprechend splitten kann. 2. Die Bandbreite ist ausschließlich auf die Bandbreite der Übergabeschnittstelle (1Gbit/s oder 10Gbit/s) begrenzt oder wird für den Einzelkunden bestimmt durch die dämpfungstechnischen Möglichkeiten der spezifischen TAL-Leitung.

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 4

3. Der Nachfrager wird für die Zugriffe auf die DSLAM‘s nach den Grundsätzen des Equivalence of Inputs so gestellt, wie die DNS:NET internen Abteilungen „Order Management“ und „Network Operations Center“. Darüber hinaus bietet die DNS:NET Nachfragern optionale Leistungen für ChangeManagement, Kollokation, Aggregation und zentrale Zuführung von Verkehren an Die in der Preisliste genannten Preise enthalten nicht die regulierten Preise einer CuTAL der Telekom und die mit den Bestellungen anfallenden Entgelte an die Telekom. Langfristig wird angestrebt, dass der Nachfrager für eine TAL-Bestellung auf einen DSLAM (MFG/MSAN) sein eigen TAL-Vertrag nutzen kann. Für den Fall, dass dies aufgrund des bestehenden TAL-Angebots der Telekom nicht möglich ist, bietet DNS:NET eine Mitnutzung des DNS:NET TAL-Vertrages an. Die Prozesse einer TAL-Bestellung werden dann mittels WEB-Client über die vorhandenen WITA/WBCI Schnittstellen realisiert. Sie werden in dem optional zu vereinbarten Anlage 7 beschrieben. Für den Fall, dass [KUNDE] Managed-Services, Spezialdienste, innovative Dienste oder ähnliches auf dem Zugangsnetz oder dem Aggregationsnetz plant, könnten Informationen zu Details wie Meldungsverkehren, Ausbauständen, DSL-Profilen, aus dem Bestandsnetz erforderlich sein. Sie werden nach tatsächlichem Bedarf der technischen Beschreibung zugefügt. Anlage 1: Anforderungsprofile von [KUNDE] an die Plattform Anlage 2: Ausbaustand / HW/SW (ggf. Qualitätsparameter der Netzkomponenten) BuGG Fallweise individuell erforderliche Detailinformationen. Anlage 3: Zugriff und Eindeutige Standort-ID der Multiplexer (DSLAM) BuGG Anlage 4: vorhandene DSL Profile auf den DSLAM’s BuGG Anlage 5: Einsetzbare und freigegebene VDSL Vectoringneutrale oder-fähige CPE’en BuGG Anlage 6: Forecast-Vereinbarung Anlage 7: Mitnutzung TAL-Vertrag der DNS:NET BuGG Optionale freiwillige Zusatzleistungen Anlage 8: Mitnutzung Aggregationsnetz (Quality of Service Concept) BuGG Standard Leistungen Anlage 9: Entstörung second level support, Eskalationen, Rechnungsstellung --individuelle Vereinbarungen--

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 5

1. Anbindungspunkte für VULA-Nachfrager im DNS:NET NGN Netz DNS:NET übergibt Endkundenanschlüsse als Layer2 Bitstream grundsätzlich an dem aus Sicht des Endkunden nächstliegenden Multiplexer-Element. Dies ist bei VDSL-Netzen grundsätzlich der DSLAM. DNS:NET stellt dem Nachfrager standardmäßig eine 1 GBit/s* Ethernet Schnittstelle an diesem Multiplexer zur Verfügung. Die Schnittstelle wird durch folgende Parameter beschrieben: Anschluss Schnittstelle VLAN-Konfiguration

1 GBit/s* Ethernet Singlemode Fiber ZX 802.1Q Trunk Port

Anmerkung *: Sofern technisch möglich auch 10GBit/s Der Nachfrager muss ein eigenes Glasfaserkabel in das Gehäuse bzw. den MultiplexerStandort der DNS:NET einführen. Dieses Kabel wird in einer DNS:NET Spleißbox abgeschlossen. In der Spleißbox werden grundsätzlich 4 Fasern je Nachfrager (1 Faserpaar aktiv + 1 Faserpaar als Störungsreserve) gespleißt. Übrige Fasern werden in der Spleißbox abgelegt. Die Fasern werden mit 1-4 bezeichnet, wobei die Fasern 1 und 2 das aktive Faserpaar beschreiben: Faser 1 2 3 4

Signalfluss Aktive Faser RX (DNS:NET Nachfrager) Reservefaser RX (DNS:NET Nachfrager)

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 6

2. Technische Spezifikationen des DNS:NET Layer2 Vorleistungsproduktes Layer 2 BSA VULA Mit L2-BSA realisiert die DNS:NET eine Zugangsmöglichkeit für Internet Service Provider (im Folgenden „Kunde“ genannt) mit eigenen IP Plattformen zur Anbindung ihrer Online-User, welche die Teilleistung L2-BSA der DNS:NET nutzen. Die Datenverkehre der Endkunden des Kunden (im Folgenden „Online-User“) werden über die L2-BSA Verbindungen lokal an der zweiten Schnittstelle des DSLAM oder alternativ zu einem Broadband Network Gateway (BNG) im Zugangsnetz der DNS:NET übertragen und über die dort angeschalteten L2-BSA-Übergabeanschlüsse an den Kunden übergeben. Layer 2 BSA Anschluss Die Leistung für einen Layer 2 BSA Anschluss umfasst die Bereitstellung und Überlassung eines breitbandigen Anschlusses im Gebäude eines Online-Users. Auf dieser technischen Basis kann der Kunde einen breitbandigen Internetzugang für einen OnlineKunden realisieren. Die DNS:NET stellt Layer 2 BSA auf Basis der VDSL Technologie in Ausbaugebieten der DNS:NET gemäß Hauptvertrag bereit. Die DNS:NET stellt dem Kunden die vertraglichen Leistungen nur bei bereits vorhandener und technisch aktiver Netzinfrastruktur der DNS:NET und bei Vorliegen einer Zugangsverpflichtung zur Verfügung. Ein Layer 2 BSA Anschluss besteht aus einer VDSL-Verbindung von der Anschalteeinrichtung beim Online-User bis zum DSLAM der DNS:NET. Anschalteeinrichtung beim Online-User ist der APL/TAL für den Übergabeanschluss die vereinbarte Schnittstelle 1GBit/s oder 10GBit/s. CPE und/oder Medienwandler sind nicht Lieferumfang.

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 7

3. Abgrenzung der Netzressourcen unterschiedlicher Nachfrager An die Multiplexer-Geräte der DNS:NET werden Teilnehmeranschlussleitungen unterschiedlicher Kunden angeschlossen, die unterschiedlichen Netzbetreibern (Nachfragern) zuzuordnen sind. Gleichzeitig handelt es sich bei den Multiplexern jedoch in der Regel nicht über „multi-tenant-Systeme“. Das bedeutet, dass Profile systemweit eine einheitliche ID haben müssen und auch die Anschlüsse systemweit durchnummeriert sind. In der Regel folgt die Nummerierung einem Chassis/Slot/Port Schema (z.B. 1/1/12). Jedoch ist dieses Schema abhängig vom eingesetzten Gerätetyp und kann von Standort zu Standort variieren. So kann auch ein Standort/Chassis/Slot/Port (z.B. 1/1/1/12) vorkommen. Um diese DNS:NET internen Bezeichnungen für den Nachfrager transparent zu gestalten, arbeitet DNS:NET für jeden Anschluss grundsätzlich mit einer Service-ID (kurz „SID“). Unter Verwendung dieser SID wird ein Port – also eine Teilnehmeranschlussleitung – im Netz der DNS:NET eindeutig beschrieben. Der Nachfrager erhält eine SID zusammen mit einem eindeutigen Passwort im Rahmen des Order-Prozesses zugeteilt.

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 8

4. Der Order-Prozess Mit dem Order-Prozess kann der Nachfrager einen Port an einem DNS:NET Multiplexer zugeteilt bekommen. Gleichwohl kann er einen nicht mehr benötigten Port kündigen.

Vorfall „Bestellung“ (neuen Port belegen) Mit dem API-Aufruf „new_sid“ wird dem Nachfrager ein bisher ungenutzter Port am Multiplexer der DNS:NET zugeteilt. Dem Nachfrager werden im Rahmen der Antwort auf den API-Aufruf weitere Parameter zum reservierten Port zur Verfügung gestellt. Aufruf: https:///vula_api.php?user=&pass=&action=new_sid&s ite_id=&descr=&customer= Parameter user pass site_id descr customer

Bedeutung Benutzerkennung des Nachfragers Passwort des Nachfragers Eindeutige Standort-ID des Multiplexers Beschreibung des Ports (Freitext) Kundennummer beim Nachfrager

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“: „error“: „site“: „device“: „loop“: „sid“: „sid_pass“:

„success“, „Fehlertext“, „3338.2.A010.000“, „3338.2.A010.01“, „K3338.2.A010.000.21K10123“, 12345, „Dke97R4h“

} Rückgabewert result error site device loop sid sid_pass Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error) Eindeutige Standort-ID des Multiplexers ID des DNS:NET Multiplexers Bezeichnung des Anschlusses an der Übergabeschnittstelle (z.B. Endverschluss bei Telekom TAL) Für den Port angelegte Service-ID Passwort für die spätere Ansteuerung des

Seite 9

Ports

Vorfall „Kündigung“ (Port kündigen) Mit dem API-Aufruf „delete_sid“ wird dem Nachfrager ein bisher ungenutzter Port am Multiplexer der DNS:NET entzogen. Dem Nachfrager werden im Rahmen der Antwort auf den API-Aufruf weitere Parameter zum reservierten Port zur Verfügung gestellt. Aufruf: https:///vula_api.php?action=delete_sid&sid=&sid_pass= Parameter sid sid_pass

Bedeutung Service-ID des Ports eindeutiges Passwort zur Service-ID

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“: „error“:

„success“, „Fehlertext“

} Rückgabewert result error

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error)

Seite 10

5. API zur Steuerung der eigenen Netzressourcen Grundsätzlich kann der Nachfrager die ihm zugeteilten Ports (SIDs) im Netz der DNS:NET selbst verwalten. Zu den möglichen Operationen zählen: 1. 2. 3. 4.

Provisionierung eines Ports (Profil einstellen) Aktivieren eines Ports Deaktivieren eines Ports Abfragen der Portstatistik

Die hierzu bereitgestellten API-Funktionen werden im Folgenden beschrieben:

5.1 Provisionieren eines Ports (Profil einstellen) Mit dem API-Aufruf „configure_sid“ wird ein zur SID gehörender Port konfiguriert, also mit einem Profil versehen. Ein Profil legt z.B. die dem Endkunden zur Verfügung stehende Bandbreite im Up- und Downstream fest. Profile müssen durch DNS:NET zunächst an jedem Multiplexer manuell angelegt werden, da ihre Parameter u.ä. vom eingesetzten Hersteller abhängig sind. Die Festlegung der Profile erfolgt im Rahmen der technischen Möglichkeiten in enger Abstimmung zwischen dem Nachfrager und DNS:NET. Das Anlegen neuer Profile erfolgt in der Regel Netzwelt und ist kostenpflichtig für den Nachfrager. Bereits vorhandene Profile sind in Anhang 1 zu dieser Anlage aufgelistet. Im Multiplexer angelegte Profile können daraufhin durch den Nachfrager selbst an einen Port (SID) gebunden werden. Hierzu muss der Nachfrager lediglich eine API-Funktion aufrufen. Aufruf: https:///vula_api.php?action=configure_sid&sid=&sid_pass=& profile= Parameter sid sid_pass profile

Bedeutung Service-ID des Ports eindeutiges Passwort zur Service-ID Bezeichnung des Profils (z.B. „auto-30/3“)

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“:

„success“,

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 11

„error“:

„Fehlertext“

} Rückgabewert result

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error)

error

5.2 Aktivieren eines Ports Mit dem API-Aufruf „activate_sid“ wird ein zur SID gehörender Port eingeschaltet. Aufruf: https:///vula_api.php?action=activate_sid&sid=&sid_pass= Parameter sid sid_pass

Bedeutung Service-ID des Ports eindeutiges Passwort zur Service-ID

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“: „error“:

„success“, „Fehlertext“

} Rückgabewert result error

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error)

5.3 Deaktivieren eines Ports Mit dem API-Aufruf „deactivate_sid“ wird ein zur SID gehörender Port abgeschaltet. Aufruf: https:///vula_api.php?action=deactivate_sid&sid=&sid_pass= Parameter sid sid_pass

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Bedeutung Service-ID des Ports eindeutiges Passwort zur Service-ID

Seite 12

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“: „error“:

„success“, „Fehlertext“

} Rückgabewert result error

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error)

5.4. Abfragen der Portstatistik Mit dem API-Aufruf „show_sid“ werden alle zur SID gehörenden Daten (inkl. Live-Daten des Multiplexers) abgefragt. Aufruf: https:///vula_api.php?action=show_sid&sid=&sid_pass= Parameter sid sid_pass

Bedeutung Service-ID des Ports eindeutiges Passwort zur Service-ID

Rückmeldung: Die Rückmeldung erfolgt in einem JSON-Format. Beispiel: { „result“: „success“, „error“: „Fehlertext“, „status“: „active“, „profile“: „auto-30/3“, „site“: „3338.2.A010.000“, „device“: „3338.2.A010.01“, „loop“: „K3338.2.A010.000.21K10123“, „history“: [ { „timestamp“: „2015-07-02 13:45:13“, „action“: „configure_sid profile=auto-30/3“ }, { „timestamp“: „2015-07-02 13:46:02“, „action“: „activate_sid“ } ], „vdsl_stats“: { Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 13

„status“: „activated“, „current_mode“: „G.993.5“, „trainings“: 2, „last_up_time“: „2015-07-20 18:16:41+02:00 DST“, „last_down_time“: „2015-07-20 18:13:04+02:00 DST“, „last_retrain“: „The CPE is disconnected“, „vendor“: „AVM“, „vendor_serial“: „C80E14555975 F!Box7360 124.06.20“, „down“: 44140, „up“: 4812, „attn_down“: 84320, „attn_up“: 37667, „snr_down“: 24.6, „snr_up“: 31.2, „vdsl2_profile“: „Profile17a“, „vectoring“: true, „bytes_up“: 231452747, „packets_up“: 1898437, „bytes_down“: 2798883316, „packets_down“: 2731417 }, „vlan_stats“: [ „untag“: { „bytes_up“: 231452747, „packets_up“: 1898437, „bytes_down“: 2798883316, „packets_down“: 2731417 }, „37“: { „bytes_up“: 0, „packets_up“: 0, „bytes_down“: 0, „packets_down“: 0 } ] } Rückgabewert result error ...

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Bedeutung success = Aktion erfolgreich error = Aktion nicht erfolgreich ein Fehlertext (nur bei result=error)

Seite 14

6. Sonderbauformen für Kollokation und dezentrale/zentrale Zuführung von Verkehren mit oder ohne Aggregation Sollte im Kontext eines Förderverfahrens oder einer Richtlinie die DNS:NET verpflichtet sein, Kollokation oder Zuführungsdienstleistungen zu erbringen, dann wird sie dies unter nachfolgenden Prämissen erfüllen:

6.1 Angebot über Kollokation Die DNS:NET wird die Realisierung der vom Kunden gewünschten Kollokation und des Bereitstellungstermins nach Zugang der vollständigen, schriftlichen Angebotsaufforderung unverzüglich prüfen. Die DNS:NET wird dem Kunden innerhalb von 20 Werktagen entweder ein schriftliches Angebot über die nachgefragte Kollokation unterbreiten oder mitteilen, dass aufgrund des Fehlens der örtlichen Möglichkeiten die weitere Behandlung der Angebotsaufforderung im Rahmen eines Nachweisverfahrens nach Ziffer 7 erfolgt. Soweit die Angebotserstellung das vorherige Einholen eines externen Angebotes über eine Teilleistung (z.B. von Energieversorgungsunternehmen) oder eines Sachverständigengutachtens (z.B. Statik) oder die Zustimmungserklärung Dritter (z.B. externer Vermieter) erfordert, wird die Frist zur Angebotserstellung für den Zeitraum ausgesetzt, der für das Einholen des externen Angebotes, des Gutachtens oder der Zustimmung durch Dritte benötigt wird. Die DNS:NET wird in diesem Fall dem Kunden über die Einholung von externen Angeboten, von Gutachten oder der Zustimmungserklärung Dritter informieren. In dem Angebot wird die DNS:NET entweder den vom Kunden gewünschten Bereitstellungstermin bestätigen oder einen anderen voraussichtlichen Bereitstellungstermin nennen, der innerhalb der verbindlichen Bereitstellungsfrist liegen muss. Ist der Kunde im Angebot zunächst nur ein voraussichtlicher Bereitstellungstermin genannt worden, wird die DNS:NET dem Kunde den verbindlichen Termin zur Abnahme, der ebenfalls innerhalb der verbindlichen Bereitstellungsfrist liegen muss, rechtzeitig, spätestens fünf Werktage vorher schriftlich per Telefax mitteilen. Mit dem Angebot wird die DNS:NET den mit der Sorgfalt eines ordentlichen Kaufmanns auf Basis marktüblicher Preise erstellten Kostenvoranschlag vorlegen. Sofern nach Beauftragung eine wesentliche Kostenerhöhung gegenüber dem Kostenvoranschlag erkennbar wird, wird die DNS:NET hierüber unverzüglich dem Kunden schriftlich unter Angabe der Gründe informieren. Der Kunde wird daraufhin unverzüglich der DNS:NET mitteilen, ob der Kunde aufgrund der wesentlichen Kostenerhöhung den Auftrag kündigt. Für die Richtigkeit des Kostenvoranschlags wird keine Gewähr übernommen. Die Vertragspartner sind sich darüber einig, dass eine wesentliche Kostenerhöhung in der Regel bei Überschreitung des Kostenvoranschlags um mehr als 10 % vorliegt. Für das Weiterführungskabel, das Fernkollokationskabel, das KollokationsFlächenverbindungskabel oder Zuführungskabel wird die DNS:NET bei Bedarf ein separates Angebot erstellen.

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 15

Preise Entgelte für die Angebotserstellung für die Bereitstellung von Kollokation und RLT Nach Zugang des Angebots über die Bereitstellung von Kollokation und RLT beim Kunden wird eine Abschlagszahlung in Höhe der im Angebot genannten Projektierungskosten und den Kosten für die Auftragsabwicklung und Fakturierung der Angebotserstellungsphase fällig. Solange der Kunde die Abschlagszahlung nicht erbracht hat, wird die DNS:NET ihre Leistung in Bezug auf die Bereitstellung von Kollokation verweigern. Die Abschlagszahlung ist innerhalb 14 Tagen zu erbringen, andernfalls ist die DNS:NET berechtigt, die Leistungsbeziehung über Kollokation bzw. RLT fristlos zu kündigen. Ob die Abschlagszahlung rechtzeitig erfolgte, richtet sich nach dem Zeitpunkt des Eingangs der Zahlung bei der DNS:NET. Eine gemeinsame Nutzung der an den Kunden überlassenen Kollokationsfläche ist nur mit Unternehmen, die mit dem Kunden im Sinne von § 15 AktG verbunden sind, zugelassen. Eine Weitervermietung ist unzulässig. Annahme des Angebotes Der Kunde wird innerhalb von 20 Werktagen nach Zugang des o.g. Angebotes das Angebot schriftlich annehmen. Anderenfalls gilt das Angebot als abgelehnt. Die Bereitstellung von Kollokation wird der Abnahme durch den Kunden abgeschlossen. Die Abnahme von Kollokation erfolgt mit einem Protokoll Kündigung durch den Kunden Die Kündigung der Kollokation hat schriftlich per Telefax bei dem Ansprechpartner, zuständigen Stelle der DNS:NET unter Einhaltung einer Kündigungsfrist von einem Jahr zum Ablauf eines Quartals zu erfolgen.

6.2 Angebot über dezentrale/zentrale Zuführung von Verkehren mit oder ohne Aggregation über das TK-Netz der DNS:NET Die DNS:NET wird die Realisierung der vom Kunden gewünschten Leistung und des gewünschten Bereitstellungstermins nach Zugang der vollständigen, schriftlichen Angebotsaufforderung unverzüglich prüfen. Es wird darauf hingewiesen, dass es ein Freiwillige Open Access Angebot der DNS:NET mit zentraler Zuführung in Berlin im Rechenzentrum Lützowstraße xx gibt. Es wird ausdrückliche empfohlen, dass eine Sonderlösung nur dann angefragt wird, wenn die dort aufgeführten Leistungsmerkmale unzureichend sind. Die DNS:NET wird dem Kunden innerhalb von 60 Werktagen entweder ein schriftliches Angebot über die nachgefragte Leistungen unterbreiten oder mitteilen, dass aufgrund des Fehlens der technisch betrieblichen Möglichkeiten die weitere Behandlung der Angebotsaufforderung im Rahmen eines Nachweisverfahrens nach Ziffer 6 erfolgt. Soweit die Angebotserstellung das vorherige Einholen eines externen Angebotes über eine Teilleistung (z.B. von Energieversorgungsunternehmen) oder eines Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 16

Sachverständigengutachtens (z.B. Machbarkeitsstudie) oder die Zustimmungserklärung Dritter (z.B. externer Lieferant von Glasfaserstrecken) erfordert, wird die Frist zur Angebotserstellung für den Zeitraum ausgesetzt, der für das Einholen des externen Angebotes, des Gutachtens oder der Zustimmung durch Dritte benötigt wird. Die DNS:NET wird in diesem Fall dem Kunden über die Einholung von externen Angeboten, von Gutachten oder der Zustimmungserklärung Dritter informieren. In dem Angebot wird die DNS:NET entweder den vom Kunden gewünschten Bereitstellungstermin bestätigen oder einen anderen voraussichtlichen Bereitstellungstermin nennen, der innerhalb der verbindlichen Bereitstellungsfrist liegen muss. Ist der Kunde im Angebot zunächst nur ein voraussichtlicher Bereitstellungstermin genannt worden, wird die DNS:NET dem Kunde den verbindlichen Termin zur Abnahme, der ebenfalls innerhalb der verbindlichen Bereitstellungsfrist liegen muss, rechtzeitig, spätestens fünf Werktage vorher schriftlich per Telefax mitteilen. Mit dem Angebot wird die DNS:NET den mit der Sorgfalt eines ordentlichen Kaufmanns auf Basis marktüblicher Preise erstellten Kostenvoranschlag vorlegen. Sofern nach Beauftragung eine wesentliche Kostenerhöhung gegenüber dem Kostenvoranschlag erkennbar wird, wird die DNS:NET hierüber unverzüglich dem Kunden schriftlich unter Angabe der Gründe informieren. Der Kunde wird daraufhin unverzüglich der DNS:NET mitteilen, ob der Kunde aufgrund der wesentlichen Kostenerhöhung den Auftrag kündigt. Für die Richtigkeit des Kostenvoranschlags wird keine Gewähr übernommen. Die Vertragspartner sind sich darüber einig, dass eine wesentliche Kostenerhöhung in der Regel bei Überschreitung des Kostenvoranschlags um mehr als 20 % vorliegt.

Annahme des Angebotes Der Kunde wird innerhalb von 20 Werktagen nach Zugang des o.g. Angebotes das Angebot schriftlich annehmen. Anderenfalls gilt das Angebot als abgelehnt. Die Bereitstellung der Leistung wird mit der Abnahme durch den Kunden abgeschlossen. Die Abnahme erfolgt mit einem Protokoll Mindestlaufzeit und Kündigung durch den Kunden Die Mindestlaufzeit für sonderbauformen von Netzdienstleitungen beträgt 48 Monate.. Die Kündigung der Leistung hat schriftlich per Telefax bei dem Ansprechpartner, zuständigen Stelle der DNS:NET unter Einhaltung einer Kündigungsfrist von einem Jahr zum Ablauf eines Quartals zu erfolgen.

6.3 Angebot über weitergehende Leistungsmerkmale des DNS:NET Netzes bei Mitnutzung Die DNS:NET wird die Realisierung der vom Kunden gewünschten Leistungsmerkmale und des gewünschten Bereitstellungstermins nach Zugang der vollständigen, schriftlichen Angebotsaufforderung prüfen. Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 17

Wenn diesem nichts entgegensteht, wird ohne Anerkennung einer Rechtspflicht ein Angebot erfolgen. Beispiel: MTU-Size Erhöhung. Erste Bedingung: es ist mit den eingesetzten Hard-/Softwarekomponenten . technisch möglich. Zweite Bedingung: es beeinträchtigt oder behindert keinerlei andere vorhandene oder geplante Anwendungen. Dritte Bedingung: es steht keinerlei gesetzlichen Vorschriften oder Richtlinien der Anforderung entgegen(z.B. Bestimmungen zur Netzneutralität).

7. Nachweisverfahren Für den Fall, dass ein Kunde Produkte oder/und Leistungsmerkmale nachfragt, die derzeit nicht von DNS:NET realisiert sind oder nicht Bestandteil des technischen Portfolio’s der DNS:NET sind, vereinbaren die Parteien ein mehrstufiges Nachweisverfahren. Dieses Nachweisverfahren steht unter dem Vorbehalt der technischen Realisierbarkeit und der Verpflichtung der DNS:NET zur Erbringung einer solchen Leistung. Nach Ablehnung einer Nachfrage des Kunden, kann Kunden die Durchführung der folgenden Schritte verlangen: • Stufe 1: Nur bei passiver Infrastruktur. Für den Kunden kostenpflichtige Begehung ob vor Ort ein Netz vorhanden ist, oder ein Leerrohr, oder eine freie Kollokationsfläche/-raum. • Stufe 2: DNS:NET wird für den Kunden kostenfrei innerhalb von 4 Wochen (für Netzdienstleistungen in Sonderbauformen 12 Wochen) eine Kostenabschätzung übermitteln. • Stufe 3: Nach Beauftragung durch den Kunden aufgrund der Kostenschätzung wird DNS:NET ein kostenpflichtiges Angebot erstellen. • Stufe 4: Annahme des Angebots durch den Kunden und Zahlung der im Angebot vereinbarten Vorab-Kosten. • Stufe 5: Realisierung des Nachgefragten Objekts bzw. Leistungsmerkmals durch DNS:NET. • Stufe 6: Abnahme des Nachgefragten Objekts bzw. Leistungsmerkmals durch den Kunden.

Technische Leistungsbeschreibung VULA Datum 20.04.2016 Version 1.4

Seite 18