Derartige Verfahren bzw. Systeme finden u. a. in Mobilfunksys- temen der dritten Generation, wie z. B. UMTS (Universal Mobile Telecommunications System) Anwendung.

Beim Mobilfunksystem der dritten Generation UMTS erfolgt die Übertragung von Informationen zu einem Anwender durch Reser- vierung einer physikalischen Ressource. Bei der Übertragung von Daten-egal welcher Art-wird im Mobilfunk zwischen zwei Übertragungsrichtungen unterschieden. Allgemein wird die Datenübertragung von der im Allgemeinen ortsfesten Basissta- tion (Bezeichnung im GSM-Global System for Mobile Communi- cations) bzw."Node B" (Bezeichnung einer Basisstation in UMTS) zu den mobilen Endgeräten (in UMTS Mobilstationen) als Übertragung in sogenannter"Downlink"-Richtung, d. h. Abwärts- strecke, bezeichnet. Bei der Datenübertragung in der Gegen- richtung von einem Endgerät zu der Basisstation spricht man von Übertragung in sogenannter"Uplink"-Richtung, d. h. Auf- wärtsstrecke. Bei UMTS sind für die Übertragung über die Luftschnittstelle zwei Modi vorgesehen : Beim Frequenzduplex- (Frequency Division Duplex-FDD) Modus erfolgt die Übertra- gung in Up-und Downlink-Richtung auf unterschiedlichen Fre- quenzen, beim Zeitduplex- (Time Division Duplex TDD) Modus wird nur eine Trägerfrequenz verwendet. Durch Zuweisung von Zeitschlitzen erfolgt eine Trennung der Up-und Downlink- Richtung. Die Teilnehmer werden bei beiden Modi durch Aufprä- gen orthogonaler Codes, sogenannter"Channelization Codes", auf die Informationsdaten getrennt. Dieses Mehrfachzugriffs- verfahren ist als CDMA- (Code Division Multiple Access) Ver- fahren bekannt. Gemäß der technischen Spezifikation TS 25.211 V3.7. 0 :"Physical Channels and Mapping of Transport Channels

onto Physical Channels"des 3rd Generation Partnership Pro- ject (3GGP), welche den UMTS-FDD-Modus beschreibt, ist ein physikalischer Kanal, das heißt ein Funkkanal, in der Down- link-Richtung durch Trägerfrequenz, einem Verschlüsselungs- Code (dem sogenannte"Scrambling Code"), einem Kanalisie- rungscode (dem sogenannten"Channelization Code") und einer Start-und Stopzeit definiert. Für die Uplink-Übertragung hat jede Mobilfunkstation ihren eigenen Scrambling Code. Der Sinn der Scrambling Codes liegt darin, die verschiedenen Mobil- funkstationen trennen zu können.

In UMTS gibt es für die Übertragung von Informationen zwei Arten von Funkkanälen : Dedizierte Kanäle, sogenannte"Dedica- ted Channels", und gemeinsame Kanäle, sogenannte Common Channels". Bei den dedizierten Kanälen wird eine physikali- sche Ressource nur für die Übertragung von Informationen für ein bestimmtes Teilnehmergerät, in UMTS"User Equipment" (UE) genannt, reserviert. Bei den gemeinsamen Kanälen können In- formationen übertragen werden, die für alle Teilnehmer ge- dacht sind oder nur für einen bestimmten Teilnehmer. Im letz- teren Fall muss auf den gemeinsamen Kanal noch mit übertragen werden, für welchen Teilnehmer die Information gedacht ist.

Figur 1 zeigt die bekannte Architektur des UMTS-Netzwerks UTRAN (Universal Terrestrial Radio Access Networks) mit einem Kern-Netzwerk CN, einer Funk-Netzwerk-Kontrolleinrichtung RNC (Radio Netwotk Controler), Basisstationen Node B1 und Node B2 und einer Mobilstation UE. Nachfolgend steht ein angefügtes "s"an eine definierte Einheit für die Mehrzahl der Einhei- ten.

Figur 2 zeigt eine UMTS Protokoll Architektur. Die darin dar- gestellten Schichten 2 und 3 sind sowohl einmal im UE als auch einmal im RNC enthalten. Der Buchstabe"L"gefolgt von einer Zahl entspricht einer Schicht, beispielsweise L2 ist die Schicht 2. Des Weiteren bedeutet"c"Steuerung. Die in Figur 2 dargestellten Protokoll-Schichten sind

