Netzdatenbanken bei Telekommunikationsnetzbetreibern

Transkript

1 Netzdatenbanken bei Telekommunikationsnetzbetreibern Anspruch und Wirklichkeit Member of

2 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 1

3 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 2

4 Übersicht Datenbanken bei TK Netzbetreibern Kunden-Stammdaten Abrechnungsdaten Teilnehmerdaten des Netzes (HLR / HSS) Prozesse Standort-Daten Netztopologie-Daten Page 3 Betriebsdaten (FM, CM, PM, SM)

5 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 4

6 OSS Architektur Datensicht über das OSS Page 5

7 OSS Architektur New Generation Operations Systeme und Software Tele FORUM (TMF) Standard Rahmen für NGOSS Beschreibung TMF NGOSS Lean Operator Program Page 6 Business Process Framework [etom] [TAM] Applications Framework Quelle: Tele FORUM (TMF) NGOSS Technical Roadmap Enterprise wide Information Framework [SID] [TNA] System Integration Framework etom definiert alle wesentlichen Prozesse innerhalb eines Operators und an seinen externen Schnittetsllen SID beschreibt die Definition und Verwendung von Daten innerhalb des Operators TNA definiert, wie Applicationen, Daten und Processe flows innerhalb einer NGOSS Umgebung kommunizieren sollen TAM Definiert eine klare Zielarchitektur für Applikationen, zu denen ein Operator sich entwickeln kann oder den er neu aufbauen kann (Greenfield Ansatz)

8 OSS Architektur etom Modell des TM Forums Customer Strategy, Infrastructure & Product Operations Strategy & Commit Infrastructure Lifecycle Product Lifecycle Operations Support & Readiness Fulfillm ent Assurance Billing M arketing & Offer M anagem ent Customer Relationship Service Development & Service & Operations Resource Development & (Application, Computing and Network) Resource & Operations (Application, Computing and Network) Supply Chain Development & Supplier/Partner Relationship Enterprise Strategic & Enterprise Planning Page 7 Financial & Asset Enterprise Risk Stakeholder & External Relations Enterprise Effectiveness Human Resources Knowledge & Research

9 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 8

10 Standortdaten Inhalt und Verwendung Die Konsistenz der Standortdatenbank und die Anbindung an das Network Inventory sind eine Herausforderung für den Netzbetreiber. Ein GIS ist äußerst wichtig. Site ID Adresse Koordinaten Objekt-Zugang Standortdaten Mietleitungen Gebäudepläne Fotos Kaufm. Verwaltung Technik-Daten Gerätetypen Baugruppen SW/FW Stände Konfigurationsdaten Mietvertrag Beschaltung Strom-Vertrag Inventarlisten Page 9 Planungssicht SOLL Stand Geräte-Typ und -anzahl Stücklisten AFA-Daten Mobiliar sonstige Einrichtung Betriebssicht IST Stand

11 Standortdaten Theorie und Praxis Insbesondere nach Fusionen herrscht oft ein undurchschaubares Wirrwarr an Standortdaten, das die Zuverlässigkeit des Betriebes lähmen kann Ziel Ist-Stand Zentralisierte Datenbestände im Online-Zugriff Klare Definition und Pflege der Zugriffsrechte Betrieb und Planung haben die selbe Sicht auf die Daten Unterschiedliche Planungsstände sind eingepflegt Netzplaner können durch Zugriff auf Fotos und Zeichnungen ein Bild von den Standorten bekommen Servicetechniker können vor der Fahrt zum Standort ihren Auftrag mit den Gegebenheiten vor Ort vergleichen (Material, Werkzeug, Zugang zum Standort etc) Die Abrechnung der Kosten und die Abschreibung der Technik-Investition lassen sich sauber zuordnen Page 10 Planung und Betrieb verwenden unterschiedliche Daten Standortnamen, Koordinaten und die aufgestellte Technik weichen voneinander ab Die Datenbestände werden bei verschiedenen Personen auf dem PC lokal gepflegt Verschiedene Datenmodelle verhindern eine Zusammenführung der einzelnen Datenbestände Oft ist nicht herauszufinden, welche Kunden oder Systeme beim Ausfall einer Verbindung betroffen sein werden. Überraschungen bei Wartungsarbeiten sind vorprogrammiert. Einführung eines integrierten Network Inventory nötig

12 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 11

13 Network Inventory in der OSS Architektur Assurance Processes - Problem & Performance End to End Customer Prozess Customer Interface Marketing & Sales Order Handling Customer Problem Handling Customer QoS /SLA Billing & Collections Page 12 Service Configuration & Activation Resource Provisioning Inventory Service Problem Managemt. Resource Trouble Managemt. Customer Process Service Quality Managemt. Resource Performance Resources, Network Elements & Service Applications Service & Specific Instance Rating Reporting / Data Warehouse Resource Data Collection & Processing Billing Data Mediation

