DE69933130T2

DE69933130T2 - Abrechnung in einem Kommunikationsnetz

Info

Publication number: DE69933130T2
Application number: DE69933130T
Authority: DE
Inventors: John Robert Woodbridge BRISCOE; Michael Ipswich RIZZO
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1998-06-05
Filing date: 1999-06-04
Publication date: 2007-03-08
Anticipated expiration: 2019-06-05
Also published as: AU4158099A; WO1999065184A3; CA2333362A1; WO1999065185A2; EP1119943A2; JP4455758B2; US7747240B1; AU763659B2; CN1310651A; JP4386582B2; EP1123604B1; EP1119944A2; WO1999065183A3; AU4157599A; CN100385851C; DE69919190T2; US7426471B1; US20050286488A1; JP4361214B2; CA2333361A1

Description

HINTERGRUND ZUR ERFINDUNG
Die vorliegende Erfindung betrifft ein Kommunikationsnetz und insbesondere Gebührenmechanismen in einem solchen Netz. Sie umfasst Aspekte der Erfindungen, die in der gleichzeitig anhängigen britischen Patentanmeldung Nr.9812161.9 des vorliegenden Anmelders, eingereicht am 5. Juni 1998, offenbart und beansprucht sind.
In herkömmlichen Kommunikationsnetzen, wie z. B. nationalen PSTNs (öffentlichen Fernsprechwählnetzen) wird ein signifikanter Anteil der Netz-Ressourcen dem Zählen und Abrechnen der Netznutzung gewidmet. Studien haben abgeschätzt, dass diese Ressourcen nicht weniger als 6 % der Einnahmen einer Telekommunikationsgesellschaft verbrauchen. Das Internet beinhaltet dagegen im Allgemeinen keine Zähl- und Abrechnungsmechanismen für die einzelnen Kunden. Die Abwesenheit der Netzinfrastruktur, die erforderlich ist, um das Zählen und Abrechnen zu unterstützen, verringert die Betriebskosten des Internets im Vergleich zu herkömmlichen Telephonnetzen und hat die schnelle Ausbreitung des Internets erleichtert. Die Abwesenheit von geeigneten Abrechnungsmechanismen hat jedoch signifikante Nachteile hinsichtlich der Eigenschaften des vom Internet übertragenen Verkehrs. Es fördert eine verschwenderische Nutzung der Netz-Ressourcen und vermindert den Anreiz für die Investition in die Netzinfrastruktur, um neue Anwendungen zu unterstützen, die z. B. eine garantierte Dienstqualität (QoS) erfordern und zu Internet-Zugangsdiensten auf Teilnahmebasis führen.
WO98/02828 beschreibt ein System, durch das ein Internet-Dienstanbieter (ISP) Teilnehmern einen "freien" Internetzugang bieten kann (vorausgesetzt, dass sie einen begrenzten Bereich von Websites be trachten, die von Organisationen betrieben werden, die darauf vorbereitet sind, die Kosten der Teilnehmer zu bezahlen). Um das System zu betreiben, erwirbt der ISP von einem PSTN-Netzbetreiber eine Nummer vom freien Telephontyp, wobei der ISP die Kosten von irgendwelchen Anrufen an diese Nummer bezahlt; ein JAVA-Applet an einem Endgerät eines Teilnehmers überwacht den Zugang zum Internet, der vom Teilnehmer durchgeführt wird, und zeichnet die mit dem Browsen von Internet-Sites verbrachte Zeit auf, für die die Betreiber mit dem ISP übereingekommen sind, dass sie die Verbindungskosten des Teilnehmers bezahlen; der ISP berechnet dann den jeweiligen Eigentümern der Internet-Sites solche Verbindungskosten und zieht solche Gebühren von der Rechnung des Teilnehmers ab.
WO95/27385 beschreibt eine Steuereinheit zur Anordnung innerhalb eines Telekommunikationsnetzes an verschiedenen Abgrenzungspunkten, um mehrere Aufgaben durchzuführen, wie z. B. Verkehrsformung, Fehlererkennung und Nutzungsüberwachung.
Sloman M S et al.: "Domain Management and Accounting in an International Cellular Network" Integrated Network Management, III Proceedings 3. International Symposium 18.-23. April 1993, Seiten 193–206, XP000199363, erörtert die Anwendung von Managementdomänen als Mittel zum Festlegen und Steuern der Dienste, zu deren Verwendung in einem internationalen Zellennetz ein Teilnehmer berechtigt ist. Es beschreibt, wie ein solches System verwendet werden kann, um das Roaming von Mobilteilnehmern zwischen Netzen in verschiedenen Ländern zu ermöglichen, während ein Anruf in Gang ist.
Estrin D et al. "Design Considerations for Usage Accounting and Feedback in Internetworks" Computer Communications Review, Band 20, Nr. 5, 1. Oktober 1990, Seiten 56–66, XP000167877, untersucht die Konstruktion von Ressourcen-Nutzungsrückmeldungsmechanismen für paketvermittelte Internetze. Es erwähnt, dass, anstatt dass das Netz die Gesamtheit der von jedem Teilnehmer durchgeführten Nutzung überwacht, das Netz die Nutzung des Netzes durch jeden Teilnehmer statt dessen abtasten und eine Gebühr auf der Basis der abgetasteten Messungen durch Extrapolation berechnen könnte, um den mit der Durchführung der Nutzungsüberwachung verbundenen Overhead zu verringern.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Kommunikationsnetzes geschaffen, wie in Anspruch 1 dargelegt.
Die vorliegenden Erfinder haben festgestellt, dass ein Schlüsselschritt beim Implementieren eines leichtgewichtigen Gebührenprotokolls, das zur Verwendung in einem vereinigten Netz geeignet ist, darin besteht, das Zählen der Netznutzung zu dezentralisieren, indem jedes Kundenendgerät dazu beschaffen wird, seine eigene Nutzung von Netz-Ressourcen zu überwachen. In dieser Weise wird ein Gebührenmechanismus geschaffen, der von Natur aus skalierbar ist und der signifikante Overheads innerhalb des Netzes vermeidet. Überdies schafft die Erfindung in bevorzugten Implementierungen eine Basis für ein Mehrdienst-Paketnetz, in dem es nicht erforderlich ist, jedes Paket zu überwachen. Dies macht es weitaus leichter als mit existierenden Schemen, ein Mehrdienst-Netz zu implementieren, d. h. eines, in dem verschiedene Pakete dementsprechend unter schiedlich zeitlich gesteuert werden können, welche Dienstklasse gilt.
Vorzugsweise umfasst das Verfahren das Speichern der durch Schritt (a) erzeugten Messdaten. Vorzugsweise werden mit den Messdaten Daten gespeichert, die einen Tarif identifizieren, der auf die Messdaten anwendbar ist. Die Daten, die den Tarif identifizieren, können der Tarif selbst sein oder können die Form eines gewissen Identifikationscodes oder Zeigers für den Tarif annehmen. Das Speichern des Tarifs ermöglicht, dass Abrechnungsdaten aus Messungen am Kundenendgerät erzeugt werden, selbst wenn der Tarif über die Zeit variiert.
Vorzugsweise umfasst das Verfahren das Übermitteln von durch Schritt (a) erzeugten Daten zu einem Netzabrechnungsobjekt, das durch einen Netzbetreiber gesteuert wird. Alternativ können Daten vom Netzbetreiber zum Kunden in einer herkömmlichen Weise übermittelt werden. Die Netznutzungsdaten können explizit übermittelt werden und die Gebühr für die Netznutzung vom Netzbetreiber berechnet werden. Alternativ können die Nutzungsdaten implizit in Abrechnungsdaten übermittelt werden, die eine Gebühr angeben, die vom Kundenendgerät berechnet wird.
Vorzugsweise umfasst das Verfahren einen Schritt, der vom Netzbetreiber ausgeführt wird, zum Abtasten nur eines Teils des zwischen einem Kundenendgerät und dem Netz übermittelten Verkehrs. Dieser abgetastete Verkehr wird dann mit den Netznutzungsdaten verglichen, die vom Kundenendgerät an das Netzanbieter-Abrechnungsobjekt gemeldet werden, wodurch irgendeine Diskrepanz erfasst wird. Der Vergleich kann an den Gesamtgebühren für die Netznutung stattfinden oder kann an den detaillierten Messdaten stattfinden. Das erstere kann die Norm für die Effizienz sein, wobei das letztere in diesem Fall nur dann verwendet wird, wenn das erstere Diskrepanzen zeigt, um einen Beweis eines Betrugs zu speichern.
Die Erfinder haben festgestellt, dass die Effizienz des Gebührenprozesses weiter verbessert werden kann, wenn der Kunde für das Messen der Nutzung und das Liefern der Nutzungsdaten oder bewerteten Nutzungsdaten verantwortlich ist, und der Netzbetreiber nur einen Abtastwert des Kundenverkehrs auf einer willkürlichen Basis misst, um die Zuverlässigkeit der vom Kunden gelieferten Daten zu bestätigen.
Vorzugsweise ist das Netzbetreiber-Abrechnungsobjekt konfigurierbar, um Daten entweder von einem Messobjekt, das vom Netzbetreiber gesteuert wird, oder von einem Kundenendgerät zu empfangen. Vorzugsweise umfasst das Verfahren das Ändern von einer Konfiguration zur anderen in Reaktion auf ein Steuersignal, das am Netzabrechnungsobjekt empfangen wird.
Vorzugsweise umfasst das Verfahren das Übermitteln von Messdaten zu einem System, das vom Kundenendgerät entfernt ist. Daten können beispielsweise von einer Anzahl von Kundenendgeräten zu einem gemeinschaftlichen Abrechnungssystem übermittelt werden. Die Daten können explizit gesandt werden und/oder eine Nutzungsgebühr, die unter Verwendung der Daten berechnet wird, kann zum entfernten System gesandt werden. Wenn Daten einem entfernten System gemeldet werden, kann dies unmittelbar, wenn die Daten erzeugt werden, durchgeführt werden oder kann in Form eines Berichts durchgeführt werden, der Daten von einer Reihe von Messungen über einen Zeitraum ansammelt.
Vorzugsweise umfasst das Verfahren:
Übermitteln von Verkehr zwischen einem Kundenendgerät und einer ersten Netzdomäne, die mit dem Kundenendgerät verbunden ist,
ferner Übermitteln des Verkehrs zwischen der ersten Netzdomäne und einer zweiten Netzdomäne, die mit der ersten Netzdomäne verbunden ist;
Übermitteln von Netznutzungsdaten vom Kundenendgerät zu einem ersten Netzabrechnungsobjekt in der ersten Domäne;
Übermitteln von Abrechnungsdaten zwischen dem ersten Netzabrechnungsobjekt und einem zweiten Netzabrechnungsobjekt in der zweiten Domäne.
Diese Schritte schaffen ein leistungsstarkes und effizientes Verfahren zum Abrechnen zwischen Domänen in einem vereinigten Datennetz. Obwohl Daten z. B. von einem ersten Kundenendgerät über Zwischennetzdomänen zu einem zweiten Kundenendgerät fließen können, müssen die Abrechnungsdaten (d. h. die Messdaten oder davon abgeleitete Daten) nicht alle in derselben Richtung fließen. Die Erfindung umfasst beispielsweise Systeme, in denen Abrechnungsdaten vom Kunden zur ersten Domäne geleitet werden und auch von der zweiten Netzdomäne zur ersten Netzdomäne geleitet werden.
Vorzugsweise umfasst das Verfahren das Bestimmen der Identität einer zweiten Domäne aus einer Stromleittabelle in der ersten Netzdomäne, welche Daten mit dem Kundenendgerät über die erste Netzdomäne übermittelt, und das Übermitteln von Abrechnungsdaten für das Kundenendgerät mit der durch die Stromleittabelle identifizierten zweiten Domäne.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird ferner ein Verfahren zum Betreiben eines Netzes mit einer Vielzahl von Netzdomänen geschaffen, welches das Berechnen einer Gebühr für die Nutzung von Netz-Ressourcen durch einen jeweiligen Kunden und das Durchführen einer Zahlung zum Ausgleich der Gebühr an eine Dritt-Verrechnungsstelle umfasst. Diese Verrechnungsstellenzahlung kann verwendet werden, um Gebühren zwischen den Endanwendern in einem beliebigen gewünschten Verhältnis umzulegen, z. B. bezahlt der Sender alles oder der Sender bezahlt 60 %, der Empfänger bezahlt 40 % usw.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird ferner ein Verfahren zum Betreiben eines Paketnetzes geschaffen, das eine Vielzahl von verschiedenen Dienstniveaus bereitstellt, wobei das Verfahren das Leiten der Pakete über einen Paket-Router und im Paket-Router das Bestimmen einer Klassifizierung von Paketen, eine unterschiedliche Zeitsteuerung von Paketen in Abhängigkeit von der Paketklassifizierung und an einer vom Router entfernten Stelle das Überwachen der Dienstniveaus von Paketen, um die Berechtigung eines Pakets für eine jeweilige Dienstklasse zu bestimmen, umfasst.
Die Erfindung umfasst auch das Kommunikationsnetz von Anspruch 28 und das Kommunikationssystem von Anspruch 27. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen beansprucht.
BESCHREIBUNG DER ERFINDUNG
Systeme, die die vorliegende Erfindung verkörpern, werden nun nur beispielhaft mit Bezug auf die begleitenden Zeichnungen genauer beschrieben, in denen:
1 ein Diagramm ist, das ein Netz zeigt, das die Erfindung verkörpert;
2 und 3 Daten zeigen, die zwischen Abrechnungsobjekten geleitet werden, die verwendet werden, um eine beispielhafte Ausführungsform der vorliegenden Erfindung zu implementieren;
4 ein Diagramm ist, das Protokollprofile an einem Kundenendgerät und in der Netzdomäne zeigt;
5a bis 5e Klassendiagramme für eine Software sind, die Abrechnungs- und Messobjekte implementiert;
6 ein Diagramm ist, das eine graphische Benutzerschnittstelle (GUI) zur Verwendung bei den Objekten von 5a bis 5e zeigt;
7 ein Diagramm ist, das die Schnittstelle zwischen benachbarten Domänen des Netzes von 1 zeigt;
8 ein Diagramm ist, das schematisch die Verteilung von Abrechnungsdaten über mehrere Netzdomänen zeigt;
9 ein Diagramm ist, das ein Netz unter Verwendung einer Dienstanbieter-Verrechnungsstelle zeigt;
10 ein Diagramm ist, das ein Netz unter Verwendung einer Dritt-Verrechnungsstelle zeigt;
11 eine Aufteilungskantenbewertung darstellt;
12 Tarifschnittstellen zeigt; und
13 eine alternative Ausführungsform zeigt.
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Wie in 1 gezeigt, umfasst ein Kommunikationsnetz 1 eine Anzahl von Netzunterdomänen 2A–C. Die Netzunterdomänen können unter der Steuerung verschiedener Betreiber stehen. Der Betrieb des Netzes nimmt nicht an, dass ein gegenseitiges Vertrauen zwischen den verschiedenen Betreibern vorliegt. Die Netzunterdomänen sind durch Gateway-Router 3, 4 miteinander verbunden. Im vorliegenden Beispiel ist das Kommunikationsnetz das Internet und unterstützt sowohl das Unicast- als auch das Multicast-Internetprotokoll (IP) und zugehörige Protokolle. Ein Kundenendgerät 5 ist über ein öffentliches Fernsprechwählnetz (PSTN) 6 und einen Zugangs-Router 7 mit einer Unterdomäne 2A verbunden. Keine Überwachung ist am Zugangs-Router erforderlich. Die Gateway-Router 3, 4 und der Zugangs-Router 7 können kommerziell erhältliche Vorrichtungen, wie z. B. Router der CISCO-Serie 7500 bzw. ein universeller Zugangsserver der CISCO-Serie AS5800, sein. Andere Kundenendgeräte sind mit dem Netz verbunden, einschließlich eines Java-fähigen mobilen Endgeräts 8 und eines Datenservers 9.
Das Kundenendgerät 5 kann über ein LAN mit einem Abrechnungsserver verbunden sein. Der Abrechnungsserver kann ein Abrechnungsobjekt umfassen, wie nachstehend beschrieben, das Messdaten vom Kundenendgerät empfängt.
Tarife für die Nutzung von Netz-Ressourcen werden über das Netz zu den Kundenendgeräten im Multicast-Betrieb gesendet. Diese Tarife sind in Bänder mit verschiedenen Unbeständigkeiten unterteilt. Die Tarife werden unter der Steuerung der Netzbetreiber verändert, um die Gesamtbelastung des Netzes widerzuspiegeln. Das heißt, wenn die Netzbelastung hoch wird, dann können die Tarife erhöht werden, um die Knappheit der Netz-Ressourcen widerzuspiegeln. Eine Netzmanagementplattform 10 ist mit jeder Unterdomäne verbunden. Jede Netzmanagementplattform kann beispielsweise ein Rechensystem mit einem SPARC-Arbeitsplatzrechner, der auf UNIX (Solaris) läuft, zusammen mit Netzmanagementanwendungen umfassen. Die Netzmanagementplattform 10 beherbergt Management-Entitäten und Tarif-Entitäten. Sie kann auch als Abrechnungsserver, der Netzabrechnungsobjekte beherbergt, fungieren, wie nachstehend beschrieben. Die Netzmanagementplattform kommuniziert mit Agenten 100 in gemanagten Vorrichtungen, die mit der jeweiligen Unterdomäne verbunden sind, beispielsweise unter Verwendung von SNMP (Simple Network Management Protocol, einfaches Netzmanagementprotokoll). Die Managementplattform überwacht die Gesamtbelastung der Netz-Ressourcen in den jeweiligen Unterdomänen und stellt die Tarife für die Netznutzung dementsprechend ein. Die Netzmanagementplattform (NMP) weist den Agenten an, die Vorrichtung zu überwachen und die angesammelten Ergebnisse in regelmäßigen Intervallen an die NMP zurückzumelden, so dass die NMP die Kombination aller Berichte überwachen kann.
Zusätzlich zu dieser zentralen Steuerung der Tarife kann ein Tarifalgorithmus an jedem Kundenendgerät so beschaffen sein, dass er automatisch auf eine lokal erfasste Änderung in der Belastung der Netz-Ressourcen reagiert. Die Verwendung der lokalen Tarifänderung wird nachstehend beschrieben.
Ein Dienstanbieter kann verschiedene Produkte anbieten, die durch verschiedene Dienstniveauvereinbarungen und/oder durch verschiedene Preisunbeständigkeiten definiert sind. Das Produkt A könnte beispielsweise den Dienst mit bester Leistung mit einem festen Preis anbieten, während ein anderes Produkt B einen Dienst mit bester Leistung mit einem variablen Preis anbieten könnte. Ein Dienstanbieter kann die Produktpreise auf der Basis der folgenden Parameter einstellen: des Preises, den der Dienstanbieter an seinen Großhandelsanbieter bezahlt: Preise von Konkurrenten; der aktuellen Ressourcen-Nutzung; des relevanten Bedarfs für verschiedene Produkte. In Reaktion auf die Änderungen dieser Parameter können die Tarifeinstellungen in einer von drei Weisen bewirkt werden. Erstens kann ein Tarif Preise auf der Basis von lokalen Beobachtungen der Netzbelastung einstellen, ohne eine explizite Kommunikation vom Anbieter zu benötigen. Diese Methode, die nachstehend genauer beschrieben wird, muss am Beginn in den Tarif eingebaut werden und ist auf diejenigen Preisänderungen begrenzt, die ausschließlich von lokalen Beobachtungen abhängen. Zweitens kann der Anbieter einen Tarif durch Einstellen von einigen seiner Parameter abstimmen. Diese Art von Einstellung ist erforderlich, wenn die Entscheidung von Parametern abhängt, die nicht direkt vom Kunden beobachtet werden können, z. B. Änderung des Großhandelspreises der Netz-Ressourcen. Drittens kann der Anbieter einen Tarif vollständig austauschen. Dies ist erforderlich, wenn der existierende Tarif den Änderungen, die erforderlich sind, nicht gerecht werden kann.
Die erste der vorstehend beschriebenen Tarifänderungen wird notwendigerweise automatisch ausgeführt. Die zweite Art von Änderung kann manuell oder durch einen Agenten durchgeführt werden, der Einstelllungen automatisch in Reaktion auf Beobachtungen ausgibt, die vom Dienstanbietersystem gemacht werden. Die dritte Art von Änderung wird wahrscheinlich manuell durchgeführt, da ein Austausch eines neuen Tarifs im Allgemeinen ein Konstruktionselement erfordert, das eine menschliche Eingabe benötigt. Es ist jedoch möglich, dass ein Agent verwendet werden könnte, um Tarife für ein Produkt auf der Basis eines Satzes von festgelegten Regeln automatisch umzuschalten.
Dieser Abschnitt beschreibt einen Prototypen, den wir implementiert haben, um das vorstehend umrissene Tarifuntersystem zu demonstrieren. Die Merkmale der Konstruktion umfassen:

• die Verwendung eines mobilen Codes, um Tarife und zugehörige Benutzerschnittstellenkomponenten darzustellen;
• die Verwendung eines wiederholten Multicast-Ankündigungsprotokolls, um Tarife und Tarifeinstellungen effizient zu übermitteln;
• die Verwendung einer dynamischen Klassenbelastung und -reflexion, um Tarife zu empfangen und abzustimmen.

Der Prototyp besteht aus einer Bibliothek von allgemeinen Java-Klassen und zwei speziellen Anwendungen, nämlich:

• einem Anbietersystem, das ermöglicht, dass der Anbieter Tarife für eine Anzahl von Produkten einführt, austauscht und abstimmt;
• einem Kundensystem, das ermöglicht, dass der Kunde die Gebüh ren verfolgt, die für die Produkte, die er verwendet, angewendet werden.

Das Anbietersystem bedient mehrere Instanzen des Kundensystems, das auf verschiedenen Hauptrechnern in einem Multicast-fähigen Netz läuft. Ein Multicast-Ankündigungsprotokoll wird verwendet, um Tarifänderungen vom Anbietersystem zu den Kundensystemen zu übermitteln. Um die Flexibilität in Bezug auf die Definition von Tarifen zu maximieren, wählen wir, Tarife unter Verwendung von Java-Klassen darzustellen. Dieses Verfahren wird auch verwendet, um Benutzerschnittstellenkomponenten zu Kunden zu liefern, um die Visualisierung des Verhaltens eines Tarifs zu unterstützen.
Die Tarif-Schnittstelle wirkt als Basisklasse für alle Tarife. Dies definiert eine einzelne Operation get GUI(), die eine Java-SWING-Komponente zurückführt, die in die GUI (graphische Benutzerschnittstelle) des Kunden integriert werden kann. Diese GUI-Komponente ermöglicht dem Kunden, das Verhalten des Tarifs unter Verwendung von für den Tarif geeigneten Verfahren zu visualisieren.
Unterklassen der Tarif-Schnittstelle legen einen Satz von Tarifarten fest, von denen jeder einem anderen Satz von Mess- und Eingabeparametern zugeordnet ist. Diese Parameter werden durch Auflisten derselben in der Signatur des Verfahrens getCharge() identifiziert. Die Schnittstelle RSVPTariff definiert beispielsweise getCharge() als ein RSVP TSPEC empfangend, was die Definition von Tarifen ermöglicht, die den Preis auf der Basis der Eigenschaften einer RSVP-Reservierung berechnen. Andererseits definiert die Schnittstelle Packet-CountTariff getCharge() als Messungen von Eingangspaketen, Ausgangspaketen und des aktuellen Staus (typischerweise als Funktion des Paketabfalls gemessen) empfangend, was die Definition von Tarifen ermöglicht, die von Paketzahlen abhängen und gegen einen Stau empfindlich sind. Andere Tarife können hinzugefügt werden, wenn neue Formen von Nutzungsmessung aufkommen. Die Tarif-Schnittstelle und die Unterklassentarif-Schnittstellen RSVPTariff und PacketCountTariff sind in 12 dargestellt.
Tarife werden durch Bereitstellung von Implementierungen der vorstehend beschriebenen verschiedenen Tarif-Schnittstellen definiert. Der Tarif PacketCountLinear implementiert beispielsweise PacketCountTariff, um Gebühren im Verhältnis zu den Paketzahlen zu berechnen. Ein weiterer Tarif CongestionSensitiveLinear arbeitet auf einer ähnlichen Basis, fügt jedoch eine Strafgebühr hinzu, wenn der Kunde nicht innerhalb einer festgelegten Verkehrsgrenze bei Anwesenheit eines Staus bleibt.
Zusätzlich zur Tarif-Schnittstellen-Implementierung kann ein Tarif von anderen "Helfer"-Klassen, um seine Operation zu unterstützen, sowie von einer oder mehreren Benutzerschnittstellen-Komponentenklassen für Kundenvisualisierungszwecke Gebrauch machen. Eine Benutzerschnittstelle auf der Anbieterseite kann auch erforderlich sein, um dem Anbieter zu ermöglichen, Tarifeinstellungen durchzuführen.
Eine vollständige Tarifbeschreibung besteht aus einem Satz von Java-Klassen, von denen einige für das Kundensystem bestimmt sind und andere zur Verwendung vom Anbietersystem vorgesehen sind. Die Klassen der Kundenseite sind in einer Java-Archivdatei (JAR-Datei) gebündelt, um die Verarbeitung durch das Anbietersystem zu erleichtern.
Um einen neuen Tarif einzusetzen, lädt das Anbietersystem zuerst die Tarifklassen, die es erfordert, in seine Ausführungsumgebung. Dann lädt es das Bündel der Kundenseite, serialisiert es, signiert es mit einem privaten Schlüssel und verwendet ein Ankündigungsprotokoll, um es zu Kundensystemen zu verteilen. Die Verwendung einer Signatur macht es möglich, dass Kunden überprüfen, dass die empfangenen Tarife echt sind.
Beim Empfangen des Bündels überprüft jedes Kundensystem die Signatur (unter Verwendung des öffentlichen Schlüssels, der dem privaten Schlüssel des Anbieters entspricht) und entpackt zur Aktivierungszeit, die in den Ankündigungsprotokollköpfen festgelegt ist, die signifikant später, z. B. Stunden oder Tage, sein kann, das Bündel und lädt die Klassen in seine Ausführungsumgebung unter Verwendung einer zweckgebauten dynamischen Klassenladeeinrichtung. Eine Instanz der empfangenen Tarifklasse wird erzeugt und anstelle des vorherigen Tarifs installiert. Wenn der Tarif eine Benutzerschnittstellen-Komponente (durch Aufrufen des Verfahrens getGUI() des Tarifobjekts erhalten) aufweist, dann ersetzt sie die Benutzerschnittstelle des vorherigen Tarifs. Der Wechsel der Benutzerschnittstelle dient zum Benachrichtigen des Benutzers, dass sich der Tarif geändert hat.
Die Tarifeinstellung beinhaltet den entfernten Aufruf einer Operation, die für den aktuell in Kraft befindlichen Tarif spezifisch ist. Dies bedeutet, dass ein Kundensystem die Signatur dieser Operation nicht vor dem Empfangen des Tarifs kennen kann, d. h. die Operation wird in keiner der dem Kundensystem bekannten Tarif-Schnittstellen aufgelistet.
Um dieses Problem zu umgehen, wird von einem "Reflexions"-Merkmal Gebrauch gemacht, das von Java unterstützt wird. Um eine Tarifeinstellung zu verbreiten, erzeugt der Anbieter eine Instanz eines Aufruf-Objekts, das den Namen der aufzurufenden Operation speichert, zusammen mit den Parametern, die zu dieser geliefert werden sollen. Dieses Objekt wird dann serialisiert, signiert und unter Verwendung des Ankündigungsprotokolls angekündigt. Wenn eine Einstellung von einem Kundensystem empfangen und überprüft wird, wird das Aufruf-Objekt entserialisiert und auf den aktuellen Tarif unter Verwendung der Reflexion angewendet, um die beschriebene Operation aufzurufen.
Um das Ankündigungsprotokoll zu vereinfachen, sind Einstellungen erforderlich, um idempotent und vollständig zu sein. Die Idempotenz garantiert, dass ein Tarif nicht nachteilig beeinflusst wird, wenn eine Einstellung mehr als einmal angewendet wird. Die Vollständigkeit impliziert, dass eine Einstellung den ganzen Parametersatz eines Tarifobjekts bestimmt, so dass eine Einstellung die Wirkungen von irgendwelchen vorher angewendeten Einstellungen vollständig entfernt hat.
Das Kundensystem kann einen Tarif durch wiederholtes Aufrufen der Operation getCharge(), die von diesem Tarif unterstützt wird, jede Sekunde und Hinzufügen des zurückgeführten Werts zur kumulativen Gebühr anwenden. Die zu getCharge() gelieferten Parameter hängen von der derzeit in Kraft befindlichen Art von Tarif ab. Wenn der Tarif beispielsweise eine Implementierung des PacketCountTariff ist, dann sind Messungen von eingehenden Paketen, ausgehenden Paketen und des Staus über die vergangene Sekunde erforderlich.
Wenn jedoch der Tarif eine Implementierung des RsvpTariff ist, dann ist nur ein TSPEC, das die aktuelle Reservierung beschreibt, erforderlich. Dies impliziert, dass ein Kundensystem nur an einem Produkt teilnehmen kann, wenn es die Parameter liefern kann, die für den diesem Produkt zugeordneten Tarif erforderlich sind.
Jeder Aufruf des Verfahrens getCharge() führt auch zu einer Aktualisierung; an der tarifspezifischen Benutzerschnittstelle. Im Tarif CongestionSensitiveLinear werden beispielsweise die Nutzungsparameter, die zu getCharge() geliefert werden, verwendet, um die graphischen Anzeigen des Verkehrs und Staus zu aktualisieren.
Das Ankündigungsprotokoll wird verwendet, um serialisierte Tarife und Einstellungen von einem Anbietersystem zu mehreren Kundensystemen zu übermitteln. Die Anzahl von Kundensystemen wird als groß angenommen und eine wiederholte Multicast-Lösung wird übernommen.
Jedem von einem Anbieter unterstützten Produkt wird ein Multicast-Kanal für Ankündigungszwecke zugewiesen. Kundensysteme hören auf die Kanäle entsprechend den Produkten, die sie verwenden. In der aktuellen Implementierung wird angenommen, dass jedes Kundensystem die Kenntnis von gut bekannten Multicast-Adressen für die Produkte, an dem es interessiert ist, hat.
Für jeden Produktkanal kündigt der Anbieter wiederholt den aktuellen Tarif und die an diesem vorgenommene jüngste Einstellung (falls vorhanden) an. Jede Ankündigung trägt eine Versionsnummer, die jedes Mal, wenn die Ankündigung geändert wird, inkrementiert wird. Kundensysteme verarbeiten nur Ankündigungen, wenn eine Versi onsnummeränderung erfasst wird. Wenn sich ein neuer Kunde einem Kanal anschließt, wartet er, bis er einen Tarif empfängt, bevor irgendwelche Einstellungsankündigungen verarbeitet werden. Ferner wird eine Einstellung nur angewendet, wenn ihre Ankündigungsversion größer ist als jene des aktuellen Tarifs, wodurch sichergestellt wird, dass eine verpasste Tarifankündigung nicht zur Anwendung einer anschließenden Einstellung an einem alten Tarif führt.
Im vorliegenden Beispiel wird die Berechnung unter Verwendung eines "Zahl-und-Anzeige"-Prozesses ausgeführt. Die zum Implementieren der Gebührenarchitektur in dieser Ausführungsform verwendeten Objekte werden nun beschrieben. Die Objekte umfassen Objekte höherer Ebene und Komponentenobjekte, die in einer Softwareimplementierung der Gebührenarchitektur verwendet werden. Einige Objekte sollen sich am Kundenendgerät (z. B. am Kundenendgerät 5) befinden und andere sollen sich irgendwo innerhalb des "Kantennetzes" (z. B. am Zugangs-Router 7 oder innerhalb der entsprechenden Netzunterdomäne – siehe 1) befinden. Die Objekte am Kundenendgerät umfassen ein Sitzungssteuerobjekt S, ein Kundengeschäftsregelobjekt B_c, ein Kundenbewertungsobjekt Pr_c, einen QoS-Manager Q, ein Kundenabrechnungsobjekt Act_c und ein Kundenmessobjekt M_c. Das Geschäftsregelobjekt B_c empfängt Informationen über diejenigen Aspekte der Sitzung, die die Verpflichtung für die Zahlung beinhalten, und empfängt aktuelle Bewertungsdaten vom Bewertungsobjekt Pr_c. Das Kundengeschäftsobjekt trifft Entscheidungen unter der Taktiksteuerung des Kunden darüber, welche gebührenpflichtigen Dienste verwendet werden und wie viel der gebührenpflichtigen Dienste genutzt werden. Diese Entscheidungen werden dem QoS-Manager Q zugeführt, der entscheidet, welche Mechanismen verwendet werden, um die Anforderungen zu erfüllen. Der QoS-Manager (und das Abrechnungsobjekt) steuert dann das Kundenmessobjekt M_c, um zu bestimmen, welche Aspekte von Verkehr und Dienst zu messen sind und welche Aspekte zu ignorieren sind. Das Messobjekt zeichnet dann die ausgewählten Aspekte des Verkehrs auf, wobei es beispielsweise die Anzahl von Paketen, die vom Kundenendgerät gesandt und empfangen werden, und die QoS-Niveaus für diese Pakete zählt. Diese Daten zusammen mit den aktuellen Tarifen, einschließlich irgendeiner Prämie für den Stau, werden dann vom Kundenendgerät verwendet, um die Gebühr zu bestimmen, die an den Netzbetreiber zahlbar ist. Das Messobjekt M_c wird auch durch das Abrechnungsobjekt mit Befehlen programmiert, die die Häufigkeit bestimmen, mit der Daten an das Kundenabrechnungsobjekt Act_c gemeldet werden. Das Kundenabrechnungsobjekt Act_c leitet Abrechnungsinformationen (bewertet oder nicht) zu einem Abrechnungsobjekt Act_p in der Domäne des Netzanbieters.
Auf der Seite des Netzanbieters, d. h. innerhalb der Unterdomäne, mit der das Kundenendgerät verbunden ist, wird der Verkehr des Kunden durch eine Version von M gemessen, die als M_p bezeichnet wird, aber nur auf einer Abtastbasis, die durch die Überwachungsfunktion Po bestimmt wird. Das heißt, der Netzbetreiber tastet den Verkehr des Kunden nur unstetig ab. Po steuert, wann im Netz Messungen durchgeführt werden, um den ganzen Verkehr irgendeines speziellen Kunden zu erfassen. Eine Volumenmessfunktion M_b ist für das Melden von angesammelten Verkehrspegeln, wie im sich bewegenden Mittelwert der Router-Warteschlangenlängen widergespiegelt, an das Bewertungsobjekt Pr_p verantwortlich. Volumenmessungen würden typischerweise über der Domäne des Anbieters zu einer zentralisierten Bewertungsfunktion (die für die Zuverlässigkeit vervielfältigt werden würde) gesammelt. Pr_p legt Preise fest, die die Geschäftsregeln vom Geschäftobjekt B_p des Netzanbieters sowie die aktuellen Verkehrsniveaus, die von M_b gemeldet werden, und die Bewertung von benachbarten Anbietern berücksichtigen. Die Überwachungsfunktion Po vergleicht Abtastmessungen von M_p mit Abrechnungsmeldungen, die bei Act_p infolge der eigenen Messungen der Kunden empfangen werden. Wenn es feststellt, dass die Konten unzureichend sind, könnte es den Dienst am Zugangs-Steuer-Gateway Acs einschränken oder irgendeine andere Bestrafung einleiten. Innerhalb des Abrechnungsobjekts eingekapselt prüft ein weiteres Überwachungsobjekt, ob die Konten den Zahlungen innerhalb der vereinbarten Zeit für die Zahlung entsprechen. Schließlich stellt die Identitätsabbildungsfunktion I eine Abbildung zwischen der Identität eines Kunden (Konto, digitale Signatur usw.) und ihrer aktuellen Netzadresse (typischerweise durch den ISP zugewiesen, ob Unicast oder Multicast) bereit.
Die Messobjekte (M-Objekte) liefern zu den Abrechnungsobjekten (Act-Objekten) die Informationen, die erforderlich sind, um zuerst Abrechnungsdatensätze und anschließend Berichte und Rechnungen zu erzeugen. Messdatensätze werden an sich nicht in den Act-Objekten gespeichert: Messdaten werden in Abrechnungsdatensätze sobald wie möglich umgesetzt. Die Umsetzung von Messdaten in Abrechnungsdatensätze beinhaltet eine Änderung der Klassenart und eine gewisse Ansammlung. Außerdem können die Messdaten mit Tarifinformationen verknüpft werden. Die von den Messobjekten zurückgeführten Messdaten umfassen in diesem Beispiel die folgenden Elemente:
IP-Adressen der zwei an der Kommunikation beteiligten Endpunkte. Dies ist von den Netzpaketen leicht erhältlich.
Portnummern: Diese werden verwendet, um zwischen verschiedenen Diensten zu unterscheiden, die von einem Benutzer auf einmal verwendet werden. Die Portnummern sind auch aus den Netzpaketen erhältlich.
Art von Paketen: Dienstidentität Dies identifiziert die Art von Dienst, z. B. als RSVP, als differentiellen Dienst oder als Daten. Diese Informationen ermöglichen, dass verschiedene Tarife in Abhängigkeit von der Paketart angewendet werden.
Netznutzungsinformationen Dies sind die Messdaten selbst und können beispielsweise einen Zählwert der Anzahl von Paketen umfassen.
Zeitperiodeninformationen Diese, falls ein Element, geben, wenn sie verwendet werden, die Länge der Zeit an, über die die Messung durchgeführt wurde.
Zeitreferenz Diese kann eine Startzeit und eine Endzeit umfassen und kann beispielsweise zum Anwenden von Rabatten auf Verkehr während definierter Stunden "außerhalb Spitzen" verwendet werden.
In der derzeit bevorzugten Implementierung werden Messdaten durch das Messobjekt zum Act-Objekt auf einer durch ein Ereignis gesteuerten Basis in Zeitintervallen zurückgeführt, die durch das Abrechnungsobjekt gesteuert werden. Alternative Methoden können eine Abfrage des Messobjekts durch das Act-Objekt oder eine durch ein Ereignis gesteuerte Abfrage verwenden. Die Kommunikation von Daten kann unter Verwendung von Java – RMI (entfernter Verfahrensauf ruf) bewirkt werden und das Java-Ereignismodell oder ein Socket kann zwischen Act und M erzeugt werden, um Messobjekte zu senden. Weitere alternative Kommunikationsmechanismen umfassen die Verwendung von CORBA- oder SNMP-ähnlicher Nachrichtenübermittlung. Das vorliegende Beispiel macht von einer RMI/CORBA-artigen verteilten Ereignisprogrammierinfrastruktur Gebrauch, die FLE-XINET genannt wird.
Messobjekte (M) bieten eine Steuerschnittstelle für Act-Objekte, so dass Act-Objekte steuern können, welche Messungen und wann und wo M seine Messinformationen meldet. Diese Steuerschnittstelle bietet einen Zugriff auf die folgenden Parameter:

