DE10338914A1

DE10338914A1 - Verfahren zur Konfiguration eines Netzwerks

Info

Publication number: DE10338914A1
Application number: DE10338914A
Authority: DE
Inventors: Juan Rodriguez Noguera
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2003-08-20
Filing date: 2003-08-20
Publication date: 2005-03-24
Also published as: JP2005073256A

Abstract

Ein Verfahren zur Konfigurierung eines Netzwerks, über das Daten übertragen werden, vorzugsweise eines UMTS-Netzwerks, wobei das Netzwerk ein zentrales Netzwerk und/oder mindestens einen Netzwerkteil umfasst, der die Kommunikation zwischen dem zentralen Netzwerk und mindestens einem Endgerät ermöglicht, wobei der Netzwerkteil mindestens zwei Schubsysteme aufweist, die zumindest einen Leitrechner zur Verwaltung der Ressourcen des Netzwerkteils und/oder der Datenübertragung aufweisen, und wobei die Leitrechner in mindestens einen R-Server zur Verwaltung der Funktionen und/oder Dienste der Endgeräte und/oder mindestens einen U-Server zur Verwaltung der vom Subsystem benötigten Funktionen unterteilt sind, ist im Hinblick auf ein robustes Netzwerkverhalten bei einer kostengünstigen Implementierung in bestehende Netzwerkkonfigurationen derart ausgebildet, dass jedem U-Server ein Primär-R-Server zur Regelung der Kommunikation der vorzugsweise in dem Subsystem befindlichen Endgeräte zugeordnet wird.

Description

Die Erfindung betrifft ein Verfahren zur Konfigurierung eines Netzwerks über das Daten übertragen werden, vorzugsweise eines UMTS-Netzwerks, wobei das Netzwerk ein zentrales Netzwerk und/oder mindestens einen Netzwerkteil umfasst, der die Kommunikation zwischen dem zentralen Netzwerk und mindestens einem Endgerät ermöglicht, wobei der Netzwerkteil mindestens zwei Subsysteme aufweist, die zumindest einen Leitrechner zur Verwaltung der Ressourcen des Netzwerksteils und/oder der Datenübertragung aufweisen und wobei die Leitrechner in mindestens einen R-Server zur Verwaltung der Funktionen und/oder Dienste der Endgeräte und/oder mindestens einen U-Server zur Verwaltung der vom Subsystem benötigten Funktionen, unterteilt sind.

Verfahren zur Konfiguration von Netzwerken werden insbesondere im Bereich des Mobilfunks ständig weiterentwickelt. Zur besseren Anschaulichkeit wird das vorliegende Verfahren anhand des derzeit in der Implementierung befindlichen Third Generation – 3G – Standards, dem UMTS – Universal Mobile Telecommunications System – beschrieben. Das UMTS-Netzwerk besteht im Wesentlichen aus folgenden Komponenten: die unterste Stufe bilden die Endgeräte, d.h. das User Equipment – UE. Dies sind beispielsweise Mobiltelefone, es können aber auch andere multifunktionale Geräte wie PDA – Personal Digital Assistants – oder ähnliche Geräte sein. Das UE kommuniziert mit einem Netzwerkteil des UMTS-Netzwerks, der als Funknetz ausgestaltet ist, dem UTRAN – UMTS Terrestrial Radio Access Network.

Das UTRAN umfasst Sende- und Empfangsanlagen, eine Signalcodierung sowie die Verwaltung der aktiven Endgeräte in seinem Bereich. Es ist dabei in Subsysteme unterteilt, die Basisstationen, genannt Node B oder auch Base Transceiver Stationen – BTS –, sowie Radio Network Controller – RNC – aufweisen. Neben der Teilnehmerverwaltung und Signalannahme ist es Aufgabe des UTRAN, die empfangenen Daten an das zentrale Netzwerk, das sogenannte Core Network – CN –, weiterzugeben, in dem die eigentliche Datenvermittlung an die Teilnehmer im UMTS-Netzwerk sowie an externe Teilnehmer, beispielsweise im Telefonfestnetz, stattfindet.

Eine Weiterentwicklung des UTRAN basiert auf einer funktionalen Teilung des UTRAN. Diese Weiterentwicklung wird als IPRAN – Internet Protocol based Radio Access Network – bezeichnet. In der IPRAN-Technologie wird der Leitrechner RNC, wie er beispielsweise in der 3GPP – Third Generation Partnership Project – R99-Architektur verwendet wird, in einen oder mehrere R-Server, in diesem Fall die Radio Control Server – RCS – und mehrere U-Server, in diesem Fall die User Plane Servers – UPS –, unterteilt. Der RCS übernimmt hierbei die Kontrolle über alle mit dem UE verbundenen Funktionen und der UPS regelt alle mit den Basisstation, d.h. den Radiozellen, verbundenen Funktionen. Der oder die RCS regeln und/oder überwachen den oder die UPS, um den UE bzw. dem Benutzer des UE Dienste zur Verfügung zu stellen. Der RCS bestimmt hierbei die Regelungs- und/oder Überwachungsebene – Control Plane, CP – und der UPS die Benutzerebene – User Plane, UE – mit dem zentralen Netzwerk CN.

