DE69934898T2

DE69934898T2 - Abrechnung in einem kommunikationsnetz

Info

Publication number: DE69934898T2
Application number: DE69934898T
Authority: DE
Inventors: John Robert BRISCOE; Michael Rizzo
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1998-06-05
Filing date: 1999-06-04
Publication date: 2007-11-15
Anticipated expiration: 2019-06-05
Also published as: JP4361214B2; JP2002518883A; CN1217510C; WO1999065183A2; WO1999065185A3; US20050286488A1; CN1222135C; AU4158099A; JP2002518882A; WO1999065184A2; US7319673B1; EP1119943A2; AU4157599A; DE69919190T2; JP4386582B2; CN1311934A; US7747240B1; CA2333712C; CA2333361C; EP1119944B1

Description

Die vorliegende Erfindung betrifft ein Kommunikationsnetz und insbesondere Abrechnungsmechanismen in einem derartigen Netz.
In herkömmlichen Kommunikationsnetzen, etwa nationale PSTNs (öffentliche Fernsprechwählnetze), ist ein wesentlicher Anteil der Netzbetriebsmittel dem Messen der Netznutzung und der Gebührenerfassung für die Netznutzung zugeordnet. Untersuchungen haben geschätzt, dass diese Betriebsmittel 6 % der Betriebskosten einer Telekommunikationsfirma verbrauchen. Das Internet enthält dagegen im Allgemeinen keine Mess- und Gebührenerfassungsmechanismen für einzelne Kunden. Das Fehlen der Netzinfrastruktur, die für die Unterstützung der Messung und Gebührenerfassung erforderlich ist, verringert die Betriebskosten des Internet im Vergleich zu herkömmlichen Telephonienetzen und hat die rasche Erweiterung des Internet erleichtert. Das Fehlen von geeigneten Gebührenerfassungsmechanismen hat jedoch wesentliche Nachteile in Bezug auf die Charakteristiken des Verkehrs, der durch das Internet befördert wird: Es ermutigt zur verschwenderischen Nutzung von Netzbetriebsmitteln und verringert den Anreiz zu Investitionen in die Netzinfrastruktur, um neue Anwendungen zu unterstützen, die z. B. eine garantierte Dienstgüte (QoS) erfordern.
Das Patent WO 97/05749 beschreibt ein Anrufmanagementsystem, bei dem die unterschiedlichen Tarife von konkurrierenden Fernsprechträgerfirmen gespeichert und durch einen Computer bei dem Versuch verwendet werden, um festzustellen, welche der Firmen das beste Angebot für einen bestimmten Anruf anbietet anhand von Faktoren, wie etwa die angerufene Nummer (und somit der Zielort), die Tageszeit und der Wochentag und die geschätzte Anrufdauer, wobei anschließend der ausgewählte Träger automatisch verwendet wird, um den Anruf auszuführen.
David Clark: "A model for cost allocation and pricing in the Internet" MIT Workshop an Internet economics, März 1995, XP002102708, http://www.press.umich.edu/jep/works/ClarkModel.html beschreibt ein vorgeschlagenes Schema zur Abrechnung für die Internetnutzung (d. h. für das Übertragen von Daten in ein Netz und/oder das Empfangen von Daten von dem Netz), welches der Autor als eine Abrechnung der erwarteten Nutzung bezeichnet, bei der Anwender eine Gebühr für die Fähigkeit bezahlen, bis zu einer vereinbarten Datenmenge auf dem Netz zu übertragen, selbst während Überlastungsperioden. Während einer Überlastung werden Daten außerhalb des vereinbarten Profils gedrosselt (z. B. durch Verwerfen der rückständigen Pakete), wenn jedoch keine Überlastung vorliegt, gibt es keine Begrenzung der Datenmenge, die der Anwender senden oder empfangen kann.
Nishibe Y. u. a. beschreiben in "Distributed channel allocation in ATM networks proceedings" der Global telecommunications conference (GLOBECOM), Houston, 29. November – 2. Dezember 1993 Bd. 1, 29. November 1993, S. 417 bis 423, XP000428091, Institute of electrical and electronics engineers einen Kanalzuweisungsmechanismus zur Verwendung in einem ATM-Netz, bei dem jede Verkehrsquelle einem Agenten zugewiesen ist (ein Agent ist eine Berechnungsinstanz, d. h. eine Software-Instanz, die autonom wirkt), der Kanäle auswählt, in denen versucht wird, Daten zu senden, die durch seine entsprechende Verkehrsquelle erzeugt werden. Jeder Kanal besitzt eine Kanalüberwachungseinrichtung, die ständig die Nutzung ihres entsprechenden Kanals überwacht und periodisch Berichte der durchschnittlichen Nutzung des Kanals seit der letzten Aktualisierung an jeden Agenten sendet (wobei dieser Prozess als Abtasten bezeichnet wird). Es werden Algorithmen beschrieben, um die tatsächliche momentane Nutzung zu jedem Zeitpunkt anhand von früheren Berichten von einer Kanalüberwachungseinrichtung zu schätzen, um einen Agenten zu unterstützen, zu jedem Zeitpunkt einen geeigneten Kanal auszuwählen.
Appleton, J. "Performance related issues concerning the contract between network and costumer in ATM-Networks" Telecommunication access networks: Technology and service trends, Proceedings of the IX International Symposium an subscribe loops and services (ISSLS), Amsterdam, 22. bis 26. April 1991, Symp. 9, 22. April 1991, S. 182 bis 188, XP00516590, Lemstra W ISBN: 0-444-89050-5 ist eine interessante Diskussionsgrundlage, die verschiedene Aspekte erläutert, die beeinflussen, wie ein ATM-Netzbetreiber Kunden für die Bereitstellung der Nutzung des ATM-Netzes unter ihrer Steuerung Gebühren berechnen könnte. Es wird insbesondere erwähnt, dass es im Allgemeinen typischerweise einen Vertrag bestimmter Gattungen (entweder mit expliziten oder impliziten Dienstanforderungen) zwischen einem Kunden und dem Netzbetreiber geben wird und es muss wahrscheinlich eine bestimmte Art der Überwachung des Kundenverhaltens geben, um sicherzustellen, dass er innerhalb seiner vertraglich vereinbarten Netznutzungsgrenzen bleibt. Die erforderliche Kontrolle hierfür ist in der Weise beschrieben, dass sie typischerweise in der lokalen Vermittlung als eine Quellenkontrollfunktion erfolgt, wobei sowohl die Überwachung der Spitzennutzung als auch die Überwachung des Datenverlustes als mögliche Typen der Kontrolle beschrieben werden. Es werden jedoch keine expliziten Einzelheiten angegeben, wie dies erfolgen könnte.
Das Patent WO 95/27385 beschreibt eine Steuereinheit zur Verwendung in einem Netz, wie etwa ein ATM-Netz, zum Ausführen einer Vielzahl von Funktionen, die die Kontrolle von Daten enthält, die von dem Anwender auf dem Netz gesendet werden, um sicherzustellen, dass sie mit den vereinbarten Nutzungsgrenzen übereinstimmen. Es wird insbesondere vorgeschlagen, dass eine Klasse von Daten, die als Zellen mit niedriger Priorität (LP-Zellen) bezeichnet werden, lediglich bei einer bestimmten maximalen Rate gesendet werden sollten (die festgelegt wird, indem sichergestellt wird, dass eine minimale Anzahl von freien Zellen, die zwischen jeder LP-Zelle längs eines bestimmten Kanals angeordnet sind, vorhanden sind).
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Kommunikationsnetzes geschaffen, das im Anspruch 1 dargelegt ist.
Dabei erfolgt in der Beschreibung und den Ansprüchen eine Bezugnahme auf ein Endgerät, das "an ein Netz angeschlossen ist", damit Endgeräte, wie etwa mobile drahtlose Datenendgeräte, die sich vorübergehend bei einem Netz anmelden, sowie andere Endgeräte, die eine drahtlose Verbindung mit dem Netz besitzen, sowie Endgeräte, die durch eine Standleitung dauerhaft mit einem Netz verbunden sind, enthalten sind. Ein mobiles Endgerät kann sich z. B. an einem Netz anmelden, um den Tarif zu empfangen, und kann anschließend die Gebühr berechnen, während es vom Netz getrennt ist, wobei eine derartige Anordnung im Umfang dieses Aspektes der Erfindung liegt.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Kommunikationsnetzes geschaffen, wobei das Verfahren umfasst:
Verteilen eines Tarifs über das Kommunikationsnetz zu mehreren Kundenendgeräten, die an das Kommunikationsnetz angeschlossen sind,
Messen der Nutzung von Netzbetriebsmitteln durch das Kundenendgerät bei dem Kundenendgerät; und
Berechnen einer Gebühr für die Verwendung des Netzes durch das Kundenendgerät für welches der Tarif gilt, unter Verwendung der Ergebnisse des Schritts des Messens zusammen mit dem Tarif.
Diese Aspekte der Erfindung schaffen einen einfachen Abrechnungsmechanismus, der z. B. für eine Verwendung im Internet oder als eine Alternative zu herkömmlichen Gebührenerfassungsmechanismen in anderen Netzen, bei denen die Endgeräte eine bestimmte Datenverarbeitungsfähigkeit besitzen, geeignet ist. Er beseitigt die Belastung durch das Messen und die Gebührenerfassung bei der Netzinfrastruktur und verteilt stattdessen den Tarif an die Kundenendgeräte, wodurch ermöglicht wird, dass Gebühren am Netzrand berechnet werden. Dieser Lösungsansatz bietet eine wesentlich bessere Skalierbarkeit im Vergleich mit herkömmlichen Lösungsansätzen und ist deswegen für eine Verwendung in einem rasch wachsenden Netz, wie etwa das Internet, besonders geeignet.
Der Tarifalgorithmus wird vorzugsweise an die mehreren Kundenendgeräte, für die der Tarif gilt, über das Kommunikationsnetz verteilt. Bei bevorzugten Implementierungen ist der Abrechnungsmechanismus so beschaffen, dass er selbst dann funktioniert, wenn bestimmte Tarifnachrichten, die über das Netz verteilt werden, ver zögert werden oder verloren gehen. Der Schritt des Verteilens des Tarifs enthält vorzugsweise den Schritt des getrennten Übermittelns einer Formel zum Berechnen von Netznutzungsgebühren und von Koeffizienten zur Verwendung in dieser Formel.
Der Netz-Overhead zur Abrechnung wird weiter verringert, indem den Anwendern der Tarifalgorithmus bereitgestellt wird und anschließend lediglich die relevanten Koeffizienten aktualisiert werden, wenn sich der Tarif ändert.
Das Verfahren enthält vorzugsweise das Messen der Belastung von Netzbetriebsmitteln und das Bestimmen eines revidierten Tarifs in Abhängigkeit von den Ergebnissen des Schritts des Messens der Belastung.
Ein weiterer wesentlicher Vorteil der vorliegenden Erfindung besteht darin, dass sie die Steuerung der Verwendung von Netzbetriebsmitteln vereinfacht, indem der Tarif in der Weise geändert wird, dass er die Knappheit eines bestimmten Betriebsmittels wiedergibt.
Die Schritte des Messens der Belastung und des Bestimmens eines revidierten Tarifs können durch eine Netzmanagement-Plattform ausgeführt werden. Alternativ und vorzugsweise wird ein Algorithmus zum Abbilden einer Überlastung auf Preiserhöhungen in dem Netz verteilt und wird vorzugsweise bei Kundenendgeräten angeordnet. Das Verfahren enthält vorzugsweise das Betreiben mehrerer unterschiedlicher Dienste auf dem Kommunikationsnetz, das Übermitteln von unterschiedlichen Tarifen für jeweilige unterschiedliche Dienste an die mehreren Kundenendgeräte und das wahlweise Verändern eines entsprechenden Tarifs in Abhängigkeit von einem Betriebszustand des entsprechenden Dienstes.
Die unterschiedlichen Dienste können lediglich durch unterschiedliche Pegel von QoS unterschieden werden oder können sich in der Art unterscheiden. Dieser Aspekt der Erfindung kann außerdem in ansonsten herkömmlichen Netzen verwendet werden, in denen z. B. eine Gebührenerfassung zentral ausgeführt wird und Tarife lediglich zur Information an die Endanwender übermittelt werden.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung umfasst das Verfahren ferner:
Betreiben mehrerer unterschiedlicher Dienste auf dem Netz;
Übermitteln von Tarifen für die unterschiedlichen Dienste an mehrere Kundenendgeräte über einen gemeinsamen Tarifverteilungsmechanismus; und
wahlweises Ändern eines entsprechenden Tarifs in Abhängigkeit von einem Betriebszustand eines entsprechenden Dienstes.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung umfasst das Verfahren ferner:
Berechnen von Gebühren für die Nutzung von Netzbetriebsmitteln durch ein entsprechendes Kundenendgerät, das an das Netz angeschlossen ist, für jeden der mehreren Kunden unter Verwendung eines ausgewählten von mehreren unterschiedlichen Tarifen;
Messen der Belastung von Netzbetriebsmitteln und
Verändern eines oder mehrerer der mehreren unterschiedlichen Tarife in Abhängigkeit von der Belastung der Netzbetriebsmittel, wobei verschiedene Tarife der mehreren unterschiedlichen Tarife entsprechende unterschiedliche Lebensdauern besitzen.
Diese Merkmale versorgen die Kunden mit veränderlichen Tarifen mit unterschiedlichen Lebensdauern. Dann kann ein Kunde, der eine größere Stabilität benötigt, eine Extragebühr bezahlen, um diese Stabilität zu erreichen, wobei trotzdem ein Bereich mit höherer Lebensdauer bestehen bleibt, der es dem Netzbetreiber ermöglicht, kurzfristige Schwankungen des Bedarfs zu bewältigen, bis langfristige Tarifänderungen ausgeführt werden können.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung enthält das Verfahren zum Betreiben eines Kommunikationsnetzes einen Punkt zum Zugang zum Netz, der lediglich eine einzige Blockierungsprüfung an dem Verkehr, der in das Netz eintritt, ausführt.
Bisher wurde ein Netz wie z. B. das Internet als ein Einzeldienstnetz betrieben. Jetzt wird jedoch vorgeschlagen, dass das Internet ein Mehrdienstnetz werden sollte. Es kann z. B. mehrere QoS-Pegel für unterschiedliche Anwendungen unterstützen oder könnte sowohl Gruppenrufdienste als auch Direktrufdienste für einige, jedoch nicht alle Kunden bereitstellen. Die Erfinder der vorliegenden Erfindung haben erkannt, dass dies unter Verwendung herkömmlicher Zugangssteuerverfahren zu einem Aufbau von mehreren Prüfungen beim Zugang zu dem Mehrdienstnetz führt, um festzustellen, welcher Dienst in jedem Paket angefordert wird, und um dann zu prüfen, ob es sich um einen Dienst handelt, für den durch den relevanten Kunden bezahlt wurde. Dieser Aspekt der Erfindung überwindet diese Nachteile, indem eine einzige Blockierungsprüfung ausgeführt wird, die prüft, ob der Kunde in einer Position ist, in der er für den Missbrauch des Netzes mit einem Bußgeld zu belegen ist. Wenn dies der Fall ist, wird das relevante Paket zu dem Netz geleitet und alle anderen geeigneten Prüfungen erfolgen parallel anstelle einer Blockierung des Pakets, während auf die Beendigung aller Prüfungen gewartet wird. Wenn eine der folgenden Prüfungen fehlschlägt, wenn z. B. das Paket einen QoS-Pegel verwendet, der nicht durch den Kunden bezahlt wurde, wird eine geeignete Bestrafung ausgeführt, z. B. durch Abbuchung einer Strafgebühr von einem Konto, das durch den Kunden hinterlegt wurde.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung umfasst das Verfahren zum Betreiben eines Kommunikationsnetzes ferner:

