10 JAHRE VFG.168/99
Dipl.-Ing. Helmut Kropp
10 Jahre Vfg.168/99 - Verbindungspreisberechnung
Dipl.-Ing. H. Kropp
Seit 1999 gilt die "Vfg.168/99" als technische Anleitung f�r die Erstellung der Gutachten zur Verbindungspreisberechnung. Der Sachverst�ndige hat es leicht: er muss nicht (und soll auch nicht) etwas zur Verbindungspreisberechnung erfinden, der Rahmen f�r sein Gutachten wird ihm durch die Verf�gung vorgegeben.
In der Vfg.168/99 der RegTP sind festgelegt die Anforderungen
Im folgenden sollen Erfahrungen mit der Begutachtung von gro�en und kleinen Netzbetreibern von Fest- und Mobilfunknetzen nach dieser Vfg. kurz dargestellt werden.
a) Zeiterfassungsgenauigkeit (3.1 Techn.Anf.)
Da sollen die Zeitpunkte von Verbindungsbeginn und Verbindungsende mit 500 ms Genauigkeit erfasst werden. Das hat im Anfang vielen Netzbetreibern Probleme bereitet, die am Markt befindlichen Systeme waren auf eine Granularit�t von 1 s eingestellt. Erst langsam im Laufe der Jahre seit 1999 hat sich das ge�ndert, die Software wurde umgestellt und meist konnte dann eine Granularit�t von 0,1 s angeboten werden, womit sich die Anforderungen an die Zeiterfassungsgenauigkeit erf�llen lie�en.
Allerdings hat sich auch die Frage gestellt: was machen Mobilfunknetze? Wenn die Mobilstation z. B. in einen Tunnel einf�hrt, ist das Gespr�ch darin nicht m�glich. Die Netzbetreiber halten jedoch in diesen F�llen die Verbindung noch etwa 10 s bis 15 s lang. Ist die Unterbrechung nicht l�nger, kann die Mobilstation das Gespr�ch fortsetzen, ohne sich neu einzuw�hlen. Ist die Unterbrechung aber l�nger, kommt diese "Haltezeit" zur Verbindungsdauer dazu. Frage: wo bleibt da die 500 ms-Genauigkeit? Diese gilt offenbar nur f�r Festnetze.
Kaum ein Netzbetreiber erfasst Beginn- und Endezeit. Meist wird die Beginnzeit und die Dauer der Verbindung (diese direkt, zumeist mit einem "Counter") erfasst, die Endezeit k�nnte man sich daraus herausrechnen.
Gedacht war es aber anders, n�mlich die Verbindungszeit als Differenz von Ende- minus Anfangszeit zu bestimmen. Die Verbindungszeit sollte auf 1 s genau sein, also teilte man diese Genauigkeitsforderung in zwei Teile, einmal 500 ms am Anfang, einmal 500 ms am Ende.
Zurück nach obenEine Auswirkung hat diese Anforderung jedoch nur bei nichtlinearen Tarifmodellen: z. B. unterschiedliche Tarife f�r Tageszeit und Nachtzeit. Dann k�nnte z.B. der Tarifsprung ggf. schon stattfinden, obwohl er noch 500 ms Zeit h�tte.
Anbieter ohne nichtlineare Tarifmodelle, also wenn rund um die Uhr gleiche Preise gelten, sind von dieser Forderung nicht betroffen, h�chstens bei einer z. B.j�hrlich einmal vorkommenden Tarifanpassung.
b) Abweichung der Systemuhr vom amtlichen Zeitnormal
Hier sind zwei Anforderungen zu beachten:
W�hrend die Uhrzeit z. B. per NTP (Network Time Protocol) von einem passenden Server ausreichend genau bezogen werden kann (auch eine manuelle Einstellung anhand einer Funkuhr w�re leicht innerhalb von 3 s m�glich), erfordert die Stabilit�tsforderung eine Hardware-Untersuchung des ma�geblichen Taktoszillators, meist einer Schaltung mit einem Schwingquarz. Dazu siehe auch den Beitrag "Stabilität der Systemuhr" auf dieser Webpage.
Die Stabilit�t der Systemuhr kann daher nicht mit NTP korrigiert oder verbessert werden, kein NTP-Server kann �ber das Internet in jeder Sekunde die Systemuhr nachstellen. Dazu w�re besser eine Synchronisation z. B. per GPS oder DCF77 geeignet.
Bei dieser Anforderung tun sich manche software-orientierte Sachverst�ndige und besonders die Anbieter von Internetservices schwer, das Auffinden des Steuerquarzes (einer Hardware-Sache) bereitet ihnen stets Probleme. Auch deren Lieferanten sind da ahnungslos; manchmal findet sich aber doch ein beherzter System-Admin, der den Einschub herauszieht, sodass der Gutachter den Quarz sehen und seine Daten notieren kann.
Zu erfassen w�re dann noch, wie die Systemuhr technisch gegen Verstellen gesichert ist bzw. ist die Routine anzugeben und darzustellen.
c) Entfernungserfassung zwischen den an einer Verbindung beteiligten Anschl�ssen
Diese Anforderung erwies sich als recht problemlos. �blicherweise werden alle Ziffern der gew�hlten Rufnummer gespeichert, ob nun Orts-, Fern- oder Mehrwertverbindung und die Rufnummer des Anrufers = Kunden des Netzbetreibers ist ohnehin bekannt, so dass deren Aufnahme in den CDR leicht m�glich ist.
d) Genauigkeit der Entgeltberechnung bei kontinuierlicher Zeiterfassung
Die Zeiterfassung erfolgt im digitalen Zeitalter auch digital, also nicht analog mit beliebiger Anzahl von Dezimalstellen (bis zur "Rauschgrenze") oder, wie in der Vfg. gefordert, mit vier Nachkommastellen. Ob diese digitale Zeiterfassung nun in 1ms-, 8-ms- oder 100-ms-Inkrementen (erzeugt durch die Systemuhr) erfolgt, Tatsache ist, dass es bei der folgenden Abrechnung auf die vom Netzbetreiber oder Provider festgelegten "Abrechnungs-Intervalle" ankommt. �blich sind dabei 1s, 10s oder z. B. 60-s-Intervalle, manchmal ist das erste Intervall l�nger (was einer pauschalen Abrechnung von Kurzgespr�chen dienlich ist).
Die Intervall-Genauigkeit von 1% bei 100 s Abrechnungsdauer in der Vfg. kann zumeist gut eingehalten werden.
"Geb�hrenimpulse" werden heute nicht mehr zur Abrechnung verwendet. Wenn diese auf analogen Leitungen oder als digitale Information im ISDN angeboten werden, sind sie nur zur Information des Teilnehmers gedacht, nicht aber zur Abrechnung.
In der Vfg. ist die Verwendung von Korrekturwerten f�r die Zeitpunkte von Beginn und Ende der Verbindung vorgesehen. Von dieser M�glichkeit wird aber kaum Gebrauch gemacht, die Systeme haben keine M�glichkeit der Einpflegung von Korrekturwerten.
Dann geht es um die Rundung. US-Firmen verstehen darunter oft nur das Abschneiden der letzten Nachkommastelle. In unseren Breiten ist die kaufm�nnische, auch "5/4tel Rundung", gefragt. Das f�hrt z. B. zu folgenden Ergebnissen:
Ein gesamter Rechnungsbetrag von 0,00500 EUR wird abgerundet auf Null Ein gesamter Rechnungsbetrag von 0,00501 EUR wird aufgrundet auf 0,01 EUR.
Viel Diskussion l�ste die Forderung nach Speicherung der berechneten Verbindungsentgelte netto (also ohne Mwst.) im System aus. Das hat dann u. a. den Vorteil, dass bei �nderung der Mehrwertsteuer nur wenige Zellen neu programmiert werden m�ssen.
Bei z. B. Mobilfunkvertr�gen ist das kein Problem, jedoch gibt es ein Problem bei Pre-Paid. Es wird mit dem privaten Verbraucher immer brutto abgerechnet, weshalb bei vorausbezahlten Entgelten (Pre-Paid) in den IN-Abrechnungssystemen die Bruttobetr�ge gespeichert sein m�ssen. Das ist dann allerdings (nach einer RegTP-Entscheidung) im Sinne der Vfg.168/99.
e) Abrechnung von Rabatten und Zuschl�gen
Gemeint sind hier Rabatte oder Zuschl�ge auf einzelne Verbindungen, nicht auf die Gesamtrechnung oder auf einen bestimmten Tarif (das w�re ein neues Tarifmodell, also z.B. ein "Ortsnetztarif").
Klassisches Beispiel ist die "Eventgeb�hr", also die Kosten, die erst einmal jeder Anruf verursacht. Diese Geb�hr kann dann ggf. mit den Verbindungskosten oder mit Dienstleistungen verrechnet werden. Beispiel: Auskunftsdienste.
f) Abrechnung einzelner Kommunikationsf�lle auf Guthabenbasis
Der klassische Fall daf�r sind die Prepaid-Tarife im Mobilfunk. Dahinter steht heute zumeist ein eigenes, zus�tzliches IN-Abrechnungssystem, denn wenn das Guthaben w�hrend einer Verbindung zur Neige geht, muss die Verbindung unterbrochen werden und das geht nur mit einer "real time"-Abrechnung. Der Gutachter muss sich daher mit diesem IN-System intensiv auseinandersetzen.
g) Daten�bertragung von Kommunikationsdatens�tzen von der Datenerfassung zur Datennachverarbeitung
Da waren wohl anfangs Bedenken aufgetaucht, die Daten w�rden zwecks Entgeltabrechnung nach Polen oder Israel per DF� �bertragen werden, die Einzelverbindungsnachweise dann zur�ck in der anderen Richtung. In der Praxis sind derartige F�lle wohl nicht vorgekommen.
Probleme machte die Bestimmung der Fehlerh�ufigkeit von Kommunikationsdatens�tzen (KDS) in H�he von 10*10^-10. Hier war es zuerst n�tig, den Hintergrund zu erforschen. Wer die KDS mit dem X.25-Protokoll �bertrug, war da fein raus, dieses Verfahren hatte eine Fehlerkorrektur und die tats�chlichen Fehler waren nach CCITT (bzw. ITU-T) nur mathematisch errechenbar. Ein SV-Kollege hatte da die gute Idee, eine Diplomarbeit dazu auszuschreiben und so kam das staunende Gremium der Verbindungspreis-Berechnungs-SV zu einem Vortrag zum Thema des Diplomanden. Tats�chlich war es der Bundespost schon nach Einf�hrung des DATEX-P-Netzes (das mit X.25 arbeitete) nicht m�glich, die Fehler zu z�hlen, weil das System einfach zu gut war....
Was noch fehlt, w�re eine weitere Diplomarbeit, ob das nun das mehrfach verwendete TCP/IP-Protokoll die gleichen Qualit�ten hat; aber da musste man sich bisher auf die Aussagen der Hersteller verlassen.
h) Protokollierung von entgeltbeeinflussenden Ma�nahmen
Heute f�hrt selbst jeder PC "Logdateien", in denen Funktion und Fehlfunktion festgehalten werden. Es w�re daher ein Leichtes, bei einer "entgeltbeeinflussenden Ma�nahme" (Tarifumstellung, Systemausfall, andere Fehler) dies im Nachhinein anhand der Logdateien zu kontrollieren. Leider sind da viele Netzbetreiber unglaublich unbeholfen, wenn es um die Vorlage dieser Dateien geht, sie wissen nicht Bescheid oder wiegeln ab: "Wie wollen Sie die Millionen Datens�tze pr�fen?" Dazu w�re anzumerken, dass hier meist nur ein zeitlich begrenztes Volumen an Logdateien gebraucht wird, zweckm��igerweise auf einem Datentr�ger abgelegt, nicht etwa auf Endlospapier.
Da diese Logdateien ebenso lange wie die Kommunikationsdatens�tze gespeichert werden m�ssen, verwechseln SV und Verpflichtete oft beide, was nat�rlich nicht vorkommen darf.
Bei Gerichtsverfahren will der erfahrene Richter zuerst das Gutachten nach TKG sehen (vorher: "nach TKV") und dann kommt die Frage: Hat das gesamte System im streitgegenst�ndlichen Zeitraum ordnungsgem�� funktioniert? Den Nachweis k�nnte man mit den Logdateien (= Protokollierung) f�hren. Bei der TKV stand dies im Par.16. In der Praxis haben da manche Netzbetreiber / Provider so ihre Probleme und oft ist f�r sie die L�sung, die Klage zur�ckzunehmen anstatt die Daten zu erheben, zu speichern und vorzulegen...
Zusammenfassung
In den 10 Jahren ihres Bestehens haben sich Regulierer, Verpflichtete und Sachverst�ndige recht gut "zusammengerauft" und die anfangs erhobene Forderung, die Vfg.168/99 zu �ndern, wurde nicht weiter verfolgt. Das war nat�rlich der einfachere Weg.
Die Vfg. ist grunds�tzlich eine Festnetzrichtlinie, die Anpassung an die Abrechnungsgenauigkeit von Mobilfunknetzen sollte aber doch einmal vorgenommen werden. Richtlinien zur Pr�fung volumenbasierter Abrechnungen wurden allerdings nicht erlassen, genausowenig wie genaue, einheitliche Pr�fvorschriften f�r Funktionen von Hard- und Software der Erfassungs- und Abrechnungssysteme. Das war denn dann doch zuviel der M�he.
k/s
11 / 2009