- die Funkmittel-Steuerungsschicht RRC (Radio Resource Control-Schicht, d. h. untere Schicht 3, die in der techni- schen Spezifikation TS 25. 331"Radio Resource Control", des 3rd Generation Partnership Projects (3GPP), März 2001, beschrieben ist ; - die Packetdaten-Konvergenz-Protokollschicht PDCP (Packet Data Convergence Protokoll-Schicht, d. h. die obere Schicht 2, die in der technischen Spezifikation TS 25. 321"Packet Data Convergence Protocol", des 3rd Generation Partnership Projects (3GPP), März 2001, beschrieben ist ; - die Übertragungs/Mehrfachübertragungs-Steurungsschicht BMC (Broadcast/Multicast Control-Schicht, d. h. die obere Schicht 2, die in der technischen Spezifikation TS 25.324 "Broadcast/Multicast Control", des 3rd Generation Part- nership Projects (3GPP), März 2001, beschrieben ist ; - die Funksterecken-Steuerungsschicht RLC (Radio Link Control-Schicht, d. h. mittlere Schicht 2, die in der tech- nischen Spezifikation TS 25. 322"Radio Link Control", des 3rd Generation Partnership Projects (3GPP), März 2001, be- schrieben ist ; - die Mediumzugriff-Steuerungsschicht MAC (Medium Access Control-Schicht), d. h. untere Schicht 2, die in der tech- nischen Spezifikation TS 25. 321"Medium Access Control", des 3rd Generation Partnership Projects (3GPP), März 2001, beschrieben ist ; und - die physikalische Schicht PHY, d. h. Schicht 1, die in der technischen Spezifikation TS 25. 302"Services Provided by Physical Layer", des 3rd Generation Partnership Projects (3GPP), März 2001, beschrieben ist ; Im Allgemeinen tauscht ein Protokoll im Sender (RNC oder UE) Protokoll-Dateneinheiten PDUs (Protocol Data Units) mit dem gleichgestellten Protokoll im Empfänger (UE oder RNC) aus, indem es die Dienste der unter ihr liegenden Protokoll- Schicht für den Transport der PDUs benutzt. Jede Protokoll- Schicht bietet dazu der über ihr liegenden Schicht ihre

Dienste an sogenannten Dienstzugangspunkten an, die zum bes- seren Verständnis der Protokoll Architektur mit allgemein ge- bräuchlichen und eindeutigen Namen versehen sind. Wie Figur 2 zu entnehmen ist, bezeichnet man die Dienstzugangspunkte o- berhalb der Protokolle PDCP, BMC und RLC als Funkstützen RB, sogenannte"Radio Bearer", die Dienstzugangspunkte zwischen den Protokollen RRC und RLC als signalisiserende Funkstützen SRB, sogenannte"Signalling Radio Bearer", die Dienstzugangs- punkte zwischen den Protokollen RLC und MAC als logische Ka- näle LogCH, sogenannte"Logical Channels", und die Dienstzu- gangspunkte zwischen dem MAC Protokoll, das das unterste Pro- tokoll der Schicht 2 darstellt, und der Physikalischen Schicht (Schicht 1) als Transportkanäle TrCH, sogenannte "Transport Channels". Die Kanäle, die für die eigentliche bertragung der Daten über die Luftschnittstelle benutzt wer- den bezeichnet man als physikalische Kanäle PhyCH. Alle phy- sikalischen Kanäle einer Übertragungsrichtung werden bei UMTS im Allgemeinen gleichzeitig über ein gemeinsames Frequenzband übertragen. Um die einzelnen physikalischen Kanäle, die sich bei der Übertragung über die Luftschnittstelle überlagern, im Empfänger wieder von einander trennen zu können, findet beim UMTS das Vielfachzugriffsverfahren CDMA Anwendung, bei dem die zu übertragenen Daten mit sogenannten Spreizkodes modu- liert werden. Daher ist ein Parameter, durch den ein physika- lischer Kanal unter anderem beschrieben wird, der Spreizkode mit dem dessen Daten gespreizt bzw. moduliert werden. Dieser Parameter ist unabhängig von den beiden im UMTS spezifizier- ten Duplexmodi FDD und TDD vorhanden. Dabei beschreibt der Duplexmode, wie die beiden Übertragungsrichtungen Downlink (DL, RNC-tUE) und Uplink (UL, UE-). RNC) einer Mobilfunkverbin- dung von einander getrennt werden. Im FDD-Modus werden DL und UL auf unterschiedlichen Frequenzbändern im allgemeinen zeit- gleich übertragen, wogegen im TDD Modus DL und UL zwar über dem selben Frequenzband übertragen werden, die Übertragung jedoch zu unterschiedlichen Zeitpunkten stattfindet.

Die weiteren Ausführungen und Erklärungen sind nur für den UMTS-FDD-Modus gültig. Im folgenden werden die Aufgaben bzw.

Funktionen des für das Verständnis der vorliegenden Erfindung notwendigen RRC-Protokolls, MAC-Protokolls und der Physikali- schen Schicht erläutert.

Nachfolgend wird das RRC-Protokoll erläutert. Für den Auf-, Abbau und die Umkonfiguration von PhyCHs, TrCHs, LogCHs und RBs und das Aushandeln aller Parameter der Schicht 2 Proto- kolle sowie der physikalischen Schicht ist das RRC-Protokoll verantwortlich. Dieses Protokoll ist sowohl im UE als auch im RNC vorhanden und es nutzt die Übertragungsdienste, die das RLC-Protokoll zur Verfügung stellt, also die SRBs, um RRC- Konfigurationsnachrichten zu versenden. Dabei gibt es im All- gemeinen beim Austausch von Konfigurationsnachrichten eine konfigurierende Einheit und eine konfigurierte Einheit, wobei im UMTS das RRC Protokoll des RNC grundsätzlich die konfigu- rierende Einheit und das RRC Protokoll des UE die konfigu- rierte Einheit ist. Die konfigurierte Einheit (UE) kann dabei den Empfang einer Konfigurationsnachricht von der konfigurie- renden Einheit (RNC) durch das Senden einer Empfangsbestäti- gung quittieren. Somit handeln die RRC Protokolle die für den Aufbau einer Verbindung benötigten Konfigurationsparameter aus, anhand derer jedes einzelne RRC Protokoll wiederum die Konfiguration der unter ihm liegenden Protokolle der Schicht 2 sowie die Konfiguration der Schicht 1 vornimmt. Die Konfi- gurationsnachrichten, die vom RRC Protokoll des RNC gesendet werden, können dabei im allgemeinen in zwei Arten aufgeteilt werden. Zum einen gibt es Konfigurationsparameter, die für mehrere UEs im Wert und der Bedeutung gleich sind, und zum anderen gibt es Konfigurationsparameter, die nur für ein ein- zelnes UE Gültigkeit haben. Daher sendet das RRC Protokoll des RNC Konfigurationsparameter, die für mehrere UEs glei- chermaßen gültig sind, auf logischen Kanälen, die von mehre- ren UEs gemeinsam empfangen werden können, sogenannte"Common LogCHs", und Konfigurationsparameter, die nur für ein UE gül- tig sind, auf LogCHs die nur von einem bestimmten UE empfan-

gen werden können, sogenannte"Dedicated LogCHs". Beispiels- weise werden allgemein gültige Konfigurationsparameter über einen Sendungs-Steuerungskanal BCCH (Broadcast Control Chan- nel) und UE spezifische Konfigurationsparameter über einen dedizierten Steuerungskanal DCCH (Dedicated Control Channel) gesendet.

Nachfolgend wird das MAC-Protokoll erläutert. Die Aufgabe des MAC Protokolls im Sender ist, die Daten, die an einem LogCH oberhalb des MAC Protokolls anliegen, auf die Transportkanäle der physikalischen Schicht abzubilden, bzw. im Empfänger auf Transportkanälen empfangene Daten auf logische Kanäle zu ver- teilen. Jeder Transportkanal ist dazu mit einem Satz von fes- ten Parametern für die Übertragung der Daten vorkonfiguriert.

Aus einem weiterer Satz von variablen Parametern kann das MAC Protokoll die jeweils für die aktuelle Übertragung günstigs- ten aussuchen und so die Datenübertragung dynamisch beein- flussen. Eine gültige Einstellung aller Parameter für einen Transportkanal wird dabei Transport-Format TF genannt. Die Menge aller möglichen Einstellungen für einen Transportkanal heißt Transport-Format-Satz TFS (Transport Format Set). In einem TFS sind die einzelnen TF durch einen Indikator gekenn- zeichnet. Dieser Indikator wird als Transport-Format- Indikator TFI bezeichnet. Nur die variablen (dynamischen) Pa- rameter des TF variieren innerhalb eines TFS. Zu einem be- stimmten Zeitpunkt ist für jeden Transportkanal nur ein Transport Format eingestellt. Die Menge der zu einem bestimm- ten Zeitpunkt für alle vorhandenen Transportkanäle einge- stellten Transport-Formate heißt Transport-Format-Kombination TFC. Aus den für jeden Transportkanal gültigen Transport- Formaten ergibt sich eine große Vielzahl von möglichen Kombi- nationen für alle Transportkanäle und theoretisch könnte jede dieser Kombinationen eine TFC ergeben. Praktisch ist die An- zahl der tatsächlich gleichzeitig erlaubten Kombinationen von Transport Formaten aber eingeschränkt. Die Menge aller er- laubten TFCs wird Transport-Format-Kombinationssatz TFCS (Transport Format Combination Set) genannt. In einem TFCS

sind wiederum die einzelnen TFCs durch einen Indikator ge- kennzeichnet, der als Transport-Format-Kombinationsindikator TFCI (Transport Format Combination Indicator) bezeichnet wird.

Wie oben beschrieben, besteht ein TF aus statischen Parame- tern, die nicht durch das MAC-Protokoll beeinflusst werden können, sondern nur durch das RRC-Protokoll ausgehandelt wer- den, und dynamischen Parametern, von denen ein Satz von ver- schiedenen Einstellungen vom RRC Protokoll ausgehandelt wird und die vom MAC Protokoll beeinflusst werden können. Zu den statischen Parametern gehören : - die Länge des Übertragungsintervalls TTI (Transmission Time Interval), d. h. das Zeitintervall, für das die physi- kalische Schicht Daten zusammenhängend verarbeitet. Dieses kann 10,20, 40 oder 80 Millisekunden lang sein.

- das Kodierungsschema zum Fehlerschutz - die Länge der Redundanzinformationen zum Fehlerschutz CRC (Cyclic Redundancy Check) Die dynamischen Parameter sind : - RLC-Größe (RLC-Size) : Da das MAC Protokoll weder MAC-PDUs generiert, noch die von RLC empfangenen RLC-PDUs segmen- tiert oder aneinander hängt, korrespondiert eine MAC-PDU solange mit genau einer RLC-PDU, wie das MAC Protokoll der RLC-PDU keinen Kontrolldatenkopf, einen sogenannten MAC- header, voranstellt. Stellt das MAC Protokoll den RLC-PDUs einen Kontrolldatenkopf voran, so ist die MAC-PDU um die Länge des MAC-headers größer als die RLC-PDU. Mit diesem Parameter wird also sowohl die Größe der RLC-PDU als auch die Größe der MAC-PDU eingestellt. Der auf dem Transport- kanal an die physikalische Schicht übergebene Datenblock, die MAC-PDU, wird auch Transport-Block genannt.

- Anzahl der Transport-Blöcke (Number of Transport Blocks) : Dieser Parameter bestimmt die Anzahl der MAC-PDUs, die während eines TTIs an die physikalische Schicht zur gleichzeitigen Verarbeitung und den Transfer über die Luftschnittstelle übergeben werden dürfen.

Wie man erkennt, ergibt sich aus den Parametern TTI, RLC- Größe und Anzahl der Transport-Blöcke die augenblickliche Da- tenrate des Transportkanals, die von dem MAC Protokoll dyna- misch durch Auswahl der verschiedenen Transport-Formate, also durch Variation des TTI, der RLC-Größe und Anzahl der Trans- port-Blöcke eingestellt werden kann.

Über die dynamische Auswahl einer TFC für jedes Übertragungs- intervall (TTI) hinaus hat das MAC Protokoll, wie eingangs schon erwähnt, die Aufgabe, die auf den verschiedenen RBs an- kommenden Daten unter Berücksichtigung des für die RB einge- stellten Dienstleistungsqualität QoS (Quality of Service) auf die Transportkanäle zu verteilen. Der Qos eines RB beschreibt dessen Übertragungsdienstqualität, die während der Dauer der Mobilfunkverbindung durch die Protokolle der Schicht 2 sowie der physikalischen Schicht gewährleistet werden soll. Der QoS zeichnet sich dabei beispielsweise durch eine bestimmte ga- rantierte Datenrate und/oder eine maximale Übertragungsverzö- gerung aus. Das RRC-Protokoll handelt dazu beim Aufbau und der Rekonfiguration von RBs z. B. aus, welche logischen Kanäle auf welche Transportkanäle abzubilden sind, wobei jedem Transportkanal mehrere logische Kanäle zugeordnet werden kön- nen.

In Figur 3 ist die auf den UMTS-FDD-Modus reduzierte Archi- tektur des MAC-Protokolls im RNC dargestellt, wobei für jedes UE, das von einem RNC versorgt wird, eine separate dedizierte MAC-Einheit MAC-d (MAC-dedicated) vorhanden ist. In Figur 3 haben bereits beschriebene Abkürzungen die gleiche Bedeutung.

Über die MAC-d Einheit werden ausschließlich UE-spezifische Nutz-und Kontrolldaten, die über die entsprechenden Logi- schen Kanäle, den dedizierten Verkehrskanal DCCH (Dedicated Traffic Channel) und den dedizierten Steuerungskanal DTCH (Dedicated Control Channel) zur MAC-d Einheit gelangen, in DL-Richtung gesendet und in UL-Richtung empfangen werden. Da- bei ist für jede Übertragungsrichtung mindestens ein separa-

ter Transportkanal, ein sogenannter dedizierten Transportka- nal DCH (Dedicated Channel), vorhanden. Ein solcher DCH wird von der physikalischen Schicht auf einen oder mehrere dedi- zierte physikalische Kanäle DPCH (Dedicated Physical Channel) abgebildet und über die Luftschnittstelle übertragen. Über die in Figur 3 dargestellte MAC-Steurungs/Verteilt-Einheit MAC-c/sh (MAC-control/shared) werden hingegen im allgemeinen Nutz-und Kontrolldaten übertragen die nicht UE spezifisch sind. Diese Daten gelangen über die logischen Kanäle Gemein- same Verkehrssteuerung CTCH (Common Traffic Channel) und Ge- meinsamer Steuerungskanal CCCH (Common Control Channel) zur MAC-c/sh Einheit. Der CTCH ist nur in DL-Richtung existent und wird über den Transportkanal FACH (Forward Access Chan- nel) zur physikalischen Schicht übertragen. Der CCCH hingegen ist sowohl in DL-als auch im UL-Richtung existent und wird daher im DL von dem FACH und im UL von einem Direktzugriffs- kanal RACH (Random Access Channel) getragen. Des weiteren können über die MAC-c/sh Einheit auch Systeminformationen transportiert werden, die für alle UEs gleich sind. Die Sys- teminformationen erreichen die MAC-c/sh Einheit über den Lo- gischen Kanal BCCH (Broadcast Control Channel). Der BCCH ist ein Rundfunksteuerungskanal und nur in DL-Richtung existent und kann im Allgemeinen auf zwei unterschiedliche Transport- kanäle abgebildet werden. Zum einen kann der BCCH ebenfalls vom FACH getragen werden, zum anderen kann er durch eine wei- tere MAC Einheit, die in Figur 3 nicht dargestellt ist und als MAC-Übertragungseinheit MAC-b (MAC-broadcast) bezeichnet wird, auf den Transportkanal BCH (Broadcast Channel) abgebil- det werden.

Die MAC-c/sh Einheit ist auch fähig, UE-spezifische Nutz-und Kontrolldaten zu senden bzw. zu empfangen. Dies ist zum einen der Fall, wenn ein UE z. Zt. keinen dedizierten Transportkanal DCH aufgebaut hat, aber dennoch geringere Mengen an UE- spezifische Daten empfangen oder senden möchte. Aus Sicht des RNC werden in solch einem Fall im DL die Daten von der MAC-d Einheit zur MAC-c/sh Einheit geleitet, woraufhin diese Ein-

heit die Daten über den FACH an die Physikalische Schicht ü- bergibt. In UL-Richtung werden in solch einem Fall die Daten auf dem RACH empfangen, um dann vom MAC-c/sh zum MAC-d weiter geleitet zu werden.

Zum anderen kann ein UE zwar ein DCH aufgebaut haben, wobei jedoch dessen Kapazität zwischenzeitlich zu gering ist, um eine gewisse Datenmenge in einem bestimmten Übertragungsin- tervall zu übertragen. Diese Situation kann beispielsweise bei einem Datenstrom vorliegen, der in seinem zeitlichen Ver- lauf Spitzen, sogenannte Peaks", in der Datenmenge aufweist und den man im allgemeinen als Datenstrom BDS (Bursty Data Stream) bezeichnet. Um dem UE zu ermöglichen, die geforderte Menge an Daten in einem bestimmten Übertragungsintervall zu empfangen, werden ihm daher für den entsprechende Zeitraum zusätzliche Kapazitäten zur Verfügung gestellt. Die zusätzli- chen Kapazitäten bestehen in einem sogenannten verteilten Ka- nal bei einer Übertragung in Downlink-Richtung DSCH (Downlink Shared Channel). Es handelt sich dabei um einen Transportka- nal, der nur in DL-Richtung existent ist und den sich mehrere UEs gemeinsam teilen, um über diesen dedizierte Daten zu emp- fangen. Dabei ist der DSCH zu einem bestimmten Zeitpunkt und für eine bestimmte Dauer immer'nur maximal einem UE zugewie- sen. Zu einem anderen Zeitpunkt hingegen ist es ohne weiteres möglich, dass die selben DSCH Ressourcen einem anderen UE zu- geteilt sind. Der DSCH wird dabei von der physikalischen Schicht auf einen oder mehrere physikalische verteilte Kanäle bei einer Übertragung in Downlink-Richtung PDSCH (Physical Downlink Shared Channel) abgebildet, welche unter anderem wieder durch spezifische Spreizkodes gekennzeichnet sind.

Die Funktion des MAC-Protokolls lässt sich nun zusammenfas- send wie folgt beschreiben : Das sendende MAC-Protokoll sucht sich für jedes TTI und für jeden TrCH ein Transport Format aus (also insgesamt eine TFC) und bestimmt von welchen LogCHs Daten in dem betrachteten TTI übertragen werden. Dann teilt das MAC-Protokoll den entsprechenden RLC-Einheiten die zum

jeweiligen TF gehörende RLC-PDU-Größe und die Anzahl der er- warteten RLC-PDUs mit. Die RLC-Protokolle übergeben daraufhin die entsprechende Anzahl an RLC-PDUs auf dem entsprechenden logischen Kanal an das MAC-Protokoll. Dieses fügt den Daten ggf. ein MAC-Kopffeld hinzu und übergibt die gesamten MAC- PDUs für einen Transportkanal gleichzeitig an die physikali- sche Schicht. Dabei übergibt das MAC-Protokoll der physikali- schen Schicht zusätzlich das für das TTI aktuelle TFI eines jeden Transportkanals.

Nachfolgend wird die Physikalische Schicht beschrieben : Die Physikalische Schicht hat die Aufgabe, die vom MAC Protokoll über die Transportkanäle erhaltenen Daten innerhalb der ent- sprechenden TTIs der Transportkanäle über die Luftschnitt- stelle zu senden. Dazu bestimmt die Physikalische Schicht an- hand der vom MAC Protokoll übermittelten TFIs der einzelnen TrCHs unter anderem die Länge der Redundanzinformationen zum Fehlerschutz (CRC), das Kanalkodierungsverfahren, die Kode- rate sowie die Dauer des TTI in dem die Daten eines TrCH über die Luftschnittstelle transportiert werden sollen. Mit diesen Informationen berechnet die physikalische Schicht für jeden Transport Block eines TrCH, der in dem entsprechenden TTI ü- bertragen werden soll, die CRC-Summe und hängt diese den Da- ten an. Alle Transport Blöcke eines TTI eines TrCH werden daraufhin gemeinsam kanalkodiert, um sie vor Übertragungsfeh- ler, die durch den Übertragungskanal verursacht werden kön- nen, zu schützen. Nach dem alle Daten eines Transportkanals noch durch weitere Maßnahmen, die in der technischen Spezifi- kation TS 25. 212"Multiplexing and channel coding (FDD)"des 3rd Generation Partnership Projects (3GPP), März 2001, näher beschrieben sind, für die Übertragung über die Luftschnitt- stelle vorbereitet wurden, werden die Daten aller Transport- kanäle auf einen internen Kanal in der physikalischen Schicht gemultiplext. Dieser Kanal wird als Zusammengesetzter- Codierter-Transportkanal CCTrCH (Coded Composit Transport Channel) bezeichnet. Dabei werden im Allgemeinen alle dedi- zierten Transportkanäle (DCHs) eines UE auf einen CCTrCH und

alle DSCHs eines UE auf einen weiteren separaten CCTrCH abge- bildet. Von einem CCTrCH werden die zu sendenden Daten dann wiederum auf die entsprechenden physikalischen Kanäle abge- bildet, die für die Übertragung der Daten über die Luft- schnittstelle verantwortlich sind. Dabei werden die Daten des CCTrCH, der die dedizierten Transportkanäle (DCHs) eines UE trägt, auf DPCHs abgebildet und die Daten des CCTrCH, der die DSCHs eines UE trägt, auf PDSCHs abgebildet. Vor dem Senden der Daten über die Luftschnittstelle werden diese dann noch moduliert und mit dem für den entsprechenden DPCH bzw. PDSCH spezifischen Spreizkode kodiert, d. h. gespreizt.

Um der physikalischen Schicht im Empfänger dabei die Möglich- keit zu geben, die über die verschiedenen DPCHs bzw. PDSCHs empfangenen Daten wieder richtig zu dekodieren, d. h. die für die Anpassung der Daten an die Luftschnittstelle vorgenomme- nen Maßnahmen (Spreizung, Modulation, Multiplexen, Kanalko- dierung, usw. ) wieder rückgängig machen, sowie dem MAC- Protokoll im UE die Möglichkeit zu geben, die über die Trans- portkanäle empfangenen Daten fehlerfrei auf die logischen Ka- näle zu demultiplexen, ermittelt die physikalische Schicht des Senders aus den TFIs der Transport Kanäle die für das ak- tuelle TTI gültige TFC und daraus wiederum den zugehörigen TFCI. Ein solcher TFCI hat im allgemeinen eine Länge von 10 Bit und wird zusammen mit den Daten des CCTrCH, der die dedi- zierten Transportkanäle trägt, über einen DPCH zum UE über- tragen. Das UE kann somit anhand des empfangenen TFCI die senderseitig an den Daten vorgenommenen Maßnahmen rückgängig machen und so die Daten im allgemeinen fehlerfrei dekodieren.

Dabei ist der TFCI im Allgemeinen für jeden CCTrCH spezi- fisch, d. h. ein UE, das zwei CCTrCH konfiguriert bekommen hat (einen für DCHs und einen für DSCHs), müssen zwei unter- schiedliche TFCIs mitgeteilt werden. Um Übertragungskapazitä- ten zu sparen wird zu einem UE jedoch zumeist nur ein einzi- ger 10 Bit Langer TFCI gesendet.

Wie vorstehend beschrieben wurde, dient ein DSCH, der von der physikalischen Schicht im Sender auf einen separaten CCTrCH und von diesem auf einen oder mehrere PDSCHs abgebildet wird, im Allgemeinen zum Abbau von Datenspitzen, die beispielsweise bei sogenannten"Bursty Data Streams" (BDS) vorkommen. Die Charakteristik eines solchen BDS beinhaltet dabei, dass die Datenpeaks generell unregelmäßig und plötzlich vorhanden sind. Somit muss der Sender (RNC) die Möglichkeit haben, dem UE die zusätzlichen Kapazitäten, die zur Übertragung der Da- tenpeaks benötigt werden und die in Form der PDSCHs vorhanden sind, schnell und unkompliziert bekannt zu machen. Aus diesem Grund ist eine explizite Signalisierung der zusätzlichen Res- sourcen nicht sinnvoll, da sie zuviel Zeit in Anspruch nehmen würde. Es müsste nämlich zunächst eine Konfigurationsnach- richt vom RRC im RNC zum RRC im UE über die Luftschnittstelle gesendet werden, um mit den in der Nachricht enthaltenden Pa- rametern die physikalische Schicht und das MAC-Protokoll des UE zu konfigurieren. Daher werden dem UE die zusätzlichen Ka- pazitäten durch den RNC implizit mitgeteilt. Dazu wird der zuvor bereits erwähnte 10 Bit lange TFCI genutzt.

Bei der Konfiguration eines RB, dessen Datenfluss die Charak- teristik eines BDS aufweist, ist der konfigurierenden Einheit (RNC) bewusst, dass in DL-Richtung von Zeit zu Zeit zusätzli- che Kapazitäten in Form eines oder mehrerer PDSCHs benötigt werden, um in einem bestimmten Zeitrahmen, einem sogenannten "Frame", eine geforderte Menge an Daten zum UE zu übertragen.

Das hat zur Folge, dass im DL für das UE ein DSCH konfigu- riert wird. D. h., dem UE werden die erforderlichen Parameter, die zum Empfang eines DSCH benötigt werden, mitgeteilt. Dazu gehört unter anderem das TFS des DSCH, das TFCS des zum DSCH gehörenden CCTrCH und die spezifischen Spreizkodes der PDSCHs, auf die ein oder mehrerer DSCH abgebildet werden. Die RRC (Re-) Konfigurationsnachricht, die die zuvor beschriebenen Parameter einem UE bekannt macht, kann in verschiedenen For- men beispielsweise als Funkstütze-Aufbau, das sogenannte "RADIO BEARER SETUP", als Funkstütze-Rekonfiguration, das so-

genannte"RADIO BEARER RECONFIGURATION"oder als Transportka- nal-Rekonfiguration, das sogenannte"TRANSPORT CHANNEL RECONFIGURATION"vorliegen. Schematisch ist in Figur 4 die in der technischen Spezifikation TS 25. 331"Radio Resource Control", des 3rd Generation Partnership Projects (3GPP), März 2001, beschriebene RADIO BEARER SETUP"-Nachricht darge- stellt. Diese Nachricht kann die für den Aufbau mehrerer RB benötigten Informationen enthalten und somit auch die Infor- mationen für den Aufbau mehrerer DSCHs. Figur 4 sowie die Fi- guren 5 und 6 zeigen dabei auf, an welcher Stelle in der"RB SETUP"-Nachricht die zuvor erwähnten Parameter durch soge- nannte Informationselemente (IEs) einem UE mitgeteilt werden.

Schon definierte Ausdrücke haben dabei wieder die gleiche Be- deutung. Ein nachgestelltes"IE"bedeutet nachfolgend, dass es sich bei den bereits erläuterten Abkürzungen jeweils um ein Informationselement handelt. MS bedeutet Typ der Nach- richt.

Das TFS eines jeden DSCHs wird einem UE explizit durch das IE "TFS" (Transport Format Set) signalisiert. Im Allgemeinen ist dieses IE in der"RB SETUP"-Nachricht für jeden Transportka- nal der aufgebaut werden soll einmal enthalten, unabhängig davon ob es sich dabei um einen DCH oder einen DSCH handelt.

Mit dem"TFS"bekommt das UE für jedes TF im TFS des entspre- chenden Transportkanals die dynamischen Parameter (RLC-Größe, Anzahl der Transport-Blöcke) sowie einmalig die für das TFS konstanten semi-statischen Parameter übermittelt. Wie Figur 4 zu entnehmen ist, wird das IE"TFS"in dem IE"Add/Reconf. DL TrCH info#1, 2" (#22 in Figur 4) übertragen. In diesem ist au- ßer dem IE"TFS" (#23 in Figur 4) noch ein weiterer wichtiger Parameter enthalten, der als"DCH Qualitätsziel"bezeichnet wird. Anhand dieses Parameters legt das UE den Referenzwert des Signal-Störabstandes SIR (Signal-to-Interference Ratio) für die für einen Transportkanal benötigten DPCHs bzw. PDSCHs fest. Wird dieser Wert beispielsweise in DL-Richtung unter- oder überschritten, signalisiert das UE dem Sender, dass die- ser die Sendeleistung im nächsten Zeitrahmen erhöhen oder

verringern soll. Somit ist der Parameter"DCH Qualitätsziel" für die Leistungsregelung der den DSCHs zugehörigen PDSCH er- forderlich.

Das TFCS des CCTrCH, auf den ein oder mehrere DSCHs von der physikalischen Schicht im Sender abgebildet werden, um dann auf die verschiedenen PDSCHs verteilt zu werden, bekommt das UE durch das IE TFCS" (Transport Format Kombination Set) mitgeteilt, welches im IE, Gemeinsame Transportkanalinforma- tion für alle Transportkanäle'DLTrCHIcfaTrCH (DL Transport channel information common for all transport channels) ent- halten ist.

Wie man Figur 5 entnehmen kann, werden im IE"TFCS"einem UE zunächst Informationen über die Konfiguration des zuvor schon erwähnten TFCI mitgeteilt, welcher während der Übertragung in jeden Rahmen zusammen mit den Daten auf einen DPCH zum UE ge- sendet wird. Erfordert z. B. keiner der für ein UE aufzubauen- den RB einen DSCH, wird der TFCI durch das IE"TFCS"als "Normal"konfiguriert. D. h., alle 10 Bits des TFCI beschrei- ben für jeden Rahmen ausschließlich die TFC des CCTrCH, der die dedizierten Kanäle (DCHs) eines UE trägt. Erfordert hin- gegen nur einer der für ein UE auEzubauenden RB einen DSCH wird dem TFCI ein sogenannter"Split"konfiguriert, d. h. der TFCI besteht in diesem Fall aus zwei Feldern. Man spricht in diesem Zusammenhang von TFCI Feld 1 und TFCI Feld 2. Dabei wird die Länge des zweiten Feldes explizit in dem IE mitge- teilt (Länge des TFCI (Feld 2)), woraus sich die Länge des ersten Feldes implizit ergibt. Während der Übertragung von Daten beinhaltet das TFCI Feld 1 dabei den TFCI des CCTrCH, der die dedizierten Transportkanäle des UE trägt, und das TFCI Feld 2 beinhaltet den TFCI des CCTrCH auf den die DSCHs eines UE abgebildet werden. Die eigentlichen TFCSs der ent- sprechenden CCTrCHs werden dem UE durch die IE"TFCI Feld 1 Info"und nTFCI Feld 2 Info"bekannt gemacht. In dem IE"TFCI Feld 2 Info"ist unter anderem wiederum das IE"TFCS explizi- te Konfiguration"enthalten, welches jedem Wert des TFCI Feld

2 eine TFC des TFCS zuordnet. Auf diesem Weg wird einem UE somit das TFCS des CCTrCH bekannt gemacht, der die DSCHs des entsprechenden UE trägt (#24 in Figur 5). Wann die physikali- sche Schicht des UE nun einen oder mehrere PDSCHs zu empfan- gen hat, um über diese zusätzliche Daten auf einem oder meh- reren DSCHs zu erhalten, wird dem UE also durch den Empfang des insgesamt 10 Bit langen TFCI signalisiert. Diese Signali- sierung findet dabei im Allgemeinen immer ein Zeitrahmen im Voraus statt, d. h. einen Zeitrahmen vor dem entsprechenden Zeitrahmen in dem das UE zusätzliche Daten auf einen oder mehreren DSCHs empfangen soll. Korrespondiert der Wert eines empfangenen TFCI Feld 2 nun mit einer TFC, die dem UE an- zeigt, dass das MAC-Protokoll im Sender (RNC) für den nächs- ten Zeitrahmen auf keinen der für das UE konfigurierten DSCHs Daten abbildet, so ist dem UE bekannt, dass es im nächsten Zeitrahmen keine Daten auf einem PDSCH zu empfangen hat. Sig- nalisiert der Wert des TFCI Feld 2 einem UE hingegen, das das MAC-Protokoll im Sender (RNC) im nächsten Zeitrahmen Daten auf einen der für das UE konfigurierten DSCHs abbildet, ist dem UE bekannt, das es im nächsten Zeitrahmen zusätzliche Da- ten auf einen oder mehreren PDSCHs zu empfangen hat. Damit das UE nun weiß auf welchen und wie vielen PDSCHs es zusätz- liche Daten empfangen soll, ist mit dem Wert des TFCI Feld 2 nicht nur die aktuelle TFC des entsprechenden CCTrCH verbun- den, sondern zusätzlich noch die Information über die Spreiz- kodes der PDSCHs, auf denen die zusätzlichen Daten vom Sender zum UE gesendet werden. D. h., mit jedem Wert des TFCI Feld 2 sind außer einer TFC für den entsprechenden CCTrCH noch die entsprechenden Spreizkodes der PDSCHs verbunden, die die Da- ten eines oder mehrerer DSCHs übertragen. Die Zuordnung von den Spreizkodes der benötigten PDSCHs zu den Werten des TFCI Feld 2 wird dem UE dabei ebenfalls durch die"RB SETUP"- Nachricht bekannt gemacht. In dieser Nachricht sind unter den "PhyCH"die IEs enthalten, die einem UE die zum Empfang der physikalischen Ressourcen benötigten Parameter mitteilen. Die zum Empfang eines bzw. mehrerer PDSCHs benötigten Parameter werden einem UE beispielsweise durch das IE"PDSCH DL Infor-

mation"signalisiert, das unter anderem wiederum das IE "PDSCH Code Mapping"enthält (#25 in Figur 6). In dem zu- letzt genannten IE ist dabei die Zuordnung von einem oder mehreren Spreizkodes (entsprechend einem oder mehreren PDSCHs) zu den Werten des TFCI Feld 2 enthalten.

Wird ein UE nun auf die zuvor beschriebene Weise konfigu- riert, kann es für jeden Zeitrahmen ermitteln, ob es im dar- auf folgenden Zeitrahmen von der Sendeeinheit (RNC) zusätzli- che Ressourcen in Form von PDSCHs zugeteilt bekommen hat, wie viele zusätzliche Ressourcen es bekommen hat und mit welchen Spreizkode die entsprechenden Ressourcen (PDSCHs) kodiert wurden. Dabei wird betont, dass sowohl die hier beschriebene Konfigurationsnachricht"RADIO BEARER SETUP"als auch die Konfigurationsnachrichten"RADIO BEARER RECONFIGURATION"und "TRANSPORT CHANNEL RECONFIGURATION"im allgemeinen über einen dedizierten logischen Kontrollkanal (DCCH) vom RRC im RNC zum RRC im UE gesendet werden. Somit sind die durch die Konfigu- rationsnachrichten für den Empfang von DSCHs und den zugehö- rigen PDSCHs vorgenommenen Einstellungen nur dem entsprechen- den UE bekannt. Dies ist sinnvoll, da die Ressource eines DSCHs zu einem bestimmten Zeitpunkt auch immer nur einem UE zugeordnet bzw. zugeteilt werden kann. Für verschiedenen An- wendungen ist es dabei aber denkbar, dass die auf einen oder mehreren DSCHs gesendeten Daten von mehreren UEs gleichzeitig empfangen werden sollen. Dies setzt dann natürlich voraus, dass die Konfiguration der DSCHs für alle UEs gleich sein muss. Dafür muss nach dem Stand der Technik zu jedem UE, das die Daten auf den entsprechenden DSCHs empfangen soll, eine separate Konfigurationsnachricht über einen DCCH vom RRC im RNC zum RRC im UE gesendet werden. Dies reduziert jedoch die freien Übertragungskapazitäten der Luftschnittstelle in unnö- tiger Weise. Der PDSCH ist ein reiner Datenkanal, d. h. über ihn werden keinerlei Signalisierungsdaten vom Sender (physi- kalische Schicht in der Node B) zum UE gesendet. Daher kann der PDSCH im UMTS-FDD-Modus auch immer nur in Verbindung mit einem DPCH in DL-Richtung und einem DPCH in UL-Richtung exis-

tieren. Dies ist nicht nur darin begründet, dass ein UE den TFCI des CCTrCH, der die DSCHs des UE trägt, über einen DPCH mitgeteilt bekommt, sondern es ist auch darin begründet, dass die gesamte Leistungsregelung der für ein UE konfigurierten PDSCHs über die DPCHs durchgeführt wird. Zur Leistungsrege- lung sendet der Sender (Node B) im Sendeleistungs- Steuerungskanal bei einer Übertragung in Downlink-Richtung DL-TPC (Transmit Power Control) Bits zusammen mit den TFCI Bits über den DPCH zum UE. Diese TPC Bits signalisieren dem UE, ob es die Sendeleistung im UL erhöhen oder verringern soll. Auf dem DPCH des UL sendet das UE dementsprechend TPC Bits, die der NodeB signalisieren, das sie die Sendeleistung im DL zu erhöhen oder zu verringern hat. Abhängig von diesen TPC Bits erhöht bzw. verringert die NodeB die Sendeleistung der DPCHs sowie der PDSCHs. Somit kann ein bekannter PDSCH nicht ohne DPCHs existieren.

Somit liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren und ein System zum Übertragen von Daten in ei- nem Mobilfunksystem bereitzustellen, bei dem der benötigte Signalisierungsaufwand über die Luftschnittstele gering gehalten wird.

Diese Aufgabe wird durch ein Verfahren zum Übertragen von Da- ten in einem Mobilfunksystem, insbesondere UMTS, mit den Merkmalen des Anspruchs 1 gelöst.

Das Verfahren zum Übertragen von Daten in einem Mobilfunksys- tem, insbesondere UMTS, weist die Verfahrensschritte - Senden von Parametern für den Empfang eines mehrfach ge- nutzten Kanals von einer Basisstation an eine Mobilstati- on, - Auswerten der Parameter in der Mobilstation, und - Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach genutzten Kanal durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, auf.

Die Parameter sind dabei allen durch die Basisstation ver- sorgten Mobilstationen bekannt. Bei dem mehrfach genutzten Kanal handelt es sich bevorzugt um einen gemeinsam genutzten Kanal bei einer Übertragung in Downlink-Richtung DSCH. Die Parameter werden in der mindestens einen Mobilstation ausge- wertet, woraufhin über den mehrfach genutzten Kanal von der Mobilstation Daten empfangen werden. Ein solcher Empfang wird durch die Parameter ermöglicht. Bevorzugt werden die Parame- ter per Rundfunk in das Versorgungsgebiet der Mobilstation ausgesendet. Bei dieser sogenannten"Broadcast"-Übertragung werden folglich allen nutzenden Mobilstationen in dem Versor- gungsgebiet der Basisstation die Parameter bekannt gemacht.

Bei dem mehrfach genutzten Kanal handelt es sich bevorzugt um einen Kanal, welcher hauptsächlich zur Übertragung von Daten- spitzen genutzt wird. Es werden darüber folglich Daten über- tragen, deren Übertragung bei einer Übertragung über norma- lerweise vorhandene Übertragungswege nicht gewährleistet wer- den könnte.

In einer Weiterbildung der vorliegenden Erfindung werden die Parameter mit einer Sendeleistung übertragen, die gewährleis- tet, dass die Parameter überall in dem Versorgungsbereich der Basisstation empfangen werden können.

In einer weiteren Ausführungsform der vorliegenden Erfindung werden die Daten gleichzeitig von einer Vielzahl von Mobil- stationen empfangen. Dies gewährleistet, dass die Daten über den mehrfach genutzten Kanal auch von dieser Vielzahl von Mo- bilstationen empfangen werden können.

In einer Weiterbildung der vorliegenden Erfindung handelt es sich bei den Daten um an eine Gruppe von an Mobilstationen gleichzeitig versandte Daten. Dabei handelt es sich bevorzugt um die Multicast-Gruppen bzw. Multicast-Daten.

Die eingangs gestellte Aufgabe wird auch durch ein System zum Übertragen von Daten in ein Mobilfunksystem, insbesondere UMTS, mit den Merkmalen des unabhängigen Anspruchs 8 gelöst.

Das System zum Übertragen von Daten in ein Mobilfunksystem, insbesondere UMTS, weist Mittel zum Senden von Parametern für den Empfang eines mehrfach genutzten Kanals von einer Basis- station an eine Mobilstation, Mittel zum Auswerten der Para- meter in der Mobilstation, und Mittel zum Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach ge- nutzten Kanal durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, auf. Die Parameter werden al- len durch die Basisstation versorgten Mobilstationen bekannt gemacht.

Die vorliegende Erfindung betrifft des Weiteren eine Mobil- station zur Verwendung bei einem erfindungsgemäßen Verfahren und/oder in einem erfindungsgemäßen System. Darüber hinaus betrifft die vorliegende Erfindung auch eine Basisstation zur Verwendung bei einem erfindungsgemäßen Verfahren und/oder in einem erfindungsgemäßen System.

Bei der vorliegenden Erfindung werden die für den Empfang von DSCHs (bzw. PDSCHs) benötigten Parameter allgemein bekannt gemacht, um mehreren Mobilfunk-Endgeräten die Möglichkeit zu geben, gleichzeitig Daten auf den DSCHs (bzw. PDSCHs) zu emp- fangen, und dabei den benötigten Signalisierungsaufwand über die Luftschnittstele möglichst gering zu halten.

Ein Vorteil der Erfindung liegt darin, dass die zum Empfang der DSCHs (bzw. PDSCHs) benötigten Parameter nicht jedem UE separat über einen DCCH mitgeteilt werden müssen, wenn DSCHs (bzw. PDSCHs) zeitgleich von mehreren Mobilfunk-Endgeräten empfangen werden sollen. Somit wird der Signalisierungsauf- wand über die Luftschnittstelle effektiv verringert, was ei- ner Einsparung von Übertragungs-Kapazitäten gleichzusetzen ist. Die eingesparten Übertragungskapazitäten können zur Übertragung von Nutzdaten verwendet werden. Dies hat den po-

sitiven Effekt, dass die Nutzdatenrate des Mobilfunksystems erhöht und die Signalisierungsrate des Mobilfunksystems ver- ringert wird.

Ein weiterer Vorteil der vorliegenden Erfindung ist, dass die entsprechenden Parameter durch die allgemeine Bekanntmachung in einem Mobilfunk-Endgerät bereits bekannt sind, auch wen der Empfang von Daten zeitgleich mit anderen Mobilfunk- Endgeräten auf einem oder mehreren DSCHs (bzw. PDSCHs) für das entsprechende Mobilfunk-Endgerät noch gar nicht vorgese- hen ist. Soll das entsprechende Mobilfunk-Endgerät nun zeit- gleich mit anderen Mobilfunk-Endgeräten-Daten auf einem oder mehreren DSCHs (bzw. PDSCHs) empfangen, können die für den Empfang der Daten benötigten Parameter sofort etabliert wer- den. Somit ist der Zeitbedarf zur Konfiguration eines Mobil- funk-Endgerätes für den Empfang von Daten auf dem DSCHs (bzw.

PDSCHs) im Allgemeinen sehr viel geringer, als bei den be- kannten Lösungen, bei denen zunächst eine Konfigurations- Nachricht zum Mobilfunk-Endgerät gesendet werden muss.

Die Erfindung wird im Folgenden unter Hinweis auf die beige- fügten Zeichnungen anhand von Ausführungsbeispielen näher er- läutert. Die dort dargestellten Merkmale und auch die bereits oben beschriebenen Merkmale können nicht nur in der genannten Kombination, sondern auch einzeln oder in anderen Kombinatio- nen erfindungswesentlich sein. Es zeigen : Figur 1 eine schematische Darstellung eines UMTS-Netzwerks ; Figur 2 eine schematische-Darstellung der Protokoll- Architektur der UMTS-Schichten 2 und 3 ; Figur 3 eine schematische Darstellung einer reduzierten MAC-Architektur ; Figur 4 eine schematische Darstellung einer Funkstütze- Aufbau-Nachricht ; Figur 5 eine DL-Transportkanal-Information gemeinsam für alle Transportkanäle ;

Figur. 6 eine schematische Darstellung physikalischer Kanal- Informations-Elemente ; Figur 7 einen System-Informationsblock Typ 6 ; Figur 8 ein Ausführungsbeispiel eines System- Informationsblocks Typ 6 ; Figur 9 ein Ausführungsbeispiel eines System- Informationsblocks Typ 6.

Die Figuren 1 bis 6 wurden bereits vorstehend bei der Einlei- tung der Beschreibung beschrieben, so dass auf diese Be- schreibung Bezug genommen wird.

Im nachfolgenden Ausführungsbeispiel wird von einem Multi- cast-Service in einem UMTS Mobilfunksystem ausgegangen. Die- ser Multicast-Service beinhaltet das Versenden von Daten, die im allgemeinen für eine Gruppe von Mobilfunkteilnehmer be- stimmt sind, über einen einzigen gemeinsamen Kanal, um Über- tragungskapazitäten der Luftschnittstelle einzusparen. Die Funktionen und Aufgaben eines solchen Kanals kann dabei bei- spielsweise der bereits beschriebene DSCH-Kanal übernehmen.

Ein DSCH, der die Funktion eines solchen Kanals übernimmt, wird daher im Folgenden als MC-DSCH"Multicast Downlink Sha- red Channel"bezeichnet. Dieser MC-DSCH ist dabei prinzipiell mit einem üblichen DSCH nach dem Stand der Technik identisch.

Ein Unterschied zum bekannten DSCH ist, dass der MC-DSCH zu einem bestimmten Zeitpunkt nicht nur einem Mobilfunkteilneh- mer bzw. UE zugeordnet ist, sondern mehreren UEs gleichzeitig zugeordnet sein kann. Die Mobilfunkteilnehmer, die zeitgleich einen MC-DSCH empfangen, gehören dabei im allgemeinen der selben Multicastgruppe (MC-Gruppe) an. Somit ist ein MC-DSCH zu einem bestimmten Zeitpunkt immer nur einer bestimmten MC- Gruppe zugewiesen.

Davon ausgehend das innerhalb eines Übertragungszeitrahmens, einem sogenannten Frame, immer nur ein MC-DSCH auf einen ent- sprechenden CCTrCH abgebildet wird, sind für alle Mobilfunk- teilnehmer, die den MC-DSCH zur gleichen Zeit empfangen sol- len, die zum Empfang des MC-DSCH benötigten Parameter iden-

tisch. Die Parameter, die die entsprechenden UEs der Mobil- funkteilnehmer für den Empfang des MC-DSCH und der zugehöri- gen PDSCHs benötigen, sind dabei das TFS des MC-DSCH, das TFCS des CCTrCH auf den der MC-DSCH abgebildet wird sowie die Spreizkodes der PDSCHs auf den die UEs die Daten des MC-DSCH empfangen sollen. Geht man nun davon aus, dass für jede MC- DSCH eine eigener CCTrCH vorhanden ist, entspricht eine TFC des TFCS immer genau einem TF des TFS des MC-DSCH.

Die Leistungsregelung eines MC-DSCH kann nach zwei unter- schiedliche Methoden durchgeführt werden. Zum einen kann die Leistungsregelung über die DPCHs der Teilnehmer einer MC- Gruppe durchgeführt werden und zum anderen über eine zusätz- lichen eigens für den Multicastservice konzipierten physika- lischen Kanal. Diese beiden Methoden werden im Folgen unter- schieden.

Für den Fall, dass ein Mobilfunkteilnehmer ausschließlich ei- nen MC-DSCH empfangen will, und die Leistungsregelung des MC- DSCH über die TPC Bits der assoziierten DPCHs durchgeführt wird, dient der DPCH im DL lediglich zur Übermittlung des ge- teilten 10 Bit langen TFCI und der TPC Bits. Dies ist darin begründet, dass das MAC Protokoll im Sender keine Daten auf einen DCH abzubilden braucht. Somit ist es sinnvoll, eine Grundeinstellung für den auf den DPCH abgebildeten DCH allge- mein bekannt zu machen. Mit Grundeinstellung ist dabei bei- spielsweise eine bestimmtes TF des DCH gemeint, das dem UE signalisiert, dass es keine Nutzdaten auf dem entsprechenden DCH zu empfangen hat. Dabei ist es aber auch möglich, dass für. den DCH das gesamte TFS und ein zugehöriges TFCS allge- mein bekannt gemacht wird.

Für den Fall, dass die Leistungsregelung eines MC-DSCH über einen zusätzlichen physikalischen Kanal gewährleistet werden soll, wird ein physikalischer Kanal für die DL-Richtung be- schrieben, der die TPC Bits aller einer MC-Gruppe zugehörigen UEs enthält und der als Multicast-Leistungskanal McPwCH (Mul-

ticast Power Channel) bezeichnet wird. Über diesen Kanal wird jedem UE der MC-Gruppe mitgeteilt, ob es im nächsten Übertra- gungszeitrahmen die Sendeleistung im UL erhöhen soll oder nicht, damit dessen TPC Bits in UL-Richtung von der NodeB weiterhin fehlerfrei empfangen werden können. Ein solcher McPwCH wird dabei wiederum mit einem separaten für den Kanal spezifischen Spreizkode kodiert. Somit ist eine weiterer Pa- rameter, der für den Empfang eines MC-DSCH und der zugehöri- gen PDSCHs benötigt wird, der Spreizkode mit dem der McPwCH kodiert wird.

Eine Variation des McPwCH beinhaltet, dass über ihn nicht ausschließlich TPC Bits gesendet werden. D. h., ein Teil der Gesamtkapazität des McPwCH kann für andere Kontrolldaten oder sogar auch für Nutzdaten reserviert sein. Betrachtet man nun den Fall, dass ein UE ausschließlich Daten eines Multi- castdienstes empfangen möchte und keine Daten über dedizierte Kanäle (DCHs), benötigt das UE des Mobilfunkteilnehmers den zum MC-DSCH assoziierten DPCH, wie zuvor schon beschrieben, lediglich zur Übertragung des geteilten 10 Bit langen TFCI.

Da dies eine Verschwendung von Übertragungskapazitäten bedeu- tet, ist es sinnvoll, dass der TFCI des CCTrCH, auf den der MC-DSCH abgebildet wird, über den McPwCH zum UE gesendet wird. Der TFCI wird dabei innerhalb der für andere Kontroll- daten oder für Nutzdaten reservierten Übertragungskapazitäten des McPwCH übertragen. Somit benötigt das UE eines Mobilfunk- teilnehmers, der ausschließlich einen oder mehrere Multi- castdienste empfangen möchte, keinen zum MC-DSCH assoziierten DCH und somit auch keinen DPCH. Da ein UE jedoch bei dem Auf- bau eines DCH bzw. des zugehörigen DPCH den im Stand der Technik erwähnten Referenzwert für die Leistungsregelung mit- geteilt bekommt, würde das UE in dem hier beschriebenen Aus- führungsbeispiel diesen Wert nicht erhalten. Das hätte zur Folge, dass ein UE in diesem Fall die Leistungsregelung nicht richtig durchführen könnte. Um zu gewährleisten, dass ein UE auch in dem Fall, dass mit einem MC-DSCH kein DCH bzw. DPCH verbunden ist, die Leistungsregelung richtig durchführen

kann, muss ein weiterer Parameter allgemein bekannt gemacht werden, der als"MC-DSCH Qualitätsziel"bezeichnet wird.

Die zuvor beschriebenen Parameter sollen den UEs der Mobil- funkteilnehmer nun allgemein durch einen System- Informationsblock SIB (System Information Block) bekannt ge- macht werden, anstatt sie durch eine separate Nachricht zu jedem UE zu übertragen. Im allgemeinen wird solch ein SIB vom RRC im RNC über den logischen Kanal BCCH zum MAC Protokoll gesendet. Das MAC-Protokoll bildet daraufhin den BCCH auf den Transportkanal BCH ab. Der BCH wird dann von der physikali- schen Schicht im Sender (Node B) mit einer Leistung übertra- gen, die gewährleistet, dass der BCH überall in dem Versor- gungsbereich der Node B empfangen werden kann. Die Informati- onen auf dem BCH können dabei von jedem im Versorgungsberei- che der Node B befindlichen UE ausgewertet werden. Somit wer- den die Information, die über den BCH gesendet werden, allge- mein bekannt gemacht. Man spricht in diesem Zusammenhang vom "Broadcasten"von Systeminformationen. Die zum Empfang eines MC-DSCH und der zugehörigen PDSCHs benötigten Parameter könne den UEs der Mobilfunkteilnehmer einer MC-Gruppe nun entweder durch ein bereits im UMTS spezifizierten SIB mitgeteilt wer- den, der dann jedoch entsprechend modifiziert werden muss, oder sie können den UEs durch einen eigenen nur für den Mul- ticastdienst einzuführenden SIB bekannt gemacht werden.

Figur 7 zeigt tabellarisch den System Informationsblock Typ 6 (SIB 6) nach dem Stand der Technik. Dieser ist der Spezifika- tion des RRC Protokolls entnommen und wird in der technischen Spezifikation TS 25. 331"Radio Resource Control", des 3rd Ge- neration Partnership Projects (3GPP), März 2001, genauer be- schrieben. In der Figur 7 sind in Zeilen die verschiedenen Informationselemente des SIB eingetragen und in der ersten Spalte der Name des Elements und ggf. eine hierarchische Gliederung des Elements mit Hilfe des Zeichens">", in der zweiten Spalte eine Angabe darüber, ob das Element vorhanden sein muss (MP="Zwingend Notwendig", OP="Optional", CV

X="Bedingter Wert"also abhängig von X, wobei X unten defi- niert wird), in der dritten Spalte ggf. eine Angabe über das mehrfache Vorhandensein des Elements und in weiteren Spalten weitere Informationen. Die Angabe"OP"bewirkt, dass in einer Bit-Representation das IE zunächst mit Informationen beginnt, die angeben, ob weitere Informationen dieses Elementes vor- handen sind. Da diese Information beispielsweise durch ein einzelnes Bit dargestellt werden können, können optionale In- formationselemente bei Nicht-Vorhandensein der Information Übertragungsbandbreite sparen.

Wie Figur 7 zu entnehmen ist, wird im SIB 6 zwischen den bei- den UMTS Modes FDD und TDD unterschieden. Die zuvor erwähnte hierarchische Gliederung der IEs durch das Zeichens">"ist anhand dieser Unterscheidung zu erkennen. Das in Zeile 4 ent- haltende Zeichen">"bedeutet, dass alle nachfolgenden IEs mit dem Zeichen" »" nur für den FDD Mode Gültigkeit haben, genauso wie alle IE, die nach Zeile 6 das Zeichen" »" haben, nur für den TDD-Modus von Bedeutung sind. Dabei ist eine wei- terführende hierarchische Gliederung durch mehr als zwei Zei- chen (>>>...) im allgemeinen möglich.

In Figur 8 (die sich über die Seiten 8 und 9 erstreckt) ist der für das Rundfunk-Übertragen von Multicastinformationen modifizierte SIB 6 abgebildet. Änderungen gegenüber dem Stand der Technik sind dabei in kursiver Schrift gezeigt. Da der SIB 6 Informationen übertragen soll, die unter anderem zum Empfang eines MC-DSCH benötigt werden, sind dem SIB 6 zu- nächst Transportkanal IEs hinzugefügt worden (Zeile 1 bis 7).

Setz man nun voraus, dass jede MC-Gruppe einen eigenen MC- DSCH konfiguriert bekommt, besagt die Zeile 2 in Figur 8, dass alle in der Tabelle folgenden Elemente, die mit mindes- tens einem">"eingerückt sind, sich so oft wiederholen, wie dieses IE angibt. Somit wird eine Liste von IEs erzeugt, die nach MC-Gruppen sortiert ist. D. h., die IEs in den Zeilen 3 bis 7 wiederholen sich für jede MC-Gruppe. Das IE in der Zei- le 3 (MC-Gruppenidentität) identifiziert dabei die MC-Gruppe,

für die die nachfolgenden IEs von Bedeutung sind. Mit dem IE 'TFS des MC-DSCH' (Zeile 4) wird nun der Transport-Format- Satz des für die MC-Gruppe konfigurierten MC-DSCHs allgemein bekannt gemacht und mit dem IE'TFCS'der Transport-Format- Kombinationssatz des CCTrCH, auf den die Daten des MC-DSCH abgebildet werden. Mit dem fünften IE in der Liste wird für den zum MC-DSCH assoziierten DCH eine Grundeinstellung bzgl. des Transport Formats übertragen, wobei dieses IE jedoch op- tional vorhanden sein kann. Das letzte IE der Liste gibt den Referenzwert für die Leistungsregelung der PDSCH an, auf die der entsprechende MC-DSCH abgebildet wird.

Die für den Empfang der PDSCHs und die für den Empfang des McPwCH allgemein gültigen Informationen sind im SIB 6 unter den IEs der physikalischen Kanäle (Zeile 13 bis 17) einge- fügt. Da diese Informationen auch wieder MC-Gruppen spezi- fisch sind, ist hier auch eine Liste von IEs vorhanden die nach den MC-Gruppen sortiert ist. D. h., wie zuvor bei den IEs für die Transportkanäle sind die nach Zeile 13 mit dem Zei- chen">>>"eingerückten IEs für jede MC-Gruppe einmal vorhan- den. Mit dem IE'MC-Gruppenidentität'wird dabei wiederum die MC-Gruppe identifiziert, für die die nachfolgenden IEs (Zeile 15 bis 17) bestimmt sind. Das IE'PDSCH Code Mapping' (Zeile 15) hat die gleiche Aufgabe wie beim Stand der Technik. Mit diesem IE wird die Zuordnung von TFCI (Feld 2) Werten zu den Spreizkodes (Kanalisierungscodes) der PDSCHs, die die Daten des MC-DSCH transportieren, übertragen. Die IEs'Spreizfaktor (für McPwCH) 'und'Codenummer (für McPwCH)'beschreiben zu- sammen den Spreizkode (Kanalisierungscode) mit dem der McPwCH vor dem Senden über die Luftschnittstelle gespreizt wird.

Betrachtet man den Fall, dass im Sender (Node B) mehrere MC- DSCHs zeitmultiplext über einen CCTrCH gesendet werden, benö- tigt ein Teilnehmer, der nur ein bestimmten MC-DSCH und damit auch nur Informationen einer bestimmte MC-Gruppe empfangen möchte, ein TFCS das die Existenz aller über den CCTrCH über- tragenen MC-DSCHs berücksichtigt. Somit ist ein solches TFCS

nicht mehr für eine MC-Gruppe spezifisch, sondern ist für mehrere MC-Gruppen gleichermaßen gültig. Daher kann das IE 'TFCS'in solch einem Fall nach den MC-Gruppen spezifischen IEs im SIB 6 übertragen werden, wie es in Figur 9 (die sich über die Seiten 10 und 11 erstreckt) zu sehen ist. Änderungen gegenüber Figur 8 sind dabei in kursiver Schrift gezeigt.

Durch das Senden des modifizierten SIB 6 können die zum Emp- fang eines MC-DSCH und der zugehörigen PDSCH benötigten In- formationen allgemein bekannt gemacht werden. Somit brauchen diese Informationen nicht zu jedem UE einzeln über eine dedi- zierte Verbindung übertragen werden, wenn ein Mobilfunkteil- nehmer einen Multicastdienst in Anspruch nehmen möchte. Das hat zur Folge, dass weniger Übertragungskapazitäten zum Auf- bau eines Multicastdienstes benötigt werden und sich der Sig- nalisierungsaufwand effektiv verringern lässt. Ferner können die von einem UE über den SIB 6 empfangenen Parameter gespei- chert werden, auch wenn das UE zum aktuellen Zeitpunkt noch keinen Multicastdienst empfangen möchte. Somit sind die zum Aufbau eines Multicastdienstes benötigten Parameter im UE be- kannt und könne sofort etabliert werden, wenn das UE zu einem späteren Zeitpunkt an einem Multicastdienst teilnehmen möch- te. Das hat zur Folge, dass der Aufbau einer Multicastverbin- dung im allgemeinen weniger Zeit in Anspruch nimmt.

Die zum Rundfunk-Übertragen vorgeschlagenen Parameter bzw.

IEs können jedoch auch in einem separaten, eigens für Multi- castdienste einzuführenden SIB enthalten sein.