a) Übermitteln von Tarifdaten an ein Benutzerendgerät, das mit dem Netz verbunden ist;
b) Berechnen einer Gebühr für Verkehr, der zwischen dem Netz und dem Endgerät übermittelt wird, bei dem Benutzerendgerät unter Verwendung der Tarifdaten und Ausführen einer Zahlung;
c) Abtasten lediglich eines Teils des Verkehrs, der zwischen Benutzern und dem Netz übermittelt wird, und für den abgetasteten Verkehr Vergleichen von Zahlungen, die durch Benutzer ausgeführt werden, und der Zahlung gemäß Tarif.

Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung umfasst das Verfahren zum Betreiben eines Kommunikationsnetzes ferner:

a) Messen der Netznutzung bei einem Kundenendgerät;
b) Übermitteln von Netznutzungsdaten von dem Kundenendgerät zu dem Netzbetreiber; und
c) Abtasten lediglich eines Teils des Verkehrs, der zwischen einem Kundenendgerät und dem Netz übermittelt wird, durch den Netzbetreiber und für den abgetasteten Verkehr Vergleichen der Netznutzung mit den Netznutzungsdaten von dem Kundenendgerät und dadurch Erfassen von Unterschieden.

Da der Tarif anstelle der Nutzungsdaten, die explizit übermittelt werden, an die Kundenendgeräte bereitgestellt wird, kann der Kunde die Nutzungsgebühr berechnen. Die Zahlung der Nutzungsgebühr oder gleichwertige Buchungsinformationen können dann zu dem Netzbetreiber übermittelt werden, wobei die Daten der gemessenen Nutzung in dieser Übermittlung implizit enthalten ist.
Gemäß einer weiteren Ausführungsform der Erfindung umfasst das Verfahren zum Betreiben eines Kommunikationsnetzes ferner das automatische Verändern in Abhängigkeit einer Netzbelastung, die bei einem Kundenendgerät erfasst wird, eines Tarifs für die Netznutzung durch ein Kundenendgerät. Dieses Merkmal kann in Verbindung mit den anderen Aspekten der Erfindung oder unabhängig hiervon verwendet werden.
Weitere Aspekte der Erfindung werden im Folgenden beschrieben und beansprucht. Die Erfindung umfasst außerdem das Kommunikationsnetz von Anspruch 27 und das Kommunikationsendgerät von Anspruch 29.
BESCHREIBUNG DER ZEICHNUNG
Systeme, bei denen die vorliegende Erfindung ausgeführt ist, werden im Folgenden lediglich beispielhaft unter Bezugnahme auf die beigefügte Zeichnung genauer beschrieben, es zeigen:
1 eine schematische Darstellung eines Netzes, bei dem die Erfindung ausgeführt ist;
2a und 2b Darstellungen, die Tariffunktionen zeigen;
3 das Byte-Format eines anderen Dienstes;
4a und 4b schematische Darstellungen der Komponenten einer Abrechnungsarchitektur zur Verwendung mit dem Netz von 1;
5a und 5b Daten, die zwischen den Abrechnungsobjekten von 4 ausgetauscht werden;
6 eine schematische Darstellung, die Protokollstapel bei einem Kundenendgerät und in dem Netzbereich zeigt;
7 eine Darstellung, die die zeitliche Änderung des Tarifs zeigt;
8a bis 8e Klassendiagramme für eine Softwareimplementierung von Abrechnungs- und Messobjekten;
9 eine Darstellung, die eine graphische Anwenderschnittstelle (GUI) zur Verwendung mit den Objekten der 8a bis 8e zeigt;
10 ein Klassendiagramm für eine Softwareimplementierung von Tarifobjekten;
11 eine Darstellung, die eine alternative Ausführungsform zeigt; und
12 eine Anwenderschnittstelle, die einen Tarifmarkt unterstützt.
BESCHREIBUNG VON BEISPIELEN
Systeme, bei denen die vorliegende Erfindung ausgeführt ist, werden im Folgenden lediglich beispielhaft unter Bezugnahme auf die beigefügte Zeichnung genauer beschrieben.
Wie in 1 gezeigt ist, enthält ein Kommunikationsnetz 1 mehrere Netz-Unterbereichen 2A-C. Die Netz-Unterbereiche können unter der Steuerung von unterschiedlichen Betreibern sein, die sich möglicherweise untereinander nicht vertrauen. Die Netz-Unterbereiche sind untereinander durch Gateway-Router 3, 4 verbunden. In dem vorliegenden Beispiel ist das Kommunikationsnetz das Internet und unterstützt sowohl das Direktruf- als auch das Gruppenruf-Internetprotokoll (IP) und zugehörige Protokolle. Ein Kundenendgerät 5 ist über ein öffentliches Fernsprechwählnetz (PSTN) 5 und einen Zugangsrouter 7 an einen Unterbereich 2A angeschlossen. Eine einzige Blockierungsprüfung wird an diesem Zugangspunkt auf Verkehr angewendet. Die Gateway-Router 3, 4 und der Zugangsrouter 7 können handelsübliche Vorrichtungen sein, wie etwa Router CISCO Serie 7500 bzw. Mehrzweck-Zugangs-Server CISCO Serie AS5800. Weitere Kundenendgeräte sind an das Netz angeschlossen, einschließlich ein Java-fähiges mobiles Endgerät 8 und ein Datenserver 9. Das Kundenendgerät 5 kann über ein LAN an einen Abrechnungsserver an geschlossen sein. Der Abrechnungsserver kann ein Abrechnungsobjekt, das später beschrieben wird, enthalten, das Messdaten von dem Kundenendgerät empfängt.
Zusätzlich zu dem lokalen Tarifänderungsmechanismus, der im Folgenden beschrieben ist, verwendet das Netz außerdem eine netzbasierte Steuerung mehrerer Tarifbänder. Eine Netzmanagement-Plattform 10 ist mit jedem Unterbereich verbunden. Jede Netzmanagement-Plattform kann z. B. ein Berechnungssystem umfassen, das eine SPARC-Arbeitsstation enthält, die mit UNIX (Solaris) gemeinsam mit Netzmanagement-Anwendungen betrieben wird. Die Netzmanagement-Plattform 10 enthält Managementinstanzen und Tarifinstanzen. Die Netzmanagement-Plattform führt einen Datenaustausch mit Agenten 100 in verwalteten Vorrichtungen aus, die z. B. unter Verwendung von SNMP (einfaches Netzmanagement-Protokoll) mit dem entsprechenden Unterbereich verbunden sind. Die Management-Plattformen überwachen die Gesamtbelastung von Netzbetriebsmitteln in den entsprechenden Unterbereichen und stellen die Tarife für eine Netznutzung dementsprechend ein, wie im Folgenden beschrieben wird. Die Netzmanagement-Plattform (NMP) weist den Agenten an, die Vorrichtung zu überwachen und gesammelte Ergebnisse in regelmäßigen Intervallen an die NMP zu melden, so dass die NMP die Kombination aller Meldungen überwachen kann.
Tarifdaten werden an gleichrangige Tarifinstanzen in anderen Unterbereichen und außerdem an die Kundenendgeräte übermittelt. Die Tarifdaten werden per Gruppenruf z. B. unter Verwendung des Distance Vector Multicast Routing Protocol (DVMRP) oder des Protocol Independent Multicast (PIM) im Dichtmodus gesendet. Die Tarifdatenkanäle sind festgelegt und werden unter Verwendung von Pro tokollen basierend auf SDP (Session Description Protocol), SAP (Session Announcement Protocol) überwacht. Eine Abrechnung erfolgt nach einem Modell "bezahlen und anzeigen". Jedes Kundenendgerät überwacht seine eigene Netznutzung z. B. durch Zählen der Anzahl von Pakten, die es über die Netzschnittstelle sendet oder empfängt, und der Datenmenge (in Bytes) in diesen Paketen. Es berechnet unter Verwendung des über das Netz empfangenen Tarifs die Zahlung zu Gunsten des Netzbetreibers und führt eine entsprechende Bezahlung auf ein Konto bei dem Netzbetreiber aus. Der Netzbetreiber überwacht die Nutzung, die durch die Kunden des Endgeräts ausgeführt wird, indem er in Abständen Verkehr zu und von einem bestimmten Kunden abtastet und die Nutzung, die erfolgt, mit der Nutzung, für die bezahlt wird, vergleicht.
Die Tarife, die an die Kundenendgeräte geliefert werden, werden in Bänder mit unterschiedlichen Lebensdauern unterteilt. Die Tarife werden unter der Steuerung der Netzbetreiber geändert, damit sie die Gesamtbelastung des Netzes widerspiegeln. Das heißt, wenn die Netzbelastung hoch wird, können die Tarife erhöht werden, damit sie die Knappheit der Netzbetriebsmittel wiedergeben.
Ein Leistungsanbieter kann verschiedene Produkte anbieten, die durch unterschiedliche Dienstpegelvereinbarungen und/oder durch unterschiedliche Preislebensdauern definiert sind. Das Produkt A könnte z. B. einen besten Dienst bei einem festen Preis anbieten, während ein anderes Produkt B einen besten Dienst bei einem veränderlichen Preis anbietet. Ein Leistungsanbieter kann Produktpreise auf der Grundlage der folgenden Parameter einstellen: der Preis, den der Dienstanbieter an seinen Großhändler-Anbieter zahlt; Preise von Konkurrenten; momentane Betriebsmittelnutzung; relevanter Bedarf an unterschiedlichen Produkten. In Reaktion auf Änderungen bei diesen Parametern kann eine Tarifeinstellung auf eine von drei Arten bewirkt werden. Erstens kann ein Tarif Preise auf der Grundlage von lokalen Beobachtungen der Netzbelastung einstellen, ohne dass eine explizite Übermittlung von dem Anbieter erforderlich ist. Dieser Lösungsansatz, der im Folgenden genau beschrieben ist, muss von vornherein in den Tarif eingebaut sein und ist auf solche Preisänderungen begrenzt, die ausschließlich von lokalen Beobachtungen abhängig sind. Der Anbieter kann zweitens einen Tarif abstimmen, indem einige seiner Parameter eingestellt werden. Diese Art der Einstellung ist erforderlich, wenn die Entscheidung von Parametern abhängt, die nicht direkt durch den Kunden beobachtet werden können, z. B. eine Änderung des Großhändlerpreises von Netzbetriebsmitteln. Der Anbieter kann drittens einen Tarif komplett ersetzen. Dies ist erforderlich, wenn der vorhandene Tarif die erforderlichen Änderungen nicht anpassen kann.
Die erste der oben beschriebenen Tarifänderungen wird notwendigerweise automatisch ausgeführt. Der zweite Typ der Änderung kann manuell ausgeführt werden oder durch einen Agenten, der Einstellungen in Reaktion auf Beobachtungen, die durch das Dienstanbietersystem gemacht werden, automatisch ausgibt. Der dritte Typ der Änderung wird wahrscheinlich manuell ausgeführt, da eine Ersetzung eines neuen Tarifs im Allgemeinen ein Konstruktionselement erfordert, bei dem eine persönliche Eingabe benötigt wird. Es ist jedoch möglich, dass ein Agent verwendet werden könnte, um Tarife für ein Produkt auf der Grundlage einer Gruppe spezifizierter Regeln automatisch umzuschalten.
Dieser Abschnitt beschreibt einen Prototyp, der implementiert wurde, um das oben angegebene Tarif-Untersystem zu demonstrieren. Die Konstruktionsmerkmale enthalten:

– Verwendung eines mobilen Codes, um Tarife und zugehörige Anwenderschnittstellenkomponenten darzustellen;
– Verwendung eines wiederholt per Gruppenruf gesendeten Ankündigungsprotokolls, um Tarife und Tarifeinstellungen wirkungsvoll zu übermitteln;
– Verwenden einer Belastung und Reflexion dynamischer Klassen, um Tarife zu empfangen und abzustimmen. Dieser Prototyp enthält eine Bibliothek aus Mehrzweck-Java-Klassen und zwei spezifische Anwendungen, und zwar:
– ein Anbietersystem, das ermöglicht, dass der Anbieter Tarife für mehrere Produkte einführt, ersetzt und abstimmt;
– ein Kundensystem, das ermöglicht, dass ein Kunde die Gebühren verfolgen kann, die für die verwendeten Produkte angewendet werden.

Das Anbietersystem versorgt mehrere Stellen des Kundensystems, die bei unterschiedlichen Hosts in einem für Gruppenruf geeigneten Netz betrieben werden. Ein Gruppenruf-Ankündigungsprotokoll wird verwendet, um Tarifänderungen von dem Anbietersystem an Kundensysteme zu übermitteln.
Für eine maximale Flexibilität in Bezug auf die Definition von Tarifen wird die Darstellung von Tarifen unter Verwendung von Java-Klassen gewählt. Diese Technik wird außerdem verwendet, um Anwenderschnittstellenkomponenten an Kunden zu liefern, um die Visualisierung des Verhaltens eines Tarifs zu unterstützen.
Die Schnittstelle Tariff wirkt als die Basisklasse für alle Tarife. Diese definiert eine einzelne Operation get GUI (), die als eine Komponente Java SWING zurückgeführt wird, die in die GUI (graphische Anwenderschnittstelle) des Kunden eingeführt werden kann. Diese GUI-Komponente ermöglicht dem Kunden, das Verhalten des Tarifs unter Verwendung von Techniken, die für den Tarif geeignet sind, visuell darzustellen.
Unterklassen der Schnittstelle Tariff bilden eine Gruppe von Tariftypen, wovon jeder einer anderen Gruppe von Mess- und Eingabeparametern zugeordnet ist. Diese Parameter werden identifiziert, indem sie in der Signatur des Verfahrens getCharge () verfolgt werden. Die Schnittstelle RSVPTariff definiert getCharge () z. B. als das Empfangen von n RSVP TSPEC, wodurch die Definition von Tarifen möglich ist, die einen Preis auf der Grundlage der Charakteristiken eines RSVP-Reservierungs-BLB98 berechnen. Die Schnittstelle Packet-CountTariff definiert dagegen getCharge () als das Empfangen von Eingangspaketen, Ausgangspaketen und der momentanen Überlastung (die typischerweise als eine Funktion von verworfenen Paketen gemessen wird), wodurch die Definition von Tarifen möglich ist, die von Paketzahlen abhängig und auf Überlastung empfindlich sind. Weitere Tarife können als neue Formen der Verwendung von Nutzungsmessungen hinzugefügt werden.
Tarife werden definiert, indem Implementierungen der verschiedenen Tarifschnittstellen, die oben beschrieben wurden, bereitgestellt werden. Der Tarif PacketCountLinear implementiert z. B. Packet-CountTariff, um Gebühren zu berechnen die zu Paketzahlen proportional sind. Ein weiterer Tarif CongestionSensitiveLinear arbeitet auf einer ähnlichen Basis, fügt jedoch eine Strafgebühr hinzu, wenn der Kunde beim Vorliegen einer Überlastung nicht innerhalb spezifizierter Tarifgrenzen bleibt.
Zusätzlich zu der Tarifschnittstellen-Implementierung kann ein Tarif weitere "Hilfs"-Klassen verwenden, die ihn in seinem Betrieb unterstützen, sowie eine oder mehrere Anwenderschnittstellenkomponenten-Klassen für die Zwecke der Visualisierung beim Kunden. Eine anbieterseitige Anwenderschnittstelle kann außerdem erforderlich sein, damit der Anbieter Tarifeinstellungen ausführen kann.
Eine vollständige Tarifbeschreibung enthält eine Gruppe von Java-Klassen, wovon einige für das Kundensystem und andere für eine Verwendung durch das Anbietersystem vorgesehen sind. Die kundenseitigen Klassen sind in einer Java-Archiv-Datei (JAR-Datei) gebündelt, um die Verarbeitung durch das Anbietersystem zu vereinfachen.
Um einen neuen Tarif zu verwenden, lädt das Anbietersystem zunächst die Tarifklassen, die es benötigt, in seine Ausführungsumgebung. Dann lädt es das kundenseitige Datenbündel, bringt es in eine serielle Form, signiert es mit einem privaten Schlüssel und verwendet ein Ankündigungsprotokoll, um es an Kundensysteme zu verteilen. Die Verwendung einer Signatur ermöglicht Kunden, zu prüfen, ob empfangene Tarife authentisch sind.
Beim Empfangen des Datenbündels überprüft jedes Kundensystem die Signatur (unter Verwendung des öffentlichen Schlüssels, der mit dem privaten Schlüssel des Anbieters übereinstimmt) und entpackt das Datenbündel an einem Aktivierungszeitpunkt, der in dem Ankündigungsprotokoll-Vorsatz spezifiziert ist und an einem wesentlich späteren Zeitpunkt liegen kann, z. B. Stunden oder Tage später, und lädt die Klassen in seine Ausführungsumgebung unter Verwendung einer zweckgebundenen dynamischen Klassenladeeinrichtung. Eine Kopie der empfangenen Tarifklasse wird erzeugt und anstelle des vorherigen Tarifs installiert. Wenn der Tarif eine Anwenderschnittstellenkomponente enthält (wird erhalten durch Aufrufen des Verfahrens getGUI () des Tarifobjekts), ersetzt sie die Anwenderschnittstelle des vorherigen Tarifs. Die Änderung der Anwenderschnittstelle dient dazu, den Anwender zu informieren, dass der Tarif geändert wurde.
Eine Tarifeinstellung beinhaltet den ferngesteuerten Aufruf einer Operation, die für den Tarif, der gegenwärtig in Kraft ist, spezifisch ist. Das bedeutet, dass das Kundensystem die Signatur dieser Operation vor dem Empfangen des Tarifs nicht kennen kann, d. h. die Operation wird in irgendeiner der Tarifschnittstellen, die dem Kundensystem bekannt sind, überwacht.
Um dieses Problem zu umgehen, wird das "Reflexions"-Merkmal verwendet, das durch Java unterstützt wird. Um eine Tarifeinstellung zu verteilen, erzeugt der Anbieter ein Aufruf-Objekt (Invocation Object), das die Bezeichnung der aufzurufenden Operation gemeinsam mit den Parametern, die an sie zu liefern sind, speichert. Dieses Objekt wird dann in eine serielle Form umgesetzt, signiert und unter Verwendung des Ankündigungsprotokolls angekündigt. Wenn eine Einstellung durch ein Kundensystem empfangen und geprüft wurde, wird das Aufruf-Objekt aus der seriellen Form umgesetzt und auf den gegenwärtigen Tarif unter Verwendung der Reflexion angewendet, um die beschriebene Operation aufzurufen.
Um das Ankündigungsprotokoll zu vereinfachen, müssen Einstellungen idempotent und vollständig sein. Die Idempotentität garantiert, dass ein Tarif nicht nachteilig beeinflusst wird, wenn eine Einstellung mehr als einmal angewendet wird. Vollständigkeit bedeutet, dass eine Einstellung den vollständigen Parametersatz eines Tarifobjekts festlegt, so dass eine Einstellung die Wirkung aller vorherig angewendeten Einstellungen vollständig beseitigt.
Das Kundensystem kann einen Tarif anwenden, indem nach jeder Sekunde die Operation getCharge (), die durch diesen Tarif unterstützt wird, wiederholt aufgerufen wird und die zurückgeführten Werte zu der kumulativen Gebühr addiert werden. Die Parameter, die an getCharge () geliefert werden, hängen von der Art des Tarifes ab, der gegenwärtig in Kraft ist. Wenn der Tarif z. B. eine Implementierung von PacketCountTariff ist, sind Messungen von eingehenden Paketen, ausgehenden Paketen und der Überlastung während der letzten Sekunde erforderlich. Wenn der Tarif jedoch eine Implementierung von RsvpTariff ist, ist lediglich ein TSPEC, der die gegenwärtige Reservierung beschreibt, erforderlich. Das bedeutet, dass ein Kundensystem ein Produkt abonnieren kann, wenn es die Parameter liefern kann, die von dem Tarif gefordert werden, der mit diesem Produkt verbunden ist.
Jeder Aufruf des Verfahrens getCharge () hat außerdem eine Aktualisierung der tarifspezifischen Anwenderschnittstelle zur Folge. Bei dem Tarif CongestionSensitiveLinear werden z. B. die Benutzungsparameter, die an getCharge () geliefert werden, zur Aktualisierung der graphischen Anzeigen von Verkehr und Überlastung verwendet.
Das Ankündigungsprotokoll wird verwendet, um in serielle Form umgesetzte Tarife und Einstellungen von einem Anbietersystem an mehrere Kundensysteme zu übermitteln. Es wird angenommen, dass die Anzahl der Kundensysteme groß ist, und es wird eine Lösung mit wiederholtem Gruppenruf verwendet.
Jedes Produkt, das durch einen Anbieter unterstützt wird, ist für Ankündigungszwecke einem Gruppenrufkanal zugeordnet. Kundensysteme verfolgen die Kanäle, die den Produkten entsprechen, die sie verwenden. Bei der gegenwärtigen Implementierung wird angenommen, dass jedes Kundensystem wohlbekannte Gruppenrufadressen für die Produkte kennt, an denen es interessiert ist.
Für jeden Produktkanal gibt der Anbieter wiederholt den aktuellen Tarif und die letzte Einstellung, die daran ausgeführt wurde (falls vorhanden) bekannt. Jede Ankündigung trägt eine Versionsnummer, die immer dann erhöht wird, wenn die Ankündigung geändert wird. Kundensysteme verarbeiten Ankündigungen nur dann, wenn eine Änderung der Versionsnummer erfasst wird. Wenn ein neuer Kunde sich in einen Kanal einschaltet, wartet er, bis er einen Tarif empfängt, bevor Einstellungsankündigungen verarbeitet werden. Ferner wird eine Einstellung nur dann angewendet, wenn ihre Ankündigungsversion größer ist als die des aktuellen Tarifs, wodurch sichergestellt wird, dass eine fehlende Tarifankündigung nicht zur Folge hat, dass eine nachfolgende Einstellung auf einen alten Tarif angewendet wird.
Während eine zentralisierte Überwachung und Steuerung von Tarifen durch die Netzmanagement-Plattform wirkungsvoll ist, um auf globale Änderungen in der Belastung des Netzes zu reagieren, ist es schwierig, eine lokale Überlastung auf diese Weise zu handhaben. Es ist schwierig zu bewirken, dass ein Preiserhöhungssignal auf eine solche Weise per Gruppenruf gesendet wird, dass das Signal nur von jenen empfangen wird, die versuchen, Pakete über den Punkt der Überlastung zu übermitteln. Dies würde eine separate Gruppenrufübertragung für jedes Element im Internet erfordern, z. B. einen Gruppenruf für alle unterschiedlichen Warteschlangen an allen Schnittstellen von allen Routern. Alternativ könnte eine bestimmte Ansammlung von Preiserhöhungen, die durch eine lokale Belastung von Betriebsmitteln ausgelöst werden, verwendet werden. Dies würde jedoch bedeuten, dass Preiserhöhungssignale an Benutzer gesendet werden, die das überlastete Betriebsmittel nicht verwenden. In diesem Fall wäre es erforderlich, dass das Preiserhöhungssignal gedämpft wird, wodurch der Zweck der Preiserhöhung, den Bedarf an den überlasteten Betriebsmittel zu verringern, gemindert wird.
Um diese Schwierigkeiten zu überwinden sind die bei den Kundenendgeräten installierten Tarifalgorithmen so beschaffen, dass sie auf eine Überlastung bei einem Netzbetriebsmittel, das durch das Endgerät verwendet wird, automatisch reagieren. Jeder Algorithmus enthält eine Funktion, die den Preis für die Netznutzung in Abhängigkeit von dem erfassten Überlastungsgrad ändert. Diese Funktion kann in den Haupttarifalgorithmus integriert sein oder kann wie in dem hier beschriebenen Beispiel ein separater Algorithmus sein, der verwendet wird, um eine Extragebühr zu berechnen, die zu einem Preis, der gemäß dem Haupttarifalgorithmus berechnet wird, addiert wird.
Der Haupttarifalgorithmus berechnet einen Preis P als eine Funktion mehrerer Qualitätsparameter Q₁, Q₂, Q₃, wobei Z. B. Q₁ eine spezifizierte Latenz für Pakete ist, die über die Schnittstelle zwischen dem Kundenendgerät und dem Netz übermittelt werden, Q₂ ist die für die Übertragung reservierte Bandbreite und Q₃ ist ein spezifizierter Pegel der Zuverlässigkeit in Übereinstimmung mit einem maximal zulässigen Pegel von Paketverlusten.
Der Preis P wird dann angegeben durch: P = f(Q1, Q2, Q3,...)
Ein Beispiel der Preisermittlungsfunktion in Bezug auf einen der Qualitätsparameter Q ist in 2a schematisch angegeben.
Ein Überlastungstarifalgorithmus berechnet eine Extragebühr ΔP, die eine Funktion von einem oder mehreren Überlastungsparametern C ist: ΔP = f(C1, C2,...)
Die Überlastungsparameter stellen ein Maß der Belastung der Betriebsmittel dar, die ein Kundenendgerät zu einem gegebenen Zeitpunkt verwendet. In dem vorliegenden Beispiel wird das Verhältnis von verlorenen Paketen und empfangenen Paketen als Überlastungsparameter verwendet. Dieser Parameter wird leicht berechnet, z. B. bei Paketen unter Verwendung von TCP (Transportsteuerungsprotokoll) oder RTP (Echtzeitprotokoll) über UDP (Anwenderdatagrammprotokoll), da diese Pakete eine Folgenummer enthalten. 2b zeigt ein Beispiel der Funktion zum Erzeugen der Extragebühr. In diesem Fall vergrößert sich die Extragebühr als eine näherungsweise exponentielle Funktion der Überlastung, so dass bei niedrigen Überlastungspegeln eine kleine Extragebühr berechnet wird, während dann, wenn die Überlastung weiter zunimmt, bei größeren Belastungspegeln die Extragebühr stark ansteigt.
Bei einer alternativen Implementierung wird ein explizites Überlastungssignal durch einen überlasteten Router den Netzpaketen hinzugefügt, die zu dem Kundenendgerät übertragen werden.
Obwohl hier lediglich ein einzelner Haupttarif und eine Extragebühr beschrieben sind, können in der Praxis unterschiedliche Unterbereiche und unterschiedliche Dienstanbieter, die mit jedem Unterbereich verbunden sind, eine unterschiedliche Preisbildungsstruktur mit unterschiedlichen Haupt- und Extragebührtarifen haben. Es gibt jedoch bei allen Unterbereichen eine gemeinsame Beziehung zwischen Netzbelastungspegeln und einer Überlastungssignalisierung.
Die Funktionsweise dieser zweiten Implementierung wird nun im Kontext eines Netzes beschrieben, das unter Verwendung eines differenziertes Dienstes betrieben wird, wie in dem Entwurf der Internet Engineering Taskforce "Differentiated Services Operational Model and Definitions" und in dem Dokument von David D. Clark (MID), "A Model of Cost Allocation and Pricing in the Internet" das auf dem IT Workshop an Internet Economics im März 1995 vorgestellt wurde (URL:http://www.press.umich.edu/jep/works/ClarkModel.html) beschrieben ist. In einem Netz, das differenzierte Dienste implementiert, sind Knoten eingerichtet, um zwischen Paketen zu unterscheiden, damit unterschiedliche Dienstpegel bereitgestellt werden. Diese Möglichkeit könnte z. B. verwendet werden, um verzögerungsempfindlichen Daten, wie etwa Daten, die durch einen IP-Telephonie-Client erzeugt werden, im Vergleich zu anderen Daten, wie etwa Email-Daten, eine höhere Priorität zuzuweisen. Am Netzrand werden Z. B. bei einem Client-Endgerät, das der IP-Telephonie-Client betreibt, Bits in einem DOS-Oktett (Diensttyp-Oktett), das in jedem Paketvorsatz enthalten ist, so eingestellt, dass sie den geeigneten Dienstpegel angeben. Diese Bits werden durch Router im Netz verwendet, um festzulegen, wie die relevanten Pakete behandelt werden sollten.
Das DOS-Oktett wird dann, wenn es auf diese Weise verwendet wird, als DS-Byte (Differentialdienst-Byte) bezeichnet. Das Format des Differenzdienst-Bytes ist in 3 gezeigt. Das Bit 0, das mit "IN" bezeichnet ist, gibt an, ob das Paket innerhalb oder außerhalb eines definierten Profils liegt. Die Bits 1 bis 5, die mit "PHB" bezeichnet sind, definieren ein "Per-Hob-Verhalten", d. h. sie geben an, wie z. B. ein Router das Paket behandeln sollte, z. B. entsprechend seiner niedrigen oder hohen Priorität. Die Bits 6 und 7 werden in dieser besonderen Form des DS-Bytes für eine explizite Überlastungsbenachrichtigung (ECN) verwendet. Eines dieser Bits ist so eingestellt, dass es angibt, ob die Router in dem Weg des Pakets das ECN-Feld einstellen können, und das andere Bit wird als ein Merkerbit verwendet, das gesetzt ist (durch ECN-fähige Router), wenn eine Überlastung oder eine Belastung, die möglicherweise zu einer Überlastung führen könnte, auftritt. Algorithmen der willkürlichen Früherfassung (RED-Algorithmen) werden gegenwärtig in Routern implementiert. Diese Algorithmen messen eine durchschnittliche Warteschlangenlänge in den Paketpuffern eines Routers. Ein exponentieller veränderlicher Mittelwert wird berechnet. Wenn die durchschnittliche Warteschlangenlänge einen vorgegebenen Stellenwert überschreitet, meldet der Router, dass eine Überlastung auftritt. Herkömmlich wurde diese Signalisierung ausgeführt, indem einfach ein Paket verworfen wurde. Im Kontext eines ECN-Schemas setzt der Router jedoch anstelle des Verwerfens eines Pakets ein ECN-Bit in einem Paketvorsatz, um anzugeben, dass eine Überlastung auftritt. Dies erfolgt wahrscheinlichkeitstheoretisch: Das heißt, lediglich einige der Pakete, die den Router durchlaufen, werden markiert. Die Wahrscheinlichkeit, dass ein Paket markiert wird, steigt mit der durchschnittlichen Warteschlangengröße. In dem seltenen Fall, dass sich die Warteschlange auf eine Lange vergrößert, bei der die Routerpuffer voll sind, werden die Pakete dann anstelle des Setzens eines ECN-Bits verworfen. In diesem Fall werden ECN-Bits für alle restlichen Pakete gesetzt.
Wenn das Client-Endgerät 5 im Betrieb auf eine Datenquelle bei dem Server 9 zugreift, kann z. B. am Router 4, der die Netz-Unterbereiche 2B und 2C verbindet, eine Überlastung auftreten. RED-ähnliche Algorithmen in dem Router 4 erfassen, dass die Warteschlangenlängen in den Routerpuffern, die unter Verwendung des exponentiellen veränderlichen Durchschnittswerts berechnet werden, einen vorgegebenen Schwellenwert übersteigen. Demzufolge wird bei einigen der Pakete von dem Server 9 auf dem Weg zu dem Client-Endgerät das ECN-Bit des DS-Bytes durch den Router 9 gesetzt, um die Tatsache zu markieren, dass eine Überlastung auftritt. Bei dem Client-Endgerät wird das DS-Byte in den Vorsätzen ankommender Pakete gelesen. Ein veränderlicher Durchschnittswert der Anzahl von Pakten, die ein markiertes ECN-Bit enthalten, wird berechnet. Dieser Durchschnittswert bildet dann den Belastungsparameter C₁, der zum Berechnen der Extragebühr verwendet wird: ΔP = f(C1).
Der Gesamtpreis für den Benutzer P_TOT wird dann berechnet, indem die Preise addiert werden, die durch den Haupttarifalgorithmus und dem Extragebührenalgorithmus bestimmt wurde: PTOT = P + ΔP.
Dieser Gesamtpreis wird zu einem Kostenentscheidungsagenten geleitet, der bei dem Client-Endgerät betrieben wird. Dieser Kostenent scheidungsagent ist mit anwenderdefinierten Regeln programmiert. Diese könnten z. B. festlegen, dass der Kostenentscheidungsagent das System berechtigen sollte, eine Verbindung so lange aufrechtzuerhalten, wie die Gesamtkosten, die über eine bestimmte Zeitperiode gemittelt sind, unter einem vorgegebenen Schwellenwert von z. B. 0,01 £ pro Minute liegen, und der Kostenentscheidungsagent eine Verbindung unterbrechen sollte und den Benutzer benachrichtigt, wenn die Kosten über diesen Schwellenwert ansteigen. Wie oben angegeben wurde, könnte der Kostenentscheidungsagent alternativ verschiedene Anwendungen gleichzeitig behandeln und kann in der Wiese programmiert sein, dass er eine der Anwendungen verlangsamt, wenn die Extragebühr für die Verwendung der Datenquelle, auf die durch diese Anwendung zugegriffen wird, steigt.
Für eine einfache Beschreibung wurden in den vorhergehenden Abschnitten die lokalen Änderungen des Tarifs in Reaktion auf eine Überlastung getrennt behandelt. In der Praxis ist dieser Mechanismus im Allgemeinen kombiniert mit anderen Reaktionen auf eine Überlastung sowie mit anderen Ursachen einer Änderung des Tarifs. Außerdem wird eine Entscheidung zum Fortsetzen einer Übertragung trotz Überlastung im Allgemeinen die Übereinstimmung der Teilnehmer an beiden Enden der Übertragung erfordern. Wird das gesamte System aus Datenquelle, Netz und Routern und dem Datenempfänger betrachtet, tritt eine Implementierung einer Tariferhöhung (die hier auch als ein "Bußgeld" bezeichnet wird) in Reaktion auf eine lokalerfasste Überlastung als letzter Ausweg auf. Andere Reaktionen werden zuerst implementiert und zwar in der folgenden numerischen Reihenfolge:

1. das Netz führt eine Umleitung um eine Überlastungsstelle aus
2. das Netz borgt eine Kapazität von niedrigeren Dienstpegeln (niedriger im Kontext der relevanten Dimensionen des QoS) einschließlich der beste Dienst
3. das Netz führt (möglicherweise automatisch) eine Zusatzkapazität ein
4. das Endsystem stellt fest, dass die Überlastung auf dem gemeinsam genutzten Netz und nicht auf den Zugangsverbindungen oder Endsystemen liegt
5. das Endsystem stellt QoS-Anforderungen auf einen "höheren" Pegel ein (wenn dies billiger ist als das Bußgeld für das Ignorieren einer Überlastung bei dem gegenwärtigen Pegel)
6. das Endsystem entscheidet, dass es besser ist, die Überlastung zu ignorieren, vorausgesetzt, dass das Bußgeld dafür verhältnismäßig hoch sein könnte
7. beide (alle) Endsysteme stimmen überein, die Überlastung zu ignorieren.

Typischerweise wird im Schritt 4 ein ECN-Signal erzeugt. Die Schritte 1 bis 3 gehen der Erzeugung dieses Signals voraus und die Schritte 5 bis 7 folgen nach der Erzeugung des ECN-Signals.
Der letzte Schritt vor der Weiterführung einer Verbindung und der Zahlung der Extragebühr dafür besteht darin, eine Übereinstimmung durch beide Teilnehmer herzustellen. Wenn das Kundenendgerät eine Überlastung erfasst, signalisiert das Kundenendgerät dementsprechend diese Tatsache an das andere Endsystem bzw. alle anderen Endsysteme entweder durch Empfangen der expliziten Überlastungsbenachrichtigung oder durch Erfassen eines relevanten Parameters, wie etwa der Paketverlust. In dem vorliegenden Beispiel meldet deswegen das Client-Endgerät 5 an den Datenserver 9, dass eine Belastung auftritt. Der Datenserver ist mit Regeln programmiert, durch die der Kunde als ein Agent implementiert sein kann und die die Reaktion auf ein derartiges Signal festlegen. Der Server kann z. B. den Dienst unter diesen Bedingungen verweigern. Wie oben unter Bezugnahme auf 1 beschrieben wurde, werden in dem vorliegenden Beispiel Tarife über eine Gruppenrufverbindung über das Netz von den Netzbetreibern zu den Kundenendgeräten übertragen und die Abrechnung wird unter Verwendung eines Prozesses "bezahlen und anzeigen" ausgeführt. Die 4a und 4b zeigen die Objekte, die zum Implementieren der Abrechnungsarchitektur in diesem Fall verwendet werden. 4a zeigt die höheren Objekte und 4b zeigt die Komponentenobjekte, die bei einer Softwareimplementierung der Architektur von 4b verwendet werden. In 4a sind Objekte bei dem Client-Endgerät in der Hälfte der Figur gezeigt, die mit "Kunde" bezeichnet ist, und Objekte bei dem Zugangsrouter 7 und dem entsprechenden Netz-Unterbereich sind in der Hälfte der Figur gezeigt, die mit "Netzrand" bezeichnet ist. Die Objekte bei dem Kundengerät enthalten ein Sitzungssteuerungsobjekt S, ein Kundengeschäftsregelobjekt B_c, ein Kundenpreisbildungsobjekt Pr_c, einen QoS-Manager Q, ein Kundenabrechnungsobjekt Act_c und ein Kundenmessobjekt M_c. Das Geschäftsregelnobjekt B_c empfangt Informationen zu diesen Aspekten der Sitzung, die die Zahlungsfähigkeit enthalten, und empfängt aktuelle Preisbildungsdaten von dem Preisbildungsobjekt Pr_c. Das Kundengeschäftsobjekt trifft Entscheidungen unter der Überwachungssteuerung des Kunden, nach denen gebührenpflichtige Dienste verwendet werden sowie wie viele der gebührenpflichtigen Dienste verwendet werden. Diese Entscheidungen werden zu dem QoS-Manager Q geleitet, der entscheidet, welche Mechanismen verwendet werden, um die Forderungen zu erreichen. Der QoS-Manager steuert dann das Kundenmessobjekt M_c, um festzulegen, welche Aspekte des Verkehrs und des Dienstes zu messen sind und welche Aspekte zu ignorieren sind. Das Messobjekt zeichnet dann die ausgewählten Aspekte des Verkehrs, indem z. B. die Anzahl von Paketen, die durch das Kundenendgerät empfangen werden, gezählt wird, und die QoS-Pegel für diese Pakete auf. Diese Daten werden dann gemeinsam mit den aktuellen Tarifen, einschließlich einer Extragebühr für Überlastung, von dem Kundenendgerät verwendet, um die Gebühr zu bestimmen, die an den Netzbetreiber zu zahlen ist. Das Messobjekt M_C ist außerdem mit Anweisungen programmiert, die die Häufigkeit festlegen, mit der es Daten zu dem Kundenabrechnungsobjekt Act_c verschickt. Das Kundenabrechnungsobjekt Act_c leitet Zahlungen an ein Abrechnungsobjekt Act_p in dem Bereich des Netzanbieters.
Die Abrechnungsobjekte bei dem Kundenendgerät können unter Verwendung einer kleinen Datenbank mit entschlüsselten flachen Dateien implementiert sein. Auf der Seite des Netzanbieters können die gleichwertigen Objekte unter Verwendung einer größeren Datenbank, die skalierbar ist, um z. B. zehntausende von Kundenkonten zu bearbeiten, implementiert sein. Ein Objektanfragevermittler (ORB) wird für Datenübertragungen zwischen Objekten der Kundenseite und Objekten der Netzseite verwendet und ist unter Verwendung von handelsüblichen Tools, wie etwa ORBIX (Handelsmarke) von Iona Technologies plc., implementiert.
Auf der Seite des Netzanbieters, d. h. in dem Unterbereich, mit dem das Kundenendgerät verbunden ist, wird der Verkehr des Kunden durch eine Version von M, die mit M_p bezeichnet ist, gemessen, jedoch lediglich auf Grundlage einer Abtastung, die durch die Überwachungsfunktion Po bestimmt ist. Das heißt, der Netzbetreiber tastet den Verkehr des Kunden lediglich mit Unterbrechungen ab. Po steuert, wo in dem Netz Messungen ausgeführt werden, um den gesamten Verkehr eines bestimmten Kunden zu erfassen. Eine Volumenmessfunktion M_b ist verantwortlich für das Melden der gesammelten Verkehrspegel, die in dem veränderlichen Durchschnittswert der Warteschlangenlängen des Routers wiedergegeben werden, an das Preisbildungsobjekt Pr_p. Volumenmessungen werden typischerweise über den gesamten Bereich des Anbieters zu einer zentralisierten Preisbildungsfunktion gesammelt (die aus Gründen der Zuverlässigkeit reproduziert wird). Pr_p bildet Preise, wobei die Geschäftsregeln von dem Geschäftsobjekt B_p des Netzanbieters sowie die aktuellen Verkehrspegel, die durch Mb berichtet werden, und die Preisbildung von benachbarten Anbietern berücksichtigt werden (siehe unten). Die Überwachungsfunktion Po vergleicht Abtastmessungen von M_p mit Abrechnungsnachrichten, die bei Act_p empfangen werden, als ein Ergebnis der eigenen Messungen der Kunden. Wenn festgestellt wird, dass die Rechnungen unzureichend sind, könnte der Dienst an den Zugangssteuerungs-Gateway Acs eingeschränkt oder eine andere Bestrafung ausgelöst werden. Eingeschlossen in das Abrechnungsobjekt prüft ein weiteres Überwachungsobjekt, ob die Abrechnungen mit den Zahlungen in der vertraglich vereinbarten Zahlungsdauer übereinstimmen. Schließlich schafft die Kennungsabbildungsfunktion I eine Abbildung zwischen der Kennung des Kunden (Abrechnung, digitale Signatur usw.) und ihrer aktuellen Netzadresse (die typischerweise durch ISP entweder per Direktruf oder Gruppenruf zugewiesen ist).
5 zeigt die Daten, die zwischen den Abrechnungsobjekten ausgetauscht werden. In diesem Beispiel umfassen die Abrechnungsdaten: Abrechungskennung: Abrechnungsdatensatzkennung; Dienst typkennung; Quellenadresse: Zieladresse; Tarifkennung; Zeit; Periode (d.. die Periode, die durch den Abrechnungsdatensatz abgedeckt ist); Einheiten; Kosten; und Währung. Die Zahlungsdaten umfassen außerdem den Geldbetrag und die Zahlungswährung.
6 zeigt den Managementbereich in den Protokollstapeln bei dem Kundenendgerät und in dem Netzbereich. Im Idealfall gibt es zwei Messpunkte in diesem Bereich, ein Messpunkt, der für den Kunden zuverlässig ist, und ein Messpunkt der für das Netz zuverlässig ist, z. B. an den beiden Punkten, die in der Figur mit (a) bezeichnet sind. Für eine einfache Implementierung kann ein einziger Messpunkt (b) der für beide Teilnehmer zuverlässig ist, verwendet werden. Dies könnte z. B. in einem Sicherheitsmodul, wie etwa eine Verschlüsselungskarte bei dem Client-Endgerät implementiert sein. Als eine Alternative können Messungen an unterschiedlichen Punkten mit einer bestimmten Möglichkeit von Unterschieden zwischen den Messungen ausgeführt werden. Im Netz ist der praktische Messpunkt an der ersten Zugangsvorrichtung, die für jeden Kunden Netzschichtvorsätze (c) (in diesem Fall IP) prüft. ISPs sollten keine tieferen Messungen in ihrem Netz ausführen (d), da ihr Zugriff auf Netz und Systeme Verzögerungen und Verluste einführt.
Für einen einzelnen Kunden (z. B. bei einem Einwählzugriff) würde ein praktischer Punkt, an dem zu messen ist, ebenfalls an der Netzschicht liegen, jedoch in dem Stapel des Endsystems (e). Im Idealfall würden diese Messpunkte in jedem Stapel weiter unten liegen, damit sie näher an der Schnittstelle zwischen den beiden Teilnehmern liegen und mit geringerer Wahrscheinlichkeit durch eine Konkurrenzsituation in dem Stapel beeinflusst werden. Eine Messung an der Verbindungsschicht (f, f) wäre jedoch ungeeignet, da lediglich einige abrechenbare Parameter, die an der Netzschicht eingestellt werden, in Rahmen der Verbindungsschicht wiedergegeben werden; wobei Netzpegel-Gruppenrufverbindungen, Ende-zu-Ende-Latenzforderungen usw. niemals an der Verbindungsschicht sichtbar sind. Außerdem müssten Verbindungsschichtvorsätze ignoriert werden, wenn Paketgrößen für Bandbreitenberechnungen gemessen werden, um offensichtliche Unterschiede zu vermeiden, wenn unterschiedliche Verbindungstechnologien miteinander verkettet werden.
In der Empfangsrichtung (im Stapel weiter oben) bedeutet diese Wahl von Messpunkten, dass die unteren Schichten so dimensioniert sein müssen (Puffergrößen, Unterbrechungs- und Threadplanungsprioritäten), um die strengsten QoS-Anforderungen höherer Schichten zu erfüllen. Wenn Rahmen aus den physikalischen Medien entnommen werden, muss die Maschine in der Lage sein, Daten im Stapel aufwärts zu leiten, ohne eine Möglichkeit, dass Daten der Nutzungsberechnung verworfen werden (z. B. infolge eines Pufferüberlaufs, der durch eine Unterbrechungs-Konkurrenzsituation bewirkt wird), bevor sie zu der Netzschicht gelangen. In der Netzschicht sollte der Dienst des ISP gemessen werden und ist es für QoS-Forderungen am bequemsten, die korrekte Differenzbehandlung der verschiedenen Ströme zu steuern, wenn sie in dem Stapel nach oben geleitet werden (bei Endsystemen) oder weitergeleitet werden (bei Routern).
Die oben beschriebenen Messobjekte können bei geeigneten Modifikationen unter Verwendung von öffentlich verfügbarer Netzmesssoftware, wie etwa das NeTraMet-System von Nevil Brownlee implementiert sein. Dies ist eine Software-Messeinrichtung, die der IETF-Internetabrechnungsarchitektur entspricht, die in RFC 2063 und RFC 2064 beschrieben ist. Die Messeinrichtung bildet unter Verwendung des Verfahrens "am Paket schnüffeln" Paket- und Bytezählerstände für Verkehrsströmungen, die durch ihre Endpunktadressen definiert sind. Obwohl Adressen im Allgemeinen Eternetadressen, Protokolladressen (IP, DECnet, EtherTalk, IPX oder CLNS) oder "Transport"-Adressen (IP-Portnummern usw.) oder jede Kombination davon sein können, werden in der vorliegenden Implementierung lediglich IP-Adressen verwendet. Die Verkehrsströme, die zu beobachten sind, werden durch eine Gruppe von Regeln spezifiziert, die durch ein "Manager"-Programm zu NeTraMed heruntergeladen wird. Verkehrsstromdaten werden über SNMP (einfaches Netzwerkmanagementprotokoll) von einem "Kollektor"-Programm gesammelt.
7 zeigt, wie der Haupttarif, der durch den Netzbetreiber festgelegt ist, zeitlich schwankt. In der Figur ist die Kurve A der momentane Preis, der so berechnet wird, dass er die Belastung des Netzes zu jedem Zeitpunkt widerspiegelt. Die Kurve B ist eines von mehreren unterschiedlichen Tarifbändern. Unterschiedliche Tarifbänder haben unterschiedliche Lebensdauern und der Kunde bezahlt eine Extragebühr für Bänder, die eine größere Stabilität bieten. Tarife werden an die Kundenendgeräte unter Verwendung einer Hierarchie von Kanälen, die durch das Netz unterstützt werden, übermittelt. In einem anfänglichen Vertrag zwischen einem Kunden und einem Dienstanbieter wurde vor einigen Monaten eine einzelne Kanaladresse verteilt, die möglicherweise neue Ankündigungen hält (z. B. für Vertragsänderungen oder für neue Dienste, die spezifizieren, welcher Kanal der zweiten Ebene nach Tarifen zu verfolgen ist oder zum Herunterladen eines neues Codes, um neue Tarifstrukturen zu behandeln). Die Kanäle der zweiten Ebene könnten im Stundenabstand Aktualisierungen liefern, die einfach die Adressen von Kanälen der dritten Ebene ankündigen für die unbeständigsten Informationen. Diese Ka näle der dritten Ebene können Aktualisierungen bei Intervallen von weniger als einer Sekunde befördern. Preise für viele Dienste können auf einem Kanal befördert werden. Für die größte Effizienz kann dieser eine Kanal zu Zeiten der höchsten Vergänglichkeit in mehrere Kanäle unterteilt sein und in stabileren Perioden wieder zu einem einzigen Kanal zusammengefasst werden.
Anstelle der Berechnung eines Standardtarifs für jeden Kunden basierend auf seiner Nutzung könnte der Anbieter wünschen, an jeden Kunden eine individuelle Dienstpegelvereinbarung (SLA) zu verkaufen. Alternativ könnten Kunden auswählen können, einen Dienst aus einem von einem möglichst großen Bereich von SLAs zu akzeptieren. Eine derartige SLA könnte Verpflichtungen des Anbieters enthalten, einen bestimmten Anteil der Dienstverfügbarkeit bereitzustellen, sowie weitere Aspekte der Qualität, die mit dem Kommunikationsverkehr nicht direkt zu tun haben. Die SLA könnte jedoch außerdem eine Verkehrskonditionierungszustimmung (TCA) enthalten, wie sie zwischen Anbietern und zwischen Anbietern und Hauptkunden in der vorgeschlagenen IETF-Architektur differenzierter Dienste vorgesehen ist. Eine TCA enthält Verpflichtungen zu der Dienstgüte des Anbieters unter der Bedingung, dass der Verkehr des Kunden in einem bestimmten Profil liegt. Wenn der Verkehr häufig außerhalb des Profils liegt, gilt die TCA trotzdem für den Ausgleich des Verkehrs in dem Profil. Ein Profil könnte die maximale Größe und Dauer von Signalfolgen festlegen, die der Kunde erzeugen sollte, oder die Spitzenrate oder die Rate mit veränderlichem Durchschnittswert unter spezifizierten Parametern. TCAs können außerdem theoretisch auf empfangenen Verkehr unter der Voraussetzung angewendet werden, dass der Kunde die Rate des entfernten Absenders unter Verwendung von Ratensteuerungsprotokollen steuern kann. In den verschie denen Vorschlägen werden TCAs durch einen Verkehrsüberwacher überwacht, der am Eingang zum Netz des Anbieters installiert ist. Dieser könnte eine spezielle Hardware sein oder mit der Funktion des Routers kombiniert sein. Verkehrsüberwacher verwerfen Verkehr außerhalb des vereinbarten Profils, das in dem Überwacher konfiguriert ist, oder markieren diesen Verkehr. Die Auswahl, welche Pakete zu markieren sind, ist willkürlich. In den verschiedenen Vorschlägen werden die ersten sechs Bits des DS-Bytes als Code-Punkt bezeichnet. Wenn die letzten fünf Bits des Code-Punkts in einem bestimmten Bereich liegen, kann das erste Bit des DS-Bytes als ein Merkerbit verwendet werden, um anzugeben, ob das Paket außerhalb des Profils liegt. Pakete, die außerhalb des Profils liegen, werden trotzdem weitergeleitet, sie besitzen jedoch die höchste Priorität zum Verwerfen in einer überlasteten Warteschlange eines stromabwärtigen Routers. Die verschiedenen Vorschläge enthalten außerdem, dass Kunden Überwacher, die mit dem Anbieterüberwacher in Reihe geschaltet sind, betreiben könnten, um Pakete zu markieren, die außerhalb des Profils liegen. Wenn dies unter der Steuerung des Kunden erfolgt, wird dadurch dem Kunden die Auswahl ermöglicht, welche Pakete auf der Grundlage ihrer Wichtigkeit für die Anwendung markiert werden.
In dem alternativen Lösungsansatz wird die Notwendigkeit vermieden, dass der Anbieter herkömmliche Verkehrsüberwacher betreibt. Der Kunde markiert trotzdem seine Pakete wie durch die verschiedenen Vorschläge vorgeschlagen wurde. Der Anbieter misst jedoch nur den Verkehr auf der Grundlage von Abtastungen. Die Messeinrichtung prüft, ob der Verkehr mit der TCA konform ist, arbeitet jedoch parallel zu dem Datenfluss, der weitergeleitet werden kann, während die Messung an der Speicherkopie des Paketvorsatzes in dem Router erfolgt. Wenn der Verkehr außerhalb des Profils liegt, wird der Kunde mit einem Bußgeld belegt. Er wird z. B. entweder abgeschaltet oder mit einem Strafgeld belegt oder der Kreditumfang wird verringert. Dies ist anders als bei dem herkömmlichen Verkehrsüberwacher, der die Pakete, die außerhalb des Profils liegen, "bestraft", indem sie markiert oder verworfen werden. Bei diesem herkömmlichen Lösungsansatz können die Pakete nicht weitergeleitet werden, bevor sie die Überwachungsprüfung durchlaufen haben. Wenn sie weitergeleitet werden würden, könnten sie nicht markiert oder verworfen werden.
Der Vorteil dieses Lösungsansatzes besteht darin, dass eine Weiterleitung typischerweise viel schneller ist als eine Überwachung. Wenn z. B. für die Weiterleitung eine vollständig optische Technologie verwendet wird, ist es viel komplexer, eine Überwachung zu implementieren und es ist deswegen unwahrscheinlich, dass diese in der nächsten Zeit in der Optik erreicht wird. Bei dem vorgeschlagenen Lösungsansatz können Abtastungen des Verkehrs aus dem optischen Fluss, der zu überwachen ist, aus dem Band elektronisch abgegriffen werden. Die Abtastrate kann so gewählt werden, dass der Verkehr einen Puffer füllen kann, bevor er an den Überwacher geleitet wird. Dadurch kann der Überwacher zwischen den Abtastungen mit der Optik "mithalten", indem der Puffer geleert wird. Dies ist eine Anwendung des Amdahl-Gesetzes, das den maximalen Leistungsgewinn aus einem parallelen Prozess, der durch den kritischen (langsamsten) Weg eingeschränkt ist, betrifft.
Die nachfolgenden Tabellen 1 bis 7 zeigen einen Java-Quellencode, der verwendet wird, um zwei unterschiedliche Tarife zu implementieren. Der Code von Tabelle 1 stellt die Operationen dar, die für eine Übermittlung zwischen einem Kundensystem und einem Tarifalgorithmus, der durch das Kundensystem heruntergeladen wird, verwendet werden. Tabelle 2 zeigt einen Algorithmus eines linearen Tarifs, bei dem der Tarif von der Gesamtzahl der durch den Kunden gesendeten Pakete und empfangenen Pakete gemeinsam mit einem Überlastungsparameter abhängt. 3 zeigt den Code zum Erzeugen der Kundenanzeige in diesem Fall. 4 zeigt den Code, der verwendet wird, um den Tarif bei dem Server des Netzbetreibers anzuzeigen. Tabelle 5 zeigt einen Algorithmus eines exponentiellen Tarifs. Tabelle 6 erzeugt die Kundenanzeige und Tabelle 7 die Betreiberanzeige für den Algorithmus des exponentiellen Tarifs. Durch Herunterladen eines Java-Codes, um die Anwenderschnittstelle zu erzeugen, kann diese Schnittstelle auf die Erfordernisse des bestimmten Tarifs zugeschnitten werden und kann angepasst werden, wenn sich der Tarif ändert.
Die Gruppenrufübertragung von Tarifen kann verwendet werden, um einen Markt von Netzdiensten von unterschiedlichen Dienstanbietern zu unterstützen. 12 zeigt eine modifizierte Anwenderschnittstelle, die in diesem Fall bei dem Kundenendgerät verwendet wird. Diese Anwenderschnittstelle könnte z. B. dann verwendet werden, wenn der Kunde eine Gruppenruf-Audio-Video-Konferenz fordert, bei der Daten, Audio- und Video-Anwendungen beteiligt sind. Eine Schnittstelle zur Slider-Steuerung wird verwendet, um den geforderten Qualitätspegel Q für jeden der beteiligten Datenströme einzustellen. Eine grundlegende Anwendung übersetzt dann den Q-Parameter in geeignete Leistungsparameter wie etwa die geforderte Bandbreite, den Paketverlust und die Latenz. Das Kundenendgerät empfangt per Gruppenruf gesendete Tarife von zwei unterschiedlichen Dienstanbietern oder Netzbetreibern SP1 und SP2. Zusätzlich zu der Anzeige der Kosten mit dem momentan ausgewählten Dienstanbieter SP1 zeigt die Anwenderschnittstelle außerdem die Kosten an, wenn der andere Dienstanbieter SP2 ausgewählt werden würde. Der Anwender kann sich entscheiden, für einen oder alle Datenströme zu dem zweiten Dienstanbieter SP2 zu schalten. Die laufenden Kosten des Videodatenstroms in dem in der Figur gezeigten Beispiel werden z. B. durch Umschalten zu dem zweiten Dienstanbieter wesentlich verringert. Die Entscheidung zum Umschalten kann manuell durch den Anwender erfolgen oder könnte durch einen Softwareagenten, der bei dem Kundenendgerät betrieben wird, automatisiert sein. In dem Kontext des Netzes, wie etwa das in 1 dargestellte Netz, kann die Umschaltung zu einem anderen Anbieter erfolgen, indem eine andere Nummer unter Verwendung des Modems des Kundenendgerätes gewählt wird, so dass die PPP-Verbindung über einen anderen Zugangsrouter, möglicherweise bei einem anderen Netzbereich erfolgt. Ein derartiges Umschalten zwischen Dienstanbietern wird erleichtert, wenn ein Protokoll, wie etwa das Internetprotokoll Version 6, verwendet wird, das in einer vorgeschlagenen Implementierung sowohl Host- als auch Siteadressen bietet, wobei die Hostadressen unverändert bleiben können, selbst wenn sich eine Site-IP-Adresse ändert. In diesem Fall würde das Kundenendgerät sowohl eine Hostadresse als auch eine Siteadresse haben, und während sich die Siteadresse beim Umschalten des Dienstanbieters ändern würde, bliebe die Host-IP-Adresse unverändert.
Obwohl die bisher beschriebenen Beispiele im Kontext von föderierten Paketdatennetzen, wie etwa das Internet, lagen, können viele Aspekte der Erfindung außerdem vorteilhaft in anderen Typen von Netzen, wie etwa in einem schaltungsvermittelten PSTN (öffentliches Fernsprechwählnetz) verwendet werden. 11 zeigt ein Beispiel der Erfindung, das in diesem Kontext gilt. In diesem Netz sind Kundenendgeräte 81, die in diesem Beispiel so genannte intelligente Telephone sind, d. h. Telephone, die einen Mikroprozessor und eine Datenschnittstelle enthalten, über lokale Vermittlungen 82 und Gruppenvermittlungen 3 mit den Telephonienetzen verbunden. Die Gruppenvermittlungen 83 sind über einen gemeinsamen Kanal SS7 (Signalisierungssystem Nummer 7) des Signalisierungsnetzes mit einem Dienststeuerungspunkt 85 verbunden, der für die Ausführung von fortschrittlichen Anrufsteuerfunktionen verantwortlich ist. Der Dienststeuerungspunkt 85 ist außerdem mit einem Betriebsunterstützungsserver 86 verbunden, der für Rechnungslegungsoperationen verantwortlich ist und in diesem Beispiel die Einstellung von Tarifen für das Netz steuert. Der OSS-Server und die Kundenendgeräte enthalten Tarif-Instanzen (TE). Das feste PSTN-Netz ist außerdem über ein Gateway 87 mit einem Zellen-GSM-Netz 88 verbunden. Basisstationen BS in dem Zellennetz übermitteln Signale zu intelligenten Mobiltelephonen 89. Im Betrieb werden Netztarife an Kundenendgeräte über das PSTN-Netz und über das GSM-Netz verteilt. Der Tarif kann vorteilhaft wieder die Form von Java-Funktionen besitzen, die bei Prozessoren in den Kundenendgeräten ausgeführt werden. Die Java-Funktionen können als Internet-Pakete durch Streaming übertragen werden. Bei einer Implementierung können diese Internet-Pakete über die PSTN-Netze und die GSM-Netze selbst verteilt werden. Die Pakete können z. B. eingekapselt sein und unter Verwendung der MTP-Transportschicht (Message Transport Part) zu den Gruppenvermittlungen transportiert werden und können unter Verwendung von Außerbandsignalisierung zu den Kundenendgeräten weiter ü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 Bei spielen überwacht der Netzbetreiber die Belastung von Betriebsmitteln in dem Netz und kann Signale an die Tarif-Instanzen in den Kundenendgeräten übermitteln, die Tarife in der Weise zu ändern, dass sie die Knappheit oder andere Angaben der relevanten Betriebsmittel widerspiegeln. Kundenendgeräte können selbst die Netzbelastung überwachen und automatisch Änderungen in den Tarifen erzeugen. Die Nutzung von Netzbetriebsmitteln kann lokal durch die Kundenendgeräte gemessen werden anstelle der herkömmlichen Rechnungslegung, die im Netz ausgeführt wird. Der Netzbetreiber kann die Messung der Nutzungsdaten überwachen, indem eine Abtastung, die oben beschrieben wurde, ausgeführt wird.
Tabelle 1
Tabelle 2
Tabelle 3
Tabelle 4
Tabelle 5
Tabelle 6
Tabelle 7

Claims

Verfahren zum Betreiben eines Kommunikationsnetzes (2A, 2B, 2C, 3, 4), das ein paketbasiertes Internetworking-Protokoll unterstützen, wobei das Verfahren umfasst: Verteilen von Tarifinformationen über das Kommunikationsnetz zu mehreren Kundenendgeräten (5, 8, 9), die an das Kommunikationsnetz angeschlossen sind, wobei die Tarifinformationen verwendbar sind, um als einen Tarif eine Formel für die Berechnung eines Preises als Funktion der Belastung des Kommunikationsnetzes zu erzeugen, um von dem Kundenendgerät des Kommunikationsnetzes verwendet zu werden; Messen der Belastung des Netzes bei dem Kundenendgerät; und Berechnen eines Preises für die Verwendung des Kommunikationsnetzes durch das Kundenendgerät bei dem Kundenendgerät unter Verwendung des Tarifs und der gemessenen Belastung.
Verfahren nach Anspruch 1, bei dem der Preis auf der Grundlage lokaler Beobachtungen der Netzbelastung bei dem Kundenendgerät (5, 8, 9) eingestellt wird.
Verfahren nach Anspruch 1 oder 2, bei dem der Schritt des Verteilens der Tarifinformationen die Schritte des getrennten Übermittelns einer Formel für die Berechnung eines Netznutzungspreises und von Koeffizienten für die Verwendung in der Formel umfasst.
Verfahren nach Anspruch 1, 2 oder 3, bei dem der Tarif an Kundenendgeräte (5, 8, 9) durch Gruppenruf verteilt wird.
Verfahren nach einem der vorhergehenden Ansprüche, das einen weiteren Schritt des Verteilens eines revidierten Tarifs an die Kundenendgeräte (5, 8, 9) umfasst.
Verfahren nach Anspruch 5, bei dem der Schritt des Verteilens eines revidierten Tarifs das Übermitteln revidierter Koeffizienten für die Verwendung in der Formel, die vorher an die Kundenendgeräte (5, 8, 9) verteilt worden ist, umfasst.
Verfahren nach Anspruch 5 oder 6, das das Erfassen der Belastung von Netzbetriebsmitteln und das Bestimmen eines revidierten Tarifs in Abhängigkeit von den Ergebnissen des Schrittes des Erfassens der Belastung umfasst.
Verfahren nach Anspruch 7, bei dem die Schritte des Erfassens der Belastung und des Bestimmens eines revidierten Tarifs durch eine Netzmanagement-Plattform (10) automatisch ausgeführt werden.
Verfahren nach Anspruch 7, bei dem die Schritte des Erfassens der Belastung und des Bestimmens eines revidierten Tarifs bei einem Kundenendgerät (5, 8, 9) automatisch ausgeführt werden.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln von Daten, die einen ersten vorgegebenen Kommunikationskanal identifizieren, an ein Kundenendgerät (5, 8, 9) und anschließend bei dem Kundenendgerät das Überwachen des Kommuni kationskanals auf Übermittlungen, die mit dem Tarif in Beziehung stehen, umfasst.
Verfahren nach Anspruch 10, das das Übermitteln von Daten, die einen oder mehrere weitere Kommunikationskanäle identifizieren, auf dem ersten Kommunikationskanal und das anschließende Überwachen zusätzlich des oder jedes weiteren Kanals durch das Kundenendgerät (5, 8, 9) umfasst.
Verfahren nach Anspruch 11, das das Einführen eines neuen Kommunikationskanals und das Identifizieren des neuen Kommunikationskanals auf einem vorher für das Kundenendgerät (5, 8, 9) identifizierten Kommunikationskanal in Abhängigkeit von der Belastung des vorher identifizierten Kommunikationskanals umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln verschlüsselter Tarifdaten an das Kundenendgerät (5, 8, 9) und das Entschlüsseln der Tarifdaten bei dem Kundenendgerät umfasst.
Verfahren nach Anspruch 13, bei dem die Tarifdaten in einem Sicherheitsmodul, das sich bei dem Kundenendgerät (5, 8, 9) befindet, entschlüsselt werden.
Verfahren nach Anspruch 13 oder 14, das das Übermitteln unterschiedlicher Tarifdaten auf mehreren unterschiedlichen Kommunikationskanälen und das Bereitstellen eines Schlüssels, der für Tarifdaten auf einem der mehreren Kommunikationskanäle spezifisch ist, bei einem Kundenendgerät (5, 8, 9) umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln unterschiedlicher Tarife mit jeweils unterschiedlichen Lebensdauern an jeweils verschiedene der mehreren Kundenendgeräte (5, 8, 9) umfasst.
Verfahren zum Betreiben eines Kommunikationsnetzes (2A, 2B, 2C) nach Anspruch 16, das umfasst: Berechnen von Gebühren für die Nutzung der Netzbetriebsmittel durch ein entsprechendes Kundenendgerät, das an das Netz angebracht ist, für jeden der mehreren Kunden (5, 8, 9) unter Verwendung eines ausgewählten der mehreren unterschiedlichen Tarife, Messen der Belastung der Netzbetriebsmittel und Verändern eines oder mehrerer der mehreren unterschiedlichen Tarife in Abhängigkeit von der Belastung der Netzbetriebsmittel.
Verfahren nach einem der vorhergehenden Ansprüche, das umfasst: a) Berechnen einer Gebühr für Verkehr, der zwischen dem Netz (2A, 2B, 2C) und dem Endgerät übermittelt wird, bei dem Kundenendgerät (5, 8, 9) unter Verwendung der Tarifinformationen und Ausführen einer Bezahlung; und b) Abtasten lediglich eines Teils des zwischen dem Anwender eines Kundenendgeräts und dem Netz übermittelten Verkehrs und für den abgetasteten Verkehr Vergleichen irgendwelcher Bezahlungen, die von dem Anwender vorgenommen werden, und der Bezahlung, die durch den Tarif bedingt ist.
Verfahren nach einem der vorhergehenden Ansprüche, das umfasst: a) Abschließen von Verträgen zwischen Netzanwendern und einem Netzbetreiber und Speichern von Anwendervertragsdaten; b) Abtasten lediglich eines Teils des Verkehrs zu oder von einem Anwender auf dem Netz; c) Vergleichen des abgetasteten Verkehrs mit Verkehr, für den der Anwender einen Vertrag geschlossen hat; und d) Ändern des Anwenderstatus, wenn zwischen den abgetasteten Parametern und den vertraglich festgelegten Parametern ein Unterschied erfasst wird.
Verfahren nach Anspruch 19, bei dem der Schritt des Abschließens von Verträgen zwischen Netzanwendern und dem Netzbetreiber das Vornehmen einer Vorauszahlung für die Netznutzung umfasst.
Verfahren nach Anspruch 19 oder 20, bei dem der Schritt des Abschließens von Verträgen das Zuordnen einer Verkehrskonditionierungszustimmung, TCA (Traffic Conditioning Agreement), zu einem entsprechenden Kunden umfasst.
Verfahren nach Anspruch 19, 20 oder 21, bei dem der Schritt des Änderns des Anwenderstatus das Belegen des Anwenders mit einem Bußgeld umfasst.
Verfahren nach Anspruch 19, bei dem der Anwender im Schritt a) ein Guthaben an den Netzbetreiber transferiert, wobei das Guthaben im Schritt d) belastet wird, wenn eine Diskrepanz zwischen den abgetasteten Parametern und den Vertragsparametern erfasst wird.
Verfahren nach einem der vorhergehenden Ansprüche, das umfasst: Verteilen eines Tarifs über das Kommunikationsnetz (2A, 2B, 2C, 3, 4) an mehrere Kundenendgeräte (5, 8, 9), die an das Kommunikationsnetz angeschlossen sind, Messen der Verwendung von Netzbetriebsmitteln durch das Kundenendgerät bei dem Kundenendgerät; und Berechnen einer Gebühr für die Verwendung durch das Kundenendgerät des Netzes unter Verwendung der Ergebnisse des Schrittes des Messens in Verbindung mit dem Tarif.
Verfahren nach einem der vorhergehenden Ansprüche, das das Übermitteln unterschiedlicher Tarife von mehreren verschiedenen Dienstanbietern an ein entsprechendes Kundenendgerät (5, 8, 9) und bei dem Kundenendgerät das Wählen zwischen den Dienstanbietern und das Empfangen von Netzdiensten über den ausgewählten Dienstanbieter umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das das Betreiben mehrerer unterschiedlicher Dienste auf dem Kommunikationsnetz (2A, 2B, 2C, 3, 4), das Übermitteln unterschiedlicher Tarife für unterschiedliche jeweilige Dienste an die mehreren Kundenendgeräte (5, 8, 9) und das wahlweise Verändern eines jeweiligen Tarifs in Abhängigkeit von einem Betriebszustand des jeweiligen Dienstes umfasst.
Kommunikationsnetz (2A, 2B, 2C, 3, 4), das ein paketbasiertes Internetworking-Protokoll unterstützt, wobei das Netz umfasst: Tarifverteilungsmittel zum Verteilen von Tarifinformationen über das Kommunikationsnetz an mehrere Kundenendgeräte (5, 8, 9), die an das Kommunikationsnetz angeschlossen sind, wobei die Tarifinformationen verwendbar sind, um eine Formel zum Berechnen eines Preises als eine Funktion der Belastung des Kommunikationsnetzes, die bei jedem Kundenendgerät gemessen wird, als einen Tarif zu erzeugen, der von dem Kundenendgerät des Kommunikationsnetzes verwendet wird.
Kommunikationsnetz nach Anspruch 27, das ferner mehrere Kundenendgeräte umfasst, wovon jedes Berechnungsmittel zum Berechnen eines Preises für die Verwendung des Kommunikationsnetzes durch das Kundenendgerät unter Verwendung des Tarifs umfasst.
Kundenendgerät (5, 8, 9) für die Verwendung in einem Kommunikationsnetz (2A, 2B, 2C, 4, 4), das ein paketbasiertes Internetworking-Protokoll unterstützt, wobei das Kundenendgerät umfasst: eine Netzschnittstelle, die so betreibbar ist, dass sie Tarifinformationen, die verwendbar sind, um eine Formel, die eine Funktion der Belastung des Kommunikationsnetzes ist, als einen Tarif zu erzeugen, über das Kommunikationsnetz empfangen; einen Speicher, der mit bei der Schnittstelle empfangenen Tarifinformationen programmiert ist; ein Messgerät zum Messen der Belastung des Netzes; und einen Prozessor, der mit dem Messgerät und mit dem Speicher verbunden und so beschaffen ist, dass er unter Verwendung der Tarifinformationen und der gemessenen Belastung der Netzinformationen einen Netznutzungspreis berechnen kann.