Zur Erhöhung der Robustheit und um eine Verteilung der Belastung zu erreichen, wird in manchen Fällen eine m-zu-n Beziehung zischen den RCS und den UPS verwirklicht. Dabei regelt und/oder überwacht ein RCS n UPS und ein UPS kann von m RCS geregelt und/oder überwacht werden.

Ein solches Verfahren erhöht zwar die Robustheit des Netzwerks, es ist allerdings in das derzeitige UMTS-Verfahren nicht implementierbar. Dabei ist problematisch, dass das CN mit Gebietsidentitätskonzepten arbeitet, beispielsweise der Location Area, der Routing Area usw., die mit geographischen Gebieten fest verknüpft sind, welche wiederum an die Position der Basisstationen, Node B, gebunden sind. In der geläufigen R99-Architektur sind die Node B statisch mit den RNC assoziiert, was bedeutet, dass die RNC statisch mit geographischen Gebieten assoziiert sind. Wenn das CN z.B. ein UE für CS-Dienste pagen will, weiß es in der Regel die Location Area in der sich das UE aufhält. Das CN kann das UE so direkt einem oder mehreren RNC zuordnen, zu dem oder denen das CN dann die Paging-Nachricht senden kann.

In einem IPRAN ist bei einer m-zu-n RCS-UPS-Beziehung ein RCS nicht direkt mit einem geographischen Gebiet verbunden und da durch ihn die CP für das CN bestimmt wird, kann das CN unmöglich wissen, welchen RCS es gebrauchen muss, um eine für irgendeine UE bestimmte Kommunikation, wie beispielsweise Paging, CS-Anrufe, PS-Verbindungen, usw., aufzubauen. Es kann dabei nicht angenommen werden, dass das CN jeden RCS verwenden kann, da es dem CN nicht bekannt ist, welches geographische Gebiet, das durch die Basisstationen abgedeckt wird, die an die n UPS angebunden ist, welche dieser RCS kontrolliert.

Daher verlangt das bisherige Konzept der m-zu-n RCS-UPS-Beziehung strukturelle Änderungen im CN und in den CN-UTRAN-Verfahren. Dies ist technisch aufwendig und daher sehr kostenintensiv.

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art anzugeben, bei dem ein robustes Netzwerkverhalten bei einer kostengünstigen Implementierung in bestehende Netzwerkkonfigurationen ermöglicht ist.

Erfindungsgemäß wird die voranstehende Aufgabe durch das Verfahren zur Konfigurierung eines Netzwerks mit den Merkmalen des Patentanspruchs 1 gelöst. Danach ist das in Rede stehende Verfahren zur Konfigurierung eines Netzwerks derart ausgestaltet und weitergebildet, dass jedem U-Server ein Primär-R-Server zur Regelung der Kommunikation der vorzugsweise in dem Subsystem befindlichen Endgeräte zugeordnet wird.

In erfindungsgemäßer Weise ist zunächst erkannt worden, dass in Abkehr zu der bisherigen Praxis ein robustes Netzwerkverhalten bei guter Implementierbarkeit nicht allein dadurch erreicht, dass ein Leitrechner, der Teil des Netzwerkteils ist, das die Kommunikation zwischen dem zentralen Netzwerk und mindestens einem Endgeräte ermöglicht, in R- und U-Server unterteilt wird. Zwar wird durch eine solche Konfigurierung eine Robustheit des Netzwerks erreicht, aber eine Implementierung in bestehende geographisch festgelegte Subsysteme ist kaum möglich. In erfindungsgemäßer Weise ist daher weiterhin erkannt worden, dass zum Erreichen eines robusten Netzwerksverhaltens bei gleichzeitigem kostengünstigen Einfügen in bestehende Systeme der R-Server ortsunabhängig zum U-Server und trotzdem ortsdifferenzierbar für das zentrale Netzwerk ausgestaltet sein muss. Dies ist auf überraschend einfache und in technischer Hinsicht besonders raffinierte Weise dadurch erreicht, dass jedem U-Server ein Primär-R-Server zugeordnet wird. Dieser Primär-R-Server ist der Standart-R-Server, der dazu verwendet wird, um mit allen Endgeräten zu kommunizieren, die sich in den Subsystemen, z.B. der Reichweite der Basisstatio nen, aufhalten, die von dem entsprechenden U-Server geregelt werden. Für das zentrale Netzwerk, beispielsweise das CN, bedeutet dies, dass ein R-Server für Endgerät terminierte Verbindungen mit dem geographischen Gebiet verbunden ist, das durch alle U-Server abgedeckt wird, für die der entsprechende R-Server der Primär-R-Server ist. Der R-Server könnte hierbei im einem UMTS-Netzwerk beispielsweise ein RCS und der U-Server ein UPS sein. Ein solches Gebiet kann als RCS-Gebiet bezeichnet werden und entspricht einem RNC-Gebiet in einer 3GPP – Third Generation Partnership Project – R99-UTRAN-Architektur. Diese Ausgestaltung ist für Netzwerke besonders vorteilhaft, da nunmehr die Datenübertragung bei einem Ausfall des R-Servers aufgrund von überhöhtem Datenaufkommen oder Fehlfunktionen des R-Servers über andere R-Server vorgenommen werden kann, die das gleiche Netzwerkgebiet abdecken wie der Primär-R-Server.

