DE10138768A1 - Broadcast/Multicast-Multiplexing - Google Patents

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Broadcast/Multicast-Multiplexing in Mobilfunknetzwerken, wobei das Abbilden und/oder Multiplexen der oberhalb der Broadcast/Multicast-Control-Schicht gelegenen Radio Bearer (14) auf die unterhalb der Broadcast/Multicast-Control-Schicht gelegenen Radio Link Control Service Access Points (Verbindung RLC-BMC), die dann im Radio Link control auf die logischen Kanäle (9) abgebildet werden, anhand von Service-Indentitäten erfolgt.

Description

• Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Broadcast/Multicast-Multiplexing, wie durch den Oberbegriff des unabhängigen Patentanspruches 1 beschrieben.
• Bei vielen, in modernen Mobilfunksystemen angebotenen Diensten und Anwendungen sollen Nachrichten nicht nur zu einem, sondern zu zwei und mehreren Mobilfunkteilnehmern übertragen werden. Beispiele für solche Dienste und Anwendungen sind News-Groups, Video-Konferenzen, Video-On-Demand, verteilte Anwendungen usw.
• Bei der Übertragung der Nachrichten zu den verschiedenen Teilnehmern ist es möglich, jedem Empfänger (Benutzerendgerät) separat eine Kopie der Daten zuzusenden. Diese Technik ist zwar einfach zu implementieren, für große Gruppen jedoch ungeeignet. Da dieselbe Nachricht über N, mit N = Anzahl der Empfänger der Nachricht, Einzelverbindungen (Unicast-Verbindungen = UC) übertragen wird und dabei mehrfach über gemeinsame Verbindungswege gesendet wird, benötigt dieses Verfahren eine sehr hohe Bandbreite.
• Eine bessere Möglichkeit bietet die Multicast-Übertragung. Hierbei werden die verschiedenen Teilnehmer, denen dieselbe Nachricht übermittelt werden soll, zu einer Gruppe (Multicast-Gruppe) zusammengefasst und dieser eine Adresse (Multicast-Adresse) zugeordnet. Die zu übertragenden Daten werden daraufhin nur einmal an diese Multicast-Adresse gesendet. Über gemeinsame Verbindungswege vom Sender zu den Empfängern wird die Multicast-Nachricht im Idealfall nur einmal gesendet. Der Sender muss nicht wissen, wo und wie viele Empfänger sich hinter der Multicast-Adresse verbergen.
• Beim Broadcast werden Nachrichten an alle Teilnehmer innerhalb eines geopraphischen Gebietes gesendet. Ein solches Gebiet kann beispielsweise durch einen Teil des Gesamtnetzes bestimmt sein. Wie beim Multicast wird die Broadcast-Nachricht dabei über gemeinsame Verbindungswege vom Sender zu den Empfängern im Idealfall nur einmal gesendet. Jeder Teilnehmer muss sich, sofern er Broadcast-Pakete empfangen will, in die entsprechende Broadcast-Gruppe eintragen. Er kann so bestimmen, ob er alle Broadcast-Nachrichten empfangen oder verwerfen möchte, oder ob er nur bestimmte Nachrichten empfangen möchte.
• Der Protokollstapel im UMTS ist in die Bitübertragungs-, die Sicherungs- und die Vermittlungsschicht unterteilt. Die Sicherungsschicht zerfällt in die Unterschichten Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) und Broadcast/Multicast Control (BMC). Die Vermittlungsschicht besteht aus den beiden Teilen Radio Resource Control (RRC) und Duplication Avoidance, wobei nur die RRC-Schicht auch im UTRAN (UMTS Terrestrial Radio Access Network) endet. Die korrespondierende Instanz der Duplication Avoidance gehört nicht zum UTRAN, sondern ist ins Core Network (CN) ausgelagert. In der dritten Schicht und der RLC- Schicht wird zwischen einer Nutzer- und einer Steuerungsebene unterschieden, wobei die PDCP- und die BMC-Schicht ausschließlich zur Nutzerebene gehören.
• Die RRC-Schicht verwaltet und steuert die Nutzung der Funkbetriebsmittel und hat deshalb über Dienstzugangspunkte Verbindungen zu allen anderen Schichten, um deren Konfiguration zu steuern. Diese Steuerdienstzugangspunkte dienen daher nicht der Kommunikation zwischen Partnerinstanzen sondern ausschließlich zwischen Schichten desselben Protokollstapels.
• Die Verbindungen zwischen RRC und niedrigeren Schichten dienen dem Empfang von Messwerten der Bitübertragungs- und der MAC-Schicht sowie dem Steuern von Funktionen in den einzelnen Schichten. Die RRC-Schicht bestimmt z. B. den Sollwert des inneren Kreises der Leistungsregelung, die in der Bitübertragungsschicht durchgeführt wird.
• Die MAC-Schicht hat Aufgaben, wie z. B. die Identifizierung der Nutzer, für die ein Paket bestimmt ist, falls es auf allgemeinen Kanälen übertragen wird, und die Abbildung der logischen Kanäle auf die Transportkanäle. Die Übertragungsdienste der MAC-Schicht werden über die logischen Kanäle erbracht. Logische Kanäle werden durch die Art der Daten charakterisiert, die von ihnen übertragen werden. Die RLC-Schicht ist verantwortlich für die Überwachung der Datenübertragung, d. h. für die Feststellung von fehlenden Paketen und eventuell deren erneute Anforderung. In der RLC-Schicht können mehrere Einheiten definiert werden. Jede RLC-Einheit ist dabei mit einer Verbindung zwischen höheren Schichten und RLC (z. B. Radio Bearer) verbunden. Auch die RLC-Schicht kann senderseitig den Paketen, die sie von höheren Schichten bekommen hat, Kontrollinformationen hinzufügen. Diese Kontrollinformationen werden empfangsseitig genutzt, um z. B. zu beurteilen, ob Pakete fehlen, und werden von den Paketen entfernt, bevor diese wieder an die höheren Schichten weitergeleitet werden. Oberhalb der RLC-Schicht befindet sich unter ihr liegenden Schichten und vor allem für den Verbindungsaufbau verantwortlich ist. Die Verbindungen zwischen der RLC-Schicht und der RRC-Schicht werden Signalling Radio Bearers genannt (SRB). Außerdem befinden sich oberhalb der RLC-Schicht die sogenannten Radio Bearer (RB), die für die eigentliche Datenübertragung verwendet werden und die Verbindung zwischen der RLC-Schicht und der darüber liegenden Anwendung darstellen.
• Werden Paketdaten übertragen, befindet sich oberhalb von RLC noch die sogenannte Paketdaten-Konvergenzschicht (PDCP = Packet Data Convergence Protocol), die z. B. für die Komprimierung von IP(Internet-Protokoll)-Paketen verantwortlich ist. Weiterhin befindet sich oberhalb der RLC-Schicht noch die sogenannte Broadcast-Multicast-Kontrollschicht, die für den Empfang von Cell-Broadcast-Nachrichten verwendet wird.
• In der BMC-Schicht können, ähnlich wie für die RLC-Schicht, mehrere BMC-Einheiten definiert werden. Die Übertragung über die Luftschnittstelle wird über sogenannte physikalische Kanäle realisiert. Die Übertragungsdienste der Bitübertragungsschicht ( = physikalische Schicht) werden an den Dienstzugangspunkten über sogenannte Transportkanäle erbracht. Transportkanäle charakterisieren sich dadurch, wie die Daten übertragen werden.
• Gleiche Protokolle tauschen Protokoll-Dateneinheiten (Protocol Data Units = PDU) aus, indem sie die Dienste der unter ihnen liegenden Protokoll-Schichten für den Transport der Packet Data Units benutzen. Jede Protokoll-Schicht bietet der über ihr liegenden Schicht ihre Dienste an sogenannten Dienstzugangspunkten an. Diese Dienstzugangspunkte werden zum besseren Verständnis der Architektur mit allgemein gebräuchlichen und eindeutigen Namen versehen (z. B. Logische Kanäle, Transportkanäle, Radio Bearer). Für den Datentransfer nehmen Protokolle an ihren Dienstzugangspunkten Dienst-Dateneinheiten (Service Data Units = SDU) auf und geben daraus erzeugte Packet Data Units an die unter ihnen liegende Schicht ab. Packet Data Units von oberen Schichten sind somit identisch mit den Service Data Units der darunter liegenden Schicht.
• In Folgenden werden unterschiedliche, logische und Transport- Kanäle angesprochen und sollen deshalb nun kurz erläutert werden:
  CBS-Nachrichten werden zwischen RLC und MAC über den logischen Kanal CTCH (Common Traffic Channel) übertragen. Der CTCH dient zur Übertragung von Daten der Nutzerebene an alle oder eine Gruppe von Benutzerendgeräten und ist ein unidirektionaler Punkt-zu-Mehrpunkt-Kanal der Abwärtsstrecke. Der CTCH wird daraufhin auf den Transportkanal FACH (Forward Access Channel) abgebildet. Der FACH ist ein gemeinsamer Transportkanal auf der Abwärtsstrecke, der zur Übertragung relativ kleiner Datenmengen dient. Der FACH wird daraufhin auf den physikalischen Kanal S-CCPCH (Secondary Common Control Physical Channel) abgebildet. Grundsätzlich trägt der S-CCPCH Informationen des FACH und des PCH. Der P-CCPCH (Primary CCPCH) überträgt die Informationen des BCH. Der logische Kanal BCCH (Broadcast Control Channel) ist ein gemeinsamer Kanal der Abwärtsstrecke, auf dem Kontrolldaten an alle Benutzerendgeräte in einer Funkzelle rundgesendet werden. Diese Kontrolldaten sind beispielsweise die System-Informations-Blöcke (SIB). Abgebildet wird der BCCH entweder auf den FACH oder auf den BCH (Broadcast Channel).
