-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft eine Richtliniensteuerung in einem
Kommunikationsnetz, und insbesondere, jedoch nicht notwendigerweise,
eine Richtliniensteuerung an einem GGSN eines Mobiltelekommunikationsnetzes.
-
Hintergrund
der Erfindung
-
Das
als 3GPP bekannte Europäische
Telekommunikationsinstitut ist derzeit dabei, ein neues Set von
Protokollen für
das als universelles mobiles Telekommunikationssystem (Universal
Mobile Telecommunications System – UMTS) bekannte Mobiltelekommunikationssystem
einzuführen.
Die Architektur eines UMTS-Netzes
basiert auf einem UMTS-Kernnetz und einem terrestrischen Funkzugangs-(Terrestrial Radio
Access Network)-UMTS-Netz (UTRAN). Für die Übertragung von Daten implementiert
UMTS einen paketvermittelten Dienst, wie beispielsweise den paketorientierten GPRS-Dienst
(General Packet Radio Service) oder dergleichen. Um Daten zu senden
und zu empfangen, baut ein mobiles Endgerät oder eine Benutzereinrichtung
(User Equipment – UE)
eine „Sitzung" mit einem Knoten
im Netz auf, der als ein Gateway-GPRS-Supportknoten (GGSN) bekannt
ist. Der GGSN sorgt für
eine Schnittstelle vom UE zur Außenwelt.
-
Eine
alternative Architektur ist in der PCT-Patentanmeldung WO 01/89234
offenbart, die ein System einführt,
in dem ein Funknetzserver als ein Richtlinienserver funktioniert,
der mit einem als Richtlinienentscheidungspunkt funktionierenden Bandbreiten-Broker
zusammenarbeitet. Flankenrouter agieren als Richtliniendurchsetzungspunkt
für deren
Domäne.
-
Innerhalb
des Kernnetzes setzt der GGSN Richtlinien (z.B. Steueroptionen)
des Netzbetreibers durch. Ein Betreiber kann z.B. Richtlinien definieren, in
denen dargelegt ist, welche Teilnehmer auf welche Datendienste Zugriff
haben können
(d.h. das Blockieren und Freigeben von Diensten), und die den Teilnehmern
Prioritäten
zuordnen, z.B. zu welchen Zeitpunkten Teilnehmer sich verbinden
können.
-
Um
die Bereitstellung von Multimedia-Diensten zu vereinfachen, hat
das 3GPP ein sogenanntes IP-Multimedia-Kernnetz-Subsystem (IP Multimedia Core
Network Subsystem – IMS)
entwickelt. Das IMS kommuniziert mit dem GPRS-Netz und enthält sämtliche
Elemente, die für
die Bereitstellung von IP-basierten Multimedia-Diensten verwendet werden. Für einen
Anruf zwischen Mobilstationen sitzt das IMS zwischen zwei GPRS-Netzen
(wenn man davon ausgeht, dass die Mobilstationen unterschiedlichen
Netzen angehören).
Bestimmte Knoten des IMS können dem
Betreiber eines ersten der GPRS-Netze gehören, während die restlichen Knoten
dem Betreiber des zweiten Netzes gehören (einige IMS-Knoten können einem
Dritten gehören).
Das Basisprotokoll für
Multimedia-Dienste ist das IETF-SIP-Protokoll (Session Initiation
Protocol). Das SIP erlaubt es einem rufenden Teilnehmer, eine Sitzung
mit dem gerufenen Teilnehmer herzustellen (über welche Daten ausgetauscht
werden können),
auch wenn der rufende Teilnehmer die aktuelle IP-Adresse des gerufenen Teilnehmer vor
der Rufinitiierung nicht kennt. Das SIP sorgt für eine andere Funktionalität, einschließlich der
Verhandlung von Sitzungsparametern (z.B. Dienstgüte und Codecs).
-
Das
IMS umfasst eine S-CSCF-Funktion (Serving Call State Control Function),
die die Sitzungssteuerungsdienste für das UE ausführt und
einen Sitzungszustand aufrechterhält, der vom Netzbetreiber für die Unterstützung von
Diensten benötigt wird.
Die Hauptfunktion, die von der S-CSCF während einer Sitzung durchgeführt wird,
ist das Routing von eingehenden und ausgehenden Verbindungsaufbauanforderungen.
Das IMS kann auch ein Proxy-CSCF (P-CSCF) umfassen. Die Hauptfunktion, die
von der P-CSCF durchgeführt
wird, ist das Routen von SIP-Nachrichten zwischen dem UE und dem Heimatnetz.
Die P-CSCF kommuniziert mit dem GGSN.
-
Die 1 zeigt
schematisch ein typisches Szenario, bei dem die Benutzereinrichtung
(UE) 1 ein Teilnehmer eines zellularen Telefonnetzes 2 ist.
Der das UE 1 benutzende Teilnehmer wird in dem Netz 2 durch
eine eindeutige Teilnehmerkennung identifiziert, und das Netz wird
als das „Heimat"-Netz des Teilnehmers
bezeichnet. In dem in der 1 dargestellten
Szenario ist das UE 1 bei einem „fremden" bzw. besuchten Netz 3 registriert.
Das besuchte Netz umfasst ein GPRS-(General Packet Radio Service)-Netz 4 (sowie
ein leitungsvermitteltes Netz, das in der 1 nicht
dargestellt ist). Innerhalb des Netzes 4 sind zwei für das UE1
relevante Knoten zu erkennen. Hierbei handelt es sich um den SGSN
(Serving GPRS Support Node) 5 und den GGSN (Gateway GPRS
Support Node) 6. Die Rolle des SGSN 5 besteht
in der Verwaltung von Teilnahmedaten (Kennungen und Adressen) sowie
in der Verfolgung des Aufenthaltsortes des UE innerhalb des Netzes.
Die Rolle des GGSN 6 besteht in der Verwaltung von Teilnahmeinformationen
und zugeordneten IP-Adressen sowie in der Verfolgung des SGSN, an
den das UE 1 angeschlossen ist. Der GGSN 6 ist
mit einem IP-Netz verknüpft.
-
Wenn
das UE 1 angeschaltet wird, „schließt" es sich normalerweise selbst an den
GGSN an, und es wird ein Paketdatenprotokollkontext zwischen dem
UE 1 und dem GGSN 6 etabliert. Dieser Kontext stellt
ein „Rohr" für den Transport
von Daten vom UE 1 zu dem GGSN 6 zur Verfügung. Dieser
Vorgang involviert die Zuordnung einer IP-Adresse zu dem UE 1.
Normalerweise ist der Routing-Präfix-Teil
der Adresse ein dem GGSN 6 zugeordnetes Routing-Präfix.
-
In
der 1 ist ein zweites UE 7 dargestellt, welches
bei einem Fremdnetz 8 registriert ist und ein Netz 9 als
dessen Heimatnetz hat. Knoten und (Sub-) Netze innerhalb des Fremdnetzes 8 sind
mit den gleichen Bezugszeichen gekennzeichnet, wie diejenigen, die
im Netz 3 verwendet werden. Das IP-Multimedia-Kernnetz-Subsystem (IMS) enthält sämtliche der
Elemente, die für
die Bereitstellung von IP-basierten
Multimedia-Diensten erforderlich sind, einschließlich des Aufbaus von Sitzungen
zwischen den beiden UEs 1, 7. Die vom IMS bereitgestellte
Funktionalität
ist in 3GPP TS 23.228 dargelegt. Das IMS besteht aus einem Set von
Knoten, die mit einem IP-Backbone-Netz verknüpft sind. In dem IMS nach 1 gezeigt
sind ein P-CSCF-(Proxy Call State Control-Function)-Knoten 10 in
jedem der besuchten Netze 3, 8 sowie ein S-CSCF-(Serving
Call State Control Function)-Knoten 11 in jedem der Heimatnetze 2, 9.
Für die
Etablierung einer Sitzung zwischen den beiden UEs 1, 7 nach 1 wird
eine geeignete SIP-Zeichengabe von der P-CSCF, die sich in dem besuchten
Netz befindet, mit dem der Ursprungsteilnehmer verbunden ist, an
die S-CSCF gesendet, die sich im Heimatnetz des Ursprungs-UE befindet.
Diese S-CSCF kontaktiert dann die S-CSCF in dem Heimatnetz des gerufenen
UE, welcher wiederum die P-CSCF in dem besuchten Netz, mit dem das
gerufene UE verbunden ist, kontaktiert. Eine Datensitzung kann dann
zwischen den beiden GGSNs 6, mit denen die UEs 1, 7 verbunden
sind, etabliert werden. Ist ein UE bei dessen Heimatnetz registriert,
so dient die S-CSCF des Heimatnetzes auch als P-CSCF für das UE.
-
Die
Internet Engineering Task Force (IETF) hat ein als COPS (Common
Open Policy Service) bekanntes Protokoll festgelegt, bei dem es
sich um ein einfaches Frage- und
Antwortprotokoll handelt, das für
den Austausch von Richtlinieninformationen (die sich auf jedes Merkmal,
jeden Dienst etc. beziehen können,
auf das oder den eine Steuerung ausgeübt werden soll) zwischen einem
Richtlinienserver (Richtlinienentscheidungspunkt oder PDP) und dessen
Clients (Richtliniendurchsetzungspunkte oder PEPs) verwendet werden
kann. Das COPS ist ein Frage-/Antwortprotokoll, welches zwei gebräuchliche Modelle
für die
Richtliniensteuerung unterstützt: Outsourcing
und Konfiguration.
-
Im
Outsourcing-Szenario delegiert der PEP die Verantwortung an einen
externen Richtlinienserver (PDP), um in dessen Namen Entscheidungen
zu treffen. Beispielsweise muss bei der Verwendung des COPS für „Resource
reSerVation Protocol" (COPS-RSVP)
beim Ankommen einer RSVP-Reservierungsnachricht der PEP entscheiden,
ob die Anforderung zuzulassen oder abzuweisen ist. Er kann diese
Entscheidung nach außerhalb
vergeben (Outsourcing), indem er eine spezielle Anfrage an seinen
PDP sendet und auf dessen Entscheidung wartet, bevor er die ausstehende
Reservierung zulässt.
Dies ist in der 2 dargestellt.
-
Das
COPS-Konfigurationsmodell betrifft die Arten von Ereignissen am
PEP, die eine sofortige Richtlinienentscheidung erfordern. Diese
Variation ist als „COPS
for Provisioning" (COPS-PR)
bekannt. COPS-PR ist konzipiert als ein Mittel zum Installieren von
Richtlinien vom Entscheidungsknoten in den Durchsetzungsknoten, in
dem die Richtlinie durchgeführt
wird. Mit diesem Protokoll werden jederzeit Entscheidungen asynchron
vom Entscheidungsknoten übertragen,
und der Durchsetzungsknoten antwortet mit einer Angabe, ob die Richtlinie
installiert wurde oder nicht. Dies ist in der 3 dargestellt.
Der PDP kann den PEP proaktiv so konfigurieren, dass dieser in festgelegter
Weise auf externe Ereignisse (z.B. Benutzereingabe), PEP-Ereignisse
und jegliche Kombinationen hiervon (N:M-Korrelation) reagiert. Die Konfiguration
oder die Bereitstellung kann im Ganzen (z.B. ganze Router-QoS-Konfiguration)
oder in Teilen (z.B. Aktualisieren eines DiffServ-Markierungsfilters) durchgeführt werden.
-
Das
COPS-PR ist ein Protokoll für
allgemeine Zwecke und kann zum Installieren von Richtlinien für beliebige
Funktionen verwendet werden. Es verwendet das Konzept einer Richtlinieninformationsbasis
(Policy Information Base – PIB).
Eine PIB definiert die Richtliniendaten. Es kann ein oder mehrere
PIBs für
einen gegebenen Richtlinienbereich geben, und unterschiedliche Richtlinienbereiche
können
unterschiedliche Sets von PIBs haben. Dies erlaubt die Unterstützung für ein Modell,
das mehrere PDPs zum Steuern von nicht-überlappenden Richtlinienbereichen
auf einem einzigen PEP enthält.
-
Ein „Client-Typ" (Wert) wird zur
Identifizierung der Funktion verwendet, die von der Richtliniensteuerung
verwaltet wird. Ein einziger Client-Typ für einen gegebenen Richtlinienbereich
(z.B. DiffServ) wird für
sämtliche
PIBs verwendet, die in diesem Bereich existieren. Der Client behandelt
sämtliche
der COPS-PR-Client-Typen, die er unterstützt, als nicht-überlappende
und unabhängige
Namensräume,
wo Instanzen gemeinsam genutzt werden. Für jeden Client-Typ, den der
PEP unterstützt,
kann der PEP nur zu einem einzigen PDP hin arbeiten.
-
Das
3GPP hat einen Mechanismus entwickelt, der es der P-CSCF erlaubt,
eine Funktion innerhalb des GGSN zu steuern. Die Architektur für die vom
3GPP definierte QoS-Verwaltung (Empfehlung 23.207) ist in der 4 dargestellt.
Wie in dieser Figur gezeigt, kommuniziert der GGSN (Gateway-Knoten)
mit einer Richtliniensteuerfunktion (PCF), die sich bei der P-CSCF
befinden kann. Die Schnittstelle zwischen dem GGSN und der PCF-Funktion
innerhalb der P-CSCF ist als die Go-Schnittstelle festgelegt. Die
Go-Schnittstelle basiert auf dem COPS-Protokoll. Es sei angemerkt, dass, obwohl
das PCF-Element extern gegenüber
der P-CSCF angeordnet sein kann, der 3GPP-Standard dessen Anordnung
bei der P-CSCF ermöglicht,
so dass die Protokolle deshalb den Betrieb in dieser Konfiguration
unterstützen
müssen.
-
Zusammenfassung
der Erfindung
-
In
der Praxis kann und wird wahrscheinlich ein GGSN mehrere P-CSCFs
für die
Sitzungen unterstützen,
in denen mit dem GGSN verbundene UEs involviert sind. Da die PCFs
bei den entsprechenden P-CSCFs angeordnet sind, muss der GGSN in
der Lage sein, mit mehreren PCF-Knoten zu arbeiten. Bei Anwendung
der COPS-Architektur
ist der GGSN der PEP-Knoten, und der PCF ist der PDP-Knoten. Die
COPS-Architektur erfordert jedoch, dass der PEP-Knoten lediglich
mit nur einem einzigen PCP-Knoten für jeden Client-Typ arbeitet.
Dieses Problem betrifft auch andere Netzarchitekturen, die eine
Vielzahl von PDP-Knoten zum Übermitteln
von Entscheidungen an einen einzigen gemeinsamen PEP-Knoten erfordern.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird ein Verfahren bereitgestellt
zum Benachrichtigen eines ersten Richtliniendurchsetzungspunktknotens
(policy enforcement point node) über Richtlinien
(policies) und/oder getroffene Richtlinienentscheidungen an einer
Vielzahl von zweiten Richtlinienentscheidungspunktknoten (policy
decision point nodes), wobei der erste und der zweite Knoten miteinander über ein
IP-Netz unter Verwendung des COPS-(Common Open Policy Service)-Protokolls
kommunizieren, wobei das Verfahren umfasst:
Am ersten Knoten
Etablieren eines virtuellen Richtliniendurchsetzungspunktes für jeden
zweiten Knoten;
Etablieren einer COPS-Verbindung zwischen jedem der
virtuellen Richtliniendurchsetzungspunkte und dem zweiten Knoten;
und
Senden von Entscheidungen und Entscheidungsantworten zwischen
den virtuellen Richtliniendurchsetzungspunkten und den zweiten Knoten über die jeweiligen
COPS-Verbindungen.
-
Ausführungsformen
der vorliegenden Erfindung erlauben die Übermittlung von Entscheidungen von
mehreren PDP-Knoten an einen einzigen PEP, ohne dass ein Konflikt
am PEP auftritt. Antworten können
auch vom PEP an die korrekten PDPs gesendet werden, d.h. an die
PDPs, an welchen die entsprechenden Entscheidungen hervorgerufen
wurden.
-
Der
erste Richtliniendurchsetzungspunktknoten ist vorzugsweise ein GGSN
eines Datennetzes in einem Mobiltelekommunikationsnetz, z.B. eines
3GPP-Netzes, und die zweiten Richtlinienentscheidungspunktknoten
sind P-CSCF-(Proxy-Call State Control Function)-Knoten eines IP-Multimedia-Kernnetz-Subsystems
(IMS), wobei die P-CSCF-Knoten jeweils eine Richtliniensteuerfunktion
(Policy Control function) für
den GGSN implementieren.
-
Gemäß einem
Aspekt der Erfindung wird ein Verfahren zum Betreiben eines Gateway-Supportknotens
eines paketvermittelten Netzes eines Mobiltelekommunikationsnetzes
bereitgestellt, wobei der Knoten mit einer Vielzahl von Richtlinienentscheidungspunkten
(policy decision points) über
ein IP-Netz verknüpft
ist, wobei das Verfahren umfasst:
Implementieren einer Vielzahl
von virtuellen Gateway-Supportknotenfunktionen, die auf Richtlinienentscheidungspunkten
abgebildet sind;
Etablieren einer COPS-Verbindung zwischen
jeder der virtuellen Gateway-Supportknotenfunktionen
und den entsprechenden Richtlinienentscheidungspunkten; und
Austauschen
von Entscheidungen und Entscheidungsantworten mit den Richtlinienentscheidungspunkten über die
jeweilige COPS-Verbindung.
-
Eine
weitere Implementierung, die zur Auswahl steht, ist eine Vorrichtung,
die ein Benachrichtigen eines ersten Richtliniendurchsetzungspunktknotens
(policy enforcement point node) über
Richtlinien (policies) und/oder getroffene Richtlinienentscheidungen
an einer Vielzahl von zweiten Richtlinienentscheidungspunktknoten
(policy decision point nodes) erlaubt, wobei der erste und der zweite
Knoten angeordnet sind, um miteinander über ein IP-Netz unter Verwendung
des COPS-(Common Open Policy Service)-Protokolls zu kommunizieren,
wobei die Vorrichtung umfasst:
Eingabe-/Ausgabemittel, die
mit dem IP-Netz verbunden sind;
ein erstes Prozessormittel,
das mit dem Eingabe-/Ausgabemittel verbunden ist und angeordnet
ist, um eine einzige COPS-Verbindung mit dem ersten Knoten zu etablieren;
ein
zweites Prozessormittel, das mit dem Eingabe-/Ausgabemittel verbunden
ist und angeordnet ist, um eine COPS-Verbindung mit jedem der zweiten Netzknoten
zu etablieren;
ein drittes Prozessormittel, das mit dem Eingabe-/Ausgabemittel
verbunden ist und angeordnet ist, Entscheidungen von den zweiten
Netzknoten über die
jeweiligen COPS-Verbindungen zu empfangen, die Entscheidungsquellen
aufzuzeichnen und die Entscheidungen an den ersten Netzknoten über die COPS-Verbindung weiterzuleiten;
und
ein viertes Prozessormittel, das mit dem Eingabe-/Ausgabemittel
verbunden ist und angeordnet ist, Antworten auf Entscheidungen von
dem ersten Netzknoten über
die COPS-Verbindung zu empfangen, die zweiten Quellenknoten der
Entscheidungen aufgrund der aufgezeichneten Quellen zu identifizieren und
die Antworten an die jeweiligen zweiten Knoten über jeweilige COPS-Verbindungen
weiterzuleiten.
-
Gemäß einem
Aspekt der Erfindung wird ein Gateway-Supportknoten zur Verwendung
in einem paketvermittelten Netz eines Mobiltelekommunikationsnetzes
bereitgestellt, wobei der Knoten umfasst:
erste Eingabe-/Ausgabemittel
zum Verbinden mit dem paketvermittelten Netz;
zweite Eingabe-/Ausgabemittel
zum Verbinden mit einem IP-Netz, mit dem eine Vielzahl von Richtlinienentscheidungspunkten
(policy decision points) verbunden sind; und
einen oder mehrere
Prozessoren, die mit den ersten und zweiten Eingabe-/Ausgabemitteln verbunden sind,
um eine Vielzahl von virtuellen Gateway-Supportknotenfunktionen zu implementieren,
um eine COPS-Verbindung zwischen jeder der virtuellen Gateway-Supportknotenfunktionen
und den entsprechenden Richtlinienentscheidungspunkten herzustellen,
und um Entscheidungen und Entscheidungsantworten mit den Richtlinienentscheidungspunkten über die
jeweiligen COPS-Verbindungen auszutauschen.
-
Der
Gateway-Supportknoten ist vorzugsweise ein GPRS-Gateway-Supportknoten
zur Verwendung beim Bereitstellen eines GPRS-paketvermittelten Dienstes.
-
Kurze Beschreibung
der Zeichnungen
-
Die 1 stellt
schematisch ein Kommunikationsnetz dar, das eine Datenverbindung
zwischen zwei UEs bereitstellt.
-
Die 2 stellt
schematisch das COPS-RSVP-Modell dar.
-
Die 3 stellt
schematisch das COPS-PR-Modell dar.
-
Die 4 stellt
die 3GPP-Architektur für QoS-Management-Funktionen
dar.
-
Die 5 stellt
schematisch eine Architektur nach einer ersten Ausführungsform
der Erfindung dar, um einem einzigen GGSN zu erlauben, mit mehreren
Richtliniensteuerfunktionen (Policy Control Functions) an entsprechenden
P-CSCFs zu kommunizieren.
-
Die 6 zeigt
eine Zeichengabe in der Architektur nach 5, verbunden
mit dem Öffnen
von COPS-Verbindungen.
-
Die 7 zeigt
eine Entscheidungs- und Antwortzeichengabe über die COPS-Verbindungen, die
mit der Zeichengabe nach 6 etabliert wurden.
-
Die 8 stellt
schematisch eine Architektur nach einer zweiten Ausführungsform
der Erfindung dar, um einem einzigen GGSN zu erlauben, mit mehreren
Richtliniensteuerfunktionen (Policy Control Functions) an entsprechenden
P-CSCFs zu kommunizieren.
-
Die 9 zeigt
eine Zeichengabe in der Architektur nach 8, verbunden
mit dem Öffnen
von COPS-Verbindungen.
-
Die 10 zeigt
eine Entscheidungs- und Antwortzeichengabe über die COPS-Verbindungen, die
mit der Zeichengabe nach 9 etabliert wurden.
-
Ausführliche
Beschreibung einer bevorzugten Ausführungsform
-
Wie
oben erläutert,
wird die Unterstützung für IMS-Fähigkeiten
in künftigen
Telekommunikationsnetzen die Go-Schnittstelle (zwischen dem Gateway-GGSN
und der PCF des P-CSCF, wie in 4 gezeigt)
erfordern, um bestimmte Abrechnungsmodelle zu unterstützen. Die
grundlegende architektonische Inkompatibilität zwischen der aktuellen 3GPP-Architektur
für die
Go-Schnittstelle und der IETF-COPS-Architektur muss überwunden
werden.
-
Dies
könnte
beispielsweise durch die Einführung
eines Koordinatorknotens für
Richtliniensteuertunktionen 15 (Policy Control Function
Coordinator (PCF-C) node) in die 3GPP-Architektur erreicht werden.
Dieser Knoten tritt gegenüber
dem GGSN 16 als der PDP-Knoten für den dienstebasierten Lokalrichtlinien-(Service-Based
Local Policy – SBLP)-Client-Typ
auf und erfüllt
somit das COPS-Erfordernis, dass für einen gegebenen Client-Typ
ein PEP nur zu einem einzigen PDP hin arbeiten kann. Der PCF-C koordiniert
die COPS-PR-Entscheidungen/-Antworten für einen GGSN an/von mehrere(n)
PCF-Elemente(n) 17, die bei entsprechenden P-CSCF-Knoten 18 mitangeordnet
sind. Dies ist in der 5 dargestellt.
-
Jeder
GGSN 16 etabliert eine COPS-Verbindung zu einem PCF-C 15 für den SBLP-Client-Typ gemäß der COPS-PR-Spezifikation.
Der PCF-C 15 öffnet
dann eine Verbindung zu jeder PCF 17, zu welcher der GGSN 16 hin
arbeiten kann (dies könnte sämtliche
P-CSCF/PCF-Knoten innerhalb des Netzes umfassen), wie in Figur 6
gezeigt. Die PCF-Knoten 17 verwenden diese Verbindung dann
zum Installieren von Richtlinien im GGSN 16.
-
Die
PCFs 17 erzeugen SBLP-Entscheidungen für den GGSN 16, und
diese werden über
das COPS-PR an den PCF-C 15 übertragen, der gegenüber den
PCFs 17 als der GGSN 16 auftritt. Wenn der PCF-C 15 eine
SBLP-Entscheidung von einer PCFs 17 empfängt, zeichnet
der PCF-C 15 Informationen über die Quelle der Entscheidung
auf. Ein „Handle-Objekt" kapselt einen eindeutigen
Wert ein, der einen installierten Zustand identifiziert. Diese Identifikation
wird von den meisten COPS-Operationen
verwendet. Das Handle ist gegenüber
anderen Client-Handles vom selben PEP (d.h. anderen COPS-TCP-Verbindungen)
für einen
bestimmten Client-Typ
einzigartig. Der PCF-C 15 soll ein lokales einzigartiges
Handle für
jedes einzigartige Handle erzeugen, das von den mehreren PCFs empfangen wird.
Das Handle-Objekt wird mit dem einzigartigen im PCF-C 15 erzeugten
Handle aktualisiert. Die TCP- und IP-Header werden gemäß den normalen
Regeln für
die TCP-Verbindung gesetzt (d.h. modifiziert, einschließlich einer Änderung
der Quellen- und Ziel-IP-Adressen),
und das modifizierte COPS-Paket wird abwärts der offenen TCP-Verbindung
zum GGSN 16 übertragen.
-
Wenn
der PCF-C 15 eine Antwort vom GGSN 16 empfängt, wird
das COPS-Paket extrahiert und eine Rückwärtsabfrage der Anforderung
wird zum Bestimmen verwendet, von welcher PCF 17 die Anforderung
hervorgerufen wurde, d.h. es findet eine Abbildung zwischen dem
COPS-Handle-Objekt (das vom PCF-C 15 zugeordnet wird) und
dem von der PCF 17 bereitgestellten Handle statt. Das COPS-Paket
wird modifiziert, um das PCF-C-definierte COPS-Handle-Objekt mit
dem Handle zu ersetzen, dass von der PCF bereitgestellt wurde. Der
PCF-C 15 passt auch die TCP- und IP-Header an und leitet die Antwort über die
offene TCP-Verbindung weiter an die Ursprungs-PCF 17.
-
Mit
der beanspruchten Lösung
wird ein Set „logischer
GGSN-Knoten" innerhalb
des einen physikalischen GGSN-Knotens erzeugt. Jeder logische Knoten
kann selbstverständlich
zu einer separaten P-CSCF/PCF hin arbeiten, wie dies in der 8 unten
gezeigt ist. Hier besteht ein einziger GGSN 19 aus einer
Anzahl von logischen oder virtuellen GGSN-Knoten 20. Jeder
logische Knoten kann mit einer separaten P-CSCF/PCF 21 kommunizieren,
die bei einem P-CSCF-Knoten 22 mitangeordnet ist. Die virtuellen
GGSN-Verbindungen könnten
entweder durch Zuordnung eines IP-Adressensatzes oder durch Verwendung
unterschiedlicher Ports getrennt werden.
-
Wird
ein Knoten initialisiert, so würde
die Verbindung zu dem einen PDP normalerweise etabliert sein. In
diesem Fall, wenn der GGSN 19 initialisiert wird, würde jeder
virtuelle GGSN bzw. v-GGSN 20 die Verbindung zu der assoziierten
PCF 21 etablieren, wie in 9 gezeigt.
Die Implementierung kann entweder nur den v-GGSN 20 erzeugen,
wenn die Benutzer tatsächlich
verbunden sind, und die PCF, zu der sie hinarbeiten, identifiziert
wird, oder sie können sämtlich von
vornherein erzeugt und die Benutzer dem vorab existierenden v-GGSN 20 zugeordnet werden,
wenn sie verbunden sind.
-
Schließt sich
ein Benutzer über
den GGSN 19 an den IMS-APN an, so wird diesem Benutzer eine
IP-Adresse zugeordnet und die P-CSCF/PCF wird für diesen Benutzer identifiziert.
Zu diesem Zeitpunkt wird die IP-Adresse für den Benutzer dem virtuellen
GGSN 20, der mit dieser PCF 21 assoziiert ist,
zugeordnet. Solange diese IP-Adresse
zugeordnet bleibt, ist der virtuelle GGSN 20 in der Lage, SBLP-Richtlinien
von dieser PCF 21 für
die IP-Adresse dieses Benutzers zu empfangen. Beendet der Benutzer
die Verbindung mit dem APN (d.h. der PDP-Kontext wird entfernt),
so entfernt der virtuelle GGSN 20 diese IP-Adresse aus
seiner IP-Adressenliste als unter der Steuerung der PCF identifiziert.
Der virtuelle GGSN 20 soll jegliche Entscheidungen ablehnen,
die er für
eine IP-Adresse empfängt,
die nicht diesem virtuellen GGSN 20 gehört.
-
Der
v-GGSN 20 soll dann wie ein normaler COPS-Client über die
offene COPS-Schnittstelle
Entscheidungen empfangen und Berichte senden, wie in 10 dargestellt.
Mit dem logischen Knoten v-GGSN 20 innerhalb des GGSN 19 besteht
für die Richtliniensteuerung
von mehreren P-CSCF/PCF-Vorrichtungen zu einem einzigen GGSN für den SBLP-Client-Typ
keine Überlappung.
-
Die
zweite hierin berücksichtige
Ausführungsform
weist einen potentiellen Vorteil dadurch auf, dass sie keine Standardisierung
erfordert. Ist die 3GPP-Architektur nicht speziell zur Einführung eines PCF-C-Knotens
(Ausführungsform
1) modifiziert, wird somit die Implementierung eines „virtuellen" GGSN das umrissene
Problem überwinden.