Im Hinblick auf eine besonders bevorzugte Ausgestaltung könnte der Primär-R-Server zur Regelung sämtlicher Kommunikation der in dem Subsystem befindlichen Endgeräte dienen. Hierdurch wären sämtliche bereits beschriebenen Vorteile im gesamten Netzwerk vorhanden.

Im Rahmen einer robusten Ausgestaltung des Netzwerks könnte jedem U-Server zusätzlich zum Primär-R-Server mindestens ein Sekundär-R-Server zugeordnet sein. Der Sekundär-R-Server könnte dann lediglich für den Fall, das der Primär-R-Server aufgrund einer Fehlfunktion oder einer Überlastung nicht erreichbar ist, dessen Funktion übernehmen. Diese Ausgestaltung ist für Netzwerke besonders vorteilhaft, da nunmehr die Datenübertragung bei einem Ausfall eines R-Servers aufgrund von Fehlfunktionen des R-Servers über andere R-Server vorgenommen werden können, die das gleiche Netzwerkgebiet abdecken, wie der Primär-R-Server. Zudem ist ein Ausgleich von erhöhtem Datenverkehr möglich, da bei überhöhtem Datenaufkommen der überlastete R-Server temporär durch andere R-Server, die das gleiche Netzwerkgebiet abdecken, entlastet werden kann und somit bei jedweden Fehlfunktionen des R-Servers die Dienste für die Endgeräten sichergestellt werden können. Es könnte allerdings auch eine Konfigurierung gewählt werden, in der dem oder den U-Servern kein Sekundär-R-Server zugeordnet ist.

In besonders vorteilhafter Weise könnte der Primär-R-Server und der Sekundär-R-Server die gleichen Teile des Netzwerks abdecken. Teile des Netzwerks könnten beispielsweise in einem UMTS-Netzwerk die durch den Primär-RCS abgedeckten geographischen Gebiete sein. Es wäre allerdings auch eine Ausgestaltung denkbar, in der zwei oder mehrere Sekundär-R-Server gemeinsam den Teil des Netzwerks abdecken, den der Primär-R-Server abdeckt, wobei jeder Sekundär-R-Server jeweils einen Teil des Netzwerksteils abdeckt, das der Primär-R-Server abdeckt.

Hinsichtlich einer besonders effektiven Ausnutzung der Systemressourcen könnte ein Primär-R-Server eines U-Servers einem anderen U-Server als Sekundär-R-Server zugeordnet werden. Dies bedeutet, dass die technische Ausgestaltung des R-Server gleich bleibt und zwar unabhängig davon, ob er als Primär- oder Sekundär-R-Server eingesetzt wird. Alternativ hierzu könnte ein R-Server nur einem U-Server als Sekundär-R-Server zugeordnet werden. Dies bedeutet, dass dieser R-Server keinem U-Server als Primär-R-Server zugeordnet wird. Hierdurch könnte die Robustheit des Netzwerks wiederum erhöht werden, da nunmehr R-Server nur zum Backup von Primär-R-Servern zur Verfügung stehen oder um in Zeiten eines besonders hohen Datenaufkommens dieses erhöhte Datenvolumen zu handhaben.

Im Hinblick auf eine besonders einfache Ausgestaltung könnte das zentrale Netzwerk vorzugsweise beim Aufbau einer Kommunikation Informationen an einen R-Server übermitteln, die definieren, ob dieser R-Server als Primär- oder Sekundär-R-Server dient. Dies könnte insbesondere dann erfolgen, wenn das zentrale Netzwerk, beispielsweise das CN, Vorgänge hinsichtlich eines R-Servers startet, z.B. eine Endgerät terminierte Kommunikation aufbauen oder für im UMTS-Netzwerk aus Gründen des Service Area Broadcast – SAB. Eine Kommunikation könnte eine verbindungs- oder paketorientierte Kommunikation sein. Die Informationen könnten dann beispielsweise Informationen über das R-Server-Gebiet sein, das für die entsprechenden Funktionen und/oder Dienste benötigt wird. Im UMTS-Netzwerk könnte die RNC-Kennung – RNC-Identifier, RNC-ID –, die in der 3GPP-R99-Architektur definiert wird, für diese Zwecke verwendet werden. Dies hätte die geringsten Einwirkungen auf die bestehenden 3GPP-Protokolle und Implementierungen, da keine neue Kennung verwendet werden müsste. Beispielsweise könnte in einem solchen Fall das Fehlen der RNC-ID oder das Vorhandensein der RNC-ID eines bestimmten RCS bedeuten, dass dieser betroffene RCS ein Primär-RCS sein soll. Das Vorhandensein einer RNC-ID, die nicht diesen RCS betrifft; könnte dann bedeuten, dass dieser RCS als Sekundär-RCS für den betroffenen Primär-RCS handeln soll.

