DE602004000763T2

DE602004000763T2 - Verfharen zur Verwaltung der Dienstqualität (QOS) in einem Mobilfunkkommunikationssystem

Info

Publication number: DE602004000763T2
Application number: DE602004000763T
Authority: DE
Inventors: Nicolas Drevon; Anne Gabriel; Pascal Treillard
Original assignee: Evolium SAS
Current assignee: Evolium SAS
Priority date: 2003-01-31
Filing date: 2004-01-28
Publication date: 2007-05-31
Anticipated expiration: 2024-01-29
Also published as: FR2850828A1; ATE325509T1; EP1443779A1; CN1522080A; US20040252699A1; DE602004000763D1; EP1443779B1; JP2004254301A; US9204491B2; ES2262098T3; CN100358372C; FR2850828B1; JP4565849B2

Description

Die vorliegende Erfindung betrifft im Allgemeinen Mobilfunkkommunikationssysteme.
Die vorliegende Erfindung ist insbesondere auf Mobilfunkkommunikationssysteme der dritten Generation anwendbar, insbesondere des Typs UMTS ("Universal Mobile Telecommunication System").
Grundsätzlich sind Mobilfunkkommunikationssysteme Gegenstand einer Normung, und für weitere Informationen hierzu kann auf die entsprechenden Normen verwiesen werden, die von den entsprechenden Normungsorganisationen veröffentlicht werden.
Die allgemeine Architektur dieser Systeme ist in 1 dargestellt; sie umfasst im Wesentlichen:

– ein Funkzugangsnetz 1 oder RAN (für "Radio Access Network");
– ein Kernnetz 4 oder CN (für "Core Network").

Das RAN umfasst Netzelemente wie die Basisstationen 2 und Basisstation-Controller 3. Das RAN steht einerseits über eine Schnittstelle 6 in Verbindung mit mobilen Endgeräten 5 und andererseits über eine Schnittstelle 7 mit dem CN. Das CN 4 steht mit (nicht im Einzelnen dargestellten) externen Netzen in Verbindung. Innerhalb des RAN kommunizieren die Basisstationen mit den Basisstation-Controllern über eine Schnittstelle 8.
In Systemen des Typs UMTS wird das RAN als UTRAN ("UMTS Terrestrial Radio Access Network") bezeichnet, die Basisstationen werden als "Node B" (B-Knoten) bezeichnet, die Basisstation-Controller werden als RNC ("Radio Network Controller") bezeichnet, und die mobilen Endgeräte werden UE ("User Equipment"; Teilnehmereinrichtung) bezeichnet. Die Schnittstelle 6 wird als "Schnittstelle Uu" bezeichnet, die Schnittstelle 7 wird als "Schnittstelle Iu", bezeichnet, die Schnittselle 8 wird als "Schnittstelle Iub" bezeichnet, und eine Schnittstelle 9 zwischen RNCs, bezeichnet als "Schnittstelle Iur", wird außerdem noch eingeführt. Die Schnittstelle 6 wird auch als Funkschnittstelle bezeichnet, und die Schnittstellen 7, 8, 9 werden auch als terrestrische Schnittstellen bezeichnet.
Für einen gegebenen Node B wird der RNC, der ihn steuert, auch als CRNC (für "Controlling Radio Network Controller") bezeichnet. Der CRNC hat die Aufgabe, die Auslastung und Funkressourcenzuteilung für den von ihm gesteuerten Node B zu steuern. 2 veranschaulicht somit einen CRNC, der eine Node-B-Gruppe sowie die (nicht im Einzelnen dargestellten) Zellen steuert, die von diesen Node Bs abgedeckt werden.
Für eine gegebene Gesprächsverbindung, die sich auf ein gegebenes UE bezieht, gibt es einen RNC, bezeichnet als SRNC (für "Serving Radio Network Controller"), der eine Steuerungsaufgabe für die betrachtete Gesprächsverbindung hat. Ein an das UE angeschlossener Node B, der jedoch nicht vom SRNC gesteuert wird, kommuniziert mit dem SRNC über den RNC, der ihn steuert und er auch als DRNC (für "Drift RNC") bezeichnet wird, über die Schnittstelle Iur. Diese Situation ist insbesondere (jedoch nicht ausschließlich) möglich im Fall einer Übertragung mit Makrodiversität (oder "Soft Handover" auf Englisch). 3 veranschaulicht somit einerseits einen SRNC, der ein UE steuert, wobei dieser SRNC mit dem CN über die Schnittstelle Iu in Verbindung steht, und andererseits einen DRNC, der das UE für Funkverbindungen steuert, die für (nicht im Einzelnen dargestellte) Zellen aufgebaut werden, welche von diesem DRNC gesteuert werden.
Im Allgemeinen müssen derartige Systeme Verkehrsarten unterstützen können, deren Anforderungen an die Dienstgüte (oder QoS für "Quality of Service") voneinander sehr verschieden sein können. Die QoS-Architektur in einem System wie UMTS ist insbesondere in der vom 3GPP (" 3rd Generation Partnership Project") veröffentlichten Spezifikation 3GPP TS 23.107 definiert. Diese QoS-Architektur beruht auf Trägerdiensten, die durch QoS-Attribute gekennzeichnet sind. Man unterscheidet unterschiedliche Trägerdienste wie insbesondere die "Funkzugangsträger"-Dienste oder RAB ("Radio Access Bearer"), die "Funkträger"-Dienste oder RB ("Radio Bearer") und "Iu-Träger"-Dienste. Man unterscheidet zwischen verschiedenen QoS-Attributen wie insbesondere: Verkehrsklasse (oder "Traffic Class"), maximale Bitrate (oder "Maximum Bit Rate"), garantierte Bitrate (oder "Guaranteed Bit Rate"), Übertragungsverzögerung (oder "Transfer Delay"), Prioritätsbehandlung des Verkehrs (oder "Traffic Handling Priority") usw. Man unterscheidet außerdem vier Verkehrsklassen, und zwar jeweils für Anwendungen des Typs Gespräch (oder "conversational") mit kontinuierlichem Fluss (oder "streaming"), interaktiv (oder "interactive") oder Hintergrund (oder "background"). Andere QoS-Attribute als die Verkehrsklasse können außerdem für verschiedene Diensttypen derselben Verkehrsklasse unterschiedlich sein; zum Beispiel ist für die Verkehrsklasse "conversational" die Übertragungsverzögerung bei einem Dienst des Typs Telefonie kleiner als die Übertragungsverzögerung bei einem Dienst des Typs Videotelefonie, die ihrerseits zum Beispiel kleiner ist als die Übertragungsverzögerung bei einem Dienst des Typs Navigation im Netz (oder "Web Browsing"), beispielsweise für die Verkehrsklasse "interactive". Im Allgemeinen wird die Übertragungsverzögerung nur für die Verkehrsklassen "conversational" oder "streaming" angegeben, und die Priorität der Verkehrsverarbeitung wird nur für die Klasse "interactive" angegeben.
Generell ist ein Modell für die Kommunikationsprotokolle auf terrestrischen Schnittstellen definiert worden, bei dem man eine Funknetzschicht (oder "Radio Network Layer"), die Funktionalitäten im Zusammenhang mit dem Funknetz unabhängig von der für den Transport auf den terrestrischen Schnittstellen genutzten Technologie entspricht, und eine Transportnetzschicht (oder "Transport Network Layer") unterscheidet, die Funktionalitäten im Zusammenhang mit dem Transport in Abhängigkeit von der für den Transport auf den terrestrischen Schnittstellen genutzten Technologie entspricht. Im Allgemeinen können zwei Datentypen gemäß diesen Protokollen übermittelt werden: Daten, die von einem UE gesendeten oder empfangenen Verkehr entsprechen (oder Benutzerdaten oder "User Data"), und Daten, die der für den Betrieb des Systems benötigten Signalisierung entsprechen. Man kann auch zwei Signalisierungstypen unterscheiden: die mit der Funknetzschicht verbundene Signalisierung und die mit der Transportnetzschicht verbundene Signalisierung.
Die mit der Funknetzschicht verbundene Signalisierung entspricht insbesondere den folgenden Protokollen, die auch als Anwendungsprotokolle bezeichnet werden:

