DE102004043533B4 - Überlaststeuerung in einem IP-Kommunikationsnetz - Google Patents

Abstract

Verfahren zum Signalisieren einer Änderung des Überlaststatus mindestens eines ersteren Netzelementes (I-CSCF-2) an mindestens ein weiteres Netzelement (I-CSCF) über mindestens ein IP-Kommunikationsnetz (IMS 1, IMS 2), wobei von dem mindestens einen weiteren Netzelement (I-CSCF) an das mindestens eine erstere Netzelement (I-CSCF-2) mindestens eine Signalisierungsnachricht betreffend eine erwünschte Benachrichtigung des mindestens einen weiteren Netzelementes (I-CSCF) bei einer Änderung des Überlaststatus des mindestens einen ersteren Netzelementes (I-CSCF-2) gesendet wird und dass das mindestens eine erstere Netzelement (I-CSCF-2) bei einer Änderung des Überlaststatus dem mindestens einen weiteren Netzelement (I-CSCF) eine Benachrichtigung sendet.

Description

• Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Signalisieren einer Änderung des Überlaststatus mindestens eines ersteren Netzelementes an mindestens ein weiteres Netzelement über mindestens ein IP-Kommunikationsnetz.
• Die US-Patentschrift 2003/0142625 A1 beschreibt einen Monitor zum Überwachen von Multimedia-Diensten in Netzen. Ein Verfahren und ein System zum Reduzieren eines Staus bei Echtzeit-Daten bei einem Multimedia-Kommunikationsnetz weist einen Datenverkehr-Kontroll-Mechanismus auf. Zuerst werden vom Datenverkehr des Multimedia-Kommunikationsnetzes Informationen, die auf einen Stau im Multimedia-Kommunikationsnetz hinweisen, extrahiert. Diese Extraktion wird von Monitoren des Multimedia-Kommunikationsnetzes ausgeführt. Danach wird der Stau von einem zentralen Server, welcher Netz-Informationen von den Monitoren erhält reguliert indem die Netz-Informationen analysiert werden. Damit erfährt der zentrale Server den Stau-Status und kann Instruktionen an das Multimedia-Kommunikationsnetz geben, damit der Stau reduziert werden kann.
• In SS7-Telekommunikationsnetzen wird durch die so genannte automatische Stau-Kontrolle (Automatic Congestion Control (ACC)) eine automatische Überlaststeuerung realisiert, die es Netzelementen ermöglicht, den Verkehr zu anderen Netzelementen lastabhängig zu verteilen. Dazu meldet jedes Netzelement mittels SS7-Nachrichten während des Auslösens einer Verbindung seine aktuelle Überlaststufe zum benachbarten Netzelement. Dieses kann dann bei künftigen Verbindungsversuchen die gespeicherte Überlaststufe bei der Wegeauswahl berücksichtigen und damit die Verkehrslast gleichmäßig verteilen. Werden über einen gewissen Zeitraum keine weiteren Nachrichten empfangen, so wird die Überlaststufe automatisch nach Ablauf ei nes entsprechenden Timers herabgesetzt. In IP-Kommunikationsnetzen, insbesondere in einem SIP-Netz wie dem 3GPP IMS (IP Multimedia Subsystem) mit verschiedenen Arten von SIP-Servern gibt es dagegen kein einheitliches und standardisiertes Verfahren für eine automatische Überlaststeuerung. Das IP Multimedia Subsystem (IMS) ist u. a. in den Spezifikationen 3GPP TS 23.228 und 3GPP TS 24.229 definiert. Das IP Multimedia Subsystem (IMS) führt eine neue Technologie zur Realisierung multimedialer, mobiler Dienste ein, wie zum Beispiel Daten-, Text-, Sprach- und/oder Videodienste. Für die Kommunikation wird dabei das so genannte Session Initiation Protocol (SIP) verwendet. Das Session Initiation Protocol (Verbindungs-Initialisierungs-Protokoll) SIP ist ein textbasiertes Signalisierungsprotokoll für Internet-Konferenzen, Telefonie, Übermittlung von Präsenzinformationen eines Nutzers, Ereignisbenachrichtigung, Instant-Messaging (Nachrich tendienste) und viele weitere Einsatzgebiete. Die Entwicklung von SIP wird durch die IESG, der Internet Engineering Steering Group innerhalb von IETF geleitet. SIP hat eine zentrale Bedeutung im IP Multimedia Subsystem. Es wird überall dort benutzt, wo Nutzer eines Endgerätes lokalisiert und Sessions (Verbindungen) im System aufgebaut, kontrolliert, modifiziert und beendet werden müssen.
• Häufig wird zur Lastverteilung zum Beispiel in IP-Kommunikationsnetzen die sogenannte „round-robin" Methode eingesetzt, bei der der Verkehr gleichmäßig auf alle bekannten Server verteilt wird. Diese Methode, eingesetzt im Zusammenhang mit Server Farmen/Pools und in DNS-Servern (Domain Name System – Server) bei der Beantwortung einer DNS-Anfrage, ist einfach zu implementieren, berücksichtigt aber nicht die tatsächliche Last der einzelnen Server und erzielt daher keine optimalen Ergebnisse.
• Aufgabe der Erfindung ist es, eine effiziente Möglichkeit zur Überlaststeuerung in einem IP-Kommunikationsnetz vorzuschlagen.
• Die Aufgabe wird erfindungsgemäß jeweils durch die Gegenstände der unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
• Ein Kern der Erfindung ist darin zu sehen, dass über mindestens ein IP-Kommunikationsnetz von mindestens einem weiteren Netzelement mindestens eine Signalisierungsnachricht betreffend eine erwünschte Benachrichtigung des weiteren Netzelementes bei einer Änderung des Überlast-Status des ersteren Netzelementes an das erstere Netzelement gesendet wird. Bei einer Änderung des Überlast-Status des ersteren Netzelementes sendet das erstere Netzelement eine Benachrichtigung an das mindestens eine Netzelement, das die Benachrichtigung wünscht. Erfindungsgemäß wird für die mindestens eine Signa lisierungsnachricht und/oder für die Benachrichtigung das SIP-Protokoll (Session Initiation Protocol) verwendet.
• Zum Beispiel können zur Überlaststeuerung die vorhandenen SIP Nachrichten SUBSCRIBE und NOTIFY verwendet werden. Mittels SUBSCRIBE subskribiert sich dabei ein Netzelement bzw. Server (nicht notwendigerweise ein SIP Server) bei allen anderen Netzelementen bzw. Servern, zu denen er in einer Kommunikationsbeziehung steht. Diese Netzelemente bzw. Server können zum Beispiel in einer Liste vorkonfiguriert sein oder sich automatisch bekannt machen. Innerhalb der SUBSCRIBE-Nachricht muss das mindestens eine weitere Netzelement nun festlegen bei Eintreten welcher Ereignisse er eine Benachrichtigung des ersteren Netzelementes (eine NOTIFY Nachricht mit entsprechenden Daten) erhalten möchte. In diesem Fall subskribiert sich der Server für zum Beispiel das neu zu definierende „overload state event package" Ereignis-Paket (event package). Das erstere Netzelement, das eine solche SUBSCRIBE Nachricht erhält, merkt sich die Adresse des Senders und benachrichtigt dieses dann, falls sich an seinem Überlaststatus etwas ändert.
• Die Benachrichtigung erfolgt dabei mittels einer NOTIFY Nachricht, die im Nachrichten-Body den aktuellen Überlaststatus des Netzelementes codiert als XML Dokument enthält. Der Überlaststatus kann dabei nach verschiedenen Kriterien bestimmt werden wie zum Beispiel aus der CPU Last, der Auslastung des Speichers, der Zahl der offenen TCP/IP Sockets, usw. und wird zum Beispiel als Zahl zwischen 0 und n codiert (n könnte zum Beispiel 10 sein), wobei 0 keine Überlast bedeutet.
• Um zu vermeiden dass zu oft NOTIFY Nachrichten ausgesendet werden, könnte bei der Berechnung des Überlaststatus ein Hysteresisfaktor berücksichtigt werden bzw. es könnten Regeln aufgestellt werden, die die Art und Weise und/oder den Zeitpunkt für eine Benachrichtigung festlegen. Dabei muß dann zum Beispiel die Überlast in mehreren aufeinanderfolgenden Zeitabschnitten einen gewissen Wert überschreiten, damit eine NOTIFY-Nachricht an alle Netzelemente geschickt wird, die sich zuvor für das „overload state event package" subskribiert haben.
• Erhält ein Server eine NOTIFY Nachricht mit einem bestimmten Überlaststatus des ersteren Netzelementes, kann er diesen beim Weiterleiten von Anfragen bzw. beim Versand von Daten berücksichtigen, wobei eine Anfrage über ein Netzelement mit dem aktuell niedrigsten Überlaststatus gesendet werden könnte. Erhält ein Netzelement über einen längeren Zeitraum keine NOTIFY Nachricht von einem seiner Kommunikationspartner, kann er selbständig den Überlaststatus für diesen herabsetzen, damit sich das System nicht selbst blockiert. Auf diese Weise kann auch ein DNS-Server über den aktuellen Lastzustand seiner Kommunikationspartner informiert werden und bei einer DNS-Anfrage die IP-Adresse des Netzelementes mit der geringsten Last zurückgeben. Dazu muß nicht der vollständige SIP Stapel mit allen Nachrichten implementiert werden, sondern nur die einfach aufgebauten SUBSCRIBE und NOTIFY Nachrichten und die zugehörigen Antwortnachrichten.
• Ein Vorteil der Erfindung besteht darin, dass eine Überlaststeuerung mit bereits bestehenden Signalisierungen bzw. Signalisierungsprotokollen einfach und kosteneffektiv implementiert werden kann.
• Die Erfindung wird anhand eines in einer Figur dargestellten Ausführungsbeispiels näher erläutert. Dabei zeigen
• 1 ein Beispiel für das erfindungsgemäße Verfahren in zwei IP-Multimedia-Subsystemen,
• 2 eine vereinfachte Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens.
• 1 zeigt ein Beispiel für das erfindungsgemäße Verfahren in zwei IP Multimedia Subsystemen (IMS). Zur Überlaststeuerung werden die vorhandenen SIP Nachrichten SUBSCRIBE und NOTIFY verwendet. Diese SIP-Nachrichten sind zum Beispiel im RFC3265 (Session Initiation Protocol (SIP)-Specific Event Notification, June 2002) beschrieben. Ein SIP Server bzw. ein weiteres Netzelement I-CSCF eines IP Multimedia Subsystem IMS 1 subskribiert sich mittels der SUBSCRIBE-Nachricht (zum Beispiel eine I-CSCF(Interrogating-Call Session Control Function) oder S-CSCF (Service – Call Session Control Function (Anruf-Verbindungs-Kontroll-Funktion)) eines IP Multimedia Subsystems) für zum Beispiel ein „overload state event package" Ereignis-Paket (event package) bei ersteren Netzelementen bzw. SIP-Servern I-CSCF-2 aus einem anderen IP Multimedia Subsystem IMS 2, die sich innerhalb eines Server-Pools befinden und wird von diesen ersteren Netzelementen I-CSCF-2 benachrichtigt, sobald sich deren Überlaststatus ändert. Das mindestens eine erstere Netzelement kann selbstverständlich auch ein Proxy-Server, ein Applikationsserver oder Ähnliches sein. Diese ersteren Netzelemente bzw. Server I-CSCF-2 können zum Beispiel in einer Liste vorkonfiguriert sein oder sich automatisch bekannt machen. Innerhalb der SUBSCRIBE-Nachricht muss das mindestens eine weitere Netzelement I-CSCF nun festlegen, bei Eintreten welcher Ereignisse es eine Benachrichtigung des ersteren Netzelementes I-CSCF-2 (eine NOTIFY Nachricht mit entsprechenden Daten) erhalten möchte. Der Überlaststatus kann dabei nach verschiedenen Kriterien bestimmt werden wie zum Beispiel aus der CPU Last, der Auslastung des Speichers, der Zahl der offenen TCP/IP Sockets, usw. und wird zum Beispiel als Zahl zwischen 0 und n codiert (n könnte zum Beispiel 10 sein), wobei 0 keine Überlast bedeutet. Um zu vermeiden dass zu oft NOTIFY Nachrichten ausgesendet werden, könnte bei der Berechnung des Überlaststatus ein Hysteresisfaktor berücksichtigt werden bzw. es könnten Regeln aufgestellt werden, die die Art und Weise und/oder den Zeitpunkt für eine Benachrichtigung festlegen. Dabei muss dann zum Beispiel die Überlast in mehreren aufeinanderfolgenden Zeitabschnitten einen gewissen Wert überschreiten, damit eine NOTIFY-Nachricht an alle Netzelemente I-CSCF geschickt wird, die sich zuvor für das „overload state event package" subskribiert haben.
• Daraufhin ist es dem SIP-Server bzw. dem weiteren Netzelement I-CSCF möglich, den Verkehr zu den überlasteten Servern I-CSCF-2 aus dem Server Pool zu drosseln und diese bei neuen Anfragen prozentual nicht mehr so häufig zu berücksichtigen. Damit wird die Last stärker auf andere Server I-CSCF-2 des Server Pools verteilt. Erhält ein Netzelement über einen längeren Zeitraum keine NOTIFY Nachricht von einem seiner Kommunikationspartner, kann es selbständig den Überlaststatus für diesen herabsetzen, damit sich das System nicht selbst blockiert. Auf diese Weise kann auch ein DNS-Server über den aktuellen Lastzustand seiner Kommunikationspartner informiert werden und bei einer DNS-Anfrage die IP-Adresse des Netzelementes mit der geringsten Last zurückgeben. Dazu muß nicht der vollständige SIP-Stapel mit allen Nachrichten implementiert werden, sondern nur die einfach aufgebauten SUBSCRIBE- und NOTIFY-Nachrichten und die zugehörigen Antwortnachrichten.
• 2 zeigt eine vereinfachte Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens, wie es in 1 beschrieben ist. Die Vorrichtung besitzt eine Sendeeinheit S und eine Empfangseinheit E zur Kommunikation mit mindestens einem weiteren Netzelement I-CSCF. Eine Verarbeitungseinheit (V) des ersteren Netzelementes I-CSCF-2 empfängt mindestens eine Signalisierungsnachricht, zum Beispiel eine SIP-SUBCRIBE-Nachricht von mindestens einem weiteren Netzelement I-CSCF betreffend eine erwünschte Benachrichtigung, zum Beispiel eine SIP-NOTIFY-Nachricht, des ersteren Netzelementes I-CSCF-2 bei einer Änderung des Überlaststatus des ersteren Netzelementes. Bei einer Änderung des Überlaststatus sendet die Verarbeitungseinheit V an das weitere Netzelement I-CSCF eine entsprechende Benachrichtigung.

