amtsblatt-24
Dieses Dokument ist Teil der Anfrage „Amtsblätter bis 2018“
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
24 2017 – Regulierung, Telekommunikation – 3639
Das folgende Beispiel soll verdeutlichen, wie historische Kundendaten zu beauskunften sind. Das
Beispiel geht von einem noch nicht beendeten Vertragsverhältnis aus, wobei die Kundendaten durch
Umzug oder Rufnummernwechsel geändert wurden.
Abbildung 7: Beispiel Kundendatensatz
Abfrage Abfragedaten Antwortdaten
Nr.
1 Rufnummer: 0160 1234567 Beispieldatensatz 1
Ermittlungsrelevanter Stichtag: 18.02.2011
2 Rufnummer: 0160 1234567 Beispieldatensatz 1 und 2
Ermittlungsrelevanter Zeitraum: 18.6.2012-01.08.2012
3 Vorname: Max Kein Treffer
Nachname: Mustermann
Straße: Wittelsbacherstr.
Hausnummer: 140
PLZ: DE-50321
Ort: Brühl
Ermittlungsrelevanter Stichtag: 18.02.2011
4 Vorname: Max Beispiel-Datensatz 2 und 3
Nachname: Mustermann
Straße: Wittelsbacherstr.
Hausnummer: 140
PLZ: DE-50321
Ort: Brühl
Ermittlungsrelevanter Zeitraum: 15.09.2012-06.01.2016
5 Rufnummer: 0160 1234567 Kein Treffer (Wenn Ruf-
Ermittlungsrelevanter Stichtag: - nummer wieder an anderen
Kunden vergeben wurde, dann
ist dieser zu Beauskunften)
6 Rufnummer: 0160 7654321 Beispiel-Datensatz 3
Ermittlungsrelevanter Stichtag: -
Tabelle 27: Beispielabfragen für historische Kundendaten
Bei bereits beendeten Vertragsverhältnissen gilt § 111 Absatz 5 TKG entsprechend. In diesen Fällen
wäre dann dem jeweiligen historischen Datensatz (siehe oben Beispiel-Datensatz 1 - 3) das Datum
des Vertragsendes hinzuzufügen.
47
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
3640 – Regulierung, Telekommunikation – 24 2017
3.5 Datenaustausch bei Antwort
3.5.1 Metadaten der Antwort
Folgende Metadaten müssen in einer Antwort übertragen werden:
die Versionsangabe (hier „TR1.0“),
die Vorgangskennung im AAV
die Kennung der Abfragestelle der Bundesnetzagentur
die EAZ-Klasse der Abfrage
die Anzahl der Suchtreffer
die Mandantenkennung innerhalb eines Mehrmandantensystems eines verpflichteten Unter-
nehmens
Die Felder für die Metadaten der Antwort sind in Anlage 04 genauer beschrieben.
3.5.2 Inhaltsdaten der Antwort
Bei der Antwort können folgende Angaben übertragen werden, deren Syntax in der WSDL-Datei
beschrieben ist:
Rufnummer
Vorname
Nachname
Geburtsdatum
Straße
Hausnummer
Postleitzahl
Ort
Straße (Anschluss)
Hausnummer (Anschluss)
Postleitzahl (Anschluss)
Ort (Anschluss)
E-Mail-Adressen (wenn diese vom Verpflichteten selbst vergeben wurden)
Gerätenummer des Mobilfunkendgeräts
Andere Anschlusskennungen
Vertragszeitraum (Vertragsbeginn, Vertragsende)
Vertragsänderung
Verweistyp (Provider- oder Portierungsverweis)
Rufnummern werden in der Antwort so zurückzuliefert, wie in Kapitel 3.3.2 vorgegeben.
Wenn eine Rufnummer an einen Provider oder Reseller abgeleitet zugeteilt wurde und daher beim
originären Netzbetreiber keine Kundendaten zur Verfügung stehen, muss in der Antwort des
Verpflichteten auf die Abfrage nach dieser Rufnummer im Datenfeld „Verweistyp“ (siehe Anlage
04.2) eine 1 zurückgeliefert werden. In das Datenfeld für Nachname muss der dem Provider zuge-
ordnete International Carrier Code (ICC) oder, falls dieser nicht bekannt ist, der Providername oder
die Portierungskennung des Providers eingetragen werden. Der ICC ist eine standardisierte Kennung
nach der Empfehlung M.1400 der Internationalen Fernmeldeunion (ITU). Eine Liste der in
48
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
24 2017 – Regulierung, Telekommunikation – 3641
Deutschland notifizierten ICC findet sich auf der Website der ITU. Die Verwendung des ICC ist nur
zulässig, wenn auf eine rufnummernbasierte Abfrage geantwortet wird.
Bei portierten Rufnummern wird im Datenfeld „Verweistyp“ eine 2 zurück geliefert, wenn die dem
Zuteilungsnehmer zugeteilte Rufnummer zu einem anderen Netzbetreiber portiert wurde. Im
Datenfeld für Nachname muss dann die Portierungskennung (Dxxx) des zuletzt bekannten
Netzbetreibers der Rufnummer eingetragen werden. Ein regelmäßig aktualisiertes Verzeichnis der
zugeteilten Portierungskennungen kann auf der Website der Bundesnetzagentur eingesehen werden.
Als Grundlage für die Erfassung in den Datenbanken der Verpflichteten wird die Schreibweise des
Wohnortes bzw. des Ortes des Anschlusses und der Straße gemäß dem DataFactory Streetcode der
Deutschen Post AG empfohlen.
Postleitzahlen sind immer mit vorangestelltem Ländercode gemäß DIN EN ISO 3166-1 und einem
darauffolgenden Bindestrich „-“ zu bilden und auch entsprechend bei der Suche auszuwerten, dies
gilt auch für deutsche oder österreichische Postleitzahlen (Beispiel: „DE-55152“, „AT-1234“). Bei
Ländern ohne Postleitzahlen ist nur der Ländercode zurück zu liefern.
49
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
3642 – Regulierung, Telekommunikation – 24 2017
4. Zeichensatz
Die Koordinierungsstelle für IT-Standards in der öffentlichen Verwaltung (KoSIT) empfiehlt, in allen
IT-Verfahren den international anerkannten Standard UNICODE für den Zeichensatz einzusetzen. Da
es nicht angemessen ist, alle bekannten Schriftzeichen umzusetzen, wird empfohlen, alle IT-Verfah-
ren auf Zeichen zu beschränken, die auf den lateinischen Grundbuchstaben basieren.
Dieser Empfehlung folg die Bundesnetzagentur und legt für das automatisierte Auskunftverfahren
den Zeichensatz „Lateinische Zeichen in UNICODE“ („String.Latin“) in Version V1.1.1 fest. Dies gilt für
alle Verfahrensteilnehmer (ersuchende Stellen und verpflichtete Unternehmen).
Die vollständige Spezifikation wird auf der Website der KoSIT (http://www.xoev.de) kostenfrei und
uneingeschränkt zur Nutzung bereitgestellt. Diese Zeichensatz-Definition ist auch in die WSDL-Datei
zur Webservice-Anbindung der ersuchenden Stellen und verpflichteten Unternehmen integriert.
Andere als die dort definierten Zeichen sind nicht zulässig.
Für die zu verwendende Kodierung wird UTF-8 vorgegeben.
Den Zeichen „*“, „?“, „[„ und „]“ kommt in Ersuchen und Abfragen eine besondere Bedeutung bei
der Suche mittels Platzhaltern zu. Soll eines dieser Zeichen zur Suche in einer Namensangabe in
seiner ursprünglichen Bedeutung eingesetzt werden, so muss es durch das vorangestellte Zeichen „\“
(Escape-Zeichen bzw. Maskierungszeichen) gekennzeichnet werden. Soll das Escape-Zeichen in
seiner ursprünglichen Bedeutung verwendet werden, so ist es aufzudoppeln („\\“).
Dies gilt nur für die Übermittlung von Ersuchen und Abfragen. Die Verpflichtetensysteme müssen die
Sonderzeichen inkl. eventueller Escape-Zeichen wie oben beschrieben interpretieren. In Antworten
und Ergebnissen werden die Daten wie in der Bestandsdatenbank des Verpflichteten hinterlegt
übergeben.
Die Systeme der ersuchenden Stellen sollten die Erfassung der o.g. Zeichen in ihrer jeweils inten-
dierten Bedeutung geeignet unterstützen.
50
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
24 2017 – Regulierung, Telekommunikation – 3643
5. Normalisierung in Verpflichteten-Datenbanken
Dieser Abschnitt ist für ersuchende Stellen rein informativ, da es Aufgabe der Verpflichteten-
Software ist, eine Normalisierung der Bestandsdaten für Suchzwecke durchzuführen.
Um die Trefferidentifikation erfasster Datensätze zu gewährleisten, ist neben der exakten Zeichen-
folge einer Eingabe (Vorname, Nachname, Anschrift) auch die transliterierte Suchform zu erzeugen
und gegebenenfalls zu speichern. Die Suche hat unabhängig von der Groß- und Kleinschreibung zu
erfolgen. Die Umsetzung von Zeichenketten über dem Zeichensatz String.Latin in eine Suchform,
bestehend aus Großbuchstaben, Ziffern und Sonderzeichen und ist in folgendem Dokument
festgelegt:
„Umstellung auf Lateinische Zeichen in Unicode – Vorgaben für Identifikationsverfahren“
Abschlussbericht
Fassung vom 17. 1. 2012
Projektgruppe Standard des AK / Der Innenministerkonferenz
Maßgeblich ist die Spalte „Suchform“ in Anhang B - Umsetzungstabelle. Das Dokument ist ebenfalls
auf der Website der KoSIT (http://www.xoev.de) zu finden.
Dabei sind nur Zeichen der Unicode-Kategorie NUMBER und LETTER zu berücksichtigen. Alle anderen
Zeichen sind bei der Bildung der Suchform zu ignorieren.
Die Platzhalter-Zeichen „*“, „?“, „[“ und „]“ sind bei der Suche gemäß ihrer oben beschriebenen
Funktion (Kapitel 2.3.3.4) gesondert zu interpretieren.
Bei Straßennamen sind folgende Zeichenfolgen als gleichwertig anzusehen:
Ausgeschrieben Abgekürzt
Straße Str
Platz Pl
Tabelle 28: Gleichwertige Zeichenfolgen im Feld Straße
Akademische Titel, Adelstitel oder sonstige Namenszusätze dürfen bei der Suche nicht
berücksichtigt werden. Soweit sie in den Kundendaten erfasst wurden, sind sie jedoch in der Antwort
in den entsprechenden Feldern zurückzuliefern. Gleiches gilt für die Rechtsformen bei Firmennamen.
Anlage 05 listet alle Namenszusätze auf, welche bei der Suche nicht berücksichtigt werden dürfen.
Die Antwort ist angereichert (String.Latin) zurückzugeben, obwohl normalisiert gesucht wird. Z. B. bei
Suche nach „Müller“ muss „Müller“ zurückgegeben werden (falls sich der Kunde mit Umlaut
schreibt), obwohl mit „MUELLER“ gesucht wird.
Nachfolgend sind die Schritte zur empfohlenen Normalisierung von Namensangaben nochmals
zusammenfassend dargestellt:
1. Eliminierung zu ignorierender Zeichen.
2. Verarmung gemäß Umsetzungstabelle im Dokument „Umstellung auf Lateinische Zeichen in
Unicode – Vorgaben für Identifikationsverfahren“ (s.o.), dies beinhaltet bereits die Transfor-
mation in Großbuchstaben.
3. Vereinheitlichung bei Straßennamen (Tabelle 28)
4. Eliminierung von Namenszusätzen und Rechtsformen bei Firmennamen
51
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
3644 – Regulierung, Telekommunikation – 24 2017
Basierend auf der so gebildeten Suchform kann die phonetische Form gebildet werden:
5. Bildung einer phonetischen Form (Kapitel 6)
Beispiele anhand des Nachnamens:
Ausgangsform Suchform Phonetische Form
(glz. zu beauskunftende Form) (nach Schritt 4) (nach Schritt 5)
Möller-Spargël MOELLERSPARGEL 65781745
@Online Service GmbH ONLINESERVICE 06568738
Ola! Import/Export OLAIMPORTEXPORT 05617248172
Aktiengesellschaft
Tabelle 29: Normalisierung Beispiel Nachname
Praktischerweise sollten die Systeme der Verpflichteten für jede in Frage kommende Angabe
zusätzlich eine Suchform und ggf. eine phonetische Form abspeichern. Die Bildung der phonetischen
Form wird im nachfolgenden Kapitel beschrieben.
52
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
24 2017 – Regulierung, Telekommunikation – 3645
6. Kölner Phonetik
Auf der Grundlage von § 5 Absatz 1 Satz 3 KDAV wird die sog. Kölner Phonetik als sprachwissen-
schaftliches Verfahren für die Suche mittels Ähnlichenfunktion vorgegeben. Ziel dieses Verfahrens ist
es, die Trefferwahrscheinlichkeit dadurch zu erhöhen, dass gleich oder ähnlich klingenden Wörtern
derselbe phonetische Code zugeordnet wird, um bei Suchfunktionen eine Ähnlichkeitssuche zu
implementieren. Die Kölner Phonetik ist ein an die Deutsche Sprache angepasster Algorithmus zur
Indizierung von Wörtern bei der Suche in Personendatenbanken. Dabei werden durch lediglich ca. 25
Regeln Buchstaben je nach Kontext in eine Ziffer von 0 bis 8 kodiert.5
Zur Bildung des Phonetischen Codes werden nur Buchstaben in bereits normalisierten Namens- und
Adressfeldern herangezogen. Ziffern und Sonderzeichen werden ignoriert. Eine phonetische Suche
muss in den Feldern Vorname und Nachname, Straße oder Wohnort möglich sein.
Die Umwandlung eines Wortes in den phonetischen Code erfolgt in drei Schritten:
1. Buchstabenweise Kodierung von links nach rechts entsprechend der Umwandlungstabelle.
2. Entfernen aller mehrfach nebeneinander vorkommenden Ziffern.
3. Entfernen aller Codes „0“ außer am Anfang.
Für die Phonetische Suche des AAV ist die korrigierte Kodierungstabelle nach Hain und Jokisch zu
verwenden, welche auch das isolierte Wort „H“ berücksichtigt.
Buchstabe Kontext Code
A, E, I, J, O, U, Y
0
ohne Kontext (isoliertes Wort H)
H Mit beliebigem Kontext -
(leer)
B
1
P nicht vor H
D, T nicht vor C, S, Z 2
F, V, W
3
P vor H
G, K, Q
im Anlaut vor A, H, K, L, O, Q, R, U, X 4
C
vor A, H, K, O, Q, U, X außer nach S, Z
X nicht nach C, K, Q 48
L 5
M, N 6
R 7
S, Z
nach S, Z
C im Anlaut außer vor A, H, K, L, O, Q, R, U, X
8
nicht vor A, H, K, O, Q, U, X
D, T vor C, S, Z
X nach C, K, Q
6
Tabelle 30: Kölner Phonetik; Umwandlungstabelle nach Hain u. Jokisch
5
Vgl. Jokisch, O., Hain, H-U. (2017), S. 9 ff.
6
Vgl. Jokisch, O., Hain, H-U. (2017), S. 16
53
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
3646 – Regulierung, Telekommunikation – 24 2017
7. Funktionstests und Datenqualität
Vor Kontaktaufnahme mit der Bundesnetzagentur bei technischen Problemen hat der Verfahrens-
teilnehmer dafür zu sorgen, soweit wie möglich zu versuchen, selbständig Störungen zu beseitigen.
7.1 Tests mit ersuchenden Stellen
Funktionstests können nur mit Begleitung der Bundesnetzagentur und nach Rücksprache durchge-
führt werden. Tests mit den Systemen der Bundesnetzagentur, außerhalb der Geschäftszeiten sind
nicht möglich. Es besteht kein Anspruch auf permanente Verfügbarkeit und Inanspruchnahme der
Testsysteme der Bundesnetzagentur.
Eine Freigabe von neuen oder geänderten Systemen für den Wirkbetrieb darf nur nach erfolgreichem
Abschluss der Testphase erfolgen. In der Testphase können nur Testdatensätze aus internen Tabellen
des für die Tests speziell vorbereiteten Webservice-Testservers abgefragt werden. Diese Test-
Ersuchen werden nicht an Verpflichtete weitergeleitet. Alle Zugriffe werden protokolliert.
Die Funktionstests mit den ersuchenden Stellen umfassen folgende Schritte:
Ping-Befehle
Statusabfragen der SINA-Boxen
Verbindungsaufbau zwischen Bundesnetzagentur und ersuchenden Stellen
Prüfung der Funktionalität des beschriebenen Webservice
Netzwerkprotokoll-Analyse
Nach erfolgreichem Aufbau der TCP- und TLS-Verbindungen vom System der ersuchenden Stelle zum
AAV-Teststandort wird von Seiten der Bundesnetzagentur ein Mitschnitt des Netzwerkverkehrs
erstellt. In diesem Mitschnitt dürfen keinerlei Fehler oder Auffälligkeiten zu sehen sein (Fehler sind
z. B. RST Pakete, auffällige Retransmissions, bzw. Reordering der Pakete, problematische TCP- oder
HTTP-Header-Parameter, nicht zum AAV gehörender Netzwerkverkehr, usw.).
Jede ersuchende Stelle ist, insbesondere beim erstmaligen Einsatz neu erstellter Software oder nach
Softwareänderungen dazu verpflichtet, auf Anforderung unverzüglich einen clientseitigen Mitschnitt
des Netzwerkverkehrs im PCAP-Format und das Anwendungsprotokoll seiner lokalen Infrastruktur
für das automatisierte Auskunftsverfahren an die Bundesnetzagentur zur Fehlersuche zu senden.
Dabei ist ein sicherer Übertragungsweg zu verwenden.
Um Portierungen in den Tests simulieren zu können, wurden vier Test-Verpflichtete (TVxx) mit den
folgenden Anbieterkennungen (Pxxx), Testrufnummern und Bestandsdaten in internen Tabellen der
Bundesnetzagentur hinterlegt:
Laufende Nummer TV01/P991 TV02/P992 TV03/P993 TV04/P994
03120100 03120200 03120300 03120400
1
03120101
03120102 03120201 03120301 03120401
2
03120103 03120202 03120302 03120402
3
03120203
03120204
54
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
24 2017 – Regulierung, Telekommunikation – 3647
03120104 03120205 03120303 03120403
4
03120403 <=portiert <=portiert
03120105 03120206 03120304 03120404
5
03120106 03120207 03120305 03120405
6
03120107 03120208 03120306 03120406
7
portiert=> 03120306
03120108 03120209 03120307 03120407
8
03120109 03120210 03120308 03120408
9
Verweis=> 03120109
03120110 03120211 03120309 03120409
10
Tabelle 31: Anbieterkennungen und Rufnummern für Funktionstests
55
Bonn, 20. Dezember 2017
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
3648 – Regulierung, Telekommunikation – 24 2017
7.2 Tests mit verpflichteten Unternehmen
Funktionstests können nur mit Begleitung der Bundesnetzagentur und nach Rücksprache durchge-
führt werden. Tests mit den Systemen der Bundesnetzagentur, außerhalb der Geschäftszeiten sind
nicht möglich. Es besteht kein Anspruch auf permanente Verfügbarkeit und Inanspruchnahme der
Testsysteme der Bundesnetzagentur.
Die Funktionstests mit den verpflichteten Unternehmen können folgende Schritte umfassen:
Ping-Befehle
Statusabfragen der SINA-Boxen
Verbindungsaufbau zwischen Bundesnetzagentur und Verpflichtetem
Prüfung der Funktionalität des beschriebenen Webservice
Netzwerkprotokoll-Analyse
Versenden von Testabfragen zu Testdatensätzen durch die Bundesnetzagentur (siehe unten).
Diese können einzeln oder in verschieden großen Gruppen zusammengefasst werden, um
Lasttests zu ermöglichen.
Nach erfolgreichem Aufbau der TCP- und TLS-Verbindungen mit dem AAV-Teststandort wird von
Seiten der Bundesnetzagentur ein Mitschnitt des Netzwerkverkehrs erstellt. In diesem Mitschnitt
dürfen keinerlei Fehler oder Auffälligkeiten zu sehen sein (Fehler sind z. B. RST Pakete, auffällige
Retransmissions, bzw. Reordering der Pakete, problematische TCP- oder HTTP-Header-Parameter,
nicht zum AAV gehörender Netzwerkverkehr, usw.).
Jedes verpflichtete Unternehmen ist, insbesondere beim erstmaligen Einsatz neu erstellter Software
oder nach Softwareänderungen dazu verpflichtet, auf Anforderung unverzüglich einen clientseitigen
Mitschnitt des Netzwerkverkehrs im PCAP-Format und das Anwendungsprotokoll seiner lokalen
Infrastruktur für das automatisierte Auskunftsverfahren an die Bundesnetzagentur zur Fehlersuche
zu senden. Dabei ist ein sicherer Übertragungsweg zu verwenden.
Für die Funktionstests sind 10 Rufnummern aus dem Kontingent des Verpflichteten bereitzustellen,
die dauerhaft in seiner Datenbank gemäß § 112 TKG zu speichern sind. Diese Rufnummern dürfen
weder geändert noch anderweitig genutzt werden. Die zugehörigen Testdatensätze mit den Kunden-
daten nach Tabelle 32, sind in die Systeme der Verpflichteten zu übernehmen und mit der jeweiligen
Rufnummern der Bundesnetzagentur mitzuteilen.
Ruf- Haus-
num num-
-mer Nachname Vorname PLZ Ort Straße mer
1 @Online Services 80992 München Mülheimer Str. 71
<=email Provider>
2 Ola! Import\Export 80992 München Mülheimer Str. 4
Abt: Lebensmittel
3 Wall-Street $-Company 80992 München Mülheimer Str. 10
{Aktienkurse}
4 ¥ Yen Japanische 80992 München Refrather Weg 66
Küche
5 Spargël Anni 80992 München Britanniahütte 122
6 µ-Systems µ-Saft- 80992 München Refrather Weg 219
Applikationen
7 Mustermannky Ûrwig 80992 München Josef-Roemer-Str. 127
56
Bonn, 20. Dezember 2017