• Die MAC-Schicht unterstützt Multiplexing. Dabei werden mehrere, logische Kanäle auf einen oder mehrere Transportkanäle abgebildet, so dass die zur Verfügung stehenden Ressourcen möglichst effizient genutzt werden. Die Konfiguration, welche logischen Kanäle auf welche Transportkanälen abgebildet werden, wird durch RRC vorgegeben. Berücksichtigt werden dabei die Prioritäten der logischen Kanäle als auch die Speicherbelegung im RLC.
• Durch die Verwendung eines TCTF (Target Channel Type Field) kann MAC feststellen, auf welchen Typ von logischem Kanal ein Transportkanal geleitet werden soll.
• Durch Verwendung der Benutzerendgerät-Identität kann MAC zwischen Benutzerendgeräten unterscheiden und weiß, auf welchen dedizierten, logischen Kanal ein gemeinsamer Transportkanal geleitet werden soll.
• In einem Sonderfall unterstützt MAC Multiplexen, wobei ein logischer Kanal auf zwei Transportkanäle abgebildet wird. In diesem Fall wird ein logischer Kanal DTCH auf je einen Transportkanal DCH und einen DSCH abgebildet.
• Für den UMTS-Standard ist bis dato nur der Cell Broadcast Service spezifiziert. Die entsprechenden CB-Daten werden dabei über einen logischen Kanal CTCH zum BMC übertragen und daraufhin, sofern die CB-Nachricht das Benutzerendgerät interessiert, über einen Radio Bearer (RB) zu höheren Schichten übertragen.
• Für Multicast und andere zukünftige Services, wie z. B. erweiterter Cell Broadcast Service, werden aber mehrere RB's, d. h. beispielsweise einer pro Service oder pro Gruppe eines Services, sowie mehrere, logische Kanäle und RLC-Entitäten für Multicast Services benötigt.
• Nach dem Stand der Technik unterstützt BMC aber keinerlei Multiplex-Funktionalität, so dass bisher lediglich jeweils einer der oberhalb des BMC gelegenen RB's über je eine BMC-Entität auf eine RLC-Entität und einen logischen Kanal abgebildet werden kann. Dies bedeutet, dass für jeden Service, insbesondere den Multicast-Service oder je Gruppe eines Multicast- Services, ein Radio Bearer, eine BMC-Entität, ein logischer Kanal und eine RLC-Entität vorhanden sein müsste.
• Die Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren vorzusehen, welches eine Multiplex-Funktionalität im Broadcast/Multicast Control vorsieht.
• Diese Aufgabe wird durch die Merkmale des unabhängigen Patentanspruchs 1 gelöst, wobei zweckmäßige Ausführungsformen durch die Merkmale der Unteransprüche beschrieben sind.
• Vorgesehen ist ein Verfahren zum Broadcast/Multicast- Multiplexing in Mobilfunknetzwerken, welches sich dadurch auszeichnet, dass das Abbilden und/oder Multiplexen der oberhalb der Broadcast/Multicast-Control-Schicht gelegenen Radio Bearer auf die unterhalb der Broadcast/Multicast-Control- Schicht gelegenen Radio Link Control Service Access Points (Verbindung RLC-BMC), die dann im Radio Link Control auf die logischen Kanäle abgebildet werden, anhand von Service-Identitäten erfolgt.
• Das Verfahren ist dabei vorzugsweise derart ausgestaltet, dass als Service-Identitäten Multicast-Service-Identitäten eingesetzt werden.
• Das Verfahren kann alternativ auch derart ausgestaltet sein, dass als Service-Identitäten Gruppen-Identitäten genutzt werden.
• Weiterhin kann das Verfahren nach Maßgabe der Erfindung derart ausgestaltet sein, dass die Broadcast/Multicast Control Packet Data Units eine Service-Identität aufweisen, über die unterschiedliche Broadcast/Multicast-Services voneinander unterschieden werden.
• Ebenso kann das Verfahren auch derart ausgestaltet sein, dass als Gruppen-Identitäten Multicast-Gruppenidentitäten genutzt werden.
• Netzwerkseitig sind die Broadcast/Multicast Control Service Data Units im Broadcast/Multicast Control um eine Service- Identitäten- bzw. Gruppen-Identität erweitert, wobei es sich hierbei insbesondere um Multicast-Service- bzw. Multicast- Gruppen-Identitäten handelt.
• Anhand dieser Identität nimmt die Broadcast/Multicast Control dann die Zuordnung zu den entsprechenden Radio Link Control Service Access Points (Verbindung RLC-BMC) vor. Dabei können Broadcast/Multicast Control Service Data Units von unterschiedlichen Radio Bearers auf einen Radio Link Control Service Access Point (Verbindung RLC-BMC) abgebildet werden, um so Ressourcen flexibel und effizient nutzen zu können.
• Auf Seiten der Endgeräte werden die Broadcast/Multicast Control Packet Data Units auf die Broadcast/Multicast Control Service- bzw. Gruppen-Identität hin überprüft.
• Das Verfahren nach Maßgabe der vorliegenden Erfindung ist dabei vorzugsweise auch derart gestaltet, dass zumindest zwei Radio Bearer im Broadcast/Multicast Control auf einen Radio Link Control Service Access Point (Verbindung RLC-BMC) abgebildet werden.
• Weiterhin ist das Verfahren nach Maßgabe der vorliegenden Erfindung auch vozugsweise derart ausgestaltet, dass ein Radio Bearer im Broadcast/Multicast Control auf zumindest zwei Radio Link Control Service Access Points (Verbindung RLC-BMC) aufgeteilt (aufgesplittet) wird.
• Das Verfahren zeichnet sich nach Maßgabe der Erfindung vorzugsweise auch dadurch aus, dass die Broadcast/Multicast Control Packet Data Units, zu denen ein Mobilfunkteilnehmer für einen oder mehrere der Broadcast/Multicast Services bzw. Gruppen eingetragen ist, demultiplext und auf den entsprechenden Radio Bearer abgebildet werden, wobei die Broadcast/Multicast Control dabei die Broadcast/Multicast Control Packet Data Units den entsprechenden Radio Bearers unter Berücksichtigung der Service- oder Gruppen-Identitäten zuordnet.
• Weiterhin kann im Rahmen des Verfahrens vorgesehen sein, dass in der Broadcast/Multicast Control eine Filterung vorgenommen wird, durch welche Broadcast/Multicast Control Packet Data Units, die zu Services bzw. Gruppen gehören, insbesondere Multicast-Services und -Gruppen, zu denen ein User Equipment nicht eingeschrieben ist, verworfen bzw. zerstört werden. Der Vorteil der Erfindung ist, dass die Möglichkeit besteht, Broadcast/Multicast-Control-Nachrichten sehr flexibel und effizient über die zur Verfügung stehenden Ressourcen zu übertragen.
• Ferner ist es möglich, einen Radio Link Control Service Access Point (Verbindung RLC-BMC) fest einem Service, insbesondere einem Multicast-Service zuzuweisen. Das heißt, dass man einen Radio Link Control Service Access Point (Verbindung RLC-BMC) bestimmen kann, der nur Informationen eines Multicast-Services transportiert, wobei diese von verschieden Radio Bearers stammen, die die Nachrichten der einzelnen Multicast-Gruppen des Multicast-Service transportieren.
• Weitere Eigenschaften und Vorteile ergeben sich aus der folgenden Beschreibung einer bevorzugten Ausführungsform der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen; darin zeigt:
• Fig. 1 die schematische Darstellung der Protokollarchitektur im UMTS;
• Fig. 2 den schematischen Aufbau eines Teiles eines Radio Bearers der Architektur nach Fig. 1;
• Fig. 3 den schematischen Aufbau eines weiteren Teiles eines Radio Bearers der Architektur nach Fig. 1;
• Fig. 4 die schematische Darstellung eines Vergleichs von Multicast-Gruppen-Identitäten im Broadcast/Multicast Control.
• Fig. 1 zeigt die UMTS-Protokoll-Architektur der zweiten Schicht und der unteren, dritten Schicht, die die Protokolle der UMTS-Luftschnittstelle beinhalten. Diese Architektur liegt sowohl im mobilen Endgerät (User-Equipment, Benutzerendgerät) als auch in einem Knoten des Mobilkommunikations- Netzes (Radio Network Controller, RNC) vor. Das heißt, dass jedes der Protokolle einmal im Benutzerendgerät und einmal im RNC existiert. Der Bereich links der gestrichelten Linie betrifft dabei das C-Plane-Signalling, d. h. die Netzwerkebene, und der Bereich rechts davon die U-Plane-Information, d. h. die Nutzerebene.
• Jede der in Abb. 1 dargestellten Protokoll-Schichten bietet der über ihr liegenden Schicht ihre Dienste an so genannten Dienstzugangspunkten an. Diese Dienstzugangspunkte werden zum besseren Verständnis der Architektur mit allgemein gebräuchlichen und eindeutigen Namen versehen, wie z. B. Logische Kanäle, Transportkanäle, Radio Bearer, Signalling Radio Bearer. Die in Abb. 1 dargestellten Protokoll-Schichten sind:
  