Claims (12)

1. Verfahren zum Signalisieren einer Änderung des Überlaststatus mindestens eines ersteren Netzelementes (I-CSCF-2) an mindestens ein weiteres Netzelement (I-CSCF) über mindestens ein IP-Kommunikationsnetz (IMS 1, IMS 2), wobei von dem mindestens einen weiteren Netzelement (I-CSCF) an das mindestens eine erstere Netzelement (I-CSCF-2) mindestens eine Signalisierungsnachricht betreffend eine erwünschte Benachrichtigung des mindestens einen weiteren Netzelementes (I-CSCF) bei einer Änderung des Überlaststatus des mindestens einen ersteren Netzelementes (I-CSCF-2) gesendet wird und dass das mindestens eine erstere Netzelement (I-CSCF-2) bei einer Änderung des Überlaststatus dem mindestens einen weiteren Netzelement (I-CSCF) eine Benachrichtigung sendet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Versand von Daten abhängig von der Benachrichtigung des mindestens einen ersteren Netzelementes (I-CSCF-2) von mindestens einem weiteren Netzelement (I-CSCF) über das IP-Kommunikationsnetz geschieht.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Signalisierungsnachricht und/oder die Benachrichtigung eine SIP-Nachricht ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Signalisierungsnachricht ein XML-Dokument betreffend die gewünschte Benachrichtigung bei einer Änderung des Überlaststatus des ersteren Netzelementes (I-CSCF-2) enthält.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass IP-Kommunikationsnetz ein IP-Multimedia-Subsystem (IMS 1, IMS 2) ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine Regel die Art und Weise und/oder den Zeitpunkt für die Benachrichtigung bei einer Änderung des Überlaststatus des ersteren Netzelementes (I-CSCF-2) festlegt.
7. Verfahren nach. einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine Regel einen von mindestens einem ersteren Netzelement (I-CSCF-2) berechneten Hysteresisfaktor berücksichtigt.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das erstere Netzelement (I-CSCF-2) und/oder das weitere Netzelement (I-CSCF) ein Anruf-Verbindungs-Kontroll-Funktions-Server (CSCF), ein Proxy-Server und/oder ein Applikationsserver ist.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Überlaststatus des ersteren Netzelementes (I-CSCF-2) anhand der CPU-Last, der Auslastung des Speichers und/oder der Zahl der offenen TCP/IP-Sockets vom ersteren Netzelement (I-CSCF-2) bestimmt wird.
10. Vorrichtung zum Signalisieren einer Änderung des Überlaststatus mindestens eines ersteren Netzelementes (I-CSCF-2) an mindestens ein weiteres Netzelement (I-CSCF) über mindestens ein IP-Kommunikationsnetz (IMS 1, IMS 2), – mit einer Sendeeinheit (S) und einer Empfangseinheit (E) zur Kommunikation mit mindestens einem weiteren Netzelement (I-CSCF), – mit einer Verarbeitungseinheit (V) des mindestens einen ersteren Netzelementes (I-CSCF-2) zum Empfangen mindestens einer Signalisierungsnachricht von mindestens einem weiteren Netzelement (I-CSCF) betreffend eine erwünschte Benachrichtigung des mindestens einen weiteren Netzelementes (I-CSCF) bei einer Änderung des Überlaststatus des mindestens einen ersteren Netzelementes (I-CSCF-2), – mit einer Verarbeitungseinheit (V) zum Senden einer Benachrichtigung bei einer Änderung des Überlaststatus an das mindestens eine weitere Netzelement (I-CSCF).
11. Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass als ersteres Netzelement (I-CSCF-2) und/oder als weiteres Netzelement (I-CSCF) ein Anruf-Status-Kontroll-Funktions-Server (CSCF), ein Proxy-Server und/oder ein Applikationsserver vorgesehen ist.
12. Vorrichtung nach Anspruch 11, dadurch gekennzeichnet, dass als IP-Kommunikationsnetz ein IP-Multimedia-Subsystem (IMS 1, IMS 2) vorgesehen ist.