-
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
Bc, ein Kundenbewertungsobjekt Prc, einen QoS-Manager Q, ein Kundenabrechnungsobjekt
Actc und ein Kundenmessobjekt Mc.
Das Geschäftsregelobjekt
Bc empfängt
Informationen über
diejenigen Aspekte der Sitzung, die die Verpflichtung für die Zahlung
beinhalten, und empfängt
aktuelle Bewertungsdaten vom Bewertungsobjekt Prc.
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
Mc, 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 Mc wird auch
durch das Abrechnungsobjekt mit Befehlen programmiert, die die Häufigkeit
bestimmen, mit der Daten an das Kundenabrechnungsobjekt Actc gemeldet werden. Das Kundenabrechnungsobjekt
Actc leitet Abrechnungsinformationen (bewertet
oder nicht) zu einem Abrechnungsobjekt Actp 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 Mp 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
Mb ist für
das Melden von angesammelten Verkehrspegeln, wie im sich bewegenden Mittelwert
der Router-Warteschlangenlängen
widergespiegelt, an das Bewertungsobjekt Prp 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. Prp legt Preise fest, die die Geschäftsregeln
vom Geschäftobjekt Bp des Netzanbieters sowie die aktuellen Verkehrsniveaus,
die von Mb gemeldet werden, und die Bewertung
von benachbarten Anbietern berücksichtigen. Die Überwachungsfunktion
Po vergleicht Abtastmessungen von Mp mit
Abrechnungsmeldungen, die bei Actp 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 Na in Nb 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 Na und
Nb hervor. Wbas und
Wbar bedeuten die Gewichtungen pro Richtung,
die auf die Gebühr
angewendet werden, die Na auf Nb für das Senden
von Daten zu Nb bzw. für das Empfangen von Daten von
Nb anwendet, während Wabs und
Wabr die Gewichtungen sind, die Nb anwendet, wenn Na für das Senden
von Daten zu Na bzw. das Empfangen von Daten
von Na 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 Nc)
haben natürlich
keinen Anbieterstatus auf dem Netzmarkt. Für alle j gilt folglich Wcjr = 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.