DE602004008741T2

DE602004008741T2 - Nachrichten-basierte verteilung von last kontrollinformationen

Info

Publication number: DE602004008741T2
Application number: DE602004008741T
Authority: DE
Inventors: Petteri YLÄ-OUTINEN; Mikael Latvala; Lauri Lahtinen; Heikki Tuunanen; Ilkka Westman; Bernhard HÖNEISEN
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2003-01-30
Filing date: 2004-01-22
Publication date: 2008-06-12
Anticipated expiration: 2024-01-23
Also published as: EP1590719A2; DE602004008741D1; US9369498B2; ATE372540T1; KR100788083B1; ES2291847T3; US20040152469A1; EP1590719B1; WO2004068261A2; WO2004068261A3; CN101053231A; KR20050095625A

Description

Bereich der Erfindung
Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Steuern der Verarbeitungslast in einem Paketdatennetzwerk, wie beispielsweise in einem Internet Protocol (IP) Multimedia Subsystem (IMS), das einem Paketdatennetzwerk übergeordnet ist und Sprach- und Multimediadienste z.B. für Mobilgeräte der dritten Generation bereitstellt.
Hintergrund der Erfindung
Es wird erwartet, dass zukünftig nahezu alle festinstallierten und mobilen Kommunikationsnetzwerke auf Internettechnologie basieren werden. Insbesondere Dienste, in denen mehrere Kommunikationsarten und -modi kombiniert sind, werden wegweisend für zukünftige Netzwerke sein. Sprache selbst wird nur ein, obgleich wichtiges Element in der gesamten Kommunikationsarchitektur darstellen.
Durch das durch die Internet-Engineering-Task-Force-(IETF) Spezifikation RFC 3261 definierte Session Initiation Protocol (SIP) wird ein aufstrebender Standard für die Einrichtung von Multimedia-Sessions im Internet bereitgestellt. Seine Grundfähigkeiten sind Aufbau, Modifikation und Abbau oder Abbruch beliebiger Kommunikations-Sessions, so dass es ein Signalisierungsprotokoll darstellt. Durch das SIP wird außerdem persönliche Mobilität bereitgestellt, d.h., dass ein Kunde unabhängig von seiner aktuellen Verbindungsposition mit dem Netzwerk über eine einzige Adresse erreichbar ist.
Zum Unterstützen von Multimediadiensten, nahtloser Mobilität und effizienter Mehrteilnehmer-Konferenzdienste (Multiparty-Conferencing) müssen die IP-Schichten erweitert werden. Durch Mobile-IP wird ermöglicht, dass Endgeräte sich zwischen verschiedenen mobilen Netzwerken frei bewegen können.
Das SIP wird zum Aufbauen, Modifizieren und Abbauen von Sessions oder Sitzungen verwendet. Es stellt persönliche Mobilität zur Verfügung, indem es einem Benutzer ermöglicht, sich mit seiner Kommunikationsadresse, d.h. SIP-URI (Uniform Ressource Indicator) im Netzwerk zu registrieren. Eine Session oder Sitzung besteht normalerweise aus mehreren auszutauschenden Echtzeit-Transportprotokoll(RTP)strömen. Normalerweise besteht eine Session aus einer Kombination aus Sprach-, Audio- und Videoströmen, sie kann jedoch auch gemeinsam verwendete Anwendungen beinhalten. Ein Basis-SIP-Netzwerk besteht aus vier Typen von Elementen, d.h. Benutzeragenten (User Agents) (UA), Proxy-Servern, Umleitungsservern (Redirect Server) und Registrar-Servern. Benutzeragenten sind typischerweise an Endpunkten angeordnet und sind z.B. IP-Telefone, Personalcomputer oder Mobilgeräte. Sie erzeugen Anforderungen oder Anfragen und Antworten. Benutzeragenten (UAs) weisen normalerweise außerdem eine Schnittstelle zum Handhaben von Medien und für aktuelle Anwendungssoftware auf, die die Benutzerschnittstelle bereit stellt. Proxy-Server sind Vermittler oder Intermediaries, die Anfragen empfangen und weiterleiten und z.B. Routing-Dienste und andere Dienste dafür bereitstellen. Umleitungsserver antworten einfach auf eine Anfrage, indem sie ihren Absender bitten, sie zu einer neuen Adresse umzuleiten. Registrar-Server verfolgen aktuelle Kontaktpunkte des Kunden, indem sie Registrierungen von den Benutzeragenten annehmen. Durch Registrar-Server und die SIP-Registrierungsprozedur wird im Allgemeinen eine Benutzermobilität bereitgestellt, indem ermöglicht wird, dass der Kunde an jeder Position über eine einzige Adresse erreichbar ist. In diesem Sinne ähneln sie einer HLR-(Heimatregister (Home Location Register)) Funktionalität in GSM-(Global System for Mobile Communication) Netzwerken. Jeder Kunde ist Teil einer Domäne, und in jeder Domäne wird mindestens ein Registrar-Server betrieben, der die Position seiner Kunden kennt, insofern sie registriert sind.
Das SIP verwendet ein für Internet-Mail übliches Adressenformat, d.h. "user@domain". Der Domänenteil wird verwendet, um die korrekte Domäne für den Kunden zu finden, und der Benutzerteil wird verwendet, um zwischen einzelnen Kunden innerhalb einer Domäne zu unterscheiden. Das SIP verwendet Anfrage- und Antwortnachrichten, die Header-Felder oder Kopffelder z.B. zum Definieren des nächsten Übertragungsziels der Nachricht, der Empfängeradresse, der Absenderadresse, usw. aufweisen. Außerdem kann eine SIP-Nachricht einen Nutzlast- oder Payload-Abschnitt zum Übertragen von teilnehmer- oder dienstspezifischer Information enthalten.
RTP-Ströme folgen nicht dem gleichen Pfad, dem die SIP-Nachricht folgt, sondern fließen direkt zwischen entsprechenden Geräten. Daher können nachfolgende SIP-Anfragen direkt zwischen Benutzeragenten (UAs) übertragen werden. In einem Internet Protocol Multimedia Subsystem (IMS) folgen nachfolgende SIP-Nachrichten einem Pfad, der im Record-Route-Kopf der Anfangsanfrage gespeichert ist, während abfragende Netzwerkknoten sich selbst vom Pfad trennen können und andere Netzwerkelemente auf dem Pfad verbleiben. Andererseits können Proxy-Server in einem Mittenabschnitt anfordern, für die Dauer des Rufs auf dem Signalisierungspfad zu verbleiben. Dies könnte vorteilhaft sein, wenn der Proxy-Server Dienste für den Ruf anbietet.
Gegenwärtig spezifiziert das Third Generation Partnership Project (3GPP) z.B. in seiner Spezifikation TS 23.228 das IMS als zugangsunabhängiges Subsystem, das in Verbindung mit verschiedenen Netzwerken verwendbar ist. Das IMS verwendet das SIP für einen Session-Aufbau. Das IMS ist grundsätzlich nur ein Beispiel eines SIP-Netzwerks. Es weist mehrere Proxy-Server und einen Registrar-Server auf. Der Benutzeragent (UA) befindet sich im Endgerät oder Benutzerendgerät (User Equipment (UE)). Wenn zwei Geräte eine Session einrichten, kommunizieren sie über Verbindungszustands- und Dienstezustands-Steuerfunktionselemente (Call-State-Control-Function- oder Call-Session-Control-Function-(CSCF) Elemente) miteinander, während RTP-Medienströme nicht über CSCFs, sondern direkt zwischen den Geräten übertragen werden. Ein Anwendungsserver (AS) ist ein SIP-Element, das Dienste handhabt, z.B. fortschrittliche Rufsteuerung, Anwesenheits- oder Sofortbenachrchtigung (Presence- oder Instant-Messaging). Der Anwendungsserver kann Sessions/Transaktionen abbrechen. Der Anwendungsserver kann außerdem Sessions/Transaktionen z.B. im Auftrag eines Benutzers oder eines Dienstes einleiten oder starten.
Es können jedoch Situationen auftreten, in denen der Anwendungsserver nicht weiss, ob er Dienste starten oder beenden sollte, wenn er eine ankommende Anfragenachricht, z.B. eine SIP-INVITE-Nachricht empfängt, oder eine Serving-CSCF (S-CSCF) nicht weiß, ob durch die ankommende Anfragenachricht eine Sessi on/Transaktion gestartet oder beendet werden soll. Außerdem kann weitere Information für einen Lastausgleich innerhalb des Netzwerks erforderlich sein. Außerdem ist es für Lastverteilungszwecke in einem CPS-Server (Connection Processing Server), insbesondere in der Serving-CSCF (S-CSCF) und in einer Interrogation-CSCF (I-CSCF) wichtig, einen schnellen und einfachen Algorithmus bereitzustellen, um festzustellen, ob eine empfangene SIP-Anfrage die erste Anfrage in einer SIP-Session ist, oder welcher SIP-Session eine empfangene Anfrage oder Antwort zugeordnet ist. Gegenwärtig wird durch das SIP kein derartiges effizientes Mittel bereitgestellt. Um einen SIP-Dialog zu identifizieren, d.h. einen Rufidentifizierungsabschnitt (Call Leg), der durch eine Kombination aus einer Rufidentifizierung, einer Quelle und einem Ziel identifiziert wird, muss ein Netzwerkelement oder ein Benutzerendgerät (UE) die jeweiligen Kopffelder jeder SIP-Nachricht vergleichen und dann bestimmen, ob der Rufidentifizierungsabschnitt (Call Leg) bereits existiert. Dies beinhaltet aufwendige Zeichenfolge-Vergleiche und Datenbankabfragen. Ein Netzwerkelement, das eine große Zahl paralleler Rufidentifizierungsabschnitte (Call Legs) hält, benötigte viele Ressourcen. Außerdem ist für den Fall einer Störung in einem Netzwerkelement Information über laufende oder existierende Sessions erforderlich.
Kurze Beschreibung der Erfindung
Daher ist es Aufgabe der vorliegenden Erfindung, ein effizientes Laststeuerungsverfahren für Paketdatennetzwerke bereitzustellen.
Diese Aufgabe wird durch ein Verfahren zum Steuern der Verarbeitungslast in einem Paketdatennetzwerk gelöst, wobei das Verfahren die Schritte aufweist:

– Einstellen einer Laststeuerinformation in einem vorbestimmten Feld einer Nachricht;
– Leiten der Nachricht durch das Paketdatennetzwerk;
– Prüfen der Laststeuerinformation auf dem Leitweg der Nachricht und/oder auf dem Leitweg einer Antwortnachricht auf die Nachricht; und
– Auswählen einer Verarbeitungsressource des Paketdatennetzwerks in Antwort auf das Ergebnis des Prüfschritts.

Außerdem wird die vorstehende Aufgabe durch eine Netzwerkvorrichtung zum Steuern der Verarbeitungslast in einem Paketdatennetzwerk gelöst, wobei die Vorrichtung aufweist:

– Prüfmittel zum Prüfen einer in einem vorbestimmten Feld einer Nachricht oder einer Antwortnachricht bereitgestellten Laststeuerinformation; und
– Auswahlmittel zum Auswählen einer Verarbeitungsressource für die Nachricht oder Antwortnachricht in Antwort auf das Prüfmittel.

Außerdem wird die vorstehende Aufgabe durch eine Vorrichtung zum Übertragen einer Nachricht an ein Paketdatennetzwerk gelöst, wobei die Vorrichtung dazu geeignet ist, eine Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks in einem vorbestimmten Feld der Nachricht zu setzen.
Außerdem wird die vorstehende Aufgabe durch ein Verfahren zum Verteilen von Laststeuerinformation in einem paketvermittelten Netzwerk gelöst, wobei das Verfahren die Schritte aufweist:

– Erzeugen einer ersten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks in einem ersten Netzelement;
– Einstellen der ersten Laststeuerinformation in ein vorbestimmtes Feld einer Nachricht;
– Leiten der Nachricht zu einem zweiten Netzelement;
– Speichern der ersten Laststeuerinformation in dem zweiten Netzelement;
– Erzeugen einer zweiten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks in dem zweiten Netzelement;
– Einstellen der zweiten Laststeuerinformation in einem vorbestimmten Feld einer zweiten Nachricht;
– Leiten der zweiten Nachricht zum ersten Netzelement; und
– Speichern der zweiten Laststeuerinformation an dem ersten Netzwerkelement.

Außerdem wird die vorstehende Aufgabe durch ein System zum Steuern der Verarbeitungslast in einem Paketdatennetzwerk gelöst, wobei das System aufweist:

– ein erstes Netzwerkelement zum Einstellen einer Laststeuerinformation in einem vorbestimmten Feld einer in dem Paketdatennetzwerk zu leitende Nachricht;
– ein zweites Netzwerkelement zum Prüfen der Laststeuerinformation auf dem Leiweg (route) der Nachricht und zum Auswählen einer Verarbeitungsressource des Paketdatennetzwerks in Antwort auf das Prüfergebnis.

Schließlich wird die vorstehende Aufgabe durch ein System zum Verteilen von Laststeuerinformation in einem paketvermittelten Netzwerk gelöst, wobei das System aufweist:

– ein erstes Netzwerkelement zum Erzeugen einer ersten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks und zum Einstellen der ersten Laststeuerinformation in einem vorbestimmten Feld einer Nachricht;
– ein zweites Netzwerkelement zum Empfangen der Nachricht, zum Speichern der ersten Laststeuerinformation, zum Erzeugen einer zweiten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks, zum Einstellen der zweiten Laststeuerinformation in einem vorbestimmten Feld einer zweiten Nachricht, und zum Leiten der zweiten Laststeuerinformation zu dem ersten Netzwerkelement; wobei das erste Netzwerkelement ausgestaltet ist, die zweite Laststeuerinformation zu speichern.