Im Rahmen einer besonders robusten Ausgestaltung könnte ein Sekundär-R-Server die Funktionen des Primär-R-Servers übernehmen, wenn der Primär-R-Server nicht funktionsfähig ist. Die Funktionsfähigkeit des Primär-R-Servers könnte hierbei beispielsweise durch Überlastung oder Fehlfunktionen des Primär-R-Servers beeinträchtigt sein. Der Sekundär-R-Server könnte in einem solchen Fall die betroffenen Funktionen kompensieren oder aber auch die Gesamtfunktion des Primär-R-Servers ersetzen. Somit wäre ein kontinuierlicher Betrieb des Netzwerks gewährleist und die Robustheit des Netzwerks erhöht. Hierbei könnte das zentrale Netzwerk zufällig einen der Sekundär-R-Server, die dem nicht funktionsfähigen Primär-R-Server zugeordnet sind, auswählen, der die Funktion oder Teile der Funktion des Primär-R-Server übernimmt. Es sind aber auch andere Verfahren zur Auswahl des die Funktion des Primär-R-Servers übernehmenden Sekundär-R-Servers möglich.

In vorteilhafter Weise könnte die Auswahl eines R-Servers als Primär-R-Server durch den U-Server erfolgen. Dies wäre besonders dann vorteilhaft, wenn es sich bei den abzuarbeitenden Vorgängen, um Vorgänge handeln würde, die von dem Endgerät, z.B. dem UE, initiiert werden, und welche die R-Server-Auswahl auslösen.

Alternativ oder zusätzlich könnte die Auswahl eines R-Servers als Primär-R-Server durch das zentrale Netzwerk erfolgen. Dies wäre dann vorteilhaft, wenn es sich um Vorgänge im Netzwerk handelt, die am Endgerät enden, und welche die R-Server-Auswahl auslösen.

Hinsichtlich einer besonders einfachen Konfigurierung könnte zwischen den R-Servern und/oder dem zentralen Netzwerk eine Inter-Working-Funktion verwendet werden. In einem solchen Fall müsste es dem zentralen Netzwerk nicht bekannt sein, welcher R-Server als Sekundär-R-Server zu einem bestimmten Primär-R-Server handeln könnte. Die Inter-Working-Funktion – IWF – könnte dann vorhanden sein, um die primären und sekundären Einsätzen des R-Servers unerkannt zu lassen. Die IWF könnte besonders vorteilhaft sein, um dieses Verfahren in bereits be stehende UMTS-Netzwerke, insbesondere bereits vorhandene CN-Strukturen zu integrieren.

Als zur Erfindung gehörend ist auch ein entsprechendes die Verfahrensschritte verwirklichendes Netzwerk zu sehen.