• - die Radio Resource Control-(RRC) 2
• - die Packet Data Convergence Protokoll-(PDCP) 4
• - die Broadcast/Multicast Control-(BMC) 6
• - die Radio Link Control-(RLC) 8
• - die Medium Access Control-(MAC) 10
• - und die physikalische Schicht (PHY) 12
• Generell können im UMTS-Mobilfunkendgerät (User Equipment = UE) Daten von verschiedenen Applikationen erzeugt werden. Für Sprachverbindungen erzeugt beispielsweise ein Sprach-Coder einen oder mehrere Sprach-Datenströme, oder ein HTML-Browser erzeugt unregelmäßige Paket-Datenströme. Diese Daten werden zunächst eventuell von Protokollen höherer Schichten modifiziert und für den Datentransfer in verschiedenen Netzen vorbereitet, beispielsweise TCP und IP. Für den Transport über die UMTS- Luftschnittstelle müssen diese Daten in den verschiedenen Protokollen der zweiten Schicht PDCP 4, BMC 6, RLC 8 und MAC 10 optimiert werden. Der Dienstzugangspunkt, an dem nicht- UMTS-spezifische Protokolle den Übertragungsdienst der UMTS- Luftschnittstelle nutzen können, wird als Radio Bearer (RB) 14 bezeichnet. RB's 14 werden also oberhalb der zweiten Schicht je nach genutzten Protokollen oberhalb von PDCP 4, BMC 6 oder RLC 8 angeboten und übertragen Daten transparent vom Benutzerendgerät über die UMTS-Luftschnittstelle zum RNC und umgekehrt. Der Dienstzugangspunkt, an dem das UMTS-spezifische RRC-Protokoll den Übertragungsdienst der UMTS-Luftschnittstelle nutzt, wird dabei als Signalling Radio Bearer (SRB) 16 bezeichnet.
• RB's 14 und SRB's 16 können dabei sowohl bidirektional als auch unidirektional sein. Sie können also Daten entweder in zwei Richtungen (im Uplink, UL und im Downlink, DL) oder nur in einer Richtung (UL oder DL) übertragen.
• Ellipsen zwischen den Schichten symbolisieren die Orte der Dienstzugangspunkte für die Kommunikation mit der jeweiligen Partnerinstanz, die sogenannten SAP's (Service Access Points), wie z. B. Logical Channels 9 sowie Transport Channels 11.
• Den höheren Schichten bietet BMC 6 seine Services an mehreren RBs 14 an. Diese RBs 14 können Daten unterschiedlicher Services transportieren (z. B. Multicast, Cell Broadcast, erweiterter CB, . . .), wobei ein RB 14 insbesondere immer die Daten eines bestimmten Services überträgt.
• Verschiedene RBs 14, die die Daten des selben Services, insbesondere Multicast-Service, übertragen, können sich insbesondere dadurch unterscheiden, dass sie die Daten der verschiedenen Multicast-Gruppen eines Multicast-Services übertragen.
• In Fig. 2 werden Informationen der Radio Bearer 14.3, 14.4, 14.5 und Nachrichten unterschiedlicher Gruppen des gleichen Multicast Services 18 übertragen. Radio Bearer 14.3 überträgt dabei die Daten von Multicast-Gruppe 20.6, RB 14.4 die von Multicast-Gruppe 20.7 und RB 14.5 die von Multicast-Gruppe 20.8. RB 14.6 transportiert Cell-Broadcast-Nachrichten 22 (Stand der Technik), die über eine Broadcast/Multicast Control Entität 6, einen Radio Link Control Service Access Point 24.4 (Verbindung RLC-BMC), eine RLC-Entität 8 und einen logischen Kanal 9 übertragen werden.
• BMC 6 ist durch die Funkressourcen-Kontrolleinheit RRC 2 konfiguriert und darüber informiert, welche Multicast-Gruppe des Multicast-Services auf welchem Radio Bearer sendet. Um die Ressource des Radio Link Control Service Access Points 24.3effektiv zu nutzen, führt BMC 6 ein Multiplexen bzw. Demultiplexen der Radio Bearer 14.3 bis RB 14.5 aus.
• Netzwerkseitig werden die Daten der Multicast-Gruppen 20.6 bis 20.8 (BMC SERVICE DATA UNITs), insbesondere nach Prioritäten geordnet, dem Radio Link Control Service Access Point 24.3 als Broadcast/Multicast Control Packet Data Units übergeben. Dieses Verschachteln der Datenpakte unterschiedlicher Herkunft wird als Multiplexen bezeichnet.
• Die Broadcast/Multicast Control fügt den Broadcast/Multicast Control Packet Data Units eine Kontrollinformation hinzu, die Auskunft darüber gibt, von welcher Multicast-Gruppe (oder Service) die Broadcast/Multicast Control Packet Data Unit kommt (Fig. 4a). Ein Service- oder Gruppen-Typ kann Informationen über die Darstellung der Service bzw. Gruppen Identität geben, oder um was für einen Service es sich handelt, z. B. Multicast oder Cell Broadcast (Fig. 4b). Alternativ kann Broadcast/Multicast Control auch eine Radio Bearer ID anfügen, die kennzeichnet, von welchem Radio Bearer die Nachricht kommt und so die Zuordnung zwischen Multicast-Gruppe und Radio Bearer erleichtert.
• Empfangsseitig wird im Benutzerendgerät die Nachricht über die physikalische Schicht 12, Transportkanäle 11 und die MAC- Schicht 10 auf einen logischen Kanal 9 übertragen. Diese gelangt dann über eine Radio Link Control Entität 8 zum Radio Link Control Service Access Point, RLC SAP (Verbindung RLC- BMC) des Benutzerendgerätes, in diesem Fall RLC SAP 24.3. Dass die BMC PDUs des MULTICAST-Services im Benutzerendgerät wieder auf RLC SAP 24.3 vorliegen, ist die Aufgabe niedrigerer Schichten (RLC, MAC, Physical Layer).
• Die BMC-Schicht des Benutzerendgerätes ist ebenfalls durch ihre Funkressourcen-Kontrolleinheit RRC 2 konfiguriert. Die auf dem RLC SAP 24.3 empfangenen BMC PDATA U's werden nun auf ihr Kontrollfeld hin überprüft.
• BMC 6 erkennt daraus, für welche Multicast-Gruppen die einzelnen BMC SERVICE DATA UNIT sind und leitet sie zu den entsprechenden RB's weiter. Dafür vergleicht BMC die Multicast-Gruppen-ID im Kontrollfeld der BMC PDUs mit einer durch RRC konfigurierten Tabelle 26, mit dem folgenden Inhalt: Mapping Table RB MULTICAST Group
  
  14.3 20.6
  14.4 20.7
  14.5 20.8
  else discard
  
  die das Mapping, d. h. die Zuordnung zwischen Multicast- Gruppen-ID und KB-Nummer angibt. In Fig. 5 ist dies schematisch dargestellt.
