DE60317503T2

DE60317503T2 - Lastausgleicher für mehrprozessorplattformen

Info

Publication number: DE60317503T2
Application number: DE60317503T
Authority: DE
Inventors: Shaoji Ni; Timo Jokiaho; Mika Panhelainen; Mikael Latvala; Vesa-Pekka Takala
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 2002-06-12
Filing date: 2003-04-29
Publication date: 2008-09-11
Anticipated expiration: 2023-04-30
Also published as: EP1512073A1; RU2005100049A; AU2003227781A1; WO2003107184A1; EP1512073B1; FI20021137A0; RU2316809C2; ATE378632T1; DE60317503D1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf die Telekommunikation. Insbesondere bezieht sich die vorliegende Erfindung auf ein neues und verbessertes Verfahren und System für den Lastausgleich für den Steuerebene-Verkehr eines Netzwerkelements, das mehrere CPU-(Zentralverarbeitungseinheiten)Knoten umfasst, die einer gemeinsamen externen IP-Adresse in einem Paketdaten-Telekommunikationsnetzwerk zugeteilt ist.
HINTERGRUND DER ERFINDUNG
Jüngste Telekommunikationsnetzwerke, z. B. Mobilkommunikationsnetzwerke haben damit begonnen, auf dem Internet Protokoll (IP) basierende Implementierungen einzuführen. Ein typisches Netzwerkelement umfasst mehrere Anwendungs-CPU-Knoten. Typischerweise wird eine externe IP-Adresse für diese CPU-Knoten verwendet, was zu einer flexiblen skalierenden Kapazitätserweiterung, zum einfachen Ausgleichen von Computerleistung für jeden CPU-Knoten und zu weniger manueller Einrichtung von Anwendungen führt.
Allerdings muss die Funktionalität eines Lastausgleichers implementiert werden, da eine externe IP-Adresse für alle Anwendungs-CPU-Knoten verwendet wird. Da die Topologie und internen IP-Adressen der CPU-Knoten nach außen versteckt sind, wird ein Lastausgleicher benötigt, um Steuerebene-Verkehr, wie Signalisierung, an die Knoten zur Verarbeitung zu leiten.
Da der Lastausgleich direkt von Protokollen und miteinbezogenen Schnittstellen abhängt und da Protokolle und Schnittstellen in Abhängigkeit von miteinbezogenen Netzwerkelementen variieren, muss der Lastausgleich typischerweise auf einer netzwerkelementspezifischen Basis implementiert werden, für die er effektiv ist.
Der allgemeine Paketfunkdienst (GPRS, engl.: General Packet Radio Service) ist ein Paketdatendienst, der konstruiert ist, um insbesondere digitale Mobilnetze zu unterstützen, die auf dem GSM-(globales System für Mobilkommunikation, engl.: Global System für Mobile Communications)Standard, UMTS-(universales Mobiltelekommunikationssystem, engl.: Universal Mobile Telecommunications System) oder GERAN-(GSM EDGE Funkzugangsnetz, engl.: GSM EDGE Radio Access Network)Systemen, als auch auf dem amerikanischen Zeitmultiplexzugangs-(TDMA, engl.: Time Division Multiple Access)System, das IS-136, basieren. Zusätzlich kann GPRS mit einem IP-Multimedia-Subsystem (IMS) verbunden sein.
Ein GPRS-fähiges Mobilkommunikationsnetzwerk umfasst auch einen bedienenden GPRS-Unterstützungsknoten (SGSN, engl: Serving GPRS Support Node) und einen Gateway-GPRS-Unterstützungsknoten (GGSN, engl. Gateway GPRS Support Node). Ein SGSN liefert typischerweise Pakete an GPRS-fähige Mobilstationen (MS) innerhalb seines Dienstbereiches. Ein GGSN wird typischerweise als eine Schnittstelle zu externen IP-Netzen verwendet, wie bspw. das Internet, GPRS-Dienste anderer Mobildienstanbieter oder Intranetzen von Unternehmen. Ein GGSN kann Routinginformation führen, die notwendig ist, um Protokolidateneinheiten (PDU) an den SGSN zu tunneln, der eine bestimmte MS bedient.
1 offenbart ein Beispiel für ein Stand der Technik GPRS-fähiges Kommunikationsnetzwerk. Das Netzwerk umfasst eine leitungsvermittelte Kernnetz-(CS CN)Domäne und eine paketvermittelte Kernnetz-(PS CN)Domäne. Die paketvermittelte Kernnetz-Domäne umfasst weiter einen SGSN und einen GGSN. Ein Heimat-Teilnehmerserver (HSS) verbindet den SGSN und das leitungsvermittelte Kernnetz miteinander. Das Netz umfasst ferner IP-Multimedia-Subsysteme, die mit dem GGSN und dem Heimat-Teilnehmerserver verbunden sind. Das Netz umfasst weiter Funkzugangsnetze (RAN), die mit dem leitungsvermittelten Kernnetz und dem paketvermittelten Kernnetz verbunden sind.
Ein GGSN verwendet verschiedene Schnittstellten mit verschiedenen Protokollen. Folglich können verschiedene Arten von Verkehr an einem GGSN gleichzeitig ankommen. Typischerweise muss der Verkehr, der zu einem GGSN gehört, an einen bestimmten Teilnehmer oder an eine Sitzung an einem bestimmten Signalisierungsknoten geliefert werden.
Folglich muss der Lastausgleich für einen GGSN, der mehrere CPU-Knoten umfasst, die einer gemeinsamen externen IP-Adresse zugeteilt sind, verschiedene Punkte behandeln. Die Last jedes Anwendungs-CPU-Knotens muss ausgeglichen werden. Ferner muss die Antwortnachricht von einem Quellnetzwerkelement an einen Zielanwendungs-CPU-Knoten weitergeleitet werden, der vorher eine Signalisierungsanfrage an das Quellnetzwerkelement gesendet hat. Ferner muss eine Reihe von nachfolgenden Signalisierungsnachrichten zur Informationsaktualisierung und -führung, die von anderen Netzwerkelementen an einen bestimmten Teilnehmer oder eine Sitzung gesendet wurden, an den Zielanwendungs-CPU-Knoten weitergeleitet werden, der den bestimmten Teilnehmer oder die Sitzung bedient.
Das Stand der Technik Dokument EP 1091602 bezieht sich auf ein dynamisches Lastausgleichsverfahren bei einem drahtlosen Kommunikationsnetzwerk, welches das erneute Kennzeichnen von aktiven und einsatzbereiten Funksteuersoftwareinstanzen miteinbezieht, um eine aktive Nachrichtenverarbeitung ohne Unterbrechung des Bedienens der Zelle zu übertragen.
Folglich besteht ein Bedarf für eine Lösung, die alle diese Punkte löst. Stand der Technik Ausgleicher können manchen dieser Punkte lösen. Allerdings gibt es kein verfügbares Verfahren, das eine Lösung für alle dies Punkte bereitstellt, die für einen GGSN erwähnt wurden, der mehrere CPU-Knoten umfasst, die einer gemeinsamen externen IP-Adresse zugeteilt sind.
KURZFASSUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft den Lastausgleich für Steuerebene-Verkehr eines Netzwerkelements, das mehrere CPU-Knoten umfasst, die einer gemeinsamen externen IP-Adresse in einem Paketdaten-(fähigen)-Telekommunikationsnetzwerk zugeteilt sind. IP-Nachrichten, die an das Netzwerkelement adressiert sind, werden empfangen und empfangene IP-Nachrichten, die GTP-C-(GPRS Tunnelprotokoll-Steuerebene)Nachrichten, enthalten, werden identifiziert. Zuerst wird ein Ziel-IP-Adresswert einer empfangen IP-Nachricht identifiziert und es wird aus dem IP-Adresswert bestimmt, ob die IP-Nachricht zu einem Steuerebene-Verkehr oder einem Benutzerebene-Verkehr gehört. Als Nächstes wird ein Protokollwert einer IP-Nachricht, die zu dem Steuerebene-Verkehr gehört, identifiziert und es wird aus dem identifizierten Protokollwert bestimmt, ob die IP-Nachricht eine UDP-(Benutzer-Datagra, mprotokoll, engl.: User Datagram Protocol)Nachricht oder eine TCP-(Übtertragungssteuerprotokoll, engl.: Transmission Control Protocol)Nachricht umfasst.
Ein Ziel-Port-Nummernwert einer IP-Nachricht, die eine TCP-Nachricht umfasst, wird identifiziert und die TCP-Nachricht wird an einen CPU-Knoten, basierend auf ihrem identifizierten Ziel-Port-Nummernwert, weitergeleitet. Es wird ein Ziel-Port- Nummernwert eine IP-Nachricht, die eine UDP-Nachricht umfasst, identifiziert und es wird aus dem identifizierten Ziel-Port-Nummernwert bestimmt, ob die UDP-Nachricht ferner eine GTP-C-Nachricht, eine GTP'-(GTP-Strich)Nachricht, eine DHCP-(Dynamische-Host-Einrichtungs-Protokoll, engl.: Dynamic Host Configuration Protocol)Nachricht oder eine RADIUS-(Entfernte-Authentifizierungs-Einwahl-Benutzerdienst, engl.: Remote Authentication Dial In User Service)Nachricht umfasst. Eine GPT'-Nachricht, eine DHCP-Nachricht oder eine RADIUS-Nachricht wird an einen CPU-Knoten, basierend auf ihren identifizierten Ziel-Port-Nummernwert, weitergeleitet.
In Übereinstimmung mit der Erfindung wird ein TEID-C-(Tunnelendpunktkennung für Steuerebene, engl.: Tunnel Endpoint Identifier for Control Plane)Wert einer GTP-C-Nachricht identifiziert. Die GTP-C-Nachricht wird an einen CPU-Knoten, basierend auf ihrem identifizierten TEID-C-Wert, weitergeleitet, wenn ihr identifizierter TEID-C-Wert nicht gleich Null ist. Allerdings wird ferner, wenn der identifizierte TEID-C-Wert der GTP-C-Nachricht gleich Null ist, eine Nachrichtentypwert der GTP-C-Nachricht identifiziert. Die GTP-C-Nachricht wird an einen CPU-Knoten unter Verwendung eines vorgegebenen Lastausgleichsverfahrens weitergeleitet, wenn ihr identifizierter Nachrichtentypwert gleich "Erzeuge-PDP-Kontext" ist. Das vorgegebene Lastausgleichsverfahren kann zum Beispiel auf einer Hash-Funktion oder einem Round-Robin-Verfahren basieren. Wenn der identifizierte Nachrichtentypwert der GTP-C-Nachricht nicht gleich "Erzeuge-PDP-Kontext" ist, wird die GTP-C-Nachricht an einen CPU-Knoten unter Verwendung eines vorgegebenen Pfad- und Fehlermanagementverfahrens weitergeleitet. Das vorgenannte PDP bezieht sich auf das Paketdatenprotokoll.
Bei einem Ausführungsbeispiel der Erfindung ist das Paketdaten-Telekommunikationsnetzwerk ein GPRS-fähiges Telekommunikationsnetzwerk, z. B. ein 3GPP-System (3. Generation Partnerschaftsprojekt, engl.: 3^rd Generation Partnership Project). Ein 3GPP-System umfasst ein Teilnehmerendgerät, ein Funkzugangsnetz und ein Kernnetz. Das Funkzugangsnetz kann das UTRAN (universale terrestrische Funkzugangsnetz, engl.: Universal Terrestrial Radio Access Network) und/oder GERAN sein. Das Kernnetz kann eine leitungsvermittelte Domäne, ein paketvermittelte Domäne und/oder ein IP-Multimedia-Subsystem umfassen.
Bei einem Ausführungsbeispiel der Erfindung ist das Netzwerkelement ein GGSN-Element.
Die vorliegende Erfindung stellt eine Lösung für verschiedene Punkte bereit, die den Lastausgleich für einen GGSN betreffen, der mehrere CPU-Knoten umfasst, die einer gemeinsamen externen IP-Adresse zugeteilt sind. Die vorliegende Erfindung macht es möglich, die Last jedes Anwendungs-CPU-Knotens auszugleichen. Ferner macht es die vorliegende Erfindung möglich, die Antwortnachricht von einem Quellnetzwerkelement an einen Zielanwendungs-CPU-Knoten, der vorher eine Signalisierungsanfrage an das Quellnetzwerkelement gesendet hat, weiterzuleiten. Ferner macht es die vorliegende Erfindung möglich, eine Reihe von nachfolgenden Signalisierungsnachrichten zur Informationsaktualisierung und -führung, die von anderen Netzwerkelementen an einen bestimmten Teilnehmer oder Sitzung gesendet wurden, an einen Zielanwendungs-CPU-Knoten weiterzuleiten, der den bestimmten Teilnehmer oder die Sitzung bedient.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die beigefügten Zeichnungen, welche beigefügt sind, um ein weiteres Verständnis der Erfindung bereitzustellen und einen Teil dieser Beschreibung zu bilden, veranschaulichen Ausführungsbeispiele der Erfindung und helfen zusammen mit der Beschreibung die Prinzipien der Erfindung zu erklären. In den Zeichnungen ist:
1 ein Blockdiagramm, das ein Stand der Technik GPRS-fähiges Kommunikationsnetzwerk veranschaulicht,
2 ein Flussdiagramm, das ein Lastausgleichsverfahren in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht, und
3 ein Blockdiagramm, das ein Lastausgleichssystem in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es wird nun detailliert auf die Ausführungsbeispiele der vorliegenden Erfindung genommen, wobei Beispiele von diesen in den beigefügten Zeichnungen veranschaulicht sind.
2 veranschaulicht ein Lastausgleichsverfahren für Steuerebene-Verkehr eines GGSN Netzwerkelements, das mehrere CPU-Knoten umfasst, die einer gemeinsamen externen IP-Adresse in einem GPRS-fähigen Telekommunikationsnetzwerk, z. B. einem 3GPP System, zugeteilt sind. IP-Nachrichten, die an das Netzwerkelement adressiert werden, werden empfangen, Phase 10. Empfangene IP-Nachrichten, die GTP-C-Nachrichten umfassen, werden identifiziert. Zuerst wird ein Ziel-IP-Adresswert einer empfangenen IP-Nachricht identifiziert und es wird aus dem identifizierten Ziel-IP-Adresswert bestimmt, ob die IP-Nachricht zum Steuerebene-Verkehr oder Benutzerebene-Verkehr gehört, Phase 11. Als Nächstes wird ein Protokollwert einer IP-Nachricht identifiziert, der zum Steuerebene-Verkehr gehört und es wird aus dem identifizierten Protokollwert bestimmt, ob die IP-Nachricht eine UDP-Nachricht oder eine TCP-Nachricht umfasst, Phase 12.
Wenn die Nachricht eine TCP-Nachricht ist, wird ihr Ziel-Port-Nummernwert identifiziert und die TCP-Nachricht wird an einen CPU-Knoten weitergeleitet, basierend auf ihrem identifizierten Ziel-Port-Nummernwert, Phase 19. Wenn die Nachricht eine UDP-Nachricht ist, wird ihr Ziel-Port-Nummernwert identifiziert und es wird aus dem identifizierten Ziel-Port-Nummernwert bestimmt, ob die UDP-Nachricht ferner eine GTP-C-Nachricht, eine GTP'-Nachricht, eine DHCP-Nachricht oder eine RADIUS-Nachricht umfasst, Phase 13. Eine GTP'-Nachricht, eine DHCP-Nachricht oder eine RADIUS-Nachricht wird an einen CPU-Knoten auf Grundlage ihres identifizierten Ziel-Port-Nummernwerts weitergeleitet, Phase 19.
Wenn die Nachricht eine GTP-C-Nachricht ist, wird ihr TEID-C-Wert identifiziert, Phase 14. Bei Phase 18 wird die GTP-C-Nachricht an einen CPU-Knoten auf Grundlage ihres identifizierten TEID-C-Werts weitergeleitet, wenn ihr identifizierter TEID-C-Wert nicht gleich Null ist. Allerdings wird ferner, wenn der identifizierte TEID-C-Wert der GTP-C-Nachricht gleich Null ist, ein Nachrichtentypwert der GTP-C-Nachricht identifiziert, Phase 15. Die GTP-C-Nachricht wird an einen CPU-Knoten durch Verwenden eines vorgegebenen Lastausgleichsverfahrens weitergeleitet, wenn ihr identifizierter Nachrichtentypwert gleich "Erzeuge-PDP-Kontext" ist, Phase 17. Wenn der identifizierte Nachrichtentypwert der GTP-C-Nachricht nicht gleich "Erzeuge-PDP-Kontext" ist, wird die GTP-C-Nachricht an einen CPU-Knoten durch Verwenden eines vorgegebenen Pfad- und Fehlermanagementverfahrens weitergeleitet, Phase 16.
3 veranschaulicht ein Lastausgleichssystem für Steuerebene-Verkehr eines GGSN-Netzwerkelements, das mehrere CPU-Knoten umfasst, die einer gemeinsamem externen IP-Adresse in einem GPRS-fähigen Telekommunikationsnetzwerk zugeteilt sind, z. B. ein 3GPP-System. Bei dem Ausführungsbeispiel der Erfindung, das in 3 offenbart ist, umfasst das Telekommunikationsnetzwerk ein SGSN-Netzwerkelement SGSN, das mit dem GGSN-Netzwerkelement GGSN durch die Gn-Schnittstelle unter Verwendung des GTP-C-Protokolls über dem UDP-Protokoll verbunden ist. Das Telekommunikationsnetzwerk umfasst ferner ein Charging-Gateway CG, das mit dem GGSN-Netzwerkelement GGSN durch eine Ga-Schnittstelle verbunden ist, die das GTP'-Protokoll über dem UDP-Protokoll verwendet. Das Telekommunikationsnetzwerk umfasst weiter ein LIG (Legal Interception Gateway), das mit dem GGSN-Netzwerkelement GGSN durch die X11-Schnittstelle verbunden ist, die eine Hersteller-abhängiges Protokoll verwendet, z. B. LAP-Protokoll (Lawful-Interception Anwendungsprotokoll) über dem TCP-Protokoll. Das Telekommunikationsnetzwerk umfasst weiter eine CSCF (Rufzustandssteuerfunktion, engl.: Call State Control Function, die manchmal auch als eine Ruf-Serversteuerfunktion bezeichnet wird, engl.: Call Server Control Function; typischerweise wird sie zum Ausführen von Rufsteuerfunktionen, Dienstvermittlungsfunktionen, Adressübersetzungsfunktionen und Sprachentschlüsselungsübertragungsfunktionen, engl.: vocoder negotiation functions, verwendet), die mit dem GGSN-Netzwerkelement GGSN durch die Go-Schnittstelle verbunden ist, die das COPS-(gemeinsamer offener Richtliniendienst, engl.: Common Open Policy Service)Protokoll über dem TCP-Protokoll verwendet. Das Telekommunikationsnetzwerk umfasst weiter ein externes IP-Netzwerk IP, das mit dem GGSN-Netzwerkelement GGSN durch die Gi-Schnittstelle verbunden ist, die das DHCP- und/oder RADIUS-Protokoll über dem UDP-Protokoll verwendet. Daher dient 3 dazu, zu veranschaulichen, wie das GGSN verschiedene Schnittstellen mit verschiedenen Protokollen verwendet. Verschiedene Arten von Verkehr können an dem GGSN gleichzeitig ankommen. Typischerweise muss der Verkehr, der zu dem GGSN gehört, an eine bestimmten Teilnehmer oder eine Sitzung an einem bestimmten Signalisierungsknoten geliefert werden.
Bei dem Ausführungsbeispiel der Erfindung, das in 3 offenbart ist, umfasst das GGSN-Netzwerkelement GGSN CPU-Knoten CPU₁, CPU₂, und CPU₃, die einer gemeinsamen externen IP-Adresse zum Empfangen von IP-Nachrichten zugeteilt sind. Das System umfasst ferner ein erstes Identifizierungsmittel ID1 zum Identifizieren empfangener IP-Nachrichten, die GTP-C-Nachrichten umfassten, ein zweites Identifizierungsmittel ID2 zum Identifizieren eines TEID-C-Wertes einer GTP-C-Nachricht, ein erste Weiterleitungsmittel FWD1 zum Weiterleiten einer GTP-C-Nachricht mit einem TEID-C-Wert, der nicht gleich Null ist, an einen CPU-Knoten auf Grundlage des TEID-C-Wertes, ein drittes Identifizierungsmittel ID3 zum weiteren Identifizieren eines Nachrichtentypwerts einer GTP-C-Nachricht mit einem TEID-C-Wert, der gleich Null ist, ein zweites Weiterleitungsmittel FWD2 zum Weiterleiten einer GTP-C-Nachricht mit einem Nachrichtentypwert, der gleich "Erzeuge-PDP-Kontext" ist, an einen CPU-Knoten unter Verwendung eines vorgegeben Lastausgleichsverfahrens, und ein drittes Weiterleitungsmittel FWD3 zum Weiterleiten einer GTP-C-Nachricht mit einem Nachrichtentypwert, der nicht gleich "Erzeuge-PDP-Knotest" ist, an einen CPU-Knoten unter Verwendung eines vorgegebenen Pfad- und Fehlermanagementverfahrens.
Das in 3 veranschaulichte System umfasst weiter ein viertes Identifizierungsmittel ID4 zum Identifizieren eines Ziel-IP-Adresswertes einer empfangenen IP-Nachricht und Bestimmen aus dem identifizierten Ziel-IP-Adresswertes, ob die IP-Nachricht zum Steuerebene-Verkehr oder Benutzerebene-Verkehr gehört, ein fünftes Identifizierungsmittel ID5 zum Identifizieren eines Protokollwerts einer IP-Nachricht, die zum Steuerebene-Verkehr gehört, und Bestimmen aus dem identifizierten Protokollwert, ob die IP-Nachricht eine UDP-Nachricht oder eine TCP-Nachricht umfasst, und ein sechstes Identifizierungsmittel ID6 zum Identifizieren eines Ziel-Port-Nummernwerts einer IP-Nachricht, die eine TCP-Nachricht umfasst, und Weiterleiten der TCP-Nachricht an einen CPU-Knoten auf Grundlage ihres identifizierten Ziel-Port-Nummernwerts.
Das in 3 veranschaulichte System umfasst ferner ein siebtes Identifizierungsmittel ID7 zum Identifizieren eines Ziel-Port-Nummernwerts einer IP-Nachricht, die eine UDP-Nachricht umfasst, und Bestimmen aus dem identifizierten Ziel-Port-Nummernwert, ob die UDP-Nachricht weiter eine GTP-C-Nachricht, eine GTP'-Nachricht, eine DHCP-Nachricht oder eine RADIUS-Nachricht umfasst, und ein achtes Identifizierungsmittel ID8 zum Weiterleiten einer GTP'-Nachricht, einer DHCP-Nachricht oder einer RADIUS-Nachricht an einen CPU-Knoten auf Grundlage ihres identifizierten Ziel-Port-Nummernwerts.
Einem Fachmann ist offensichtlich, dass mit dem Fortschreiten der Technologie die Grundidee der Erfindung auf verschiedene Arten ausgeführt werden kann. Die Erfindung und ihre Ausführungsbeispiele sind deshalb nicht auf die oben beschriebenen Beispiele eingeschränkt, sondern sie können innerhalb des Schutzbereiches der Ansprüche variieren.