1. Häufigkeit, mit der Messdatensätze erforderlich sind (für einen gegebenen Kunden oder Satz von Kunden). Dies macht es möglich, verschiedenen Abrechnungsgeschäftsmodellen gerecht zu werden, einschließlich z. B. Bezahlen, wenn Sie gehen, und herkömmliche Abrechnung. Die Häufigkeit kann als Periode einer Anzahl von Millisekunden festgelegt werden.
2. Was an Act gemeldet werden soll (für einen gegebenen Kunden oder Satz von Kunden). Dieser Parameter könnte alle Pakete oder nur Pakete mit einer gegebenen QoS-Schwelle angeben usw.
3. Wohin Messungen gemeldet werden sollen (für einen gegebenen Kunden oder Satz von Kunden). Dieser Parameter kann ein einfacher Verweis auf das Act-Objekt oder ein anderes mit dem Geschäft in Beziehung stehendes Objekt für Prüfungs- oder Marketingzwecke sein.
4. Aktuelle Zähleigenschaften des Messobjekts. Der Zähler M beim Netzanbieter multiplexiert die unterschiedliche Messanforderung für verschiedene Kunden und optimiert die Mess- und Meldeprozesse.

Die Abrechnungsobjekte am Kundenendgerät können unter Verwendung einer kleinen verschlüsselten Einheitsdatei-Datenbank implementiert werden. Auf der Seite des Netzanbieters können die äquivalenten Objekte unter Verwendung einer größeren Datenbank implementiert werden, die skalierbar ist, um z. B. Zehntausende von Kundenkonten zu handhaben. Ein Objektanforderungs-Makler (ORB) wird für die Kommunikation zwischen den Objekten auf der Kundenseite und den Objekten auf der Netzseite verwendet, der unter Verwendung von kommerziell erhältlichen Werkzeugen wie z. B. ORBIX (Handelsmarke) von Iona Technologies plc. Implementiert wird. Die Serialisierung wird verwendet, um Objekte von einer Datenbank zur anderen über das Netz zu leiten. Der Prozess der Serialisierung nimmt alle Attribute eines Objekts und leitet die Attribute über ein festgelegtes Medium zusammen mit Informationen, die die Art von Objekt festlegen, das die Daten veranlasst hat. Ein Prozess der Entserialisierung nimmt dann die Daten vom Übertragungsmedium zusammen mit den Objektarteninformationen und erzeugt ein neues Objekt der festgelegten Art und füllt es mit den Daten. Die Abrechnungsdatenbanken halten einen Satz von serialisierten Abrechnungsobjekten. Die für den Netzanbieter erforderliche größere Datenbank kann eine objektorientierte Datenbank sein, die Objekte annimmt und sie in ihren Speicherplatz serialisiert. Alternativ kann eine nichtobjektorientierte Datenbank verwendet werden, in welchem Fall die Abrechnungsobjekte in Datenbankarten umgesetzt werden. Die Abrechnungsobjekte werden beispielsweise in SQL-Datentypen für die Verwendung mit relationalen Datenbanken umgesetzt.
Der vorstehend beschriebene Serialisierungs/Entserialisierungs-Mechanismus wird auch verwendet, um die Mess- und Abrechnungsschnittstelle zwischen Netzdomänen zu unterstützen. Die Netzkantendomäne, die Pakete zum und vom Kundenendgerät übermittelt, leitet beispielsweise wiederum Pakete zu einer Anzahl von benachbarten Domänen. Genau wie Abrechnungsdaten vom Kunden zur Netzkantendomäne geleitet werden, so werden auch Abrechnungsdaten von einem Abrechnungsobjekt 71 in der Netzkantendomäne zu einem Abrechnungsobjekt 72 in einer benachbarten Domäne geleitet und die Zahlung wird durch den Betreiber der Netzkantendomäne an den Betreiber der benachbarten Domäne durchgeführt. In diesem Zusammenhang ist die Netzkantendomäne eine Einzelhandelsdomäne und die benachbarten Domänen sind Großhandelsdomänen. Wie in 7 gezeigt, ist die Architektur der Schnittstelle zwischen der Einzelhandelsdomäne und den Großhandelsdomänen eine rekursive Version der Schnittstelle zwischen der Einzelhandelsdomäne und dem Endkunden. Alle Mess- und QoS-Merkmale der Schnittstelle zum Endkunden sind jedoch in der Schnittstelle zwischen den Einzelhandels- und Großhandelsnetzen nicht erforderlich. Wenn, wie in diesem Beispiel, mehrere Großhandelsanbieter vorhanden sind, dann wird die aktuelle Leitungs- und/oder Adressenzuordnung im Einzelhandelsnetz abgefragt, um die Abrechnung zwischen den Großhandelsnetzen aufzuteilen. Dies ist effektiv eine andere Form von Identitätsabbildung I. Die Abbildung ist zwischen den Identitäten von jedem benachbarten Anbieter und ihren aktuellen Gruppen von Unicast-Adressen, Adressenpräfixen, Multicast-Adressen oder Nummern des autonomen Systems (AS) erforderlich. Dies ist in der Kantenarchitektur im Allgemeinen nicht erforderlich, da ein Kantenkunde typischerweise nur einen Anbieter aufweist. Wenn mehrere Anbieter vom Kunden verwendet werden würden, dann wird eine Abbildung zum Aufteilen der Abrechnung an der Kante auch verwendet. Wie vorher, kann die Messung von Verkehr zwischen Einzelhandels- und Großhandelsdomänen parallel zum Datenfluss abgetastet und durchgeführt werden – keine Blockierung ist erforderlich. Irgendein Paar von Netzanbietern könnte in der Praxis jeweils gegenseitige Kunden sein. In diesem Fall wird die Architektur für die Einzelhandels/Großhandels-Schnittstelle gespiegelt, so dass alle Funktionen in beiden Richtungen arbeiten. Irgendwelche Zahlungen zwischen Netzdomänen werden dann durch den Ausgleich der Produkte von jedem Abrechnungsfluss und der relevanten Preise bestimmt.
In einem Netz mit mehreren Domänen kann dann, wie in 8 gezeigt, eine "Großhandels"-Domäne 82 Abrechnungsdaten von einer Anzahl von Einzelhandelsnetzen 81, 83 empfangen. Diese Daten werden durch das Abrechnungsobjekt in der Domäne 82 angesammelt und dann zwischen weiteren benachbarten Domänen wie z. B. der Domäne 84 aufgeteilt. Die Art und Weise, in der die Abrechnungsdaten aufgeteilt werden, wird durch eine in der Domäne 82 gewartete gemittelte Randleitungstabelle bestimmt. 3a und 3b zeigen die Daten, die zwischen den Abrechnungsobjekten geleitet werden. In diesem Beispiel umfassen die Abrechnungsdaten: Abrechnungsidentität; Rechnungsdatensatzidentität; Dienstartidentifizierer; Quellenadresse; Zieladresse; Tarifidentität; Zeit; Periode (d. h. die durch den Rechnungsdatensatz abgedeckte Periode); Einheiten; Kosten; und Währung. Außerdem umfassen die Zahlungsdaten die Menge an Geld und die Währung der Zahlung.
4 zeigt den Messbereich innerhalb Protokollprofilen am Kundenendgerät und in der Einzelhandelsnetzdomäne. Idealerweise würden sich zwei Messpunkte innerhalb dieses Bereichs befinden, einer, dem der Kunde vertraut, und einer, dem das Netz vertraut, beispielsweise an den in der Fig. ausgewiesenen zwei Punkten (a). Für eine leichte Implementierung kann ein einzelner Messpunkt (b), dem beide Parteien vertrauen, verwendet werden. Dies könnte beispielsweise innerhalb eines sicheren Moduls wie z. B. einer kryptographischen Karte am Kundenendgerät implementiert werden. Als Alternative können Messungen an verschiedenen Punkten mit einer gewissen Möglichkeit für Diskrepanzen zwischen den Messungen durchgeführt werden. Im Netz befindet sich der praktische Messpunkt an der (den) ersten Zugangsvorrichtung(en), die für jeden Kunden Netzebenenköpfe (c) (IP in diesem Fall) untersucht (untersuchen). ISPs sollten nicht tiefer in ihrem Netz (d) messen, da ihr Zugangsnetz und ihre Zugangssysteme Verzögerungen und Verluste einführen.
Für einen individuellen Kunden (z. B. beim Einwählzugang) würde ein praktischer Punkt, an dem gemessen werden soll, auch längs der Netzebene, aber in ihrem Endsystemstapel (e) liegen. Idealerweise würden diese Messpunkte in jedem Stapel niedriger liegen, damit sie näher an der Schnittstelle zwischen den zwei Parteien liegen und weniger wahrscheinlich durch eine Konkurrenz im Stapel beeinträchtigt werden. Das Messen auf der Verbindungsebene (f-f) wäre jedoch ungeeignet, da nur einige gebührenpflichtige Parameter, die an der Netzebene festgelegt sind, jemals in den Verbindungsebenenrahmen widergespiegelt werden; Netzebenen-Multicast, End-End-Wartezeitanforderungen usw. können niemals an der Verbindungsebene sichtbar sein. Verbindungsebenenköpfe müssten auch ignoriert werden, wenn Paketgrößen für Bandbreitenberechnungen gemessen werden, um scheinbare Diskrepanzen zu vermeiden, wenn verschiedene Verbindungstechnologien miteinander verkettet werden.
In der Empfangsrichtung (den Stapel aufwärts) impliziert diese Wahl von Messpunkten, dass die niedrigeren Ebenen dimensioniert werden müssen (Puffergrößen, Unterbrechungs- und Thread-Zeitsteuerungsprioritäten), um mit den strengsten QoS-Anforderungen von höheren Ebenen zurechtzukommen. Wenn Rahmen den physikalischen Medien entnommen werden, muss die Maschine Daten den Stapel aufwärts leiten können, ohne irgendeine Möglichkeit, dass Nutzungsgebührdaten verworfen werden (z. B. aufgrund eines durch eine Unterbrechungskonkurrenz verursachten Pufferüberlaufs), bevor sie zur Netzebene gelangen. Genau an der Netzebene soll der Dienst des ISP gemessen werden und ist dort es am zweckmäßigsten, dass QoS-Anforderungen die korrekte differentielle Behandlung der verschiedenen Flüsse steuern, wenn sie weiter den Stapel aufwärts geleitet werden (an Endsystemen) oder weiter geleitet werden (an Routern).
Die vorstehend beschriebenen Messobjekte können mit geeigneten Modifikationen unter Verwendung von öffentlich erhältlicher Netzzählsoftware wie z. B. des NeTraMet-Systems von Nevil Brownlee implementiert werden. Dies ist ein Softwarezähler, der der IETF-Internet-Abrechnungsarchitektur entspricht, die in RFC 2063 und RFC 2064 beschrieben ist. Der Zähler baut unter Verwendung von "Paketschnüffeln" Paket- und Bytezählwerte für Verkehrsflüsse auf, die durch ihre Endpunktadressen definiert sind. Obwohl Adressen im Allgemeinen Ethernet-Adressen sein können, werden nur Protokolladressen (IP, DECnet, EtherTalk, IPX oder CLNS) oder "Transport"-Adressen (IP-Portnummern usw.) oder eine beliebige Kombination von diesen bei den IP-Adressen der vorliegenden Implementierung verwendet. Die zu beobachtenden Verkehrsflüsse werden durch einen Satz von Regeln festgelegt, die durch ein "Manager"-Programm zu NeTraMet heruntergeladen werden. Verkehrsflussdaten werden über SNMP (Simple Network Management Protocol, einfaches Netzmanagementprotokoll) von einem "Sammler"-Programm gesammelt.
5a bis 5e sind Klassendiagramme, die eine Implementierung der vorstehend beschriebenen Mess- und Abrechnungsobjekte darstellen. Die Klassendiagramme sind als Reihe von Ansichten gezeigt.
Die Steueransicht (5a) gruppiert die Klassen/Schnittstellen, die das Ermöglichen einer Steuerung über die Abrechnungsklasse betreffen, einschließlich Meldesteuerung, mit der Zählung in Beziehung stehende Steuerung und allgemeine Steuerfunktionen. Diese Ansicht betrifft auch die Ereignisverteilung. Die Steuerung über die Abrechnungsklasse ist gemäß der Art von Steuerung getrennt. Deshalb stehen vier Schnittstellen zur Verfügung. Zwei von diesen Schnittstellen stellen eine direkte Steuerung über das Verhalten des Abrechnungsobjekts bereit und die zwei anderen stehen mit einem Java-Ereignismodell in Zusammenhang, das verwendet wird, um sowohl Meldeinformationen als auch Messinformationen zu übermitteln. Die ActControl-Schnittstelle stellt eine Steuerung über die Abrechnungsklasse bereit, die das Abrechnungsverhalten im Allgemeinen betrifft. Sie stellt sowohl Verfahren zum Festlegen eines Verhaltens oder von Eigenschaften und Verfahren zum Herausfinden über das aktuelle Verhalten des Abrechnungsobjekts breit. Diese Schnittstelle wird beispielsweise verwendet, um den Namen des Abrechnungsobjekts festzulegen oder das Act-Objekt abzufragen, um einen Namen herauszufinden, der dem Act-Objekt vorher gegeben wurde. Die Act-Report-Schnittstelle stellt eine Steuerung über Themen bereit, die mit der Abrechnungsmeldung in Beziehung stehen. Steuerungsaufrufe stehen direkt mit dem Meldeverhalten des Abrechnungsobjekts in Beziehung. Ein Verfahren, das addReportListener() genannt wird, wird beispielsweise verwendet, um Interesse an Meldeinformationen zu registrieren. Sobald die Registrierung wirksam ist, definieren anschließende Aufrufe an andere Steuerverfahren das Verhalten, wie z. B. die Meldehäufigkeit, die Anforderung für eine sofortige Meldung, Meldesicherheitseigenschaften usw. Die zwei anderen Hörerschnittstellen (Report & Measurement), die die Abrechnungsklasse implementiert, werden verwendet, um anzugeben, dass Abrechnungsobjekte an Abrechnungsberichten und Messungen interessiert sind.
Die Abrechnungsberichtsansicht (5b) gruppiert die Klassen/-Schnittstellen um, die das Meldeverhalten und den Meldeprozess im Abrechnungsobjekt betreffen. Das Abrechnungsobjekt hört auf die Abrechnungsberichte und erzeugt ebenso solche Ereignisse. Abrechnungsobjekte erzeugen Abrechnungsberichte und verteilen sie (unter Verwendung des herkömmlichen Java-Ereignismodells) zu Objekten, die ihr Interesse an solchen Ereignissen registriert haben. In der vorliegenden Implementierung wird Flexinet (eine CORBA-artige verteilte Programmierinfrastruktur) verwendet, um die Kommunikation zwischen Objekten zu unterstützen, so dass die Berichte von Objekten stammen können, die vom Abrechnungsobjekt entfernt sind. Die Abrechnungsklasse implementiert die ReportListener-Schnittstelle, so dass sie diese Abrechnungsberichte ebenso empfangen kann. Die Abrechnungsberichtereignisse sind von einer Report-Event-Klasse. Ein Ereignis in dieser Klasse ist ein herkömmliches Java-Ereignis, das ein Berichtobjekt umfasst. Das Hauptattribut in der Berichtsklasse sind Datensätze. Datensätze sind ein einfacher Vektor von Abrechnungsdatensätzen. Diese Datensätze sind in der Abrechnungsspeicheransicht (5c) beschrieben. Die ActReport-Ctrl-Schnittstelle definiert die Steueraufrufe in Bezug auf den Abrechnungsmeldeprozess eines Abrechnungsobjekts. Aufrufe stehen für ein Objekt zur Verfügung, um Interesse an Abrechnungsberichten zu registrieren, das Interesse zu deregistrieren und den Meldeprozess zu steuern.
Die Abrechnungsspeicheransicht (5c) gruppiert die Klassen/-Schnittstellen um, um die mit der dauerhaften Speicherung der Abrechnungsinformationen in Beziehung stehenden Klassen zu zeigen. Ein Abrechnungsobjekt besitzt eine Datenbank von Abrechnungsdatensätzen. Die Datensatzart hält Abrechnungsinformationen, die nicht bewertet sind. Bewertete Informationen sind Gegenstand einer anderen Klasse. Die Datenbank-Klasse ist ein einfacher Vektor von Datensatzobjekten und sie kann zu einer Datei auf einem externen Speichermedium serialisiert werden. Die Datenbank ist auch für das Zurückführen von Abrechnungsdatensätzen, die gemeldet werden müssen, verantwortlich.
Die Abrechnungszähleransicht (5d) gruppiert die Klassen/Schnittstellen um, um die mit dem Zählaspekt der Abrechnungsklasse in Beziehung stehenden Klassen/Schnittstellen zu zeigen. Dies betrifft sowohl den Empfang von Messinformationen in den Abrechnungsobjekten als auch die Steuerung des Zählers sowie die Darstellung einer einfachen Zähler-Klasse. Die Zähler-Klasse verwendet ein "Pulsar"-Objekt, das Impulsereignisse nach Bedarf erzeugt. Die Frequenz der Impulse wird vom Zähler-Objekt festgelegt. Beim Empfang von Impulsen erzeugt der Zähler Objekte des Typs MeasurementEvent. Objekte, die die MeasurementListener-Schnittstelle implementieren und die ihr Interesse an Messergebnissen registriert haben, empfangen dann diese Ereignisse über ein MeasurementHandler-Verfahren. Wie vorher angegeben, können das Zähler-Objekt und eines oder mehrere der Objekte, die Messereig nisse empfangen, voneinander entfernt sein. Ein Messereignis ist ein herkömmliches Java-Ereignis und umfasst einen Messdatensatz des Typs MeasurementRecord. Ein Abrechnungsobjekt erhält Messinformationen von einem Zähler, über den es eine gute Steuerung über die MeterControl-Schnittstelle hat. Ein typisches Beispiel der Steuerung ist die Messmeldehäufigkeit, d. h. ein Abrechnungsobjekt kann die Häufigkeit steuern, mit der ein Zähler-Objekt Berichte zu ihm sendet. Diese Steuerschnittstelle ist auch diejenige, die zu verwenden ist, um Interesse an Messergebnissen zu registrieren.
Die Abrechnungsmischansicht (5e) gruppiert die Klassen/-Schnittstellen um, um alle anderen Klassen zu zeigen, die nicht in die vorher beschriebenen Ansichten passen. Dies umfasst mit Java-Bean in Beziehung stehende Klassen, Klassen zum Abarbeiten des Codes und der graphischen Benutzerschnittstellen (GUI). Die AccountingBeanInfo-Klasse ist eine mit JavaBean in Beziehung stehende Klasse, die die Beschreibung einiger Attribute an der Abrechnungs-Klasse modifiziert, wenn diese Eigenschaften in der Bean-Box oder in irgendeinem anderen Komponentenaufbauwerkzeug graphisch angezeigt werden müssen. Die Go- und MeterGo-Klassen implementieren nur ein Hauptverfahren. Go wird verwendet, um ein Abrechnungsobjekt und MeterGo ein Zähler-Objekt zu starten. Die AccountingGUI-Klasse ist für die GUI verantwortlich, die mit den Abrechnungsobjekten in Beziehung steht. Dem Zähler-Objekt ist keine GUI zugeordnet. Die Accounting-GUI ist in 6 gezeigt. Der obere Teil der GUI umfasst Daten vom Abrechnungsobjekt und der untere Teil betrifft die über das Abrechnungsobjekt verfügbare Steuerung. Der Steuerteil steht direkt mit den Steuerschnittstellen in Beziehung, die für die Abrechnungsobjekte verfügbar sind. Die Abrechnungsklasse kennt die GUI nicht, da die Referenz von der GUI zur Abrechnungsklasse besteht.
Die vorstehend beschriebenen Abrechnungsmechanismen können in Kombination mit Verträgen zwischen Kunden und Einzelhandels- und Großhandelsnetzen verwendet werden, um eine Verpflichtung zum Zahlen festzulegen und festzulegen, von wem eine Zahlung erwartet wird. Der folgende Abschnitt beschreibt verschiedene Verrechnungsstellenmodelle für die Durchführung von Zahlungen. Die in diesem Abschnitt beschriebenen Systeme können in Verbindung mit oder unabhängig von den vorstehend beschriebenen speziellen Abrechnungsmechanismen verwendet werden.
Zahlungsverrechnungsstelle
Ebenso wie "Verpflichtung zum Zahlen" und "von wem eine Zahlung erwartet wird" besteht auch die Frage dessen, wer bezahlt werden sollte. Jeder Kanten-ISP kann auf einer "Halbkreis"-Basis für sowohl seinen gesandten als auch empfangenen Dienst bezahlt werden. Andere Geschäftsmodelle können jedoch unterstützt werden. In einem Geschäftsmodell, in dem ISPs nicht erwarten, dass eine Zahlung für den ganzen gesandten und empfangenen Verkehr an alle Kantenanbieter durchgeführt wird, könnte ein Kunde statt dessen seinen eigenen Anbieter zugunsten beider (aller) Enden wie beim Fernsprechen bezahlen. Ein weiteres Abrechnungsfeld würde erforderlich scheinen – ein "Zahlungsempfänger"-Feld. Dieses alternative Geschäftsmodell könnte beispielsweise die Entscheidung hinsichtlich dessen sein, an welche(s) Ende(n) eine Zahlung von Kantenkunden, die in das System eingetreten sind, auf einer Basis pro Fluss durch Kunden durchgeführt wird. Wir werden dieses Modell "Anbieter-Verrechnungsstellen"-Modell aus Gründen, die klar werden, wenn wir weiter gehen, nennen. Dies ist in 9 gezeigt. Hier kommunizieren Endkunden 91, 92 über eine Anzahl von Zwischennetzen 93. Die Geldflüsse zwischen Anbietern in diesem Modell hängen davon ab, an welchen Enden eine Zahlung in das System auf einer Basis pro Fluss (oder pro Paket) eintritt. Für einige Flüsse kann sogar eine proportionale Aufteilung der Kosten zwischen den Enden bestehen. Wegen der Geschäftsmodellflexibilität könnte daher anstatt einfach "lokales" oder "entferntes" Ende anzugeben, das "Zahlungsempfänger"-Feld statt dessen ein "Zahlungsempfänger-Prozentsatz"-Feld sein – wobei der Prozentsatz der Gesamtkosten, die durch den Kunden am Ende bezahlt werden sollen, berücksichtigt wird. Somit wäre es gewöhnlich 100 % oder 0 % in den typischen Fällen von "vollständig an den lokalen Anbieter bezahlt" oder "vollständig an entfernt". Der Ausgleich wäre die Zahlung des entfernten Endes. Es ist jedoch zu beachten, dass der wahrgenommene Zweck dieses Modells die Transaktionseffizienz ist, wenn der lokale Zahlungsempfänger 100 % erhält. Es bestehen jedoch gewisse Nachteile für das "Anbieter-Verrechnungsstellen"-Modell:
Wie bereits aufgezeigt, müsste das "Zahlungsempfänger-Prozentsatz"-Feld eine Abrechnung zwischen Anbietern steuern, ansonsten würden die Einnahmen eines Kanten-ISP und seiner Stromaufwärts-Anbieter von einem Faktor abhängen, der vollständig außerhalb seiner Steuerung liegt – an welches Ende seine Kunden wählen, eine Zahlung durchzuführen. Dem "Zahlungsempfänger-Prozentsatz"-Feld müssten daher Stromaufwärts-Anbieter vertrauen. Um zu helfen, zu verhindern, dass am Feld manipuliert wird, müsste es durch den entfernten ISP signiert werden. Signierte Felder werden ohne Verlieren der Signaturintegrität zusammengefügt. Die Zusammenfügung könnte durch die Software durchgeführt werden, die durch einen Dritten signiert wird, dem alle beteiligten Parteien (TTP) vertrauen, und dann der Datensatz durch den TTP erneut signiert werden. Die Zusammenfügungs-Software müsste jedoch auch auf einem Hauptrechner laufen, dem der TTP vertraut. Ferner würde die Verwendung dieses Modells bedeuten, dass alle Kanten-ISPs irgendeinen entfernten ISP von der entfernten Adresse identifizieren können müssten, etwas, das mit hierarchischer Leitung nicht möglich ist. Trotzdem haben wir bereits festgestellt, dass die Zahlungsschnittstelle des entfernten ISP in ein Protokoll höherer Ebene zwischen Endstationen geleitet werden kann. Es wäre nur geringfügig komplexer für sie, dies in den Abrechnungsdatensatz aufzunehmen. Der ISP müsste jedoch immer noch geeignete Prüfungen durchführen, ob dies ein gültiger ISP wäre und ob er der entfernten Adresse entsprechen würde. Sobald er die Adresse hat, wird dies trivial, aber ineffizienter und negiert gewöhnlich den Vorteil des lokalen ISP, der die Verrechnung über seinen Stromaufwärts-Anbieter durchführt. Eine noch weitere Komplikation könnte für einige zukünftige Anwendungen eingeführt werden, wenn die Aufteilung der Zahlung zwischen den Parteien nicht fest wäre, sondern von Eigenschaften des Flusses oder anderen Parametern abhängen würde, die nur auf einer höheren Ebene verständlich sind – höher als der Anbieter normalerweise interessiert wäre. Dies ist auch ein Problem für das Feld des "erwarteten Zahlenden", aber in diesem Fall ist das Feld nur informativ, im Gegensatz zum "Zahlungsempfänger-Prozentsatz"-Feld im "Anbieter-Verrechnungsstellen"-Modell.
Die Zahlung sollte Idealerweise aufgeteilt werden, wobei die aktuellen Preise aller Kantenanbieter berücksichtigt werden, die schließlich bezahlt werden. Die einzige Alternative (im internationalen Abrechnungsratensystem (IARS) für Fernsprechen verwendet) besteht darin, dass ISPs Kompromisspreisen zwischen ihnen zustimmen, die Preisinkonsistenzen mitteln.
Aufgrund der viel längeren Anbieterketten, die typischerweise im Internet zu finden sind, werden potentiell unannehmbare Verzögerungen eingeführt, bevor die Einnahmen an der korrekten Stelle ankommen. Irgendeine Verzögerung in der Verrechnung erhöht die Kosten des Zahlungssystems erheblich, da zusätzliche Vertrauensmechanismen aufgerufen werden müssen, während die Zahlung unbestätigt bleibt. Diese Vertrauensmechanismen müssen auf die Kantenkunden, nicht nur die Anbieter, angewendet werden, wodurch die Gesamtkosten des Systems erheblich erhöht werden.
Trotz dieser Begrenzung scheint ein solches Modell die Anzahl von Zahlungstransaktionen zu verringern. Wenn die Parteien in einer Internet-Telephonkonversation beispielsweise beide (alle) durch den Anrufer bezahlt werden, scheint es für den Anrufer weniger komplex, die Zahlungen von jedem an seinen eigenen ISP zu bezahlen, dann den ISP den korrekten Betrag zu seinem Stromaufwärts-Anbieter als Teil einer Massetransaktion zu übermitteln. Andererseits muss in einem "Dritt-Verrechnungsstellen"-Modell (in 10 gezeigt) der Anrufer die Zahlung zwischen beiden (allen) ISPs von beiden (allen) beteiligten Parteien aufteilen.
Deshalb besteht die Unterscheidung zwischen den Namen der zwei Modelle in der Verrechnungsstelle, nicht darin, wer bezahlt wird. Beide Modelle enden mit Kanten-ISPs, die auf Halbkreisbasis bezahlt werden. Der Unterschied liegt nur im Weg, den die Zahlung vom Zahlenden zum Zahlungsempfänger nimmt. Mit der Anbieter-Verrechnungsstelle folgt die Zahlung dem Datenpfad. Entlang des Weges nehmen Anbieter ihren Anteil, wobei zwei Arten von Geldaufteilung miteinander vermischt werden: Großhandelsanteil und Halbkreisaufteilung.
In einem "Dritt-Verrechnungsstellen"-System (auch Ende-zu-Ende-Verrechnungsstelle genannt) behandelt die Verrechnungsstellenhausrolle die Halbkreisaufteilung (einschließlich der problemlosen Preisunterschiede zwischen den zwei Enden), wobei die Abrechnung zwischen Anbietern rein über Großhandel belassen wird. Die Dritt-Verrechnungsstelle kann auf einer der Managementplattformen 10 oder auf einer zusätzlichen Plattform, die mit einer der Netzdomänen verbunden ist, implementiert werden. Anbieter oder Kunden können die Verrechnungsstellenhausrolle annehmen, aber das Abrechnungsinformationsmodell basiert auf einem Dritt-Verrechnungsstellensystem, um den allgemeinsten Fall zu ermöglichen. Zur Verdeutlichung, ob der bezahlende Kunde eine Zahlung an ein reserviertes Verrechnungsstellenhaus, direkt an den ISP am entfernten Ende oder sogar direkt an den entfernten Kunden durchführt, so dass er seinen eigenen ISP bezahlen kann, ist die Rolle der Verrechnungsstelle in allen Fällen separat, selbst wenn kein separates Unternehmen besteht, um die Funktion zu erreichen. Der letzte Fall ist speziell – die Verrechnungsstellenrolle ist null, aber erscheint immer noch im Informationsmodell. Die Gebühren für alle Enden werden während der Abrechnung nicht zusammengefügt. Wenn die Halbkreisaufteilung durch die Anbieterkette erreicht wird, muss dies von der Abrechnung für Großhandel separat gehalten werden. Wenn es dies nicht ist, sind die Arten des Modells, die in die Infrastruktur eingebaut werden können, eingeschränkt.
Nachdem die Rolle der Verrechnungsstelle getrennt wurde, zeigt dies nun explizit, dass eine Telephongesellschaft auch eine andere Rolle in ihr Geschäft eingebunden hat – jene des "Sitzungshändlers". Das heißt, die Kanten-Telephongesellschaft bietet Telephonsitzungen mit festen Preisen, aber der Bereich von Preisen ist geringer als die Anzahl von möglichen Weisen, in denen der Preis variieren könnte, wenn er einfach aus allen Ende-zu-Ende-Preisen bestehen würde, die durch Anbieter berechnet werden, die erforderlich sind, um jede Sitzung zusammenzusetzen. Wiederum kann diese Rolle vom Kantenkunden in der Internetwelt übernommen werden, aber es ist möglich, dass andere Parteien Preise für Übertragungen durch Verkaufen von IP-Dienst anbieten, während Schwankungen über Anbieter in den Preisen, mit denen sie im Großhandel belastet werden, absorbiert werden. Diese Rolle kann auch weiterhin von Telephongesellschaften und auch ISPs übernommen werden.
Es ist redundant, in Abrechnungsmeldungen anzugeben, welches Ende tatsächlich bezahlt wird. Wer schließlich die Zahlung empfangen sollte, ist impliziert, da die Regel nun darin besteht, dass Konten für andere Anbieter nicht mit Konten für den lokalen Anbieter zusammengefasst werden sollten. Das Korrolar besteht darin, dass irgendeine Abrechnung implizit mit Zahlungen in Beziehung steht, die schließlich an den lokalen Anbieter durchgeführt werden. Zu sagen, wer bezahlt wird, ist während der Abrechnung redundant. Es ist nur zum Zeitpunkt der Zahlung relevant. Dann ist es wesentlich zu sagen, für wen die Zahlung schließlich vorgesehen ist, wenn sie einer Verrechnungsstellenorganisation gegeben wird.
11 zeigt die Verwendung von Kantenbewertung in der Netz-Fig. Ein Paket ist als mit Multicast von N_a in N_b und weiter in die anderen Netze gesandt gezeigt. Da Multicast ein allgemeiner Fall von Unicast ist, ermöglicht dies uns, beide Topologien zu modellieren. Wir können auch die Topologie als Ansammlung behandeln, indem die Richtung der Übertragung umgekehrt wird. Der Begriff Paket wird verwendet, aber die Pfeile könnten Flüsse von Paketen einer ähnlichen Klasse für eine gewisse Zeit darstellen. Das Paket oder der Fluss, der modelliert wird, könnte Daten oder Signalgebung sein. Es ist nicht erforderlich, Multicast mit mehreren Quellen separat zu modellieren, da Pakete von verschiedenen Quellen immer getrennt bleiben. 11 hebt die Bewertung zwischen den Netzen N_a und N_b hervor. W_bas und W_bar bedeuten die Gewichtungen pro Richtung, die auf die Gebühr angewendet werden, die N_a auf N_b für das Senden von Daten zu N_b bzw. für das Empfangen von Daten von N_b anwendet, während W_abs und W_abr die Gewichtungen sind, die N_b anwendet, wenn N_a für das Senden von Daten zu N_a bzw. das Empfangen von Daten von N_a belastet wird. Jeder gewichtete Preis dient zur Übertragung zwischen der fraglichen Kante und der entfernten Kante des Internets, nicht nur der entfernten Kante dieses Anbieters. Es gibt vier Preisgewichtungen wie diese an jeder Schnittstelle zwischen Netzen, aber die Gewichte würden verschiedene Werte annehmen, wenn nicht die Nachbarn denselben Status besitzen. Folglich hängt die Zahlung für Verkehr in irgendeiner Richtung über jede Schnittstelle von der Differenz zwischen den zwei gewichteten Preisen, die von den Netzen beider Seiten angeboten werden, ab. Mit anderen Worten, keine Annahmen werden darüber gemacht, wer der Anbieter ist und wer der Kunde ist; dies hängt rein vom Vorzeichen der Differenz zwischen den Gebühren zu irgendeiner Zeit ab. Kantenkunden (beispielsweise N_c) haben natürlich keinen Anbieterstatus auf dem Netzmarkt. Für alle j gilt folglich W_cjr = 0. Wir können dann Szenarios wie "nur Sender zahlen" oder "nur Empfänger zahlen" analysieren, indem alle Empfangsgewichte auf Null oder alle Sendegewichte auf Null gesetzt werden. Die Stabilität einer Taktik kann beispielsweise durch Bewerten, ob ein Netz von einer Außenseitertaktik profitieren würde, bestimmt werden.
"Nur Sender zahlen" oder "nur Empfänger zahlen" fördert gewöhnlich die Wanderung von Kunden, die hauptsächlich Empfänger sind, und von jenen, die hauptsächlich Sender sind, zu verschiedenen Anbietern. Diese Situation ist haltbar, da der Anbieter mit all den nicht bezahlenden Kunden seine ganzen Einnahmen von seinem Verbindungsgeschäft erhält. Beide Szenarien bleiben stabil, da, wenn ein Netz zum Außenseiter wird (z. B. nur Empfänger belastet, wenn jeder sonstige nur Sender belastet), sowohl vorherrschende Sender als auch Empfänger eine Wahl eines preiswerteren Anbieters haben. Daher verringert das Einkommen in das ganze System die Garantie, dass der Außenseiteanbieter zuerst Pleite gehen würde – ausreichend abschreckend, um Außenseiter zu sein! Diese beiden Taktiken machen jedoch natürlich die Netznutzung ineffizient und beide sind instabil, wenn es um Multicast (und folglich Ansammlung) geht.
Im Gegensatz dazu ist "Sender und Empfänger zahlen" sowohl in Unicast- als auch Multicast-Fällen stabil. Es führt auch nicht zu einer ineffizienten Netznutzung im Gegensatz zu den obigen Fällen. Es ist auch möglich, für unterschiedliche Ausgleiche von vorherrschenden Sendern und Empfängern zu sorgen, indem der Sendepreis anders als der Empfangspreis gewichtet wird. Wenn beispielsweise wenige große vorherrschende Sender, aber viele kleine vorherrschende Empfänger vorhanden sind, kann die Wirtschaftlichkeit des Maßstabes beim Managen eines großen Kunden in einer niedrigeren Sendergewichtung widergespiegelt werden. Ebenso können die Ineffizienzen von Multicasts zu kleineren Empfängergemeinschaften im Ver gleich zu mehreren Unicasts durch geringfügiges Gewichten der Multicast-Senderbewertung gehemmt werden.
Obwohl die bisher beschriebenen Beispiele im Zusammenhang mit vereinigten Paketdatennetzen wie z. B. dem Internet standen, können viele Aspekte der Erfindung auch in anderen Netzarten vorteilhaft verwendet werden, wie z. B. in einem leitungsvermittelten PSTN (öffentlichen Fernsprechwählnetz). 13 zeigt ein Beispiel der Erfindung, das in diesem Zusammenhang angewendet ist. In diesem Netz sind Kundenendgeräte 131, die in diesem Beispiel so genannte intelligente Telephone sind, d. h. Telephone, die einen Mikroprozessor und eine Datenschnittstelle enthalten, über lokale Vermittlungsstellen 132 und Fernvermittlungsstellen 133 mit den Telephonnetzen verbunden. Die Fernvermittlungsstellen 133 sind über ein Netz 2 der zentralen Zeichengabekanäle SS7 (Signalisierungssystem Nummer 7) mit einem Dienststeuerpunkt 135 verbunden, der für die Ausführung von fortschrittlichen Anrufsteuerfunktionen verantwortlich ist. Der Dienststeuerpunkt 135 ist auch mit einem Betriebsunterstützungsserver 136 verbunden, der für Abrechnungsoperationen verantwortlich ist und der in diesem Beispiel die Einstellung von Tarifen für das Netz steuert. Der OSS-Server und die Kundenendgeräte umfassen Tarif-Entitäten (TE). Das feste PSTN-Netz ist auch über einen Gateways 137 mit einem GSM-Mobilnetz 138 verbunden. Basisstationen BS im Mobilnetz übermitteln Signale zu intelligenten Mobiltelephonen 139. Im Betrieb werden die Netztarife über das PSTN-Netz und über das GSM-Netz zu Kundenendgeräten verteilt. Zweckmäßigerweise kann der Tarif wieder die Form von Java-Funktionen annehmen, die auf Prozessoren in den Kundenendgeräten ausgeführt werden. Die Java-Funktionen können als Internet-Pakete geleitet werden. In einer Implementierung können diese Internet-Pakete über die PSTN-Netze und GSM-Netze selbst verteilt werden. Die Pakete können beispielsweise unter Verwendung der MTP-Schicht (Nachrichtentransportteil-Schicht) eingekapselt und zu den Fernvermittlungsstellen transportiert werden und können weiter zu den Kundenendgeräten unter Verwendung von Außerbandsignalisierung übermittelt werden. Alternativ kann eine separate Datenverbindung zwischen dem OSS-Server und den Kundenendgeräten über das öffentliche Internet hergestellt werden. Wie in den obigen Beispielen überwacht der Netzbetreiber die Belastung von Ressourcen innerhalb des Netzes und kann Signale zu den Tarif-Entitäten in den Kundenendgeräten übertragen, um den Tarif zu ändern, um die Knappheit oder dergleichen von relevanten Ressourcen widerzuspiegeln. Die Kundenendgeräte können selbst die Netzbelastung überwachen und automatisch Änderungen in den Tarifen erzeugen. Die Nutzung von Netz-Ressourcen kann lokal durch die Kundenendgeräte anstelle der herkömmlichen Abrechnung, die innerhalb des Netzes ausgeführt wird, gemessen werden. Der Netzbetreiber kann die Messung von Nutzungsdaten durch Ausführen einer Abtastung überwachen, wie vorher beschrieben.