14 Network Inventory in der OSS Architektur Help Desk Customer Interface TMF SID Datenmodel Order Handling Service Configuration Customer Problem Handling Service Problem Managemt. weitere Instanzen erfüllt Modul-übergreifende Aufgaben Workflow Inventory erfüllt Modul- übergreifende Aufgaben Trouble Ticket System Fault Impact Server (Correlation) Reporting Network Operation Center direkte Schnittstellen Resource Provisioning Object Server (Ressource Monitoring) Trouble Ticket Daten Resource Activation Performance Supplier / Partner Daten Polling Fernwartung EM Element Manager SM Service Manager Page 13 Konfigurations- Daten & Quittierung oder SNMP SM Events Events S/P Events Performance Daten Probe Probe Probe Probe Network Resources, Network Elements & Service Applikations Polling SNMP SNMP SNMP SNMP SNMP EM EM EM EM SNMP Fernwartung Kommandos & Quittierung SSH

15 Network Inventory - Umsetzung Methodik zur Umsetzung OSS-Konsolidierungsprojekte haben drei Dimensionen: Fachliche Anforderungen an die OSS, Aspekte der Datenmodelle sowie Betriebsprozesse. Erstellung des einheitlichen Datenmodells OSS Analyse, Konzepterstellung und Ausschreibung Umsetzung Prozessdesign Einführung der Prozesse Aufgabenverteilung definieren Zugriffsrechte einzelnen MA und Abteilungen etc Page 14

16 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 15

17 Dienstprofil-Daten Einführung zentralisierter Wirknetzdatenbanken Traditionell haben HLR, VAS und IN-Systeme getrennte Datenbanken, die untereinander verknüpft sind. Mit fas jedem neuen Dienst steigen die Komplexität und Anfälligkeit. Traditioneller Dienste- Ansatz Kundenorientierter Ansatz Data Provisioning System Data Provisioning System Data Logic Logic Logic Logic Data Page 16 Data Data Data Neuer Dienst Logic Logic Logic Logic Neuer Dienst

18 Dienstprofil-Daten Konsolidierte Datenlandschaft Die Profil-Datenbank kommuniziert in Real-Time mit den Anwendungen über Directory Services Ablösung der alten HLR s spart OPEX Provisionierung System Moderne Datenbanken lassen sich hochverfügbar, performant und redundant aufbauen. Vereinfachte Einführung neuer Dienste ohne Verknüpfung mit bestehenden Diensten BSS Profil- DB Directory Services OSS Directory Kunden-Anwendungen Page 17 NG HLR HSS MMSC MNP Voice mail Core Signalling Network IN andere

19 Inhalt 1. Übersicht 2. OSS Architektur 3. Standortdaten 4. Network Inventory in der OSS Architektur 5. Dienstprofil-Daten 6. Zusammenfassung Page 18

20 Zusammenfassung Ausblick Eine Zentralisierung der Datensicht in verschiedenen Bereichen des Wirk- und Support-Netzes ist zwingend erforderlich, um die Geschäftsprozesse konsistent zu halten und die Zuverlässigkeit der Dienste und Abläufe im Unternehmen zu gewährleisten. Die schrittweise Migration von CS zu IP basierten Netzen sollte zum Anlass genommen werden, auch die dazugehörigen OSS Systeme sukzessive zu NGOSS zu entwickeln. Die zentrale Haltung aller Netzwerkdaten in einer einzigen Datenbank wird durch ihre hohe Komplexität in ihrer Machbarkeit beschränkt, jedoch sollten alle Systeme für die relevanten Anwender online verfügbar sein Die Ablösung alter HLR s durch neue DB-Systeme ermöglicht im Wirknetzbetrieb eine Zentralisierung der Profil-Daten, die eine erhebliche Erleichterung in der Realisierung neuer Dienste und erhebliche Kosteneinsparungen bringt. Organisatorische Veränderungen wie Firmenübernahmen und Outsourcing von Betriebsaufgaben sollten als Chance genutzt werden, veraltete Systeme durch zentralisierte Datenbanken abzulösen. Die Veränderung der Daten-Architektur geht in der Regel mit Änderungen in Prozessen und Zuständigkeiten im Unternehmen einher. Diese sind meist nur mit Hilfe von externen Kräften umzusetzen, da sie immer von Positionskämpfen und Machtansprüchen einzelner Mitarbeiter überschattet werden. Page 19

21 Kontakt Vielen Dank für Ihre Aufmerksamkeit Mathias Hoder Managing Partner Detecon International GmbH Oberkasseler Str Bonn (Germany) Phone Fax Mobile Mathias.Hoder@detecon.com Integrierte - und Technologieberatung weltweit Page 20