DE10064107A1 - Verfahren zum Verteilen einer Gruppennachricht in einem Funkkommunikationssystem sowie zugehöriges Funkkommunikationssystem - Google Patents

Abstract

Zum Verteilen einer Gruppennachricht (GN1) in einem Funkkommunikationsnetz (FN2) wird durch mindestens ein Multicast-Center (MCC) an die Mitglieder-Teilnehmergeräte einer ausgewählten Gruppe (A) die zu verteilende Gruppenachricht (GN1) lediglich auf einem gemeinsamen Übertragungspfad (GP) an mindestens eine übergeordnete Funknetzwerkkontrolleinheit (SGSN1) gesendet. Dabei werden mittels mindestens einer Speichervorrichtung (SP1) die aktuell zugehörigen, zu benachrichtigenden Teilnehmergeräte (UE1, UE2, UE4, UE5) der jeweils ausgewählten Gruppe (A) ermittelt und diese der übergeordneten Funknetzwerkkontrolleinheit (SGSN1) mitgeteilt. DOLLAR A "Verteilung von Multicast-Nachrichten im UMTS".

Description

Verfahren zum Verteilen einer Gruppennachricht in einem Funk­ kommunikationssystem sowie zugehöriges Funkkommunikationssys­ tem

Bei vielen in modernen Mobilfunksystemen angebotenen Diensten und Anwendungen ist es wünschenswert, Nachrichten nicht nur zu einem, sondern zu zwei oder mehreren Mobilfunkteilnehmern zu übertragen. Beispiele für solche Dienste und Anwendungen sind insbesondere News-Groups, Videokonferenzen, Video-On- Demand, verteilte Anwendungen, usw.

Eine Aufgabe der Erfindung ist es, einen Weg aufzuzeigen, wie solche Gruppen-Nachrichten an eine Vielzahl von Teilnehmerge­ räten eines Funkkommunikationssystems, insbesondere Mobil­ funknetzes, in effizienter Weise übertragen werden können. Diese Aufgabe wird durch folgendes erfindungsgemäße Verfahren gelöst: Verfahren zum Verteilen einer Gruppennachricht an mindestens eine Gruppe von Teilnehmergeräten eines Funkkommu­ nikationssystems, wobei in mindestens einer Speichervorrich­ tung die ein oder mehreren Teilnehmergeräte der jeweiligen Gruppe unter einer gemeinsamen Identifizierungsadresse abge­ legt worden sind und dort fortlaufend aktualisiert werden, wobei zur Verteilung der jeweiligen Gruppennachricht durch mindestens ein Multicast-Center an die Mitglieder- Teilnehmergeräte einer ausgewählten Gruppe diese zu vertei­ lende Gruppennachricht lediglich über einen gemeinsamen Über­ tragungspfad an mindestens eine übergeordnete Funknetzwerk- Kontrolleinheit gesendet wird, mittels der Speichervorrich­ tung die aktuell zugehörigen, zu benachrichtigenden Teilneh­ mergeräte dieser ausgewählten Gruppe ermittelt, und diese der übergeordneten Funknetzwerk-Kontrolleinheit mitgeteilt wer­ den, und wobei dann von dieser übergeordneten Funknetzwerk- Kontrolleinheit mindestens ein Übertragungspfad zur Verteilung der Gruppennachricht an die ermittelten Mitglieds- Teilnehmergeräte der ausgewählten Gruppe unter Zuhilfenahme einer oder mehrerer untergeordneter Funknetzwerk- Kontrolleinheiten bereitgestellt wird.

Dadurch ist eine effiziente und einfache Verteilung von Grup­ pen-Nachrichten an die verschiedenen Teilnehmergeräte der je­ weilig ausgewählten Gruppe ermöglicht.

Die Erfindung betrifft weiterhin ein Funkkommunikationssystem zum Verteilen einer Gruppennachricht an mindestens eine Grup­ pe von Teilnehmergeräten, insbesondere nach einem der vorher­ gehenden Ansprüche, wobei mindestens eine Speichervorrichtung vorgesehen ist, in der ein oder mehrere Teilnehmergeräte der jeweiligen Gruppe unter einer gemeinsamen Identifizierungsad­ resse ablegbar und dort fortlaufend aktualisierbar sind, wo­ bei mindestens ein Multicast-Center vorgesehen ist, mit des­ sen Hilfe bei einem Verteilungswunsch eine neue Gruppennach­ richt an die Mitglieds-Teilnehmergeräte einer ausgewählten Gruppe auf einem gemeinsamen Übertragungspfad an mindestens eine übergeordnete Funknetzwerkkontrolleinheit sendbar ist, wobei die Speichervorrichtung derart ausgebildet ist, dass die aktuell zugehörigen, zu benachrichtigenden Teilnehmerge­ räte dieser ausgewählten Gruppe ermittelbar, und diese der übergeordneten Funknetzwerkkontrolleinheit mitteilbar sind, und wobei die übergeordnete Funknetzwerkkontrolleinheit und/oder ihre jeweilig in Wirkverbindung stehende untergeord­ nete Funknetzwerkkontrolleinheit derart ausgebildet sind, dass mindestens ein Übertragungspfad von dieser übergeordne­ ten Funknetzwerkkontrolleinheit zur Verteilung der Gruppen­ nachricht an die ermittelten Mitglieds-Teilnehmergeräte be­ reitstellbar ist.

Sonstige Weiterbildungen der Erfindung sind in den Unteran­ sprüchen wiedergegeben.

Die Erfindung und ihre Weiterbildungen werden nachfolgend an­ hand von Zeichnungen näher erläutert.

Es zeigen:

Fig. 1 in schematischer Darstellung die prinzi­ pielle Architektur eines Mobilfunksys­ tems,

Fig. 2 in schematischer Darstellung den Aufbau eines Funkkommunikationssystems, das zur Durchführung des erfindungsgemäßen Ver­ fahrens zusätzlich zum Mobilfunksystem von Fig. 1 mindestens ein Multicast- Center zur Verteilung von Multicast- Nachrichten aufweist,

Fig. 3 mit 5 in schematischer Darstellung den schritt­ weisen Aufbau eines PDP-Contextes, wenn für ein bestimmtes Teilnehmergerät des Funkkommunikationssystems nach Fig. 1 bzw. 2 ein Datenpaket netzwerkseitig ü­ bermittelt werden soll,

Fig. 6 in schematischer Darstellung verschiedene Paketwege im Funkkommunikationssystem nach Fig. 1 für mehrere zu benachrichti­ gende Teilnehmergeräte, an die diesselbe Nachricht nach Aufbau von Übertragungsverbindungen entsprechend den Fig. 3 mit 5 jeweils einzeln übermittelt wird,

Fig. 7 in schematischer Darstellung Paketwege im erfindungsgemäßen Funkkommunikationssys­ tem nach Fig. 2 bei Anwendung des Über­ tragungswegaufbaus entsprechend den Fig. 3 mit 5 für das Mobilfunksystem nach Fig. 1,

Fig. 8 mit 10 in schematischer Darstellung den schritt­ weisen Aufbau von Übertragungsverbindun­ gen zur Übertragung von Multicast- Nachrichten an eine ausgewählte Gruppe von Teilnehmergeräten nach einer ersten Variante des erfindungsgemäßen Verfahrens mit Hilfe des Funkkommunikationssystems nach Fig. 2,

Fig. 11 in schematischer Darstellung den detail­ lierten Ablauf eines Verbindungsaufbaus für ein einzelnes Teilnehmergerät nach dem erfindungsgemäßen Verfahren entspre­ chend den Fig. 8 mit 10,

Fig. 12 in schematischer Darstellung eine weitere Variante des erfindungsgemäßen Verfah­ rens,

Fig. 13 in schematischer Darstellung den detail­ lierten Verbindungsaufbau für ein be­ stimmtes Teilnehmergerät,

Fig. 14 in schematischer Darstellung den Regist­ rierungsprozess eines Teilnehmergeräts im Funkkommunikationssystem nach Fig. 2, um eine Multicast-Nachricht nach dem erfin­ dungsgemäßen Verfahren empfangen zu kön­ nen,

Fig. 15 in schematischer Darstellung die Kompo­ nenten einer Packlet Switched Domaine, die beim Transport von Paketdaten im UMTS-Network beteiligt sind,

Fig. 16, 17 schematisch das prinzipiellen Verfahren zur Verteilung von Gruppennachrichten nach dem Internet Group Managment Proto­ koll,

Fig. 18 schematisch das prinzipielle Verteilungs­ verfahren für Gruppennachrichten nach dem Reverse Path Multicasting Prinzip,

Fig. 19 in schematischer Darstellung die Signali­ sierung für ein bestimmtes Teilnehmerge­ rät zum Eintrag seiner Multicast-Grup­ penzugehörigkeit in eine Datenbank zur Durchführung des erfindungsgemäßen Ver­ fahrens mit dem Funkkommunikationssystem nach Fig. 2,

Fig. 20 in schematischer Darstellung eine erste Variante einer Multicast-Context Aktivie­ rung zur Verteilung von Multicast- Nachrichten nach dem erfindungsgemäßen Verfahren mit Hilfe des Funkkommunikati­ onssystems nach Fig. 2,

Fig. 21, 22 jeweils in schematischer Darstellung mo­ difizierte Multicast-Context Aktivierun­ gen zur Durchführung des erfindungsgemä­ ßen Verfahrens,

Fig. 23 mit 25 drei verschiedene Varianten des erfin­ dungsgemäßen Multicast-Verfahrens zur Verteilung von Multicast.Nachrichten,

Fig. 26 eine Variante des Multicast-Verfahrens nach Fig. 23

Fig. 27 eine Variante des Multicast-Verfahrens nach Fig. 24, und

Fig. 28 eine Variante des Multicast-Verfahrens nach Fig. 25.

Elemente mit gleicher Funktion und Wirkungsweise sind in den Fig. 1 mit 28 jeweils mit denselben Bezugszeichen verse­ hen.

In modernen Mobilfunksystemen wie z. B. nach dem UMTS (Univer­ sal Mobil Communication System), GPRS (General Paket Radio Service), EDGE (Enhanced Data Rates for GSM Environment) ist es wünschenswert, Nachrichten nicht nur zu einem einzelnen, sondern zu zwei oder mehreren Mobilfunkteilnehmern zu über­ tragen. 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 separat eine Ko­ pie der Daten zuzusenden. Diese Vorgehensweise ist zwar ein­ fach zu implementieren, für große Gruppen von Teilnehmergerä­ ten jedoch zu aufwendig. Da die selbe Nachricht über N (N = An­ zahl der Empfänger der Nachricht) Einzelverbindungen (= Uni­ cast-Verbindungen) übertragen und dabei mehrfach über gemein­ same Verbindungswege gesendet wird, benötigt dieses Verfahren eine zu hohe Bandbreite.

Eine bessere Möglichkeit bietet demgegenüber die sog. Multi­ cast-Übertragung. Hierbei werden die verschiedenen Teilneh­ mergeräte, denen die selbe Nachricht übermittelt werden soll, zu einer Gruppe (= Multicast-Gruppe) zusammengefasst und die­ ser eine gemeinsame Identifizierungsadresse (Multicast- Adresse) zugeordnet. Auf diese Weise ist es nicht erforder­ lich, dass der jeweilige Sender weiß, wie viele und welche Empfänger sich hinter der Multicast-Adresse verbergen. Es ist vielmehr ausreichend für den jeweiligen Sender, lediglich den Namen bzw. die Adresse der zu benachrichtigenden Multicast- Gruppe zu kennen. Die zu übertragenden Daten werden daraufhin nur einmal an diese Multicast-Adresse versendet.

