-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren, ein System und ein
Netzwerkelement zum Adressieren eines auf eine Zelle bezogenen Servers in
einem Funkzugriffsnetzwerk (bzw. Radio Access Network (RAN) wie
z.B. einem UTRAN (UMTS Terristrisches RAN), einem GERAN (GSM EDGE
RAN), einem IP (Internetprotokoll) bezogenen RAN oder jedem anderen
zellenförmigen
RAN.
-
HINTERGRUND
DER ERFINDUNG
-
Da
die Popularität
des Internets gewachsen ist und mobiles Internet für Text basierende
Informationen und Bildbenachrichtigung schon Realität sind, hat
die Industrie ihren Schwerpunkt auf die Konstruktion des kosteneffizientesten
Netzwerks für
noch anspruchsvollere Multimedia-Dienste gerichtet. IP-basierende
Netzwerke werden von vielen als der beste Weg nach vorne betrachtet
und Forschung und Entwicklung der Netzwerktechnologie liegen bei
und sind stark um IP-Technologie zentriert.
-
Die
Entwicklung eines IP-basierenden Funkzugriffsnetzwerk wird eine
Anzahl von Funkzugriffsnetzwerktechnologien einschließlich der
zweiten Generation (2G), der dritten Generation (3G) und das Ortsbereichsfunkzugriffsnetzwerk
bzw. Wireless Local Area Network (WLANs) zusammenführen. Netzwerkbetreiber
wechseln von leitungsvermittelter zur paketvermittelten Technologie,
während
IP-basierende Netzwerke
eine schnelle, flexible und kosteneffiziente Expansion des Funkzugriffs
benötigen.
-
IP-basierende
Funkzugriffsnetzwerk können als
weiche Entwicklung der bestehenden GSM (Globalen System für mobile
Kommunikation bzw. Global System for Mobile communications)-, EDGE
(verbesserte Datenrate für
GSM-Entwicklung
bzw. Enhanced Data Rates for GSM Evolution)- und WCDMA (Breit band
codegeteilter Mehrfachzugriff bzw. Wideband Code Division Multiple
Access)-Netzwerken eingeführt
werden. Entscheidende Vorteile solcher IP-basierender Funkzugriffsnetzwerke sind
ein verteilter Aufbau mit einer Trennung von Anwender- und Steuer-Ebenen
(was unbegrenzte Skalierbarkeit ohne Flaschenhälse bietet), Integration verschiedenen
Technologien für
Funkschnittstellen in einem einzigen Funkzugriffsnetzwerk, gemeinsame
Verwaltung der Funkressourcen für
eine optimale Verwendung der Funkressourcen, Steuerung der Dienstqualität (QoS)
und Netzwerkautomatisierung, offene Schnittstellen für Netzwerke
mit mehreren Anbietern und Kompatibilität zu bestehenden Übertragungsnetzen.
-
In
derartigen neuen Funkzugriffsnetzwerken führt der Standardisierungskörper (beispielsweise 3GPP
(Partnerschaftsprojekt der dritten Generation bzw. 3rd Generation
Partnership Project)) einige „Server" auf Steuerebene
ein, die nur RAN-Funktionen
besitzen, wie beispielsweise eine dienende mobile Lokalisierungszentrale
(bzw. Serving Mobile Location Centre, SMLC) zum Durchführen der
Positionsbestimmungsfunktion für
die Mobilstation (MS) oder die Anwenderausstattung (UE) in dem Funkzugriffsnetzwerk
und einen gemeinsamen Funkressourcenverwalter (bzw. Common Radio
Resource Manager, CRRM) oder gemeinsamen Ressourcenverwaltungs-Server
(bzw. Common Resource Manager Server, CRMS) zum Durchführen der
Funkressourcenverwaltungsalgorithmen basierend auf dynamischen Statusinformationen
der Zellen, die nicht zur selben Basis-Sende-/Empfangs-Station (bzw.
Base Transceiver Station, BTS) oder Funknetzwerksteuerung bzw. Funktnetzwerks-Kontrollrechner
(bzw. Radio Network Controller, RNC) gehören. Die SMLC und der CRMS
sind einem bestimmten Bereich zugeordnet, wo sie die Steuerung über eine
Aufenthaltsortsmesseinheit bzw. die Funkressourcen der Zellen inne
haben.
-
Eine
dienender RNC (bzw. Serving RNC, SRNC), die eine UE steuert, kann
verwenden die SMLC zur Berechnung der Position der UE oder den CRRM
für die
Priorisierung der Übergabe-
bzw. Handover-Ziel-Zelle(n), die durch die UE durchzuführen ist
(oder jede andere Operation, die Einfluss auf die durch die UE verwendeten
Funkressourcen hat). Dabei muss die SRNC mit der SMLC und dem CRMS, die
der bzw. den durch die UE verwendete(n) Zelle(n) zugeordnet sind,
Kontakt aufnehmen. Jedoch kann die UE Zellen verwenden, die nicht
durch die SRNC gesteuert werden. In diesem Fall, falls eine Zelle
von der UE verwendet wird, die durch eine Drift-RNC (DRNC) gesteuert
wird, welche ein beliebiger RNC ist, ein anderer als der SRNC, der
die durch die UE verwendeten Zellen steuert, durch Bereitstellen
nur von Ressourcen und Funkschicht 1 (L1)-Funktionen für die UE-Verbindung derart,
um Daten transparent zwischen der Schnittstelle (z.B. Iu-Schnittstelle),
welche das Funkzugriffsnetzwerk mit einem Kernnetzwerk (CN) und
der Schnittstelle (beispielsweise Iur-Schnittstelle), welche die
DRNC mit der SRNC verbindet, zu routen. Es sei angemerkt, dass ein SRNC
jeden der anderen RNCs als DRNC verwenden kann.
-
So,
falls die SRNC wünscht,
die SMLC oder den CRMS, die der aktuellen durch die UE verwendeten
Zelle zugeordnet sind oder mit ihr in Beziehung stehen (beispielsweise
für mobile
Aufenthaltsortsbestimmung, für
Priorisierung des Handover-Kandidaten oder andere damit in Verbindung
stehenden Operationen), zu kontaktieren, tritt das Problem auf,
dass die Adresse des CRMS oder der SMLC, welche die Drift-Zelle
steuern, der SRNC nicht zur Verfügung steht.
-
Dieses
Problem ist unbekannt, da derartige gemeinsame Server (CRMS und
SMLC) noch nicht im 3GPP spezifiziert sind. Die Diskussion über die Standardisierung
der SMLC hat sich bis jetzt auf ein Verfahren zur Bestimmung des
Aufenthaltsorts konzentriert, welches es nicht erfordert, dass die
SMLC Messungen von der Aufenthaltsortmesseinheit (LMU) empfängt, somit
ohne mit diesem Problem konfrontiert zu werden.
-
Dieses
Problem kann durch eine Vorkonfigurierung der CRMSs und/oder der
SMLCs, die jede eigene und jede mögliche Drift-Zelle (oder jede
mögliche
Drift-RNC) in der
RNC steuern, gelöst
werden. Jedoch erfordert dies eine Konfigurationstabelle, die schwierig
zu verwalten und neu zu konfigurieren ist, sobald sich die Netzwerkkonfiguration ändert. Alternativ
könnte
das Problem gelöst
werden, indem die SRNC die Dienstanforderung (Aufenthaltsortbestimmung,
Handover-Kandidat)
an eine/einen (oder eine/einen von) vorbestimmten SMLC(s)/CRMS(s) sendet,
die/der für
die Weiterleitung für
die CMRS/SMLC relevanten Daten Sorge trägt. Nichts destoweniger wird
eine Konfigurationstabelle, welche die vorherbestimmten CRMS(s)/SMLC(s)
festlegt noch benötigt.
Schließlich
könnte
die SRNC den Aufenthaltsort/die Handover-Priorität an die DRNC über die
Iur-Schnittstelle weiterleiten. Die DRNC verwendet dann die SMLC
und den CRMS für
die Auswertung. Jedoch führt
dies zu einer Verzögerung
und Extraverarbeitung der DRNC und damit zu einer reduzierten Dienstqualität (QoS).
-
Dieses
Problem wurde oben für
eine UTRAN-Umgebung beschrieben. In der IP-RAN-Umgebung ist dieses Problem sogar
größer, da
die Anzahl der IP-BTSs (IP-Basis-Sende-/Empfangs-Stationen)
größer als
die Anzahl der RNCs ist. Im IP-RAN, handelt
die IP-BTS in vielen Aspekten ähnlich
wie eine RNC, sodass die Anzahl der Drift-BTSs (DBTSs) sehr groß werden
kann.
-
Das
Dokument Toskala A. et al., „IP
based UTRAN Architecture" TSG
RAN#10 TDOC RP-00-0712 [online] 6–8 Dezember 2000, Seiten 1 bis
8, XP002200942 Bangkok, Thailand, zeigt kurz den Aufbau und die
Motivation für
den IP-basierenden
UTRAN-Aufbau. Weiter wird ein Verfahren zur dynamischen Zuordnung
zwischen einem Funkzugriffsnetzwerk-Sever und einem Knoten in einem IP-basierenden
UTRAN-Aufbau offenbart. Auch Skalierbarkeit und die Verwendung eines
gemeinsamen Ressourcen-Verwalters werden erwähnt. Jedoch, während dieses
Dokument die Aspekte der Netzwerktopologie veranschaulicht, schweigt
es sich aus über
Adress-Angelegenheiten.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, eine, eine Adressierungs-Prozedur bereitzustellen,
mittels welcher der richtige Server im Funkzugriffsnetzwerk adressiert
werden kann, insbesondere im Fall, dass die Verbindung durch einen
oder mehrere DRNCs oder DBTSs gehandhabt wird.
-
Diese
Aufgabe wird gelöst
durch ein Verfahren gemäß Anspruch
1. Entsprechend wird die obige Aufgabe gelöst durch ein Netzwerkelement
gemäß Anspruch
10. Zusätzlich
hierzu wird die obige Aufgabe gelöst durch ein Netzwerkelement
gemäß Anspruch
12. Außerdem
wird die obige Aufgabe gelöst durch
ein System gemäß Anspruch
14.
-
Entsprechend
wird immer der richtiger Server basierend auf der Server-Kennzeichnung, die
in der von der Drift-Steuerungs-Funktionalität gegebenen Antwortnachricht
gegeben worden ist, adressiert. Eine Konfigurationstabelle und die
damit verbundene Schwierigkeit, diese zu verwalten und zu rekonfigurieren,
wenn sich die Konfiguration des Netzwerks verändert, kann so vermieden werden.
Weiter werden dynamische Konfigurationen, dynamischer Fehlerausgleich
usw. ermöglicht.
-
Aufgrund
der Tatsache, dass die dienende Steuerung direkt den Server (SMLC/CRMS)
kontaktieren kann, können
Verzögerung
und Extraverarbeitung an der Drift-Zelle vermieden werden.
-
Weitere
Ausführungsbeispiele
und Vorteile werden durch die abhängigen Ansprüche ersichtlich.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Im
folgenden wird die vorliegende Erfindung in größerem Detail basierend auf
bevorzugten Ausführungsbeispiele
mit Bezug auf die begleitenden Zeichnungen beschrieben, in denen
-
1 einen
Grundaufbau eines Funkzugriffsnetzwerk zeigt, in dem die vorliegende
Anmeldung implementiert werden kann; und
-
2 ein
Signalisierungsdiagramm zeigt, welches der Adressierungs-Prozedur gemäß dem bevorzugten
Ausführungsbeispiel
entspricht.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
-
Das
bevorzugte Ausführungsbeispiel
wird nun unter Verwendung der UTRAN-Terminologie beschrieben, jedoch ist
die folgende Beschreibung für jedes
zellenförmige
Zugriffsnetzwerke mit der folgenden Notationsänderung gültig. Die beschriebene RNC
kann durch irgendeine Funkressourcen-Steuerungs-Funktionalität ersetzt werden, wie beispielsweise
eine IP BTS, die SRNC kann durch eine beliebige Steuerungs-Funktionalität ersetzt
werden, wie beispielsweise eine dienende IP BTS, die für die Steuerung
eines mobilen Endgerätes
verantwortlich ist, die DRNC kann durch eine beliebige Steuerungs-Funktionalität ersetzt
werden, wie beispielsweise eine Drift IP BTS, die für die Steuerung
einer Zelle verantwortlich ist, die SMLC kann ersetzt werden durch
irgendeine Art von Server zur Positionsberechnung und der CRRM/CRMS
kann ersetzt werden durch irgendeine Art von Server für die Handover-Priorisierung
oder ähnliches.
-
In 1 ist
der Aufbau eines Funkzugriffsnetzwerks gezeigt, wo eine UE 40,
beispielsweise ein mobiles Endgerät oder irgendeine Funk verbundene Endgeräteeinrichtung, über eine
Basisstation oder einen Knoten B (nicht gezeigt) einer ersten Zelle
c1 mit einer DRNC 20 verbunden ist, die für die Steuerung der
Funkressourcen in vier Zellen c1 bis c4 verantwortlich ist. Eine
SRNC 10, die für
die Steuerung der Kernnetzwerkschnittstelle (beispielsweise Iu-Schnittstelle)
und zum Abschließen
der Funkressourcen-Steuerung (RRC) für die UE 40 verantwortlich ist,
ist mit der DRNC 20 mit einer Iur-Verbindung auf Anwenderebene
verbunden. In der in 1 gezeigten Konfiguration steht
ein erster CRMS 30 mit einer ersten Zelle c1 und einer
zweiten Zelle c2 in Beziehung und ein zweiter CRMS 31 steht
mit einer dritten Zelle c3 und einer vierten Zelle c4 in Beziehung.
Es sei angemerkt, dass obwohl zwei CRMSs in diesem Beispiel gezeigt
sind, es nicht erforderlich ist, dass mehrere CRMSs bereitgestellt
sind, die mit einer DRNC in Beziehung stehen.
-
Wenn
die Iur-Verbindung auf Anwenderebene zwischen der SRNC 10,
welche die UE 40 kontrolliert, und der DRNC 20,
welche die Zellen c1 bis c4 steuert, aufgebaut wird, gibt die DRNC 20 an
die SRNC 10 die Adresse der SMLC und/oder des CRMS zurück, beispielsweise
den ersten CRMS 30 oder den zweiten CRMS 31, der
für den
Bereich, in dem sich die Drift-Zelle (die Zelle, die von der DRNC 20,
die durch die UE 40 verwendet wird, gesteuert wird) befindet,
verantwortlich ist. Die Adresse kann in der „Antwort" der Iur-Aufbauprozedur auf Anwenderebene
enthalten sein, beispielsweise der Funkverbindungs-Aufbauantwort (bzw.
Radio Link Setup Response), der Funkverbindungs-Hinzufügungsantwort (bzw. Radio Link
Addition Response), der Gemeinkanal-Aufbauantwort (bzw. Common Channel Setup Response)
oder jeder anderen geeigneten Antwortmitteilung der Aufbauprozedur.
Eine detaillierte Beschreibung der Iur-Aufbauprozedur kann aus der
aktuellen 3GPP-Spezifikation TS 25.423 des Iur-Signalisierungs-Protokolls
für den
Funktnetzwerk-Untersystem- Anwendungsteil
(bzw. Radio Network Subsystem Application Part, RNSAP) erhalten
werden.
-
2 zeigt
ein Signalisierungsdiagramm, das eine RNSAP-Signalisierung zeigt,
die durch die SRNC 10 initiiert worden ist, um die Server-Adresse des
ersten oder zweiten CRMS 30, 31 zu erhalten.
-
Der
Aufbau der ersten Funkverbindung mit der DRNC 20 kann durch
Verwendung einer der folgenden Prozeduren durchgeführt werden.
Eine Gemeintransportkanal-Ressourcen-Initialisierung kann in Richtung
der DRNC 20 durchgeführt
werden, unter Verwendung eines RACH/FACH (wahlfreier Zugriffskanal
bzw. Random Access Channel/Weiterleitungs-Zugriffskanal bzw. Forward
Access Channel), falls die UE 40 sich in Zustand mit einem
Gemeinkanal befindet. Alternativ, wie in 2 angezeigt,
kann ein Funkverbindungs (bzw. Radio Link, RL)-Aufbau durch Übertragen
einer RL-Aufbauanforderung an die DRNC 20 initiiert werden,
sobald sich die UE 40 im fest zugeordneten Zustand befindet
und die Drift-Zelle, d.h. die erste Zelle c1, die erste ist, die
im DRNC 20 verwendet wird. Als eine andere Alternative
kann eine Funkverbindungs-Hinzufügungs-Prozedur durch die
SRNC 10 initiiert werden, sobald die UE 40 sich
im fest zugeordneten Zustand befindet und die Drift-Zelle c1 nicht
die erste ist, die in dieser DRNC 10 verwendet wird.
-
Dann
ist die DRNC 20 eingerichtet, in die Antwortnachricht dieser
Prozeduren (beispielsweise eine Gemeintransport-Kanal-Ressourcen-Antwortnachricht,
eine Funkverbindungs-Aufbau-Antwortnachricht (wie in 2 angezeigt),
Funkverbindungs-Hinzufügung-Antwortnachricht
oder irgendeine andere geeignete Antwortnachricht) Kennungen der
Signalisierungs-Adressen des CRMS (beispielsweise des ersten und/oder
des zweiten CRMS 30, 31) und/oder der für die Steuerung
der Drift-Zelle c1 verantwortlichen SMLC hinzu- oder einzufügen.
-
Basierend
auf den empfangenen Kennungen oder Signalisierungsadressen kann
die SRNC 10 nun eine Dienstanforderung oder Antwort (beispielsweise
Handover-Kandidat-Priorisierung) an den zugeordneten CRMS übertragen,
wobei eine beliebige geeignete Signalisierung, beispielsweise eine RAN-Anwendungsteil
(bzw. RAN Application Part, RANAP)-Signalisierung verwendet wird.
-
Der
DRNC 20 kann genauso gut andere Informationen zurückgeben,
die es erlauben, dass die SRNC 10 die Adresse des Servers
enthält,
beispielsweise die Signalisierungs-Verbindungs-Steuerteil (bzw.
Signaling Connection Control Part, SCCP)-Adresse (ähnlich dem
globalen Titel bzw. Global Title), eine durch den Netzwerkbetreiber
zugeordnete Kennzeichnung (ID), eine DNS (Domain Name Server)-Adresse
oder Kennzeichnung, eine IP-Adresse und Portnummer oder ähnliches.
-
Darüber hinaus
kann die DRNS 20 ihre eigene Adresse (oder nichts) zurückgeben
für den
Fall, dass sie die Funktion der SMLC oder CRMS eingebaut hat (welche
optionale Netzwerkelemente sind) oder im Fall, dass sie es aus irgendeinem
Grund wünscht,
die Dienstanforderung selbst zu erhalten.
-
Falls
die DRNC 20 mehrere als einen CRMS/eine SMLC, die der Drift-Zelle
c1 zugeordnet sind, besitzt, kann sie einen/eine von Fall zu Fall
auswählen
(zur Lastteilung, zum dynamischen Fehlerausgleich etc.) oder sie
kann mehr als eine Adresse für
den CRMS und/oder die SMLC zurückgeben,
und die SRNC 10 kann auswählen, welcher/welche zu verwenden
ist.
-
Für den Fall,
dass der CRMS/die SMLC Steuerungen (RNC) anstelle von Zellen zugeordnet sind
(vereinfachterer Aufbau), werden die Adressen oder IDs in der RL
Hinzufügung-Antwortnachricht nicht
benötigt,
da die SRNC 10 diese IDs oder Adressen schon empfangen
hat, sobald die erste Funkverbindung in der DRNC 20 mit
der RL Aufbau-Prozedur aufgebaut worden ist.
-
Im
Fall eines Softhandover in der DRNC 20 (die einer RL-Hinzufügung entspricht)
können
die zwei Handover-Zellen in der DRNC 20 zwei verschiedenen
Servern zugeordnet werden. Dann kann die DRNC 20 entweder
die ID oder die Adresse der Server, die beide Zellen steuern oder
nur eine ID oder Adresse des Servers, der für die Verbindung verwendet
werden soll, zurückgeben.
-
Wie
bereits erwähnt,
kann die vorliegende Erfindung in jedem beliebigen Funkzugriffsnetzwerk eingesetzt
werden und ist nicht auf die spezifischen Elemente des Funkzugriffsnetzwerk
gemäß den bevorzugten
Ausführungsbeispielen
beschränkt.
Die Erfindung kann auf andere „Server" verallgemeinert werden,
die in zukünftige
zellenförmige
Funkzugriffsnetzwerken eingefügt
werden können.
Die Namen der verschiedenen funktionellen Einheiten, wie beispielsweise
die RNC, die BSC und die BTS können in
verschiedenen zellenförmigen
Netzwerken unterschiedlich sein. Die im Kontext der bevorzugten
Ausführungsbeispiele
verwendeten Namen sind nicht dazu vorgesehen, die Erfindung zu begrenzen
oder zu beschränken.
Allgemein kann jede logische Schnittstelle zwischen zwei Netzwerkelementen,
die verantwortlich ist für
die Steuerung der Verwendung und Integrität der Funkressourcen, anstelle
der beschriebenen Iur-Schnittstelle verwendet werden. Außerdem kann
irgendeine Zwischenverbindung zwischen einem Netzwerkelement, das
für die
Steuerung der Integrität
der Funkressourcen und ein Kernnetzwerk verantwortlich ist, anstelle
der Iur-Schnittstelle verwendet werden. Das beschriebene Drift-Netzwerkelement
kann jedes beliebige Netzwerkelement sein, welches ein dienendes
Netzwerkelement mit Funkressourcen unterstützt, sobald die Verbindung
zwischen dem Funkzugriffsnetzwerk und der Anwenderausstattung es
erfordert, dass Zellen, die durch dieses Netzwerkelement gesteuert
werden, genutzt werden. Das dienende Netzwerkelement kann jedes
beliebige Netzwerkelement sein, welches die Kernnetzwerk-Schnittstelle
abschließt
und für
die Funkressourcen-Steuerungsverbindung zwischen einer Anwender-Ausstattung
und dem Funkzugriffsnetzwerk verantwortlich ist. Die bevorzugten
Ausführungsbeispiele
können
daher innerhalb des Bereichs der angehängten Ansprüche variieren.