• BMC SERVICE DATA UNITs 28 für Multicast-Gruppen, zu denen ein Benutzerendgerät nicht eingeschrieben ist, sollen in BMC verworfen bzw. herausgefiltert werden. Die Konfiguration der Tabelle zur Zuordnung zwischen Multicast-Gruppe und RB nimmt die Funkressourcen-Kontrolleinheit RRC im Benutzerendgerät nur für solche Multicast-Gruppen vor, für die ein Benutzerendgerät auch eingeschrieben ist. Beim Vergleich der MULTICAST-Gruppen-Identität im Kontrollfeld der BMC PDUs mit den Einträgen in der von RRC konfigurierten Tabelle erkennt BMC dann, ob ein Benutzerendgerät zu einer bestimmten MULTICAST-Gruppe eingetragen ist. Trifft dies nicht zu, so soll die entsprechende BMC SERVICE DATA UNIT verworfen werden. In Fig. 6 ist das durch den Eintrag "else ~ discard" in der BMC- Tabelle 26 gekennzeichnet. Das bedeutet: Wenn BMC eine andere als die in ihrer Tabelle gelisteten MULTICAST-Gruppen-IDs erkennt, so soll BMC die entsprechende BMC SDU verwerfen.

Claims (9)

1. Verfahren zum Broadcast/Multicast-Multiplexing in Mobilfunknetzwerken,
dadurch gekennzeichnet,
dass das Abbilden und/oder Multiplexen der oberhalb der Broadcast/Multicast-Control-Schicht gelegenen Radio Bearer (14) auf die unterhalb der Broadcast/Multicast- Control-Schicht gelegenen Radio Link Control Service Access Points (Verbindung RLC-BMC), die dann im Radio Link Control auf die logischen Kanäle (9) abgebildet werden, anhand von Service-Identitäten erfolgt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Service-Identitäten Multicast-Service-Identitäten eingesetzt werden.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Service-Identitäten Gruppen-Identitäten eingesetzt werden.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es sich bei den Service-Identitäten um solche von Broadcast/Multicast Control Packet Data Units handelt, über die unterschiedliche Broadcast/Multicast-Services voneinander unterschieden werden.

5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass als Gruppen-Identitäten Multicast-Gruppenidentitäten genutzt werden.

6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest zwei Radio Bearer (14) im Broadcast/Multicast Control (6) auf einen Radio Link Control Service Access Point abgebildet werden.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass ein Radio Bearer (14) im Broadcast/Multicast Control (6) auf zumindest zwei Radio Link Control Service Access Points aufgeteilt wird.

8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Broadcast/Multicast Control Packet Data Units, zu denen ein Mobilfunkteilnehmer für einen oder mehrere der Broadcast/Multicast-Services bzw. -Gruppen eingetragen ist, demultiplext und auf den entsprechenden Radio Bearer (14) abgebildet werden, wobei die Broadcast/Multicast Control (6) dabei die Broadcast/Multicast Control Packet Data Units den entsprechenden Radio Bearers (14) unter Berücksichtigung der Service- oder Gruppen-Identitäten zuordnet.

9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Broadcast/Multicast Control (6) eine Filterung vorgenommen wird, durch welche Broadcast/Multicast Control Packet Data Units, die zu Multicast-Services und -Gruppen gehören, zu denen ein Benutzerendgerät nicht eingeschrieben ist, verworfen und/oder zerstört werden.