Claims

Verfahren zum Betreiben eines Kommunikationsnetzes (1), das umfasst: a) bei jedem von mehreren Kundenendgeräten (5, 8, 9) Messen der Nutzung von Netz-Ressourcen durch das jeweilige Kundenendgerät; und b) anschließend Berechnen einer Netz-Nutzungsgebühr aus den im Schritt a) erzeugten Messdaten; dadurch gekennzeichnet, dass: c) ein Betreiber des Kommunikationsnetzes die Nutzung der Netz-Ressourcen durch ein oder mehrere Kundenendgeräte abtastet, indem er nur einen Teil der Nutzung durch das oder jedes entsprechende Kundenendgerät misst und dies bezüglich der abgetasteten Nutzung mit der Nutzung der Netz-Ressourcen, die durch das oder jedes entsprechende Kundenendgerät im Schritt a) gemessen wird, und/oder mit der Netz-Nutzungsgebühr, die im Schritt b) berechnet wird, vergleicht.
Verfahren nach Anspruch 1, das ferner einen Schritt des Ansammelns von Messdaten, die durch eine Reihe von Messungen an entsprechenden Kundenendgeräten erzeugt werden, umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner das Speichern der Messdaten umfasst.
Verfahren nach Anspruch 3, das ferner das Speichern von Daten, die einen auf die Messdaten anwendbaren Tarif identifizieren, zusammen mit den Messdaten umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln von im Schritt a) erzeugten Daten oder einer aus den im Schritt a) erzeugten Daten berechneten Nutzungsgebühr an ein durch einen Netzbetreiber kontrolliertes Netzabrechnungsobjekt umfasst.
Verfahren nach Anspruch 5, das das Übermitteln einer aus den Messdaten berechneten Nutzungsgebühr an das Netzabrechnungsobjekt umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln von Messdaten an ein von dem Kundenendgerät entferntes System umfasst.
Verfahren nach Anspruch 5 oder 6, bei dem der Abtastschritt das Abtasten nur eines Teils des zwischen einem Kundenendgerät und dem Netz kommunizierten Verkehrs umfasst und für den abgetasteten Verkehr ferner das Vergleichen der auf dieser Weise abgetasteten Netznutzung mit den Daten, die von dem jeweiligen Kundenendgerät an das Netzabrechnungsobjekt übermittelt werden, und dadurch das Erfassen jeglicher Diskrepanz umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Netzabrechnungsobjekt so konfigurierbar ist, dass es Daten von einem durch den Netzbetreiber kontrollierten Messobjekt oder von einem Kundenendgerät empfängt.
Verfahren nach Anspruch 9, bei dem ein Kundenabrechnungsobjekt, das dem Kundenendgerät zugeordnet ist, so konfigurierbar ist, dass es Daten zu dem Netzabrechnungsobjekt leitet.
Verfahren nach Anspruch 9 oder 10, das das Umschalten des Netzabrechnungsobjekts zwischen einer Konfiguration, in der Daten von dem Messobjekt empfangen werden, und einer weiteren Konfiguration, in der Daten von dem Kundenendgerät in Reaktion auf ein bei dem Netzabrechnungsobjekt empfangenes Steuersignal empfangen werden, umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner das Übermitteln eines Tarifs an jedes der Kundenendgeräte und das Berechnen der Netz-Nutzungsgebühr bei jedem der Endgeräte aus dem Tarif und aus den Abrechnungsdaten umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Kommunikationsnetz ein vereinigtes Datennetz ist, das mehrere Netzdomänen (2A–2C) umfasst.
Verfahren nach Anspruch 13, das umfasst: Kommunizieren von Verkehr zwischen einem Kundenendgerät (5) und einer an das Kundenendgerät angeschlossenen ersten Netzdomäne (2A); ferner Kommunizieren des Verkehrs zwischen der ersten Netzdomäne und einer an die erste Netzdomäne angeschlossenen zweiten Netzdomäne (2B); Kommunizieren von Netznutzungsdaten von dem Kundenendgerät zu einem ersten Netzabrechnungsobjekt in der ersten Domäne; Kommunizieren von Abrechnungsdaten zwischen dem ersten Netzabrechnungsobjekt und einem zweiten Netzabrechnungsobjekt in der zweiten Domäne.
Verfahren nach Anspruch 14, das umfasst: Bestimmen der Identität einer zweiten Domäne aus einer Stromleittabelle in der ersten Netzdomäne, wobei die zweite Domäne Daten mit dem Kundenendgerät über die erste Netzdomäne kommuniziert, und Übermitteln von Netznutzungsdaten für das Kundenendgerät zu der durch die Stromleittabelle identifizierten zweiten Domäne.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Messschritt das Zählen der Datenmenge umfasst, die in Paketen kommuniziert wird, die zwischen dem Kundenendgerät und dem Kommunikationsnetz übertragen werden.
Verfahren nach Anspruch 16, das das Messen sowohl von Paketen, die bei dem Kundenendgerät empfangen werden, als auch von Paketen, die von dem Kundenendgerät gesendet werden, umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Zahlung für die Netznutzung an eine Dritt-Verrechnungsstelle (10) erfolgt.
Verfahren nach einem der Ansprüche 1 bis 18, das das automatische Verändern eines Tarifs für die Netznutzung in Abhängigkeit von der Belastung des Netzes und das Berechnen einer Netz-Nutzungsgebühr durch Anwenden des Tarifs auf die Messdaten umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übertragen von Paketen auf dem Netz mit mehreren verschiedenen Dienstklassen umfasst.
Verfahren nach Anspruch 20, das das Schicken der Pakete durch einen Paket-Router und in dem Paket-Router das Bestimmen der Dienstklassen, die auf die Pakete anwendbar sind, sowie eine unterschiedliche Zeitsteuerung der Pakete in Abhängigkeit von der jeweiligen Dienstklasse umfasst.
Verfahren nach Anspruch 21, bei dem ein Schritt des Überwachens der Klassifizierung von Paketen für die Bestimmung der Berechtigung eines Pakets für eine jeweilige Dienstklasse an einem von dem Router entfernten Ort ausgeführt wird.
Verfahren nach Anspruch 22, bei dem der Schritt des Überwachens bei einem Kundenendgerät ausgeführt wird.
Verfahren zum Betreiben eines Kommunikationsnetzes nach Anspruch 1, wobei das Netz eine oder mehrere Netzdomänen umfasst, wobei die oder jede Netzdomäne durch einen jeweiligen Netzbetreiber betrieben wird, wobei das Verfahren umfasst: i) Aufbauen eines Datenflusses von einem mit dem Netz verbundenen Quell-Kundenendgerät zu wenigstens einem mit dem Netz verbundenen Ziel-Kundenendgerät; ii) Übermitteln von Tarifdaten von dem oder jedem Netzbetreiber zu einer Verrechnungsstellen-Entität; iii) Übermitteln von Tarifdaten für einen Ende-zu-Ende-Fluss von der Verrechnungsstellen-Entität zu wenigstens einem der Quell- und Ziel-Kundenendgeräte; wobei der Schritt a) umfasst: iv) Messen der Datenmenge, die von dem Quell-Kundenendgerät in das Netz fließt, und der Datenmenge, die von dem Netz zu dem oder jedem Ziel-Kundenendgerät fließt, bei jedem entsprechenden Kundenendgerät; wobei das Verfahren ferner umfasst: v) Übermitteln von im Schritt iv) erzeugten Messdaten an die Verrechnungsstellen-Entität; vi) bei der Verrechnungsstellen-Entität Berechnen einer Gebühr aus den Messdaten und aus dem Tarif; vii) Ausführen einer Zahlung von der Verrechnungsstellen-Entität an einen oder mehrere des einen oder der mehreren Netzbetreiber in Übereinstimmung mit der berechneten Gebühr; und viii) Übermitteln einer Rechnung in Übereinstimmung mit dem Ende-zu-Ende-Tarif von der Verrechnungsstellen-Entität an wenigstens einen der Quell- und Zielkunden; wobei der Schritt c) das Abtasten der Nutzung der Netz-Ressourcen durch eines oder mehrere der Kundenendgeräte durch Messen nur eines Teils der Nutzung durch das oder jedes entsprechende Kundenendgerät und das Vergleichen dieses Teils bezüglich der abgetasteten Nutzung mit der Nutzung der Netz-Ressourcen, die durch das oder jedes entsprechende Kundenendgerät im Schritt iv) gemessen wird, und/oder mit der Netz-Nutzungsgebühr, die im Schritt vi) berechnet wird, umfasst.
Verfahren nach Anspruch 8 oder einem der vorhergehenden Ansprüche, wenn abhängig von Anspruch 8, das das Bestrafen eines Kunden umfasst, wenn eine Diskrepanz erfasst wird.
Verfahren zum Betreiben eines Kommunikationsnetzes nach einem der vorhergehenden Ansprüche, wobei das Netz mehrere Netzdomänen umfasst, wobei das Verfahren ferner das Berechnen einer Gebühr für die Nutzung der Netz-Ressourcen bei der Übertragung von Verkehr über das Netz zu einem zweiten Kunden bei einem ersten Kunden umfasst und außerdem umfasst: Bestimmen von Kosten in Abhängigkeit von bei der Übertragung verwendeten Netz-Ressourcen; Bestimmen eines Kostenzuteilungsparameters zu dem ersten und dem zweiten Kunden; und Berechnen von Gebühren für den ersten und/oder den zweiten Kunden durch Kombinieren der Kosten und des Zuteilungsparameters.
Kommunikationssystem, das ein Kommunikationsnetz (1) und mehrere daran angeschlossene Kundenendgeräte (5, 8, 9) umfasst, wobei jedes Kundenendgerät Messmittel zum Messen der Nutzung der Netz-Ressourcen durch das Endgerät und/oder Berechnungsmittel zum Berechnen der Netz-Nutzungsgebühr in Abhängigkeit von der gemessenen Netznutzung umfasst und bei dem das Netz (1) Empfangsmittel zum Empfangen der durch die Kundenendgerät-Messmittel erzeugten Messdaten und/oder der durch ein Kundenendgerät-Berechnungsmittel erzeugten Netzgebührdaten umfasst, dadurch gekennzeichnet, dass das Netz ferner Abtastmittel umfasst, um die Nutzung von Netz-Ressourcen durch ein oder mehrere der Kundenendgeräte abzutasten, indem nur ein Teil der Nutzung der Netz-Ressourcen durch das oder jedes entsprechende Kundenendgerät gemessen und dies bezüglich der abgetasteten Nutzung mit den Messdaten und/oder mit den Nutzungsgebührdaten, die von dem entsprechenden Kundenendgerät empfangen werden, verglichen wird.
Kommunikationsnetz (1) für die Verwendung in dem System nach Anspruch 27, das Empfangsmittel zum Empfangen von Messdaten, die von einem Messmittel des Kundenendgeräts (5, 8, 9) erzeugt werden, und/oder von Nutzungsgebührdaten, die von einem Kundenendgerät-Berechnungsmittel erzeugt werden, umfasst, gekennzeichnet durch Abtastmittel zum Abtasten der Nutzung von Netz-Ressourcen durch ein oder mehrere der Kundenendgeräte durch Messen lediglich eines Teils der Nutzung der Netz-Ressourcen durch das oder jedes entsprechende Kundenendgerät und Vergleichsmittel zum Vergleichen der durch die Abtastmittel gemessenen Nutzung mit Messdaten und/oder mit Nutzungsgebührdaten, die von dem entsprechenden Kundenendgerät empfangen werden.