Ein besonders vorteilhafte Ausgestaltung, die auch ergänzend und/oder erläuternd zu den bereits beschrieben Ausführungsbeispielen zu sehen ist, wird im Folgenden beschrieben:
Eine „Fortgeschrittene Architektur basierend auf einer funktionellen Trennung", im Folgenden „IPRAN" genannt, wird von 3GPP als eine potenzielle Netzwerkarchitektur für das zukünftige UTRAN (UMTS Terrestrial Radio Access Network) betrachtet. Siehe 3GPP TR 25,897 für Details über die „Entwicklung von UTRAN".
Allgemein gesprochen sieht IPRAN vor, den Radio Network Controller (RNC) in die 3GPP R99 UTRAN Architektur (siehe 3GPP TS 25,401), in einen oder mehr Radio Control Servers (RCS) und einige User Plane Servers (UPS) aufzuspalten. Das RCS ist verantwortlich für alle Funktionen bezüglich der Mobilfunkendgeräte (UE). Die UPS ist für alle Funktionen bezüglich der Radiozelle verantwortlich. Das RCS steuert die UPS, um Dienstleistungen zum UE zur Verfügung zu stellen (letztendlich werden die Dienste dem Nutzer des UE zu Verfügung gestellt).
Das RCS terminiert die Control Plane (CP) mit dem Kern-Netz (CN) und die UPS terminiert die User Plane (UP) mit dem CN.
Aus Gründen der Robustheit und Lastverteilung wurde vorgeschlagen, ein m zu n Verhältnis zwischen RCSs und UPSs herzustellen. Dass heißt, ein RCS steuert "n" UPSs, und ein UPS kann durch „m" RCSs gesteuert werden.
Jedoch funktioniert diese Art des Verhältnisses nicht mit gegenwärtigen UMTS-Verfahren und seine tatsächliche Implementierung ist mehr ein Wunsch als eine Wirklichkeit. Die Probleme werden hauptsächlich mit der Tatsache verbunden, dass das UMTS CN mit Bereichs-Identitäts-Konzepten (Location Area, Routing Area, Ser vice Area, usw.) arbeitet, die mit geographischen Bereichen verbunden sind, die wiederum mit NodeB Positionen verbunden sind.
In der R99 Architektur sind NodeBs statisch mit RNCs verbunden, daher sind RNCs statisch mit geographischen Bereichen verbunden. Wenn das CN z.B. ein UE für CS-Dienstleistungen kontaktieren muss, kennt das CN normalerweise die Location Area, in dem dieses UE sich befindet und kann einen Bezug zu einem oder mehreren RNCs herstellen, zu dem/denen es die Paging-Message schickt.
In IPRAN, für das allgemeine m zu n RCS-UPS Verhältnis, kann ein RCS nicht mehr mit einem geographischen Bereich assoziiert werden. Weiterhin, da es den CP zum CN terminiert, kann das CN nicht immer wissen, welchen RCS es für jede Kommunikation (Paging, CS-call, PS session, usw.), die beim UE endet, verwenden muss. Es kann auch nicht angenommen werden, dass das CN einfach jedes RCS verwenden kann, da es nicht weiss, welchen „geographischen Bereich" die NodeBs abdecken, die mit den „n" UPSs verbunden sind, die von diesem RCS kontrolliert werden.
Folglich würde das allgemeine Konzept des m zu n RCS-UPS Verhältnisses strukturelle Veränderungen in den CN und CN-UTRAN Prozeduren erfordern. Das bedeutet aber einen zu großen Aufwand im Verhältnis zum Nutzen dieser Idee.
Die Schlüsseleigenschaft der Erfindung ist die Identifikation der verantwortlichen RCSs falls mehr als eins zuständig sein könnte. Die vorgeschlagene Methode hat minimale Auswirkungen auf vorhandene UMTS Protokolle. Es ist möglich, diesen Entwurf in Einklang mit vorhandenen Bereichs-Konzepten einzuführen.
Die Schlüsselideen dieser Erfindung, die sowohl separat betrachtet werden und in jeder möglicher Kombination verwendet werden können:

1. Es wird vorgeschlagen, die folgenden Rollen für das RCS festzulegen: Primär-RCS: jeder UPS hat nur einen Primär-RCS. Der Primär-RCS wird standardmäßig verwendet, um mit UEs zu kommunizieren, die sich in den Zellen von allem NodeBs unter der Steuerung dieses UPS befinden (UPS Bereich). Vom Standpunkt des CN wird für UE-terminierte Kommunikationen ein RCS auf den geographischen Bereich abgebildet, der durch die UPS gebildet wird, für die dieser RCS der „Primäre" RCS ist. Dieser Bereich wird RCS Bereich genannt, und ist mit einem RNC Bereich in der 3GPP R99 UTRAN Architektur gleichwertig. Sekundär-RCS: jeder UPS hat Null, ein oder mehrere „Sekundäre" RCSs. Ein „Sekundär" RCS wird nur vom CN verwendet, um mit UEs verbunden zu werden die sich im UPS Bereich befinden, wenn der „Primär" RCS nicht erreichbar ist (außer Betrieb oder überbelastet). „Primär" und „Sekundär" sind Rollen eines RCS, nicht unterschiedliche Arten von RCSs. Ein RCS kann zu einer Menge von UPSs „Primär" sein, und „Sekundär" zu einer Menge von RCSs. Wenn der UE den Kommunikationsaufbau initiiert, wird die Auswahl eines RCS vom UPS durchgeführt, Falls ein Verbindungsaufbau beim UE terminiert, so wird die Auswahl einen RCS vom CN durchgeführt.
2. Es wird weiterhin vorgeschlagen, dass ein RCS, der einem anderen (primären) RCS als Sekundärer dient, den vollständigen RCS Bereich von diesem (Primären) RCS umfassen sollte. Jedoch werden auch andere Deckungkonfigurationen vorgesehen. Z.B. mehrere Sekundär-RCSs, die zusammen den vollen Primär-RCS Bereich abdecken, jeder einzelne aber nur einen Teilbereich umfasst.
3. Es wird weiterhin vorgeschlagen, dass wenn das CN ein Verfahren in Richtung eines RCS beginnt, z.B., um eine UE-terminierte Kommunikation zu starten oder zu Service-Area-Boradcast (SAB)-Zwecken, dann übermittelt das CN Informationen über den RCS Bereich, der durch das Verfahren angefordert wird. Das RCS ver wendet diese Informationen, um zu ermitteln, ob er gebeten wird, als Primär-RCS zu agieren oder als Sekundär-RCS. Eine Möglichkeit für diesen 3. Antrag ist es, den RNC Bezeichner (RNC ID) definiert in 3GPP R99 (siehe 3GPP TS 25.413), zu diesem Zweck zu benutzen. Dieses würde die geringste Auswirkung auf die gegenwärtigen 3GPP Protokolle und Implementierungen haben, da kein neuer Bezeichner erforderlich wäre. Als Beispiel für die Verwendung der obigen Idee, würde das gänzliche Fehlen einer RNC Identifikation, oder auch das Vorhandensein der RNC Identifikation für den RCS bedeuten, dass der RCS gebeten wird, eine „Primär-Rolle einzunehmen. Das Vorhandensein einer RNC-Identifikation die nicht zu diesem RCS gehört, würde dagegen bedeuten, dass das RCS gebeten wird, eine „Sekundär"-Rolle für den RCS einzunehmen, zu dem die RNC-Identifikation zugehörig ist.
4. Das CN muss wissen, welche RCSs als „Sekundär" zu jedem bestimmten RCS dienen können. Für eine CN Infrastruktur, die von der RCS/UPS UTRAN Architektur nichts weiss, könnte eine Inter-Working Funktion (IWF) zwischen dem bestimmten RCS und diesem CN verwendet werden, um die Existenz der „Primär-" und „Sekundär"-Rollen des RCS „zu verstecken". Der Gebrauch einer IWF ist auch nötig, um eine Integration mit der „legacy" CN-Infrastruktur zu ermöglichen.
6. Ein RCS kann auch nur „Sekundär"-Rollen haben, und keine „Primär"-Rolle erfüllen. Dies könnte aus Gründen der Redundanz erfolgen (z.B. um die Robustheit zu erhöhen oder um mit Höchstlast-Situationen fertig zu werden).
5. Es wird auch vorgeschlagen, sinnvolle Methoden zur Auswahl des Sekundär-RCS zu benutzen, um die Last eines Primär-RCS zu teilen, wenn der Primäre RCS ausfällt oder überlastet wird. Eine Methode um die Lastverteilung für die UPSs des ausgefallenen RCS sicherzustellen ist es, einen zufällig gewählten Sekundär-RCS auszuwählen (wenn mehr als einer vorhanden ist). Andere Methoden sind ebenfalls denkbar.

