-
Die
vorliegende Erfindung betrifft Telekommunikationssysteme. Insbesondere
betrifft die vorliegende Erfindung ein neues und verbessertes Verfahren
zum Multiplexen von Datenströmen
auf einen Transportträger
zwischen einem Ausgangsnetzknoten und einem Empfangsnetzknoten.
-
Hintergrund der Erfindung
-
In
den derzeitigen Spezifikationen der Mobilnetze der dritten Generation
(bezeichnet als UMTS, Universelles Mobil-Telekommunikations-System) verwendet
das System die gleiche wohlbekannte Architektur, die von allen Hauptsystemen
der zweiten Generation verwendet wurde. Ein Blockdiagramm der Systemarchitektur
des derzeitigen UMTS-Netzwerks wird in 1 dargestellt.
Die UMTS-Netzarchitektur schließt
das Kernnetzwerk (CN), das UMTS terrestrische Funkzugangsnetz (UTRAN)
und die Benutzerausrüstung
(UE) ein. Das Kernnetzwerk ist weiter mit den externen Netzwerken
verbunden, d. h. dem Internet, PSTN (öffentliches Fernsprechnetz, Public
Switched Telephone Network) und/oder ISDN (Dienstintegrierendes
digitales Netz, Integrated Services Digital Network).
-
Die
UTRAN-Architektur besteht aus mehreren Funknetz-Untersystemen (RNS).
Das RNS ist weiter aufgeteilt in den Funknetzkontroller (RNC) und mehrere
Basisstationen (BTS, in den 3GPP Spezifikationen als Node B bezeichnet).
In dieser Architektur gibt es mehrere verschiedene Verbindungen
zwischen den Netzwerkelementen. Die Iu-Schnittstelle verbindet CN
und UTRAN. Die Iur-Schnittstelle ermöglicht den Austausch von Signalisierungsinformationen
und Nutzdaten(user plane)-Informationen zwischen zwei RNCs. Es gibt
keine zu Iur äquivalente Schnittstelle
in den Architekturen der Mobilnetze der zweiten Generation. Das
Funknetzschicht(RNL)-Signalisierungsprotokoll über die Iur-Schnittstelle wird der Funknetz-Untersystem-Anwendungsteil (RNSAP)
genannt. Der RNSAP wird an beiden Enden der Iur-Schnittstelle durch
einen RNC abgeschlossen. Die Iub-Schnittstelle verbindet einen RNC und
einen Node B. Die Iub-Schnittstelle ermöglicht es dem RNC, dem Node
die erforderlichen Funknetzressourcen anzugeben, zum Beispiel zum
Hinzufügen
und Entfernen von Zellen, die durch den Node B gesteuert werden,
um Kommunikation einer dedizierten Verbindung zwischen UE und C-RNC
(Steuerung RNC, Control-RNC) zu unterstützen, Informationen, die verwendet
werden, um die Rundsende(broadcast) und Funkruf-(paging)Kanäle zu steuern,
und Informationen, die auf den Rundsende- und Funkrufkanälen transportiert
werden sollen. Ein Node B kann eine oder mehrere Zellen bedienen.
UE ist mit dem Node B durch die Uu-Funkschnittstelle verbunden. UE
besteht weiter aus einem Teilnehmeridentitätsmodul (USIM) und Mobilausrüstung (ME).
Sie sind durch die Cu-Schnittstelle verbunden. Verbindungen mit
externen Netzen werden durch Gateway-MSC (Mobildienste-Vermittlungsstellen,
Mobile Services Switching Centre) (zu leitungsvermittelten Netzwerken)
oder GGSN (Gateway GPRS (Gruppen-Paket-Funk-System) Support Node) (zu paketvermittelten
Netzwerken) hergestellt.
-
Das
allgemeine Protokollmodell für UTRAN-Schnittstellen
ist in 2 dargestellt, und wird im Folgenden im Detail
beschrieben. Die beschriebene Struktur basiert auf dem Prinzip,
dass die Schichten (layers) und Ebenen (planes) logisch voneinander
unabhängig
sind.
-
Die
Protokollstruktur besteht aus zwei Hauptschichten, Funknetzschicht
und Transportnetzschicht (Transport Network Layer, TNL). Diese sind
in den horizontalen Ebenen von 2 dargestellt.
Alle UTRAN-bezogenen Angelegenheiten sind nur in der Funknetzschicht
sichtbar, und die Transportnetzschicht repräsentiert die Standardtransporttechnologie,
die für
die Verwendung in UTRAN gewählt
worden ist. UTRAN weist bestimmte spezifische Anforderungen an TNL
auf. Zum Beispiel die Echtzeit-Anforderung,
d. h. die Übertragungsverzögerung muss gesteuert
und niedrig gehalten werden.
-
In
der HS-DSCH (HS-DSCH, High Speed Downlink Shared Channel; HSDPA
High Speed Downlink Packet Access) Spezifikations-Arbeit ist die grundlegende
Annahme, dass die gleiche Transportlösung, die für DSCH verwendet wurde, auch
für HS-DSCH
verwendet werden wird. In dieser Anmeldung wird der Begriff HS-DSCH
verwendet, um den Kanal oder Datenstrom zwischen CRNC und Node B auf
der Iub-Schnittstelle zu beschreiben, und daher sollte er nicht
mit dem auf HSDPA bezogenen Transportkanal verwechselt werden, der ein
interner Kanal zwischen MAC-hs (Medium Access Control) und L1 (Lager
1) in Node B ist. Bei dieser Lösung
ist ein dedizierter Transportträger
separat für
jeden DSCH-Datenstrom zwischen SRNC (Serving RNC) und Node B reserviert. 3 zeigt
die Funkschnittstellen-Protokollarchitektur
mit Abschlussstellen. Im logischen Modell ist MAC-hs, welches in
Node B eingefügt
ist, unterhalb von MAC-c/sh angeordnet, welches weiter in CRNC implementiert
ist. Das HS-DSCH FP (frame protocol) wird den Datentransport von
SRNC zu CRNC (falls die Iur-Schnittstelle betroffen ist) und zwischen
CRNC und dem Node B handhaben. Die Architektur unterstützt sowohl
FDD (Frequenzmehrfach-Zugriff) und TDD (Zeitvielfach-Zugriff) Betriebsmodi,
obwohl im Fall von TDD einige Details der zugehörigen Signalisierung für HS-DSCH
verschieden sind.
-
Die
grundlegende Struktur von HS-DSCH wird als auf zwei Architekturen
basierend angenommen: einer RNC-basierten Architektur, die mit der
Architektur Ausgabe '99
konsistent ist, und einer Node B-basierten Architektur zur Zeitsteuerung
(scheduling). Das Verlagern der Zeitsteuerung in den Node B ermöglicht eine
effizientere Implementierung von Zeitsteuerung, indem es der Zeitsteuerung
ermöglicht
wird, mit den aktuellsten Kanalinformationen zu arbeiten. Die Zeitsteuerung
kann die Modulation anpassen, um besser den derzeitigen Kanalbedingungen
und der derzeitigen Schwundumgebung zu entsprechen. Ferner kann
die Zeitsteuerung die Mehrbenutzer-Diversität ausnutzen, indem nur die
Benutzer in konstruktivem Schwund zeitlich eingeteilt werden. Weiterhin
besitzt der HSPDA Vorschlag das zusätzliche Potenzial, die RNC-basierte
HARQ Architektur sowohl in Bezug auf UE-Speicheranforderungen als
auch Übertragungsverzögerung zu
verbessern. Die Zeitsteuerung für
den HS-DSCH ist daher in dem Node B angeordnet, wobei der HS-DSCH
sich auf den Transportkanal bezieht, der zwischen MAC-hs und L1
intern im Node B angeordnet ist.
-
Es
gibt keine Identifikations-IE in Iub/Iur FP (FP, frame protocol),
um eine bestimmte UE zu identifizieren. Daher waren die dedizierten
Transportträger
nötig,
um eine bestimmte UE zu identifizieren, um die effiziente Verwendung
der Leistungssteuerfunktion über
die Funkschnittstelle zu ermöglichen.
Das bedeutet, dass die Anzahl von erforderlichen Transportträgern, die
zwischen dem SRNC und dem Node B reserviert werden müssen, die gleiche
ist wie die Anzahl von DSCH Datenströmen. Eine UE kann mehrere Datenströme aufweisen.
Damit das System richtig arbeitet, muss Kapazität, d. h. Bandbreite, für jeden
Transportträger
gemäß der reservierten
DSCH Kapazität über die
Funkschnittstelle reserviert werden. Z. B. falls die DSCH Kapazität in der
Funkschnittstelle 512 kbps beträgt
und es 10 Datenströme gibt,
die sich den Kanal teilen, ist die maximale erforderliche Transportkapazität 10 Mal
512 kbps über
die Iub-Schnittstelle, um die QoS sicherzustellen. Und da die Zeitsteuerung
nur durch MAC-sh in dem CRNC ausgeführt wird, wird in einem bestimmten
Zeitrahmen nur ein Transportträger
verwendet. Als Folge wird eine Menge Bandbreite verschwendet. Dies
erhöht
den Bedarf an Bandbreitenressourcen.
-
Die
Erfindung ist durch das gekennzeichnet, was in den unabhängigen Ansprüchen offenbart
ist.
-
Zusammenfassung der Erfindung
-
Die
Erfindung betrifft ein Verfahren zum Multiplexen eines Datenstroms
auf einen Transportträger über die
Iur- und Iub-Schnittstellen zwischen Serving Radio Network Controller
(SRNC) und Drift Radio Network Controller (D-RNC) oder Node B in
einem IP-Funkzugangsnetz.
Dies wird gemacht, um die effektive Nutzung der Transportressourcen über die zwei
Schnittstellen sicherzustellen, d. h. Iub/Iur. Um dies zu erreichen,
sollte der RNC und/oder Node B/RNC prüfen, ob bereits ein Transportträger existiert,
der für
einen HS-DSCH-Datenstrom über
die Iub/Iur-Schnittstelle verwendet werden kann. Daher wird ein
Transportträger-Identifikationscode
oder eine Transportträger-ID
benötigt,
um diesen Träger zwischen
RNC und Node B/RNC zu identifizieren.
-
Die
Zeitsteuerung bzw. -einteilung auf die Funkschnittstelle für DSCH wird
durch eine MAC-sh-Funktion ausgeführt, die im CRNC angeordnet
ist, wobei im HS-DSCH, wobei der HS-DSCH sich auf den Transportkanal
bezieht, der zwischen MAC-sh und L1 intern im Node B angeordnet
ist, die Zeiteinteilung auf die Funkschnittstelle durch die MAC-sh
ausgeführt
werden soll, die im Node B angeordnet ist. Daher kann die Identifizierung
des Transportträgers
durch andere Mittel ausgeführt
werden als die dedizierten Transportträger zwischen SRNC/CRNC und
Node B zu verwenden. Durch das Ermöglichen des Multiplexens von
HS-DSCH-Datenströmen
auf den gleichen Transportträger
kann das große
Maß an
Transportressourcen eingespart werden.
-
Vor
dem Senden irgendeiner Nachricht an den Node B/RNC, um einen neuen
Transportträger für HS-DSCH-Datenströme anzufordern,
prüft der RNC,
ob bereits ein Transportträger
zwischen RNC und Node B/RNC existiert, der für diesen Zweck verwendet werden
kann. Falls kein Transportträger
existiert, identifiziert durch eine Transportträger-ID, der verwendet werden
kann, um einen neuen HS-DSCH-Datenstrom zu transportieren, sendet
der RNC die Anforderung eines Transportträgers für einen HS-DSCH-Datenstrom
ohne Transportträger-ID, um
dem Node B/RNC anzuzeigen, dass ein neuer Transportträger benötigt wird.
-
Falls
der Transportträger
existiert, der verwendet werden kann, schließt der RNC die Transportträger-ID in
der Anforderungsnachricht ein, um dem Node B/RNC anzuzeigen, welchen
Transportträger
er für
diesen neuen HS-DSCH-Datenstrom verwenden möchte. Falls der Node B/RNC
die Anforderung akzeptiert, sollen keinen zusätzlichen Transportschichtinformationen
in der Antwortnachricht eingeschlossen werden. Anderenfalls schließt der Node B/RNC
neue Transportschichtinformationen in der Antwortnachricht ein,
um anzuzeigen, dass der neue Transportträger benötigt wird.
-
Es
gibt auch eine andere Möglichkeit
für den Node
B/RNC, um über
die Verwendung des Transportträgers
zu entscheiden. In diesem Fall wird der RNC die HS-DSCH-Anforderungs/Modifikationsnachricht
an den Node B/RNC ohne jede weitere Information senden. Der empfangende
Node B/RNC wird entscheiden, ob er einen neuen Transportträger zuweisen
oder einen existierenden Transportträger verwenden soll. Falls er
entscheidet, einen neuen Transportträger zuzuweisen, wird er mit
neuer Transportadresse und neuer Transportträger-ID antworten. Falls er entscheidet,
einen existierenden Transportträger
zu verwenden, wird er nur mit der existierenden Transportträger-ID antworten,
der ausgewählt worden
ist, als ein gemeinsam genutzter Transportträger für den neuen HS-DSCH-Datenstrom
durch den Node B/RNC verwendet zu werden, ohne neue Transportadresse.
-
In
der derzeitigen Spezifikation gibt es keine ID, die als eine Transportträger-ID verwendet
werden kann, um auf der Funknetzschicht einen bestimmten bereits
existierenden Transportträger
aus einem bestimmten UE-Kontext zwischen RNC und Node B zu identifizieren.
Es ist unmöglich,
dem Node B/RNC durch den RNC anzuzeigen, dass einer der existierenden
Transportträger
verwendet werden kann, um einen anderen Datenstrom für eine andere
oder die gleiche UE zu transportieren.
-
Um
die Transportträger-Auswahlfunktion
für HS-DSCH
zu ermöglichen,
soll eine neue Transportträger-ID
zwischen RNC und Node B/RNC in NBAP/RNSAP-Nachrichten eingeführt werden. Wenn
eine neue Transportträger-Dienstinstanz
erzeugt wird, wird ihr durch die RNL-Anwendung eine Transportträger-ID zugewiesen.
Diese Transportträger-ID
muss zumindest pro Schnittstelle eindeutig sein, d. h. zwischen
den zwei UTRAN-Knoten, die das entsprechende RNL-Anwendungsprotokoll
abschließen.
Die Transportträger-ID
wird sowohl durch Ausgangs- als auch Empfangs-Knoten (RNC, RNC/Node
B) für
die Lebensdauer der entsprechenden Transportträger-Dienstinstanz gespeichert.
-
Um
die Eindeutigkeit der Transportträger-ID sicherzustellen, könnte sie
durch einen der Endpunkte der Verbindung zugewiesen werden, oder
sie könnte
eine Kombination sein, so dass jedes Ende einen bestimmten Teil
der Kennung zuweist.
-
Bei
der vorliegenden Erfindung wird auch angenommen, dass das Multiplexen
von HS-DSCH-Datenströmen oberhalb
der Transportschicht, d. h. in der FP/MAC-Schicht bereitgestellt
wird.
-
Gemäß einem
anderen Aspekt der Erfindung wird ein IP-Funkzugangsnetz-Knoten
zum Multiplexen eines Datenstroms auf einen Transportträger über die
Iur- und Iub-Schnittstellen bereitgestellt, wobei der Knoten konfiguriert
ist, um eine Transportträgerressource
für einen
Datenstrom abzubilden bzw. zuzuweisen. Der Knoten (node) ist weiter
konfiguriert, um zu überprüfen, ob
es verfügbare
Transportträgerressourcen
in der Gruppe existierender Transportträger gibt. Wenn eine Transportträgerressource existiert,
die für
den Datenstrom verwendet werden kann, ist der Knoten konfiguriert,
um die existierende Transportträgerressource
für den
Datenstrom zu reservieren, und um eine Angabe der existierenden Transportträgerressource
in einem Transportträger-ID-Informationselement
an einen Serving Radio Network Controller (SRNC), einen Drift Radio
Network Controller (D-RNC)
oder einen Node B in einer NBAP/RNSAP-Nachricht zu senden, oder
eine neue Transportträgerressource
anzufordern, eine Angabe einer neuen Transportträgerressource in einem Transportträger-ID-Informationselement
zwischen dem Serving Radio Network Controller (SRNC), dem Drift
Radio Network Controller (D-RNC) oder dem Node B in einer NBAP/RNSAP-Nachricht
zu senden, und um die neue Transportträgerressource für den Datenstrom
zu reservieren.
-
Die
Vorzüge
der Erfindung können
wie folgt zusammengefasst werden: die verfügbare Transportkapazität (d. h.
Bandbreite) wird besser genutzt, aufgrund der verbesserten statistischen
gemeinsamen Nutzung von Transportträgern, z. B. wird eine AAL2 (ATM
Adaption Layer 2) Verbindung reduziert, da ein Träger durch
mehrere Benutzerdatenströme
gemeinsam genutzt werden kann. Die Häufigkeit des Aufbaus und Abbaus
von Transportträgern
wird deutlich verringert, da es keine Notwendigkeit gibt, einen
dedizierten Träger
für jeden
Benutzerdatenstrom zu haben.
-
Kurze Beschreibung der Zeichnung
-
Die
begleitende Zeichnung, die enthalten ist, um ein weitergehendes
Verständnis
der Erfindung bereitzustellen und die einen Teil dieser Beschreibung
bildet, stellt Ausführungsformen
der Erfindung dar und hilft zusammen mit der Beschreibung dabei, die
Prinzipien der Erfindung zu erläutern.
In der Zeichnung:
-
1 ist
ein Blockdiagramm, das ein Beispiel des Szenarios des Stands der
Technik darstellt, der sich auf das derzeitige Mobilnetz bezieht;
-
2 ist
ein allgemeines Protokollmodell für UTRAN-Schnittstellen von 1;
-
3 beschreibt
eine Funkschnittstellen-Architektur von HDSPA;
-
4 ist ein Signalisierungs-Schaubild, das eine
Ausführungsform
der vorliegenden Erfindung beschreibt; und
-
5 ist ein Signalisierungs-Schaubild, das eine
andere Ausführungsform
der vorliegenden Erfindung beschreibt.
-
Detaillierte Beschreibung
der Erfindung
-
Es
wird nun im Detail Bezug genommen auf die Ausführungsformen der vorliegenden
Erfindung, von denen Beispiele in der begleitenden Zeichnung dargestellt
sind.
-
In
den 4 und 5 sind
fünf Netzwerkelemente
offenbart. Zwei dieser Elemente sind zweimal benannt, d. h. Node
B/DRNC und Node B/SRNC. Diese Benennung wird gemacht, da diese zwei
Figuren nur zwei Beispiele der vorliegenden Erfindung beschreiben
und diese selben Elemente auch das in der Bezeichnung andere Element
repräsentieren könnten.
-
In 4 ist ein Signalisierungsschaubild offenbart,
welches einen Beispielfall beschreibt, in dem der Node B entscheidet,
keine existierende Transportträgerressource
zu verwenden. In 4 entscheidet der
Serving Radio Network Controller SRNC, einen HS-DSCH-Kanal aufzubauen
bzw. einzurichten, Punkt 1. Nach dieser Entscheidung sendet er eine
Radio Network Subsystem Application Part (RNSAP) Nachricht, die
den Aufbau bzw. die Einrichtung einer Funkverbindung anfordert,
Punkt 2. Der Parameter in dieser Nachricht ist [Mux Indication IE]. Dieser
Mux Indication IE kann die folgenden Werte aufweisen: „darf (may)" oder „soll nicht
(shall not)" in der
Anforderungsnachricht. Im Falle von „darf" kann der Empfänger entscheiden ob er Multiplexen
will oder nicht. Aber im Falle von „soll nicht" kann der Empfänger keine
Multiplex-Option verwenden. Die Nachricht wird an den Drift Radio
Network Controller DRNC gesendet.
-
Danach
sendet der Drift Radio Network Controller DRNC eine Node B Application
Part message (NBAP), welche die Einrichtung einer Funkverbindung
anfordert, an den Node B, Punkt 3. Der Parameter auch in dieser
Nachricht ist [Mux Indication IE]. Der Node B prüft dann, ob ein verfügbarer Transportträger für eine neue
Funkverbindung vorhanden ist, Punkt 4. In diesem Fall erfasst er,
dass kein geeigneter Transportträger
existiert und ein neuer Transportträger benötigt wird. Dann sendet der
Node B eine Funkverbindungsaufbau-Nachricht an den DRNC, um den DRNC über die
Parameter des neuen Transportträgers
zu informieren, den aufzubauen er entschieden hat. Die Parameter
sind [Transport Bearer ID IE, Binding ID IE, Transport Layer Address
IE], Punkt 5. Basierend auf der Information von dem Node B entscheidet
der DRNC, einen neuen Transportträger aufzubauen, Punkt 6. Schließlich sendet der
DRNC eine Funkverbindungsaufbau-Antwort mit Parameter [Transport
Bearer ID IE, Einding ID IE, Transport Layer Address IE] an den
SRNC.
-
In 5 ist ein Signalisierungsschaubild offenbart,
welches einen Beispielfall beschreibt, in dem der Node B entscheidet,
eine vorhandene Transportträgerressource
zu verwenden. In 5 entscheidet der
Serving Radio Network Controller SRNC, einen HS-DSCH-Kanal aufzubauen,
Punkt 1. Nach dieser Entscheidung sendet er eine Radio Network Subsystem
Application Part (RNSAP) Nachricht, die den Aufbau einer Funkverbindung
anfordert, Punkt 2. Die Nachricht wird an den Drift Radio Network
Controller DRNC gesendet. Der Parameter in dieser Nachricht ist
[Mux Indication IE]. Dieser Mux Indication IE kann die folgenden
Werte aufweisen: „darf
(may)" oder „soll nicht
(shall not)" in
der Anforderungsnachricht. Im Falle von „darf" kann der Empfänger entscheiden ob er Multiplexen
will oder nicht. Aber im Falle von „soll nicht" kann der Empfänger keine
Multiplex-Option verwenden. Der Drift Radio Network Controller DRNC
sendet eine Node B Application Part Nachricht (NBAP), die den Aufbau
einer Funkverbindung anfordert, an den Node B, Punkt 3. Der Parameter
auch in dieser Nachricht ist [Mux Indication IE]. Der Node B prüft dann,
ob ein verfügbarer
Transportträger
für eine
neue Funkverbindung vorhanden ist, Punkt 4. In diesem Fall erfasst
er, dass ein geeigneter Transportträger existiert und kein neuer
Transportträger
benötigt
wird. Dann sendet der Node B eine Funkverbindungsaufbau-Antwortnachricht
an den DRNC mit dem Parameter [Transport Bearer ID IE], um den vorhandenen
Transportträger
zu informieren, der für
diesen neuen Datenstrom verwendet werden soll, Punkt 5. Basierend
auf der Information vom Node B entscheidet der DRNC, keinen neuen
Transportträger aufzubauen,
und benutzt stattdessen einen existierenden Transportträger, der
mit der Transport Bearer ID angegeben wurde, Punkt 6. Schließlich sendet
der DRNC eine Funkverbindungsaufbau-Antwortnachricht mit Parameter
[Transport Bearer ID IE] an den SRNC. Dies ist alles, was benötigt wird,
da der SRNC einen existierenden Transportträger verwenden wird, und er
bereits die notwendigen Parameter für diesen Träger besitzt.
-
Das
Zuweisen für
den Transportträger-Identifikations-Code
oder Transport Bearer ID kann auf drei Arten erfolgen. Ein Ausgangs-RNC
weist die Transport Bearer ID zu, wenn ein neuer Transportträger für HS-DSCH
zwischen RNC und RNC/Node B benötigt
wird und schließt
die Transport Bearer ID in der Nachricht ein, die HS-DSCH Aufbau/Modifikation anfordert.
Wenn der empfangende Knoten (Node B oder DRNC) die neue Transport
Bearer ID erhält, speichert
er sie (mit anderen Transportschicht-bezogenen Informationen) und
gibt die Transport Bearer ID zurück
an den Ausgangsknoten mit zugewiesener Transportschichtinformation.
-
Wenn
der empfangende Node B/RNC eine Funkverbindungsaufba-Anforderung
für einen HS-DSCH-Kanal
von dem RNC ohne die Transport Bearer ID erhält, weist er die ID zu und
schließt
sie mit den Transportschichtinformationen in die Antwortnachricht
ein und speichert die Transport Bearer ID mit der korrekten Transportschichtinformation.
-
In
der dritten Option weisen sowohl der Ausgangs- als auch der Empfangsnetzknoten
einen Teil der Transport Bearer ID zu. In diesem Fall weist der RNC
den ersten Teil der Transport Bearer ID zu, wenn ein neuer Transportträger für HS-DSCH
zwischen RNC und RNC/Node B benötigt
wird, und schließt
den Teil der Transport Bearer ID in die Nachricht ein, die HS-DSCH Aufbau/Modifikation
anfordert. Nach dem Empfangen des ersten Teils der Transport Bearer
ID weist der Empfangsknoten den anderen Teil der ID zu und speichert
die ganze Transport Bearer ID (mit anderen Transportschicht-bezogenen
Informationen) und gibt die Transport Bearer ID zurück an den
Ausgangsknoten mit zugewiesener Transportschichtinformation.
-
Die
Transport Bearer ID wird in beiden Knoten so lange gespeichert,
wie der Transportträger existiert,
der dadurch identifiziert wird.
-
Es
ist einem Fachmann ersichtlich, dass mit dem Fortschritt der Technologie
die grundlegende Idee der Erfindung auf verschiedene Arten implementiert
werden kann und in verschiedenen Netzwerkumgebungen. Die Erfindung
und ihre Ausführungsformen
sind daher nicht auf die vorstehend beschriebenen Beispiele beschränkt. Stattdessen
können
sie innerhalb des Schutzumfangs der Ansprüche variieren.