Problematisch für das Verteilen solcher Multicast-Nachrichten ist hierbei allerdings insbesondere die Verwaltung der Multi­ cast-Gruppen sowie die Wegwahl (= Routing) der Multicast- Nachrichten zu den einzelnen Teilnehmergeräten der Multicast- Gruppen. Die Erfassung der zu einer Multicast-Gruppe gehören­ den Teilnehmer ist insbesondere im Hinblick darauf problema­ tisch, dass zu jedem Zeitpunkt neue Teilnehmergeräte zu die­ ser Multicast-Gruppe beitreten, aber auch Mitglieder der je­ weiligen Multicast-Gruppe wieder austreten können.

Im Rahmen der Erfindung wird beispielhaft im folgenden auf die Komponenten der packetswitched Domain eine UMTS- Mobilfunknetzes FN1 eingegangen. Die Funktion und Wirkungs­ weise dessen Komponenten werden nachfolgend anhand von Fig. 15 näher erläutert:
Ein Teilnehmer-Endgerät wie z. B. UE (User Equipment) ist über eine Luftschnittstelle Uu (Uu-Interface) mit einer Basissta­ tion Node B verbunden. Diese Node B ist über eine Festnetz­ verbindung Iub mit einem RNC (Radio Network Controller) als erste Funknetzwerkkontrolleinheit verbunden, die die Ressour­ cen der Luftschnittstelle kontrolliert und verteilt. Der RNC wiederum kann eine oder mehrere Basisstationen versorgen. Das Teilsystem aus mindestens einem Radio Network Controller und entsprechend zugehörigen Basisstationen wird im allgemeinen als Radio Network Subsystem RNS bezeichnet, was in der Figur gestrichelt umrahmt angedeutet ist. Für die paketvermittelte Übertragung von z. B. IP-Paketen aus dem Internet IP zu einem einzelnen Teilnehmergerät wie z. B. UE ist mindestens einer der Radio Network Controller wie z. B. RNC über eine Festnetz­ verbindung Iu mit einer höheren Funknetzwerkkontrolleinheit SGSN, insbesondere im UMTS-Standard mit einer sog. Serving GPRS Support Node, verbunden. Für eine Übertragung von Daten aus einem fremden Paketdatennetz, wie hier beispielsweise dem Internet IP, ist die übergeordnete Funknetzwerkkontrollein­ heit SGSN vorzugsweise über eine Festnetzverbindung Gn mit mindestens einem Gateway GGSN, insbesondere einem Gateway GPRS Support Node, verbunden. Dieses Gateway GGSN realisiert den Zugangspunkt zu einem fremden Paketdatennetz. Über eine Festnetzverbindung Gi ist hier im Ausführungsbeispiel von Fig. 15 das Gateway GGSN mit einem Serverr im Internet IP ver­ bunden. Informationen für das Managment der mobilen Teilnehmer können von Gateway GGSN über eine Festnetzverbindung Gc und von der höheren Netzwerkeinheit SGSN über eine Festnetz­ verbindung Gr von einer zentral geführten Datenbank HLR ins­ besondere dem sog. Home Location Register abgefragt werden. Die höhere Funknetzwerkkontrolleinheit SGSN erfragt vom Home Location Register HLR nutzerspezifische Informationen wie z. B. zur Authentifizierung eines Teilnehmers. Desweiteren ist die höhere Kontrolleinheit SGSN vorzugsweise verantwortlich für einen Verbindungsaufbau zwischen dem jeweiligen Teilneh­ mergerät und einem fremden Paketdatennetz wie hier z. B. IP.

Sollen Paketdaten aus dem externen Paketdatennetz zum Funk­ netzwerk übertragen werden, so gelangen diese zuerst zum Ga­ teway GGSN, das beim Home Location Register HLR die jeweilig zuständige höhere Funknetzwerk-Kontrolleinheit SGSN erfragt. Dieser Gateway GGSN teilt nun der höheren Funknetzwerk- Kontrolleinheit SGSN mit, dass Daten für das entsprechende Teilnehmergerät vorliegen. Die höherer Funknetzwerk- Kontrolleinheit SGSN veranlasst daraufhin den Aufbau der Ver­ bindungen zwischen dem zu benachrichtigenden Teilnehmergerät UE und dem externen Netzwerk IP.

Im Rahmen der Erfindung wird dabei unter einem Teilnehmerge­ rät (User Equipment) als Komponente eines Funkkommunikations­ systems vorzugsweise ein mobiles Endgerät verstanden. Dieses ist z. B. im UMTS-Standard insbesondere über die Luftschnitt­ stelle Uu (Uu-Interface) mit dem sog. UTRAN (UMTS Terrestrial Radio Access Network) verbunden. Es enthält das UMTS Subscri­ ber Identity Modul (USIM), indem (ähnlich wie in der SIM im GSM-Netz) Identifizierungsdaten, die das Teilnehmergerät zur Registrierung und Teilnahme im UMTS-Netz berechtigen, gespei­ chert sind.

Eine Basisstation (Node B) ist eine Funknetzwerk-Komponente, die für die Versorgung einer bzw. mehrerer Funkzellen zustän­ dig ist. Mittels einer Basisstation erfolgt die Funkkommuni­ kation über die Luftschnittstelle mit dem jeweiligen Teilneh­ mergerät in der Funkzelle dieser Basisstation.

Unter Radio Network Controller wird im Rahmen der Erfindung eine erste, untergeordnete Funknetzwerk-Kontrolleinheit ver­ standen, mit deren Hilfe die Ressourcen der Luftschnittstelle zwischen der jeweiligen Basisstation und den etwaigen Teil­ nehmergeräten in deren Funkzelle kontrolliert wird. Ein Radio Network Controller versorgt und kontrolliert vorzugsweise ein oder mehrere Basisstationen. Das Teilsystem aus einem Radio Network Controller wie z. B. RNC in Fig. 15 und einem oder mehreren Basisstationen wird als Radio Network Subsystem RNS bezeichnet, was in der Fig. 15 durch eine gestrichelte Um­ rahmen angedeutet ist. Dieses Teilsystem ist durch das Iu- Interface mit mindestens einer höheren Netzwerkkontrollein­ heit wie z. B. SGSN in Fig. 15 verbunden.

GPRS Support Nodes wie z. B. SGSN bilden die Schnittstelle zwischen dem Funksystem und einem Festnetz für vorzugsweise paketvermittelte Services (PDN). Ein GPRS Support Node führt alle notwendigen Funktionen aus, um den Transport von Daten­ paketen vom externen PDN zum End-Teilnehmergerät, insbesonde­ re zur Mobilstation, und umgekehrt zu gewährleisten. Z. B. im UMTS-GPRS-Netzwerk gibt es vorzugsweise 2 verschiedene GPRS Support Nodes (GSNs): den SGSN (Serving GSN) und den GGSN (Ga­ teway GSN).

