-
GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft Richtliniensteuerung in einem Kommunikationsnetz
und insbesondere, jedoch nicht notwendigerweise, Richtliniensteuerung
an einem GGSN eines Mobiltelekommunikationsnetzes.
-
ALLGEMEINER STAND DER TECHNIK
-
Das
europäische
Telekommunikationsinstitut, das als 3GPP bekannt ist, befindet sich
gegenwärtig
im Prozess des Einführens
eines neuen Satzes von Protokollen für das Mobiltelekommunikationssystem,
das als universelles Mobiltelekommunikationssystem (UMTS) bekannt
ist. Die Architektur eines UMTS-Netzes basiert auf einem UMTS-Kernnetz
und einem terrestrischen UMTS-Funkzugangsnetz (UMTS Terrestrial
Radio Access Network, UTRAN). Für
den Datentransfer wird UMTS einen Paketvermittlungsdienst wie den
allgemeinen Datenpaketfunkdienst (General Packet Radio Service, GPRS)
oder etwas Ähnliches
ausführen.
Um Daten zu senden und zu empfangen, baut ein mobiles Endgerät oder ein
Teilnehmergerät
(User Equipment, UE) eine „Sitzung" mit einem Knoten
in dem Netz auf, der als ein Gateway-GPRS-Unterstützungsknoten (Gateway GPRS
Support Node, GGSN) bekannt ist. Der GGSN stellt eine Schnittstelle
für das
UE zur Außenwelt
bereit.
-
Eine
alternative Architektur ist in
WO 01/89234 A offenbart, die ein System einführt, in
dem ein Funknetzserver als ein Richtlinienserver betreibt, der mit
einem Bandbreitenbroker zusammenarbeitet, der als ein Richtlinienentscheidungspunkt
arbeitet. Randrouter fungieren als Richtliniendurchsetzungspunkt
für ihre
Domäne.
-
In
dem Kernnetz setzt der GGSN Richtlinien (d. h. Steuerungsoptionen)
des Netzbetreibers durch. Zum Beispiel kann ein Betreiber Richtlinien
definieren, die festlegen, welche Teilnehmer auf welche Datendienste
zugreifen können
(d. h. das Blockieren und Freigeben von Diensten), und Teilnehmern
Prioritäten
zuteilen, z. B. zu welchen Zeitpunkten Teilnehmern eine Verbindung
herstellen können.
-
Um
die Bereitstellung von Multimediadiensten zu erleichtern, hat 3GPP
ein so genanntes IP-Multimedia-Kernnetzuntersystem
(IMS) entwickelt. Das IMS kommuniziert mit dem GPRS-Netz und enthält alle
Elemente, die dazu verwendet werden, IP-basierte Multimediadienste
bereitzustellen. Für
einen Anruf von einem Mobilgerät
zu einem anderen Mobilgerät
wird das IMS zwischen zwei GPRS-Netzen sitzen (vorausgesetzt, dass
die Mobilgeräte
zu unterschiedlichen Netzen gehören).
Bestimmte Knoten des IMS können
dem Betreiber eines ersten der GPRS-Netze gehören, wobei die übrigen Knoten
dem Betreiber des zweiten Netzes gehören (einige IMS-Knoten können einer
dritten Partei gehören).
Das Basisprotokoll für
Multimediadienste ist das IETF-Sitzungsinitiierungsprotokoll
(SIP). SIP ermöglicht
es einer anrufenden Partei, eine Sitzung mit einer angerufenen Partei
aufzubauen (über
die Daten ausgetauscht werden können),
obwohl die anrufende Partei die aktuelle IP-Adresse der angerufenen Partei nicht
kennt, bevor sie den Anruf initiiert. SIP stellt weitere Funktionalität bereit,
einschließlich
der Verhandlung über
Sitzungsparameter (z. B. Dienstgüte (Quality
of Service, QoS) und Codecs).
-
Das
IMS umfasst eine bedienende Verbindungszustandssteuerfunktion (Serving
Call State Control Function, S-CSCF), die die Sitzungssteuerungsdienste
für das
UE durchführt
und einen Sitzungszustand wie von dem Netzbetreiber zur Unterstützung von
Diensten erfordert aufrechterhält.
Die Hauptfunktion, die von der S-CSCF während einer Sitzung durchgeführt wird,
ist das Routen von eingehenden und abgehenden Anrufaufbauanfragen.
Das IMS kann auch eine Proxy-CSCF (P-CSCF) umfassen. Die Hauptfunktion, die
von der P-CSCF während einer
Sitzung durchgeführt
wird, ist das Routen von SIP-Nachrichten zwischen dem UE und dem
Heimatnetz. Die P-CSCF
kommuniziert mit dem GGSN.
-
1 stellt
schematisch ein typisches Szenario dar, wobei das Teilnehmergerät (User
Equipment, UE) 1 ein Teilnehmer eines Mobiltelefonnetzes 2.
Der Teilnehmer, der das UE 1 verwendet, wird in dem Netz 2 durch
eine einzigartige Teilnehmeridentität identifiziert und das Netz
wird als das „Heimat"-Netz des Teilnehmers
bezeichnet. In dem in 1 dargestellten Szenario ist
das UE 1 bei einem „Fremd"- oder besuchten
Netz 3 registriert. Das besuchte Netz umfasst ein GPRS-Netz
(GPRS = General Packet Radio Service, allgemeiner Datenpaketfunkdienst) 4 (sowie
ein Leitungsvermittlungsnetz, das in 1 nicht
dargestellt ist). Im Netz 4 können zwei Knoten, die für das UE 1 relevant
sind, identifiziert werden. Dabei handelt es sich um den bedienenden
GPRS-Unterstützungsknoten
(Serving GPRS Support Node, SGSN) 5 und den Gateway-GPRS-Unterstützungsknoten
(Gateway GPRS Support Node, GGSN) 6. Die Rolle des SGSN 5 besteht
darin, Subskriptionsdaten (Identitäten und Adressen) zu pflegen
und die Position des UE in dem Netz zu verfolgen. Die Rolle des
GGSN 6 besteht darin, Subskriptionsinformationen und zugeteilte IP-Adressen
zu pflegen und den SGSN zu verfolgen, an den das UE 1 angeschlossen
ist. Der GGSN 6 ist mit einem IP-Netz verbunden.
-
In
der Regel, wenn das UE 1 eingeschaltet wird, „schließt" es sich selbst an
den GGSN an und ein Paketdatenprotokoll-Kontext wird zwischen dem UE 1 und
dem GGSN 6 hergestellt. Dieser Kontext stellt eine „Leitung" zum Transportieren
von Daten von dem UE 1 zu dem GGSN 6 bereit. Dieser
Vorgang schließt
die Zuteilung einer IP-Adresse an das UE 1 ein. In der
Regel ist der Routingpräfixteil
der Adresse ein Routingpräfix,
das dem GGSN 6 zugeteilt wird.
-
1 stellt
ein zweites UE 7 dar, das bei einem Fremdnetz 8 registriert
ist und dessen Heimatnetz ein Netz 9 ist. Knoten und (Teil-)Netze
in dem Fremdnetz 8 sind durch dieselben Bezugsziffern identifiziert,
wie sie im Netz 3 verwendet wurden. Das IP-Multimedia-Kernnetzuntersystem
(INS) enthält alle
Elemente, die zum Bereitstellen von IP-basierten Multimediadiensten erforderlich
sind, einschließlich des
Einrichtens von Sitzungen zwischen den zwei UE 1, 7.
Die von dem INS bereitgestellte Funktionalität ist in 3GPP TS 23.228 dargelegt.
Das IMS besteht aus einem Satz Knoten, die mit einem IP-Fernnetz
verbunden sind. In dem IMS von 1 sind ein P-CSCF-Knoten
(P-CSCF = Proxy Call State Control Function, Proxy-Verbindungszustandssteuerfunktion) 10 in
jedem der besuchten Netze 3, 8 und ein S-CSCF-Knoten (S-CSCF
= Serving Call State Control Function, bedienende Verbindungszustandssteuerfunktion) 11 in
jedem der Heimatnetze 2, 9 dargestellt. Um eine
Sitzung zwischen den zwei UE 1, 7 von 1 aufzubauen,
wird entsprechende SIP-Signalisierung von der P-CSCF, die in dem
besuchten Netz angeordnet ist, mit dem die initiierende Partei verbunden
ist, an die S-CSCF, die in dem Heimatnetz des initiierenden UE angeordnet
ist, gesendet. Diese S-CSCF kontaktiert dann die S-CSCF in dem Heimatnetz
des angerufenen UE, die wiederum die P-CSCF in dem besuchten Netz,
mit dem das angerufene UE verbunden ist, kontaktiert. Eine Datensitzung
kann dann zwischen den zwei GGSN 6 aufgebaut werden, mit
denen die UE 1, 7 verbunden sind. Wenn ein UE
bei seinem Heimatnetz registriert ist, dient die S-CSCF des Heimatnetzes
auch als eine P-CSCF für
das UE.
-
Die
Internet Engineering Task Force (IETF) hat ein Protokoll spezifiziert,
das als gemeinsamer offener Richtliniendienst (Common Open Policy
Service, COPS) bekannt ist, bei dem es sich um ein einfaches Abfrage-
und Antwortprotokoll handelt, das zum Austauschen von Richtlinieninformationen
(die sich auf eine beliebige Funktion, einen beliebigen Dienst usw.
beziehen können,
von der bzw. dem gewünscht
wird, eine Kontrolle darüber
auszuüben) zwischen
einem Richtlinienserver (Richtlinienentscheidungspunkt, Policy Decision
Point oder PDP) und dessen Clienten (Richtliniendurchsetzungspunkte,
Policy Enforcement Points oder PEP) verwendet werden kann. COPS
ist ein Abfrage-/Antwortprotokoll,
das zwei gewöhnliche
Modelle zur Richtliniensteuerung unterstützt: Auslagerung und Konfiguration.
-
Hamer
et al. beschreiben in „COPS-PR
for outsourcing in UMTS: UMTS Go PIB", Internet-Entwurf von IETF, datiert
12.11.2001, Nutzungsvorschriften zum Unterstützen von COPS-Auslagerungsrichtliniendiensten
in der UMTS-Umgebung. Durch Verwendung des UMTS Go PIB wird COPS-PR
zur Auslagerung über
die Go-Schnittstelle eingesetzt.
-
Im
Auslagerungsszenario delegiert der PEP die Verantwortlichkeit an
einen externen Richtlinienserver (PDP), um Entscheidungen in dessen
Namen zu fällen.
Zum Beispiel muss der PEP im COPS-Nutzung-zur-Ressourcenreservierung-Protokoll
(COPS Usage for Resource reSerVation Protocol, COPS-RSVP), wenn eine
RSVP-Reservierungsnachricht ankommt, entscheiden, ob er die Anfrage zulässt oder
abweist. Er kann diese Entscheidung auslagern, indem er eine spezifische
Abfrage an seinen PDP sendet, auf dessen Entscheidung wartet, bevor
er die ausstehende Reservierung zulässt. Dies ist in 2 dargestellt.
-
Das
COPS-Konfigurationsmodell befasst sich mit der Art von Ereignissen
am PEP, die eine sofortige Richtlinienentscheidung erfordern. Diese
Variation ist als COPS-zur-Bereitstellung (COPS for Provisioning,
COPS-PR) bekannt. COPS-PR ist als ein Mittel zum Einführen von
Richtlinien aus dem Entscheidungsknoten in den Durchsetzungsknoten,
in dem die Richtlinie in Kraft gesetzt wird, konzipiert. Mit diesem
Protokoll werden Entscheidungen asynchron von dem Entscheidungsknoten
zu einer beliebigen Zeit übertragen
und der Durchsetzungsknoten antwortet, um anzuzeigen, ob die Richtlinie
eingeführt wurde
oder nicht. Dies ist in 3 gezeigt. Der PDP kann den
PEP in Eigeninitiative darauf konfigurieren, auf eine beliebige
spezifische Art und Weise auf externe Ereignisse (wie Benutzereingabe),
PEP-Ereignisse und eine beliebige Kombination davon (N:M-Korrelation)
zu reagieren. Das Konfigurieren oder Bereitstellen kann in einem
großen
Schritt (z. B. Konfiguration der QoS des gesamten Routers) oder in
Teilen (z. B. Aktualisieren eines DiffServ-Kennzeichnungsfilters)
durchgeführt
werden.
-
COPS-PR
ist ein Universalprotokoll und kann zum Einführen von Richtlinien für beliebige Funktionen
verwendet werden. Es setzt das Konzept einer Richtlinieninformationsbasis (Policy
Information Base, PIB) ein. Eine PIB definiert die Richtliniendaten.
Es können
eine oder mehrere PIB für
einen gegebenen Richtlinienbereich vorliegen und unterschiedliche
Richtlinienbereiche können
unterschiedliche Sätze
von PIB aufweisen. Dies ermöglicht
die Unterstützung
eines Modells, das mehrere PDP beinhaltet, die sich nicht überlappende
Richtlinienbereiche auf einem einzigen PEP steuern.
-
Ein „Client-Typ" (Wert) wird zum
Identifizieren der Funktion verwendet, die von der Richtliniensteuerung
verwaltet wird. Ein einziger Client-Typ für einen gegebenen Richtlinienbereich
(z. B. DiffServ) wird für
alle PIB verwendet, die in diesem Bereich existieren. Der Client
wird alle COPS-PR-Client-Typen, die er unterstützt, als sich nicht überlappende und
unabhängige
Namensräume,
in denen Instanzen geteilt werden, behandeln. Für jeden Client-Typ, den der
PEP unterstützt,
kann der PEP nur in Richtung eines einzigen PDP arbeiten.
-
3GPP
hat einen Mechanismus zum Ermöglichen,
dass die P-CSCF eine Funktion in dem GGSN steuert, entwickelt. Die
Architektur zur QoS-Verwaltung, die von 3GPP definiert wurde (Empfehlung 23.207),
ist in 4 dargestellt. Wie in dieser Figur gezeigt, kommuniziert
der GGSN (Gateway-Knoten) mit einer PCF-Funktion (PCF = Policy Control
Funktion, Richtliniensteuerfunktion), die ortsgleich mit der P-CSCF
angeordnet sein kann. Diese Schnittstelle zwischen dem GGSN und
der PCF-Funktion in der P-CSCF ist als die Go-Schnittstelle spezifiziert.
Die Go-Schnittstelle basiert auf dem COPS-Protokoll. Es ist anzumerken,
dass, obwohl das PCF-Element
außerhalb
der P-CSCF angeordnet sein kann, ermöglicht der 3GPP-Standard, dass
es ortsgleich mit der P-CSCF
angeordnet ist, und die Protokolle folglich den Be trieb in dieser
Konfiguration unterstützen
müssen.
-
KURZDARSTELLUNG DER ERFINDUNG
-
In
der Praxis kann ein GGSN mehrere P-CSCF für die Sitzungen, an denen UE,
die mit dem GGSN verbunden sind, beteiligt sind, unterstützen und
wird dies wahrscheinlich tun. Da PCF ortsgleich mit jeweiligen P-CSCF
angeordnet sind, muss der GGSN dazu im Stande sein, mit mehreren
PCF-Knoten zu arbeiten.
Unter Anwendung der COPS-PR-Architektur ist der GGSN der PEP-Knoten
und die PCF ist der PDP-Knoten. Die COPS-Architektur bedingt jedoch,
dass der PEP-Knoten mit nur einem einzigen PCP-Knoten für jeden
Client-Typ arbeitet. Dieses Problem gilt auch für andere Netzarchitekturen,
die mehrere PDP-Knoten zum Kommunizieren von Entscheidungen an einen
einzigen gemeinsamen PEP-Knoten erfordern.
-
Dieses
Problem wird durch die Lehre der unabhängigen Ansprüche gelöst. Weitere
bevorzugte Ausführungsformen
sind in den abhängigen
Ansprüchen
beschrieben.
-
Gemäß einem
Gesichtspunkt der Erfindung wird ein Verfahren zum Benachrichtigen
eines ersten Richtliniendurchsetzungspunktknotens über Richtlinien
und/oder Richtlinienentscheidungen, die an mehreren zweiten Richtlinienentscheidungspunktknoten
getroffen wurden, wobei der erste und die zweiten Knoten so angeordnet
sind, dass sie über
ein IP-Netz unter
Anwendung des COPS-Protokolls (COPS = Commmon Open Policy Service,
gemeinsamer offener Richtliniendienst) miteinander kommunizieren,
bereitgestellt, wobei das Verfahren Folgendes umfasst:
Aufbauen
einer einzigen COPS-Verbindung zwischen dem ersten Knoten und einem
dritten Koordinationsnetzknoten, der ebenfalls mit dem IP-Netz verbunden
ist;
Aufbauen einer COPS-Verbindung zwischen dem dritten Netzknoten
und jedem der zweiten Netzknoten;
Senden von Entscheidungen
von den zweiten Netzknoten über
die jeweiligen COPS-Verbindungen an den dritten Netzknoten, Aufzeichnen
der Quellen der Entscheidungen am dritten Netzknoten und Weiterleiten
der Entscheidungen über
die COPS-Verbindung an den ersten Netzknoten und
Senden von
Antworten auf Entscheidungen von dem ersten Netzknoten über die
COPS-Verbindung an den dritten Netzknoten und Identifizieren der
zweiten Quellknoten der Entscheidungen am dritten Netzknoten auf
Basis der aufgezeichneten Quellen und Weiterleiten der Antworten über die
jeweiligen COPS-Verbindungen an die jeweiligen zweiten Knoten.
-
Beispiele
der vorliegenden Erfindung ermöglichen,
dass Entscheidungen von mehreren PDP-Knoten an einen einzigen PEP
kommuniziert werden, ohne dass ein Konflikt am PEP resultiert. Antworten
können
ebenfalls von dem PEP an die korrekten PDP gesendet werden, d. h.
an die PDP, von denen die entsprechenden Entscheidungen ausgingen.
-
Vorzugsweise
ist der erste Richtliniendurchsetzungspunktknoten ein GGSN eines
Datennetzes in einem Mobiltelekommunikationsnetz, z. B. eines 3GPP-Netzes,
und die zweiten Richtlinienentscheidungspunktknoten sind P-CSCF-Knoten
eines IP-Multimedia-Kernnetzuntersystems (IMS), wobei die P-CSCF-Knoten
eine Richtliniensteuerfunktion für
den GGSN ausführen.
-
Gemäß einem
weiteren Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren
zum Ermöglichen,
dass ein erster Richtliniendurchsetzungspunktknoten über Richtlinien
und/oder Richtlinienentscheidungen, die an mehreren zweiten Richtlinienentscheidungspunktknoten
getroffen wurden, benachrichtigt wird, wobei der erste und die zweiten Knoten
so angeordnet sind, dass sie über
ein IP-Netz unter Anwendung des COPS-Protokolls (COPS = Commmon
Open Policy Service, gemeinsamer offener Richtliniendienst) miteinander
kommunizieren, bereitgestellt, wobei das Verfahren an einem dritten Netzknoten,
der mit dem IP-Netz verbunden ist, Folgendes umfasst:
Aufbauen
einer einzigen COPS-Verbindung zu dem ersten Knoten;
Aufbauen
einer COPS-Verbindung mit jedem der zweiten Netzknoten;
Empfangen
von Entscheidungen von den zweiten Netzknoten über die jeweiligen COPS-Verbindungen, Aufzeichnen
der Quellen der Entscheidungen und Weiterleiten der Entscheidungen über die
COPS-Verbindung an den ersten Netzknoten und
Empfangen von
Antworten auf Entscheidungen von dem ersten Netzknoten über die
COPS-Verbindung, Identifizieren der zweiten Quellknoten der Entscheidungen
auf Basis der aufgezeichneten Quellen und Weiterleiten der Antworten über jeweilige
COPS-Verbindungen an die jeweiligen zweiten Knoten.
-
Gemäß einem
weiteren Gesichtspunkt der vorliegenden Erfindung wird eine Vorrichtung
zum Ermöglichen,
dass ein erster Richtliniendurchsetzungspunktknoten über Richtlinien
und/oder Richtlinienentscheidungen, die an mehreren zweiten Richtlinienentscheidungspunktknoten
getroffen wurden, benachrichtigt wird, wobei der erste und die zweiten Knoten
so angeordnet sind, dass sie über
ein IP-Netz unter Anwendung des COPS-Protokolls (COPS = Commmon
Open Policy Service, gemeinsamer offener Richtliniendienst) miteinander
kommunizieren, bereitgestellt, wobei die Vorrichtung Folgendes umfasst:
Eingabe-/Ausgabemittel,
die mit dem IP-Netz verbunden sind;
ein erstes Prozessormittel,
das mit den Eingabe-/Ausgabemitteln verbunden und so angeordnet ist,
dass es eine einzige COPS-Verbindung zu dem ersten Knoten aufbaut;
ein
zweites Prozessormittel, das mit den Eingabe-/Ausgabemitteln verbunden
und so angeordnet ist, dass es eine COPS-Verbindung mit jedem der zweiten Netzknoten
aufbaut;
ein drittes Prozessormittel, das mit den Eingabe-/Ausgabemitteln
verbunden und so angeordnet ist, dass es Entscheidungen von den
zweiten Netzknoten über
die jeweiligen COPS-Verbindungen empfängt, die
Quellen der Entscheidungen aufzeichnet und die Entscheidungen über die
COPS-Verbindung an den ersten Netzknoten weiterleitet, und
ein
viertes Prozessormittel, das mit den Eingabe-/Ausgabemitteln verbunden
und so angeordnet ist, dass es Antworten auf Entscheidungen von
dem ersten Netzknoten über
die COPS-Verbindung
empfängt,
die zweiten Quellknoten der Entscheidungen am auf Basis der aufgezeichneten
Quellen identifiziert und die Antworten über jeweilige COPS-Verbindungen
an die jeweiligen zweiten Knoten weiterleitet.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 stellt
schematisch ein Kommunikationsnetz dar, das eine Datenverbindung
zwischen zwei UE bereitstellt;
-
2 stellt
schematisch das COPS-RSVP-Modell dar;
-
3 stellt
schematisch das COPS-PR-Modell dar;
-
4 stellt
die 3GPP-Architektur für QoS-Verwaltungsfunktionen
dar;
-
5 stellt
schematisch eine Architektur gemäß einer
ersten Ausführungsform
der Erfindung zum Ermöglichen,
dass ein einziger GGSN mit mehreren Richtliniensteuerfunktionen
an jeweiligen P-CSCF kommuniziert, dar;
-
6 zeigt
Signalisierung in der Architektur von 5 dar, die
mit dem Öffnen
von COPS-Verbindungen in Zusammenhang steht;
-
7 zeigt
Entscheidungs- und Antwortsignalisierung über die COPS-Verbindungen,
die mit der Signalisierung von 6 aufgebaut
wurden;
-
8 stellt
schematisch eine Architektur gemäß einem
alternativen Beispiel zum Ermöglichen, dass
ein einziger GGSN mit mehreren Richtliniensteuerfunktionen an jeweiligen
P-CSCF kommuniziert, dar;
-
9 zeigt
Signalisierung in der Architektur von 8 dar, die
mit dem Öffnen
von COPS-Verbindungen in Zusammenhang steht;
-
10 zeigt
Entscheidungs- und Antwortsignalisierung über die COPS-Verbindungen,
die mit der Signalisierung von 9 aufgebaut
wurden.
-
AUSFÜHRLICHE BESCHREIBUNG EINER
BEVORZUGTEN AUSFÜHRUNGSFORM
-
Wie
oben erläutert
wurde, wird die Unterstützung
von IMS-Fähigkeiten
in künftigen
Telekommunikationsnetzen die Go-Schnittstelle
(zwischen dem Gateway-GGSN und der PCF der P-CSCF, wie in 4 gezeigt)
erfordern, um bestimmte Abrechnungsmodelle zu unterstützen. Die
grundlegende Architekturinkompatibilität zwischen der aktuellen 3GPP-Architektur
für die
Go-Schnittstelle und der IETF-COPS-Architektur muss überwunden
werden. Es wird nun eine Ausführungsform
beschrieben, die ermöglicht,
dies zu erreichen.
-
Ausführungsform
1
-
Die
erste Ausführungsform
besteht darin, einen PCF-C-Knoten (PCF-C = Policy Control Function Co-ordinator,
Richtliniensteuerfunktionskoordinator) 15 in die 3GPP-Architektur
einzuführen.
Dieser Knoten erscheint dem GGSN 16 gegenüber als
der PDP-Knoten für
die SBLP-Client-Typ (SBLP = Service Based Local Policy, dienstbasierte
lokale Richtlinie), wodurch das COPS-Erfordernis erfüllt wird, dass
ein PEP für einen
gegebenen Client-Typ nur in Richtung eines einzigen PDP arbeiten
kann. Der PCF-C koordiniert die COPS-PR-Entscheidungen/Antworten
für einen
GGSN zu/von mehreren PCF-Elementen,
die ortsgleich mit jeweiligen P-CSCF-Knoten 18 angeordnet
sind. Dies ist in 5 dargestellt.
-
Jeder
GGSN 16 baut eine COPS-Verbindung zu einem PCF-C 15 für den SBLP-Client-Typ auf,
gemäß der COPS-PR-Spezifikation.
Der PCF-C 15 öffnet
dann eine Verbindung zu jeder PCF 17, in deren Richtung
der GGSN 16 arbeiten kann (dies könnte alle P-CSCF/PCE-Knoten
in dem Netz beinhalten), wie in 6 gezeigt.
Die PCF-Knoten 17 verwenden dann diese Verbindung zum Einführen von Richtlinien
in dem GGSN 16.
-
Die
PCF 17 erstellen SBLP-Entscheidungen für den GGSN 16 und
dies werden über
COPS-PR an den PCF-C 15 übertragen, der den PCF 17 als
der GGSN 16 erscheint. Wenn der PCF-C 15 von einer PCF 17 eine
SBLP-Entscheidung empfängt,
zeichnet der PCF-C 15 Informationen über die Quelle der Entscheidung
auf. Ein „Kennungsobjekt" schließt einen einzigartigen
Wert ein, der einen eingeführten
Zustand identifiziert. Diese Identifikation wird von den meisten
COPS-Arbeitsgängen
verwendet. Die Kennung ist einzigartig im Vergleich zu anderen Client-Kennungen
vom selben PEP (d. h. anderen COPS-TCP-Verbindungen) für einen
bestimmten Client-Typ. Der PCF-C 15 soll eine lokale einzigartige Kennung
für jede
einzigartige Kennung erzeugen, die von den mehreren PCF empfangen
wurde. Das Kennungsobjekt wird mit der einzigartigen Kennung aktualisiert,
die in dem PCF-C 15 erzeugt wurde. Die TCP- und IP-Paketköpfe werden
gemäß den normalen
Regeln für
die TCP-Verbindung gesetzt (d. h. modifiziert, einschließlich des Änderns der
Quell- und Ziel-IP-Adresse) und das modifizierte COPS-Paket wird
die offene TCP-Ver bindung herunter an den GGSN 16 übertragen.
-
Wenn
der PCF-C 15 eine Antwort von dem GGSN 16 empfängt, wird
das COPS-Paket extrahiert und ein umgekehrtes Nachschlagen der Anfrage,
die dazu verwendet wird, zu bestimmen, von welcher PCF 17 die
Anfrage ausging, d. h. eine Abbildung wird zwischen dem COPS-Kennungsobjekt
(von dem PCF-C 15 zugeteilt) und der von der PCF 17 zugeführten Kennung
vorgenommen. Das COPS-Paket wird modifiziert, um das vom PCF-C definierte COPS-Kennungsobjekt
durch die von der PCF zugeführte
Kennung zu ersetzen. Der PCF-C 15 passt auch die TCP- und
IP-Paketköpfe
an und leitet die Antwort über
die offene TCP-Verbindung an die Ausgangs-PCF 17 weiter.
-
Alternative Beispiele
-
Alternative
Beispiele, die nicht in den folgenden Ansprüchen beansprucht werden, werden
im folgenden Abschnitt beschrieben.
-
Ein
alternatives Beispiel, das nicht in den folgenden Ansprüchen beansprucht
wird, besteht darin, einen Satz „logischer GGSN-Knoten" in dem einen physikalischen
GGSN-Knoten zu erzeugen.
Jeder logische Knoten kann selbstverständlich in Richtung einer separaten
P-CSCF/PCF arbeiten, wie unten in 8 gezeigt.
Hier besteht ein einziger GGSN 19 aus einer Reihe logischer
oder virtueller GGSN-Knoten 20.
Jeder logische Knoten kann mit einer separaten P-CSCF/PCF 21 kommunizieren,
die ortsgleich mit einem P-CSCF-Knoten 22 angeordnet
ist. Die virtuellen GGSN-Verbindungen könnten entweder durch Zuteilen
eines Satzes von IP-Adressen oder durch Verwendung unterschiedlicher
An schlösse
getrennt werden.
-
Wenn
ein Knoten initialisiert wird, würde
normalerweise die Verbindung zu dem einen PDP aufgebaut. In diesem
Fall, wenn der GGSN 19 initialisiert wird, würde jeder
virtuelle GGSN oder v-GGSN 20 die Verbindung zu der damit
verbundenen PCF 21 aufbauen, wie in 9 gezeigt.
Die Implementierung kann entweder nur den v-GGSN 20 erzeugen,
wenn die Benutzer tatsächlich
angeschlossen sind und die PCF, in deren Richtung sie arbeiten,
identifiziert sind, oder sie können
alle von vornherein erzeugt werden und die Benutzer können den
vorher existierenden v-GGSN 20 zugeteilt werden, wenn sie
angeschlossen werden.
-
Wenn
ein Benutzer durch den GGSN 19 mit dem IMS-APN eine Verbindung
herstellt, wird diesem Benutzer eine IP-Adresse zugeteilt und die P-CSCF/PCF
für diesen
Benutzer wird identifiziert. Zu diesem Zeitpunkt wird die IP-Adresse
für den
Benutzer dem virtuellen GGSN 20 zugeteilt, der mit dieser
PCF 21 in Zusammenhang steht. Solange diese IP-Adresse zugeteilt
bleibt, ist der virtuelle GGSN 20 dazu im Stande, SBLP-Richtlinien
von dieser PCF 21 für
die IP-Adresse dieses
Benutzers zu empfangen. Wenn der Benutzer die Verbindung zu dem
APN abbricht (d. h. der PDP-Kontext wird entfernt), soll der virtuelle
GGSN 20 diese IP-Adresse von seiner Liste von IP-Adressen
entfernen, die als unter der Kontrolle der PCF stehend identifiziert
wurden. Der virtuelle GGSN 20 soll jegliche Entscheidungen
abweisen, die er für
eine IP-Adresse empfängt,
die nicht diesem virtuellen GGSN 20 gehört.
-
Der
v-GGSN 20 soll dann Entscheidungen empfangen und Berichte über die
offene COPS-Schnittstelle gemäß einem normalen COPS-Clienten
senden, wie in 10 gezeigt. Mit dem logischen
v-GGSN-Knoten 20 in dem GGSN 19 gibt es keine Überlappung
bei der Richtliniensteuerung von mehreren P-CSCF/PCF-Vorrichtungen in Richtung eines
einzigen GGSN für
den SBLP-Client-Typ.
-
Das
hier betrachtete alternative Beispiel weist insofern einen potentiellen
Vorteil auf, dass es keine Normierung erfordert. Folglich, wenn
die 3GPP-Architektur nicht spezifisch modifiziert wird, um einen
PCF-C-Knoten einzuführen
(Ausführungsform
1), wird die Implementierung eines „virtuellen" GGSN das umrissene
Problem überwinden.
-
Ein
alternatives Beispiel bezieht sich auf ein Verfahren zum Benachrichtigen
eines ersten Richtliniendurchsetzungspunktknotens über Richtlinien und/oder
Richtlinienentscheidungen, die an mehreren zweiten Richtlinienentscheidungspunktknoten getroffen
wurden. Der erste und die zweiten Knoten sind so angeordnet, dass
sie über
ein IP-Netz unter Anwendung des COPS-Protokolls (COPS = Commmon
Open Policy Service, gemeinsamer offener Richtliniendienst) miteinander
kommunizieren. Das Verfahren umfasst die folgenden Schritte:
- – Aufbauen
eines virtuellen Richtliniendurchsetzungspunkts für jeden
zweiten Knoten an dem ersten Knoten;
- – Aufbauen
einer COPS-Verbindung zwischen jedem der virtuellen Richtliniendurchsetzungspunkte
und dem zweiten Knoten und
- – Senden
von Entscheidungen und Entscheidungsantworten zwischen den virtuellen
Richtliniendurchsetzungspunkten und dem zweiten Knoten über die
jeweiligen COPS-Verbindungen.
-
In
dem alternativen Beispiel ist der erste Richtliniendurchsetzungspunktknoten
vorzugsweise ein GGSN eines Datennetzes in einem Mobiltelekommunikationsnetz
und die zweiten Richtlinienentscheidungspunktknoten sind P-CSCF-Knoten
eines IP-Multimedia-Kernnetzuntersystems (IMS), wobei die P-CSCF-Knoten
eine Richtliniensteuerfunktion für
den GGSN ausführen.
-
Ein
alternatives Beispiel bezieht sich auf ein Verfahren zum Betreiben
eines Gateway-Unterstützungsknotens
eines Paketvermittlungsnetzes in einem Mobiltelekommunikationsnetz,
wobei dieser Knoten über
ein IP-Netz mit mehreren Richtlinienentscheidungspunkten verbunden
ist. Das Verfahren umfasst den Schritt des Ausführens mehrerer Funktionen eines
virtuellen Gateway-Unterstützungsknotens,
die auf Grundlage der Identitäten
von Benutzern des Paketvermittlungsnetzes auf Richtlinienentscheidungspunkte
abgebildet sind.
-
Ein
alternatives Beispiel bezieht sich auf einen Gateway-Unterstützungsknoten
zur Verwendung in einem Paketvermittlungsnetz eines Mobiltelekommunikationsnetzes.
Der Knoten umfasst Folgendes:
- – ein erstes
Eingabe-/Ausgabemittel zum Verbinden mit dem Paketvermittlungsnetz;
- – ein
zweites Eingabe-/Ausgabemittel zum Verbinden mit einem IP-Netz,
mit dem mehrere Richtlinienentscheidungspunkte verbunden sein können; und
- – einen
oder mehrere Prozessoren, die mit dem ersten und dem zweiten Eingabe-/Ausgabemittel zum
Ausführen
mehrerer Funktionen eines virtuellen Gateway-Unterstützungsknotens,
die auf Grundlage der Identitäten
von Benutzern des Paketvermittlungsnetzes auf Richtlinienentscheidungspunkte
abgebildet sind, verbunden sind.
-
Zum
Beispiel, während
die Erfindung unter Bezugnahme auf das aktuelle COPS-Protokoll dargestellt
wurde, kann die Erfindung auch auf aktuelle und künftige Versionen
dieses Protokolls angewendet werden.
-
Ein
Fachmann wird zu schätzen
wissen, dass verschiedene Abänderungen
an den oben beschriebenen Ausführungsformen
vorgenommen werden können,
ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen, der
nur durch die folgenden Ansprüche
definiert ist.