Die Vorteile des neuen Features) der Erfindung und Vorteile gegenüber vorheriger Technologie sind:
Die Idee in dieser Erfindung ermöglicht es, ein m zu n RCS-UPS Beziehung unter Erhalt der Schlüsselvorteile solch eines Verhältnisses einzuführen. Einige dieser Schlüsselvorteile sind:

– Datenverkehr wird im Falle des RCS Ausfalles übernommen: Wenn ein RCS ausfällt, können andere RCSs noch Telekommunikationsdienste in dem Bereich zur Verfügung stellen, der durch den ausgefallenen RCS umfasst wird.
– RCS Lastausgleich: Wenn ein RCS vorübergehend überlastet wird, können andere RCSs des Bereichs, der durch den überbelasteten RCS umfasst wird, weiterhin Telekommunikationsdienste zur Verfügung stellen.

Weitere Vorteile sind möglich.
Ein m zu n RCS-UPS Verhältnis verbessert die Robustheit und Verfügbarkeit von TK-Dienstleistungen in einem vom RCS umfassten Bereich. Dieses kann in der Implementierung zu Kostenreduktion und zur Minderung der Netzwerk-Komplexität führen, da Redundanz im m zu n Verhältnis eingebaut ist und nicht in jeden Netzwerkknoten eingebaut werden muss. Die RCS/UPS Aufteilung eines RNC und des m zu n RCS-UPS Verhältnisses sind bereits definierte Konzepte in 3GPP, die durch diese Erfindung realisierbar werden.
Es gibt nun verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die dem Patentanspruch 1 nachgeordneten Patentansprüche und andererseits auf die nachfolgende Erläuterung eines bevorzugten Ausführungsbeispiels des erfindungsgemäßen Verfahrens zur Konfigurierung eines Netzwerks zu verweisen. In Verbindung mit der Erläuterung des bevorzugten Ausführungsbeispiels des erfindungsgemäßen Verfahrens zur Konfigurierung eines Netzwerks werden auch im Allgemeinen bevorzugte Ausgestaltungen und Weiterbildungen der Lehre erläutert.
Das erfindungsgemäße Verfahren wird in diesem Ausführungsbeispiel im Mobilfunkbereich, nämlich im Bereich eines Third Generation – 3G – Standards, dem UMTS – Universal Mobile Telecommunications System –, angewendet. Das UMTS-Netzwerk umfasst Endgeräte, d.h. das User Equipment – UE. Dies sind in diesem Ausführungsbeispiel Mobiltelefone. Das UE kommuniziert mit einem Netzwerkteil des UMTS-Netzwerks, nämlich einem Funknetz, dem UTRAN – UMTS Terrestrial Radio Access Network.
Das UTRAN ist in Subsysteme unterteilt, die zum einem Basisstationen, genannt Node B, sowie Radio Network Controller – RNC – aufweisen. Neben der Teilnehmerverwaltung und Signalannahme ist es die Aufgabe des UTRAN, die empfangenen Daten an das zentrale Netzwerk, an das sogenannte Core Network – CN – weiterzugeben, in dem die eigentliche Datenvermittlung an ein anderes Mobiltelefon im UMTS-Netzwerks oder an einen externen Teilnehmer im Telefonfestnetz stattfindet.
Bei dem hier vorliegenden UTRAN ist eine funktionalen Teilung des UTRAN vorgenommen, das im Folgenden als IPRAN – Internet Protocol based Radio Access Network – bezeichnet wird. In der IPRAN-Technologie wird der zum Subsystem gehörende Leitrechner, der RNC, in mehrere R-Server, die sogenannten Radio Control Server – RCS – und mehrere U-Server, die sogenannten User Plane Servers – UPS – unterteilt. Das RCS übernimmt hierbei die Überwachung und Regelung aller mit dem UE verbundenen Funktionen und das UPS übernimmt alle mit den Netzwerkteilen, den Basisstationen, verbundenen Funktionen. Die RCS kontrollieren hierbei die UPS, um den UE bzw. dem Benutzer des UE Dienste zur Verfügung zu stellen.
Zur Erhöhung der Robustheit und um eine Verteilung der Belastung zu erreichen, liegt eine m zu n Beziehung zwischen den RCS und den UPS vor. Dabei kontrolliert ein RCS n UPS und ein UPS kann von m RCS kontrolliert werden. Die Anzahl n ist in diesem Ausführungsbeispiel kleiner als die Anzahl m. Es könnte allerdings auch n größer als m sein.
In dem IPRAN ist bei einer m-zu-n RCS-UPS-Beziehung ein RCS nicht direkt mit einem geographischen Gebiet verbunden und da der RCS die Control Plane CP für das CN bestimmt, ist dem CN nicht bekannt, welchen RCS es verwenden muss, um eine für irgendein UE bestimmte CS-Anrufe aufzubauen. Auch kann das CN nicht jeden RCS verwenden, da es dem CN nicht bekannt ist, welche geographisches Gebiet die Basisstationen – Node B – abdecken, die an die n UPS angebunden sind, das dieser RCS kontrolliert.
Erfindungsgemäß wird jedem UPS ein Primär-RCS zur Regelung der Kommunikation der in Reichweite der Basisstation befindlichen UE zugeordnet. Dieser Primär-RCS ist der Standart-RCS, der dazu verwendet wird, um mit allen UE zu kommunizieren, die sich in der Reichweite der Basisstationen aufhalten, die von dem entsprechenden UPS geregelt werden. Für das CN bedeutet dies, dass ein RCS für UE terminierte Verbindungen mit dem geographischen Gebiet verbunden ist, das durch alle UPS abgedeckt wird, für die der entsprechende RCS der Primär-RCS ist. Der RSC ist hierbei immer gleich ausgestaltet sein, so dass er bezüglich eines UPS ein Primär-RCS ist, währenddessen der gleiche RCS bezüglich mehrerer anderer UPS ein Sekundär-RCS ist. Dies bedeutet eine besonders einfache und technisch wenig aufwendige Implementierung.
Ein solches geographisches Gebiet wird als RCS-Gebiet bezeichnet und entspricht einem RNC-Gebiet in einer 3GPP – Third Generation Partnership Project – R99-UTRAN-Architektur. Diese Ausgestaltung ist besonders vorteilhaft, da nunmehr die Datenübertragung bei einem Ausfall des RCS aufgrund von überhöhtem Datenaufkommen oder Fehlfunktionen des RCS über andere RCS vorgenommen werden kann, die das gleiche Netzwerkgebiet abdecken wie der Primär-RCS. Der Primär-RCS dient hierbei zur Regelung sämtlicher Kommunikation aller sich in der Reichweite der Basisstation , d.h. der Radiozelle, befindlichen UE.
Jedem UPS ist zusätzlich zum Primär-RCS ein Sekundär-RCS zugeordnet. Der Sekundär-RCS übernimmt für den Fall, das der Primär-RCS aufgrund einer Fehlfunktion oder einer Überlastung nicht erreichbar ist, dessen Funktion. In diesem Ausführungsbeispiel decken der Primär-RCS und der Sekundär-RCS die gleichen Teile des Netzwerks ab. Die Teile des Netzwerks sind in diesem UMTS-Netzwerk die durch die den Primär-RCS abgedeckten geographischen Gebiete. Eine besonders effektive Ausnutzung der Systemressourcen wird durch die Zuordnung des Primär-RCS eines UPS zu einem anderen UPS als Sekundär-RCS erreicht.
Der CN übermittelt beim Aufbau einer Kommunikation Informationen an den RCS, die definieren, ob er als Primär- oder Sekundär-RCS dient. Dies erfolgt, wenn das CN Vorgänge hinsichtlich eines RCS startet, z.B. eine UE terminierte Kommunikation aufbaut oder aus Gründen des Service Area Broadcast – SAB. Die Informationen sind Informationen über das RCS-Gebiet, das für die entsprechenden Funktionen und Dienste benötigt wird. Hierbei wird die RNC-Kennung – RNC-Identifier, RNC-ID – verwendet, die in dem 3GPP-R99-Standart definiert wird. Dies hat die geringsten Einwirkungen auf die bestehenden 3GPP-Protokolle und Implementierungen, da keine neue Kennung verwendet werden muss. In diesem Ausführungsbeispiel bedeutet das Vorhandensein der RNC-ID eines bestimmten RCS, dass dieser betroffene RCS ein Primär-RCS sein soll. Und das Vorhandensein einer RNC-ID, die nicht mit diesem RCS verbunden ist, bedeutet, dass dieser RCS als Sekundär-RCS für den betroffenen Primär-RCS handeln soll.
Der Sekundär-RCS übernimmt die Funktionen des Primär-RCS, wenn der Primär-RCS nicht funktionsfähig ist. Dies ist bei Überlastung oder Fehlfunktionen des Primär-RCS der Fall. Der Sekundär-R-Server ersetzt dann sämtliche Funktionen des Primär-R-Servers. Somit ist ein kontinuierlicher Betrieb des Netzwerks gewährleist und die Robustheit des Netzwerks erhöht.
Die Auswahl eines RSC als Primär-R-Server erfolgt durch den UPS, wenn es sich bei den abzuarbeitenden Vorgängen, um Vorgänge handelt, die von dem UE initiiert werden, welche die RCS-Auswahl auslösen. Zusätzlich erfolgt die Auswahl eines R-Servers als Primär-R-Server durch das zentrale Netzwerk dann, wenn es sich um Vorgänge im Netzwerk handelt, die UE terminiert sind, welche die RCS Auswahl auslösen.
Zwischen den R-Servern und/oder dem zentralen Netzwerk wird eine Inter-Working-Funktion verwendet, da es dem zentralen Netzwerk nicht bekannt ist, welcher RCS als Sekundär-RCS zu einem bestimmten Primär-RCS handelt.
Hinsichtlich weiterer vorteilhafter Ausgestaltungen und Weiterbildungen der erfindungsgemäßen Vorrichtung wird zur Vermeidung von Wiederholungen auf die allgemeine Beschreibung sowie auf die beigefügten Patentansprüche verwiesen.
Schließlich sei ausdrücklich darauf hingewiesen, dass das voranstehend beschriebene Ausführungsbeispiel lediglich zur Erörterung der beanspruchten Lehre dient, diese jedoch nicht auf das Ausführungsbeispiel einschränkt.