Daher kann Lastverteilungs- oder Lastausgleichsinformation in Nachrichten zu den jeweiligen Netzwerkknoten oder -servern geleitet bzw. übertragen werden, um die für die Laststeuerungsfunktionalität benötigten Ressourcen zu vermindern. Darüber hinaus kann im Fall von Störungen von Netzwerkelementen Information über laufende oder existierende Sessions bereitgestellt werden.
Das vorbestimmte Feld kann ein "Via-Zweig" oder Weiterleitungszweig einer SIP-Nachricht sein. Die Lastausgleichsinformation kann von einem anderen vorbestimmten Feld in das vorbestimmte Feld kopiert werden.
Das vorbestimmte Feld kann ein Unterfeld eines Benutzerteils eines Adressenkopfes, z.B. eines URI- oder eines SIP-Route-Kopfes sein. Dadurch kann zusätzliche Information im Benutzerteil übertragen werden. Insbesondere kann vertrauliche Unternehmensinformation in einem oder mehreren Unterfeldern übertragen werden, z.B. verschlüsselte und/oder tokenisierte und/oder codierte Information. Außerdem kann eine Übertragung innerhalb eines Netzwerkelements, z.B. die Auswahl eines korrekten Rufzustandmodells (beispielsweise zum Erzeugen oder Beenden einer Session/Transaktion), unter Verwendung des Unterfeldes bzw. der Unterfelder des Benutzerteils ausgeführt werden. Die Laststeuerinformation und/oder andere Steuerinformation kann eine teilnehmer- und/oder dienst- und/oder serverspezifische Information sein, die in einem oder mehreren Unterfeldern z.B. von einer S-CSCF zu einem Anwendungsserver (AS) übertragen wird. Alternativ kann eine IP-Adresse im Unterfeld übertragen werden, die eine Adresse des Hosts im Domänenteil sein kann.
Daher können im Benutzerteil mehrere Unterfelder zum Übertragen verschiedenartiger Lassteuerinformation und/oder anderer Steuerinformation bereitgestellt werden. Insbesondere kann der Benutzerteil geparst und in die Unterfelder unterteilt werden. Alternativ kann die Struktur und/oder die Folge und/oder die Nutzung der Unterfelder z.B. auf einer standardisierten Basis vorgegeben sein. Die Unterfelder können durch eine vorgegebene Bitfolge, ein Zeichen, eine Zeichenfolge oder ein anderes Trennelement getrennt werden.
Der Auswahlschritt kann für einen Lastausgleich verwendet werden. Eine virtuelle Adresse wird zum Verteilen der Nachricht zu einem vorgegebenen Prozessorknoten verwendet. Die virtuelle Adresse kann von mehreren Prozessorknoten gemeinsam verwendet werden. Diese Prozessorknoten können eine Rufzustandsteuerungsfunktionalität eines IP-basierten zellularen Netzwerks aufweisen. Dadurch wird ein Mechanismus zum Gewährleisten eines gleichmäßigen Lastausgleichs bereitgestellt, und ein Teilnehmer kann für die gesamte Registrierungszeitdauer einem Prozessorknoten zugewiesen werden. Unter Verwendung einer virtuellen Adresse kann ein Cluster selbst einen Lastausgleich für Clusterknoten implementieren.
Außerdem kann die Laststeuerinformation eine erste Port-Nummer aufweisen, die einen ersten Port zum Empfangen einer Anfragenachricht anzeigt. Außerdem kann die Laststeuerinformation eine zweite Port-Nummer aufweisen, die einen zweiten Port zum Empfangen einer Antwortnachricht anzeigt. Dadurch können Anfragen und Antworten am angezeigten Port empfangen werden, an dem Lastausgleichsinformation bereitgestellt wird.
Gemäß einem anderen Aspekt kann die Laststeuerinformation eine erste Information und eine optionale zweite Information aufweisen. Die erste und die optionale zweite Information können in einem Kopffeld gesetzt werden, das aus einem Route-Kopffeld, einem Via-Kopffeld oder einem Contact-Kopffeld einer SIP-Nachricht ausgewählt wird. Die erste Information kann anzeigen, ob eine Session der Nachricht bereits existiert. Die optionale zweite Information kann dann eine Identifizierung der existierenden Session anzeigen. Die erste und die zweite Information können verborgene Informationen sein, die für andere Netzwerke bedeutungslos sind.
Daher können zwei Alternativen bereitgestellt werden. Gemäß der ersten Alternative wird lediglich erfasst, ob die Nachricht die erste Nachricht in einem Rufidentifizierungsabschnitt (Call Leg) ist. Dadurch kann eine einfache und schnelle Erkennung der ersten Nachricht in einer Session bereitgestellt werden. Andere Netzwerkelemente oder Endgeräte müssen nicht modifiziert werden. Das Schema kann auch auf einer nicht-standardisierten Basis bereitgestellt werden. Gemäß der zweiten Alternative wird basierend auf der zweiten Information eine zusätzliche Session-Identifizierung erfasst. Dadurch kann zusätzlich zu den vorstehend beschriebenen Vorteilen der ersten Alternative eine einfache und schnelle Erkennung der betreffenden Session bereitgestellt werden.
Insbesondere können die erste und/oder die zweite Information als Teil eines Benutzerteils in einer Adresse (z.B. SIP URI) eines Kopffeldes, als Teil eines Host-Namens eines Kopffeldes, als Teil eines Domänennamens eines Kopffeldes, als Parameter des Kopffeldes, als Port-Nummer des Kopffeldes, wobei die Port-Nummer zum Unterscheiden einer ersten Nachricht von nachfolgenden Nachrichten verwendbar ist, oder als Erweiterungskopffeld der Nachricht gesetzt werden. Alternativ können die erste und/oder die zweite Information in einem Payload-Abschnitt der Nachricht gesetzt werden.
Die zweite Information kann dann in Antwort auf eine Erfassung der ersten Information extrahiert und im Auswahlschritt verwendet werden.
Die Netzwerkvorrichtung zum Steuern der Verarbeitungslast kann eine Rufzustand- oder Ruf-Session-Steuerungsfunktionalität eines IP-basierten zellularen Netzwerks aufweisen. Die Auswahleinrichtung kann dazu geeignet sein, einen vorgegebenen Prozessorknoten auszuwählen, an den die Nachricht verteilt wird. Daher wird der Prozessorknoten nicht nur durch die virtuellen Adresse, sondern zusätzlich auch durch die Laststeuerinformation spezifiziert.
Die Auswahleinrichtung kann dazu geeignet sein, eine neue Session aufzubauen.
Die Vorrichtung zum Übertragen der Nachricht kann außerdem eine Rufzustandsteuerungsfunktionalität oder eine Ruf-Session-Steuerungsfunktionalität des IP-basierten zellularen Netzwerks aufweisen. Diese Session-Steuerungsfunktionalität kann eine Serving-CSCF-(S-CSCF), eine Interrogation-CSCF-(I-SCCF) oder eine Proxy-CSCF-(P-CSCF) Funktionalität sein. Die Vorrichtung kann dazu geeignet sein, die Laststeuerinformation im Benutzerteil der Kopfadresse der Nachricht oder alternativ in einem Host-Namen, einem Domänennamen, einem Kopfparameter, einer Port-Nummer, einem Erweiterungskopffeld eines Kopfabschnitts oder in einem Payload-Abschnitt der Nachricht zu setzen.
Weitere vorteilhafte Entwicklungen der vorliegenden Erfindung sind in den beigefügten Patentansprüchen definiert.
Kurzbeschreibung der Zeichnungen
Die vorliegende Erfindung wird nachstehend unter Bezug auf bevorzugte Ausführungsformen in Verbindung mit den beigefügten Zeichnungen beschrieben; es zeigen:
1 eine IMS-Netzwerkarchitektur, in der die vorliegende Erfindung implementierbar ist;
2 eine Struktur einer SIP-URI gemäß der ersten bevorzugten Ausführungsform;
3 ein Signalisierungs- und Verarbeitungsdiagramm eines ersten Signalisierungsbeispiels gemäß der ersten bevorzugten Ausführungsform;
4 ein Verarbeitungs- und Signalisierungsdiagramm eines ersten Signalisierungsbeispiels gemäß der ersten bevorzugten Ausführungsform;
5 ein Signalisierungs- und Verarbeitungsdiagramm gemäß einer zweiten bevorzugten Ausführungsform;
6 ein Ablaufdiagramm eines ersten Beispiels eines Lastverteilungsmechanismus gemäß der zweiten bevorzugten Ausführungsform; und
7 ein Ablaufdiagramm eines zweiten Beispiels eines Lastverteilungsmechanismus gemäß der zweiten bevorzugten Ausführung.
Beschreibung der bevorzugten Ausführungsformen
Nachstehend werden bevorzugte Ausführungsformen unter Bezug auf die in 1 dargestellte IMS-Netzwerkarchitektur beschrieben.
1 zeigt nur die für die Beschreibung der vorliegenden Erfindung erforderlichen IMS-Komponenten. Beispielsweise sind in 1 das Funkzugangsnetzwerk und das Kernnetzwerk nicht dargestellt. Gemäß 1 ist ein Endgerät oder ein Benutzerendgerät (User Equipment (UE)), das ein mobiles oder zellulares Endgerät sein kann, mit einer Proxy- oder P-CSCF 20 verbunden, die in einer besuchten Domäne 70 des Benutzerendgerät 10 angeordnet ist und eine Basis-IP-Konnektivität und ein Mobilmanagement bereitstellt. Das Benutzerendgerät 10 verwendet das SIP für eine Kommunikation mit der P-CSCF 20 auf ähnliche Weise wie bei einem SIP-Proxy-Server. Im vorliegenden Fall roamt der Kunde oder Teilnehmer des Benutzerendgeräts 10 in der besuchten Domäne 70, in der die P-CSCF 20 angeordnet ist. Die P-CSCF 20 dient zum Bereitstellen eines Notrufdienstes und ähnlicher Dienste, für die eine spezifische Kenntnis der besuchten Domäne 70 erforderlich ist. An Stelle eines Funkzugangsnetzwerks können auch alternative Netzwerke verwendet werden. An Stelle eines mobilen oder zellularen Endgeräts können auch andersartige Endgeräte verwendet werden, insbesondere in alternativen Zugangsnetzwerken.
Außerdem ist immer eine S-CSCF 40 in der Heimat-Domäne 80 des Teilnehmers oder Kunden angeordnet und dient als SIP-Registrar- und Proxy-Server, so dass das Benutzerendgerät 10 unter Verwendung des SIP über die P-CSCF 20 an der S-CSCF 40 registriert werden kann. Außerdem wird eine I-CSCF 30 als weiterer SIP- Proxy-Server bereitgestellt, der hauptsächlich dafür verantwortlich ist, die korrekte S-CSCF für einen vorgegebenen Teilnehmer oder Kunden zu finden. Die S-CSCFs können pro Registrierung dynamisch zugewiesen werden, um einen effizienten Lastausgleich und eine effiziente Fehlerpositionsbestimmung zu ermöglichen. Ein Anwendungsserver (AS) 60 wird als SIP-Element bereitgestellt, das die für das Benutzerendgerät 10 bereitgestellten Dienste handhabt. Für verschiedene Zwecke können separate Anwendungsserver bereitgestellt werden. Schließlich ist ein Heimat-Teilnehmerserver (Home Subscriber Server (HSS)) 50 für ein Profilmanagement und eine Authentifizierung vorgesehen.
Nachstehend wird eine erste bevorzugte Ausführungsform der vorliegenden Erfindung unter Bezug auf die 2 bis 6 beschrieben.
In der ersten bevorzugten Ausführungsform wird ein Inhalt eines Benutzerteils der SIP-URI für eine Laststeueung, z.B. eine Session-Steuerung und einen Lastausgleich, verwendet. Insbesondere kann der Benutzerteil der SIP-URI (Uniform Resource Idenitifier) in Unterfelder unterteilt werden, die z.B. für Steuerungs- und/oder Routing-Zwecke verwendbar sind. Im SIP enthält der Route-Kopf normalerweise SIP-URIs, die nur einen Domänenteil aufweisen, so dass der Benutzerteil für andere Zwecke frei nutzbar ist.
2 zeigt ein schematisches Diagramm einer Struktur der FQDN-(Fully Qualified Domain Name) oder SIP-URI 100 gemäß der ersten bevorzugten Ausführungsform. Die SIP-URI 100 weist ähnlich wie eine eMail-Adresse einen Benutzerteil 120 und einen Domänenteil 140 auf, die durch ein "@"-Zeichen getrennt sind. Die durch das SIP adressierten Objekte sind durch die SIP-URI 100 identifizierte Benutzer an Hosts. Der Benutzerteil 120 wird zum Übertragen eines Benutzernamens oder einer Telefonnummer verwendet, während der Host- oder Domänenteil 140 entweder einen Domänennamen oder eine numerische Netzwerkadresse überträgt.
Aufgrund der Tatsache, dass der Benutzerteil weder im Route-Kopf noch im Via-Kopf verwendet wird, kann er in Unterfelder 121, 122, ... 12n unterteilt werden, die durch ein geeignetes Trennelement 130, z.B. eine Bitfolge, ein Zeichen oder eine Zeichenfolge, getrennt werden können, wobei die Zeichen druckbare und/oder nicht-druckbare Zeichen oder Bitfolgen sein können. Die Folge und die Nutzung der Un terfelder 121 bis 12n kann vorgegeben oder standardisiert sein, insofern sie nicht als implementierungsspezifische Information betrachtet wird.
Hinsichtlich der Anordnung und Struktur der Unterfelder 121 bis 12n im Benutzerteil 120 können drei Optionen verwendet werden.
Gemäß der ersten Option kann der Benutzerteil 120 als einzelnes Feld strukturiert sein, das die Unterfelder 121 bis 12n enthält. Dieses einzelne Feld kann dann gegebenenfalls in die Unterfelder 121 bis 12n geparst und unterteilt werden. Dadurch wird der Vorteil erhalten, dass keine Standardisierung erforderlich ist, wenn das Feld innerhalb des gleichen Netzwerks erzeugt und verwendet wird.
Gemäß einer zweiten Option kann der Benutzerteil 120 strukturell aus den Unterfeldern 121 bis 12n bestehen, während die Syntax und möglicherweise auch die Sematik der Unterfelder 121 bis 12n vordefiniert und standardisiert sind. In diesem Fall können die Unterfelder 121 bis 12n auch in verschiedenen Netzwerken erzeugt und verwendet werden.
Gemäß der dritten Option kann eine Kombination aus der ersten und der zweiten Option verwendet werden.
Nachstehend wird ein Beispiel der SIP-URI 100 beschrieben, wobei ein zweites Unterfeld zum Signalisieren des Session-/Transaktionsfalls und ein erstes Unterfeld zum Signalisieren einer implementierungsspezifischen Information verwendet werden. Das Trennelement 130 wird durch das Korrekturzeichen "_" gebildet.
57BC442C_terminating@s-cscf2.ims.sonera.fi
Daher wird "terminating" als Session-/Transaktionsfall signalisiert, und "57BC442C" wird als implementierungsspezifische Information signalisiert.
Nachstehend werden ein erstes und ein zweites Beispiel eines Laststeuerungsmechanismus gemäß der ersten bevorzugten Ausführungsform unter Bezug auf die 3 und 4 beschrieben.
Der Laststeuerungsmechanismus dient zum Gewährleisten eines gleichmäßigen Lastausgleichs, wenn ein Netzwerkelement oder ein Netzwerkteil durch mehrere Prozessorknoten implementiert wird. In der in 1 dargestellten IMS-Netzwerkarchitektur weist das Benutzerendgerät (UE) 10 die P-CSCF 20 als Kontaktpunkt zum Netzwerk auf. Zwischen dem Benutzerendgerät 10 und der P-CSCF 20 wird eine IP-Sicherheitsfunktion IPSec für einen Integritäts- und Vertraulichkeitsschutz verwendet. Außerdem kann eine Komprimierungsfunktion zum Komprimieren der Signalisierungsinformation im Präfix- oder Benutzerteil 120 der FQDN- oder SIP-URI 100 des Benutzerendgeräts 10 verwendet werden. Zum Erzielen einer hohen Kapazität und schneller Ansprechzeiten müssen die IPSec-Daten und die Komprimierungsdaten des spezifischen Teilnehmers des Benutzerendgeräts 10 in einem Speicher gespeichert werden, z.B. in einem flüchtigen Speicher oder einem Direktzugriffsspeicher (RAM). Dadurch sollte ein Teilnehmer dem Prozessorknoten zugewiesen werden, in dem er registriert ist. Unter Verwendung der virtuellen Adresse kann nur der Knoten- oder Server-Cluster selbst einen Lastausgleich für Clusterknoten ausführen.
3 zeigt ein Signalisierungs- und Verarbeitungsdiagramm eines Laststeuerungsmechanismus zum Verteilen einer Lastausgleichsinformation (LBI) nach einer Registrierung eines Benutzers. Hierbei ist z.B. ein Grund dafür, dass ein Lastausgleich ausgeführt wird, dass eine Komprimierung an verteilten Knoten ausgeführt wird. Daher kann in der Praxis an der Schnittstelle zwischen dem Benutzerendgerät (UE) 10 und der P-CSCF 20 kein Lastausgleich basierend auf SIP-Ebeneninformation ausgeführt werden, weil diese komprimiert ist. An dieser Schnittstelle wird ein geeigneter Lastausgleichsschlüssel durch die IP-Adresse des Benutzerendgeräts (UE) 10 gebildet. Wenn ein Abbruchversuch (Termination Attempt) oder eine Abbruchanforderung empfangen wird, der/die für das Benutzerendgerät (UE) 10 bestimmt ist, ist es wesentlich, dass der Abbruchversuch am gleichen Verarbeitungsknoten empfangen wird, an den Nachrichten vom Benutzerendgerät 10 verteilt werden. Dadurch können unnötige Sprünge im IP-basierten Netzwerk vermieden werden.
Wenn das Benutzerendgerät 10 in Schritt 1 eine SIP-Registrierungsnachricht überträgt, erzeugt die P-CSCF 20 in Schritt 2 eine erste Lastausgleichsinformation LBI(P-CSCF-1) und setzt sie in den SIP-URL(P-CSCF) des Pfadfeldes des Kopfes dieser Registrierungsnachricht ein. Die erste Lastausgleichsinformation LBI(P-CSCF-1) im Pfadfeld wird zukünftig empfangen, wenn eine Anfangsanfrage von der S-CSCF 40 empfangen wird. Die P-CSCF 20 erzeugt eine zweite Lastausgleichsinformation LBI(P-CSCF-2) und fügt sie in den Via-Zweig dieser Registrierungsnachricht ein. Die zweite Lastausgleichsinformation LBI(P-CSCF-2) am Via-Zweig wird zusammen mit einer Antwort auf diese Registrierungsnachricht empfangen. Die erste und die zweite Lastausgleichsinformation LBI(P-CSCF-1) und LBI(P-CSCF-2) können identisch oder verschieden sein. Die Registrierungsnachricht wird in den Schritten 3 und 4 über die I-CSCF 30 zur S-CSCF 40 übertragen. Wenn die S-CSCF 40 die Registrierungsnachricht von der P-CSCF 20 empfängt, führt sie in Schritt 5 z.B. basierend auf der Rufidentifizierung einen Lastausgleich aus. In Schritt 6 speichert die S-CSCF 40 dann den SIP-URL(P-CSCF) vom Pfadfeld, der die erste Lastausgleichsinformation LBI(P-CSCF-1) der P-CSCF 20 enthält, in einer Teilnehmerdatenbank. In Schritt 7 erzeugt die S-CSCF 40 eine eigene Lastausgleichsinformation LBI(S-CSCF-1) und fügt sie in den SIP-URL(S-CSCF) des Service-Route-Feldes der SIP-200OK-Antwortnachricht ein, die in den Schritten 8 und 9 über die I-CSCF 30 an die P-CSCF 20 übertragen wurde. Diese Lastausgleichsinformation LBI(S-CSCF-1) wird zukünftig empfangen, wenn eine Anfangsanfrage von der P-CSCF 20 empfangen wird. Außerdem enthält der Via-Zweig den SIP-URL(P-CSCF) der P-CSCF 20, der von der nach Schritt 4 empfangenen Registrierungsnachricht kopiert worden ist. Wenn die P-CSCF 20 diese 200OK-Antwortnachricht empfängt, kann in Schritt 10 basierend auf der vom Via-Zweig erhaltenen zweiten Lastausgleichsinformation LBI(P-CSCF-2) ein Lastausgleich ausgeführt werden. In Schritt 11 speichert die P-CSCF 20 den SIP-URL(S-CSCF), der die vom Service-Route-Feld der 200OK-Antwortnachricht erhaltene Lastausgleichsinformation LBI(S-CSCF-1) der S-CSCF 40 enthält, in einer Datenbank. Schließlich wird in Schritt 12 die eine erfolgreiche Registrierung anzeigende 200OK-Antwortnachricht an das Benutzerendgerät 10 weitergeleitet.
Daher weist die P-CSCF 20 gemäß der vorstehenden Prozedur den SIP-URL(S-CSCF) in ihren Teilnehmerdaten auf, der zur S-CSCF 40 zeigt und die entsprechende Lastausgleichsinformation LBI(S-CSCF-1) enthält. Ähnlicherweise weist die S-CSCF 40 den SIP-URL(P-CSCF) in ihren Teilnehmerdaten auf, der zur P-CSCF 20 zeigt und die entsprechende Lastausgleichsinformation LBI(P-CSCF-1) enthält. Die Lastausgleichsinformation kann daher durch die jeweiligen Lastausgleichsein richtungen der P-CSCF 20 und der S-CSCF 40 verwendet werden. Beispielsweise ruft, wenn ein Abbruchversuch auftritt, die S-CSCF 40 diese Lastausgleichsinformation von der Teilnehmerdatenbank ab und fügt sie in die entsprechende Anfrage ein.
4 zeigt ein Verarbeitungs- und Signalisierungsdiagramm eines Laststeuerungsmechanismus für die Verwendung der Lastausgleichsinformation (LBI), wenn eine Session-Startanfrage an das Netzwerk übertragen wird. Wenn das Benutzerendgerät in Schritt 1 eine SIP-Invite-Nachricht an die P-CSCF 20 überträgt, wird basierend auf der IP-Adresse des Benutzerendgeräts 10 ein Lastausgleich ausgeführt. In Schritt 2 liest die P-CSCF 20 von der Teilnehmerdatenbank den zuvor gespeicherten SIP-URL(S-CSCF), der in Schritt 3 für die Übertragung der Invite-Nachricht an die S-CSCF 40 verwendet werden soll. Außerdem wird der SIP-URL(S-CSCF) in das oberste Route-Feld eingefügt, und der SIP-URL(P-CSCF) wird in das Record-Route-Feld eingefügt. Außerdem wird die erste Lastausgleichsinformation LBI(P-CSCF-1) in den Via-Zweig eingefügt. Wenn die Invite-Nachricht an der S-CSCF 40 empfangen wird, erhält sie vom obersten Route-Feld den SIP-URL(S-CSCF), der die zuvor gesetzte Lastausgleichsinformation LBI(S-CSCF-1) enthält. Basierend auf diese Lastausgleichsinformation LBI(S-CSCF-1) wird in Schritt 4 ein Lastausgleich ausgeführt, um einen korrekten Computer zu finden. Wenn die S-CSCF 40 in Schritt 5 die Invite-Nachricht überträgt, fügt sie den SIP-URL(S-CSCF) in das Record-Route-Feld ein und fügt ihre Lastausgleichsinformation LBI(S-CSCF-1) in den Via-Zweig ein. In Schritt 6 antwortet der Anwendungsserver 60 mit einer 200OK-Antwortnachricht, die die Lastausgleichsinformationen LBI(P-CSCF-1) und LBI(S-CSCF-1) der P-CSCF 20 und der S-CSCF 40 im Via-Zweig enthält. Wenn die S-CSCF 40 die 200OK-Antwortnachricht empfängt, erhält sie ihre Lastausgleichsinformation LBI(S-CSCF-1) vom Via-Zweig und verwendet sie in Schritt 7 für einen Lastausgleich. Ähnlicherweise erhält, wenn die P-CSCF 20 anschließend die in Schritt 8 durch die S-CSCF 40 weitergeleitete 200OK-Antwortnachricht empfängt, die P-CSCF 20 ihre erste Lastausgleichseinformation LBI(P-CSCF-1) vom Via-Zweig und verwendet sie in Schritt 9 für einen Lastausgleich. In Schritt 10 wird die 200OK-Nachricht an das Benutzerendgerät 10 weitergeleitet, um die vorangehende Invite-Nachricht zu bestätigen.
Wenn der Anwendungsserver 60 in Schritt 11 eine nachfolgende SIP-Anfrage, z.B. eine Invite-Nachricht, innerhalb eines Dialogs überträgt, verwendet er eine Route- Liste, die er basierend auf den Record-Route-Eintragungen der Anfangsanfrage, d.h. der nach Schritt 5 empfangenen Invite-Nachricht, erzeugt hat. Die oberste Route-Eintragung ist der SIP-URL(S-CSCF), der die entsprechende Lastausgleichsinformation LBI(S-CSCF-1) enthält. Die zweite Route-Eintragung ist der SIP-URL(P-CSCF), der die entsprechende Lastausgleichsinformation LBI(P-CSCF-1) enthält. Wenn die S-CSCF 40 die nachfolgende Invite-Nachricht empfängt, erhält sie von der obersten Route-Eintragung ihre Lastausgleichsinformation LBI(S-CSCF-1), die im SIP-URL(S-CSCF) enthalten ist. In Schritt 12 führt die S-CSCF 40 basierend auf dieser Lastausgleichsinformation LBI(S-CSCF-1) einen Lastausgleich aus und entfernt die auf sich selbst zeigende Route-Eintragung. Nun zeigt die oberste Route-Eintragung zur P-CSCF 20. In Schritt 13 wird die nachfolgende Invite-Nachricht zur P-CSCF 20 weitergeleitet. Wenn die P-CSCF 20 die nachfolgende Invite-Nachricht empfängt, erhält sie von der obersten Route-Eintragung ihre Lastausgleichsinformation LBI(P-CSCF-1), die im SIP-URL(P-CSCF) bereitgestellt wird. Dann führt sie in Schritt 14 basierend auf dieser Lastausgleichsinformation LBI(P-CSCF-1) einen Lastausgleich aus und entfernt die auf sich selbst zeigende Route-Eintragung. Schließlich wird die Invite-Nachricht in Schritt 15 zum Benutzerendgerät 10 weitergeleitet.
Im Allgemeinen wird die Pfad- und Lastausgleichsinformation zur Verwnedung in späteren Anfragen in der Registrierungsphase aufgezeichnet und gespeichert. Spätere Anfragen sollten diese Lastausgleichsinformation enthalten, so dass ein Lastausgleich basierend auf dieser Lastausgleichsinformation ausgeführt wird. Daher dient jegliche Lastausgleichsinformation, die während der Registrierungsphase eingefügt wird, für zukünftige Anfragen.
In allen Fällen kann der Via-Zweig-Parameter des Via-Kopffeldes dafür verwendet werden, ähnliche Information zu übertragen, die durch die Lastausgleichsfunktion verwendet wird, um Antworten zum korrekten Prozessorknoten zu verteilen.
Außerdem können verschiedene Port-Nummern verwendet werden, um zu identifizieren, an welcher Stelle die Lastausgleichsinformation gefunden werden kann. Insbesondere wird der Anfrageport während einer "Pfadaufzeichnung" im Domänenteil 140 der SIP-URI 120 gesetzt. Infolgedessen werden Anfragen am Anfrageport empfangen und ist bekannt, an welcher Stelle die Lastausgleichsinformation gelesen werden soll. Ähnlicherweise kann ein "Port" für abgehende Anfragen gesetzt werden, so dass Antworten an diesem Port empfangen werden.
Im Fall einer Lastausgleichsfunktion für einen für ein betreffendes Netzwerkelement bestimmten ankommenden SIP-Verkehr wird die Ziel-IP-Adresse geprüft, um festzustellen, ob sie eine virtuelle IP-Adresse ist oder nicht. Wenn sie keine virtuelle IP-Adresse ist, ist kein Lastausgleich erforderlich, so dass in diesem Fall z.B. ein normales L3-Routing für das Paket angewendet werden kann. Wenn die Ziel-IP-Adresse eine virtuelle IP-Adresse ist, ist dagegen ein Lastausgleich erforderlich. Hierbei bestehen zwei Auswahlmöglichkeiten, d.h., die virtuelle IP-Adresse kann entweder eine P-CSCF-Adresse oder eine S-CSCF- bzw. eine I-CSCF-Adresse sein. Es wird eine entsprechende Ziel-Port-Information verwendet, um die Art und die Position der Lastausgleichsinformation zu erfassen. Dann wird ein Lastausgleich basierend auf der Lastausgleichsinformation ausgeführt, wobei das erhaltene Ausgangssignal dem korrekten Verarbeitungsknoten entspricht, an den die Pakete weitergeleitet werden sollten. Die Lastausgleichsinformation kann eine Rufidentifizierung, eine Benutzerendgerät-IP-Adresse oder eine im Voraus erzeugte Lastausgleichsinformation sein.
Im Fall von vom betreffenden Netzwerkelement erzeugtem abgehenden Verkehr wird die Quellen-IP-Adresse geprüft, um festzustellen, ob sie eine der virtuellen Adressen (P-CSCF, S-CSCF oder I-CSCF) des CPS-Servers ist. Wenn dies nicht der Fall ist, wird ein normales Routing ausgeführt. Wenn die Quellen-IP-Adresse eine der virtuellen Adressen des CPS-Servers ist, wird das Transportprotokoll bestimmt, und anschließend wird der Ziel-Port geprüft, um einen Anfrageport oder einen dedizierten Port zu bestimmen. Basierend auf dem Prüfergebnis wird eine Verarbeitung zum Extrahieren der Lastausgleichsinfornmation und Weiterleiten des IP-Pakets ausgewählt. Im Fall einer Nicht-Schleifenadresse (Not-Loop-Adresse) wird die Quellen-IP-Adresse erneut geprüft, um festzustellen, ob sie eine S-CSCF-/I-CSCF-Adresse oder eine P-CSCF-Adresse ist. Wenn sie eine S-CSCF-/I-CSCF-Adresse ist, wird das Transportprotokoll, d.h. Transmission Control Protocol (TOP) oder User Datagram Protocol (UDP), bestimmt. Wenn TOP angezeigt wird, wird die SIP-Nachricht nach einem Puffervorgang neu zusammengesetzt und dann weitergeleitet. Wenn UDP angezeigt wird, kann das IP-Paket direkt weitergeleitet werden. Wenn sie eine P-CSCF-Adresse ist, wird der Quellen-Port bestimmt. Wenn ein Client-Port oder ein Anfrageport angezeigt wird, wird das Transportprotokoll bestimmt, und die vorstehend beschriebene Verarbeitung wird erneut gestartet. Wenn ein UE-Unsecure/Secure-Client-/Server-Port angezeigt wird, wird das IP-Paket durch eine L3-(Protokollschicht 3) Prozedur direkt weitergeleitet.
Nachstehend wird die zweite bevorzugte Ausführungsform der vorliegenden Erfindung unter Bezug auf die 5 bis 7 beschrieben. Die zweite bevorzugte Ausführungsform betrifft einen Lastverteilungsmechanismus zum effektiven Bestimmen, welcher SIP-Verkehr welcher Session zugeordnet ist, und ob eine Anfrage, z.B. eine SIP-Invite-Anfrage, eine Anfangsanfrage oder eine erneute Anfrage ist.
5 zeigt ein Verarbeitungs- und Signalisierungsdiagramm zum Darstellen eines ersten Beispiels des Lastverteilungsmechanismus gemäß der zweiten bevorzugten Ausführungsform. Der Mechanismus des ersten Beispiels ist dazu geeignet, zu erfassen, ob eine SIP-Anfrage, z.B. eine SIP-Invite-Nachricht, die erste Anfrage in einem Rufidentifizierungsabschnitt (Call Leg) ist. Dies wird durch Bereitstellen einer verborgenen Information im Record-Route-Kopffeld der SIP-Anfrage erreicht.
Immer wenn eine session-orientierte CSCF, z.B. die S-CSCF 40 in 1, eine SIP-Anfrage empfängt und ein Record-Route-Kopffeld einfügt (Schritt 1), fügt sie eine verborgene Anzeige in das Record-Route-Kopffeld ein (Schritt 2) und leitet die SIP-Anfrage mit der verborgenen Information zur Zieladresse weiter. Im vorliegenden Fall bedeutet "verborgen", dass die Anzeige für andere Netzwerke, z.B. Netzwerke außerhalb des Netzwerks, in dem die Anzeige gesetzt wird, bedeutungslos ist. Gegebenenfalls kann jedoch die zusätzliche Anzeige auch eine durch andere Netzwerke lesbare standardisierte Information sein.
Dann prüft, immer wenn eine Invite-Nachricht ankommt, eine session-orientierte CSCF, ob das oberste Route-Kopffeld oder die Anfrage-URI (falls kein Route-Kopffeld vorhanden ist) derartige verborgene Information enthält. Das Route-Kopfeld wird vom Record-Route-Kopffeld konstruiert. Wenn die verborgene Information oder Anzeige vorhanden ist, existiert die Session bereits. Andernfalls muss in der betreffenden session-orientierten CSCF intern eine neue Session erzeugt werden.
Weil SIP-Antworten (z.B. 200OK) im Normalfall einer existierenden Session zugeordnet sind, müssen sie nicht unterschieden werden.
Die Anzeige kann Teil des Host-Namens sein. Beispielsweise könnte, wenn vorausgesetzt wird, dass die Default-Routing-Adresse dieses Elements <scscf17.operator.net> ist, z.B. <B@provider.net; maddr=scscf17.operator.net>, das Record-Route-Kopffeld folgendermaßen aussehen:
Record-Route: <B@provider.net; maddr=exist.scscf17.operator.net>
oder
Record-Route: <B@exist.provider.net>
oder
Record-Route: <B@exist.scscf17.operator.net>
Hierbei wäre die verborgene Anzeige "exist" Teil des Host-Namens. Der Benutzerteil 120 kann in diesen Beispielen leer sein. Beispielsweise kann an Stelle von <B@exist.scscf17.operator.net> der Ausdruck <exist.scscf17.operator.net> verwendet werden. Das Route-Kopffeld wird vom Record-Route-Kopffeld konstruiert. Beispielsweise wird durch:
Record-Route: <B@exist.scscf17.operator.net>
Route: <B@exist.scscf17.operator.net>
erhalten.
Alternativ kann die S-CSCF 40 dem Record-Route-Kopffeld einen gemäß dem Standard RFC3261 definierten Parameter "rr-param" hinzufügen:

Record-Route: = "Record-Route" HCOLON rec-route*(COMMA rec-route)
rec-route: = name-addr*(SEMI rr-param)
rr-param: = generic-param
generic-param: = token[EQUAL gen-value]
gen-value: = token/host/quoted-string
token: = 1*(alphanum/"-"/"."/"!"/"%"/"*"/"_"/"+"/"'"/"''"/"~")
Route: = "Route" HCOLON route-param *(COMMA route-param)
route-param: = name-addr *(SEMI rr-param)

Ein entsprechendes Beispiel könnte folgendermaßen aussehen:
Record-Route: <B@provider.net; maddr=scscf17.operator.net; existing>
oder
Record-Route: <B@provider.net; existing>
oder
Record-Route: <B@scscf17.operator.net; existing>
Wiederum kann der Benutzerteil 120 leer sein. Das Route-Kopffeld wird vom Record-Route-Kopffeld konstruiert.
Wenn der Parameter rr-param "existing" empfangen wird, kann leicht erfasst werden, dass die Anfrage einer existierenden Session zugeordnet ist.
Gemäß einer weiteren Alternative können für die erste und die nachfolgenden Anfragen verschiedene Port-Nummern verwendet werden. Beispielsweise wird vorausgesetzt, dass die Default-Routing-Adresse des betreffenden Elements oder Knotens <B@provider.net; maddr=scscf17.operator.net> lautet. In diesem Fall könnte die Route-Record-Eintragung folgendermaßen aussehen.
Record-Route: <B@provider.net; maddr=scscf17.operator.net:19373>
oder
Record-Route: <B@provider.net:19373>
oder
Record-Route: <B@scscf17.operator.net;19373>
Auch hier kann der Benutzerteil 120 leer sein. Das Router-Kopffeld wird vom Record-Route-Kopffeld konstruiert. Beispielsweise wird durch
Record-Route: <B@provider.net; maddr=scscf17.operator.net:19373>
Route: <B@provider.net; maddr=scscf17.operator.net:19373>
erhalten.
Alle am Port 19373 ankommenden Anfragen werden als einer existierenden Session zugeordnet erkannt.
Gemäß einer anderen Alternative kann im SIP ein neues, anwendereigenes oder nicht-standardisiertes Erweiterungskopffeld zum Übertragen der Information verwendet werden. Ein Beispiel einer neuen Kopfeintragung kann folgendermaßen aussehen:
CSCF-session: existing in scscf17.operator.net
In diesem Fall müsste das Benutzerendgerät jedoch diese Merkmal unterstützen, d.h. dazu geeignet sein, dieses neue Kopffeld von den SIP-Anfragen in die SIP-Antworten und nachfolgende SIP-Anfragen zu kopieren.
Gemäß einer noch anderen Alternative könnte der Payload-Abschnitt der SIP-Anfrage zum Übertragen der verborgenen Anzeige verwendet werden.
6 zeigt ein schematisches Ablaufdiagramm zum Darstellen des ersten Beispiels des Lastverteilungsmechanismus. Wenn eine Anfangsanfrage durch ein Element gehandhabt wird, kann der Record-Route-Kopf in die Anfrage eingefügt werden, bevor sie versendet wird. Diesem Record-Route-Kopf kann eine verborgene Information hinzugefügt werden. Später werden diese Record-Route-Köpfe in der Antwort an den Absender der Anfrage zurückgesendet. Wenn der Absender diese Antwort empfängt, erhält er diese Record-Route-Köpfe und kopiert sie in die Route-Liste. Wenn der Absender nachfolgende Anfragen überträgt, nimmt er auf diese Route-Liste Bezug und fügt alle Eintragungen als Route-Köpfe in die nachfolgende Anfrage ein. Nun kann die nachfolgende Anfrage übertragen werden. Wenn der nächste Server diese Anfrage empfängt, kann er vom Route-Kopf die gleiche SIP-URI finden, die er früher in die Anfangsanfrage eingefügt hat. Außerdem wird ein Via-Kopf in die Anfrage eingefügt. Der gleiche Via-Kopf wird in Antwort auf die Anfrage empfangen, und verborgene Information im Via-Kopf kann verwendet werden, um die Stelle oder das Element zu finden, zu der/dem die Antwort weitergeleitet werden muss.
Daher wird gemäß 6, wenn eine SIP-Anfrage empfangen wird, das Route-Kopffeld oder ein neues Kopffeld oder ein Payload-Abschnitt hinsichtlich der verborgenen Anzeige geprüft (Schritt S201). Wenn in Schritt S202 eine verborgene Anzeige erfasst wird, existiert bereits eine Session, so dass keine Session erzeugt werden muss, und die Anfrage kann dem Rufidentifizierungsabschnitt (Call Leg) der existierenden Session zugewiesen werden (Schritt S204). Wenn dagegen keine verborgene Anzeige erfasst wird, wird in Schritt S203 eine neue Session erzeugt.
Gemäß dem zweiten Beispiel des Lastverteilungsmechanismus wird basierend auf der verborgenen Anzeige eine interne Session-Identifizierung (ISId) erfasst. Diese Alternative weist den vorstehenden Mechanismus des ersten Beispiels auf, d.h., es wird angenommen, dass, wenn die ISId nicht erfasst werden kann, die Anfrage einem neuen Rufidentifizierungsabschnitt (Call Leg) zugeordnet ist.
Im zweiten Beispiel wird eine verborgene Anzeige beispielsweise im Record-Route-Kopffeld und im Via-Kopffeld der SIP-Anfrage bereitgestellt.
Daher wird gemäß 5, immer wenn eine session-orientierte CSCF, z.B. die S-CSCF 40, ein Record-Route- oder Via-Kopffeld einfügt, die CSCF eine verborgene Anzeige einfügen, die Information über die interne Session-Identifizierung (ISId) enthält.
7 zeigt ein schematisches Ablaufdiagramm zum Darstellen des erweiterten Lastverteilungsmechanismus gemäß dem zweiten Beispiel. Immer wenn eine Nachricht ankommt, wird geprüft, ob die Nachricht einer SIP-Anfrage entspricht (Schritt S301). Wenn dies der Fall ist, prüft die session-orientierte CSCF in Schritt S303, ob das oberste Route-Kopffeld eine verborgene Anzeige enthält. Wenn in Schritt S305 bestimmt wird, dass die verborgene Anzeige vorhanden ist, existiert die Session, und die ISId kann extrahiert werden, so dass eine schnelle Session-Erkennungs- und Zuweisungsfunktion bereitgestellt wird (Schritt S307). Wenn festgestellt wird, dass die verborgene Anzeige nicht vorhanden ist, muss in Schritt S306 eine neue Session erzeugt werden.
Wenn in Schritt S301 eine SIP-Anfrage erfasst wird, wird in Schritt S302 geprüft, ob die Nachricht einer SIP-Antwort entspricht. Wenn dies der Fall ist, prüft die session-orientierte CSCF in Schritt S304, ob das oberste Via-Kopffeld eine verborgene Anzeige enthält. Wenn in Schritt S305 bestimmt wird, dass die verborgene Anzeige vorhanden ist, extrahiert die session-orientierte CSCF die ISId vom obersten Via-Kopffeld der SIP-Antwort (Schritt S307).
Daher kann an den CSCFs eine existierende Session schnell identifiziert werden.
Ähnlich wie im ersten Beispiel kann die verborgene Anzeige Teil des Host-Namens sein. Beispielsweise wird vorausgesetzt, dass die Default-Routing-Adresse dieses Elements durch <scscf17.operator.net> dargestellt wird, z.B. durch <B@provider.net; madsr=scscf17.operator.net>. Dann könnte das Route-Kopffeld folgendermaßen aussehen. Das Route-Kopffeld wird vom Record-Route-Kopffeld konstruiert.
Route: <B@provider.net; maddr=ISId224497.scscf17.operator.net>
oder
Route: <B@ISId224497.provider.net>
oder
Route: <B@ISId224497.scscf17.operator.net>
Hierbei ist die ISId "224497" Teil des Host-Namens. Der Benutzerteil 120 kann leer sein.
Ähnlicherweise könnte das Via-Kopffeld verwendet werden, das dann folgendermaßen aussehen könnte:
Via: SIP/2.0/UDP ISId224497.scscf17.operator.net:5060
Alle SIP-Antworten, die "ISId224497" als Teil des Host-Namens aufweisen, sind der gleichen existierenden Session zugeordnet.
Optional könnte die ISId als Teil des Host-Namens für Verbergungs- oder Redundanzzwecke auch verschlüsselt/tokenisiert sein.
Alternativ kann die S-CSCF 40 dem Record-Route-Kopffeld einen gemäß dem Standard RFC3261 definierten Parameter "rr-param" hinzufügen.
Dies trifft ähnlicherweise auch für SIP-Antworten zu, in denen das Via-Kopffeld durch eine gemäß dem Standard RFC3261 definierte "Via-Erweiterung" erweitert würde:

Via: = ("Via"/"v") HCOLON via-parm *(COMMA via-parm)
via-parm: = sent-protocol LWS sent-by *(SEMI via-params)
via-params: = via-ttl/via-maddr/via-received/via-branch/via-extension
via-ttl: = "ttl" EQAL ttl
via-maddr: = "maddr" EQUAL host
via-received: = "received" EQUAL (IPv4address/IPv6address)
via-branch: = "branch" EQUAL token
via-extension: = generic-param
sent-protocol: = protocol-name SLASH protocol-Version SLASH transport
protocol-name: = "SIP"/token
protocol-version: = token
transport: = "UDP"/"TCP"/"TLS"/"SCTP"/other-transport
sent-by: = host[COLON Port]
ttl: = 1*3DIGIT; 0 bis 255
generic-param: = token[EQUAL gen-value]
gen-value: = token/host/quoted-string
token: = 1*(alphanum/"-"/"."/"!"/"%"/"*"/"_"/"+"/"'"/"''"/"~")

Beispielsweise könnte das Route-Kopffeld dann folgendermaßen aussehen. Das Route-Kopffeld wird vom Record-Route-Kopffeld konstruiert.
Route: <B@provider.net; maddr=scscf17.operator.net; ISId224497.>
oder
Route: <B@.provider.net;ISId224497>
oder
Route: <B@.scscf17.operator.net;ISId224497>
Hierbei ist die ISId "224497" ein Parameter des Route-Kopffeldes.
Das entsprechende Via-Kopffeld könnte dann folgendermaßen aussehen:
Via: SIP/2.0/UDP scscf17.operator.net:5060; ISId224497.
In diesem Fall sind alle SIP-Antworten, die den Parameter "ISId=224497" enthalten, der gleichen existierenden Sitzung zugeordnet.
Optional könnte die ISId als Teil des Host-Namens für Verbergungs- oder Redundanzzwecke auch verschlüsselt/tokenisiert sein.
Daher können gemäß einer weiteren Alternative für alle existierenden Sessions verschiedene Port-Nummern verwendet werden.
Wenn beispielsweise vorausgesetzt wird, dass die Default-Routing-Adresse des betreffenden Elements <B@provider.net; maddr=scscf17.operator.net> ist, könnte das Route-Kopffeld folgendermaßen aussehen. Das Route-Kopffeld wird vom Record-Route-Kopffeld konstruiert.
Route: <B@provider.net; maddr=scscf17.operator.net: 224497>
oder
Route: <B@provider.net:224497>
oder
Route: <B@scscf17.operator.net:224497>
Der Benutzerteil kann leer sein. Alle SIP-Anfragen, die beispielsweise am Port 224497 ankommen, sind dann der gleichen existierenden Session zugeordnet.
Dies trifft ähnlicherweise auch auf das Via-Kopffeld zu, das folgendermaßen aussehen könnte:
Via: SIP/2.0/UDP scscf17.operator.net: 224497
Hierbei sind alle am Port 224497 ankommenden SIP-Antworten der gleichen existierenden Session zugeordnet.
Das parallele Überwachen vieler Ports könnte jedoch zu Problemen hinsichtlich der Leistungsfähigkeit oder der Skalierbarkeit führen.
Als andere Alternative kann im SIP ein neues, anwendereigenes Erweiterungskopffeld zum Übertragen verborgener Information verwendet werden. Beispielsweise kann das neue Erweiterungskopffeld folgendermaßen aussehen:
CSCF-session: "ISId=224497 in scscf17.operator.net"
Wie in Verbindung mit dem ersten Beispiel bereits erwähnt wurde, müsste der Benutzeragent (UA) dieses Merkmal unterstützen, d.h., er müsste dazu geeignet sein, dieses neue Kopffeld von den SIP-Anfragen in SIP-Antworten und nachfolgende SIP-Anfragen zu kopieren.
Als weitere Alternative könnte auch der Payload-Abschnitt der SIP-Anfrage oder Antwort für diesen Zweck verwendet werden.
Die vorstehend beschriebenen Lastverteilungsmechanismen werden im Wesentlichen in CSCFs oder in anderen Netzwerkknoten mit einer entsprechenden Funktionalität bereitgestellt. Sie können jedoch im Allgemeinen auch in Endgeräten, z.B. im Benutzerendgerät (UE) 10 implementiert werden.
Die vorliegende Erfindung ist nicht auf die vorstehend beschriebenen bevorzugten Ausführungsformen beschränkt. Die vorliegende Erfindung kann in einem beliebigen Netzwerkknoten mit einer Laststeuerungsfunktionalität in einem beliebigen Netzwerk implementiert werden. Insbesondere kann ein beliebiges Kopf- oder Payload-Feld einer beliebigen Paketdatennachricht oder eines Datagramms verwendet werden. Außerdem kann beliebige Information übertragen werden, die für eine Laststeuerung verwendbar ist. Daher können innerhalb des durch die beigefügten Patentansprüche definierten Schutzumfangs der Erfindung Änderungen in den Ausführungsformen vorgenommen werden.