Der SGSN ist derjenige Knoten, der die Teilnehmergeräte, ins­ besondere Mobilfunkstationen einer ihm zugeordneten Region (SGSN Area) versorgt. Er verfolgt den Aufenthaltsort des jeweiligen Teilnehmergeräts, führt Sicherheitsfunktionen und Zugriffskontrollen aus (Authentication, cipher setting proce­ dures und ähnliches). Ein SGSN besitzt Routing/Traffic- Managment-Funktionen und realisiert die Schnittstelle zum GGSN (Gn) Access Network (Gb) und zu anderen PLMNs (Gp) (pub­ lic land mobile networks). Die Location Register Funktion des SGSN speichert neben den Teilnehmer Re­ gistrierungsinformationen (IMSI, temporäre Identitäten, PDP Adressen (packet data protocol) auch sogenannte Location In­ formationen, die benötigt werden, um eine Paketdatenübertra­ gung aufzubauen bzw. zu beenden.

Die Location Information kann je nach Modus der Mobilstation (MS) entweder die Cell- oder die Routing-Area sein, wo die MS derzeit registriert ist. Desweiteren werden aber auch die VLR-Nummer des verbundenen VLR (visitor location register) und die Adressen jedes GGSN gespeichert, für den ein aktiver PDP Context (siehe untenstehenden Abschnitt "Übertragung von Paketdaten im UMTS") besteht.

Desweiteren steuert der SGSN das Mobility Management (mm), das genutzt wird, um den aktuellen Aufenthaltsort einer MS zu bestimmen. Auf der gleichen Protokollebene zum Mobility Mana­ gement existiert das Session Management (SM), welches für die Aktivierung und Deaktivierung des eben genannten PDP Contex­ tes im SGSN sowie im GGSN zuständig ist.

Über das Gr-Interface tauschen SGSN und HLR Informationen aus.

Der GGSN ist der Knoten, der den Kontakt (Interworking) zwi­ schen einem UMTS PLMN und einem Paketdaten Netzwerk (PDN) er­ möglicht. Die Datenaustausch erfolgt über das Gi-Interface (Fig. 15). Der GGSN beinhaltet die Routing Informationen für die im PLMN erreichbaren UMTS Teilnehmer. Die Routing Infor­ mationen dienen der Kontaktierung des jeweiligen SGSN, in dessen Versorgungsbereich (SGSN Area) sich eine bestimmte MS momentan befindet. Um diesen SGSN zu kontaktieren, wird des­ sen Adresse als Location Information zweckmäßigerweise ge­ speichert.

Aufenthaltsinformationen über eine MS können über das Gc-In­ terface vom HLR abgefragt werden.

Home Location Register (HLR)

Das HLR besteht aus einer Datenbank, die für das Management der mobilen Teilnehmer verantwortlich ist. Ein PLMN (Public Land Mobile Network) kann ein oder mehrere HLRs beinhalten. Dies ist abhängig von der Anzahl der mobilen Teilnehmer, der Kapazität des Equipments und von der Organisation des Netz­ werkes. Die folgenden Arten von Informationen werden hier ge­ speichert:

• - Anmeldungsinformationen der Teilnehmer
• - Einige Location Informationen ermöglichen die Abrechnung und das Routing von Gesprächen zu dem MSC (Mobile-services Switching Center), bei dem die MS (Mobile Station) regist­ riert ist (z. B. die MS Roaming Number, die VLR (Visitor Lo­ cation Register) Number, die MSC Number, die Local MS Iden­ tity).

Sofern GPRS unterstützt wird, werden Location Informationen gespeichert, die die Abrechnung und das Routing von Nachrich­ ten im SGSN (Serving GPRS Support Node) ermöglichen, an dem die MS gegenwärtig angemeldet ist (z. B. die SGSN Number). Unterschiedliche Typen von Identifizierungen sind mit jeder Anmeldung einer MS verbunden und werden im HLR gespeichert:

• - International Mobile Subscriber Identity (IMSI)
• - Eine oder mehrere Mobile Station International ISDN numbers (MSISDN)
• - Keine, eine oder mehrere Packet Data Protocol (PDP) Adres­ sen (IP Adressen)

Es wird immer mindestens eine Identität, getrennt von der IMSI, mit einer MS Anmeldung übergeben und im HLR gespei­ chert. Die IMSI oder die MSISDN können als Kennung für den Zugang zu den Informationen des HLR für die "mobile Anmel­ dung" genutzt werden. Die HLR-Datenbank enthält auch andere Informationen, wie z. B.:

• - Teleservices und Übermittlerservices, Anmeldeinformationen
• - Serviceeinschränkungen (z. B. begrenztes Roaming)
• - eine Liste aller Gruppen IDs, welche die Teilnehmer zum Auf­ bau einer Voice Group oder eines Broadcast Calls berechtigen
• - Informationen darüber, wenn es einem GGSN (Gateway GPRS Support Node) erlaubt ist, dynamisch einem Teilnehmer eine PDP Adresse zuzuweisen
• - Optional zusätzliche Services

Home Subscriber Server (HSS)

Das HSS enthält LCS subscription data und Routing- Informationen. Für umherschweifende (roaming) UEs kann das HSS in verschiedenen PLMNs sein.

Dieses Netzwerkelement ist eine Erweiterung des HLR für das zukünftige All-IP-Netzwerk.

Bevor Paketdaten (hier im Ausführungsbeispiel IP-Pakete) zwi­ schen beispielsweise einem Server im Internet IP und einem End-Teilnehmergerät wie z. B. UE (vergleiche Fig. 15) über­ tragen werden können, wird vom Teilnehmergerät UE zweckmäßi­ gerweise ein sog. PDP Context (Paket Data Protokoll Context) aufgebaut, mit dessen Hilfe eine Verbindung zum Internet IP hergestellt wird. Ein PDP Context beschreibt dabei den Pfad durch das jeweilige Netzwerk, insbesondere UMTS-Netzwerk, und macht diesen in den Netzelementen UE, SGSN, GGSN bekannt. Erst daraufhin kann eine Verbindung aufgebaut werden, über die dann die Paketdaten (im UMTS IP-Pakete) übertragen wer­ den.

Im Rahmen dieser Erfindung wird häufig der Begriff Bearer verwendet. Allgemein beschreibt der Begriff Bearer (Träger) einen Pfad zur Übertragung von Informationen. Dieser ist ins­ besondere definiert durch seine Kapazität, Laufzeitverzöge­ rung und Bitfehlerrate. Die Schnittstelle zwischen dem jewei­ ligen Radio Network Subsystem RNS und sog. Core-Network (CN) wird als EU-Interface bezeichnet. Das Core-Network ist dabei durch eine gestrichelte Umrahmung in der Fig. 15 angedeutet. Der Informationspfad zwischen dem RNS und dem CN wird dabei insbesondere EU-Baerer genannt. Ein Radio-Bearer ist vorzugsweise der Service für den Transfer von Nutzerdaten zwischen dem jeweiligen Teilnehmergerät UE und UTRAN (UMTS Terrestrial Radio Access Network).

Insbesondere im UMTS-Funkkommunikationssystem sowie weiteren Funkkommunikationssystemen wie z. B. nach dem GPRS, EDGE, OFDM (Orthogonal Frequency Division Multiplexing) Prinzip sind Multicast-Services zur Verteilung von Multicast-Nachrichten von Interesse.

Bisher werden lediglich im Internet Multicast-Dienste angebo­ ten, d. h. auf der Festnetzseite. Ein solcher Dienst ist bei­ spielsweise das IP Multicast. Das international genormte In­ ternet-Protokoll (IPV6) bietet die Möglichkeit der sog. Mul­ ticast-Adressierung, über die Informationen zwischen Gruppen von Rechnern (oder ganzen Subnetzen) ausgetauscht werden kön­ nen. Die Empfängergruppe, auch Multicast-Gruppe genannt, wird mit einer eindeutigen IP-Adresse (Multicast-Adresse) ange­ sprochen, wobei der Sender die Zusammensetzung der Gruppe, z. B. Mitgliederanzahl und Aufenthaltsort nicht kennt. Einzel­ ne Hosts, insbesondere Rechner können jederzeit einer Gruppe beitreten und sie wieder verlassen. Ein Host kann Mitglied in mehreren Gruppen sein. Um an eine Gruppe Daten zu senden, ist es nicht erforderlich, dass der Sender zwingend Gruppenmit­ glied ist. Für die Verwaltung von Multicast-Gruppen und die Wegwahl (Routing) der Nachrichten zu den Teilnehmern einer IP Multicast-Gruppe gibt es im Internet unterschiedliche Algo­ rithmen bzw. Protokolle.

Internet-Group-Managment-Protokoll (IGMP)

Dieses Protokoll ermöglicht eine Multicast-Router (MC-Router) wie z. B. IPR von Fig. 16 Gruppenzugehörigkeiten einzelner Rechner wie z. B. H1 mit HN abzufragen. Es gibt einem Host die Möglichkeit, auf solch eine Anfrage RQ alle seine Mitglied­ schaften anzuzeigen. Das Internet-Group-Managment-Protokoll IGMP Version 1 kann zwei Arten von Meldungen versenden. Die eine nennt sich Host Membership Query (Typ = 1) und die andere Host Membership Report (Typ = 2). Ein Multicast-Router wie z. B. IPR von Fig. 16 informiert sich in seinem Zuständigkeitsbe­ reich (Subnetz) über die anwesenden Gruppenmitglieder wie z. B. H1 mit HN. Dies erreicht er durch die Aufforderung RQ an alle Hosts, ihre Gruppenzugehörigkeit bekannt zu geben (Host Membership Query). Solche Querys werden vorzugsweise in peri­ odischen Abständen erzeugt, damit sich der Router IPR auf Veränderungen einstellen kann. Damit diese Nachricht alle Hosts erreicht, wird diese an die Gruppe aller Hosts im Sub­ netz gesendet. Nach Erhalt dieses Querys antwortet jeder Host für jede Gruppe, in der er Mitglied ist, mit einem Host Mem­ bership Report RE, was in der Fig. 17 veranschaulicht ist. Er gibt dem Multicast-Router IPR damit bekannt, dass er Mit­ glied dieser Gruppe ist. IGMP Version 2 bietet Hosts die Mög­ lichkeit, dem MC-Router beim Verlassen einer MC-Gruppe eine Leave-Nachricht zu zusenden, um so unnötigen Verkehr zu ver­ meiden. Desweiteren können gruppenspezifische Querys versen­ det werden, was bedeutet, dass nicht immer alle Gruppenzuge­ hörigkeiten abgefragt werden, sondern vorzugsweise immer nur Bestimmte.

Reverse Path Multicasting (RPM)

Ein Algorithmus, der Multicast-Nachrichten vom Sender über ein Netz (z. B. Internet) bis zu den Empfängern verteilt, ist das sog. Reverse Path Multicasting. Dessen Grundprinzip ist schematisch in der Fig. 18 veranschaulicht. Beim RPM- Verfahren wird ein erstes Datenpaket (einer Multicast- Nachricht) eines Senders über das ganze Netz verteilt. Be­ kommt nun ein Blattrouter (Multicast Router, der keine weite­ ren Verbindungen zu anderen Routern hat) ein Paket einer Gruppe, für die er keine Mitglieder in seinem Subnetz hat (was er beispielsweise mit Hilfe von IGMP erfragt hat), so sendet er an seine Vorgänger eine sog. Prune Nachricht wie z. B. PRN. Damit teilt er seinem Vorgänger mit, dass er zu­ künftig Daten dieser Gruppe nicht mehr benötigt. Falls nun ein Router auf allen seinen child links (Verbindungen zu an­ deren Routern, außer die, über die er die Nachricht bekommen hat) Prune Nachrichten erhält und in seinem eigenen Subnetz auch keine Mitglieder für diese Gruppe vorhanden sind, so gibt auch er an seine Vorgänger eine Prune Nachricht für die­ se Gruppe weiter. Somit beschränkt sich die Verteilung der Daten auf Pfade, die zu Gruppenmitgliedern führen. Bezogen auf Fig. 17 bedeutet dies, vorausgesetzt im Subnetz von Rou­ ter E und F befinden sich keine Mitglieder der betrachtenden Gruppe, dass keine Daten vom Router B nach Router E gesendet werden. Um jedoch zu überprüfen, ob in einem durch Prune Nachrichten verkürzten Teilbaum ein Host einer Gruppe beige­ treten ist, ist es zweckmäßig, in periodischen Abständen Da­ ten wieder über das ganze Netz zu senden. Jeder Router pro Gruppe speichert vorzugsweise Daten darüber, an welchen Rou­ ter er Pakete weitergeben darf und an welche nicht.

Um nun für ein Funkkommunikationsnetz, insbesondere für ein UMTS und/oder GPRS Mobilfunksystem, eine effiziente Vertei­ lung von Multicast-Nachrichten zu ermöglichen, wird vom Grundkonzept her betrachtet zweckmäßigerweise ein Eintrag der Multicast-Gruppenzugehörigkeit in mindestens eine Datenbank, das Bekanntmachen der Multicast-Gruppenteilnehmern in den Netzwerkelementen des Funkkommunikationsnetzwerks (Multicast- Context activation) und/oder die Übertragung einer Multicast- Nachricht von der jeweiligen Nachrichtenquelle wie z. B. einem Multicast-Sender bis zur Nachrichtensenke wie z. B. dem End- Teilnehmergerät einer Multicast-Gruppe vorgenommen. Im Rahmen der Erfindung wird häufig das sog. Multicast-Center erwähnt. Diese zusätzliche Komponente ist für das Generieren von Mul­ ticast-Nachrichten zuständig.

Mit Hilfe dieser prinzipiellen Einführung einer Datenbank für den Eintrag der Multicast-Gruppenzugehörigkeiten sowie der Funktionalitätserweiterung der bereits bestehenden Funknetz­ werkkomponenten um die Fähigkeit, Multicast-Nachrichten er­ kennen zu können, ist eine einfache und effiziente Verteilung von Multicast-Nachrichten im jeweiligen Funkkommunikations­ system ermöglicht. Weiterhin ist eine effiziente Anbindung an externe Festnetze ermöglicht, die insbesondere paketorien­ tiert arbeiten.

Fig. 1 zeigt in schematischer Darstellung die grundsätzliche Architektur eines UMTS-Funkkommunikationssystems. Nicht ge­ zeigt ist dabei der Übersichtlichkeit halber das sog. Home Location Register HLR als Datenbank, die eine Verbindung zu SGSN und GGSN hat, wie dies in Fig. 15 dargestellt ist. Ebenfalls weggelassen ist das sog. Visitor Location Register VLR, das mit dem Home Location Register HLR verbunden ist. In einem solchen Funknetzwerk FN1 entsprechend Fig. 1 bildet der GGSN den Zugang für externe Netze EN zum UMTS-Funknetz. Am Gateway GGSN sind üblicherweise mehrere übergeordnete Funknetzwerk-Kontrolleinheiten wie z. B. SGSN1 mit SGSGN3 über zugehörige Datenverbindungen LI1G mit LI3G angekoppelt. Diese Kontrolleinheiten SGSN1, SGSN2 sowie SGSN3 sind vorzugsweise für den Verbindungsaufbau im Funknetz FN1 verantwortlich. Je­ de höhere Funknetzwerk-Kontrolleinheit wie z. B. SGSN1 mit SGSN3 steht wiederum über Datenverbindungen wie z. B. LI11, LI21, LI31, LI202, LI503 mit untergeordneten Funknetzwerk- Kontrolleinheit RNC1, RNC2, RNC3, RNC20 sowie RNC50 in Wirk­ verbindung. Diese untergeordneten Funknetzwerkeinheiten wer­ den im UMTS-Standard mit Radio Network Controller bezeichnet. Diese verwalten jeweils die Ressourcen auf der Luftschnitt­ stelle und stellen die Teilverbindung zwischen dem jeweiligen RNC und dem End-Teilnehmergerät her. Jedem Radio Network Controller sind ein oder mehrere Basisstationen zugeordnet, die über jeweils mindestens eine Luftschnittstelle die Funk­ verbindung zu ein oder mehreren Teilnehmergeräten in ihrer jeweiligen Funkzelle bereitstellen.

Im Einzelnen ist an die erste höhere Funknetzwerk- Kontrolleinheit SGSN1 eine Gruppe von 3 untergeordneten Kon­ trolleinheiten, insbesondere Radio Network Controller RNC1, RNC2, RNC3 über entsprechende Datenverbindungen LI11, LI21, LI31 angekoppelt. Die höhere Funknetzwerk-Kontrolleinheit SGSN2 steht in der Fig. 1 lediglich mit der einzelnen untergeordneten Kontrolleinheit RNC20 über die Datenleitung LI202 in Wirkverbindung. Mit der höheren Netzwerkeinheit SGSN3 ist ebenfalls lediglich ein einzelner Radio Network Controller RNC50 über eine Datenleitung LI503 verbunden. An den ersten Radio Network Controller RNC1 sind in der Fig. 1 die beiden Basisstationen BS11, BS12 über zugehörige, separate Datenver­ bindungen LI111*, LI121* angekoppelt. Im Bereich der Funkzel­ len dieser beiden Basisstationen BS11, BS12 halten sich dabei dabei die beiden Teilnehmergerät UE4 und UE5 auf. Dem zweiten Radio Network Controller RNC2. der ebenfalls an derselben hö­ heren Funknetzwerk-Kontrolleinheit SGSN1 hängt, sind eben­ falls 2 Basisstationen BS21, BS22 über entsprechende separate Datenverbindungen LI212*, LI222* zugeordnet. Im Funkzellenbe­ reich der Basisstation BS22 befindet sich dabei im Ausfüh­ rungsbeispiel von Fig. 1 aktuell das Teilnehmergerät UE1. Der dritte Radio Network Controller NNC3, der über die Daten­ verbindung LI31 ebenfalls mit der höheren Kontrolleinheit SGSN1 gekoppelt ist, versorgt schließlich die Basisstation BS31 über eine Datenverbindung LI313*. In der Funkzelle die­ ser Basisstation BS31 hält sich beispielhaft das Teilnehmer­ gerät UE2 auf.

Die 4 Teilnehmergerät UE1, UE2, UE4, UE5 sollen nun als Mul­ ticast-Gruppe A vom externen Netzwerk EN eine Multicast Nach­ richt möglichst effektiv empfangen können. Dazu wird den Kom­ ponenten des Mobilfunknetzes eine erweiterte Funktionalität gegeben sowie zusätzlich mindestens ein sog. Multicast-Center eingeführt. Fig. 2 zeigt ein derart gegenüber Fig. 1 modi­ fiziertes Funknetzwerk FN2 insbesondere für den UMTS- Standard. Das Mobilfunknetz FN2 weist als zusätzliches logi­ sches Netzwerkelement gegenüber dem Funknetzwerk FN1 von Fig. 1 das Multicast-Center MCC auf. Es ist über separate Da­ tenverbindungen wie z. B. LI1C, LI2C, LI3C mit allen höheren Funknetzwerk-Kontrolleinheiten, hier im UMTS insbesondere Serving GPRS Support Nodes wie z. B. SGSN1, SGSN2, SGSN3 ver­ bunden. Dabei können Nachrichten wie in einem IP-Festnetz üb­ lich, auch über mehrere Netzwerkknoten zu den einzelnen Serving GPRS Support Nodes gelangen. Die Funktionalität des Mul­ ticast-Centers umfasst dabei insbesondere die Verwaltung der für das UMTS Mobilfunknetz zur Verfügung gestellte Multicast- Gruppen, d. h. alle zur Verfügung gestellten Multicast-Gruppen und deren Identitäten sind zur Adressierung im Multicast- Sender gespeichert und dort somit bekannt. Die Speicherung der Multicast-Gruppen ist in der Fig. 2 beispielhaft dadurch veranschaulicht, daß das Multicast-Center MCC über eine ge­ strichelt gezeichnete Datenleitung KO4 mit einer externen Speichervorrichtung SP1 verbunden ist. Ebenfalls der Serving GPRS Support Node SGSN1 ist über eine Datenverbindung KO1 mit der Speichervorrichtung SP1 verbunden und hat somit Zugriff auf deren Datenbestände. In dieser Speichervorrichtung SP1 ist unter einer gemeinsamen Identifizierungsadresse IDA die Multicast-Gruppe A abgelegt, die im Ausführungsbeispiel von Fig. 2 aktuell die Teilnehmergeräte UE1, UE2, UE4 und UE5 umfasst. In entsprechender Weise dazu sind in der Speicher­ vorrichtung SP1 auch die Identifizierungsadressen wie z. B. IDB für weitere Multicast-Gruppen abgespeichert. Mit dieser Speichervorrichtung SP1 sind vorzugsweise auch alle anderen höheren Funknetzwerk-Kontrolleinheiten, insbesondere Serving GPRS Support Nodes verbunden. In der Fig. 2 ist im einzelnen der Serving GPRS Support Node SGSN2 über eine Datenverbindung KO2, sowie der Support Node SGSN3 über eine Datenverbindung KO3 an die Speichervorrichtung SP1 angekoppelt. Die Speicher­ vorrichtung SP1 wird also vorzugsweise als zentral geführte Datenbank betrieben. Selbstverständlich kann es auch zweckmä­ ßig sein, mehrere solche Speichervorrichtungen im Funknetz FN2 vorzusehen. Die Datenverwaltung der Multicast-Gruppen wird dabei ebenfalls zweckmäßigerweise zentralisiert als eine logische Einheit vorgenommen.

Gegebenenfalls kann es auch zweckmäßig sein, solche Speicher­ vorrichtungen zum Ablegen der Identifizierungsadressen für die Multicast-Gruppen sowie deren spezifischen Teilnehmerein­ träge nicht als externe, eigenständige Komponenten im Netz zu installieren, sondern im Multicast-Center selbst sowie in der jeweiligen höheren Funknetzwerk-Kontrolleinheit, insbesondere im jeweiligen Serving GPRS Support Node zu integrieren (und nicht wie in Fig. 2 als separate Datenbank auszubilden).

Neben der Verwaltung der Multicast-Gruppen-Einträge fungiert das Multicast-Center MCC zusätzlich auch als Quelle für alle Multicast-Nachrichten.

Die Fig. 3 mit 5 stellen schematisch den zeitlichen Ablauf eines logischen Verbindungsaufbaus beispielhaft ausgehend vom externen Netzwerk EN zum Teilnehmergerät UE4 dar. Es wird vorausgesetzt, dass sich das Teilnehmergerät UE4 bereits im Funknetzwerk FN2 registriert hat, momentan jedoch keinen PDP Context (Paket Data Protokoll) und keine aktive logische Übertragungsverbindung zum Funknetz FN2 hat. Kommt nun ein Datenpaket PK4 für das Teilnehmergerät UE4 vom externen Pa­ ketdatennetz EN, so wird mit dem Datenpaket PK4 eine Identi­ fikation des Teilnehmergeräts UE4 mitgeliefert. GGSN von Fig. 3 kennt nun entweder den SGSN an, an dem das Teilnehmer­ gerät UE4 registriert ist, oder erfragt diese in der nicht eingezeichneten Datenbank HLR. In diesem Ausführungsbeispiel wird angenommen, das der GGSN weiß, dass das Teilnehmergerät UE4 am Support Node SGSN1 registriert ist. Daraufhin sendet der GGSN dem SGSN1 eine Mitteilung MPK4, dass ein Datenpaket PK4 für das Teilnehmergerät UE4 im GGSN angekommen ist. Der Support Node SGSN1 kennt im allgemeinen die sog. Routing A­ rea, in der das Teilnehmergerät UE4 vermutet wird. Diese Rou­ ting-Area kann dabei mehrere Radio Network Controller umfas­ sen. Der Support Node SGSN1 sendet daraufhin eine Anfrage RQ1, RQ2, RQ3 an alle in Frage kommenden Radio Network Cont­ roller, hier RNC1, RNC2, RNC3, ob sich das Teilnehmergerät UE4 in den von den Radio Network Controllern verwalteten Funkzellen befindet (= Paging Request). Die Radio Network Controller RNC1, RNC2, RNC3 senden daraufhin eine Anfrage IF1, IF2, IF3 in alle von ihnen verwaltete Funkzellen (= Paging). Das Teilnehmergerät UE4 meldet sich daraufhin beim entsprechenden Radio Network Controller RNC1. Der Radio Network Controller RNC1 teilt dann seiner übergeordneten Kon­ trolleinheit SGSN1 mit, dass das Teilnehmergerät UE4 sich in seinem Bereich befindet. Dies ist in der Fig. 4 durch das Antwortsignal RE1 angedeutet. Die übermittelten Signale sind dabei in den Fig. 3 mit 5 jeweils durch dicker ausgezogene Pfeile veranschaulicht. Auf dieses Antwortsignal RE1 hin, baut nun der SGSN1 logische Übertragungsverbindungen zum GGSN (core network bearer) und RNC1 (Iu-Baerer) auf, die nur Daten für das Teilnehmergerät UE4 transportieren. Die logische Ü­ bertragungsverbindung wird mit einem sog. PDP Context be­ schrieben, der alle notwendigen Daten der Verbindung zwischen dem Teilnehmergerät und dem GGSN beinhaltet. Jeder logischen Übertragungsverbindung zwischen dem jeweiligen SGSN und GGSN ist dabei genau eine logische Übertragungsverbindung zwischen SGSN und RNC zugewiesen, welcher wiederum genau eine logische Übertragungsverbindung zwischen RNC und dem Teilnehmergerät zugeordnet ist. Im SGSN und RNC bestehen somit feste Abbil­ dungen der logischen Übertragungsverbindungen, wodurch z. B. SGSN weiß, über welche logische Übertragungsverbindung (und somit auch an welchen RNC) er eine Nachricht an das jeweilige Teilnehmergerät weiterleiten muss, wenn er die Nachricht über eine bestimmte logische Übertragungsverbindung von einem GGSN bekommt. In der Fig. 5 ist der komplette Übertragungspfad vom GGSN zum SGSN1, weiter zum RNC1, der Basisstation BS12 und schließlich zum End-Teilnehmergerät UE4 durch einen di­ cker ausgezogenen Pfeil UP11 angedeutet.

Fig. 6 zeigt die Übertragungsverbindungen mehrerer Teilneh­ mergeräte in einem Funkkommunikationssystem FN1 entsprechend Fig. 1. Jedes Teilnehmergerät hat für jede ihm zugeordnete Übertragungsverbindung einen PTP Context. Selbst wenn die Nachrichten, die aus dem externen Netzwerk EN an die Teilneh­ mergerät UE1, UE2 und UE4, UE5 gesendet werden sollen, exakt gleich sind, ist es erforderlich, die Nachrichten an jeden Nutzer extra separat zu schicken, auch wenn die physikali­ schen Verbindungen die gleichen sind. Dies ist in der Praxis zu aufwendig und belegt zu viele Ressourcen. Denn zwischen allen Netzwerkkomponenten wird jeweils eine feste Abbildung von Nutzeridentifikationen auf logische Verbindungen durchge­ führt, d. h. für jeden einzelnen Teilnehmer wird eigens eine Verbindung aufgebaut. Für die 4 Teilnehmergeräte UE1, UE2, UE4, UE5 der MULTICASTGRUPPE a werden somit im Ausführungs­ beispiel von Fig. 6 insgesamt 4 komplette Übertragungspfade belegt, die vom externen Netzwerk EN über den GGSN, SGSN1 so­ wie den zugeordneten Radio Network Controllern RNC1, RNC2, RNC3 bis zu den Endteilnehmergeräten durchgehend aufgebaut werden.

Fig. 7 veranschaulicht, wie Multicast Nachrichten vom Multi­ cast-Sender MCC zu den Teilnehmergeräten UE1, UE2, UE4, UE5 gesendet würden, wenn man das Konzept nach Fig. 6 der festen Zuweisung von logischen Kanälen zu Teilnehmergeräten hier e­ benfalls anwenden würde. Obwohl Multicast-Nachrichten, die von Multicast-Sender MCC gesendet werden, für alle zu benach­ richtigenden Teilnehmergeräte gleich sind, müssten sie den­ noch für jeden Nutzer einzeln zwischen Multicast-Sender MCC und SGSN1, SGSN1 und RNC1/RNC2/RNC3, und RNCs und den End­ teilnehmergeräten UE1, UE2, UE4, UE5 gesendet werden. Dies bedeutet allgemein ausgedrückt, dass so viele Einzelverbin­ dungspfade aufgebaut werden müssten, wie Endteilnehmergeräte durch die Multicast Nachricht zu benachrichtigen wären. Dies wäre zu aufwendig und nicht ausreichend effizient.

Um eine effizientere Verteilung von Gruppennachrichten im Funkkommunikationsnetz FN2 von Fig. 2 zu ermöglichen, wird nach einer ersten Variante des erfindungsgemäßen Verfahrens zweckmäßigerweise folgendermaßen entsprechend den Fig. 8 mit 10 vorgegangen:
Das Multicast Center MCC sendet eine Multicast Nachricht GN1 für die Multicastgruppe A an alle SGSNs (der Einfachheit hal­ ber wird im weiteren nur SGSN1 betrachtet; entsprechendes gilt für die übrigen SGSN's)

• - SGSN1 hat nun erfindungsgemäß eine neue Funktionalität und erkennt an Hand der mitgesendeten Multicast Gruppen Identi­ tät, daß es sich bei der Nachricht um eine Multicast Nach­ richt handelt.
• - Erfindungsgemäß hat der SGSN1 die Multicast Gruppenzugehö­ rigkeiten aller bei ihm registrierten Nutzer gespeichert, o­ der die Multicast Gruppenzugehörigkeiten werden in der HLR Datenbank gespeichert und nun von SGSN dort erfragt. (siehe EM).
• - Es wird angenommen, daß Nutzer UE1, UE2 und UE4, UE5 zu der Multicast-Gruppe A gehören. Weiterhin wird angenommen, daß diese Nutzer keine aktive Verbindung habe.
• - SGSN1 kennt die Routing Areas in denen sich die Nutzer auf­ halten könnten. Eine Routing Area kann mehrere RNCs umfassen.
• - SGSN1 sendet nun entweder 1 Anfrage AF pro Nutzer (hier al­ so 4) an alle in Frage kommenden RNCs, ob der Nutzer sich in einer von diesen verwalteten RNCs befindet. Die Anfrage AF ist in der Fig. 8 durch dicker eingezeichnete Pfeile ange­ deutet. Wenn die Routing Areas gleich sind, kann erfindungs­ gemäß auch eine Anfrage mit einer Liste von Nutzern an die RNCs gesendet werden.
• - Die RNCs fragen wiederum in den von ihnen verwalteten Funk­ zellen an, ob sich einer der zu benachrichtigenden Teilneh­ mergeräte der Multicast-Gruppe A dort befindet. (Gemeinsame Anfrage für mehrere Nutzer ist möglich).
• - Die Nutzer melden sich bei den entsprechenden RNCs, welche wiederum die bei ihnen lokalisierten Nutzer zum SGSN1 melden, was in Fig. 9 durch dick eingezeichnete Pfeile RM angedeutet ist.
• - SGSN1 weiß nun, daß sich am RNC1 Nutzer UE4 und UE5, am RNC2 Nutzer UE1 und an RNC3 Nutzer UE2 befindet.
• - Erfindungsgemäß wird nun zu jedem RNC, bei dem sich ein Nutzer dieser Multicast Gruppe befindet, genau eine Übertra­ gungsverbindung aufgebaut.
• - Zu jedem Nutzer wird zwischen SGSN und Nutzer erfindungsge­ mäß ein Multicast Context aufgebaut, der, wie der PDP Con­ text, die Verbindung beschreibt.

Der Unterschied zum PDP Context liegt dabei darin, daß ein Multicast Context nicht fest einer Verbindung zugeordnet wird, sondern mehrere Multicast Contexte sich eine bzw. Teile der logischen Übertragungsverbindung gemeinsam nutzen. Ein Multicast Context ist jedoch ebenfalls nur genau einem Nutzer zugewiesen.

• - Jeder SGSN wird dafür erweitert, daß er einer Übertragungs­ verbindung mehrere MC Contexte zuordnen kann. Dafür muß der SGSN auch die Liste der Nutzer oder Multicast Contexte spei­ chern, die diesem Iu-Bearer zugeordnet sind.
• - Jeder RNC wird ebenfalls erweitert, um es zu ermöglichen, die Daten nach dem RNC über einem Nutzer zugeordnete Übertra­ gungsverbindungen weiterzuleiten, d. h. also die Nachricht vervielfältigen und an jeden Nutzer einzeln zu schicken. Da­ für wird dem jeweiligen RNC beim Verbindungsaufbau des Iu- Bearers eine Liste der Identitäten der Nutzer oder Multicast Contexte mitgeliefert, die dem Iu-Bearer zugeordnet sind. Diese Liste wird im RNC gespeichert.
• - jeder RNC baut für jeden Nutzer, der sich in von ihm ver­ walteten Zellen befindet, eine Übertragungsverbindung auf.

Es besteht damit eine feste Abbildung einer Multicast Gruppe auf mehrere Iu-Bearer, jedoch maximal 1 (= ein einziger) Iu- Bearer pro RNC. Außerdem besteht eine feste Abbildung eines Iu-Bearers auf mehrere Radio Bearer.

Fig. 11 veranschaulicht noch einmal den detaillierten Ablauf eines solchen Verbindungsaufbaus beispielhaft für das Teil­ nehmergerät UE4. Es wird davon ausgegangen, dass sich das Teilnehmergerät UE4 zunächst im Idle-Mode befindet, d. h. zwar eingeschaltet ist, aber keine aktive Verbindung zum Funknetz FN2 aufweist. Kommt nun vom Multicast-Center MCC eine Multi­ cast Nachricht MC-Message, so wird in der dem Support Node SGSN1 zugeordneten Speichervorrichtung die Multicast-Gruppe identifiziert, an die die Multicast Nachricht gerichtet ist. Damit ist dem SGSN1 bekannt, welche Mitglieder dieser Multi­ cast-Gruppe die Multicast Nachricht erhalten sollen. Der SGSN1 initiiert daraufhin ein Paging für die jeweilig zu be­ nachrichtigenden Teilnehmergeräte dieser Gruppe. Dazu wird an alle an den SGN1 angekoppelten RNCs ein Anfragesignal gesen­ det, ob sich in ihren Funkzellenbereichen die Teilnehmergerät UE1, UE2, UE4, UE5 aufhalten. Die Radio Network Controller senden diese Paging-Signale über ihre zugehörigen Basisstati­ onen in ihre zu versorgenden Funkzellenbereiche aus. Befindet sich eines der zu benachrichtigenden Teilnehmergeräte im Ver­ sorgungsbereich dieser Radio Network Controller, so schalten diese Teilnehmergeräte vom Idle-Mode auf dem Connected-Mode um, d. h. es wird eine aktive Verbindung RRC-Connection Mel­ dung (Radio Resource Control) zurück an den jeweiligen Radio Network Controller geschickt. Derjenige Radio Network Cont­ roller - hier RNC1 -, der von seiner jeweiligen Basisstation gemeldet bekommt, dass sich in deren Funkzelle ein zu benach­ richtigendes Teilnehmergerät aufhält, macht dies auch der ü­ bergeordneten Kontrolleinheit - hier SGSN1 - bekannt. Diese fordert dann entsprechend dem Ablaufpunkt 6 von Fig. 11 vom jeweiligen Teilnehmergerät wie z. B. UE4 den Multicast-Context an, um eine Wegbeschreibung zum Endteilnehmergerät entspre­ chend Punkt 7 zurückzuerhalten. In der unteren Bildhälfte von Fig. 11 ist unterhalb der gestrichelten Linie der Zustand dargestellt, ab oder bei dem sich die Teilnehmergeräte UE4 und UE5 bereits im Connected-Mode befinden. Dies entspricht dem Endzustand nach der Signalisierung des Ablaufpunktes 7. "Aktivate Multicast-Context-Request". Da nun die übergeordne­ te Kontrolleinheit SGSN1 weiß, welche Radio Network Control­ ler zuständig sind für die zu benachrichtigenden Teilnehmer­ geräte, und ein entsprechender Multicast-Context zum Verbin­ dungsaufbau zum jeweiligen Teilnehmergerät zur Verfügung steht, wird nun vom Suppord Node SGSN1 ein Verbindungsaufbau zu den zu benachrichtigenden Teilnehmergeräten - hier UE4 - initiiert. Dazu wird entsprechend Ablaufpunkt 8 ein Iu-Baerer zwischen dem RNC1 und dem SGSN1 aufgebaut. Zusätzlich wird die Information mitgegeben, dass der Iu-Baerer für den Teil­ nehmer UE4 und UE5 besteht. Daraufhin wird zwischen dem RNC1 und den Endteilnehmergeräten UE4 und UE5 jeweils ein Radio- Baerer entsprechend dem Ablaufpunkt 9 aufgebaut und dies ent­ sprechend dem Ablaufpunkt 10 dem Radio Network Controller RNC1 bestätigt. Damit konnten Radio-Baerer zu allen Endteil­ nehmergeräten - hier UE4, UE5 -, die am Radio Network Cont­ roller RNC1 angekoppelt sind, aufgebaut werden. Gleichzeitig wird die Abbildung von einem einzelnen Iu-Baerer zwischen dem Radio Network Controller RNC1 und der übergeordneten Kon­ trolleinheit SGSN1 auf mehrere Radio-Baerer zwischen Radio Network Controller RNC1 und den Endteilnehmergeräten UE4, UE5 im Radio Network Controller RNC1 gespeichert. Dieser bestä­ tigt den Aufbau des Iu-Baerers nach Ablaufpunkt 11. Daraufhin sendet der Support Node SGSN1 ein Bestätigungssignal Aktivate Multicast Context Exept nach Ablaufpunkt 12 an den jeweiligen Endteilnehmer UE4 bzw. UE5. Schließlich wird über den aufge­ bauten Übertragungspfad die Multicast Nachricht vom SGSN1 an die Endteilnehmergeräte UE4, UE5 übertragen.

Bei dem Übertragungskonzept entsprechend den Fig. 10 und 11 wird also zusammenfassend betrachtet zunächst die Multi­ cast Nachricht für die Multicast-Gruppe A an den Support Node SGSN1 übertragen. Der Support Node SGSN1 kennt aufgrund sei­ ner Speicherzugriffsmöglichkeit diejenigen Radio Network Controller und die logischen Übertragungsverbindung (Iu- Bearer), die für Nachrichten der Multicast-Gruppe A aufgebaut wurden, und sendet die Multicast Nachricht nur einmal zu je­ dem der Radio Network Controller, mit denen ein Nutzer dieser Multicast-Gruppe verbunden ist. Der jeweilige Radio Network Controller kennt die Nutzer der Multicast-Gruppe A und die logischen Übertragungsverbindungen zu den Nutzern (Radio Bae­ rer), die mit dem Iu-Baerer also der am RNC ankommenden Ver­ bindung verknüpft sind. Der jeweilige Radio Network Control­ ler sendet nun die Multicast Nachricht der Multicast-Gruppe A über die aufgebauten Verbindungen (Radio Baerer) für jeden Nutzer einmal. Obwohl also hier im Ausführungsbeispiel von Fig. 10 vom Radio Network Controller RNC1 mehrere Teilneh­ mergeräte UE4, UE5 versorgt werden, wird lediglich ein ein­ zelner Übertragungspfad zwischen dem Radio Network Controller RNC1 und dem übergeordneten Support Node SGSN1 aufgebaut und benutzt. Dies ermöglicht eine effiziente Verteilung der Mul­ ticast Nachricht GN1.

Fig. 12 zeigt eine weitere Variante zur erfindungsgemäßen Verteilung von Multicast Nachrichten zwischen dem Multicast- Sender MCC und den zu benachrichtigenden Endteilnehmergeräten einer bestimmten Multicast-Gruppe wie z. B. A. Vom Support No­ de SGSN1 wurde wie in Fig. 10 zum RNC1 ebenfalls eine logi­ sche Übertragungsverbindung (Iu-Baerer) pro Nutzer aufgebaut. Des Multicast-Center MCC sendet dabei die Multicast Nachricht GN1 vorzugsweise nur einmal. Der Support Node SGSN1 kennt er­ findungsgemäß die Teilnehmergeräte dieser Multicast-Gruppe A aufgrund seiner Zugriffsmöglichkeit in die Speichervorrich­ tung SP1 von Fig. 2 und damit die zugehörigen logischen Ü­ bertragungsverbindungen zu den Radio Network Controllern. Der Support Node SGSN1 vervielfältigt die eingehende Multicast Nachricht GN1 und sendet diese Nachricht jeweils einmal pro Teilnehmergerät an die entsprechenden Radio Network Control­ ler RNC1, RNC2, RNC3. Da am Radio Network Controller RNC1 hier im Ausführungsbeispiel 2, d. h. allgemein ausgedrückt mehrere Teilnehmer hängen, werden entsprechen viele logische Übertragungsverbindungen zu Übermittlung der Grupppennach­ richt GN1 bereitgestellt zwischen den Support Node SGSN1 und dem Radio Network Controller RNC1. Im Einzelnen heißt das, dass ein Übertragungspfad UP11* zwischen den Support Node SGSN1 und dem Radio Network Controller RNC1 für das Teilneh­ mergerät UE4 sowie ein weiterer, zweiter Übertragungspfad UP11** für das Teilnehmergerät UE5 abgestellt wird. Vorteil­ haft bei dieser Übertragungsvariante ist insbesondere: Es ist keine neue Funktionalität im jeweiligen Radio Network Cont­ roller erforderlich. Die übergeordente Funknetzwerk- Kontrolleinheit SGSN1 kann weiterhin ähnlich dem PDP Context eine Verbindung pro Nutzer aufbauen. Für die übergeordnete Funknetzwerk-Kontrolleinheit SGSN1 und dem jeweiligen Radio Network Controller ist es nicht erforderlich, eine Liste der Multicast-Context bzw. Teilnehmergeräte der jeweilig zu be­ nachrichtigenden Multicast-Gruppe zu führen, die zu einer lo­ gischen Übertragungsverbindung gehören. Auf diese Weise ist eine Umänderung der Signalisierung zwischen den Netzwerkkom­ ponenten bestehender Mobilfunknetze weitgehend vermieden. Le­ diglich die Einführung eines Multicast-Senders sowie einer zentral geführten Datenbank für die Multicast-Gruppen ist zur Durchführung des erfindungsgemäßen Verfahrens zweckmäßig.

Fig. 13 zeigt diesen Verbindungsaufbau passend zu Fig. 12 nochmals im Detail. Änderungen gegenüber dem Verfahren von Fig. 11 sind jeweils grau unterlegt gezeichnet.

Fig. 14 zeigt schließlich einen Registrierungsprozess bei­ spielhaft für Teilnehmergerät UE4. Schaltet das Teilnehmerge­ rät UE4 sein Mobilfunkgerät an, wird zunächst eine Radio Re­ source Controll Verbindung zum Radio Network Controller RNC1 aufgebaut. Anschließend authentifiziert sich das Teilnehmer­ gerät UE4 am Support Node SGSN1. Dabei wird bei der Authenti­ fizierung die Multicast-Gruppenzugehörigkeit des Teilnehmer­ geräts UE4 zum Support Node SGSN1 übertragen. Der Support No­ de SGSN1 speichert diese Informationen in einer internen oder externen Datenbank. Alternativ können die Informationen auch an eine externe Datenbank wie z. B. einem erweiterten Home Lo­ cation Register HLR weitergeleitet werden. Dafür wird eine Identifikation des Teilnehmergeräts UE4 sowie Identifikatio­ nen der Multicast-Gruppen dieses Teilnehmergeräts an eine solche Datenbank gesendet.

Zusammenfassend betrachtet sind somit folgende Schritte zum effizienten Verteilen von Multicast Nachrichten in einem Funkkommunikationssystem vorteilhaft:

• 1. Einführung eines logischen Netzwerkelementes "Multicast Center":
  Das Multicast Center hat die Aufgabe, die Multicast Grup­ pen zu verwalten, die Informationen für die Multicast Gruppen bereitzustellen und sie an alle SGSNs im UMTS Netzwerk zu senden. Dazu speichert es zweckmäßigerweise auch eine Identität einer Multicast Gruppe, die im gesam­ ten Netzwerk eindeutig ist.
• 2. Erweiterung der SGSN Funktionalität um die Fähigkeit zu erkennen, daß es sich bei einer empfangenen Nachricht um eine Multicast Nachricht handelt.
• 3. Erweiterung des SGSN um die Fähigkeit, Multicast Gruppen­ zugehörigkeiten der an dem SGSN registrierten Nutzer zu speichern.
• 4. Alternativ zu 3. kann die Gruppenzugehörigkeitsinformation auch in einer externen Datenbank (z. B. HLR) gespeichert werden. Dazu wird die HLR Funktionalität zweckmäßigerweise erweitert. Außerdem wird der SGSN zweckmäßigerweise die zusätzliche Fähigkeit gegeben, die Gruppenzugehörigkeiten bei der externen Datenbank zu erfragen.
• 5. Erweiterung der SGSN Funktionalität durch die Fähigkeit, Daten zu speichern, die eine für einen nutzerspezifische Verbindung zum SGSN beschreiben. Diese Daten werden im weiteren Multicast Contexte genannt.
• 6. Erfindungsgemäß gehören zum Multicast Context mindestens eine Identifikation des Nutzers und eine Identifikation der Multicast Gruppe.
• 7. Erweiterung der SGSN Funktionalität durch die Fähigkeit, eine logische Übertragungsverbindung für mehrere Multicast Contexte zwischen SGSN und RNC aufzubauen, die zur selben Multicast Gruppe gehören und die Liste der Multicast Con­ texte dieser Übertragungsverbindung zu speichern und zu aktualisieren (wenn z. B. ein Nutzer den RNC wechselt).
• 8. Erweiterung der RNC Funktionalität durch die Fähigkeit, eine Liste der Multicast Contexte bzw. Nutzer zu speichern und zu aktualisieren, die zu einer logischen Verbindung zwischen RNC und SGSN gehören.
• 9. Erweiterung der RNC Funktionalität durch die Fähigkeit ei­ ne logische Übertragungsverbindung zwischen RNC und SGSN (Iu-Bearer) auf mehrere logische Übertragungsverbindungen zwischen RNC und Nutzer bzw. UE (Radio Bearer) abzubilden.
• 10. Hinzufügen der Multicast-Gruppenzugehörigkeit eines Nut­ zers in die Registrierungsnachricht, damit diese im SGSN gespeichert werden kann, bzw. vom SGSN an eine externe Da­ tenbank (z. B.) HLR weitergeleitet werden kann, wo sie dann gespeichert wird.

Im Weiteren wird auf die Einführung der effizienten Vertei­ lung von Multicast Nachricht insbesondere im Hinblick auf UNTS eingegangen:

1. Eintrag der MC-Gruppenzugehörigkeit in eine Datenbank

Das im Internet verwendete Protokoll IGMP zur Erfassung der Teilnehmer von Multicast-Gruppen ist für UMTS nicht gut ge­ eignet. Durch das "Nachfragen" (Query, Report) nach der Mul­ ticast-Gruppenzugehörigkeit bei allen Hosts, somit also auch bei solchen, die keine Teilnehmer der entsprechenden Multi­ cast-Gruppe enthalten, kommt es zu zusätzlicher Übertragungs- Komplexität und somit erhöhtem Bandbreitebedarf.

Im Rahmen dieser Erfindung soll der Eintrag der Zugehörigkeit von Teilnehmern zu Multicast-Gruppen in eine zentrale Daten­ bank vorgenommen werden (Fig. 19). Im UMTS-Corenetwork kann dafür möglicherweise das HLR, HSS (home subscriber server), VLR, der SGSN oder der GGSN verwendet werden.

Teilnehmer, die zu einer bestimmten Multicast-Gruppe beitre­ ten oder diese verlassen wollen, senden eine Nachricht, even­ tuell über verschiedene Netzwerkknoten, entweder direkt an die Datenbank oder an einen Netzwerkknoten, der wiederum den Eintrag in die Datenbank vornimmt. Der Netzwerkknoten, der die Eintragung in die Datenbank vornehmen soll, kann bei­ spielsweise der SGSN sein.

Kommt es nun zur Übertragung einer Multicast-Nachricht, er­ folgt zuerst eine Anfrage an diese Datenbank, ob und welche Teilnehmer der entsprechenden Multicast-Gruppe angehören.

Der Vorteil dieses Verfahrens ist, dass die Zugehörigkeit von Teilnehmern zu Multicast-Gruppen aus einer zentralen Daten­ bank erfragt werden kann.

Zusätzliche Übertragungskomplexität und der so entstehende zusätzliche Bandbreitebedarf wie für das IGMP, wie es bei­ spielsweise im Internet praktiziert wird, wird so vermieden.

Der Eintrag in die Datenbank kann ggf. auch getrennt vom UMTS-Netzwerk beispielsweise durch den Netzbetreiber durch­ geführt werden.

Ausführungsbeispiel

Für das Ausführungsbeispiel wird angenommen, dass sich Teil­ nehmer X bei einer Multicast-Gruppe anmelden will. Mit Hilfe einer entsprechenden Applikation generiert er eine Registrie­ rungs-Anforderung (Subscriber-Nachricht), welche mind. seine Identität (IMSI, IP-Adresse o. ä.) und die MC-Adresse der ent­ sprechende Multicast-Gruppe enthält. Diese Subscriber- Nachricht sendet er nun über den RNC zum SGSN (Serving GPRS Support Node).

Der SGSN erkennt, dass es sich um eine Registrierungs- Anforderung handelt und veranlasst einen Eintrag in die zent­ rale Datenbank.

Die Adressen der Teilnehmer der entsprechenden MC-Gruppen können für den Transport der MC-Nachrichten zu den Teilneh­ mern aus der Datenbank abgefragt werden. Dort erfolgt ein Mapping von Teilnehmer auf Multicast-Gruppe bzw. Mulitcast- Gruppe auf Teilnehmer. Mit Hilfe dieser Information aus der Datenbank in Kombination mit der Location Information aus dem SGSN, welcher RNC den MC-Teilnehmer bedient, können nun die MC-Nachrichten zu den entsprechenden SRNC und daraufhin zu den MC-Teilnehmern übertragen werden.

2. MC-Context activation

Nach dem Einschalten eines UE wird als erstes eine Registrie­ rungs- und Authentifizierungsprozedur eingeleitet. Dafür geht das UE zuerst in den Connected Mode über. Über den Aufbau ei­ ner RRC-Connection zum RNC und einer Signalisierung zum SGSN macht sich das UE beim SGSN bekannt.

Dem SGSN ist nun unter anderem die Identität des UE und des RNC bekannt, der das entsprechende UE versorgt.

Kommt es zu keinen weiteren Aktionen des UE (Gesprächsaufbau, Datenübertragung etc.) so fällt es in den Idle-Mode. Sämtli­ che Verbindungen werden abgebaut und der SGSN hat lediglich Information über die Identität des UE und die Routing-Area in der es sich befindet.

Das hier vorgestellte Verfahren, bezeichnet als "Multicast- Context activation", beschreibt den Prozessablauf, wie sich ein UE mit seinen MC-Gruppenzugehörigkeiten beim SGSN bekannt macht.

Nach dieser Prozedur sind dem SGSN wie bisher die Identität und die Location Information, zusätzlich nun aber auch die MC-Gruppenzugehörigkeiten des UE bekannt.

Eine Möglichkeit zur Aktivierung eines MC-Contextes ist, dass ein UE beim Einschalten und der darauf folgenden Registrie­ rungs- und Authentifizierungsprozedur jedes Mal standardmäßig (default) seine MC-Gruppenzugehörigkeit zum SGSN mit über trägt (Fig. 20). Diese Informationen werden im SGSN gespei­ chert und bilden den MC-Context.

Fällt das UE daraufhin in den Idle-Mode (im Falle keiner wei­ teren Aktionen des UE), so muss der SGSN neben den Informati­ onen über die Identität und die Routing-Area des UE nun auch die MC-Gruppenzugehörigkeits-Informationen speichern.

Denkbar ist auch der Fall, dass die MC-Gruppenzugehörigkeits- Information nach dem Einschalten eines UE und der darauf fol­ genden Registrierungs- und Authentifizierungsprozedur stan­ dardmäßig (default) vom SGSN aus einer Datenbank (siehe Ein­ trag der MC-Gruppenzugehörigkeit in eine Datenbank) abgefragt wird (Fig. 21). Diese Informationen werden im SGSN gespei­ chert und bilden den MC-Context.

Fällt das UE daraufhin in den Idle-Mode (im Falle keiner wei­ teren Aktionen des UE), so speichert der SGSN neben den In­ formationen über die Identität und die Routing-Area des UE nun auch die MC-Gruppenzugehörigkeits-Informationen.

Eine weitere Möglichkeit ist, dass die MC- Gruppenzugehörigkeits-Information beim Eintreffen einer MC- Message bzw. eines MC-Message-Request vom SGSN aus einer Da­ tenbank (siehe Eintrag der MC-Gruppenzugehörigkeit in eine Datenbank) abgefragt wird (Fig. 22). Diese Informationen werden im SGSN gespeichert und bilden den MC-Context. Vorteil dieser Variante ist, dass die MC- Gruppenzugehörigkeits-Information nicht ständig im SGSN ge­ speichert werden muss, sondern nur dann, wenn MC-Nachrichten eintreffen bzw. übertragen werden.

Damit die MC-Gruppenzugehörigkeits-Information aber nicht bei jeder einzelnen MC-Nachricht einer bestimmten Gruppe oder so­ gar bei jedem einzelnen IF-Packet einer MC-Nachricht neu ab­ gefragt werden muss, kann ein Timer initialisiert werden.

Kommt es nun zu einer erneuten Übertragung einer MC- Nachricht, bevor der Timer abgelaufen ist, so muß die MC- Gruppenzugehörigkeits-Information nicht erneut abgefragt wer­ den, da die Informationen während der Laufzeit des Timers ge­ speichert wird.

Grundsätzlich kommt es zu einem Update der MC- Gruppenzugehörigkeits-Information im SGSN, wenn sich neue Mitglieder zu einer MC-Gruppe anmelden bzw. diese verlassen (siehe dazu Abschnitt 1. Eintrag der MC-Gruppenzugehörigkeit in eine Datenbank).

3. Aufbau der Verbindungswege und Übertragung der MC- Nachrichten I. Ausführungsbeispiel

Für dieses Beispiel wird angenommen, dass eine MC-Nachricht im IP-MC-Center (MCC) generiert wurde und nun zu den Teilneh­ mern dieser MC-Gruppe gesendet werden soll. Diese MC- Nachricht ist mit der MC-Adresse der entsprechenden MC-Gruppe adressiert. Das IP-Multicast-Center hat die Funktionalität eines IP-MC-Routers.

Die MC-Nachricht wird nun zu allen SGSNs gesendet (1. in Fig. 23). Aufgrund der Aktivierung des MC-Kontextes (siehe Ab­ schnitt 2. MC-Context activation) sind dem SGSN die UEs und ihre MC-Gruppenzugehörigkeiten bekannt. Das SGSN kennt die UE5, die die MC-Nachricht erhalten sollen und deren Routing Areas (RA), in denen sich die UEs befinden.

Befindet sich ein UE, das Mitglied der entsprechenden MC- Gruppe ist, im Idle-Mode, so wird nun vom SGSN ein MC- Message-Request an alle RNCs in der ihm bekannten Routing A­ rea gesendet (2. in Fig. 23). Dieser MC-Msg.-Request bein­ haltet die Identität der UEs (z. B. IMSI. IP-Adresse o. ä.) und die MC-Adresse der entsprechenden MC-Gruppe.

Die RNCs führen daraufhin ein Paging der UEs durch, die im MC-Msg.-Request benannt sind (3. in Fig. 23).

Diese UEs bauen nun eine RRC-Connection und Radio Bearer (RB) zum RNC auf und befinden sich daraufhin im Connected Mode (4. in Fig. 23).

Befindet sich ein UE, das Mitglied der entsprechenden MC- Gruppe ist, bereits im Connected-Mode, so wird ein MC-Msg.- Request von SGSN über die RNCs zu den entsprechenden UEs, welche Mitglieder der MC-Gruppe sind, gesendet (5. in Fig. 23). Dieser MC-Msg.-Request beinhaltet die Identität der UEs (z. B. IMSI. IP-Adresse o. ä.) und die MC-Adresse der entspre­ chenden MC-Gruppe.

Da sich die UEs bereits im Connected Mode befinden (RRC Con­ nection besteht), müssen nun (soweit noch nicht vorhanden) Radio Bearer (RB) zum RNC aufgebaut werden (6. in Fig. 23).

Nachdem sich nun alle UEs der MC-Gruppe im Connected Mode be­ finden und sowohl eine RRC-Connection als auch Radio Bearer aufgebaut sind, wird nun von jedem RNC, der Mitglieder der MC-Gruppe versorgt, zum SGSN ein MC-Bearer pro RNC aufgebaut (7. in Fig. 23). Ein MC-Msg.-Confirm., der vom RNC über die­ se MC-Bearer gesendet wird, gibt nun dem SGSN die Bereit­ schaft der UEs kund, MC-Nachrichten empfangen zu können. Der SGSN hat nun die Informationen, wo sich die UEs der MC- Gruppe befinden und kann nun die MC-Nachricht über die zuvor aufgebauten MC-Bearer zu dem entsprechenden RNCs senden (8. in Fig. 23).

Mit der Mapping-Information (UE/MC-Gruppe) aus dem MC-Msg.- Request kann die MC-Nachricht nun zu den UEs der MC-Gruppe übertragen werden (9. in Fig. 23).

Ein SGSN, der eine MC-Nachricht für eine bestimmte MC-Gruppe bekommt aber keine Mitglieder dieser MC-Gruppe versorgt, be­ nötigt diese Nachricht nicht und kann sie verwerfen.

Eine weitere Möglichkeit ist, dass der SGSN, sofern er keine Mitglieder der MC-Gruppe besitzt, eine Prune-Nachricht (Vergl. RPM) an das IP-Multicast-Center zurück sendet. Dieser SGSN erhält dann solange keine MC-Nachrichten für die MC- Gruppe, bis:

• - der SGSN an das IP-MC-Center eine Join-Nachricht sendet, die den Eintritt eines Teilnehmers in eine MC-Gruppe sig­ nalisiert (event-triggered).
• - ein zuvor festgelegter Timer abgelaufen ist.

Denkbar ist auch der Fall, dass die MC-Nachricht, nachdem sie im MCC generiert wurde, nicht sofort an alle SGSNs gesendet wird (Vergl. 1. in Fig. 23). Stattdessen kann auch zuerst ein MC-Message-Request zu den SGSNs gesendet werden (1. in Fig. 24).

Die weiteren Prozeduren zum Aufbau der Verbindungen für die Übertragung der MC-Nachricht vom SGSN zu den UEs der MC- Gruppe-Teilnehmer bleiben dann gleich (2. bis 7. in Fig. 24).

Nachdem dann der MC-Msg.-Req. beim SGSN eingegangen ist (7. in Fig. 24), wird nun ein Bearer (pro SGSN) vom SGSN zum MCC aufgebaut und es erfolgt ein MC-Msg.-Req. an das MCC (8. in Fig. 24).

Erst jetzt sendet das MCC die MC-Nachricht an alle SGSNs zu denen Bearer aufgebaut sind und von denen er die MC-Msg.-Req. erhalten hat (9. in Fig. 24).

Die weiteren Schritte (10. und 11. in Fig. 24) sind nun wie­ der identisch mit 8. und 9. aus Fig. 23.

Eine weitere Möglichkeit ist, dass nach dem Eintreffen des MC-Msg.-Req. beim SGSN (7. in Fig. 25) nun ein Bearer pro RNC vom SGSN zum MCC aufgebaut wird (8. in Fig. 25). Über diese RNC-spezifischen Bearer werden nun die MC- Nachrichten über den SGSN zu den entsprechenden RNCs weiter­ geleitet (9. in Fig. 25).

Mit der Mapping-Information (UE/MC-Gruppe) aus dem MC-Msg.- Request kann die MC-Nachricht nun zu den UEs der MC-Gruppe übertragen werden (10. in Fig. 25).

Damit die Verbindungswege (Bearer) für die Übertragung der MC-Nachrichten zu den einzelnen UEs einer MC-Gruppe nicht für jede einzelne MC-Nachricht einer bestimmten Gruppe oder sogar bei jedem einzelnen IP-Packet einer MC-Nachricht neu aufge­ baut werden müssen, kann ein Timer initialisiert werden. Die Verbindungen (Bearer) werden nun solange aufrecht erhalten, bis der Timer abgelaufen ist. Kommt es zu einer erneuten Ü­ bertragung einer MC-Nachricht, bevor der Timer abgelaufen ist, so wird die MC-Nachricht über die noch bestehenden Ver­ bindungswege übertragen.

Eine weitere Möglichkeit ist der Abbau der Bearer durch ex­ plizite Signalisierung ausgehend vom MCC, SGSN oder beiden.

II. Ausführungsbeispiel

Für dieses Beispiel wird erneut angenommen, dass eine MC- Nachricht im IP-MC-Center generiert wurde und nun zu den Teilnehmern dieser MC-Gruppe gesendet werden soll. Diese MC- Nachricht ist mit der MC-Adresse der entsprechenden MC-Gruppe adressiert. Das IP-Multicast-Center hat die Funktionalität eines IP-MC-Routers.

Die Schritte 1. bis 6. sind jeweils identisch mit denen aus Verfahren I.

Nachdem sich nun alle UEs der MC-Gruppe im Connected Mode be­ finden und sowohl eine RRC-Connection als auch Radio Bearer aufgebaut sind, wird nun von jedem RNC, der Mitglieder der MC-Gruppe versorgt, zum SGSN ein Iu-Bearer pro UE aufgebaut (7. in Fig. 26). Ein MC-Msg.-Confirm., der vom RNC über die­ se Iu-Bearer gesendet wird, gibt nun dem SGSN die Bereit­ schaft der UEs kund, MC-Nachrichten empfangen zu können. Der SGSN hat nun die Informationen, wo sich die UEs der MC- Gruppe befinden und kann nun die MC-Nachricht über die zuvor aufgebauten Iu-Bearer zu dem entsprechenden UE senden (8. in Fig. 26).

Ein SGSN, der eine MC-Nachricht für eine bestimmte MC-Gruppe bekommt, aber keine Mitglieder dieser MC-Gruppe versorgt, be­ nötigt diese Nachricht nicht und kann sie verwerfen.

Eine weitere Möglichkeit ist, dass der SGSN, sofern er keine Mitglieder der MC-Gruppe besitzt, eine Prune-Nachricht (Vergl. RPM) an das IP-Multicast-Center zurücksendet. Dieser SGSN erhält dann solange keine MC-Nachrichten für die MC- Gruppe, bis:

• - der SGSN an das IP-MC-Center eine Join-Nachricht sendet, die den Eintritt eines Teilnehmers in eine MC-Gruppe sig­ nalisiert (event-triggered).
• - ein zuvor festgelegter Timer abgelaufen ist.

Denkbar ist auch der Fall, dass die MC-Nachricht, nachdem sie im MCC generiert wurde, nicht sofort an alle SGSNs gesendet wird (Vergl. 1. in Fig. 26). Stattdessen kann auch zuerst ein MC-Message-Request zu den SGSNs gesendet werden (1. in Fig. 27).

Die weiteren Prozeduren zum Aufbau der Verbindungen für die Übertragung der MC-Nachricht vom SGSN zu den UEs der MC- Gruppen-Teilnehmer bleiben dann gleich (2. bis 7. in Fig. 27).

Nachdem der MC-Msg.-Req. beim SGSN eingegangen ist (7. in Fig. 27), wird nun ein Bearer (pro SGSN) vom SGSN zum MCC auf­ gebaut und es erfolgt ein MC-Msg.-Req. an das MCC (8. in Fig. 27).

Erst jetzt sendet das MCC die MC-Nachricht an alle SGSNs, zu denen Bearer aufgebaut sind und von denen er die MC-Msg.-Req. erhalten hat (9. in Fig. 27).

Die Übertragung der MC-Nachricht über die Iu-Bearer zu den UEs der MC-Gruppe ist nun wieder identisch mit der aus Fig. 26.

Eine weitere Möglichkeit ist, dass nach dem Eintreffen des MC-Msg.-Req. beim SGSN (7. in Fig. 28) nun ein Bearer pro UE vom SGSN zum MCC aufgebaut wird (8. in Fig. 28).

Über diese UE-spezifischen Bearer werden nun die MC- Nachrichten über die SGSNs und die RNCs zu den entsprechenden UEs weitergeleitet (9. in Fig. 28).

Damit die Verbindungswege (Bearer) für die Übertragung der MC-Nachrichten zu den einzelnen UEs einer MC-Gruppe nicht für jede einzelne MC-Nachricht einer bestimmten Gruppe oder sogar bei jedem einzelnen IP-Packet einer MC-Nachricht neu aufge­ baut werden müssen, kann ein Timer initialisiert werden. Die Verbindungen (Bearer) werden nun solange aufrecht erhalten, bis der Timer abgelaufen ist. Kommt es zu einer erneuten Ü­ bertragung einer MC-Nachricht, bevor der Timer abgelaufen ist, so wird die MC-Nachricht über die noch bestehenden Ver­ bindungswege übertragen.

Eine weitere Möglichkeit ist der Abbau der Bearer durch ex­ plizite Signalisierung ausgehend vom MCC, SGSN oder beiden.

Weitere Hinweise, Definitionen, Funktionsangaben zu den Funk­ netzwerkelementen von UMTS finden sich insbesondere in fol­ genden Spezifikationen:

• - 3G TS 23.002 V3.3.0, Technical Specification Group Servi­ ces and Systems Aspects, Network architecture, Release 1999
• - 3G TR 21.905 V3.2.0, Technical Specification Group Servi­ ces and Systems Aspects, Vocabulary for 3GPP Specificati­ ons, Release 1999
• - 3G TS 23.060 V3.4.0, Technical Specification Group Servi­ ces and Systems Aspects, General Packet Radio Service (GPRS), Service description, Stage 2, Release 1999

Folgende Abkürzungen wurden in Zusammengang mit der Beschrei­ bung der Erfindung insbesondere verwendet:

Grundsätzlich: Mehrzahlbildung durch Anhängen eines 's', z. B.: ein RB, zwei RBs
CN: Core-Network
GGSN: Gateway GPRS Support Node
GPRS: General Packet Radio Service
GSM: Global System for Mo­ bile communications
HLR: Home Location Regis­ ter
HSS: Home Subscriber Ser­ ver
IGMP: Internet Group Mana­ gement Protocol
IMSI: International Mobile Subscriber Identity
IP: Internet Protocol
MC: Multicast
MCC: Multicast-Center
MM: Mobility Management
MS: Mobile Station
MSC: Mobile Switching Cen­ ter
MSISDN: MS International ISDN Number
PDP: Packet Data Protocoll
PLMN: Public Land Mobile Network
RNC: Radio Network Controller
RNS: Radio Network Subsystem
RPM: Reverse Path Multicasting
SGSN: Serving GPRS Support Node
SM: Session Management
UE: User Equipment
UMTS: Universal Mobile Telecom­ munication System
UTRAN: UMTS Terrestrial Radio Ac­ cess Network
VLR: Velocity Location Register

Claims (9)

1. Verfahren zum Verteilen einer Gruppennachricht (GN1) an mindestens eine Gruppe (A) von Teilnehmergeräten eines Funk­ kommunikationssystems (FN2), wobei in mindestens einer Spei­ chervorrichtung (SP1) die ein oder mehreren Teilnehmergeräte der jeweiligen Gruppe (A) unter einer gemeinsamen Identifi­ zierungsadresse (IDA) abgelegt worden sind und dort fortlau­ fend aktualisiert werden, wobei zur Verteilung der jeweiligen Gruppennachricht (GN1) durch mindestens ein Multicast-Center (MCC) an die Mitglieder-Teilnehmergeräte (UE1, UE2, UE4, UE5) einer ausgewählten Gruppe (A) diese zu verteilende Gruppen­ nachricht (GN1) lediglich über einen gemeinsamen Übertra­ gungspfad (GP) an mindestens eine übergeordnete Funknetzwerk- Kontrolleinheit (SGSN1) gesendet wird, mittels der Speicher­ vorrichtung (SP1) die aktuell zugehörigen, zu benachrichti­ genden Teilnehmergeräte (UE1, UE2, UE4, UE5) dieser ausge­ wählten Gruppe (A) ermittelt, und diese der übergeordneten Funknetzwerk-Kontrolleinheit (SGSN1) mitgeteilt werden, und wobei dann von dieser übergeordneten Funknetzwerk- Kontrolleinheit (SGSN1) mindestens ein Übertragungspfad (UP11) zur Verteilung der Gruppennachricht (GN1) an die er­ mittelten Mitglieds-Teilnehmergeräte (UE1, UE2, UE4, UE5) der ausgewählten Gruppe (A) unter Zuhilfenahme einer oder mehre­ rer untergeordneter Funknetzwerk-Kontrolleinheiten (RNC1) be­ reitgestellt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Verteilung der Gruppennachricht (GN1) in einem UMTS (Universal Mobile Telecommunication System), GPRS (General Packet Radio Service), EDGE (enhanced data rates for GSM environments), und/oder OFDM (Orthogonal Frequency Division Multiplexing)-Funkkommunikationssystem durchgeführt wird.

3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als übergeordnete Funknetzwerkkontrolleinheit (SGSN1) jeweils ein Serving GPRS Support Node von UMTS verwendet wird.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als untergeordnete Funknetzwerkkontrolleinheit (RNC1) jeweils ein Radio Network Controller von UMTS verwendet wird.

5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von der jeweiligen untergeordneten Funknetzwerkkontroll­ einheit (RNC1) jeweils ein Verbindungsaufbau zu derjenigen Basisstation (BS11, BS12) ihres Versorgungsbereiches initiiert wird, in deren Funkzelle sich das jeweilig zu benachrichti­ gende Teilnehmergerät (UE4) aufhält.

6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für die Übermittlung der Gruppennachricht (GN1) von der übergeordneten Funknetzwerkkontrolleinheit (SGSN1) zur jewei­ lig zugeordneten, untergeordneten Funknetzwerkkontrolleinheit (RNC1) lediglich ein einziger, gemeinsamer Übertragungspfad (GP11) aufgebaut wird.

7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine Speichervorrichtung (SP1) im Funk­ kommunikationssystem (FN2) zentral geführt und verwaltet wird.

8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Teilnehmergerät (UE1) jeweils ein Mobilfunkgerät, insbesondere Zellulartelefon, verwendet wird.

9. Funkkommunikationssystem (FN2) zum Verteilen einer Grup­ pennachricht (GN1) an mindestens eine Gruppe (A) von Teilneh­ mergeräten, insbesondere nach einem der vorhergehenden An­ sprüche, wobei mindestens eine Speichervorrichtung (SP1) vor­ gesehen ist, in der ein oder mehrere Teilnehmergeräte (UE1, UE2, UE4, UE5) der jeweiligen Gruppe (A) unter einer gemein­ samen Identifizierungsadresse (IDA) ablegbar und dort fort­ laufend aktualisierbar sind, wobei mindestens ein Multicast- Center (MCC) vorgesehen ist, mit dessen Hilfe bei einem Ver­ teilungswunsch eine neue Gruppennachricht (GN1) an die Mit­ glieds-Teilnehmergeräte (UE1, UE2, UE4, UE5) einer ausgewähl­ ten Gruppe (A) auf einem gemeinsamen Übertragungspfad (GP) an mindestens eine übergeordnete Funknetzwerkkontrolleinheit (SGSN1) sendbar ist, wobei die Speichervorrichtung (SP1) der­ art ausgebildet ist, dass die aktuell zugehörigen, zu benach­ richtigenden Teilnehmergeräte (UE1, UE2, UE4, UE5) dieser ausgewählten Gruppe (A) ermittelbar, und diese der übergeord­ neten Funknetzwerkkontrolleinheit (SGSN1) mitteilbar sind, und wobei die übergeordnete Funknetzwerkkontrolleinheit (SGSN1) und/oder ihre jeweilig in Wirkverbindung stehende un­ tergeordnete Funknetzwerkkontrolleinheit (RNC1) derart ausge­ bildet sind, dass mindestens ein Übertragungspfad (UP11) von dieser übergeordneten Funknetzwerkkontrolleinheit (SGSN1) zur Verteilung der Gruppennachricht (GN1) an die ermittelten Mitglieds-Teilnehmergeräte (UE1, UE2, UE4, UE5) bereitstellbar ist.