Claims

Verfahren zur Konfigurierung eines Netzwerks über das Daten übertragen werden, vorzugsweise eines UMTS-Netzwerks, wobei das Netzwerk ein zentrales Netzwerk und/oder mindestens einen Netzwerkteil umfasst, der die Kommunikation zwischen dem zentralen Netzwerk und mindestens einem Endgerät ermöglicht, wobei der Netzwerkteil mindestens zwei Subsysteme aufweist, die zumindest einen Leitrechner zur Verwaltung der Ressourcen des Netzwerksteils und/oder der Datenübertragung aufweisen und wobei die Leitrechner in mindestens einen R-Server zur Verwaltung der Funktionen und/oder Dienste der Endgeräte und/oder mindestens einen U-Server zur Verwaltung der vom Subsystem benötigten Funktionen, unterteilt sind, dadurch gekennzeichnet, dass jedem U-Server ein Primär-R-Server zur Regelung der Kommunikation der vorzugsweise in dem Subsystem befindlichen Endgeräte zugeordnet wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Primär-R-Server zur Regelung sämtlicher Kommunikation der in dem Subsystem befindlichen Endgeräte dient.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass jedem U-Server zusätzlich zum Primär-R-Server mindestens ein Sekundär-R-Server zugeordnet wird.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Primär-R-Server und der Sekundär-R-Server die gleichen Teile des Netzwerks abdecken.
Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass ein Primär-R-Server eines U-Servers einem anderen U-Server als Sekundär-R-Server zugeordnet wird.
Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass ein R-Server nur einem U-Server als Sekundär-R-Server zugeordnet wird.
Verfahren nach einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass das zentrale Netzwerk vorzugsweise beim Aufbau einer Kommunikation Informationen an einen R-Server übermittelt, die definieren, ob dieser R-Server als Primär- oder Sekundär-R-Server dient.
Verfahren nach einem der Ansprüche 3 bis 7, dadurch gekennzeichnet, dass ein Sekundär-R-Server die Funktionen des Primär-R-Servers übernimmt, wenn der Primär-R-Server nicht funktionsfähig ist.
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Auswahl eines R-Servers als Primär-R-Server durch den U-Server erfolgt.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Auswahl eines R-Servers als Primär-R-Server durch das zentrale Netzwerk erfolgt.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass zwischen den R-Servern und/oder dem zentralen Netzwerk eine Inter-Working-Funktion verwendet wird.