Claims

Lastausgleichsverfahren für den Steuerebene-Verkehr eines Netzwerkelements (GGSN), das mehrere Zentralverarbeitungseinheiten, CPU, -Knoten (CPU₁, CPU₂, ..., CPU_N) umfasst, die einer gemeinsamen externen Internetprotokoll, IP, -Adresse zugeteilt sind, in einem Paketdaten-Telekommunikationsnetzwerk, wobei das Verfahren die Schritte umfasst: Empfangen von IP-Nachrichten, die an das Netzwerkelement adressiert sind, und Identifizieren empfangener IP-Nachrichten, die Allgemeine-Paketfunkdienst, GPRS, -Tunnelprotokoll-Steuerebene-, GTP-C, -Nachrichten umfassen, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Identifzieren einer Tunnelendpunktkennung für den Steuerebene-, TEID-C, -Wert einer GTP-C-Nachricht, in Abhängigkeit des identifizierten TEID-C-Wertes der GTP-C-Nachricht, entweder Weiterleiten der GTP-C-Nachricht an einen CPU-Knoten, basierend auf dem identifizierten TEID-C-Wert der GTP-C-Nachricht, oder Identifiziern eines Nachrichtentypwerts der GTP-C-Nachricht, und Weiterleiten einer GTP-C-Nachricht mit einem identifizierten Nachrichtentypwert, der gleich einem "Erzeuge Paketdatenprotokoll-Kontext" ist, an einen CPU-Knoten durch Verwenden eines vorgegebenen Lastausgleichsverfahrens.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Weiterleiten der GTP-C-Nachricht an einen CPU-Knoten auf der Grundlage des identifzierten TEID-C-Werts der GTP-C-Nachricht ausgeführt wird, wenn der identifizierte TEID-C-Wert nicht gleich Null ist, und das Identifzieren des Nachrichtentypwerts der GTP-C-Nachricht ausgeführt wird, wenn der identifizierte TEID-C-Werts gleich Null ist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Verfahren weiter den Schritt umfasst: Weiterleiten einer GTP-C-Nachricht mit einem identifizierten Nachrichtentypwert, der nicht gleich "Erzeuge Paketdatenprotokoll-Kontext" ist, an einen CPU-Knoten durch Verwenden eines vorgegebenen Pfad- und Fehlermanagementverfahrens.
Verfahren nach einem der Ansprüche 1, 2 oder 3, dadurch gekennzeichnet, dass der Schritt des Identifizierens empfangener IP-Nachrichten, die GTP-C-Nachrichten umfassen, weiter die Schritte umfasst: Identifizieren eines Ziel-IP-Adresswertes einer empfangenen IP-Nachricht und Bestimmen aus dem identifzierten Ziel-IP-Adresswert, ob die IP-Nachricht zu einem Steuerebene-Verkehr oder zu dem Benutzerebene-Verkehr gehört.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Identifizieren eines Portokollwerts einer IP-Nachricht, die zu dem Steuerebene-Verkehr gehört, und Bestimmen aus dem identifizierten Protkollwert, ob die IP-Nachricht eine Benutzer-Datagrammprotokoll, UDP, -Nachricht oder eine Übertragungssteuerprotokoll-, TCP, -Nachricht umfasst.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Identifizieren eines Ziel-Port-Nummernwerts einer IP-Nachricht, die eine TCP-Nachricht umfasst, und Weiterleiten der TCP-Nachricht an einen CPU-Knoten, basierend auf ihrem identifizierten Ziel-Port-Nummernwert.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Identifizieren eines Ziel-Port-Nummernwerts einer IP-Nachricht, die eine UDP-Nachricht umfasst, und Bestimmen aus dem identifizierten Ziel-Port-Nummernwert, ob die UDP-Nachricht weiter eine GTP-C-Nachricht umfasst, eine Allgemeine-Paket-Funkdienst-Tunnelprotokoll-Strich, GTP-C', -Nachricht, eine Dynamische-Host-Einrichtungs-Protokoll, DHCP, -Nachricht oder eine Entfernte-Authentifizierungs-Einwahl-Benutzerdienst, RADIUS, -Nachricht.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: Weiterleiten einer GTP-C-Nachricht, einer DHCP-Nachricht oder einer RADIUS-Nachricht an einen CPU-Knoten, basierend auf ihrem identifizierten Ziel-Port-Nummernwert.
Verfahren nach einem der Ansprüche 1, 2, 3, 4, 5, 6, 7 oder 8, dadurch gekennzeichnet, dass das Paketdaten-Telekommunikationsnetzwerk ein GPRS-Kommunikationsnetzwerk ist.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das Netzwerkelement ein Gateway-Allgemeiner-Paketfunkdienst-Unterstützungsknoten, GGSN, -Element ist.
Lastausgleichssystem für den Steuerebene-Verkehr eines Netzwerkelements (GGSN), das mehrere Zentralverarbeitungseinheiten, CPU, -Knoten (CPU₁, CPU₂, ..., CPU_N) umfasst, die einer gemeinsamen externen Internetprotokoll, IP, -Adresse zugeteilt sind, in einem Paketdaten-Telekommunikationsnetzwerk, wobei das Lastausgleichssystem umfasst: ein erstes Identifizierungsmittel (ID1) zum Identifizieren empfangener IP-Nachrichten, die an das Netzwerkelement adressiert sind, wobei sie Allgemeine-Paketfunkdienst-Tunnelprotokoll Steuerebene, GTP-C, -Nachrichten umfassen, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein zweites Identifizierungsmittel (ID2) zum Identifzieren einer Tunnelendpunktkennung für den Steuerebene, TEID-C, -Wert einer GTP-C-Nachricht, ein erstes Weiterleitungsmittel (FWD1) zum Weiterleiten der GTP-C-Nachricht an einen CPU-Knoten, basierend auf dem identifizierten TEID-C-Wert der GTP-C-Nachricht, ein drittes Identifizierungsmittel (ID3) zum Identifiziern eines Nachrichtentypwerts einer GTP-C-Nachricht, und ein zweites Weiterleitungsmittel (FWD2) zum Weiterleiten einer GTP-C-Nachricht mit einem identifizierten Nachrichtentypwert, der gleich einem "Erzeuge Paketdatenprotokoll-Kontext" ist, an einen CPU-Knoten durch Verwenden eines vorgegebenen Lastausgleichsverfahrens.
Lastausgleichssystem nach Anspruch 11, dadurch gekennzeichnet, dass das erste Weiterleitungsmittel in Reaktion auf den identifizierten TEDI-C-Wert, der nicht gleich Null ist, betrieben wird und, dass das dritte Identifizierungsmittel in Reaktion auf den identifizierten TEID-C Wert, der gleich Null ist, betrieben wird.
Lastausgleichssystem nach Anspruch 11 oder 11, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein drittes Weiterleitungsmittel (FWD3) zum Weiterleiten einer GTP-C-Nachricht mit einem identifizierten Nachrichtentypwert, der nicht gleich "Erzeuge Paketdatenprotokoll-Kontext" ist, an einen CPU-Knoten, durch Verwenden eines vorgegebenen Pfad- und Fehlermanagementverfahrens.
Lastausgleichssystem nach einem der Anspruch 11, 12 oder 13, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein viertes Identifizierungsmittel (ID4) zum Identifizieren eines Ziel-IP-Adresswertes einer empfangenen IP-Nachricht und Bestimmen aus dem identifizierten Ziel-IP-Adresswert, ob die IP-Nachricht zu einem Steuerebene-Verkehr oder Benutzerebene-Verkehr gehört.
Lastausgleichsmittel nach Anspruch 14, dadurch gekennzeichnet, dass das Lastausgleichsmittel weiter umfasst: ein fünftes Identifizierungsmittel (ID5) zum Identifizieren eines Protokollwertes einer IP-Nachricht, die zum dem Steuerebene-Verkehr gehört, und Bestimmen aus dem identifizierten Protokollwert, ob die IP-Nachricht eine Benutzerdatagramm-Protokoll, UDP, -Nachricht oder eine Übertragungs-Steuerprotokoll, TCP, -Nachricht umfasst.
Lastausgleichssystem nach Anspruch 15, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein sechstes Identifizierungsmittel (ID6) zum Identifizieren eines Ziel-Port-Nummernwerts einer IP-Nachricht, die eine TCP-Nachricht umfasst, und Weiterleiten der TCP-Nachricht an einen CPU-Knoten, basierend auf ihrem identifizierten Ziel-Port-Nummernwert.
Lastausgleichssystem nach Anspruch 15, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein siebtes Identifizierungsmittel (ID7) zum Identifizieren eines Ziel-Port-Nummernwerts einer IP- Nachricht, die eine UDP-Nachricht umfasst, und Bestimmen aus dem identifizierten Ziel-Port-Nummernwert, ob die UDP-Nachricht weiter eine GTP-C-Nachricht umfasst, eine Allgemeine-Paket-Funkdienst-Tunnelprotokoll-Strich, GTP-C', -Nachricht, eine Dynamische-Host-Einrichtungs-Protokoll, DHCP, -Nachricht oder eine entfernte Authentifizierungs-Einwahl-Benutzerdienst, RADIUS, -Nachricht.
Lastausgleichssystem nach Anspruch 17, dadurch gekennzeichnet, dass das Lastausgleichssystem weiter umfasst: ein achtes Identifizierungsmittel (ID8) zum Weiterleiten einer GTP-C'-Nachricht, einer DHCP-Nachricht oder einer RADIUS-Nachricht an einen CPU-Knoten, basierend auf ihrem identifizierten Ziel-Port-Nummernwert.
Lastausgleichssystem nach einem der Ansprüche 11 bis 18, dadurch gekennzeichnet, dass das Lastausgleichssystem in einem Gateway-Allgemeiner-Paketfunkdienst-Unterstützungsknoten-Element (GGSN) eines GPRS-Kommunikationsnetzwerk angeordnet ist.