Claims

Verfahren zum Steuern der Verarbeitungslast in einem Paketdatennetzwerk, wobei das Verfahren die Schritte umfasst: a) Einstellen einer Laststeuerinformation in einem vorbestimmten Feld (121 bis 12n) einer Nachricht; b) Leiten der Nachricht in dem Paketdatennetzwerk; c) Prüfen der Laststeuerinformation auf dem Leitweg der Nachricht; und d) Auswählen einer Verarbeitungsressource des Paketdatennetzwerks in Antwort auf das Ergebnis des Prüfschritts.
Verfahren nach Anspruch 1, wobei das vorbestimmte Feld ein Unterfeld (121 bis 12n) eines Nutzerteils (120) eines Adresskopfs (100) ist.
Verfahren nach Anspruch 1, wobei das vorbestimmte Feld ein Via-Zweig einer SIP-Nachricht ist.
Verfahren nach Anspruch 3, des weiteren umfassend den Schritt des Kopierens der Laststeuerinformation von einem anderen vorbestimmten Feld in das vorbestimmte Feld.
Verfahren nach Anspruch 2, wobei der Adresskopf eine URI (100) eines SIP-Route-Kopfes ist.
Verfahren nach Anspruch 2 oder 5, des weiteren umfassend den Schritt des Bereitstellens einer Vielzahl von Unterfeldern (121 bis 12n) in dem Nutzerteil (120) zum Befördern von verschiedenen Arten der Laststeuerinformation.
Verfahren nach Anspruch 6, wobei der Nutzerteil (120) interpretiert und in die Unterfelder (121 bis 12n) aufgeteilt wird.
Verfahren nach Anspruch 6, wobei zumindest eines von Struktur, Reihenfolge und Nutzung der Unterfelder (121 bis 12n) vorbestimmt ist.
Verfahren nach einem der Ansprüche 6 bis 8, wobei die Unterfelder (121 bis 12n) durch eine vorbestimmte Bit-Folge, ein Zeichen oder eine Zeichenfolge getrennt sind.
Verfahren nach Anspruch 1, wobei eine virtuelle Adresse von einer Vielzahl von Prozessorknoten gemeinsam genutzt wird.
Verfahren nach Anspruch 10, wobei der Prozessorknoten eine Gesprächszustandssteuerfunktionalität eines IP-basierten zellularen Netzwerks aufweist.
Verfahren nach einem der Ansprüche 2 bis 11, wobei die Laststeuerinformation eine erste Port-Nummer aufweist, die einen ersten Port zum Empfangen einer Anfragenachricht angibt.
Verfahren nach einem der Ansprüche 2 bis 12, wobei die Laststeuerinformation eine zweite Port-Nummer aufweist, die einen zweiten Port zum Empfangen einer Antwortnachricht angibt.
Verfahren nach Anspruch 1, wobei die Laststeuerinformation eine erste Information aufweist, die angibt, ob eine Session der Nachricht bereits existiert.
Verfahren nach Anspruch 14, wobei die Laststeuerinformation eine zweite Information umfasst, die eine Identifikation der existierenden Session angibt.
Verfahren nach Anspruch 14 oder 15, wobei die Laststeuerinformation in einem Route-Kopffeld, einem Via-Kopffeld oder einem Contact-Kopffeld einer SIP-Nachricht gespeichert wird.
Verfahren nach einem der Ansprüche 14 bis 16, wobei die Laststeuerinformation eine für andere Netzwerke bedeutungslose versteckte Information ist.
Verfahren nach einem der Ansprüche 14 bis 17, wobei die Laststeuerinformation als Teil eines Host-Namens eines Kopffelds festgelegt wird.
Verfahren nach einem der Ansprüche 14 bis 17, wobei die Laststeuerinformation als ein Parameter eines Kopffelds festgelegt wird.
Verfahren nach einem der Ansprüche 14 bis 17, wobei die Laststeuerinformation als eine Port-Nummer eines Kopffelds festgelegt wird.
Verfahren nach Anspruch 20, wobei die Port-Nummer zur Unterscheidung einer ersten Nachricht von nachfolgenden Nachrichten verwende wird.
Verfahren nach einem der Ansprüche 14 bis 17, wobei die Laststeuerinformation als ein Erweiterungskopffeld zu einem Kopffeld festgelegt wird.
Verfahren nach einem der Ansprüche 14 bis 17, wobei die Laststeuerinformation in einem Nutzlastabschnitt der Nachricht eingestellt wird.
Verfahren nach Anspruch 15, des weiteren umfassend die Schritte des Extrahierens der zweiten Information im Ansprechen auf eine Erfassung der ersten Information und Nutzens der zweiten Information für den Auswahlschritt.
Verfahren zum Verteilen einer Laststeuerinformation in einem paketvermittelten Netzwerk, mit den Schritten: a) Erzeugen einer ersten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketnetzwerks in einem ersten Netzelement (20); b) Einstellen der ersten Laststeuerinformation in ein vorbestimmtes Feld einer Nachricht; c) Leiten der Nachricht zu einem zweiten Netzelement (40); d) Speichern der ersten Laststeuerinformation in dem zweiten Netzelement; e) Erzeugen einer zweiten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketnetzwerks in dem zweiten Netzelement; f) Einstellen der zweiten Laststeuerinformation in einem vorbestimmten Feld einer zweiten Nachricht; g) Leiten der zweiten Nachricht zu dem ersten Netzelement; und h) Speichern der zweiten Laststeuerinformation an dem ersten Netzelement.
Netzwerkvorrichtung zum Steuern einer Verarbeitungslast in einem Paketdatennetzwerk, wobei die Vorrichtung (20, 40) umfasst: a) Prüfmittel zum Prüfen einer in einem vorbestimmten Feld (121 bis 12n) einer Nachricht bereitgestellten Laststeuerinformation; b) Auswahlmittel zum Auswählen einer Verarbeitungsressource für die Nachricht in Antwort auf das Prüfmittel.
Netzwerkvorrichtung nach Anspruch 26, wobei die Netzwerkvorrichtung (20, 40) eine Gesprächszustandssteuerfunktionalität eines IP-basierten zellularen Netzwerks umfasst.
Netzwerkvorrichtung nach Anspruch 26 oder 27, wobei das Auswahlmittel ausgestaltet ist zum Auswählen eines vorbestimmten Prozessorknotens, zu dem die Nachricht verteilt wird.
Netzwerkvorrichtung nach Anspruch 26 oder 27, wobei das Auswahlmittel ausgestaltet ist zum Initiieren eines Aufbaus einer neuen Session.
Netzwerkvorrichtung nach Anspruch 29, wobei die Laststeuerinformation einer erste Information umfasst, die angibt, ob eine Session der Nachricht bereits existiert.
Netzwerkvorrichtung nach Anspruch 30, wobei die Laststeuerinformation eine zweite Information zum Identifizieren der bestehenden Session umfasst.
Vorrichtung zum Übertragen einer Nachricht zu einem Paketdatennetzwerk, wobei die Vorrichtung (10, 20, 40) ausgestaltet ist, zum Einstellen einer Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketdatennetzwerks, in einem vorbestimmten Feld (121 bis 12n) der Nachricht.
Vorrichtung nach Anspruch 32, wobei die Vorrichtung eine Gesprächszustandssteuerfunktionalität eines IP-basierten zellularen Netzwerks umfasst.
Vorrichtung nach Anspruch 33, wobei die Gesprächszustandssteuerfunktionalität eine bedienende Anrufzustandsteuerfunktionalität oder eine Proxy-Anrufzustandsteuerfunktionalität ist.
Vorrichtung nach einem der Ansprüche 32 bis 34, wobei die Vorrichtung ausgestaltet ist zum Einstellen der Laststeuerinformation in einem Nutzerteil (120) einer Kopfadresse (100) der Nachricht.
Vorrichtung nach Anspruch 35, wobei die Kopfadresse eine SIR URI (100) ist.
Vorrichtung nach einem der Ansprüche 32 bis 34, wobei die Vorrichtung ausgestaltet ist zum Einstellen der Laststeuerinformation in einem Host-Namen, einem Kopfparameter, einer Port-Nummer oder einem Erweiterungskopffeld eines Kopfteils der Nachricht oder in einem Nutzlastabschnitt der Nachricht.
Vorrichtung nach Anspruch 37, wobei die Laststeuerinformation eine erste Information aufweist zum Angeben, ob eine Session der Nachricht bereits existiert.
Vorrichtung nach Anspruch 38, wobei die Laststeuerinformation eine zweite Information umfasst, die die existierende Session angibt.
System zum Steuern einer Verarbeitungslast in einem Paketdatennetzwerk, wobei das System umfasst: a) ein erstes Netzwerkelement (10, 20, 40) zum Einstellen einer Laststeuerinformation in einem vorbestimmten Feld (121 bis 12n) einer in dem Paketdatennetzwerk zu leitenden Nachricht; und b) ein zweites Netzwerkelement (20, 40) zum Prüfen der Laststeuerinformation auf dem Leitweg der Nachricht und zum Auswählen einer Verarbeitungsressource des Paketdatennetzwerks in Antwort auf das Prüfergebnis.
System zum Verteilen einer Laststeuerinformation in einem paketvermittelten Netzwerk, wobei das System umfasst: a) ein erstes Netzwerkelement (20) zum Erzeugen einer ersten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketnetzwerks und zum Einstellen der ersten Laststeuerinformation in einem vorbestimmten Feld einer Nachricht; b) ein zweites Netzwerkelement (40) zum Empfangen der Nachricht, zum Speichern der ersten Laststeuerinformation, zum Erzeugen einer zweiten Laststeuerinformation zum Auswählen von Verarbeitungsressourcen des Paketnetzwerks, zum Einstellen der zweiten Laststeuerinformation in einem vorbestimmten Feld einer zweiten Nachricht, und zum Leiten der zweiten Laststeuerinformation zu dem ersten Netzwerkelement; c) wobei das erste Netzwerkelement (20) ausgestaltet ist zum Speichern der zweiten Laststeuerinformation.
System nach Anspruch 40 oder 41, wobei das erste und zweite Netzwerkelement eine Gesprächszustandssteuerfunktionalität aufweisen.