– für die Schnittstelle Iu das Protokoll RANAP ("Radio Network Aplication Part"), definiert insbesondere in der vom 3GPP veröffentlichten Spezifikation 3GPP TS 25.413;
– für die Schnittstelle Iub das Protokoll NBAP ("Node B Application Part"), definiert insbesondere in der vom 3GPP veröffentlichten Spezifikation 3GPP TS 25.433;
– für die Schnittstelle Iur das Protokoll RNSAP ("Radio Network Subsystem Application Part"), definiert insbesondere in der vom 3GPP veröffentlichten Spezifikation 3GPP TS 25.423.

Das Protokoll RANAP schließt insbesondere die Signalisierung in Verbindung mit dem Aufbau des Funkzugangsträgers (oder RAB für "Radio Access Bearer") ein. Das Protokoll NBAP schließt insbesondere die Signalisierung in Verbindung mit dem Aufbau einer Funkverbindung für die vom SRNC gesteuerten Zellen ein. Das Protokoll RNSAP schließt insbesondere die Signalisierung in Verbindung mit dem Aufbau einer Funkverbindung für die vom DRNC gesteuerten Zellen ein.
Grundsätzlich umfasst die Verwaltung der QoS in einem solchen System einerseits die mit dem Funkzugang verbundene QoS-Verwaltung unabhängig von der für den Transport auf den terrestrischen Schnittstellen genutzten Technologie und andererseits eine mit dem Transport verbundene QoS-Verwaltung, die von der für den Transport auf den terrestrischen Schnittstellen genutzten Technologie abhängt.
Die QoS-Verwaltung in Verbindung mit dem Funkzugang ist typisch für CDMA-Systeme ("Code Division Multiple Access") wie insbesondere UMTS und schließt Mechanismen ein wie beispielsweise: Funkzugangskontrolle, Auswahl von geeigneten Transportformaten auf den Transportkanälen usw. Allgemein ermöglichen die in den oben aufgeführten Anwendungsprotokollen definierten Signalisierungsaustauschvorgänge den betroffenen Netzelementen des UTRAN, die QoS-Anforderungen zu kennen, die für die Implementierung derartiger mit dem Funkzugang verbundener QoS-Verwaltungsmechanismen benötigt werden. Das wichtigste Netzelement des UTRAN, das von der Implementierung von mit dem Funkzugang verbundenen QoS-Verwaltungsmechanismen betroffen ist, ist der RNC in seiner Rolle als SRNC. Tatsächlich kann der SRNC ausgehend von den QoS-Parametern, die ihm vom CN (über das RANAP-Protokoll) signalisiert werden, entscheiden, welcher Diensttyp für ein UE angefordert wird, und folglich diese QoS-Parameter in Parameter übersetzen, die für den Aufbau von Funkverbindungen zwischen Node B und UE nutzbar sind, nötigenfalls über einen oder mehrere DRNC, und anschließend diese Parameter an die betroffenen Netzelemente signalisieren: Node B (über das NBAP-Protokoll), DRNC (über das RNSAP-Protokoll).
Im Allgemeinen wird für den Transport auf den terrestrischen Schnittstellen Paketvermittlung verwendet, um die Nutzung der auf diesen Schnittstellen verfügbaren Übertragungsressourcen zu optimieren. Grundsätzlich wurde die Paketvermittlung ursprünglich eher für Nicht-Echtzeit-Dienste (ohne strenge Anforderungen an Verzögerung und/oder Priorität) entwickelt, und zusätzliche Mechanismen, darunter insbesondere QoS-Verwaltungsmechanismen, sind anschließend eingeführt worden, damit die Paketvermittlung auch Echtzeitdienste (mit strengen Anforderungen an Verzögerung und/oder Priorität) unterstützen kann wie insbesondere Sprachübertragungsdienste. Insbesondere im Fall von UMTS ist die Einführung des Echtzeitbegriffs für paketvermittelte Dienste auch für das Problem des "Soft Handover" erforderlich, das vom RNC verlangt, dass er die Sendezeitpunkte der Daten an die verschiedenen Nodes Bs liefert, welche die Zellen steuern, mit denen das Mobiltelefon verbunden ist. Diese Sendezeitpunkte werden in Form von Nummern der Funk-Frames angegeben und begrenzen folglich die maximale Verzögerung, die für die Übertragung der Daten zwischen dem RNC und dem Node B zulässig ist. Diese maximale Verzögerung kann nicht auf einen zu hohen Wert gesetzt werden, insbesondere aus Gründen der Wirksamkeit von Leistungskontrolle und Funkzugangskontrolle.
Eine der im UTRAN genutzten Transporttechnologien ist die ATM-Technologie ("Asynchronous Transfer Mode"), die auf einem asynchronen Zeitmultiplexverfahren kleiner Pakete von fester Größe basiert, die als Zellen bezeichnet werden. Generell ist die ATM-Technologie genormt, und für weitere Informationen hierzu wird auf die entsprechenden Normen verwiesen, die von den entsprechenden Normungsorganisationen veröffentlicht werden. Es sei lediglich daran erinnert, dass ein ATM-Netz mittels einer als ATM-Schicht bezeichneten Schicht und einer ATM-Anpassungsschicht (oder AAL-Schicht für "ATM Adaptation Layer") bezeichneten Schicht modelliert werden kann, welche zwischen der ATM-Schicht und den Teilnehmern liegt. Die ATM-Schicht ist verbindungsorientiert und führt eine Zellenübertragung auf einer logischen Verbindung zwischen einer Quelle und einem Ziel aus, wobei diese logische Verbindung auch als virtuelle Verbindung oder VC (für "Virtual Channel") bezeichnet wird. Für die Anwendung des ATM auf den Transport innerhalb des UTRAN wird eine spezifische als AAL2 bezeichnete AAL-Schicht für die Teilenehmerdaten verwendet. Wenn ein UE mit dem UTRAN kommuniziert, wird eine dazugehörige logische Verbindung oder AAL2-Verbindung auf einer oder mehreren der von dem UTRAN betroffenen terrestrischen Schnittstellen aufgebaut. Im Fall des ATM schließen die Mechanismen, welche die Verwaltung der Transport-QoS ermöglichen, insbesondere eine Verbindungszugangskontrolle ein (um zu entscheiden, ob die Übertragungsressourcen dafür ausreichen, dass eine neue AAL2-Verbindungsanforderung angenommen werden kann, während gleichzeitig die geforderte QoS eingehalten wird) und eine Warteschlangenfunktion (oder "Scheduling" auf Englisch) zum Multiplexen von AAL2-Verbindungen innerhalb einer virtuellen Verbindung VC, zum Beispiel in Abhängigkeit von der Priorität.
Im Transportnetz können auch andere Technologien als ATM genutzt werden, wie insbesondere die IP-Technologie ("Internet Protocol"). Generell ist die IP-Technologie ebenfalls genormt, und für weitere Informationen hierzu kann in gleicher Weise auf die entsprechenden Normen verwiesen werden, die von den entsprechenden Normungsorganisationen veröffentlicht werden. Ebenso können im Fall der IP-Technologie Mechanismen vorgesehen werden, welche die Verwaltung der Transport-QoS ermöglichen.
Die vorliegende Erfindung interessiert sich besonders für die QoS-Verwaltung im Zusammenhang mit dem Transport und, noch weiter im Besonderen, für die Mechanismen, welche es den betroffenen Netzelementen des UTRAN ermöglichen, die für die Implementierung dieser QoS-Verwaltung benötigten QoS-Anforderungen zu kennen. Wenn keine derartige Kenntnis vorhanden ist oder bei einer unzureichenden Kenntnis kann diese QoS-Verwaltung nicht optimal umgesetzt werden, und daraus können folglich für die Teilnehmer unannehmbare QoS-Verschlechterungen entstehen.
Ausgehend von den Parametern RAB ("Radio Access Bearer"), die ihm vom CN über das RANAP-Protokoll signalisiert werden, kann der SRNC entscheiden, welcher Diensttyp für ein UE angefordert wird und somit welche QoS im Transportnetz verwendet werden sollte, um Benutzerdaten (oder "User Data" auf Englisch) für dieses UE in Abwärtsrichtung auf der Schnittstelle Iub zum Node B (beziehungsweise auf der Schnittstelle Iur zum DRNC) zu übertragen.
Ein Problem besteht für den Node B (beziehungsweise den DRNC) jedoch darin festzustellen, welche QoS im Transportnetz verwendet werden sollte, um Benutzerdaten für ein UE in Aufwärtsrichtung auf der Schnittstelle Iub zu übertragen (beziehungsweise in Aufwärtsrichtung auf der Schnittstelle Iur und/oder in Abwärtsrichtung auf der Schnittstelle Iub).
Eine erste Lösung zur Behebung dieses Problems ist folgende: Im Fall eines Transportnetzes, das mit ATM-Technologie arbeitet, enthält die Signalisierung im Zusammenhang mit der Transportnetzschicht das ALCAP-Protokoll ("Access Link Control Application Part"), wie es insbesondere in den von der ITU ("International Telecommunication Union") veröffentlichen Spezifikationen ITU-T Q.2360-1 und ITU-T Q.2360-2 definiert ist und das aufeinander folgenden Versionen der Norm 3GPP entspricht, nämlich der Version R99 (für die Spezifikation ITU-T Q.2360-1) und den Versionen R4 und danach R5 (für die Spezifikation ITU-T Q.2360-2). Die Spezifikation ITU-T Q.2360-2 definiert einen als "AAL Type 2 Requested Type Path") bezeichneten QoS-Parameter, der je nach Diensttyp einen der folgenden Werte annehmen kann: "stringent", "tolerant", "stringent bi-level". Dieser Parameter wird vom CRNC (beziehungsweise SRNC) an den Node B (beziehungsweise DRNC) übertragen und ermöglicht dem Node B (beziehungsweise DRNC), innerhalb der auf diese Weise von diesen drei möglichen Werten definierten Grenzen die für die Übertragung der Benutzerdaten geltenden QoS-Werte in Aufwärtsrichtung auf der Schnittstelle Iub (beziehungsweise in Aufwärtsrichtung und in Abwärtsrichtung auf der Schnittstelle Iur) zu kennen.
Diese erste Lösung ist jedoch erst ab der Version R4 der Norm 3GPP anwendbar. Sie ist weder im Fall der Version R99 noch im Fall der Version R5 anwendbar, wenn das Transportnetz mit der IP-Technologie arbeitet. Insbesondere ist nach dem derzeitigen Stand der Norm im Fall eines Transportnetzes, das mit IP-Technologie arbeitet, die Signalisierung im Zusammenhang mit der Transportnetzschicht von der Art, dass der Node B (beziehungsweise der DRNC) nicht weiß, welche QoS im Transportnetz verwendet werden sollte, um Benutzerdaten in Aufwärtsrichtung auf der Schnittstelle Iub (beziehungsweise in Aufwärtsrichtung auf der Schnittstelle Iur und/oder in Abwärtsrichtung auf der Schnittstelle Iub) zu übertragen. Außerdem ermöglichen die drei weiter oben aufgeführten Werte für den Parameter "AAL Type Requested Type Path" nicht notwendigerweise eine ausreichende Differenzierung der verschiedenen möglichen Diensttypen, und sie ermöglichen somit nicht notwendigenweise eine optimale Implementierung der QoS-Verwaltungsmechanismen.
Eine zweite Lösung zur Behebung dieses Problems ist folgende: Für den Fall der Version R99 der Norm wäre es, da keine genormte Lösung vorhanden ist, möglich, einen anbieterspezifischen oder "proprietären" Mechanismus im Node B (beziehungsweise DRNC) zu verwenden, um die Transportpriorität für jeden Diensttyp auf Iub (beziehungsweise Iur) zu konfigurieren. Zum Beispiel könnte der Node B (beziehungsweise DRNC) anhand der vom CRNC (beziehungsweise SRNC) über das ALCAP-Protokoll übertragenen Parameter wieder erkennen, welche Verbindungen Sprachdiensten zugeordnet sind, und ihnen eine hohe Transport-QoS zuweisen, und umgekehrt Verbindungen, die mit anderen Diensttypen verbunden sind (zum Beispiel der Navigation im Internet (oder "Web Browsing"), FTP, dedizierte Signalisierung, Videotelefonie usw.) eine geringere Transport-QoS zuweisen.
Diese zweite Lösung ist jedoch nur für den Fall anwendbar, dass der Node B (beziehungsweise der DRNC) und der CRNC (beziehungsweise der SRNC) vom selben Hersteller stammen. Sie ist für den Fall, in dem diese Netzelemente von unterschiedlichen Herstellern stammen, nicht anwendbar.
Die vorliegende Erfindung arbeitet mit einem anderen Ansatz zur Lösung dieses Problems. Die vorliegende Erfindung beruht insbesondere auf den folgenden Beobachtungen: Bestimmte QoS-Parameter, wie beispielsweise für die Übertragungsverzögerung (oder "Transfer Delay") und/oder die Prioritätsbehandlung des Verkehrs (oder "Traffic Handling Priority") repräsentative Parameter, wie sie insbesondere in der zuvor genannten Spezifikation 3GPP TS 23.107 definiert sind, sind von sehr großer Wichtigkeit, um die QoS und insbesondere die Transport-QoS innerhalb eines solchen Netzes zu garantieren. Nun werden aber derartige Parameter bereits für die QoS-Verwaltung im Zusammenhang mit dem Funkzugang verwendet. Beim derzeitigen Stand der Norm, und wie weiter oben erwähnt, bleibt bei der QoS-Verwaltung im Zusammenhang mit dem Funkzugang die Kenntnis derartiger QoS-Parameter im Wesentlichen lokal beim SRNC angesiedelt. Wie zuvor erwähnt, kann der SRNC nämlich anhand von Parametern RAB ("Radio Access Bearer"), die ihm vom CN (über das RANAP-Protokoll) signalisiert werden, entscheiden, welcher Diensttyp für ein UE erforderlich ist. Der SRNC kann daraufhin diese Parameter in Parameter übersetzen, die für den Aufbau von Funkverbindungen zwischen Node B und UE, nötigenfalls über einen oder mehrere DRNC, verwertbar sind, und anschließend diese Parameter an die betroffenen Netzelemente signalisieren: Node B (über das NBAP-Protokoll), DRNC (über das RNSAP-Protokoll). Derartige Parameter schließen insbesondere für den Aufbau einer Funkverbindung zwischen Node B und UE Parameter wie insbesondere Transportformatparameter oder TFCS (für "Transport Format Combination Set") ein, und nötigenfalls für ein Multiplexverfahren durch den DRNC auf gemeinsamen oder geteilten Transportkanälen Parameter wie die Verkehrsklasse (oder "Traffic Class") und die Prioritätsbehandlung des Verkehrs (oder "Traffic Handling Priority").
Beim derzeitigen Stand der Norm bietet eine solche Signalisierung der Transportformatparameter jedoch im Allgemeinen keine Möglichkeit, die QoS-Anforderungen für die Transportnetzschicht anzugeben, und eine solche Signalisierung der Verkehrsklasse und der Prioritätsbehandlung des Verkehrs erfolgt nur auf der Schnittstelle Iur (und nicht auf der Schnittstelle Iub) und nur im Fall von gemeinsamen oder geteilten Transportkanälen (und nicht im Fall von jeweils fest zugeordneten eigenen Kanälen). Außerdem bietet eine solche Signalisierung keine Möglichkeit, die QoS-Anforderungen für die Transportnetzschicht zumindest in Bezug auf die Übertragungsverzögerung anzugeben. Insbesondere ermöglicht sie nicht, unter verschiedenen Diensten der Klasse "conversational" eine Unterscheidung zwischen Diensten (wie insbesondere Telefoniediensten), welche eine geringe Übertragungsverzögerung erfordern, und Diensten (wie zum Beispiel Videotelefoniediensten), die größere Übertragungsverzögerungen tolerieren können, zu treffen.
WO 01 86974 offenbart ein Verfahren zur Verwaltung der Dienstgüte (QoS) in einem mobilen Netz. Nachrichten, welche die QoS definieren, werden unter den Teilnehmern unter der Kontrolle eines Controllers ausgetauscht.
Die vorliegende Erfindung hat insbesondere zum Ziel, alle oder einen Teil der Probleme zu lösen und/oder alle oder einen Teil der verschiedenen zuvor erwähnten Nachteile zu vermeiden. Die vorliegende Erfindung hat ebenso zum Ziel, verschiedene Mechanismen vorzuschlagen, die es den betroffenen Netzelementen des UTRAN ermöglichen, die Anforderungen an die Transport-QoS zu kennen, die für die Implementierung dieser QoS-Verwaltung benötigt werden. Allgemeiner hat die vorliegende Erfindung das Ziel, die Verwaltung der Dienstgüte in diesen Systemen zu verbessern und/oder zu vereinfachen.
Einer der Gegenstände der vorliegenden Erfindung ist ein Verfahren zur Verwaltung der Dienstgüte in einem Mobilfunkkommunikationsnetz, in dem die Kommunikationsprotokolle auf den terrestrischen Schnittstellen eine Funknetzschicht und eine Transportnetzschicht umfassen und in dem die Verwaltung der Dienstgüte eine mit der Funknetzschicht verbundene Dienstgüte-Verwaltung und eine mit der Transportnetzschicht verbundene Dienstgüte-Verwaltung umfasst, wobei dieses Verfahren umfasst:

– einen Schritt, bei dem ein als erstes Netzelement bezeichnetes Netzelement einem als zweites Netzelement bezeichneten anderen Netzelement mittels eines Signalisierungsprotokolls der Funknetzschicht mindestens einen Parameter signalisiert, der für die Transport-QoS oder die Dienstgüte für die Transportnetzschicht repräsentativ ist;
– einen Schritt, bei dem das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS nutzt.

Nach einem anderen kennzeichnenden Merkmal ist das erste Netzelement ein CRNC ("Controlling Radio Network Controller").
Nach einem anderen kennzeichnenden Merkmal ist das zweite Netzelement ein Node B oder eine Basisstation.
Nach einem anderen kennzeichnenden Merkmal ist das Signalisierungsprotokoll der Funknetzschicht ein Signalisierungsprotokoll (NBAP), das auf die Schnittstelle (Iub) zwischen dem CRNC und Node B anwendbar ist.
Nach einem anderen kennzeichnenden Merkmal nutzt das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS für die Übertragung in Aufwärtsrichtung auf der Schnittstelle (Iub) zwischen CRNC und Node B.
Nach einem anderen kennzeichnenden Merkmal ist das erste Netzelement ein SRNC ("Serving Radio Network Controller").
Nach einem anderen kennzeichnenden Merkmal ist das zweite Netzelement ein DRNC ("Drift Radio Network Controller").
Nach einem anderen kennzeichnenden Merkmal ist das Signalisierungsprotokoll der Funknetzschicht ein Signalisierungsprotokoll (RNSAP), das auf die Schnittstelle (Iur) zwischen SRNC und DRNC anwendbar ist.
Nach einem anderen kennzeichnenden Merkmal nutzt das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS für die Übertragung in Aufwärtsrichtung auf der Schnittstelle (Iur) zwischen SRNC und DRNC und/oder in Abwärtsrichtung auf der Schnittstelle (Iub) zwischen DRNC und Node B.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine für die Transport-QoS repräsentative Parameter einem spezifischen Parameter, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine für die Transport-QoS repräsentative Parameter mindestens einem Parameter RAB ("Radio Access Bearer"), der ebenso als Parameter der Transport-QoS genutzt werden kann.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine Parameter RAB ("Radio Access Bearer"), der ebenso als Parameter der Transport-QoS genutzt werden kann, der Übertragungsverzögerung.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine Parameter RAB ("Radio Access Bearer"), der ebenso als Parameter der Transport-QoS genutzt werden kann, der Prioritätsverarbeitung des Verkehrs.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine Parameter RAB ("Radio Access Bearer"), der ebenso als Parameter der Transport-QoS genutzt werden kann, der Verkehrsklasse.
Nach einem anderen kennzeichnenden Merkmal wird der mindestens eine Parameter, der dem mindestens einen Parameter RAB ("Radio Access Bearer") entspricht und der ebenso als Parameter der Transport-QoS genutzt werden kann, vom RANAP-Protokoll in das NBAP-Protokoll kopiert oder übersetzt beziehungsweise vom RANAP-Protokoll in das RNSAP-Protokoll.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine für die Transport-QoS repräsentative Parameter mindestens einem Parameter, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB ("Radio Access Bearer") zugeordnet werden kann, der ebenso als Parameter der Transport-QoS genutzt werden kann.
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine Parameter, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB ("Radio Access Bearer") zugeordnet werden kann, welcher ebenso als Parameter der Transport-QoS genutzt werden kann, einem Parameter für die zeitliche Einstellung, wobei die kleinsten Werte dieses Parameters Verbindungen zugewiesen werden, welche die höchsten Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsbehandlung des Verkehrs aufweisen, und wobei die höchsten Werte dieses Parameters Verbindungen zugewiesen werden, welche die geringsten Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsbehandlung des Verkehrs aufweisen.
Nach einem anderen kennzeichnenden Merkmal ist der Parameter für die zeitliche Einstellung der Parameter TOAWS ("Time of Arrival Window Start").
Nach einem anderen kennzeichnenden Merkmal entspricht der mindestens eine Parameter, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB ("Radio Access Bearer") zugeordnet werden kann, welcher ebenso als Parameter der Transport-QoS genutzt werden kann, einem Parameter, der für die Anzahl der dedizierten Kanäle (oder DCH für "Dedicated Channel") repräsentativ ist, die einer Verbindung zugeteilt werden, wobei eine hohe Anzahl von dedizierten Kanälen für Verbindungen zugeteilt wird, welche hohe Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsverarbeitung des Verkehrs aufweisen, und wobei eine weniger hohe Anzahl von dedizierten Kanälen Verbindungen zugeteilt werden, die weniger hohe Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsverarbeitung des Verkehrs aufweisen.
Ein weiterer Gegenstand der vorliegenden Erfindung ist ein Netzelement, welches Mittel für die Implementierung eines solchen Verfahrens umfasst.
Nach einem anderen kennzeichnenden Merkmal entspricht das Netzelement einem CRNC.
Nach einem anderen kennzeichnenden Merkmal entspricht das Netzelement einem SRNC.
Nach einem anderen kennzeichnenden Merkmal entspricht das Netzelement einem DRNC.
Nach einem anderen kennzeichnenden Merkmal entspricht das Netzelement einem Node B.
Weitere Gegenstände und kennzeichnende Merkmale der vorliegenden Erfindung werden bei der Lektüre der folgenden Beschreibung eines Ausführungsbeispiels ersichtlich werden, die unter Bezugnahme auf die beigefügten Zeichnungen erfolgt, auf denen:
1, die weiter oben beschrieben wurde, die allgemeine Architektur eines Mobilfunkkommunikationssystems darstellt, wie insbesondere UMTS eines ist;
2 und 3, die weiter oben beschrieben wurden, die verschiedenen möglichen Aufgaben eines RNC darstellen: CRNC, SRNC, DRNC.
Nachfolgend werden verschiedene Ausführungsformen der vorliegenden Erfindung beschrieben.
In einer ersten Ausführungsform können einer oder mehrere neue Parameter in eine oder mehrere Signalisierungsnachrichten eingefügt werden, die vom CRNC zum Node B über das NBAP-Protokoll (beziehungsweise vom SRNC zum DRNC über das RNSAP-Protokoll) übertragen werden. Mit Hilfe dieses oder dieser neuen Parameter kann der CRNC (beziehungsweise SRNC) ein hohes Niveau der Transport-QoS bestimmten Diensttypen zuweisen (insbesondere Diensttypen, die hohe Anforderungen an Verzögerung und/oder Priorität aufweisen) und ein niedrigeres Niveau der Transport-QoS anderen Diensttypen (insbesondere Diensttypen, die weniger strenge Anforderungen an Verzögerung und/oder Priorität aufweisen). Insbesondere kann ein hohes Niveau der Transport-QoS Sprachdiensten zugewiesen werden, und ein niedrigeres Niveau der Transport-QoS kann anderen Diensttypen zugewiesen werden. Mittlere QoS-Niveaus können ebenfalls in ausreichender Zahl vorgesehen werden, um eine ausreichende Differenzierung der Diensttypen und somit eine Optimierung der QoS-Verwaltung vorzusehen. Insbesondere dieser oder diese neuen Parameter können in einer Nachricht wie beispielsweise der Nachricht "Radio Link Setup Request" übertragen werden, die vom CRNC zum Node B über das NBAP-Protokoll (beziehungsweise vom SRNC zum DRNC über das RNSAP-Protokoll) übertragen wird.
In einer zweiten Ausführungsform können einer oder mehrere neue Parameter, deren Aufgabe es ist, die Parameterwerte der Transport-QoS nach Diensttypen anzugeben, in eine oder mehrere Signalisierungsnachrichten eingefügt werden, die vom CRNC zum Node B über das NBAP-Protokoll (beziehungsweise vom SRNC zum DRNC über das RNSAP-Protokoll) übertragen werden. Insbesondere können dieser oder diese neuen Parameter von Parametern RAB ("Radio Access Bearer") abgeleitet werden, die an den SRNC über das RANAP-Protokoll übertragen werden. Es sei nämlich daran erinnert, dass das RANAP-Protokoll die Übertragung vom CN zum SRNC von folgenden Parametern RAB einschließt:

– der Verkehrsklasse (oder "Traffic Class");
– der Übertragungsverzögerung (oder "Transfer Delay") für Dienste der Klasse "conversational" oder "streaming";
– die Prioritätsbehandlung (oder "Traffic Handling Priority") für Dienste der Klasse "interactive".

Insbesondere dieser oder diese neuen Parameter können einem oder mehreren Parametern "Traffic Class", "Transfer Delay" und "Traffic Handling Priority" entsprechen, die dann vom RANAP-Protokoll auf das NBAP-Protokoll kopiert (oder in es übersetzt) werden können, oder einem oder mehreren Parametern "Transfer Delay" und "Traffic Handling Priority" die dann vom RANAP-Protokoll auf das RNSAP-Protokoll kopiert (oder in es übersetzt werden können (wobei der Parameter "Traffic Class" bereits vom RANAP-Protokoll auf das RNSAP-Protokoll kopiert wurde).
Insbesondere dieser oder diese neuen Parameter können in einer Nachricht wie der Nachricht "Radio Link Setup Request" vom CRNC zum Node B über das NBAP-Protokoll übertragen werden (beziehungsweise vom SRNC zum DRNC über das RNSAP-Protokoll).
In einer dritten Ausführungsform können einer oder mehrere vorhandene Parameter, die dem Node B (beziehungsweise DRNC) über das NBAP-(beziehungsweise RNSAP-)Protokoll mitgeteilt werden, vom Node B (beziehungsweise DRNC) genutzt werden, um ein hohes Niveau der Transport-QoS bestimmten Diensttypen zuzuweisen (insbesondere Diensttypen mit strengen Anforderungen an Verzögerung und/oder Priorität), und ein geringeres Niveau der Transport-QoS anderen Diensttypen (insbesondere Diensttypen mit weniger strengen Anforderungen an Verzögerung und/oder Priorität).
Ein erstes mögliches Beispiel für solche vorhandenen Parameter ist der Parameter TOAWS ("Time of Arrival Window Start"), der insbesondere in der Spezifikation 3GPP TS 25.402 definiert ist. Es sei daran erinnert, dass für die Übertragung von Benutzerdaten auf den terrestrischen Schnittstellen als "Frame Protocol" bezeichnete spezifische Protokolle verwendet werden, wie sie insbesondere in den Spezifikationen 3GPP TS 25.425, 3GPP TS 25.427, 3GPP TS 25.435 definiert sind. Diese Protokolle sehen eine Datenstrukturierung nach einem Frame-Format vor sowie Funktionen zur zeitlichen Einstellung und Synchronisation, an denen insbesondere der Parameter TOAWS beteiligt ist. Genauer gesagt, wird ein Empfangsfenster definiert, in dem der Ankunftszeitpunkt eines vom RNC übertragenen Frames am Node B liegen sollte. Dieses Fenster ist durch einen Anfangszeitpunkt des Fensters (oder TOAWS für "Time of Arrival Window Start") definiert, der im Verhältnis zu einem Endzeitpunkt des Fensters (oder TOAWE für "Time of Arrival Window End") definiert ist, der selbst im Verhältnis zu einem spätestmöglichen Zeitpunkt der Ankunft (oder LTOA für "Latest Time of Arrival") definiert ist. Wenn der Ankunftszeitpunkt eines Frames vor TOAWS oder nach TOAWE liegt, dann wird eine zeitliche Anpassung vom Node B beim RNC angefordert. Damit soll sichergestellt werden, dass der Node B Frames innerhalb einer Zeit empfängt, die für ihre Rückübertragung zu vorher festgelegten Zeitpunkten auf der Funkschnittstelle geeignet ist, das heißt, relativ früh, um die notwendigen Verarbeitungsschritte vor einer solchen Rückübertragung durchführen zu können, jedoch nicht zu früh, um Wartezeiten zu vermeiden. Ein solches Empfangsfenster wird im Node B bei jedem Aufbau einer Funkverbindung konfiguriert. Somit werden Werte von TOAWE und TOAWS vom SRNC (beziehungsweise SRNC) dem Node B (beziehungsweise DRNC) in verschiedenen Nachrichten signalisiert, die gemäß dem NBAP-(beziehungsweise RNSAP-)Protokoll vorgesehen sind, wie insbesondere die Nachricht "Radio Link Set-up Request" usw.
Nach einem der Aspekte der Erfindung kann der CRNC (beziehungsweise SRNC) auf diese Weise insbesondere die niedrigsten TOAWS-Werte Verbindungen mit einem höheren Niveau der Transport-QoS zuweisen, und der Node B (beziehungsweise der DRNC) kann daraufhin diese TOAWS-Werte für die QoS-Verwaltung der Transport-QoS nutzen. Mit anderen Worten, ein Parameter für die zeitliche Einstellung wie der Parameter TOAWS kann als ein für die Transport-QoS repräsentativer Parameter betrachtet werden, und zwar in dem Maße, in dem er einem Niveau der Transport-QoS oder mindestens einem Parameter RAB zugeordnet werden kann, der als Parameter der Transport-QoS genutzt werden kann. Der CRNC (beziehungsweise der SRNC) kann zum Beispiel einen TOAWS-Wert gleich 10 ms Verbindungen mit einem hohen Niveau der Transport-QoS zuweisen (wie insbesondere Verbindungen für Sprachdienste) oder einen höheren TOAWS-Wert Verbindungen mit einem niedrigern Niveau der Transport-QoS, und er kann diesen Wert dem Node B (beziehungsweise dem DRNC) insbesondere in der Nachricht NBAP (beziehungsweise RNSAP) "Radio Link Setup Request" signalisieren. Der Node B (beziehungsweise der DRNC) weist daraufhin ein hohes Niveau der Transport-QoS Verbindungen mit den niedrigsten TOAWS-Werten zu, oder ein niedrigeres Niveau der Transport-QoS Verbindungen mit höheren TOAWS-Werten.
Ein zweites mögliches Beispiel für derartige vorhandene Parameter ist die Anzahl der dedizierten Kanäle (oder DCH für "Dedicated Channel"), die einer Verbindung zugeteilt werden. In bekannter Weise kann der CRNC (beziehungsweise SRNC) mehrere DCH-Kanäle Verbindungen mit einem hohen Niveau der Transport-QoS (wie insbesondere Verbindungen für Sprachdienste) zuweisen, oder einen einzigen CDH-Kanal für Verbindungen anderer Diensttypen mit einem niedrigeren Niveau der Transport-QoS. Zum Beispiel werden für Sprache, die mit AMR-Codierung ("Adaptive Multi-Rate") arbeitet, im Allgemeinen drei verschiedene Transportkanäle verwendet: einer für sogenannte Bits der Klasse A, einer für sogenannte Bits der Klasse B und einer für sogenannte Bits der Klasse C, wobei diese drei Bitklassen unterschiedlichen Wichtigkeitsstufen der Bits entsprechen. Man kann zum Beispiel auch auf die Spezifikation 3GPP TS 34.108 verweisen. Der CRNC (beziehungsweise SRNC) kann dann diese Anzahl dedizierter Kanäle an den Node B (beziehungsweise den DRNC) signalisieren, insbesondere in der Nachricht NBAP (beziehungsweise RNSAP) "Radio Link Setup Request".
Nach einem der Aspekte der Erfindung kann der Node B (beziehungsweise der DRNC) dann insbesondere ein hohes Niveau der Transport-QoS Verbindungen wie beispielsweise Verbindungen für Sprachdienste zuweisen, denen drei DCH-Kanäle zugeteilt sind, oder ein niedrigeres Niveau der Transport-QoS Verbindungen, denen ein einziger DCH-Kanal zugeteilt ist. Mit anderen Worten: Ein Parameter wie die Anzahl der dedizierten Kanäle, die einer Verbindung zugeteilt sind, kann ebenfalls als ein für die Transport-qoS repräsentativer Parameter angesehen werden, und zwar in dem Maße, in dem er einem Niveau der Transport-QoS oder mindestens einem Parameter RAB zugeordnet werden kann, der als Parameter der Transport-QoS genutzt werden kann.
Nach einem anderen Beispiel kann der SRNC:

– die Verkehrsklasse "conversational" zuordnen und Verbindungen für Sprachdienste drei DCH-Kanäle zuteilen;
– die Verkehrsklasse "conversational" zuordnen und Verbindungen für andere Diensttypen der Klasse "conversational" (zum Beispiel für Videotelefonie-Dienste) nur einen DCH-Kanal zuteilen;
– anderen Verbindungen andere Verkehrsklassen zuordnen;

Diesen verschiedenen Ausführungsformen ist gemeinsam, dass jedes Mal, wenn der CRNC (beziehungsweise der SRNC) eine Funkverbindung aufbaut, der ein Diensttyp mit hohen Anforderungen an Verzögerung und/oder Priorität zugeordnet ist, er dem Node B (beziehungsweise dem DRNC) über das NBAP-(beziehungsweise das RNSAP-)Protokoll signalisiert, dass die dieser bestimmten Funkverbindung zugeordnete Transportverbindung ein hohes Niveau der Transport-QoS aufweist (insbesondere hohe Anforderungen an Verzögerung und/oder Priorität). Umgekehrt signalisiert der CRNC (beziehungsweise der SRNC) jedes Mal, wenn er eine Funkverbindung aufbaut, die einem Diensttyp mit einem niedrigeren Niveau der Transport-QoS (insbesondere mit geringeren Anforderungen an Verzögerung und/oder Priorität) zugeordnet ist, dem Node B (beziehungsweise dem DRNC) über das NBAP-(beziehungsweise das RNSAP-)Protokoll, dass die dieser bestimmten Funkverbindung zugeordnete Transportverbindung ein niedrigeres Niveau der Transport-QoS aufweist (insbesondere geringere Anforderungen an Verzögerung und/oder Priorität).
Mit Hilfe dieser Information ist der Node B (beziehungsweise der DRNC) nun in der Lage, Mechanismen zur Verwaltung der Transport-QoS in Aufwärtsrichtung auf der Schnittstelle Iub (beziehungsweise in Aufwärtsrichtung auf der Schnittstelle Iur und/oder in Abwärtsrichtung auf der Schnittstelle Iub) so zu implementieren, dass die vom CRNC (beziehungsweise dem SRNC) angegebenen Anforderungen an die Transport-QoS erfüllt werden, insbesondere Anforderungen an Verzögerung und/oder Priorität. Dies ermöglicht insbesondere, die Verzögerungsanforderungen für Sprachdienste zu erfüllen.
Die vorliegende Erfindung hat auch ein Netzelement (wie insbesondere den CRNC, SRNC, DRNC, Node B) zum Gegenstand, das Mittel zur Implementierung eines Verfahrens gemäß der Erfindung umfasst.
Da die einzelne Ausführung derartiger Mittel für den Fachmann keine besondere Schwierigkeit aufweist, brauchen derartige Mittel hier nicht ausführlicher beschrieben zu werden, als es hier zuvor durch ihre Funktion erfolgt ist.

Claims

Verfahren zur Verwaltung der Dienstgüte in einem Mobilfunkkommunikationsnetz, in dem die Kommunikationsprotokolle auf den terrestrischen Schnittstellen eine Funknetzschicht und eine Transportnetzschicht umfassen und in dem die Verwaltung der Dienstgüte eine mit der Funknetzschicht verbundene Dienstgüte-Verwaltung und eine mit der Transportnetzschicht verbundene Dienstgüte-Verwaltung umfasst, wobei dieses Verfahren gekennzeichnet ist durch: – einen Schritt, bei dem ein als erstes Netzelement bezeichnetes Netzelement einem als zweites Netzelement bezeichneten anderen Netzelement mittels eines Signalisierungsprotokolls der Funknetzschicht mindestens einen Parameter signalisiert, der für die Transport-QoS oder die Dienstgüte für die Transportnetzschicht repräsentativ ist; – einen Schritt, bei dem das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS nutzt.
Verfahren nach Anspruch 1, bei dem das erste Netzelement ein CRNC, Controlling Radio Network Controller, ist.
Verfahren nach Anspruch 2, bei dem das zweite Netzelement ein Node B oder eine Basisstation ist.
Verfahren nach einem der Ansprüche 2 oder 3, bei dem das Signalisierungsprotokoll der Funknetzschicht ein Signalisierungsprotokoll, NBAP, ist, das auf die Schnittstelle zwischen CRNC und Node B anwendbar ist.
Verfahren nach einem der Ansprüche 2 bis 4, bei dem das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS für die Übertragung in Aufwärtsrichtung auf der Schnittstelle zwischen CRNC und Node B nutzt.
Verfahren nach Anspruch 1, bei dem das erste Netzelement ein SRNC, Serving Radio Network Controller, ist.
Verfahren nach Anspruch 6, bei dem das zweite Netzelement ein DRNC, Drift Radio Network Controller, ist.
Verfahren nach einem der Ansprüche 6 oder 7, bei dem das Signalisierungsprotokoll der Funknetzschicht ein Signalisierungsprotokoll, RNSAP, ist, das auf die Schnittstelle zwischen SRNC und DRNC anwendbar ist.
Verfahren nach einem der Ansprüche 6 bis 8, bei dem das zweite Netzelement den mindestens einen Parameter für die Verwaltung der Transport-QoS für die Übertragung in Aufwärtsrichtung auf der Schnittstelle zwischen SRNC und DRNC und/oder in Abwärtsrichtung auf der Schnittstelle zwischen DRNC und Node B nutzt.
Verfahren nach einem der Ansprüche 1 bis 9, bei dem der mindestens eine für die Transport-QoS repräsentative Parameter einem spezifischen Parameter entspricht, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.
Verfahren nach einem der Ansprüche 1 bis 9, bei dem der mindestens eine für die Transport-QoS repräsentative Parameter mindestens einem Parameter RAB, Radio Access Bearer, entspricht, der ebenso als Parameter der Transport-QoS genutzt werden kann.
Verfahren nach Anspruch 11, bei dem der mindestens eine Parameter RAB, der ebenso als Parameter der Transport-QoS genutzt werden kann, der Übertragungsverzögerung entspricht.
Verfahren nach Anspruch 11, bei dem der mindestens eine Parameter RAB, der ebenso als Parameter der Transport-QoS genutzt werden kann, der Prioritätsverarbeitung des Verkehrs entspricht.
Verfahren nach Anspruch 11, bei dem der mindestens eine Parameter RAB, der ebenso als Parameter der Transport-QoS genutzt werden kann, der Verkehrsklasse entspricht.
Verfahren nach einem der Ansprüche 11 bis 14, bei dem der mindestens eine Parameter RAB, der ebenso als Parameter der Transport-QoS genutzt werden kann, vom RANAP-Protokoll in das NBAP-Protokoll kopiert oder übersetzt wird, beziehungsweise vom RANAP-Protokoll in das RNSAP-Protokoll.
Verfahren nach einem der Ansprüche 1 bis 9, bei dem der mindestens eine für die Transport-QoS repräsentative Parameter mindestens einem Parameter entspricht, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB, Radio Access Bearer, zugeordnet werden kann, der ebenso als Parameter der Transport-QoS genutzt werden kann.
Verfahren nach Anspruch 16, bei dem der mindestens eine Parameter, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB zugeordnet werden kann, welcher ebenso als Parameter der Transport-QoS genutzt werden kann, einem Parameter für die zeitliche Einstellung entspricht, wobei die kleinsten Werte dieses Parameters Verbindungen zugewiesen werden, welche die höchsten Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsbehandlung des Verkehrs aufweisen, und wobei die höchsten Werte dieses Parameters Verbindungen zugewiesen werden, welche die geringsten Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsbehandlung des Verkehrs aufweisen.
Verfahren nach Anspruch 17, bei dem der Parameter für die zeitliche Einstellung der Parameter TOAWS, Time of Arrival Window Start, ist.
Verfahren nach Anspruch 16, bei dem der mindestens eine Parameter, der einem Niveau der Transport-QoS oder mindestens einem Parameter RAB zugeordnet werden kann, welcher ebenso als Parameter der Transport-QoS genutzt werden kann, einem Parameter entspricht, der für die Anzahl der dedizierten Kanäle repräsentativ ist, die einer Verbindung zugeteilt werden, wobei eine hohe Anzahl von dedizierten Kanälen für Verbindungen zugeteilt wird, welche hohe Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsverarbeitung des Verkehrs aufweisen, und wobei eine weniger hohe Anzahl von dedizierten Kanälen Verbindungen zugeteilt werden, die weniger hohe Anforderungen an die Übertragungsverzögerung und/oder die Prioritätsverarbeitung des Verkehrs aufweisen.
Netzelement, umfassend Mittel zur Implementierung eines Verfahrens nach einem der Ansprüche 1 bis 19.
Funknetz-Controller CRNC, umfassend Mittel, um einem Node B mit Hilfe eines Signalisierungsprotokolls einer Funknetzschicht, das dem auf die Schnittstelle Iub zwischen dem Funknetz-Controller CRNC und dem Node B anwendbaren NBAP-Protokoll entspricht, mindestens einen Parameter zu signalisieren, der für die Dienstgüte für die Transportnetzschicht repräsentativ ist.
Funknetz-Controller nach Anspruch 21, umfassend Mittel, um den mindestens einen Parameter in einer Nachricht Radio Link Setup Request zu signalisieren.
Funknetz-Controller nach einem der Ansprüche 21 oder 22, bei dem der mindestens eine Parameter einem spezifischen Parameter entspricht, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.
Funknetz-Controller SRNC, umfassend Mittel, um einem Funknetz-Controller DRNC mit Hilfe eines Signalisierungsprotokolls einer Funknetzschicht, das dem auf die Schnittstelle Iur zwischen Funknetz-Controller SRNC und Funknetz-Controller DRNC anwendbaren RNSAP-Protokoll entspricht, mindestens einen Parameter zu signalisieren, der für die Dienstgüte für die Transportnetzschicht repräsentativ ist.
Funknetz-Controller nach Anspruch 24, umfassend Mittel, um den mindestens einen Parameter in einer Nachricht Radio Link Setup Request zu signalisieren.
Funknetz-Controller nach einem der Ansprüche 24 oder 25, bei dem der mindestens eine Parameter einem spezifischen Parameter entspricht, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.
Funknetz-Controller DRNC, umfassend: – Mittel, um von einem Funknetz-Controller SRNC mit Hilfe eines Signalisierungsprotokolls einer Funknetzschicht, das dem auf die Schnittstelle Iur zwischen Funknetz-Controller SRNC und Funknetz-Controller DRNC anwendbaren RNSAP-Protokoll entspricht, mindestens einen Parameter zu empfangen, der für die Dienstgüte für die Transportnetzschicht repräsentativ ist; – Mittel, um den mindestens einen Parameter zur Verwaltung der Transport-Dienstgüte für die Übertragung in Aufwärtsrichtung auf der Schnittstelle Iur zwischen Funknetz-Controller SRNC und Funknetz-Controller DRNC zu nutzen.
Funknetz-Controller nach Anspruch 27, umfassend Mittel, um den mindestens einen Parameter in einer Nachricht Radio Link Setup Request zu empfangen.
Funknetz-Controller nach einem der Ansprüche 27 oder 28, bei dem der mindestens eine Parameter einem spezifischen Parameter entspricht, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.
Node B, umfassend – Mittel, um von einem Funknetz-Controller CRNC mit Hilfe eines Signalisierungsprotokolls einer Funknetzschicht, das dem auf die Schnittstelle Iub zwischen Funknetz-Controller CRNC und Node B anwendbaren NBAP-Protokoll entspricht, mindestens einen Parameter zu empfangen, der für die Dienstgüte für die Transportnetzschicht repräsentativ ist; – Mittel, um den mindestens einen Parameter zur Verwaltung der Transport-Dienstgüte für die Übertragung in Aufwärtsrichtung auf der Schnittstelle Iub zwischen Funknetz-Controller CRNC und Node B zu nutzen.
Node B nach Anspruch 30, umfassend Mittel, um den mindestens einen Parameter in einer Nachricht Radio Link Setup Request zu empfangen.
Node B nach einem der Ansprüche 30 oder 31, bei dem der mindestens eine Parameter einem spezifischen Parameter entspricht, dessen Aufgabe es ist, ein Niveau der Transport-QoS anzugeben.