-
Hintergrund der Erfindung
-
Technisches Gebiet
-
Die
vorliegende Erfindung betrifft Echtzeit-Datenübertragungssysteme und -verfahren.
-
Allgemeiner Stand der Technik
-
Die
Struktur von Telefonnetzen, die die Architektur der industriellen
Fokusgruppe des Internet-Protokolls der dritten Generation (3G IP)
und die Architektur des Partnerschaftsprojekts der dritten Generation
(3G PP) verwenden, ist dergestalt, daß jeglicher Voice-Over-Internet-Protokoll-Verkehr (VoIP)
eine relativ lange Route in dem Netz durchläuft. Wie zum Beispiel in 1 gezeigt,
nimmt also VoIP-Verkehr, der an einer Mobilstation (T1) 2 eingeleitet
wird und für
eine Zielstation (T2) 14 bestimmt
ist, die folgende Route: beginnend von der Mobilstation 2 wird
Verkehr durch eine Funknetzsteuerung (RNC) 4 zu einem versorgenden
Unterstützungsknoten
des GPRS (Allgemeinen Paketfunksystems) SGSN 6 geleitet.
Von dort aus wird das Signal durch einen Gateway-GPRS-Unterstützungsknoten
(GGSN) 8 zu einem Media-Gateway (MGW) 12 geleitet,
um mit einem öffentlichen
Fernsprechwählnetz
(PSTN) zusammenzuarbeiten, wird getroffen oder wenn Transcodierung
erforderlich ist, woraufhin das Ziel des Zieltelefons (T2) 14 erreicht wird.
-
Die
Verkehrsabwicklung unter Verwendung des oben skizzierten Weges kann
sehr ineffizient sein.
-
Bisher
besteht keine Koordination zwischen der Auswahl des GGSN und dem
VoIP-Media-Gateway (MGW). Die Bestimmung des GGSN (beim Aufbauen
des PDP-Trägers)
und die Wahl des MGW (die durch Verbindungssteuerung auf Anwendungsebene
bestimmt wird) sind zwei unabhängige Prozeduren.
Da der Verkehr jedoch durch diese beiden Punkte laufen muß, können der
bestimmte GGSN und das bestimmte MGW zu einer suboptimalen Verkehrsroute
führen.
Dazu käme
es zum Beispiel, wenn die Mobilstation (MS), der GGSN und das MGW
ein Dreieck bilden.
-
Im öffentlichen
Landmobilnetz (PLMN) (z.B. dem Netz des Mobiltelefonbetreibers)
muß Verkehr durch
eine erste Schnittstelle In-ps zwischen der RNC 4 und dem
SGSN 6, eine zweite Schnittstelle Gn zwischen dem SGSN 6 und
dem GGSN 8 durchlaufen. Folglich erhielt der Kopfteil jedes
Signalpakets den folgenden Protokollstapel bzw. die folgende Reihe
von Codes. Echtzeit-Transportprotokoll/Benutzerdatagramm-Protokoll/Internet-Protokoll/GPRS-Tunnelungsprotokoll/Benutzerdatagramm-Protokoll/Internet-Protokoll/L1,2 (RTP/UDP/IP/GTP/UDP/L1,2).
Das Ergebnis ist, daß für Echtzeit-
oder Voice-Dienste
die Betriebsmittelbenutzung gering ist (etwa 25%).
-
Dieses
Problem wird durch eine neue Mobiltelefonsystemarchitektur überwunden,
die auch in der am selben Datum vom selben Anmelder eingereichten
gleichzeitig anhängigen
Patentanmeldung beschrieben wird. Das Problem bei diesem System besteht
darin, daß neue
Protokolle eingeführt
werden müssen.
-
Eine
Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines
verbesserten Echtzeit-Datenübertragungssystems,
bei dem das Protokoll-Overhead reduziert ist.
-
Kurzfassung der Erfindung
-
Gemäß der vorliegenden
Erfindung wird ein Echtzeit-Datenübertragungssystem
für Aufwärtsstrecken-
und Abwärtsstreckenübertragungen
zwischen einer Mobilstation und einer Zielstation bereitgestellt, wobei
die Mobilstation in der Aufwärtsstreckenübertragung
zu dem Nutzinformationsdatenstrom hinzufügt, indem sie einen Kopfteil
erzeugt, der ihre eigene Identität
und eine Zielidentität
enthält,
um die Nutzinformationen in dem Datenstrom zu begleiten, wobei eine
Funknetzsteuerung beim Empfang des Datenstroms eine Tunnelidentität zu dem
Datenstrom hinzufügt,
die aus einem Verbindungssteuerserver erhalten wird, um den Datenstrom
zu identifizieren, und dann den Datenstrom direkt zu einem Media-Gateway
leitet, wobei das Media-Gateway
in der Abwärtsstreckenübertragung
einen Datenstrom empfängt, der
einen Kopfteil umfaßt,
der die Mobilstationsidentität
und eine Mobilstations-Portidentität enthält, die aus
dem versorgenden allgemeinen Paketfunksystem-Unterstützungsknoten
SGSN erhalten wird, wobei das Media-Gateway wirkt, um sowohl die
Mobilstationsidentität
als auch die Mobilstations-Portidentität in dem
Kopfteil mit der Adresse der Funknetzsteuerung, der Portidentität der Funknetzsteuerung und
einer Tunnelidentität
zum Identifizieren des Datenstroms zu ersetzen, die alle aus dem
Verbindungssteuerserver erhalten werden, und dann den Datenstrom
direkt zu der Funknetzsteuerung zu leiten, und die Funknetzsteuerung
wirkt, um die Funknetzsteuerungsadresse in dem Kopfteil mit der
Mobilstationsidentität
und der Mobilstations-Portidentität zu ersetzen,
die beide aus dem Verbindungssteuerserver über den SGSN erhalten werden,
und auf die empfangene Tunnelidentität zu reagieren, um den Datenstrom
zu identifizieren, und dann den Datenstrom zu einem entsprechenden
Funküberbringer
zu leiten, der die Funknetzsteuerung mit der Mobilstation verbindet.
-
Die
vorliegende Erfindung liefert ferner ein Echtzeit-Datenübertragungsverfahren
in einem Netz mit einer Mobilstation, einer Funknetzsteuerung, einem
Media-Gateway, einer
Zielstation und einem Verbindungssteuerserver, wobei der Durchgang
eines Datenstroms, der einen Kopfteil und einen Nutzinformationsteil
enthält,
zwischen der Mobilstation und der Zielstation durch den Inhalt des
Kopfteils geregelt wird, wobei das Verfahren folgendes umfaßt: in der
Aufwärtsstreckenübertragung
von der Mobilstation zu der Zielstation den Schritt des Hinzufügens der Identitäten beider
Stationen zu dem Kopfteil des von der Mobilstation zu der Funknetzsteuerung
gesendeten Datenstroms, den Schritt des Hinzufügens einer aus dem Verbindungssteuerserver
erhaltenen Tunnelidentität
zu dem Kopfteil des durch die Funknetzsteuerung gehenden Datenstroms,
den Schritt des Weiterleitens des Datenstroms von der Funknetzsteuerung
zu dem Media-Gateway
und in der Abwärtsstreckenübertragung
von der Zielstation zu der Mobilstation den Schritt des Hinzufügens der
Mobilstationsidentität
und der Portidentität
der Mobilstation, die beide aus dem Verbindungssteuerserver erhalten
werden, zu dem Kopfteil des von der Zielstation kommenden Datenstroms,
den Schritt des Ersetzens der Mobilstationsidentität und der
Portidentität der
Mobilstation in dem Kopfteil des Datenstroms mit der Funknetzsteuerungsadresse,
der Portidentität der
Funknetzsteuerung und einer Tunnelidentität für den Datenstrom, die alle
aus dem Verbindungssteuerserver erhalten werden, während der
Datenstrom das Media-Gateway durchläuft, den Schritt des Weiterleitens
des Datenstroms zu der Funknetzsteuerung, den Schritt des Ersetzens
der Funknetzsteuerungsadresse und der Portidentität der Funknetzsteuerung
in dem Kopfteil des Datenstroms mit der Mobilstationsidentität und der
Portidentität
der Mobilstation, die beide über
den SGSN aus dem Verbindungssteuerserver erhalten werden, während der Datenstrom
die Funknetzsteuerung durchläuft,
und den Schritt des Leitens des Datenstroms zu der Mobilstation.
-
Kurze Beschreibung der Zeichnungen
-
Es
wird nun als Beispiel mit Bezug auf die beigefügten Zeichnungen in Diagrammform
ein die vorliegende Erfindung realisierendes Telefonnetz beschrieben.
Es zeigen:
-
1 ein
Blockschaltbild der Hauptkomponenten eines existierenden Netzes;
-
2 ein
Blockschaltbild eines in der gleichzeitig anhängigen Patentanmeldung beschriebenen Netzes,
wobei die physischen Verbindungen zwischen den Hauptkomponenten
des Netzes gezeigt sind;
-
3 ein
Blockschaltbild der logischen Verbindung zwischen den Hauptkomponenten
des Netzes von 2;
-
4 ein
Blockschaltbild eines lokal mit PSTN zusammenarbeitenden Verbindungsaufbau-Szenarios;
-
5 ein
Blockschaltbild eines aus der Ferne mit PSTN zusammenarbeitenden
Verbindungsaufbau-Szenarios;
-
6 ein
Blockschaltbild der Aufwärtsstrecken-Verkehrsabwicklung;
-
7 ein Blockschaltbild der Abwärtsstrecken-Verkehrsabwicklung
in einem lokalen Media-Gateway;
-
8 ein
Blockschaltbild der Abwärtsstrecken-Verkehrsabwicklung
in einer Funknetzsteuerung;
-
9 ein
Blockschaltbild der Abwärtsstrecken-Verkehrsabwicklung
unter Verwendung eines auf Portnummern basierenden Schemas in der
Funknetzsteuerung; und
-
10 ein
Blockschaltbild der zwei Wege für Voice- Dienst in einem universellen
Mobiltelefonsystem UMTS.
-
Das
in 2 gezeigte Netz der gleichzeitig anhängigen Patentanmeldung
enthält
einen Kern bzw. eine Wolke 20 des PLMN-Internet-Protokolls (IP).
Dieser Kern 20 wird durch eine Funknetzsteuerung (RNC)
bzw. ein Funkzugangsnetz (RAN) 24 zu einer Mobilstation 22 übermittelt.
Der PLMN-IP-Kern 20 ist durch ein Media-Gateway mit Zeitmultiplex-Echtzeittransportprotokoll
(TDM-RTP) MGW 28 an das öffentliche Telekommunikationswählnetz (PSTN)
bzw. diensteintegrierte digitale Netz (ISDN) 26 angekoppelt.
-
Der
PLMN-IP-Kern 20 wird durch zwei Routen mit einem Internet-Protokoll-IP-Backbone-Netz 30 verbunden.
Eine erste Route umfaßt
ein Echtzeit-Transportprotokoll-Echtzeit-Transportprotokoll-Media-Gateway
(RTP-RTP-MGW) 32 während die
zweite Route einen SGSN 34, einen GGSN 36 umfaßt. Eine
Media-Gateway-Steuerung 40 steuert die Routen.
-
Es
ist also ersichtlich, daß Voice-Internet-Protokoll-Verkehr nun den IP-Backbone 30 erreichen
kann, indem weniger Kopfteilinhalt auftritt.
-
3 zeigt
die logischen Verbindungen zwischen den in 2 gezeigten
Komponenten, wobei Steuerverbindungen mit gestrichelten Linien,
Media-Verbindungen in einer einzigen durchgezogenen Linie und Media-
und Steuerverbindungen in parallelen Linien (eine dick und eine
dünn) gezeigt
sind.
-
Die
Schnittstellen zwischen den Einheiten sind wie folgt. Gx ist die
Schnittstelle zwischen der RNC 24 und dem MGW 28,
Gy ist die Schnittstelle zwischen der RNC 24 und dem MGW 32.
Iu-ps ist die Schnittstelle zwischen der RNC 24 und dem
SGSN 34. Gn ist die Schnittstelle zwischen dem SGSN 34 und
dem GGSN 36 und Gi ist die Schnittstelle zwischen dem GGSN 36 und
dem IP-Backbone 30.
-
Da
die MGW 28 und 32 durch den PLMN-IP-Kern 20 mit
der RNC 24 verbunden werden, ist ersichtlich, daß jedes
MGW mit einer beliebigen RNC in einer einzigen Verwaltungs-(Mobilbetreiber)-Domäne kommunizieren
kann.
-
Es
ist erkennbar, daß der
VoIP-Fluß eines der
MGW 28, 32 durchläuft, das mit dem PLMN-IP-Kernnetz 20 verbunden
ist. Wenn der Verbindungsverkehr sofort zu dem PSTN/ISDN-Netz geht,
wird ein RTP-PSTN-Gateway verwendet. Wenn Verkehr zu einem anderen
Internet-Protokoll-Endpunkt
geht, der ein PSTN/ISDN-Gateway umfassen kann, sollte andernfalls
das RTP-RTP-GW 32 verwendet werden. Beide Arten von MGW 28 und 32 können Transcodierungsfunktionen
durchführen.
-
Das
MGW für
jeden VoIP-Fluß ist
der Ankerpunkt während
jeder Kommunikationssitzung. Das gewählte MGW kann den VoIP-Fluß von einer
RNC 24 unter der Kontrolle der MGC 40, die selbst
Anweisungen möglicherweise über den
GGSN 36 von dem GSN 34 empfängt, auf eine andere in dem
selben System umschalten.
-
Beschreibung der bevorzugten
Ausführungsform
-
Um
das in 2 dargestellte System zu betreiben, ist es notwendig,
vielfältige
neue Prozeduren zu implementieren.
-
Um
eine beliebige Verbindung zwischen einer Mobilstation und ihrem
Ziel aufzubauen, muß ein Überbringeraufbau
sowie ein Verbindungsaufbau implementiert werden, wie nun beschrieben
werden wird.
-
Überbringeraufbau
-
Der Überbringer
des Internet-Protokolls (IP) muß als
eine erste Phase eine Datensitzung zum Transfer von Paketen von
Daten aufbauen, und somit wird ein Paketdatensteuerungs-PDP-Kontext
auf die normale Weise für
GRPS aufgebaut. Der Kontext kann gegebenenfalls mit Attributen für Dienstgüte (QoS)
für die
Signalisierung von Diensten assoziiert werden.
-
Nach
der ersten Phase einer Verbindungsaufbauprozedur wird insbesondere
für den
VoIP-Media-Verkehr (dies kann durch einen speziellen PDP-Typ angezeigt
werden) ein neuer oder modifizierter Überbringer (PDP-Kontext) erforderlich.
Diese Art von Überbringer
wird einer anderen Behandlung als normal unterzogen. Weder der SGSN 34 noch
der GGSN 36 müssen
tatsächlich
Betriebsmittel für
ihn zuteilen, da der tatsächliche
Media-Weg direkt zwischen der RNC 24 und einem der beiden
MGW 28, 32 verlaufen wird. SGSN 34 und
GGSN 36 müssen nur
Steuerfunktionalität
durchführen.
Wie normal werden zwei Tunnel-ID (TID), d.h. Identitäten des GPRS-Tunnelungsprotokolls,
zugeteilt.
-
Nach
dem Empfang der PDP-Kontextaufbauanforderung für VoIP-Media-Verkehr instruiert der
SGSN 34 die MGC 40 und die MGC instruiert die MGW 28 oder 32,
Betriebsmittel zwischen dem zu verwendenden lokalen MGW und der
RNC 24 zu reservieren.
-
Die
Abwicklung des Verkehrs in diesem Überbringer wird später durch
den SGSN 34 instruiert und gesteuert, nachdem die Verbindungsaufbauprozedur
abgeschlossen wurde.
-
Verbindungsaufbau
-
Die
Verbindungsaufbauprozeduren in bezug auf Routingentscheidungen unterscheidet
sich von den normalen oder standardmäßigen VoIP-Verbindungssteuerprozeduren,
da sie immer dafür
wirken werden, ein lokales MGW in den Verbindungs-(Verkehrs-)Weg
zu bringen. Die Verbindungs-Routing-Richtlinie
wird nachfolgend unter Berücksich tigung
zweier möglicher
Szenarien beschrieben.
-
Das
erste Verbindungsaufbauszenario umfaßt Zusammenarbeit mit dem PSTN/ISDN-Netz 26 und
ist in 4 dargestellt. Beim Aufbauen der Verbindungsprozedur
müssen
die folgenden Informationen erhalten werden:
- (a)
die Internet-Protokoll-Adresse IP1 der Mobilstation 22;
- (b) die Internet-Protokolladresse IP2 des gewählten Media-Gateway 28;
- (c) die Portnummer des Benutzerdatagramm-Protokolls (UDP) Port1
für Abwärtsstrecken-Media-Verkehr
an der Mobilstation 22;
- (d) die UDP-Portnummer Port2 des Aufwärtsstrecken-Media-Verkehrs an dem Gateway 28;
und
- (e) das Verbindungsleitungsglied (trunk-id) der Verbindungsleitung,
die das Gateway 28 mit dem PSTN/ISDN-Netz 22 verbindet.
-
Wenn
eine Verbindung von der Mobilstation 22 eingeleitet wird,
werden die folgenden höheren Prozeduren
und allgemeinen implementiert.
-
Die
Mobilstation 22 leitet eine Verbindungsanforderung in Richtung
des CC-(Verbindungssteuer-)Servers 38 ein, die die Nummer
des angerufenen Teilnehmers und seine IP-Adresse (IP1) enthält.
-
Der
CC-Server 38 analysiert die Nummer des angerufenen Teilnehmers
und identifiziert, wenn lokale Zusammenarbeit mit dem PSTN/ISDN-Netz 22 entschieden
wird, ein Gateway 28 (IP2) zum Beispiel auf der Basis von
Lastausgleich bzw. Kapazität bzw.
unterstütztem
Codec.
-
Der
CC-Server 38 spricht mit der Station 22 und der
Media-Gateway-Steuerung (MGC) 40, die das identifizierte
Gateway 28 steuert, um Mediaweg unter Verwendung von für das verwendete
Verbindungssignalisierungsprotokoll spezifischen Nachrichten aufzubauen,
und folglich würde
der Media-Weg das Gateway 28, die Portnummern port1 und
port2 und die TDM-Verbindungsleitungsnummer (trunk-id)
enthalten.
-
Wenn
die Verbindung an der Mobilstation 22 abgeschlossen wird,
werden die folgenden höheren und
allgemeinen Prozeduren implementiert:
Eine Verbindungsanforderung
von dem PSTN/ISDN-Netz 22 erreicht den CC-Server 38 über ein
(nicht gezeigtes) Signalisierungs-Gateway, einschließlich der
Nummer des angerufenen Teilnehmers.
-
Der
CC-Server 38 analysiert die Nummer des angerufenen Teilnehmers
und bildet sie aus den lokal in dem CC-Server 38 verfügbaren Daten
auf die IP-Adresse (IP1) der Mobilstation 22 ab.
-
Außerdem identifiziert
der CC-Server 38 die Adresse (IP2) des Gateway 28 zum
Beispiel auf der Basis von Lastausgleich bzw. Kapazität bzw. unterstütztem Codec.
-
Der
CC-Server 38 spricht mit der Mobilstation 22 und
der (das identifizierte Media-Gateway 28 steuernden) Gateway-Steuerung 40,
um Mediaweg unter Verwendung von für das verwendete Verbindungssignalisierungsprotokoll
spezifischen Nachrichten aufzubauen, und folglich würde der
Media-Weg das gewählte
Gateway 28 enthalten und die Portnummern Port1 und Port2
würden
bestimmt.
-
Bei
dem zweiten Verbindungsaufbauszenario erfolgt abgesetzte Zusammenarbeit
mit dem PSTN/ISDN-Netz 22, wie in 5 dargestellt.
In diesem Fall ist das zweite Gateway 28 zusammen mit seinem
eigenen Server 39 für
Verbindungssteuerung (CC) beteiligt.
-
Beim
Aufbau der Verbindungsprozedur (einschließlich Verbindungsrouting) müssen die
folgenden Informationen erhalten werden:
- (a)
die Internet-Protokoll-Adresse IP3 der Mobilstation 22;
- (b) die Internet-Protokoll-Adresse IP4 des lokalen RTP-RTP-Media-Gateway 32;
- (c) die Internet-Protokoll-Adresse IP5 des abgesetzten Gateway 28;
- (d) die UDP-Portnummer (port3) für Abwärtsstreckenverkehrs-Medien
an der Mobilstation 22;
- (e) die UDP-Portnummer (port4) für den Aufwärtsstreckenmedienverkehr an
dem Gateway 32;
- (f) die UDP-Portnummer (port5) für den Aufwärtsstreckenmedienverkehr an
dem abgesetzten Gateway 28; und
- (g) die UDP-Portnummer (port6) für den Abwärtsstreckenmedienverkehr von
dem Netz 26 zu dem ersten oder lokalen Gateway 32.
-
Für den Fall,
daß die
Mobilstation 22 die Verbindung einleitet, werden die folgenden
höheren
und allgemeinen Prozeduren implementiert:
Die Mobilstation 22 leitet
eine Verbindungsanforderung in Richtung des CC-(Verbindungssteuer-)Servers 38 ein,
einschließlich
der Nummer des angerufenen Teilnehmers und seiner IP-Adresse (IP3).
-
Der
CC-Server 38 analysiert dann die Nummer des angerufenen
Teilnehmers, um zu sehen, ob lokale Zusammenarbeit mit dem PSTN-Netz 26 erforderlich
ist. Wenn nicht, identifiziert der lokale CC-Server 38 ein
lokales Gateway 32 (mit der Adresse IP4).
-
Der
lokale CC-Server 38 kontaktiert einen weiteren (abgesetzten)
CC-Server 39, der ein abgesetztes Gateway 28 und
seine IP-Adresse IP5 identifiziert.
-
Der
lokale CC-Server 38 spricht mit der Station 22 und
der (das lokale Gateway 32 steuernden) Media-Gateway-Steuerung 40 unter
Verwendung von für
das verwendete Verbindungssignalisierungsprotokoll spezifischen
Nachrichten, und folglich würde
der Media-Weg das lokale Gateway 32 enthalten, und die
Portnummern port3 und port4 würden
bestimmt.
-
Der
lokale CC-Server 38 spricht mit dem abgesetzten CC-Server 39 unter
Verwendung von für das
verwendete Verbindungssignalisierungsprotokoll spezifischen Nachrichten,
und folglich werden die Portnummern port5 und port6 bestimmt.
-
Für den Fall,
daß eine
Mobilstation 22 die Verbindung abschließt, werden die folgenden höheren und
allgemeinen Prozeduren implementiert:
Die Verbindungsanforderung
von einem abgesetzten CC-Server 39 erreicht
den lokalen CC-Server 38 über eine IP-Verbindung, einschließlich der
Nummer des angerufenen Teilnehmers.
-
Der
lokale CC-Server 38 analysiert die Nummer des angerufenen
Teilnehmers und bildet sie auf die IP-Adresse (IP3) der Mobilstation
ab.
-
Der
lokale CC-Server 38 identifiziert eine lokale Gateway-Adresse
IP4 zum Beispiel auf der Basis von Lastausgleich bzw. Kapazität bzw. unterstütztem Codec.
-
Der
lokale CC-Server 38 spricht mit dem abgesetzten CC-Server 39 unter
Verwendung von für das
verwendete Verbindungssignalisierungsprotokoll spezifischen Nachrichten
und folglich werden die IP-Adresse IP5 des abgesetzten Gateway 28,
die Portnummer port5 und die Portnummer port6 bestimmt.
-
Der
lokale CC-Server 38 spricht mit der Mobilstation 22,
der (das lokale Gateway 32 steuernden) Media-Gateway-Steuerung 40 unter
Verwendung von für
das verwendete Verbindungssignalisierungsprotokoll spezifischen
Nachrichten, und folglich würde
der Media-Weg das
lokale Gateway 32 enthalten, und die Portnummern port3
und port4 werden bestimmt.
-
Nach
der obigen Verbindungsaufbauprozedur wird die Route der Verbindung
(der Media-Weg) bestimmt (der durch die IP-Adressen verschiedener Gateways
und Portnummern widergespiegelt wird). Dann informiert der (lokale)
CC-Server 38 den GGSN 36 und den SGSN 34 über diese
Details (die Transportadressen) des Media-Flusses, die dann die RNC 24 und
das lokale Gateway 28 instruieren, die beteiligt sind,
um Verkehr direkt über
das PLMN-IP-CN (Kernnetz) 20 zu transportieren, das zwischen
der RNC 24 und dem lokalen Media-Gateway 32 liegt.
-
Wie
oben beschrieben, können
die VoIP-Medien nun direkt über
den PLMN-IP-Kern 20 zwischen dem Media-Gateway und der
RNC 24 transportiert werden, ohne den SGSN 34 und
den GGSN 36 zu durchlaufen. Die Vorteile dieser Anordnung
bestehen darin, daß eine
kleinere Anzahl von Elementen vorliegt, die die Media-Ströme durchlaufen
müssen,
und der Media-Transport zwischen dem Media-Gateway und der RNC 24 über einen
kürzeren
Protokollstapel erfolgen und somit zu einem verringerten Protokoll-Overhead
führen
kann.
-
Um
den Transport des Verkehrs zu optimieren, werden nun zwei unabhängige Verfahren
beschrieben.
-
Das
erste Verfahren umfaßt
Datenstromidentifikation auf der Basis der GPRS-Tunnelungsprotokollidentifikation
(GTP-TID) und arbeitet wie folgt.
-
Nachdem
er informiert wurde über
den hergestellten VoIP-Verkehrsweg (Transportadressen), identifiziert
der SGSN 34 die beiden TID (GTP-Tunnel-ID), die dem Aufwärtsstrecken-
und Abwärtsstreckenverkehrsweg
für die
hergestellte VoIP-Sitzung entsprechen. Dann kann der SGSN 34 die
RNC 24 und das (lokale) MGW (über die Media-Gateway-Steuerung)
steuern, um den Media-Verkehr speziell auf eine optimierte Weise
abzuwickeln, die nachfolgend beschrieben wird.
-
Für Aufwärtsstreckenverkehrsabwicklung
informiert der SGSN 34 die RNC 24, über die
GTP-TID, die die Tunnel-ID für
den Aufwärtsstreckenverkehr der
VoIP-Sitzung ist. Die diese TID erhaltende RNC 24 kann
dann den Verkehr abwickeln, der von einem bestimmten RAB ankommt,
das mit der TID assoziiert ist. Die Verkehrsabwicklung für dieses
RAB ist wie folgt (siehe 6).
-
Ein
VoIP-Paket 50 kommt an der RNC von der Mobilstation 22 über einen
Knoten B wie normal an. Für
jedes Paket entfernt die RNC 24 die L1- und L2-Kopfteile
und erhält
das Benutzerebenen-IP-Paket. Dieses Benutzerebenen-IP-Paket wird unter
Verwendung eines normalen IP-Routing-Schemas zu dem lokalen MGW 28 geroutet
(folglich wird die Schnittstelle von L1- und L2-Kopfteilen über Gx verwendet).
-
Die
Abwärtsstreckenverkehrsabwicklung muß an dem
lokalen Media-Gateway und in der RNC 24 geschehen. Zur
Verkehrsabwicklung an dem Media-Gateway instruiert der SGSN 34 über den
GGSN 36 das lokale Gateway, die folgenden Aktionen durchzuführen:
Wenn
das lokale Media-Gateway ein TDM-RTP-MGW ist, muß die Verbindung zwischen der
TDM-Verbindungsleitung und (IP1, port1) wie in 7a gezeigt
auf (IPRNC, port-x) umgeschaltet werden. Die Portnummer
port-x wird durch das lokale MGW oder beliebige andere Mittel bestimmt,
vorausgesetzt keine konfliktierende Benutzung.
-
Wenn
das lokale Media-Gateway ein RTP-RTP-MGW ist, muß die Verbindung zwischen dem
ankommenden RTP-Strom an dem MGW und (IP1, port1) wie in 7(b) gezeigt auf (IPRND,
port-x) umgeschaltet werden. Die Portnummer port-x wird durch das
lokale MGW oder beliebige andere Mittel bestimmt, vorausgesetzt
keine konfliktierende Benutzung.
-
Der
SGSN 34 informiert das lokale MGW dann mit der TID, die
die Tunnel-ID für
den Abwärtsstreckenverkehr
der VoIP-Sitzung ist. Das lokale MGW fügt diese TID dann in jedes
Paket des Abwärtsstrecken-Echtzeit-Tranportprotokolls
(RTP) dieser Verbindung ein. Die TID (4 Byte) kann als ein erweitertes
RTP-Kopfteilfeld unter Verwendung eines existierenden RTP-Kopfteilfelds
eingefügt
werden. Das RTP nach erweitertem oder wiederverwendetem Kopfteil
wird als RTP+ bezeichnet.
-
In
der RNC 24 wird der Abwärtsstreckenverkehr
folgendermaßen
abgewickelt (siehe 8):
Der SGGN 34 informiert
die RNC 24 mit der TID, die die Tunnel-ID für den Abwärtsstreckenverkehr
der VoIP-Sitzung
ist und der Zieltransportadresse (IP1, port1). Die RNC 24 behält diese
Abbildung zur späteren
Verwendung.
-
Für jedes
von dem lokalen Media-Gateway kommende RTP+/UDP/IP-Paket wird die
durch das Gateway eingefügte
TID geprüft
und auf eine Zieltransportadresse (IP1, port1) abgebildet. Dann
wird das TID-Feld entfernt oder ein ordnungsgemäßer Wert gesetzt, wenn das
RTP wiederverwendet wird (somit wird das ursprüngliche RTP-Paket wiederhergestellt). Die Zielportnummer
des Benutzerdatagramm-Protokolls (UDP) wird mit port1 ersetzt und die
IP-Zieladresse auf IP1 gesetzt. Das neue RTP/UDP/IP-Paket wird in
ein RAB abgelegt, das mit der TID assoziiert ist.
-
Das
zweite Schema umfaßt
Stream-Identifikation auf der Basis der Portnummer und arbeitet
wie folgt:
Nachdem er über
den hergestellten VoIP-Verkehrsweg (Transportadressen) informiert
wurde, kann der SGSN 34 die RNC 24 und das lokale
Media-Gateway (über
eine Gateway-Steuerung) steuern, um den Media-Verkehr speziell auf
eine optimierte Weise abzuwickeln. Die Aufwärtsstreckenverkehrsabwicklung
ist genau wie bei dem ersten Schema (unter Verwendung von TID zur
Stream-Identifikation),
aber die Abwärtsstreckenabwicklung
ist verschieden.
-
Die
Abwärtsstreckenverkehrsabwicklung muß an dem
lokalen Gateway (MGW) und in der RNC 24 erfolgen, die folgendermaßen implementiert wird:
Für die Abwicklung
an dem lokalen Media-Gateway instruiert der SGSN 34 über den
GGSN 36 das lokale Gateway folgendermaßen:
Wenn das lokale Media-Gateway
ein TDM-RTP-MGW ist, wird die Verbindung zwischen der TDM-Verbindungsleitung
und (IP1, port1) wie in 7(a) gezeigt
auf (IPRNC, port-x) umgeschaltet. Die Portnummer
port-x wird durch den SGSN 34 bereitgestellt.
-
Wenn
das lokale Media-Gateway ein RTP-RTP-MGW ist, wird die Verbindung
zwischen dem ankommenden RTP-Strom an dem Media-Gateway und (IP1,
port1) wie in 7(b) gezeigt auf (IPRNC, port-x) umgeschaltet. Die Portnummer
port-x wird durch den SGSN 34 oder den GGSN 36 bereitgestellt.
-
In
der RNC 24 wird der Abwärtsstreckenverkehr
folgendermaßen
abgewickelt (siehe 9):
Der SGSN 34 gibt
der RNC 24 die folgenden Informationen: die TID, die die
Tunnel-ID für
den Abwärtsstreckenverkehr
der VoIP-Sitzung ist, die Zieltransportadresse (IP1, port1) und
die durch den SGSN 34 für
diese VoIP-Sitzung zugewiesene Portnummer port-x. Die RNC 24 behält diese
Informationen zur späteren
Verwendung.
-
Für jedes
von dem lokalen Media-Gateway kommende RTP/UDP/IP-Paket wird die
UDP-Portnummer (port-x) geprüft
und auf eine Zieltransportadresse (IP1, port1) abgebildet. Die UDP-Zielportnummer
wird mit port1 ersetzt und die IP-Zieladresse auf IP1 gesetzt. Das
neue RTP/UDP/IP-Paket wird dann in eine mit der TID assoziiertes
RAB abgelegt.
-
Die
aktuelle Architektur zur Unterstützung von
VoIP in einem universellen Mobiltelefonsystem (UMTS) besteht darin,
eine VoIP-Dienstdomäne
einer UMTS-PS-Domäne
zu überlagern
(siehe 10). Die VoIP-Dienstdomäne enthält mehrere Komponenten,
darunter eine CSCF (Verbindungszustandssteuerungsfunktion) bzw.
Signalisierungs-Gateway.
-
Die
CSCF liefert Verbindungssteuerfunktionalität und Ergänzungsmerkmale (z.B. Verbindungsweiterschaltung,
Anklopfen und Mehrwegeverbindung).
-
Die
CSCF liefert Funktionen wie Adressierungsübersetzung, Zulassungssteuerung,
wie etwa Erlaubnis zum Abschließen
von Verbindungen und Setzen von Bandbreitenbegrenzungen, Verwaltung und
Steuerung von Gateways und Verbindungssignalisierung, Verbindungsverwaltung,
Meldungen und Protokollierung.
-
Das
Signalisierungs-Gateway stellt Signalisierungszusammenarbeit und
eine Schnittstelle zu dem PST/ISTN-Netz bereit.
-
Das
Media-Gateway liefert viele Dienste, darunter Protokoll- und Media-Übersetzung.
Diese Entität
führt bidirektionale
Synchron/Asynchron-Umsetzung (TDM zu Paket) und Signalisierungszusammenarbeit-Funktionen
durch, darunter Verwaltung der Steuerungsschnittstelle (SS7) bzw.
Verbindung.
-
An
den Kombinationen und Anordnungen der Elemente, die oben beschrieben
und in den Zeichnungen gezeigt wurden, können Änderungen vorgenommen werden,
wobei es sich versteht, daß Änderungen
an der offengelegten Ausführungsform vorgenommen
werden können,
ohne von dem in den folgenden Ansprüchen definierten Schutzumfang
der Erfindung abzuweichen.