DE60133754T2 - Kommunikationssystem, das die drahtlose übermittlung von paketdaten unterstützt und verfahren und anordnung dazu - Google Patents

Kommunikationssystem, das die drahtlose übermittlung von paketdaten unterstützt und verfahren und anordnung dazu Download PDF

Info

Publication number
DE60133754T2
DE60133754T2 DE60133754T DE60133754T DE60133754T2 DE 60133754 T2 DE60133754 T2 DE 60133754T2 DE 60133754 T DE60133754 T DE 60133754T DE 60133754 T DE60133754 T DE 60133754T DE 60133754 T2 DE60133754 T2 DE 60133754T2
Authority
DE
Germany
Prior art keywords
fsn
nodes
functional server
rnc
packet data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60133754T
Other languages
English (en)
Other versions
DE60133754D1 (de
Inventor
Hans RÖNNEKE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Mobile Communications AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of DE60133754D1 publication Critical patent/DE60133754D1/de
Publication of DE60133754T2 publication Critical patent/DE60133754T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/12—Mobility data transfer between location registers or mobility servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0247—Traffic management, e.g. flow control or congestion control based on conditions of the access network or the infrastructure network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft drahtlose Kommunikationssysteme, welche die Übertragung von Paketdaten unterstützen und welche ein Kernnetz und eine Anzahl von Funknetzen umfassen, und insbesondere betrifft sie die Steuerung von Funknetzen, z. B. über Funknetz-Steuerungsmittel, durch Paketdaten-Unterstützungsknoten des Kernnetzes. Die Erfindung betrifft außerdem einen Paketdaten-Unterstützungsknoten in einem Kommunikationssystem, das die Übertragung von Paketdaten unterstützt, und ein Verfahren, das die Übertragung von Paketdaten unterstützt, zum Steuern in einem Kommunikationssystem von Verbindungen zwischen Benutzerstationen und/oder Verbindungen zwischen Benutzerstationen und externen Paketdatennetzen.
  • STAND DER TECHNIK
  • In Kommunikationssystemen, welche die Übertragung von Paketdaten unterstützen und eine Anzahl von Funknetzen und ein Kernnetz, z. B. ein PLMN (öffentliches Mobilfunknetz), enthalten, umfasst jedes Funknetz im Allgemeinen Funknetz-Steuerungsmittel, die einen oder mehrere Funknetz-Steuerungsknoten umfassen, die eine Anzahl von Basisstationen steuern, mit welchen Benutzerstationen verbunden oder bei welchen Benutzerstationen angemeldet werden können. Im Allgemeinen wird ein Funknetz-Steuerungsmittel oder ein Funknetz-Steuerungsknoten von einem Paketdaten-Unterstützungsknoten des Kernnetzes gesteuert. Für GPRS/UMTS wird ein solcher Paketdaten-Unterstützungsknoten als ein SGSN (Serving GPRS Support Node, Bedienender GPRS-Unterstützungsknoten) bezeichnet. Ein anderer Unterstützungsknoten in einem solchen Kommunikationssystem ist der GGSN (Gateway GPRS Support Node, Gateway-GPRS-Unterstützungsknoten), welcher die Kommunikation mit externen Paketdatennetzen abwickelt oder steuert. In gegenwärtig bekannten Systemen steuert der SGSN oder, allgemeiner, der Paketdaten-Unter stützungsknoten ein oder mehrere Funknetz-Steuerungsmittel, d. h. er ist für solche Funknetz-Steuerungsmittel verantwortlich, zum Beispiel RNC. Es ist festgelegt, welcher SGSN welche(n) RNC(s) steuert.
  • Es ist vorgeschlagen worden, einen Paketdaten-Unterstützungsknoten oder insbesondere einen SGSN in zwei "Unterknoten" aufzuteilen, nämlich einen SGSN-Server und einen anderen Unterknoten, der als Medien-Gateway (MGW) bezeichnet wird, wobei der SGSN-Serverknoten Steuerebenen-Funktionalitäten erfüllt und das Medien-Gateway Benutzerebenen-Funktionalitäten erfüllt. In einem solchen System stellen jedoch Redundanzfragen ein Problem dar, da, wenn ein SGSN (oder ein SGSN-Serverknoten) eine Fehlfunktion aufweist, ein anderer SGSN zugewiesen werden muss oder ein redundanter SGSN vorgesehen werden muss. Wenn ein Teilnehmer eine Anmeldeprozedur bei dem Netz ausführt, weist im Allgemeinen der RNC, der die Basisstation steuert, mit dem er eine Verbindung herstellt, einen in der Nähe befindlichen SGSN (oder SGSN-Server) zu, d. h. der SGSN, welcher gewählt wird, hängt im Allgemeinen von Standort des Teilnehmers ab.
  • Dies führt zu Probleme, auch was die Lastverteilung anbelangt, welche im Allgemeinen nicht auf eine zufrieden stellende Weise gehandhabt wird. Beispielsweise bewegt sich zu den Hauptverkehrszeiten eine große Anzahl von Teilnehmern in dieselbe Richtung, d. h. zum Zentrum einer Stadt hin, und da die Wahl eines SGSN-Servers standortabhängig ist, d. h. davon abhängt, bei welchem Funknetz sich der Teilnehmer angemeldet hat, besteht die Gefahr, dass die SGSN-Server in solchen Gebieten überlastet werden, während andere SGSN-Server fast überhaupt nicht benutzt werden. Zu einem späteren Zeitpunkt kann die Situation umgekehrt sein, d. h. die zuvor kaum belasteten SGSN sind dann stark belastet, während die anderen ein Menge an freier Kapazität haben. Dies bedeutet, dass die SGSNs (oder SGSN-Server) für den "ungünstigsten Fall" bemessen werden müssen. Außerdem wird, wenn sich ein Teilnehmer innerhalb des Netzes auf eine solche Weise bewegt ("roamt"), dass die nächstgelegene Basisstation von einem anderen Funknetz-Steuerungsmittel gesteuert wird als diejenige, bei der er sich angemeldet hat, und daher der SGSN, welcher für ein bestimmtes Funknetz-Steuerungsmittel verantwortlich ist, statisch konfiguriert ist, die Verantwortung für die Verbindung von einem anderen SGSN (Server) übernommen, usw. Dies bringt viel Signalisierung mit sich, z. B. mit dem Heimatkonten (HLR) des Teilnehmers, d. h. es erfordert HLR-Aktualisierungen, was eine Belastung für den HLR bedeutet, und es ist mit viel Signalisierung verbunden. Die Durchführung von Umkonfigurationen und Hinzufügung von Einrichtungen in einem solchen System bringt außerdem hohe Kosten und viel komplizierte Konfigurationsarbeit mit sich. Noch höhere Kosten werden verursacht, wenn ein solches System ausgebaut werden muss, d. h. wenn neue Server oder Server mit einer größeren Kapazität oder Server, welche nicht richtig funktionierende Server ersetzen, hinzugefügt werden müssen. Demzufolge sind die bekannten Lösungen ungünstig, was die Lastverteilung anbelangt, und außerdem ist die Redundanz von Paketdaten-Unterstützungsknoten nicht in einem ausreichenden Umfang gewährleistet, die Netzkonfigurationsarbeit ist teuer, zeitaufwendig und kompliziert. Hinzu kommt, dass Paketdaten-Unterstützungsknoten mit spezifischen Funknetz-Steuerungsmitteln verknüpft sind, was bedeutet, dass für einen "roamenden" Teilnehmer die Verantwortung für diesen Teilnehmer von einem Paketdaten-Unterstützungsknoten an andere Paketdaten-Unterstützungsknoten übertragen wird, während sich der Teilnehmer durch das Netz bewegt. Dies führt zu viel Signalisierung zwischen Paketdaten-Unterstützungsknoten und Heimatknoten des Teilnehmers, um die beteiligten Knoten (HLR-Knoten, SGSN-SGSN, SGSN-GGSN) zu aktualisieren, was eine hohe Last z. B. für den Heimatknoten verursacht und allgemein viel Signalisierung erfordert. Dieses Problem kann natürlich, vom Standpunkt eines Netzes aus gesehen, sogar noch ernster werden, wenn sich zu einem gegebenen Zeitpunkt eine Vielzahl von Teilnehmern im Wesentlichen entlang desselben Weges bewegt, vgl. Verkehr zur Hauptverkehrszeit.
  • WO 98/59505 betrifft einen Datenpaket-Funkdienst mit verbesserter Mobilitätsverwaltung. Eine spezielle Aktualisierungsnachricht, die von einem SGSN zu einem GGSN gesendet wird, liefert die Adresse eines letzten SGSN. Die Aktualisierungsnachricht kann entweder in einem Szenario der GPRS-Anmeldung gesendet werden, oder in einem Szenario der Routing-Bereich-Aktualisierung zwischen SGSN. Der GGSN antwortet auf die Aktualisierungsnachricht, indem er mitteilt, ob die Adressaktualisierung erfolgreich war.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Benötigt wird daher ein Kommunikationssystem, das die Übertragung von Paketdaten unterstützt, wobei dieses System von einer Art ist, welche ein Kernnetz mit einer Anzahl von Paketdaten-Unterstützungsknoten (und Gateway-Knoten zur Kommunikation mit externen Paketdatennetzen) und eine Anzahl von Funknetzen, die durch Funknetz-Steuerungsmittel gesteuert werden, umfasst, wobei die Belastung der Paketdaten-Unterstützungsknoten auf eine geeignete Art und Weise verteilt werden kann, oder, anders ausgedrückt, welche in der Lage ist, für eine geeignete Lastaufteilung zwischen den Paketdaten-Unterstützungsknoten zu sorgen und bei welcher die Belastung der Paketdaten-Unterstützungsknoten so unabhängig wie möglich von der Zeit wird oder wenigstens so gleichmäßig wie möglich auf die Paketdaten-Unterstützungsknoten verteilt wird.
  • Außerdem wird ein Kommunikationssystem benötigt, in welchem auf eine einfache und direkte Art und Weise für eine Redundanz von Paketdaten-Unterstützungsknoten gesorgt werden kann. Ferner wird ein System benötigt, in welchem Konfigurationsarbeit und Entwicklung von Paketdaten-Unterstüt zungsknoten so leicht und effizient wie möglich erledigt werden können, zum Beispiel im Falle von nicht ordnungsgemäß funktionierenden Knoten, der Einführung zusätzlicher Einrichtungen oder speziell der Hinzufügung von ganzen Paketdaten-Unterstützungsknoten usw. Ferner wird ein System benötigt, bei welchem Betrieb und Wartung, besonders sofern es Paketdaten-Unterstützungsknoten betrifft, auf eine kostengünstige, einfache und schnelle Art und Weise ermöglicht werden können. Ferner wird ein System benötigt, durch welches die Signalisierung im Zusammenhang mit der Steuerung eines Paketdaten-Unterstützungsknotens reduziert werden kann, ebenso wie die Belastung von Heimatknoten für Teilnehmer, die sich im Netz umherbewegen, zum Beispiel insofern, als Aktualisierungen von Heimatknoten im Zusammenhang mit solchen Teilnehmern reduziert werden können, verglichen mit bisher bekannten Systemen.
  • Daher stellt die vorliegende Erfindung ein Kommunikationssystem wie oben angegeben bereit, in welchem wenigstens einige der Paketdaten-Unterstützungsknoten aufgeteilt sind in einen funktionalen Serverknoten (Functional Server Node, FSN) und einen funktionalen Benutzer-Gateway-Knoten (User Gateway Node, UGN). Alternativ dazu wird die Funktionalität funktionaler Serverknoten, d. h. die Steuerungsebenen-Funktionalitäten, einer Anzahl von Paketdaten-Unterstützungsknoten, d. h. von funktionalen Serverknoten, in einem Pool bereitgestellt, wobei keine funktionalen Benutzer-Gateway-Knoten vorgesehen sind. Eine Anzahl von funktionalen Serverknoten ist vorgesehen, um gemeinsam wenigstens eine Anzahl von Routing-Bereichen zu steuern, die von verschiedenen Funknetz-Steuerungsmitteln bedient werden. Diese funktionalen Serverknoten sind dazu eingerichtet, einen Pool von funktionalen Serverknoten zu bilden, und jeder der funktionalen Serverknoten in diesem Pool ist in der Lage, jedes beliebige von den Funknetz-Steuerungsmitteln zu steuern.
  • Bei einer besonders vorteilhaften Implementierung sind alle funktionalen Serverknoten in einem Pool enthalten, welches für das gesamte Netz, d. h. alle Funknetze gemeinsam ist. Ein beliebiger funktionaler Serverknoten kann dann ein beliebiges Funknetz-Steuerungsmittel bedienen. Natürlich können auch zum Beispiel zwei oder mehr verschiedene Pools vorhanden sein, wobei die funktionalen Serverknoten eines Pools gewöhnlich für einen Teil des Netzes verantwortlich sind, während die restlichen Funknetz-Steuerungsmittel gewöhnlich von den funktionalen Serverknoten des anderen Pools gesteuert werden.
  • Eine Anzahl von funktionalen Serverknoten kann sich an einem ersten Serverstandort befinden, während sich andere funktionale Serverknoten desselben Pools an einem anderen Serverstandort befinden können, um zusätzlich zur Redundanz funktionaler Serverknoten auch für eine Redundanz von Serverstandorten zu sorgen, wodurch die Serverknoten-Redundanz noch weiter erhöht wird. Natürlich ist es auch nicht notwendig, einen oder zwei Standorte vorzusehen, sondern die funktionalen Server-Mittel können auf eine beliebige geeignete Art und Weise angeordnet sein. Es ist jedoch besonders vorteilhaft, mehrere funktionale Serverknoten an wenigstens einem Standort zu sammeln, oder an zwei oder mehr Standorten, falls Redundanz in einem sogar noch höheren Maße berücksichtigt wird.
  • Bei einer speziellen Implementierung umfasst das Kommunikationssystem ein PLMN (Public LAN Mobile Network, öffentliches LAN-Mobilfunknetz), welches somit ein Kernnetz und eine Anzahl von Funknetzen umfasst. Bei einer vorteilhaften Implementierung sind alle funktionalen Serverknoten in der Lage, das gesamte PLMN zu bedienen. Ein Funknetz-Steuerungsmittel kann insbesondere einen oder mehrere Funknetz-Steuerungsknoten für dieses spezielle Funknetz umfassen, welche mehrere Basisstationen steuern. Die Funknetz-Steuerungsknoten kommunizieren mit einem zugewiesenen oder gewählten funktionalen Serverknoten über ein Steuerungsebenen-Subprotokoll und mit dem Benutzer-Gateway-Knoten über ein Benutzerebenen-Subprotokoll. Dies bedeutet, dass, um die Aufteilung des Paketdaten-Unterstützungsknotens zu ermöglichen, ein Protokoll verwendet werden muss, welches zwischen dem Paketdaten-Unterstützungsknoten und dem Funknetz in ein Steuerungsebenen-Subprotokoll und ein Benutzerebenen-Subprotokoll aufgeteilt werden kann. Jedoch auch wenn kein solches Protokoll vorhanden ist, kann das erfindungsgemäße Konzept implementiert werden; dann erfolgt jedoch die gesamte Kommunikation über einen UGN, welcher die Steuerungssignalisierung an den FSN weiterleitet. Ein solches Konzept ist in der vorläufigen US-Patentanmeldung 60/152-748 beschrieben, die am 09. September 1999 von demselben Anmelder eingereicht wurde, mit dem Titel "Method, apparatus and system for enabling communication between second generation and third generation packet data networks", deren Inhalt hiermit durch Querverweis in die vorliegende Anmeldung einbezogen wird. Auf diese Anmeldung folgte eine auf ihr beruhende reguläre Patentanmeldung.
  • Insbesondere umfasst das System GPRS/UMTS, und die Paketdaten-Unterstützungsknoten sind SGSN-Knoten (bedienende GPRS-Unterstützungsknoten), welche hier in funktionale Serverknoten (und funktionale Benutzer-Gateway-Knoten) aufgeteilt sind. Die Benutzer-Gateway-Knoten umfassen, falls sie implementiert sind, insbesondere so genannte Medien-Gateways (MGW). Die Funknetze sind so genannte UTRANs, und das Funknetz-Steuerungsmittel eines solchen UTRAN umfasst ein oder mehrere RNCs. Jeder Teilnehmer- oder Benutzerstation (Teilnehmer- oder Benutzergerät) (UE oder US), welche eine Anmeldeprozedur bei dem Netz eingeleitet hat, wird ein funktionaler Serverknoten unabhängig vom Standort der Benutzerstation zugewiesen, d. h. es kann ein beliebiger funktionaler Serverknoten gewählt werden, und diese Zuweisung wird auch nicht dadurch beeinflusst, dass sich die Benutzerstation durch das Netz bewegt, wenn sie in dem Netz "roamt". Solange der Benutzer angemeldet oder verbunden ist, kann derselbe (gewählte) funktionale Serverknoten für die Steuerung verantwortlich sein, natürlich sofern sie nicht von einer Störung oder ähnlichem betroffen ist. Bei einer speziellen Implementierung wird die Zuweisung eines funktionalen Serverknotens für einen Teilnehmer oder eine Benutzerstation mindestens für ein gegebenes Zeitintervall beibehalten, oder aber so lange, wie der Teilnehmer bei dem Netz angemeldet ist.
  • Bei einer vorteilhaften Implementierung bleibt ein funktionaler Serverknoten für einen bestimmten Teilnehmer, dem der funktionale Serverknoten zugewiesen wurde, auch verantwortlich, wenn der Teilnehmer eine Abmeldeprozedur durchgeführt hat. Informationen darüber, welches der zugewiesene funktionale Serverknoten für diesen speziellen Teilnehmer war, können in Speichermitteln in dem Funknetz-Steuerungsmittel gespeichert werden, so dass, wenn der Teilnehmer erneut eine Anmeldeprozedur einleitet, derselbe funktionale Serverknoten erneut für diesen Teilnehmer verwendet werden kann. Es sind die Funknetz-Steuerungsmittel, welche für das Zuweisen eines funktionalen Serverknotens oder für das Auswählen eines funktionalen Serverknotens für einen Teilnehmer verantwortlich sind, der eine Anmeldeprozedur ausführt, um bei dem Netz angemeldet zu werden.
  • Ein Funknetz-Steuerungsmittel kann einen funktionalen Serverknoten auf unterschiedliche Weisen zuweisen oder auswählen. Bei einer Implementierung werden aufeinanderfolgenden Teilnehmern, welche sich über einen bestimmten Funknetz-Steuerungsknoten bei dem Netz anmelden/mit dem Netz verbinden, unterschiedliche funktionale Serverknoten zugewiesen, was bedeutet, dass das Funknetz-Steuerungsmittel unterschiedliche funktionale Serverknoten auswählt, um nacheinander Teilnehmer mit ihnen zu verbinden oder bei ihnen anzumelden. Dies kann ebenfalls auf verschiedene Weisen geschehen, aufeinanderfolgenden Teilnehmern können unterschiedliche funktionale Servermittel nach irgendeinem gegebenen Schema oder in irgendeiner gegebenen Reihenfolge zugewiesen werden. Es ist auch möglich, für jeden Teilnehmer ein funktionales Servermittel zufällig auszuwählen. Dann kann natürlich zwei aufeinanderfolgenden Teilnehmern derselbe funktionale Serverknoten zugewiesen werden; dies ist jedoch nicht wichtig, da es im Prinzip nicht notwendig ist, dass aufeinanderfolgenden Teilnehmern tatsächlich verschiedene funktionale Servermittel zugewiesen werden. Bei einer alternativen Implementierung werden Teilnehmern gruppenweise funktionale Servermittel zugewiesen, derart, dass zum Beispiel fünf Teilnehmern ein erstes funktionales Servermittel zugewiesen werden kann, der nächsten Gruppe von Teilnehmern ein anderes funktionales Servermittel zugewiesen werden kann usw. Dies ist keine kritische Frage, wobei die Hauptsache ist, dass die Auswahl oder Zuweisung von funktionalen Servermitteln wenigstens so lange erhalten bleibt, wie der Teilnehmer angemeldet ist, d. h. dass sie nicht von dem Standort eines Funknetz-Steuerungsmittels abhängig ist, sondern dass die Last von jedem Funknetz-Steuerungsmittel zwischen den funktionalen Servermitteln ausgeglichen werden kann, derart, dass eine gute Aufteilung der Last sowie Redundanz sichergestellt ist. Es ist ein wirksames Mittel, um eine ungleichmäßige Last in dem Netz zu handhaben, siehe die zu Beginn erwähnte Situation, wenn sich viele Teilnehmer zur gleichen Zeit in dieselbe Richtung bewegen usw., oder wenn eine große Anzahl von Teilnehmern sich zur gleichen Zeit an demselben Ort befindet usw.
  • Bei einer speziellen Implementierung weist jeder funktionale Serverknoten eine Funktionalität zum Auswählen eines funktionalen Benutzer-Gateway-Knotens für jeden Teilnehmer auf, für welchen der spezielle funktionale Serverknoten gewählt wurde. Der funktionale Serverknoten kann einen optionalen funktionalen Benutzer-Gateway-Knoten für einen Teilnehmer auswählen, oder aber ein funktionaler Serverknoten hat einen Benutzer-Gateway-Knoten zu wählen, welcher sich nahe bei dem Teilnehmer befindet, oder entsprechend einem gegebenen Schema oder Algorithmus. Auch dies kann auf eine beliebige geeignete Art und Weise geschehen. Ferner ist der funktionale Serverknoten vorteilhafterweise für das Auswählen eines Paketdaten-Gateway-Unterstützungsknotens zur Kommunikation mit externen Paketdatennetzes verantwortlich. Dies kann ebenfalls auf unterschiedliche Weisen geschehen.
  • Die Erfindung stellt außerdem einen Paketdaten-Unterstützungsknoten zur Mobilitäts- und Sitzungsverwaltung in einem Kommunikationssystem bereit, welches die Übertragung von Paketdaten unterstützt. Der Paketdaten-Unterstützungsknoten ist in einen funktionalen Serverknoten und einen Benutzer-Gateway-Knoten aufgeteilt oder umfasst wenigstens einen (separaten) funktionalen Serverknoten. Der funktionale Serverknoten ist Bestandteil eines Pools von funktionalen Serverknoten und ist, gemeinsam mit den besagten anderen funktionalen Serverknoten, in der Lage, wenigstens einen gegebenen Teil des Kommunikationssystems zu bedienen, d. h. wenigstens eine Anzahl von Routing-Bereichen oder eine Anzahl von Funknetzen, insbesondere Funknetz-Steuerungsmittel, welche eine Anzahl von verschiedenen Funknetzen steuern. Dies bedeutet, dass dieser funktionale Serverknoten für alle Funknetz-Steuerungsmittel innerhalb des gegebenen Teils des Netzes verantwortlich ist.
  • Bei einer Implementierung sind alle funktionalen Serverknoten in dem Pool für das gesamte Netz verantwortlich, was bedeutet, dass der funktionale Serverknoten selbst die Verantwortung für alle Funknetz-Steuerungsmittel mit allen anderen funktionalen Serverknoten teilt und dass er von jedem beliebigen der Funknetz-Steuerungsmittel gewählt oder zugewiesen werden kann. Der funktionale Serverknoten umfasst insbesondere Mittel zum Wählen eines Benutzer-Gateway-Knotens für einen Teilnehmer (Verbindung), welchem er als ein funktionaler Serverknoten zugewiesen worden ist, oder, anders ausgedrückt, für welchen er von dem Funknetz-Steuerungsmittel gewählt worden ist, das die den Teilnehmer bedienende Basisstation oder die Benutzerstation des Teilnehmers steuert.
  • Die Aktion des Wählens eines Benutzer-Gateway-Knotens kann auf verschiedene Weisen durchgeführt werden. Bei einer Implementierung kann ein Benutzer-Gateway-Knoten frei gewählt werden. Bei einer alternativen Ausführungsform kann die Wahl entsprechend gewissen gegebenen Anforderungen erfolgen. Bei einer speziellen Ausführungsform sollte der Benutzer-Gateway-Knoten "gewählt" werden, der dem Teilnehmer, welcher eine Anmeldeprozedur eingeleitet hat, am nächsten ist; es sind jedoch auch andere Kriterien anwendbar, und es ist beabsichtigt, dass ein beliebiges derartiges Auswahlmodell im Rahmen der vorliegenden Erfindung liegt. Bei einer speziellen Implementierung ist der Paketdaten-Unterstützungsknoten ein SGSN des GPRS/UMTS-Systems, welcher in einen funktionalen Serverknoten (SGSN-Server) und einen Benutzer-Gateway-Knoten aufgeteilt ist, wobei der Benutzer-Gateway-Knoten ein so genanntes Medien-Gateway umfasst. Insbesondere ist der funktionale Serverknoten für die Wahl eines Benutzer-Gateway-Knotens oder eines MGW verantwortlich. Bei einer Ausführungsform kann die Auswahl mehr oder weniger frei erfolgen, und bei einer alternativen Implementierung sollte der MGW "gewählt" werden, der dem Funknetz-Steuerungsmittel am nächsten ist. Es sind auch andere Auswahlprozeduren möglich.
  • Die Erfindung offenbart daher außerdem ein Verfahren in einem Kommunikationssystem, das ein Kernnetz und eine Anzahl von Funknetzen umfasst und welches die Übertragung von Paketdaten unterstützt, zum Steuern von Verbindungen zwischen Benutzerstationen (Benutzergeräten) und/oder zwischen Benutzerstationen (Benutzergeräten) und externen Paketdatennetzen, wobei Benutzerstationen mit Funknetzen verbunden sind, von denen jedes durch ein Funknetz-Steue rungsmittel gesteuert wird und wobei Paketdaten-Unterstützungsknoten zur Funknetzsteuerung vorgesehen sind. Gemäß der Erfindung ist ein Paketdaten-Unterstützungsknoten in einen funktionalen Serverknoten und einen Benutzer-Gateway-Knoten für Steuerungsebenen-Anwendungen bzw. Benutzerebenen-Anwendungen aufgeteilt. Das Verfahren beinhaltet die folgenden Schritte: Bereitstellen eines Pools von funktionalen Serverknoten; gemeinsames Steuern mindestens eines Teils des Netzes durch die funktionalen Serverknoten, derart, dass ein beliebiger funktionaler Serverknoten in dem Pool eine beliebige Verbindung steuern kann, unabhängig davon, in welchem Funknetz sich die Benutzerstation befindet.
  • Bei einer speziellen Implementierung weist das Verfahren die folgenden Schritte auf: Wählen, willkürlich oder entsprechend einem gegebenen Schema, eines funktionalen Serverknotens für einen Teilnehmer, der eine Anmeldeprozedur bei dem Netz eingeleitet hat; Beibehalten dieses funktionalen Serverknotens für diesen Teilnehmer/die Benutzerstation unabhängig davon, wo in dem Netz sich der Teilnehmer befindet. Vorteilhafterweise beinhaltet das Verfahren die Schritte: Wählen verschiedener funktionaler Serverknoten für aufeinanderfolgende Teilnehmer, die eine Netzanmeldeprozedur über ein bestimmtes Funknetz durchführen. Die Wahl des funktionalen Serverknotens wird durch das Funknetz-Steuerungsmittel vorgenommen, welches das Funknetz steuert, bei welchem sich ein Teilnehmer anmeldet. Das Verfahren beinhaltet insbesondere auch die folgenden Schritte: Wählen eines Benutzer-Gateway-Knotens von dem zugewiesenen oder gewählten funktionalen Serverknoten; Wählen eines Gateway-Unterstützungsknotens für den Zugang zu externen Paketdatennetzen ebenfalls von dem zugewiesenen funktionalen Serverknoten.
  • Daher wählt bei einer vorteilhaften Implementierung, wenn ein funktionaler Server gewählt worden ist und ein Teilneh mer eine Anmeldeprozedur ausgeführt hat, sowie während einer PDP-Kontext-Anforderungsprozedur, der funktionale Serverknoten einen Benutzer-Gateway-Knoten, was ebenfalls auf eine beliebige Art und Weise geschehen kann, jedoch bei einer vorteilhaften Implementierung wird ein Benutzer-Gateway-Knoten in der Nähe des Funknetz-Steuerungsmittels, d. h. des Teilnehmers gewählt.
  • Der funktionale Serverknoten ist auch für das Auswählen eines Gateway-Unterstützungsknotens für den Zugang zu externen Paketdatennetzen verantwortlich. Allgemein enthält jedes Funknetz-Steuerungsmittel Informationen darüber, welches die funktionalen Serverknoten sind, und zum Beispiel wird für jeden nachfolgenden Teilnehmer, der eine Verbindung mit dem Netz herstellt, ein anderes funktionales Servermittel gewählt, z. B. nach einem zyklischen Schema; dies kann jedoch auf viele verschiedene Weisen geschehen, und die Hauptsache ist, dass nicht allen Teilnehmern, die über ein bestimmtes Funknetz-Steuerungsmittel eine Verbindung herstellen oder sich anmelden, derselbe funktionale Serverknoten zugewiesen wird, und außerdem, dass ein funktionaler Serverknoten selbst dann beibehalten wird, wenn sich der Teilnehmer in dem Netz umherbewegt, und daher die Signalisierungslast verringert wird und es vermieden wird, dass der Heimatknoten oder HLR des Teilnehmers ständig aktualisiert werden muss. Bei einer Ausführungsform sind Speichermittel in dem Funknetz-Steuerungsmittel vorgesehen, um wenigstens für einen gegebenen Zeitraum Informationen darüber zu speichern, welches der zuletzt gewählte funktionale Serverknoten für einen bestimmten Teilnehmer war, der von dem Netz abgemeldet worden ist, so dass bei einer erneuten Anmeldung bei dem Netz für diesen Teilnehmer wieder derselbe funktionale Serverknoten gewählt werden kann.
  • Bei anderen Implementierungen ist die Steuerungsebenen-Funktionalität des Paketdaten-Unterstützungsknotens in einem oder mehreren Pools vorgesehen, wie oben erläutert, und es sind keine Benutzer-Gateways für Benutzerebenen-Funktionalitäten implementiert, jedoch es ist ein direkter Tunnel von Funknetz-Steuerungsmitteln zu einem Paketdaten-Gateway-Unterstützungsknoten (z. B. GGSN) vorhanden.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird im Folgenden auf eine nicht einschränkende Weise und unter Bezugnahme auf die beigefügten Zeichnungen näher beschrieben, wobei:
  • 1 schematisch ein Kommunikationssystem mit einem Pool von funktionalen Servermitteln zeigt,
  • 2 eine zu 1 ähnliche Figur ist, wobei ein Kommunikationssystem, das GPRS/UMTS umfasst, eine Anzahl funktionaler Serverknoten umfasst, die aus SGSN-Serverknoten und Benutzer-Gateway-Knoten, welche Medien-Gateways umfassen, bestehen,
  • 3 eine alternative Implementierung mit zwei Pools mit funktionalen Servermitteln zeigt,
  • 4A schematisch die Anmeldeprozedur in aufeinanderfolgenden Schritten zeigt,
  • 4B schematisch die PDP-Kontext-Aktivierungsprozedur in aufeinanderfolgenden Schritten zeigt,
  • 5A ein Flussdiagramm ist, welches schematisch einen Weg, um einen funktionalen Serverknoten von einem Funknetz-Steuerungsmittel zu wählen, und die Anmeldeprozedur zeigt,
  • 5B eine PDP-Kontext-Aktivierungsprozedur zeigt,
  • 6 ein schematisches Flussdiagramm ist, welches die Wahl eines Benutzer-Gateway-Knotens von einem funktionalen Servermittel zeigt, und
  • 7 ein Flussdiagramm ist, welches schematisch die Wahl eines Gateway-Unterstützungsknotens, GGSN, durch den funktionalen Serverknoten, SGSN Serverknoten, zeigt.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • 1 zeigt eine Möglichkeit der Implementierung der erfindungsgemäßen Idee. Es wird ein Kommunikationssystem offenbart, welches die Übertragung von Paketdaten unterstützt. Es umfasst ein Backbone-Netz mit IP-Konnektivität und eine Anzahl von Funknetzen RAN1, RAN2, ..., RAN6 (von welchen nur RAN1–RAN3 explizit in der Figur angegeben sind). Jedes Funknetz umfasst eine Anzahl von Basisstationen ES, welche von jeweiligen Funknetz-Steuerungsmitteln RNC 11, ..., RNC 16 gesteuert werden. In der Figur ist eine Benutzergeräte-Station UEA dargestellt, welche z. B. einen Computer umfasst, der mit einer Mobilstation MSA verbunden ist, welche hier mit RAN2 in Verbindung steht. Funktionalität von Paketdaten-Unterstützungsknoten wird durch funktionale Serverknoten FSN bzw. Benutzer-Gateway-Knoten UGN bereitgestellt. Daher ist eine Anzahl von zerlegten Paketdaten-Unterstützungsknoten als FSN 1–FSN 8 und UGN 21–26 vorgesehen.
  • Die funktionalen Serverknoten FSN 1, ..., FSN 8 sind in einem Pool 100 vorgesehen, und sie tragen gemeinsam die Verantwortung für die Steuerung von, hier, sämtlichen Funknetzen RAN1, ..., RAN6, was bedeutet, dass ein beliebiger FSN des Pools in der Lage ist, jedes beliebige der Funknetze zu steuern. Bei dieser Ausführungsform sind die funktionalen Serverknoten aus Gründen der Redundanz an zwei verschiedenen Standorten vorgesehen, Standort 10 bzw. Standort 20, was offenkundig vorteilhaft ist, zum Beispiel wenn ein Standort aus dem einen oder anderen Grunde zerstört wird, zum Beispiel infolge eines Brandes oder von Sabotage. Natürlich können mehr als zwei Standorte vorhanden sein, und es ist natürlich ebenso gut auch möglich, alle funktionalen Servermittel an einem einzigen Standort zu belassen. Andere Alternativen sind ebenfalls möglich. So sind bei dieser Ausführungsform FSN 1, ..., FSN 4 an Standort 10 vorgesehen, während FSN 5, ..., FSN 8 an Standort 20 vorgesehen sind. Es ist anzumerken, dass in diesem Falle sämtliche funktionalen Serverknoten in einem gemeinsamen Pool vorgesehen sind. Es ist auch möglich, über mehr als einen Pool zu verfügen, in Abhängigkeit zum Beispiel von geographischen und praktischen Erwägungen. FSN 1, ..., FSN 4 sind mit einem Router R5 verbunden, welcher wiederum mit einem Router R1 des Backbone-Netzes verbunden ist, welcher in direkter oder indirekter Kommunikation mit den anderen Routern des Backbone-Netzes steht, hier R2, R3, R4. Auf eine ähnliche Weise sind FSN 5, ..., FSN 8 mit dem Router R6 am Standort 20 verbunden, welcher wiederum direkt mit dem Router R4 des Backbone-Netzes kommuniziert. Die Router auf den Verbindungen des Backbone-Netzes können ebenso wie Router an den jeweiligen Standorten auf eine beliebige geeignete Weise angeordnet sein. Es ist auch möglich, redundante Router und Verbindungen in dem Backbone-Netz vorzusehen.
  • Es sind Paketdaten-Gateway-Unterstützungsknoten GW1, GW2, GW3 zur Verbindung mit externen Paketdatennetzen wie etwa Internet, Intranets und Unternehmens-LANs vorgesehen. Die Verbindung mit einem externen Netz kann über ein oder mehrere GWs erfolgen. Falls mehr als ein Gateway zu einem externen Netz vorhanden ist, ist bei jeder Verbindungsaktivierung eine Wahl von Gateways erforderlich. Das Heimatregister HLR und der Domänennamenserver DNS sind über den Router R4 mit Backbone-Konnektivität verbunden, doch sie können natürlich auf eine beliebige andere geeignete Weise verbunden sein.
  • Die Funknetz-Steuerungsmittel RNC 11, ..., 16 sind für das Auswählen eines funktionalen Serverknotens verantwortlich, wenn ein Teilnehmer sich mit dem Netz verbindet/bei dem Netz anmeldet. Daher ist, wenn ein Benutzergerät UEA eine Anmelde- oder Verbindungsprozedur einleitet, um über eine Basisstation von RAN2 bei dem Netz angemeldet zu werden, RNC 12, welches RAN2 steuert, für das Auswählen eines funktionalen Serverknotens FSN verantwortlich. Im Prinzip kann RNC 12 jeden beliebigen von den FSNs des Pools 100 auswählen, um den Teilnehmer des Benutzergerätes UEA zu steuern. Es wird hier angenommen, dass RNC 12 den FSN 3 wählt. Vorteilhafterweise erfolgt die Auswahl des FSN unter Berücksichtigung von Lastverteilung, FSN-Zustand usw. Die Auswahl kann auf unterschiedliche Weisen vorgenommen werden, zum Beispiel kann ein gewichtetes Round-Robin-(Weighted Round-Robin, WRR)Auswahlverfahren mit Möglichkeit der Zurückweisung angewendet werden. Dies bedeutet im Allgemeinen, dass für jede Verbindung oder Anmeldung ein anderer oder der nachfolgende FSN gewählt wird, d. h. für den nächsten Teilnehmer, der eine Verbindung herstellt, würde RNC 12 zum Beispiel FSN 4 wählen. Ein Gewichtungsfaktor bei einem WRR-Auswahlverfahren kann ein Faktor sein, welcher die Kapazität (konfigurierte Kapazität) jedes FSN-Servers berücksichtigt. Die tatsächliche Last auf dem FSN kann ebenfalls in dem Gewichtungsfaktor enthalten sein, ebenso wie andere Faktoren. Ein FSN-Server kann mit der Möglichkeit des Zurückweisens einer Anforderung durch ein RNC ausgestattet sein, und dann versucht das RNC es bei einem anderen FSN Serverknoten. Bei einer vorteilhaften Implementierung beinhaltet das Auswahlverfahren auch die Möglichkeit, in einer Zurückweisungsnachricht Informationen zurückzusenden, z. B. den Grund für die Zurückweisung, den aktuellen Lastzustand des betreffenden funktionalen Serverknotens usw. Vorteilhafterweise bewahrt jedes RNC Informa tionen über den Zustand der verschiedenen FSN-Server auf und gibt diese in den Auswahlalgorithmus ein.
  • Bei einer besonders vorteilhaften Implementierung bewahrt ein RNC Informationen darüber auf, welchen FSN-Server eine Benutzergeräte-Station zuvor verwendet hat. Diese Information kann dann vorteilhaft verwendet werden, wenn ein abgemeldeter Benutzer sich wieder anmeldet, und der FSN kann wieder verwendet werden. Auf diese Weise wird die Signalisierung verringert oder minimiert, und es besteht keine Notwendigkeit, Informationen über den alten Kontext in dem alten FSN-Server zu beschaffen. Sie kann auch verwendet werden, wenn der Träger auf dem verwendeten Kommunikationsprotokoll zeitweilig freigegeben worden ist und sie dann benötigt wird, wenn der Träger wieder eingerichtet werden soll. Die in einem RNC gespeicherten Informationen werden jedoch nur für eine gegebene Zeitdauer aufbewahrt, andernfalls müsste die Speicherkapazität unnötig hoch sein, und zu alte Informationen sind im Allgemeinen nicht von Nutzen.
  • Bei einer Ausführungsform werden in den RNCs Statistiken aufbewahrt, welche die Anzahl von Zurückweisungen oder Gründe für Zurückweisungen usw. durch verschiedene FSNs betreffen. Es ist auch möglich, solche Informationen in einem FSN oder sowohl in RNC als auch in FSN aufzubewahren. Die Informationen können verwendet werden, um anzugeben, wie groß die Kapazität ist, und um eine Kapazitätserhöhung auszulösen. Welcher FSN für einen bestimmten Teilnehmer oder eine bestimmte Benutzerstation zugewiesen oder gewählt wird, ist unabhängig davon, wo im Netz sich der Teilnehmer befindet, und es ist kein Wechsel des FSN erforderlich, wenn sich der Teilnehmer oder die Benutzerstation zu anderen Routing-Bereichen oder Funknetzen bewegt, sondern es kann derselben FSN-Server beibehalten werden. Dies bedeutet, dass keine Aktualisierung von Routing-Bereichen zwischen funktionalen Serverknoten erforderlich ist, was dann wiederum zur Folge hat, dass weniger Signalisierung als in bisher bekannten Systemen benötigt wird und keine HLR-Aktualisierungen für solche Zwecke benötigt werden. Die Kennung (P-TMSI) einer durch einen FSN zeitweilig zugewiesenen Benutzerstation (UE) (welche beim Abmelden und Ausschalten in der Benutzerstation gespeichert wird) kann verwendet werden, um den zuvor verwendeten FSN zu ermitteln, falls ein Benutzer sich zu einem anderen RNC bewegt hat. Es können unterschiedliche Methoden angewendet werden, um einen FSN in der Kennung einer Benutzerstation zu codieren, z. B. durch einige Bits, die den FSN identifizieren, usw.
  • Da alle FSN-Server im Wesentlichen dieselbe oder eine identische Konfiguration haben, werden die Betriebs- und Wartungskosten niedrig sein, viel niedriger als bei bisher bekannten Systemen, und es wird auch einfacher, mehr Kapazität hinzuzufügen, z. B. durch Hinzufügen eines neuen FSN. Die Parameter und Softwarekonfigurationen der FSNs sind vorteilhafterweise mehr oder weniger identisch. Die Hardwarekonfiguration kann natürlich unterschiedlich sein, die Kapazität kann sich unterscheiden usw.
  • Falls mehr als ein Pool vorhanden ist, welcher das Netz bedient, dann haben alle FSNs innerhalb eines Pools insbesondere identische Parameter und eine identische Softwarekonfiguration. Da stets alternative FSNs vorhanden sind, welche verwendet werden können, falls ein vollständiger Knoten ausfällt, wird eine Redundanz auf Netzebene erzielt, und die Redundanzanforderungen an den FSN sind dann nicht so streng wie die Anforderungen an Serverknoten/Paketdaten-Unterstützungsknoten in bisher bekannten Systemen. Wenn die Paketdaten-Unterstützungsknoten in zwei funktionale Knoten aufgeteilt sind, erfüllen die funktionalen Serverknoten im Allgemeinen die Steuerungsebenen-Funktionalitäten, während die Benutzer-Gateway-Knoten die Benutzerebenen-Funktionalitäten erfüllen. Dies wird unten unter Bezugnahme auf 2 näher beschrieben, welche eine Figur ist, die zu 1 ähnlich ist, jedoch speziell eine UMTS-Implementierung zeigt.
  • Bei einer vorteilhaften Ausführungsform ist, wenn ein RNC einen funktionalen Serverknoten FSN für eine Benutzerstation oder einen Teilnehmer, die bzw. der sich beim Netz anmeldet, gewählt hat, der zugewiesene oder gewählte FSN für die Wahl eines Benutzer-Gateway-Knotens verantwortlich. Insbesondere kann jeder FSN-Server innerhalb eines Pools mit jedem beliebigen Benutzer-Gateway-Knoten UGN in dem Netz (oder dem Teil, der durch den Pool gesteuert wird) kommunizieren, und jeder Benutzer-Gateway-Knoten UGN kann von jedem beliebigen funktionalen Serverknoten FSN an dem Netz des Pools verwendet werden. Gemäß einer Implementierung "wählt" der FSN den UGN, der mit dem RNC verbunden ist, mit dem er kommuniziert, d. h. durch welchen er gewählt wurde. (Es ist dann eine 1:M Beziehung zwischen Benutzer-Gateway-Knoten UGN und Funknetz-Steuerungsmittel RNC vorhanden.)
  • Bei einer alternativen Implementierung wählt ein FSN einen UGN auf eine freiere Art und Weise. Bei einer Implementierung wird ein Algorithmus angewendet, gemäß welchem der am nächsten befindliche UGN zuerst probiert wird. Es ist dann eine m:N Beziehung zwischen UGN und RNC vorhanden. Dies ist insofern vorteilhaft, als es für UGN-Redundanz sorgt. Insbesondere sollte der dem betreffenden RNC nächstgelegene UGN zuerst gewählt werden, um die Verwendung von Backbone-Kapazität zu minimieren, und falls dieser UGN nicht verfügbar ist oder falls er die Anforderung zurückweist, wird ein anderer UGN gewählt. Bei einer speziellen Implementierung kann im Falle einer Zurückweisung ein gewichteter Round-Robin-Algorithmus angewendet werden, um einen anderen UGN zu wählen. Falls ein UGN ohne Einschränkungen gewählt wird, wenigstens bis zu einem gewissen Grade, oder falls mehr als ein UGN wählbar ist, so sorgt dies für Redundanz auf einer Netzebene, sofern es funktionale Benutzer-Gateway-Knoten betrifft, und es sind dann stets andere UGN vorhanden, welche verwendet werden können, wenn ein vollständiger UGN ausfällt. Die Redundanzanforderungen an solche Knoten sind dann auch weniger streng. Es ist auch insofern vorteilhaft, als Auf- bzw. Umrüstungsarbeiten erleichtert werden, z. B. wenn ein UGN-Knoten aus dem Verkehr gezogen wird. Weiterhin könnte bei einer Implementierung eine Option darin bestehen, denselben UGN bis zu einer Deaktivierung oder Abmeldung zu verwenden.
  • Ferner ist bei einer Implementierung der gewählte funktionale Serverknoten verantwortlich für das Wählen zwischen verschiedenen Gateway-Knoten zu externen Paketdatennetzen, wie zum Beispiel dem Internet oder einem Intranet für mehrfach beheimatete (multi-homed) APNs (Access Point Name, Zugangspunktname). Gemäß verschiedenen Ausführungsformen wird der am nächsten befindliche Gateway-Knoten zuerst gewählt, oder es wird stattdessen ein bestimmter Algorithmus verwendet, wie etwa der bereits erwähnte gewichtete Round-Robin-Algorithmus. Bei einer speziellen Implementierung werden Last- und/oder Kapazitätsbetrachtungen in den Algorithmus einbezogen. Somit kann für Redundanz auf Netzebene auch insofern gesorgt werden, wie es Gateway-Knoten zu einem externen Netz betrifft. Es sind dann stets alternative Knoten vorhanden, die verwendet werden können, falls ein vollständiger Gateway-Knoten ausfällt, und die Redundanzanforderungen sind für solche Knoten weniger streng als in bekannten Systemen. Für solche Knoten ist es dann auch einfach, sie aufzurüsten, z. B. indem Knoten aus dem Verkehr gezogen werden usw.
  • 2 zeigt eine Implementierung des erfindungsgemäßen Konzepts für UMTS. Paketdaten-Unterstützungsknoten umfassen hier SGSNs (Serving GPRS Support Node, Bedienender GPRS-Unterstützungsknoten), und sie werden aufgeteilt oder zerlegt in einen SGSN-Serverknoten und ein Medien-Gateway (MGW). Unter anderen Aspekten ist diese Figur ähnlich zu 1, und es befinden sich SGSN-Serverknoten 11 , ..., 81 an zwei verschiedenen Standorten 101 , 201 , und alle sind Teil eines gemeinsamen Pools 100. In dieser Figur ist jedoch das Medien-Gateway 231 mit einem Router R9, welcher mit dem RNC 131 des Funknetzes in Verbindung steht, und mit einem Router R2 des IP-Backbone-Netzes verbunden. Auf diese Weise sind redundante MGWs implementiert. Ein entsprechender Router kann ebenso gut mit den anderen MGWs verbunden sein (siehe 3). Das Konzept der Bereitstellung redundanter Benutzer-Gateway-Knoten wurde oben eingehender beschrieben; hier ist jedoch die spezifische Implementierung eines UGN in der Form eines Medien-Gateways MGW dargestellt. Betreffs der Konzepte, Terminologie usw., welche verwendet wird, wird auf 3GTS 23.060 v3.4.0 (2000-07), Technische Spezifikation, von 3rd Generation Partnership Project (3GPPTM) verwiesen, welche hiermit durch Querverweis in die vorliegende Anmeldung einbezogen wird.
  • Im Folgenden wird die Zerlegung oder Aufteilung eines SGSN-Knotens in einen SGSN-Server und ein Medien-Gateway MGW eingehender beschrieben. Ein SGSN erfüllt normalerweise einen großen Teil der Benutzerebenen- und Steuerungsebenen-Funktionen. Wenn er aufgespaltet ist, handhabt der SGSN-Serverknoten dann sämtliche Signalisierungs-Schnittstellen (Gs, Gr, Gd usw.), ebenso wie das GTP-C Protokoll, während das MGW den Benutzerverkehr abwickelt, und insbesondere das GTP-U Protokoll. Daher wird beim Stand der Technik die Last, die von dem SGSN getragen wird, auf zwei verschiedene Netzelemente verteilt, den SGSN-Serverknoten und das MGW. Es wird jedoch eine neue Schnittstelle zwischen SGSN-Serverknoten und MGW eingeführt; dies wird eine gewisse zusätzliche Verarbeitung und Signalisierung erfordern, doch diese wird recht unbedeutend sein und nahezu vollständig durch die allgemeinen Vorteile ausgeglichen, die durch die Aufteilung bewirkt werden. Bei einer speziellen Implementierung sind die Funktionen des SGSN-Serverknotens Sit zungsverwaltung, Mobilitätsverwaltung, GTP-C Beendigung, MAP Beendigung, RANAP Beendigung, CDR-Abwicklung, Medien-Gateway-Wahl, GGSN-Wahl, Bereitstellung von abhörbezogenen (Intercept-Related) Informationen. Die oben erwähnten Protokolle, GTP-C (GTP Steuerungsebene), wobei GTP für GPRS Tunneling Protocol steht, MAP, RANAP (Radio Access Network Application Protocol), sind in 3GPP, 3G TS 23.060 v3.4.0 (2000-07) erläutert.
  • Der Medien-Gateway-Knoten beinhaltet dann die Funktionalitäten von GTP-U (GTP Benutzerebene) Beendigung, Sammeln von Nutzungsinformationen für Zwecke der Vergebührung und Netzüberwachung, Melden von Nutzungsinformationen auf Anforderung oder ereignisbedingt an den SGSN-Serverknoten oder andere Knoten, Bereitstellung von Inhalt von Kommunikation usw.
  • Der SGSN-Serverknoten kann das MGW über die Mc Schnittstelle entsprechend dem ITU-T H.248/IETF MEGACO Standard steuern, und den GGSN über die Gn Schnittstelle durch GTP-C Nachrichten. GTP-U Pakete werden zwischen dem MGW und dem GGSN über die Gn Schnittstelle und zwischen dem MGW und dem RNC über die Iu Schnittstelle entsprechend der GTP-U Spezifikation übertragen, siehe das oben erwähnte 3GPP Dokument. Durch das Aufspalten eines SGSN in einen SGSN-Serverknoten und ein MGW wird nur eine funktionale Auswirkung auf den SGSN selbst bewirkt, und RNCs, GGSNs und andere SGSNs sowie die Protokolle, welche zwischen diesen Knoten verwendet werden, werden durch die Zerlegung nicht beeinflusst. Außer der Mc Schnittstelle zwischen dem SGSN-Server und MGW werden keine anderen Schnittstellen beeinflusst. Der SGSN-Serverknoten ist ein Haupt-Steuerungsknoten für UMTS (und GPRS). Er handhabt sämtliche Signalisierungsschnittstellen eines 3GPP Release 1999 SGSN, einschließlich des GTP-C Protokolls auf den Gn und Gp Schnittstellen und des RANAP Protokolls auf der Iu Schnittstelle. Der SGSN-Server steuert das Medien-Gateway durch die Mc Schnittstelle entspre chend dem H.248 Standard. Der SGSN-Server unterstützt die Iu Schnittstelle für UMTS und, bei einer Implementierung, die Gb Schnittstelle für GPRS für GSM.
  • Das MGW erfüllt die Benutzerebenen-Funktionalität für GPRS und beendet die GTP-U Tunnel zu dem GGSN über die GN und GP Schnittstellen und zu dem RNC über die Iu Schnittstelle. Das MGW wird durch den SGSN-Server über die Mc Schnittstelle entsprechend dem H.248 Standard gesteuert. Für UMTS wird das MGW durch den SGSN-Server über die Mc Schnittstelle gesteuert, die das H.248 Protokoll mit den GPRS-spezifischen Erweiterungen unterstützt; die Iu Schnittstelle zwischen dem RNC und dem SGSN-Server unterstützt das RANAP Protokoll. Mc und RANAP gehören zu der Steuerungsebene, ebenso wie die Iu Schnittstelle zwischen dem RNC und MGW, welche das GTP-U Protokoll unterstützt. Bei UMTS unterstützt die Gn Schnittstelle zwischen dem SGSN-Serverknoten und dem GGSN das GTP-C Protokoll und gehört zur Steuerungsebene. Wie oben erwähnt, sind die Protokolle und die Terminologie in der Spezifikation 3GPP, 3G TS 23.060 zu finden, welche durch Querverweis in die vorliegende Anmeldung einbezogen wurden.
  • Das erfindungsgemäße Konzept umfasst auch eine Implementierung, bei welcher FSNs (SGSN-Server) in einem oder mehreren Pools vorgesehen sind, in welchen jedoch keine UGNs vorhanden sind, d. h. keine Knoten oder Mittel, die Benutzerebenen-Funktionalitäten erfüllen, welche für paketvermittelte Daten möglicherweise nicht erforderlich sind. Für leitungsvermittelten Verkehr werden solche Knoten aber im Allgemeinen benötigt, RNCs kommunizieren dann direkt mit FSNs.
  • 3 zeigt eine alternative Implementierung des erfindungsgemäßen Konzepts. Sie wird hier unter Bezugnahme auf UMTS erörtert, doch es dürfte klar sein, dass sie allgemein für ein beliebiges System anwendbar ist, und insbesondere ein beliebiges System, bei dem das Protokoll zwischen dem Funknetz und dem Paketdaten-Unterstützungsknoten zwischen Steuerungsebenen-Funktionalitäten und Benutzerebenen-Funktionalitäten aufgeteilt werden kann.
  • SGSN-Serverknoten sind in zwei verschiedenen Pools vorgesehen, Pool A 100 bzw. Pool B 200. Die funktionalen Serverknoten, insbesondere die SGSN-Serverknoten 1A, 2A, 3A von Pool A 100 befinden sich am Standort 10AB , während sich die funktionalen Serverknoten 4A, 5A, 6A von Pool A 100 am Standort 20AB befinden. Entsprechend befinden sich die funktionalen Serverknoten 1B, 2B, 3B von Pool B 200 am Standort 10AB , während sich die funktionalen Serverknoten 4B, 5B, 6B von Pool B 200 am Standort 20AB befinden. Funktionale Servermittel ein und desselben Pools befinden sich aus Gründen der Redundanz an unterschiedlichen Standorten, für den Fall, dass ein Standort durch Sabotage oder Brand zerstört wird oder aus einem anderen Grunde außer Betrieb ist; die RNCs 112 , 122 , 132 werden hier durch Pool A gesteuert, während die RNCs 142 , 152 , 162 durch Pool B gesteuert werden. Bei dieser Ausführungsform sind alle Medien-Gateways 212 , 222 , 232 , 242 , 252 , 262 mit Routern R7, R8, R9, R10, R11 bzw. R12 verbunden, was die Verwendung redundanter Medien-Gateways ermöglicht, wie auch unter Bezugnahme auf 2 erläutert wurde. Es ist anzumerken, dass MGW 252 sowohl mit RNC 152 als auch mit R11 verbunden ist, was eine Alternative ist, welche auch anderswo dargestellt sein könnte; natürlich könnte R11 auch wie z. B. R10 verbunden sein. In anderen Aspekten ist die Figur ähnlich zu 1, 2.
  • Es ist möglich, anstelle eines Pools an zwei Standorten (hier 1, 2) oder zwei Pools, welche zwei Standorte gemeinsam nutzen, nur einen Pool an einem Standort zu haben, wobei die Redundanz dann jedoch nicht so gut ist; oder zwei Pools an nur einem Standort, drei Pools, die zwei Standorte oder drei Standorte gemeinsam nutzen, oder irgendeine andere geeignete Konstellation. Bei einer speziel len Implementierung sind zwei oder mehr Standorte an einem Ort angeordnet, jedoch nach wie vor getrennt. Stattdessen können sich zwei Standorte auch an völlig unterschiedlichen Orten befinden.
  • Allen Ausführungsformen ist gemeinsam, dass die Anzahl von FSNs (SGSN-Servern) beliebig geändert werden kann, ohne dass sich dies auf die Netzstruktur auswirkt. Insbesondere werden, wenn sich die Anzahl der Teilnehmer erhöht, einfach mehr FSNs (SGSN-Server) hinzugefügt – es besteht keine Notwendigkeit, UGNs (MGWs), RNCs, BSs usw. hinzuzufügen, was äußerst vorteilhaft ist.
  • 4A zeigt ein Beispiel einer Anmeldeprozedur, wenn das erfindungsgemäße Konzept implementiert ist. Eine Anmeldeanforderung (Attach Request) wird von US1 zu RNC unter Verwendung des RLC (Radio Link Control) Protokolls gesendet. I bezeichnet die Prozedur der Auswahl eines SGSN-Servers, die z. B. unter Bezugnahme auf 5A näher beschrieben ist. Wenn ein SGSN-Server gewählt worden ist, wird die Anmeldeanforderung unter Verwendung des RANAP Protokolls zu dem SGSN-Server weitergesendet. Danach folgt eine Authentifizierungsprozedur, z. B. auf eine herkömmliche Weise (siehe 3G TS 23.060 V.3.4.0 (2000-07)). Die nachfolgenden Schritte betreffen die Standortaktualisierung, einschließlich der Einfügung von Teilnehmerdaten, und schließlich wird eine Quittung der Standortaktualisierung (Update Location Acknowledgement) an den ausgewählten SGSN-Server gesendet. Nach diesem Schritt wird eine neue P-TMSI (Paket-TMSI) zugewiesen, was in der Figur mit II bezeichnet ist. Dann folgt eine Anmeldebestätigung (Attach Accept) vom SGSN-Server zum RNC unter Verwendung des RANAP Protokolls. Bei Empfang der Anmeldebestätigung im RNC werden Informationen über die neue P-TMSI und den gewählten (und annehmenden) SGSN-Server im RNC gespeichert (III). Schließlich wird eine Anmeldebestätigung unter Verwendung des RLC-Protokolls an US1 gesendet.
  • 4B zeigt ein Beispiel einer PDP-Kontext-Aktivierungsprozedur, wenn das SGSN-Pool-Serverkonzept gemäß der Erfindung implementiert ist. Eine PDP-Kontext-Aktivierungsanforderung (Activate PDP Context Request) wird unter Verwendung des RLC-Protokolls von US1 an RNC gesendet. An dieser Stelle, siehe IV in 4B, wird ein Nachschlagen des SGSN-Servers durchgeführt. Dies wird unten unter Bezugnahme auf 5B näher beschrieben. Wenn die Information darüber vorhanden ist, welcher der gewählte (und annehmende) SGSN-Server ist, wird die PDP-Kontext-Aktivierungsanforderung unter Verwendung von RANAP zu dem ausgewählten (nachgeschlagenen) SGSN-Server weitergesendet. Danach wird eine MGW-Wahl durchgeführt; dies wird unter Bezugnahme auf 6 näher beschrieben. Der SGSN-Server sendet dann eine Nachricht "Kontext für Iu Tunnelendpunkt hinzufügen" (Add Context for Iu tunnel end-point) an das MGW, welches eine Nachricht "Antwort Kontext mit Iu Tunnelendpunkt hinzufügen" (Reply Add Context with Iu tunnel end-point) an den SGSN-Server zurücksendet.
  • Danach folgen eine RAB (Radio Access Bearer, Funkzugangsträger-)Anforderung vom SGSN-Server zum RNC und eine entsprechende Antwort. Anschließend sendet der SGSN eine Anforderung "Kontext Iu Tunnelendpunkt modifizieren und Kontext für Gn Tunnelendpunkt hinzufügen" an das MGW, welches eine Antwort an den SGSN-Server zurücksendet. Danach sendet der SGSN-Server eine DNS-Abfrage an den DNS (Domänennamenserver), und im Anschluss an die Antwort kann ein GGSN gewählt werden, VI. Wie dies geschehen kann, wird unten unter Bezugnahme auf 7 näher erläutert. Anschließend wird eine PDP-Kontext-Erzeugungsanforderung (Create PDP Context Request) an den ausgewählten GGSN gesendet, welcher eine Antwort an den SGSN-Server zurücksendet. Es wird eine Nachricht "Kontext modifizieren" (mit Gn Tunnelendpunkt) an das MGW gesendet, welches eine Bestätigung an den SGSN-Server sendet. Schließlich wird eine PDP-Kontext-Aktivierungsbestätigung (Activate PDP Context Accept) unter Verwendung von RANAP von dem SGSN-Server an den RNC gesendet. Eine PDP-Kontext-Aktivierungsbestätigung wird unter Verwendung des RLC Protokolls von dem RNC an US1 weitergesendet.
  • Die Reihenfolge, in welcher Tunnelendpunkte in dem MGW hinzugefügt und modifiziert werden, kann unterschiedlich sein.
  • In dem Flussdiagramm von 5A wird die Wahl eines SGSN-Serverknotens, wie sie durch eine Anmeldeanforderung ausgelöst wird, beschrieben, insbesondere im Zusammenhang mit dem UMTS-System und gemäß einer Implementierung. Zuerst wird angenommen, dass eine Anmeldeanforderung von einer Benutzerstation, hier mit US1 bezeichnet, im RNC X empfangen wird, 101. RNC X prüft in Speichermitteln, ob irgendwelche Informationen über einen unlängst verwendeten SGSN-Serverknoten für US1, im Allgemeinen den zuletzt verwendeten SGSN-Server, vorhanden sind, 102. Falls das Speichermittel solche Informationen enthält, wird die Anmeldeanforderung von dem RNC X zu dem vorhergehenden SGSN-Serverknoten weitergesendet, 103. Es wird dann festgestellt, ob der "vorhergehende" SGSN-Server die Anmeldeanforderung annimmt, 104. Falls nicht, wird eine Zurückweisungsnachricht an RNC X gesendet, 105. Bei einer bevorzugten Implementierung enthält die Nachricht Informationen darüber, warum die Anforderung zurückgewiesen wird, und über den Zustand des "vorhergehenden" SGSN-Servers. Bei einer alternativen Implementierung muss der SGSN-Server, der als "vorhergehender" SGSN-Server gespeichert ist, nicht verwendet werden, sondern es können andere SGSN-Server verwendet werden, z. B. um die Lastsituation zu berücksichtigen, selbst wenn dann mehr Signalisierung erforderlich ist. Falls eine Zurückweisung von dem SGSN-Server empfangen wird, dann wählt RNC X einen SGSN-Server aus dem Pool, der für RNC X verantwortlich ist, z. B. unter Verwendung eines Algorithmus wie etwa WRR, wobei der Zustand der SGSN-Server und mögliche Zurückweisungen berücksichtigt werden, 106. Danach wird eine Anmeldeanforderung an den ausgewählten SGSN-Server gesendet, 107. Falls die Anmeldeanforderung nicht angenommen wird, sendet der gewählte SGSN-Server eine Zurückweisungsnachricht, vorzugsweise mit Informationen über den Grund für die Zurückweisung und über den Zustand, an RNC X, 109, ähnlich zu dem oben erörterten Schritt 105. Es wird dann ein neuer SGSN-Server gewählt, und die Prozedur wird ab dem Schritt 106 wiederholt, vorzugsweise bis die Anmeldeanforderung angenommen wird.
  • Die Intelligenz für das Treffen solcher Entscheidungen kann darin im SGSN-Server liegen, der einen Zurückweisungsmechanismus verwendet, um die Wahl eines neuen SGSN-Servers auszulösen.
  • Das Senden von Zurückweisungsnachrichten muss nicht obligatorisch sein; bei einer alternativen Implementierung wird ein neuer SGSN-Server gewählt, falls nicht eine Annahmebestätigung empfangen wird oder die Auswahl innerhalb eines vorbestimmten Zeitintervalls abgeschlossen ist (Anmeldeanforderung bestätigt). Es sind verschiedene Alternativen möglich, wie vorgegangen werden kann, wenn eine Auswahl nicht erfolgreich war. Falls dagegen der gewählte SGSN-Serverknoten akzeptiert, gewählt zu werden, ist die Wahl/Zuweisung abgeschlossen, 110, und es wird eine Bestätigungsnachricht (Annahmenachricht) an RNC X weitergesendet, 110. Die Information über den gewählten/zugewiesenen SGSN-Server wird dann in RNC gespeichert, 111. Von RNC wird die Annahmenachricht an US1 weitergesendet, 112, und dann werden die Auswahl- und Anmeldeprozeduren beendet, 113.
  • 5B zeigt den Empfang einer PDP-Kontext-Aktivierungsanforderung von US1 in RNC X, 114. (Die PDP-Kontext-Aktivierungsprozedur ist in der Spezifikation 3GPP TS 23.060 beschrieben, auf die weiter oben in diesem Dokument verwie sen wurde.) Es wird geprüft, ob irgendwelche Informationen über einen gewählten/zugewiesenen SGSN-Server für US1 in dem Speichermittel von RNC X vorhanden sind, 115. Falls nicht, wird eine Fehlermeldung an US1 zurückgesendet, 116. Die Ursache ist dann vermutlich, dass keine Anmeldeprozedur durchgeführt/vollendet wurde. Falls in dem Speichermittel von RNC X Informationen enthalten sind, wird die PDP-Kontext-Aktivierungsanforderung von US1 durch RNC X an den gewählten SGSN-Server weitergesendet, 117. Nach einer Signalisierungsprozedur, z. B. wie in dem oben erwähnten Dokument beschrieben (durch eine gestrichelte Linie dargestellt), wird die PDP-Kontext-Aktivierungsanforderung angenommen, 118.
  • Während der Prozedur der Aktivierung einer PDP-Kontext-Anforderung wird durch den SGSN-Serverknoten ein MGW gewählt. Falls keine MGWs implementiert sind, kann stattdessen ein Tunnel direkt zu dem entsprechenden GGSN aufgebaut werden. Schließlich können Pakete zwischen US1 und GGSN geroutet werden, 119.
  • 6 zeigt die Prozedur des Wählens eines MGW, für welche vorzugsweise der gewählte SGSN-Server verantwortlich ist (vorausgesetzt, dass tatsächlich MGWs implementiert sind), 201. Die Auswahl findet zwischen den Schritten 117 und 118 von 5B statt.
  • Es kann ein Schritt 202 eingefügt werden, um festzustellen, ob tatsächlich redundante MGWs vorhanden sind. Falls nicht, wird das MGW "gewählt", welches mit dem RNC verbunden ist, das den SGSN-Server gewählt hat, 203. Falls jedoch redundante MGWs implementiert sind, wird eine Anforderung von dem gewählten SGSN-Server an das MGWi gesendet, welches dem RNC, das den SGSN-Server gewählt hat, am nächsten ist, 204. Anschließend wird festgestellt, ob die Wahl von MGWi angenommen wird, 205. Falls ja, wird MGWi gewählt und für Benutzerebenen-Funktionalitäten verwendet. Falls dagegen MGWi die Wahl nicht annimmt, wählt der SGSN-Server das nächste MGWi, i := i + 1, entsprechend einem Schema oder einem Algorithmus, z. B. WRR, wie im Zusammenhang mit der Wahl des SGSN-Servers erläutert wurde. Es können Zurückweisungsnachrichten mit oder ohne begleitende Informationen von MGWi an den SGSN-Server gesendet werden. Auch das Senden von Annahme-Nachrichten kann implementiert sein. Es wird dann eine neue Anforderung an das nachfolgende MGWi gesendet, wobei i := i + 1, 208. Die Prozedur wird insbesondere ab dem Schritt 205 wiederholt, bis ein MGWi gefunden wird, welches akzeptiert, gewählt zu werden.
  • 7 bezieht sich auf die Wahl eines GGSN entsprechend einer speziellen Ausführungsform, bei welcher der gewählte SGSN-Server für die Wahl eines GGSN verantwortlich ist, 301. Es wird eine Anforderung von dem GGSN-Server an den DNS (Domänennamenserver) gesendet, um eine Liste von GGSNs für das angeforderte externe Netz/APN zu erhalten, 302. Anschließend wird geprüft, ob mehr als ein GGSN auf der zurückgesendeten Liste vorhanden ist, 303. Falls nicht, wird eine PDP-Kontext-Erzeugungsanforderung (Create PDP Context Request) an den "gewählten" GGSN gesendet, 308. Es wird dann geprüft, ob der GGSN die Anforderung annimmt, 309. Falls ja, wird der Aufbau des Routings zwischen US1 und GGSN beendet, oder abgeschlossen, 310, und es wird eine PDP-Kontext-Aktivierungsbestätigung (Activate PDP Context Accept) an US1 zurückgesendet. Andernfalls wird eine PDP-Kontext-Zurückweisung (PDP Context Reject) an US1 zurückgesendet, 311. Falls dagegen festgestellt wird, dass mehr als ein GGSN auf der Liste vorhanden ist, wird ein GGSN aus der Liste ausgewählt, und zwar unter Berücksichtigung der Kapazität des GGSN, der Lastsituation des GGSN, des Standortes des GGSN im Vergleich zu dem verwendeten MGW und RNC, von früher gewählten GGSN usw., 304. Wenn auf diese Weise ein GGSN gewählt worden ist, wird eine PDP-Kontext-Erzeugungsanforderung an diesen gesendet, 305. Es wird geprüft, ob die Anforderung angenommen wird oder nicht, 306. Falls ja, ist der Aufbau des Routings zwischen US1 und GGSN beendet, 310, und es wird dann eine PDP-Kontext-Aktivierungsbestätigung an US1 zurückgesendet. Falls nicht, wird geprüft, ob noch irgendein GGSN auf der Liste verblieben ist, 307. Falls nicht, wird eine PDP-Kontext-Zurückweisung an US1 zurückgesendet, 311. Falls noch ein GGSN (oder mehrere GGSN) auf der Liste verblieben ist (sind), wird zu Schritt 304 zurückgekehrt, usw.
  • Es sollte klar sein, dass die Erfindung nicht auf die dargestellte Ausführungsform beschränkt ist, sondern auf verschiedene Weisen innerhalb des Schutzbereiches der beigefügten Ansprüche variiert werden kann; insbesondere können FSNs in einem oder mehreren Pools (an einem oder mehreren Standorten) vorgesehen sein, UGNs können implementiert sein oder nicht (für paketvermittelte Kommunikation). Falls UGNs (MGWs) verwendet werden, können sie auf irgendeine herkömmliche Weise gewählt werden, oder entsprechend den Prozeduren, die hier erörtert wurden. Die Wahl von SGSN kann ebenfalls auf eine herkömmliche Weise erfolgen, oder so wie hier beschrieben. Insbesondere kann, als eine Alternative, die Wahl eines SGSN-Servers (FSN) abgeschlossen werden, bevor irgendeine Anmeldeanforderung von RNC durch getrennte Signalisierung weitergesendet wird, und erst nachdem durch RNC eine Bestätigung empfangen worden ist (oder z. B. wenn ein Zeitintervall abgelaufen ist), wird die Anmeldeanforderung zu dem gewählten FSN (SGSN-Server) weitergesendet, der akzeptiert hat, gewählt zu werden.

Claims (18)

  1. Kommunikationssystem zur Unterstützung der Übertragung von Paketdaten innerhalb eines Paketdatennetzes, umfassend: – ein Kernnetz, ferner umfassend – mehrere Paketdaten-Unterstützungsknoten; und – mehrere Gateway-Knoten (GW1, GW2, GW3) zum Kommunizieren mit externen Paketdatennetzen; – mehrere Funknetze (RAN1, RAN2, RAN3), wobei jedes Funknetz (RAN1, RAN2, RAN3) Mittel (RNC 11, RNC 16) zum Steuern des jeweiligen Funknetzes (RAN1, RAN2, RAN3) enthält; dadurch gekennzeichnet, dass einige der mehreren Paketdaten-Unterstützungsknoten ferner mehrere funktionale Serverknoten (FSN 1, FSN 8) umfassen, die einen gemeinsamen Pool (100) bilden, und wobei jeder der funktionalen Serverknoten (FSN 1, FSN 8) innerhalb des gemeinsamen Pools (100) in der Lage ist, mit jedem beliebigen von den Mitteln (RNC 11, RNC 16) zum Steuern des jeweiligen Funknetzes (RAN1, RAN2, RAN3) verknüpft zu werden und dieses zu steuern; und wobei jedes der Mittel (RNC 11, RNC 16) zum Steuern des jeweiligen Funknetzes (RAN1, RAN2, RAN3) ferner Mittel zum Ausführen einer Anmeldeprozedur umfasst, um eine bestimmte Benutzerstation (UE) unabhängig vom Standort der Benutzerstation (UE) und unbeeinflusst vom Roaming der Benutzerstation (UE) bei einem bestimmten von den mehreren funktionalen Serverknoten (FSN 1, FSN 8) anzumelden.
  2. Kommunikationssystem nach Anspruch 1, wobei die mehreren funktionalen Serverknoten (FSN 1, FSN 8) zu zwei oder mehr gemeinsamen Pools (100, 200) zusammengefasst sind, wobei jeder gemeinsame Pool (100, 200) einen zugewiesenen Teil des Paketdatennetzes steuert und wobei jeder funktionale Serverknoten (FSN 1, FSN 8) innerhalb eines bestimmten Pools (100, 200) in der Lage ist, mit jedem beliebigen von den Mitteln (RNC 11, RNC 16) zum Steuern des jeweiligen Funknetzes (RAN1, RAN2, RAN3) innerhalb des zugewiesenen Teils des Paketdatennetzes verknüpft zu werden und dieses zu steuern.
  3. Kommunikationssystem nach Anspruch 1 oder 2, wobei das Paketdatennetz ein öffentliches Mobilfunknetz PLMN umfasst und der gemeinsame Pool (100, 200) von funktionalen Serverknoten (FSN 1, FSN 8) in der Lage ist, das gesamte PLMN zu bedienen.
  4. Kommunikationssystem nach Anspruch 1, 2 oder 3, wobei das Mittel zum Steuern (RNC 11, RNC 16) des jeweiligen Funknetzes (RAN1, RAN2, RAN3) einen Funknetzsteuerungs-(RNC-)Knoten enthält, der dazu eingerichtet ist, mit einem funktionalen Serverknoten (FSN 1, FSN 8) über ein Steuerungsebenen-Subprotokoll zu kommunizieren.
  5. Kommunikationssystem nach einem der Ansprüche 1 bis 4, wobei die funktionalen Serverknoten (FSN 1, FSN 8) Bedienende GPRS-Unterstützungsknoten (Serving GPRS Support Nodes) SGSN sind, welche funktionale SGSN-Server-Knoten und Media-Gateway-Knoten MGW umfassen.
  6. Kommunikationssystem nach einem der Ansprüche 1 bis 5, wobei das Mittel zum Ausführen der Anmeldeprozedur einen bestimmten von den funktionalen Serverknoten (FSN 1, FSN 8) innerhalb des gemeinsamen Pools (100, 200) auswählt, um die Kapazität innerhalb des gemeinsamen Pools (100, 200) gleichmäßig zu verteilen.
  7. Kommunikationssystem nach einem der Ansprüche 1 bis 6, wobei das Mittel zum Ausführen der Anmeldeprozedur ferner einen Datensatz zum Speichern von Informationen darüber umfasst, welche bestimmte Benutzerstation (UE) bei welchem funktionalen Serverknoten (FSN 1, FSN 8) angemeldet ist, und wobei das Mittel zum Ausführen der Anmeldeprozedur dazu eingerichtet ist, falls die Benutzerstation (UE) von dem funktionalen Serverknoten (FSN 1, FSN 8) abgemeldet wird und danach wieder versucht sich bei dem Kommunikationssystem anzumelden, die Benutzerstation (UE) wieder bei dem funktionalen Serverknoten (FSN 1, FSN 8) anzumelden, der durch den Datensatz angegeben ist.
  8. Kommunikationssystem nach Anspruch 7, wobei die Benutzerstation (UE) wieder bei dem funktionalen Serverknoten (FSN 1, FSN 8) angemeldet wird, unabhängig davon, welches Mittel (RNC 11, RNC 16) zum Steuern von Funknetzen (RAN1, RAN2, RAN3) tatsächlich die Benutzerstation (UE) bedient.
  9. Kommunikationssystem nach einem der Ansprüche 1 bis 8, wobei jeder der funktionalen Serverknoten (FSN 1, FSN 8) ferner Mittel zum Annehmen oder Zurückweisen eines Anmeldeversuches umfasst, der mit der Anmeldeprozedur verknüpft ist, die von einem bestimmten Mittel (RNC 11, RNC 16) zum Steuern des Funknetzes (RAN1, RAN2, RAN3) ausgeführt wird.
  10. Kommunikationssystem nach einem der Ansprüche 1 bis 9, wobei die mehreren Paketdaten-Unterstützungsknoten ferner mehrere Benutzer-Gateway-Knoten (User Gateway Nodes, UGN) umfassen und wobei die funktionalen Serverknoten (FSN 1, FSN 8) Mittel zum Auswählen eines bestimmten von den mehreren Benutzer-Gateway-Knoten (UGN) für Benutzerstationen (UE), die bei dem funktionalen Serverknoten (FSN 1, FSN 8) angemeldet sind, umfassen.
  11. Kommunikationssystem nach Anspruch 10, wobei die funktionalen Serverknoten (FSN 1, FSN 8) dazu eingerichtet sind, einen Benutzer-Gateway-Knoten (UGN) auszuwählen, der dem Funknetz (RAN1, RAN2, RAN3), das eine bestimmte Benutzerstation (UE) bedient, am nächsten ist.
  12. Verfahren in einem Kommunikationssystem, das ein Kernnetz und eine Anzahl von Funknetzen (RAN1, RAN2, RAN3) umfasst, wobei das Kommunikationssystem die Übertragung von Paketdaten unterstützt, zum Steuern von Verbindungen zwischen Benutzerstationen (UE) und/oder zwischen Benutzerstationen (UE) und externen Paketdatennetzen, wobei Benutzerstationen (UE) mit Funknetzen (RAN1, RAN2, RAN3) verbunden sind, wobei jedes Funknetz (RAN1, RAN2, RAN3) durch Funknetz-Steuerungsmittel (RNC 11, RNC 16) gesteuert wird, wobei Paketdaten-Unterstützungsknoten zum Steuern der Funknetz-Steuerungsmittel (RNC 11, RNC 16) vorgesehen sind, wobei ein Paketdaten-Unterstützungsknoten mindestens einen funktionalen Serverknoten (FSN 1, FSN 8) umfasst, gekennzeichnet durch die folgenden Schritte: – Bereitstellen einer Anzahl von Pools (100, 200) von funktionalen Serverknoten (FSN 1, FSN 8); – gemeinsames Steuern mindestens eines Teils des Netzes durch die funktionalen Serverknoten (FSN 1, FSN 8) in einem Pool (100, 200), wobei das Steuern von Verbindungen durch jeden funktionalen Serverknoten (FSN 1, FSN 8) des Pools (100, 200) unabhängig davon ausgeführt wird, welches das Funknetz (RAN1, RAN2, RAN3) innerhalb des gemeinsam gesteuerten Teils des Netzes ist; wobei der Schritt des Steuerns den Schritt des Anmeldens der Benutzerstation (UE) bei einem ausgewählten funktionalen Serverknoten (FSN 1, FSN 8) unabhängig vom Standort der Benutzerstation (UE) und unbeeinflusst vom Roaming der Benutzerstation (UE) umfasst.
  13. Verfahren nach Anspruch 12, welches den Schritt des Auswählens unterschiedlicher funktionaler Serverknoten (FSN 1, FSN 8) für aufeinander folgende Benutzerstationen (UE), die eine Netzanmeldeprozedur ausführen, umfasst.
  14. Verfahren nach Anspruch 12 oder 13, wobei die Paketdaten-Unterstützungsknoten ferner mehrere Benutzer-Gateway-Knoten (UGN) umfassen und wobei der funktionale Serverknoten (FSN 1, FSN 8), der für eine bestimmte Benutzerstation (UE) ausgewählt ist, ferner einen bestimmten von den mehreren Benutzer-Gateway-Knoten (UGN) auswählt.
  15. Verfahren nach Anspruch 12, 13 oder 14, wobei das Kommunikationsnetz ferner mehrere Gateway-Unterstützungsknoten (GW1, GW2, GW3) enthält und wobei der funktionale Serverknoten (FSN 1, FSN 8) für eine bestimmte Benutzerstation (UE) einen bestimmten von den mehreren Gateway-Unterstützungsknoten (GW1, GW2, GW3) zum Kommunizieren mit einem externen Paketdatennetz auswählt.
  16. Verfahren nach einem der Ansprüche 12 bis 15, welches die folgenden Schritte umfasst: – Empfangen einer Anforderung von einer bestimmten Benutzerstation (UE), welche bei einem bestimmten funktionalen Serverknoten (FSN 1, FSN 8) angemeldet worden ist und danach von dem Kommunikationsnetz abgemeldet worden ist, wobei durch die Anforderung ein Anmelden bei dem Kommunikationsnetz angefordert wird; – Identifizieren des funktionalen Serverknotens (FSN 1, FSN 8), bei dem die Benutzerstation (UE) zuvor angemeldet war; und – erneutes Anmelden der Benutzerstation (UE) bei dem früheren funktionalen Serverknotens (FSN 1, FSN 8)
  17. Verfahren nach einem der Ansprüche 12 bis 16, wobei der Schritt des Anmeldens der Benutzerstation (UE) bei einem ausgewählten funktionalen Serverknoten (FSN 1, FSN 8) den Schritt des Auswählens eines bestimmten funktionalen Serverknotens (FSN 1, FSN 8) durch Anwenden einer gewichteten Round-Robin-Auswahl umfasst.
  18. Verfahren nach Anspruch 17, wobei ein Gewichtungsfaktor bei der gewichteten Round-Robin-Auswahl von einer Kapazität des jeweiligen funktionalen Serverknotens (FSN 1, FSN 8) und/oder einer tatsächlichen Last auf dem funktionalen Serverknoten (FSN 1, FSN 8) abhängt.
DE60133754T 2000-10-13 2001-10-11 Kommunikationssystem, das die drahtlose übermittlung von paketdaten unterstützt und verfahren und anordnung dazu Expired - Lifetime DE60133754T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE0003719A SE518479C2 (sv) 2000-10-13 2000-10-13 Kommunikationssystem som stödjer trådlös kommunikation av paketdata och förfarande och anordning relaterande därtill
SE0003719 2000-10-13
PCT/SE2001/002210 WO2002032062A1 (en) 2000-10-13 2001-10-11 Communication system supporting wireless communication of packet data and method and arrangement relating thereto

Publications (2)

Publication Number Publication Date
DE60133754D1 DE60133754D1 (de) 2008-06-05
DE60133754T2 true DE60133754T2 (de) 2009-07-02

Family

ID=20281422

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60133754T Expired - Lifetime DE60133754T2 (de) 2000-10-13 2001-10-11 Kommunikationssystem, das die drahtlose übermittlung von paketdaten unterstützt und verfahren und anordnung dazu

Country Status (8)

Country Link
US (1) US7359360B2 (de)
EP (1) EP1325596B1 (de)
AT (1) ATE393520T1 (de)
AU (1) AU2001296111A1 (de)
DE (1) DE60133754T2 (de)
ES (1) ES2305113T3 (de)
SE (1) SE518479C2 (de)
WO (1) WO2002032062A1 (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4368680B2 (ja) * 2001-09-03 2009-11-18 富士通株式会社 移動通信システム
NO20014865D0 (no) * 2001-10-05 2001-10-05 Ericsson Telefon Ab L M Optimalisering av handover-prosedyrer i GPRS
DE60221917T2 (de) 2002-11-27 2008-05-15 Research In Motion Ltd., Waterloo Datenübertragung von einem hostserver via tunnelserver zu einem drahtlosen gerät und zuordnung einer temporären ipv6 addresse zu einer temporären ipv4 addresse für die kommunikation in einem ipv4 drahtlosen netzwerk mit dem gerät
WO2004084572A1 (en) * 2003-03-20 2004-09-30 Telefonaktiebolaget L M Ericsson (Publ) Method for transferring a mobile terminal in e.g. an umts-network from one server node in a pool to another server node in the same pool
CN100341341C (zh) * 2004-01-16 2007-10-03 华为技术有限公司 一种无线局域网中用户终端获取分组数据关口地址的方法
GB0410151D0 (en) * 2004-05-07 2004-06-09 Zeus Technology Ltd Load balancing & traffic management
ES2303088T3 (es) * 2004-08-28 2008-08-01 Telefonaktiebolaget Lm Ericsson (Publ) Un sistema, una disposicion y un metodo para proporcionar nodos de red basica con informacion relativa a estaciones moviles.
ATE413078T1 (de) * 2004-08-28 2008-11-15 Ericsson Telefon Ab L M Anordnung und verfahren in kommunikationsnetzen
FR2879070B1 (fr) * 2004-12-02 2007-02-23 Cit Alcatel Determination d'adresses ip de noeuds ggsn de reseaux de communication, en fonction de criteres de proximite et de disponibilite, en vue de l'activation de contexte(s) pdp
US7483416B2 (en) 2005-04-01 2009-01-27 Cml Emergency Services Inc. Internet protocol radio dispatch system and method
US7460510B2 (en) * 2005-04-01 2008-12-02 Cml Emergency Services Inc. Radio gateway system and method for interfacing a radio system and an IP network
US20070189273A1 (en) * 2006-02-10 2007-08-16 3Com Corporation Bi-planar network architecture
EP1889494B1 (de) 2005-06-07 2019-12-18 Apple Inc. Bereitstellung einer datenfunktion in einem zugangs-gateway-knoten
US20070003024A1 (en) * 2005-06-22 2007-01-04 Cml Emergency Services Inc. Network emergency call taking system and method
US7676228B2 (en) * 2005-09-19 2010-03-09 Plant Equipment Inc. Radio interoperability system and method
CN100401689C (zh) * 2005-10-24 2008-07-09 华为技术有限公司 一种网络资源配置方法
US7870263B2 (en) * 2005-12-27 2011-01-11 At&T Intellectual Property I, L.P. Carrier interoperability for critical services
US9438436B2 (en) * 2006-08-14 2016-09-06 Alcatel Lucent Broadcast anchor availability indication
US9300487B1 (en) 2007-02-06 2016-03-29 Apple Inc. Re-establishing a direct tunnel between an access node and a gateway router
WO2008113300A1 (fr) * 2007-03-20 2008-09-25 Huawei Technologies Co., Ltd. Procédé, système et appareil pour sélectionner des dispositifs de réseau
CN101272614B (zh) * 2007-03-20 2010-12-08 华为技术有限公司 一种选择网络设备的方法和系统及装置
JP5105922B2 (ja) * 2007-03-22 2012-12-26 日本電気株式会社 情報更新システム、情報記憶サーバ、情報更新方法、及び、プログラム
CN101399767B (zh) * 2007-09-29 2011-04-20 华为技术有限公司 终端移动时安全能力协商的方法、系统及装置
KR101531531B1 (ko) * 2009-01-08 2015-07-07 삼성전자주식회사 이동통신 시스템에서 단말의 로컬 패킷 데이터 망 접속 서비스 방법
US8331938B2 (en) * 2009-11-23 2012-12-11 Telefonaktiebolaget L M Ericsson (Publ) Moving user equipment without service interruption
KR101094033B1 (ko) * 2010-04-12 2011-12-19 중앙대학교 산학협력단 분산 네트워크를 이용한 노드 등록 및 유동 ｉｐ 검색 방법 및 장치
US9807669B1 (en) * 2014-10-24 2017-10-31 Sprint Communications Company L.P. Identifying communication paths based on packet data network gateway status reports
DE102015207536A1 (de) * 2015-04-24 2016-10-27 Voith Patent Gmbh Behandlungsgarnitur
EP3406102A1 (de) * 2016-01-18 2018-11-28 Telefonaktiebolaget LM Ericsson (PUBL) Verfolgungsbereich und nutzerebenen-mapping für steuerungsebenen/benutzerebenen-teilung

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0810875B2 (ja) * 1991-04-18 1996-01-31 インターナショナル・ビジネス・マシーンズ・コーポレイション 局所ネットワークを大域ネットワークと接続する方法及び装置
FI98586C (fi) * 1995-01-10 1997-07-10 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja menetelmiä datapaketin reitittämiseksi protokollariippumattomasti pakettiradioverkoissa
US5721914A (en) * 1995-09-14 1998-02-24 Mci Corporation System and method for hierarchical data distribution
US5831975A (en) * 1996-04-04 1998-11-03 Lucent Technologies Inc. System and method for hierarchical multicast routing in ATM networks
US6141325A (en) * 1996-12-18 2000-10-31 International Business Machines Corporation Paradigm for enabling interoperability between different subnetworks
AU738855B2 (en) * 1997-06-20 2001-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Data packet radio service with enhanced mobility management
US6104929A (en) * 1997-06-20 2000-08-15 Telefonaktiebolaget Lm Ericsson Data packet radio service with enhanced mobility management
US6122276A (en) * 1997-06-30 2000-09-19 Cisco Technology, Inc. Communications gateway mapping internet address to logical-unit name
US6088330A (en) * 1997-09-09 2000-07-11 Bruck; Joshua Reliable array of distributed computing nodes
US6178160B1 (en) * 1997-12-23 2001-01-23 Cisco Technology, Inc. Load balancing of client connections across a network using server based algorithms
JP4354641B2 (ja) * 1998-04-03 2009-10-28 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ユニバーサル移動電話システム（ｕｍｔｓ）におけるフレキシブル無線アクセス及びリソース割り当て
US6529497B1 (en) * 1998-04-30 2003-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Channel allocation and release for packet data services
CA2238137A1 (en) * 1998-05-20 1999-11-20 Universite Du Quebec A Montreal A universal plant promoter inducing gene transcription in response to low-temperatures
FI106288B (fi) * 1998-10-06 2000-12-29 Nokia Networks Oy Matkaviestimen yksilöiminen pakettiradioverkossa
US6973057B1 (en) * 1999-01-29 2005-12-06 Telefonaktiebolaget L M Ericsson (Publ) Public mobile data communications network
FI109170B (fi) 1999-06-28 2002-05-31 Nokia Corp Sijainninhallinta solukkojärjestelmiä varten
US6920116B1 (en) * 1999-12-16 2005-07-19 Telefonaktiebolaget Ln Ericsson System and method for automatically configuring network service entity identifiers utilizing a Gb-over-IP interface in a GPRS network
EP1111862A1 (de) * 1999-12-23 2001-06-27 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Verfahren und Vorrichtungen zur Bereitstellung von definierter Servicequalität in einem paketvermittelten Kommunikationsnetzwerk
DE60041240D1 (de) * 2000-01-26 2009-02-12 Ericsson Telefon Ab L M Verfahren, Server und Anordnung in einem Kommunikationsnetz
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
US7072329B2 (en) * 2000-05-22 2006-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Combining differing transport technologies in a telecommunications system
US7126939B2 (en) * 2000-07-24 2006-10-24 Nortel Networks Limited Packet-based calls in a wireless network
US6735220B1 (en) * 2000-08-01 2004-05-11 Sun Microsystems, Inc. Using a centralized server to coordinate assignment of identifiers in a distributed system
US6845100B1 (en) * 2000-08-28 2005-01-18 Nokia Mobile Phones Ltd. Basic QoS mechanisms for wireless transmission of IP traffic
US6996081B1 (en) * 2000-10-05 2006-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Resource capacity reporting to control node of radio access network
US6889050B1 (en) * 2000-11-22 2005-05-03 Telefonaktiebolaget Lm Ericsson (Publ) Variable transmission rate services in a radio access network
US6973054B2 (en) * 2001-01-05 2005-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Communication management in mobile networks having split control planes and user planes
US7106718B2 (en) * 2001-02-09 2006-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Signaling quality of service class for use in multimedia communicatations
US6850759B2 (en) * 2001-02-22 2005-02-01 Telefonaktiebolaget Lm Ericsson (Publ) Reducing signaling in RNSAP protocol upon cell change in cellular telecommunications network
FI111506B (fi) * 2001-03-14 2003-07-31 Nokia Corp Menetelmä palvelun laatutason valitsemiseksi langattomassa tiedonsiirtojärjestelmässä
US6950398B2 (en) * 2001-08-22 2005-09-27 Nokia, Inc. IP/MPLS-based transport scheme in 3G radio access networks
US7191231B2 (en) * 2003-02-12 2007-03-13 Cisco Technology, Inc. System and method for consistent forwarding of packets across wireless and wireline networks

Also Published As

Publication number Publication date
SE518479C2 (sv) 2002-10-15
ATE393520T1 (de) 2008-05-15
ES2305113T3 (es) 2008-11-01
SE0003719D0 (sv) 2000-10-13
US7359360B2 (en) 2008-04-15
DE60133754D1 (de) 2008-06-05
EP1325596B1 (de) 2008-04-23
AU2001296111A1 (en) 2002-04-22
US20040053607A1 (en) 2004-03-18
EP1325596A1 (de) 2003-07-09
SE0003719L (sv) 2002-04-14
WO2002032062A1 (en) 2002-04-18

Similar Documents

Publication Publication Date Title
DE60133754T2 (de) Kommunikationssystem, das die drahtlose übermittlung von paketdaten unterstützt und verfahren und anordnung dazu
DE10297190B4 (de) Anordnungen und Verfahren in mobilen Internetkommunikationssystemen
DE60126770T2 (de) Umändern einer ersten teilnehmerkennung in eine zweite kennung
DE69924679T2 (de) Reduzierung der signalisierungslast in einem funkpaketnetzwerk
EP1282997B1 (de) Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
DE19832290B4 (de) Kommunikationssystem und Verfahren zum Aufbauen von Verbindungen zwischen Terminals eines ersten und eines zweiten Kommunikationsnetzes
DE60306754T2 (de) Verfahren zum Herunterladen von Software mit Unterstützung von mobilen Sitzungen in Mobilkommunikationssystemen
DE69928839T2 (de) Verfahren und vorrichtung zur ausführung von paketdatenübertragung
DE69926799T2 (de) Verfahren und system zur begrenzung der dienstqualität einer datensübertragung
DE60105841T2 (de) Signalisierung in einem zellularen mobilfunknetz mit gepoolten msc'n
DE602004003146T2 (de) System und verfahren für telekommunikation
DE69922492T2 (de) Verfahren zum anschluss einer basisstation an ein zellulares system
DE19922288A1 (de) Anordnung zur mobilen Kommunikation
DE10105093A1 (de) Paging-Verfahren und -System für ein Funkzugriffsnetz
WO2002087160A2 (de) Heterogenes mobilfunksystem
DE10039193A1 (de) Verfahren und Anordnung zur Durchführung eines Handovers in mobilen Datenübertragungssystemen unter Datenduplizierung
DE102005043364A1 (de) Telekommunikationssystem und Verfahren zum Steuern eines Wechsels eines Teilnehmerendgerätes zwischen zwei Netzwerken
DE60312184T2 (de) Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen
DE102005001123A1 (de) Kommunikationssystem, Verfahren zum Steuern eines Kommunikationssystems, Netzzugangsvorrichtung und Verfahren zum Steuern einer Netzzugangsvorrichtung
DE10361704A1 (de) Vorrichtung und Verfahren zum Aufbauen einer Verbindung in einem aus mobilen Knoten gebildeten Funknetzwerk
DE60215053T2 (de) Verfahren zur unterstützung der mobilität in drahtlosen netzwerken
DE69925028T2 (de) Weiterreichen in einem kommunikationssystem
DE60313821T2 (de) Paketdatenprotokoll-Kontextaktivierung (PDP) in einem GPRS Netzwerk
DE60032070T2 (de) Architektur zur Bereitstellung von Leistungsmerkmalen für drahtlose Anrufe in einem drahtlosen Telekommunikationssystem
EP1364549B1 (de) Verfahren zur relokation des diversitätspunktes einer mobilen station in einem funkzugriffsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
R082 Change of representative

Ref document number: 1325596

Country of ref document: EP

Representative=s name: PATENT- UND RECHTSANWAELTE KRAUS & WEISERT, DE

R081 Change of applicant/patentee

Ref document number: 1325596

Country of ref document: EP

Owner name: SONY MOBILE COMMUNICATIONS AB, SE

Free format text: FORMER OWNER: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), STOCKHOLM, SE

Effective date: 20121219

R082 Change of representative

Ref document number: 1325596

Country of ref document: EP

Representative=s name: PATENT- UND RECHTSANWAELTE KRAUS & WEISERT, DE

Effective date: 20121219