WO2002051187A1

WO2002051187A1 - Method for distributing a group message in a radio communication system and corresponding radio communication system

Info

Publication number: WO2002051187A1
Application number: PCT/DE2001/004643
Authority: WO
Inventors: Alexander Chruschwitz; Martin Hans; Mark Beckmann; Michael Eckert; Thomas Gottschalk
Original assignee: Siemens Aktiengesellschaft
Priority date: 2000-12-21
Filing date: 2001-12-10
Publication date: 2002-06-27
Also published as: DE10064107A1; AU2002229473A1

Abstract

In order to distribute a group message (GN1) in a radio communication network (FN2), a group message (GN1) that is to be distributed is sent by at least one multicast center (MCC) to the member-subscriber devices of a selected group (A) using only one common transmission path (GP) in at least one higher-level radio network control unit (SGSN1). The subscriber devices (UE1,UE2,UE4,UE5) currently belonging to the corresponding selected group (A) that are to be notified are determined by at least one storage device (SP1) and communicated to the higher-level radio network control unit (SGSN1).

Description

description

Method for distributing a group message in a radio communication system and associated radio communication system

With many of the services and applications offered in modern mobile radio systems, it is desirable to transmit messages not only to one but to two or more mobile radio subscribers. Examples of such services and applications are in particular news groups, video conferences, video on demand, distributed applications, etc.

An object of the invention is to show a way in which such group messages can be transmitted to a large number of subscriber devices of a radio communication system, in particular a mobile radio network, in an efficient manner. This object is achieved by the following method according to the invention: Method for distributing a group message to at least one group of subscriber devices of a radio communication system, the one or more subscriber devices of the respective group having been stored in at least one storage device and being continuously updated there, wherein for distribution of the respective group message by at least one multicast center to the member subscriber devices of a selected group, this group message to be distributed is only sent via a common transmission path to at least one higher-level radio network control unit, by means of the storage device, the currently associated subscriber devices to be notified of the selected one Group determined, and these are communicated to the higher-level radio network control unit, and then by this higher-level Radio network control unit at least one transmission path to the distribution The group message to the determined member subscriber devices of the selected group is provided with the aid of one or more subordinate radio network control units.

This enables an efficient and simple distribution of group messages to the different subscriber devices of the selected group.

The invention further relates to a radio communication system for distributing a group message to at least one group of subscriber devices, in particular according to one of the preceding claims, wherein at least one storage device is provided in which one or more subscriber devices of the respective group can be stored under a common identification address and can be continuously updated there At least one multicast center is provided, with the aid of which a distribution group can send a new group message to the member subscriber devices of a selected group on a common transmission path to at least one higher-level radio network control unit, the storage device being designed such that the currently associated ones subscriber devices of this selected group to be notified, and these can be communicated to the higher-level radio network control unit, and the higher-level F network control unit and / or its respective subordinate radio network control unit are designed in such a way that at least one transmission path can be provided by this higher-level radio network control unit for distributing the group message to the determined member subscriber devices. Other developments of the invention are given in the subclaims.

The invention and its developments are explained in more detail below with reference to drawings.

Show it:

FIG. 1 shows a schematic representation of the basic architecture of a mobile radio system,

FIG. 2 shows a schematic representation of the structure of a radio communication system which, in addition to the mobile radio system from FIG. 1, has at least one multicast center for distributing multicast messages in order to carry out the method according to the invention,

FIGS. 3 and 5 in a schematic representation the step-by-step structure of a PDP context if a data packet is to be transmitted on the network side for a specific subscriber device of the radio communication system according to FIGS. 1 and 2,

Figure 6 in a schematic representation different

Packet routes in the radio communication system according to FIG. 1 for a plurality of subscriber devices to be notified, to which the same message has been set up after transmission Connections according to FIGS. 3 and 5 are transmitted individually,

FIG. 7 shows a schematic representation of packet routes in the radio communication system according to the invention according to FIG. 2 when using the transmission path structure corresponding to FIGS. 3 and 5 for the mobile radio system according to FIG. 1,

Figures 8 with 10 in a schematic representation the step-by-step establishment of transmission connections for the transmission of multicast messages to a selected group of subscriber devices after a first

Variant of the method according to the invention with the aid of the radio communication system according to FIG. 2,

FIG. 11 shows a schematic representation of the detailed sequence of establishing a connection for an individual subscriber device using the method according to the invention in accordance with FIGS. 8 and 10,

Figure 12 shows another in a schematic representation

Variant of the method according to the invention,

FIG. 13 shows a schematic representation of the detailed connection setup for a specific subscriber device, FIG. 14 shows a schematic illustration of the registration process of a subscriber device in the radio communication system according to FIG. 2 in order to be able to receive a multicast message using the method according to the invention,

Figure 15 is a schematic representation of the components of a Packlet Switched Domain, which in the transport of packet data in

UMTS network are involved,

FIGS. 16, 17 schematically the basic method for distributing group messages according to the Internet Group Management Protocol,

FIG. 18 schematically the basic distribution method for group messages according to the reverse path multicasting principle,

FIG. 19 shows a schematic representation of the signaling for a specific subscriber device for entry of its multicast group membership in a database

Implementation of the method according to the invention with the radio communication system according to FIG. 2,

Figure 20 shows a first in a schematic representation

Variant of a multicast context activation for the distribution of multicast messages according to the invention A method using the Funkkommunikati ^¬ onssystems of Figure 2,

FIGS. 21, 22 each show a schematic representation of modified multicast context activations for carrying out the method according to the invention,

23 with 25 three different variants of the multicast method according to the invention

Distribution of multicast messages,

26 shows a variant of the multicast method according to FIG. 23

FIG. 27 shows a variant of the multicast method according to FIG. 24, and

FIG. 28 shows a variant of the multicast method according to FIG. 25.

Elements with the same function and mode of operation are provided with the same reference numerals in FIGS.

In modern mobile radio systems such as UMTS (Universal Mobil Communication System), GPRS (General Paket Radio Service), EDGE (Enhanced Data Rates for GSM Environment) it is desirable to not only send messages to one, but to two or more mobile subscribers transfer. Examples of such services and applications are news groups, video conferences, video-on-de anD, distributed applications, etc. When transmitting the messages to the various participants, it is possible to send a copy of the data separately to each recipient. Although this procedure is easy to implement, it is too complex for large groups of subscriber devices. Since the same message is transmitted via N (N = number of recipients of the message) individual connections (= unicast connections) and is sent several times over common connection paths, this method requires too much bandwidth.

The so-called multicast transmission offers a better option. The various subscriber devices to which the same message is to be transmitted are combined to form a group (= multicast group) and this is assigned a common identification address (multicast address). In this way it is not necessary for the respective sender to know how many and which receivers are hidden behind the multicast address. Rather, it is sufficient for the respective sender to only know the name or the address of the multicast group to be notified. The data to be transmitted are then only sent once to this multicast address.

However, the management of the multicast groups and the routing of the multicast messages to the individual subscriber devices of the multicast groups are particularly problematic for the distribution of such multicast messages. The registration of the subscribers belonging to a multicast group is particularly problematic with regard to the fact that new subscriber devices can join this multicast group at any time, but members of the respective multicast group can also leave. Within the scope of the invention, the components of the packetswitched domain of a UMTS mobile radio network FN1 are dealt with below. The function and mode of operation of its components are explained in more detail below with reference to FIG. 15:

A subscriber terminal such as UE (User Equipment) is connected to a base station Node B via an air interface Uu (Uu interface). This node B is connected via a landline connection Iub to an RNC (Radio Network Controller) as the first radio network control unit, which controls and distributes the resources of the air interface. The RNC, in turn, can serve one or more base stations. The subsystem consisting of at least one radio network controller and corresponding associated base stations is generally referred to as a radio network subsystem RNS, which is indicated by a dashed line in the figure. For packet-switched transmission of e.g. IP packets from the Internet IP to a single subscriber device such as UE is at least one of the radio network controllers such as RNC is connected via a landline connection Iu to a higher radio network control unit SGSN, in particular in the UMTS standard with a so-called serving GPRS support node. For a transmission of data from a foreign packet data network, such as the Internet IP here, the higher-level radio network control unit SGSN is preferably connected to at least one gateway GGSN, in particular a gateway GPRS support node, via a fixed network connection Gn. This gateway GGSN realizes the access point to an external packet data network. Over a

In the exemplary embodiment of FIG. 15, the fixed network connection Gi is connected to the gateway GGSN with a server in the Internet IP. Information for the management of mobile participants mer may Gateway GGSN over a landline connection Gc and senior network unit SGSN via a landline connection ^¬ Gr from a centrally managed database HLR to ^¬ particular the so-called. Home Location Register to query. The higher radio network control unit SGSN requests user-specific information from the home location register HLR, such as for authentication of a subscriber. Furthermore, the higher control unit SGSN is preferably responsible for establishing a connection between the respective subscriber device and an external packet data network, such as IP here.

If packet data are to be transmitted from the external packet data network to the radio network, they first reach the gateway GGSN, which inquires from the home location register HLR of the relevant higher radio network control unit SGSN. This gateway GGSN now notifies the higher radio network control unit SGSN that data is available for the corresponding subscriber device. The higher radio network control unit SGSN then initiates the establishment of the connections between the user equipment UE to be notified and the external network IP.

In the context of the invention, a subscriber device (user equipment) as a component of a radio communication system is preferably understood to be a mobile terminal. In the UMTS standard, for example, this is connected in particular to the UTRAN (UMTS Terrestrial Radio Access Network) via the air interface Uu (Uu interface). It contains the UMTS Subscriber Identity Module (USIM) by storing (similar to SIM in the GSM network) identification data that authorize the subscriber device to register and participate in the UMTS network. A base station (Node B) is a radio network component that is responsible for the supply of one or more radio cells. The radio communication takes place by means of a base station via the air interface with the respective subscriber device in the radio cell of this base station.

In the context of the invention, a radio network controller is understood to be a first, subordinate radio network control unit, with the aid of which the resources of the air interface between the respective base station and any subscriber devices in its radio cell are controlled. A radio network controller preferably supplies and controls one or more base stations. The subsystem from a radio network controller such as RNC in FIG. 15 and one or more base stations is referred to as a radio network subsystem RNS, which is indicated in FIG. 15 by a dashed frame. This subsystem is through the IU interface with at least one higher network control unit such as SGSN connected in Figure 15.

GPRS support nodes such as SGSN form the interface between the radio system and a fixed network for preferably packet-switched services (PDN). A GPRS support node performs all the functions necessary to ensure the transport of data packets from the external PDN to the end user device, in particular to the mobile station, and vice versa. For example, In the UMTS-GPRS network there are preferably 2 different GPRS support nodes (GΞNs): the SGSN (serving GSN) and the GGSN (gateway GSN).

The SGSN is the node that supplies the subscriber devices, in particular mobile radio stations in a region assigned to it (SGSN area). He keeps track of the whereabouts of the some subscriber devices, performs security functions and access controls (authentication, cipher setting procedures and the like). An SGSN has routing / traffic management functions and implements the interface to the GGSN (Gn) Access Network (Gb) and to other PLMNs (Gp) (public land mobile networks). In addition to the subscriber registration information (IMSI, temporary identities, PDP addresses (packet data protocol)), the location register function of the SGSN also stores so-called location information, which is required to set up or end a packet data transmission.

Depending on the mode of the mobile station (MS), the location information can be either the cell or the routing area where the MS is currently registered. Furthermore, the VLR number of the connected VLR (visitor location register) and the addresses of each GGSN for which there is an active PDP context (see section "Transmission of packet data in UMTS" below) are also stored. The SGSN also controls Mobility Management (MM), which is used to determine the current location of an MS. At the same protocol level for mobility management there is session management (SM), which is responsible for activating and deactivating the PDP context just mentioned in the SGSN and the GGSN. SGSN and HLR exchange information via the Gr interface.

The GGSN is the node that enables the contact (interworking) between a UMTS PLMN and a packet data network (PDN). Data exchange takes place via the Gi interface

(Figure 15). The GGSN contains the routing information for the UMTS participants that can be reached in the PLMN. The routing information is used to contact the respective SGSN in whose service area (SGSN area) a particular MS is currently located. In order to contact this SGSN, its address is conveniently stored as location information. Location information about an MS can be queried by the HLR via the GC interface.

Home Location Register (HLR): The HLR consists of a database that is responsible for the management of the mobile participants. A PLMN (Public Land Mobile Network) can include one or more HLRs. This depends on the number of mobile subscribers, the capacity of the equipment and the organization of the network. The following types of information are stored here:

• Registration information of the participants

• Some location information enables billing and routing of calls to the MSC (Mobile Services Switching Center) with which the MS (Mobile Station) is registered (eg the MS Roaming Number, the VLR (Visitor Location Register) Number, the MSC Number, the Local MS Identity). If GPRS is supported, location information is saved that enables the billing and routing of messages in the SGSN (Serving GPRS Support Node) to which the MS is currently logged on (e.g. the SGSN Number). Different types of identification are associated with each registration of an MS and are stored in the HLR: • International Mobile Subscriber Identity (IMSI)

• One or more Mobile Station International ISDN numbers (MSISDN)

• None, one or more Packet Data Protocol (PDP) addresses (IP addresses) At least one identity, separate from the IMSI, is always transferred with an MS registration and saved in the HLR. The IMSI or the MSISDN can be used as an identifier for access to the HLR information for "mobile registration". The HLR database also contains other information such as:

^• Teleservices and intermediary services, credentials

^• Service restrictions (eg limited roaming) • A list of all group IDs that authorize the participants to set up a voice group or a broadcast call

• Information about when a GGSN (Gateway GPRS Support Node) is allowed to dynamically assign a participant a PDP address

• Optional additional services

Home Subscriber Server (HSS):

The HSS contains LCS subscription data and routing information. For roaming UEs, the HSS can be in different PLMNs.

This network element is an extension of the HLR for the future all-IP network.

Before packet data (here IP packets in the exemplary embodiment) between, for example, a server in the Internet IP and an end user device such as UE (cf. FIG. 15) can be transmitted, the subscriber device UE expediently sets up a so-called PDP context (packet data protocol context), with the aid of which a connection to the Internet IP is established. A PDP context describes the path through the respective network, in particular UMTS network, and makes it known in the network elements UE, SGSN, GGSN. Only then can a connection be established via which the packet data (in UMTS IP packets) is then transmitted.

The term bearer is frequently used in the context of this invention. In general, the term bearer describes a path for the transmission of information. This is particularly defined by its capacity, delay time and bit error rate. The interface between the respective radio network subsystem RNS and the so-called core network (CN) is referred to as the EU interface. The core network is indicated by a dashed frame in FIG. 15. The information path between the RNS and the CN is particularly called ΕU-Baerer. A radio bearer is preferred the service for the transfer of user data between the respective user equipment UE and UTRAN (UMTS Terrestrial Radio Access Network).

Especially in the UMTS radio communication system as well as other radio communication systems such as According to the GPRS, EDGE, OFDM (Orthogonal Frequency Division Multiplexing) principle, multicast services for the distribution of multicast messages are of interest.

So far, only multicast services have been offered on the Internet, i.e. on the landline. One such service is IP multicast. The internationally standardized Internet protocol (IPV6) offers the possibility of so-called multicast addressing, via which information can be exchanged between groups of computers (or entire subnets). The recipient group, also called multicast group, is addressed with a unique IP address (multicast address), the sender determining the composition of the group, e.g. Number of members and whereabouts is unknown. Individual hosts, especially computers, can join and leave a group at any time. A host can be a member of multiple groups. In order to send data to a group, it is not necessary for the sender to be a member of the group. For the management of multicast groups and the

Routing of the messages to the participants in an IP multicast group, there are different algorithms and protocols on the Internet.

Internet Group Management Protocol (IGMP):

This protocol enables a multicast router (MC router) such as IPR from FIG. 16 to group groups of individual computers such as Hl with HN. It gives a host the ability to display all of its memberships on such a RQ request. The Internet Group Manager protocol IGMP Version 1 can send two types of messages. One calls siclr Host Me bership Query (type = 1) and the other Host Membership Report (type = 2). A multicast router such as IPR from FIG. 16 informs itself in its area of responsibility (subnet) about the group members present, such as Hl with HN. He does this by requesting RQ to all hosts to announce their group membership (host membership query). Such queries are preferably generated at periodic intervals so that the router IPR can adapt to changes. To ensure that this message reaches all hosts, it is sent to the group of all hosts in the subnet. Upon receipt of this query, each host replies for each group in which it is a member with a Host Membership Report RE, which is illustrated in FIG. 17. It announces to the multicast router IPR that it is a member of this group. IGMP Version 2 offers hosts the option of sending the MC router a leave message when leaving an MC group in order to avoid unnecessary traffic. Furthermore, group-specific queries can be sent, which means that not all group memberships are always queried, but preferably only certain ones.

Reverse Path Multicasting (RPM):

An algorithm that distributes multicast messages from the sender via a network (eg Internet) to the receivers is the so-called reverse path multicasting. Its basic principle is illustrated schematically in FIG. 18. In the RPM process, a first data packet (a multicast message) from a sender is distributed over the entire network. If a leaf router (multicast router that has no further connections to other routers) now receives a packet from a group for which it has no members in its subnet (which it asked for using IGMP, for example), it sends it to Predecessor a so-called Prune message such as PRN. He is thus informing his predecessor that he will no longer need data from this group in the future. If a router now links to all of its child (connections to other routers ^' , except the one through which it receives the message has) Prune message gets and in its own subnet, no members of this group are present, it also passes a Prune message for the ^¬ se Group to its predecessor. Thus, the distribution of the data is limited to paths that lead to group members. In relation to FIG. 17, this means that provided that there are no members of the group under consideration in the subnet of routers E and F, no data are sent from router B to router E. However, in order to check whether a host in a subtree shortened by Prune messages has joined a group, it is advisable to send data again over the entire network at periodic intervals. Each router in each group preferably stores data about which router it can forward packets to and which it cannot.

In order to enable an efficient distribution of multicast messages for a radio communication network, in particular for a UMTS and / or GPRS mobile radio system, an entry of the multicast group membership in at least one database, the publication of the multicast group participants, is expediently considered from the basic concept in the network elements of the radio communication network (multicast context activation) and / or the transmission of a multicast message from the respective message source, for example a multicast transmitter down to the message sink, e.g. the end user equipment of a multicast group. The so-called multicast center is frequently mentioned in the context of the invention. This additional component is responsible for generating multicast messages.

With the help of this basic introduction of a database for the entry of the multicast group memberships and the expansion of the functionality of the already existing radio network components by the ability to be able to recognize multicast messages, a simple and efficient distribution of multicast messages in the respective radio communication system is made possible , There is also an efficient connection to external fixed networks that work in a packet-oriented manner.

Figure 1 shows a schematic representation of the basic architecture of a UMTS radio communication system. Not ge ^¬ shows the clarity while the so-called. Home Location Register HLR database that has a connection to the SGSN and GGSN, as shown in Figure 15. The Visitor Location Register VLR, which is connected to the Home Location Register HLR, is also omitted. In such a radio network FN1 according to FIG. 1, the GGSN forms the access for external networks EN to the UMTS radio network. Several higher-level radio network control units, such as, for example, SGSN1 with SGSGN3, are usually coupled to the gateway GGSN via associated data connections LI1G with LI3G. These control units SGSN1, SGSN2 and SGSN3 are preferably responsible for establishing the connection in the radio network FN1. Each higher radio network control unit such as SGSN1 with SGSN3 is in turn connected via data connections such as LI11, LI21, LI31, LI202, LI503 with subordinate radio network control unit RNC1, RNC2, RNC3, RNC20 and RNC50. These subordinate radio network units are called radio network controllers in the UMTS standard. These each manage the resources on the air interface and establish the partial connection between the respective RNC and the end user device. Each radio network controller is assigned one or more base stations, each of which provides the radio connection to one or more subscriber devices in their respective radio cell via at least one air interface.

Specifically, a group of 3 subordinate control units, in particular radio network controllers RNC1, RNC2, RNC3, is coupled to the first higher radio network control unit SGSN1 via corresponding data connections LI11, LI21, LI31. The higher the radio network control unit SGSN2 is in ^'of Figure 1, only with the single sub- orderly control unit RNC20 via the data line LI202 in operative connection. Only a single radio network controller RNC50 is also connected to the higher network unit SGSN3 via a data line LI503. In FIG. 1, the two base stations BS11, BS12 are coupled to the first radio network controller RNC1 via associated, separate data connections LI111 *, LI121 *. The two subscriber devices UE4 and UE5 are located in the area of the radio cells of these two base stations BS11, BS12. The second radio network controller RNC2. which also depends on the same higher radio network control unit SGSNl, 2 base stations BS21, BS22 are also assigned via corresponding separate data connections LI212 *, LI222 *. In the exemplary embodiment of FIG. 1, the subscriber device TJE1 is currently located in the radio cell area of the base station BS22.

Finally, the third radio network controller NNC3, which is also coupled to the higher control unit SGSN1 via the data link LI31, supplies the base station BS31 via a data link LI313 *. The user device UE2 is present in the radio cell of this base station BS31, for example.

The 4 subscriber devices UE1, UE2, UE4, UE5 should now be able to receive a multicast message as effectively as possible as multicast group A from the external network EN. For this purpose, the components of the mobile radio network are given extended functionality and at least one so-called multicast center is also introduced. FIG. 2 shows a radio network FN2 modified in this way compared to FIG. 1, in particular for the UMTS standard. The mobile radio network FN2 has the multicast center MCC as an additional logical network element compared to the radio network FN1 from FIG. It is connected to all higher radio network control units via separate data connections such as LUC, LI2C, LI3C, here in particular UMTS serving GPRS support nodes such as SGSNl, SGSN2, SGSN3. As usual in an IP fixed network, messages can also be sent via several network nodes to the individual servers. ving GPRS support nodes. The functionality of the multicast center includes, in particular, the administration of the multicast groups made available for the UMTS mobile radio network, ie all the multicast groups made available and their identities are stored in the multicast transmitter for addressing and are therefore known there. The storage of the multicast groups is illustrated by way of example in FIG. 2 in that the multicast center MCC is connected to an external storage device SP1 via a data line K04 shown in broken lines. The serving GPRS support node SGSNl is also connected to the storage device SPl via a data connection KOI and thus has access to its data stocks. The multicast group A is stored in this storage device SP1 under a common identification address IDA, which in the exemplary embodiment in FIG. 2 currently comprises the subscriber devices UE1, UE2, UE4 and UE5. In a corresponding manner, the identification addresses such as IDB for further multicast groups are also stored in the storage device SP1. All other higher radio network control units, in particular serving GPRS support nodes, are preferably also connected to this storage device SP1. In FIG. 2, the serving GPRS support node SGSN2 is coupled to the storage device SP1 via a data connection K02 and the support node SGSN3 via a data connection K03. The storage device SP1 is therefore preferably operated as a centrally managed database. Of course, it can also be expedient to provide several such storage devices in the radio network FN2. The data management of the multicast groups is also advantageously carried out centrally as a logical unit.

If necessary, it may also be expedient not to install such storage devices for storing the identification addresses for the multicast groups and their specific subscriber entries as external, independent components in the network / but in the multicast center itself and in the to integrate the respective higher radio network control unit, in particular in the respective serving GPRS support node (and not as a separate database as in FIG. 2).

In addition to managing the multicast group entries, the MCC multicast center also acts as the source for all multicast messages.

FIGS. 3 and 5 schematically illustrate the chronological sequence of a logical connection establishment, for example starting from the external network EN to the subscriber device UE4. It is assumed that the subscriber device UE4 has already registered in the radio network FN2, but currently no PDP context (packet data protocol). and has no active logical transmission connection to the radio network FN2. If a data packet PK4 for the user device UE4 now comes from the external packet data network EN, an identification of the user device UE4 is supplied with the data packet PK4. GGSN from FIG. 3 either recognizes the SGSN on which the user equipment UE4 is registered or queries it in the HLR database (not shown). In this exemplary embodiment it is assumed that the GGSN knows that the user device UE4 is registered at the support node SGSNl. The GGSN then sends the SGSN1 a message MPK4 that a data packet PK4 for the user equipment UE4 has arrived in the GGSN. The support node SGSNl generally knows the so-called routing area in which the user device UE4 is suspected. This routing area can include several radio network controllers. The support node SGSNl then sends a request RQ1, RQ2, RQ3 to all radio network controllers in question, here RNC1, RNC2, RNC3, whether the subscriber device UE4 is in the radio cells managed by the radio network controllers (= paging request). The radio network controllers RNC1, RNC2, RNC3 then send a request IF1, IF2, IF3 to all radio cells that they manage

(= Paging). The UE4 subscriber device then reports to the corresponding ^' Radio Network Controller RNC1. The radio net The work controller RNC1 then notifies its higher-level control unit SGSN1 that the user device UE4 is in its area. This is indicated in FIG. 4 by the response signal RE1. The transmitted signals are illustrated in FIG. 3 with 5 by arrows drawn thicker. In response to this response signal RE1, the SGSN1 now sets up logical transmission connections to the GGSN (core network bearer) and RNC1 (Iu-Baerer), which only transport data for the user equipment UE4. The logical transmission connection is described with a so-called PDP context, which contains all the necessary data for the connection between the subscriber device and the GGSN. Each logical transmission connection between the respective SGSN and GGSN is assigned exactly one logical transmission connection between SGSN and RNC, which in turn is assigned exactly one logical transmission connection between RNC and the subscriber device. The SGSN and RNC thus have fixed mappings of the logical transmission connections, which means that, for example, SGSN knows which logical transmission connection (and thus also to which RNC) he / she is to forward a message to the respective subscriber device if he / she sends the message via a certain logical transmission connection GGSN gets. FIG. 5 shows the complete transmission path from the GGSN to the SGSN1, further to the RNC1, the base station BS12 and finally to the end user device UE4 by means of a thick arrow UP11.

FIG. 6 shows the transmission connections of several subscriber devices in a radio communication system FN1 corresponding to FIG. 1. Each subscriber device has a PTP context for each transmission connection assigned to it. Even if the messages that are to be sent from the external network EN to the user equipment UE1, UE2 and UE4, UE5 are exactly the same, it is necessary to send the messages to each user separately, even if the physical connections are the same are. In practice, this is too complex and requires too many resources. Because between A fixed mapping of user identifications to logical connections is carried out for all network components, ie a connection is set up specifically for each individual subscriber. For the 4 subscriber devices UE1, UE2, UE4, UE5 of MULTICASTGRUPPE a, a total of 4 complete transmission paths are thus occupied in the exemplary embodiment in FIG the end user devices are built up continuously.

FIG. 7 illustrates how multicast messages would be sent from the multicast transmitter MCC to the subscriber devices UE1, UE2, UE4, UE5 if the concept according to FIG. 6 of the fixed assignment of logical channels to subscriber devices were also applied here. Although multicast messages sent by multicast transmitter MCC are the same for all subscriber devices to be notified, they would still have to be separate for each user between multicast senders MCC and SGSNl, SGSNl and RNC1 / RNC2 / RNC3, and RNCs and the end subscriber devices UE1, UE2, UE4, UE5 are sent. Generally speaking, this means that as many individual connection paths would have to be set up as the end user devices would have to be notified by the multicast message. This would be too complex and not sufficiently efficient.

In order to enable a more efficient distribution of group messages in the radio communication network FN2 of FIG. 2, according to a first variant of the method according to the invention, the procedure corresponding to FIGS. 8 and 10 is expediently as follows:

The multicast center MCC sends a multicast message GN1 for the multicast group A to all SGSNs (for the sake of simplicity, only SGSNl will be considered below; the same applies to the other SGSNs) - SGSNl now has a new functionality according to the invention and recognizes on the basis of the multicast group identity that is sent that the message is a multicast message. - According to the invention, the SGSNl the multicast Gruppenzugehö ^¬ culties of all stored with him registered users, o of the multicast group memberships are stored in the HLR database and will now ask of SGSN there (see EM). - It is assumed that users UE1, UE2 and UE4, UE5 belong to multicast group A. It is also assumed that these users have no active connection.

- SGSNl knows the routing areas in which the users could be. A routing area can include several RNCs. - SGSNl now either sends 1 request AF per user (in this case 4) to all RNCs in question whether the user is in an RNC managed by them. The inquiry AF is indicated in FIG. 8 by arrows drawn in thicker. If the routing areas are the same, a request with a list of users can also be sent to the RNCs according to the invention.

The RNCs in turn inquire in the radio cells they manage whether one of the subscriber devices of multicast group A to be notified is located there. (Joint request for multiple users is possible).

The users report to the corresponding RNCs, which in turn report the users located to them to the SGSN1, which is indicated in FIG. 9 by arrows RM drawn in bold. - SGSNl now knows that user RN4 and UE5 are on RNC1, user UE1 on RNC2 and user UE2 on RNC3.

- According to the invention, exactly one transmission connection is now established for each RNC in which a user of this multicast group is located. According to the invention, a multicast context is set up for each user between SGSN and user, which, like the ^" PDP Context, ^" describes the connection. The difference to the PDP context is that a multicast context is not permanently assigned to a connection, but several multicast contexts share one or parts of the logical transmission connection. However, a multicast context is also only assigned to exactly one user.

- Each SGSN is expanded so that it can assign several MC contexts to a transmission connection. For this, the SGSN must also store the list of users or multicast contexts that are assigned to this Iu-Bearer.

- Each RNC is also expanded to allow the data to be forwarded to the RNC over a user-assigned transmission link, i.e. so reproduce the message and send it to each user individually. For this purpose, the respective RNC is supplied with a list of the identities of the users or multicast contexts that are assigned to the Iu-Bearer when the Iu-Bearer is set up. This list is saved in the RNC.

- Every RNC sets up a transmission connection for every user who is in the cells he manages.

There is thus a fixed mapping of a multicast group to several Iu-Bearers, however a maximum of 1 (= one) Iu-Bearer per RNC. There is also a fixed mapping of an Iu bearer to several radio bearers.

Figure 11 illustrates again the detailed flow of such a connecting structure by way of example for the part ^¬ slave device UE4. It is assumed that the user device UE4 is initially in idle mode, that is to say is switched on, but has no active connection to the radio network FN2. If a multicast message MC message now comes from the multicast center MCC, the multicast group to which the multicast message is directed is identified in the storage device assigned to the support node SGSN1. This means that the SGSNl knows which members of this multicast group should receive the multicast message. The SGSNl then initiates paging for the respective subscriber devices of this group to be notified. For this purpose, a request signal is sent to all RNCs coupled to the SGN1 as to whether the user equipment UE1, UE2, UE4, UE5 are in their radio cell areas. The radio network controllers transmit these paging signals via their associated base stations to the radio cell areas to be supplied. If one of the subscriber devices to be notified is in the coverage area of this radio network controller, these subscriber devices switch from idle mode to connected mode, ie an active connection RRC connection message (radio resource control) is sent back to the respective one Radio network controller sent. The radio network controller - here RNC1 - that receives notification from its respective base station that there is a subscriber device to be notified in its radio cell, also makes this known to the higher-level control unit - here SGSNl. The latter then requests the multicast context from the respective subscriber device, such as UE4, in accordance with the sequence point 6 of FIG. In the lower half of FIG. 11, the state is below the dashed line shown, from or in which the subscriber devices UE4 and UE5 are already in connected mode. This corresponds to the final state after the signaling of the run point 7. "Activate multicast context request". Since the higher-level control unit SGSNl now knows which radio network controllers are responsible for the subscriber devices to be notified, and a corresponding multicast context is available for establishing a connection to the respective subscriber device, the support node SGSNl now establishes a connection to those to be notified Subscriber devices - here UE4- initiated. For this purpose, an Iu-Baerer is set up between the RNCl and the SGSNl in accordance with process point 8. In addition, the information is given that the Iu-Baerer exists for the participants UE4 and UE5. A radio bearer is then set up between the RNCl and the end user devices UE4 and UE5 in accordance with the sequence point 9 and this is confirmed in accordance with the sequence point 10 to the radio network controller RNCl. This enabled radio users to be set up for all end user devices - here UE4, UE5 - that are connected to the Radio Network Controller RNCl. At the same time, the mapping from a single Iu-bearer between the radio network controller RNCl and the higher-level control unit SGSNl to several radio bearers between the radio network controller RNCl and the end user devices UE4, UE5 is stored in the radio network controller RNCl. This confirms the structure of the Iu-Baer after process point 11. The support node SGSNl then sends a confirmation signal Aktivate Multicast Context Exept after process point 12 to the respective end user UE4 or UE5. Finally, the multicast message is transmitted from the SGSN1 to the end user devices UE4, UE5 via the established transmission path. 10 and 11, the multicast message for multicast group A is first transmitted to the support node SGSN1. Due to its memory access option, the support node SGSNl knows those radio network controllers and the logical transmission connection (Iu-Bearer) that were set up for messages of multicast group A, and only sends the multicast message to each of the radio network controllers once to which a user of this multicast group is connected. The respective radio network controller knows the users of multicast group A and the logical transmission connections to the users (radio bearers) who are linked to the Iu-bearer, ie the connection arriving at the RNC. The respective radio network controller now sends the multicast message of multicast group A over the established connections (Radio Baerer) once for each user. Although here in the exemplary embodiment of FIG. 10 the radio network controller RNCl supplies several subscriber devices UE4, UE5, only a single transmission path is set up and used between the radio network controller RNCl and the higher-level support node SGSN1. This enables an efficient distribution of the multicast message GN1.

FIG. 12 shows a further variant for the distribution of multicast messages according to the invention between the multicast transmitter MCC and the end user devices to be notified of a specific multicast group, such as A. As in FIG. 10, a logical transmission connection to the RNCl was also made from the support node SGSNl ( Iu-Baerer) built per user. The multicast center MCC preferably sends the multicast message GN1 only once. According to the invention, the support node SGSNl knows the subscriber devices of this multicast group A. due to its ability to access the storage device SP1 of Figure 2 and thus the associated logical transmission connections to the radio network controllers. The support node SGSN1 duplicates the incoming multicast message GNl and sends this message once per subscriber device to the corresponding radio network controller RNCl, RNC2, RNC3. Since here in the exemplary embodiment 2, that is to say in general terms, several subscribers hang on the radio network controller RNCl, many logical transmission connections are provided for transmitting the group message GN1 between the support node SGSN1 and the radio network controller RNCl. Specifically, this means that there is a transmission path UP11 * between the support node SGSN1 and the radio network controller RNCl for the subscriber device UE4 and a further, second transmission path

UP11 ** for the user equipment UE5 is turned off. This transmission variant is particularly advantageous: No new functionality is required in the respective radio network controller. The higher-level radio network control unit SGSN1 can continue to establish a connection per user, similar to the PDP context. For the higher-level radio network control unit SGSN1 and the respective radio network controller, it is not necessary to maintain a list of the multicast context or subscriber devices of the multicast group to be considered, which belong to a logical transmission connection. In this way, a change in the signaling between the network components of existing mobile radio networks is largely avoided. Merely the introduction of a multicast transmitter and a centrally managed database for the multicast groups is expedient for carrying out the method according to the invention. FIG. 13 shows this connection set-up again in detail, corresponding to FIG. 12. Changes to the method in FIG. 11 are shown with a gray background.

FIG. 14 finally shows an example of a registration process for user equipment UE4. If the user device UE4 switches on its mobile radio device, a radio resource control connection to the radio network controller RNCl is first established. The UE4 subscriber device then authenticates itself at the support node SGSNl. During authentication, the multicast group membership of the user device UE4 is transmitted to the support node SGSNl. The Support Node SGSNl stores this information in an internal or external database. Alternatively, the information can also be sent to an external database such as an extended home location register HLR. For this purpose, an identification of the user device UE4 and identifications of the multicast groups of this user device are sent to such a database.

In summary, the following steps for the efficient distribution of multicast messages in a radio communication system are advantageous:

1. Introduction of a logical network element "Multicast Center":

The multicast center has the task of managing the multicast groups, providing the information for the multicast groups and sending them to all SGSNs in the UMTS network. For this purpose, it also expediently stores an identity of a multicast group which is unique in the entire network. 2. Extension of the SGSN functionality by the ability to recognize that a received message is a multicast message.

3. Extension of the SGSN by the ability to store multicast group memberships of the users registered on the SGSN.

4. As an alternative to 3. the group membership information can also be stored in an external database (e.g. HLR). For this purpose, the HLR functionality is expediently expanded. In addition, the SGSN is expediently given the additional ability to request group membership from the external database.

5. Extension of the SGSN functionality by the ability to store data that describe a user-specific connection to the SGSN. This data is called multicast contexts.

6. According to the invention, the multicast context includes at least one user identification and one identification of the multicast group. 7. Extension of the SGSN functionality by the ability to establish a logical transmission connection for several multicast contexts between SGSN and RNC that belong to the same multicast group and to save and update the list of multicast contexts of this transmission connection (if, for example, a user changes the RNC ). 8. Extension of the RNC functionality through the ability to save and update a list of multicast contexts or users that belong to a logical connection between RNC and SGSN. 9. Extension of the RNC functionality by the ability to map a logical transmission connection between RNC and SGSN (Iu-Bearer) to several logical transmission connections between RNC and user or UE (Radio Bearer). 10. Add the multicast group membership of a user in the registration message so that it can be saved in the SGSN, or can be forwarded by the SGSN to an external database (eg) HLR, where it is then saved.

Furthermore, the introduction of the efficient distribution of multicast messages is dealt with, particularly with regard to UMTS:

1. Entry of the MC group membership in a database

The IGMP protocol used on the Internet to record the subscribers of multicast groups is not well suited for UMTS. The "asking" (query, report) for the multicast group membership for all hosts, and thus also for those that do not contain any participants in the corresponding multicast group, leads to additional transmission complexity and thus increased bandwidth requirements.

In the context of this invention, the affiliation of subscribers to multicast groups is to be made in a central database (FIG. 19). In the UMTS core network, the HLR, HSS (home subscriber server), VLR, the SGSN or the GGSN can possibly be used for this.

Participants who join or want to leave a certain multicast group send a message, possibly via different network nodes, either directly to the database or to a network node, which in turn makes the entry in the database. The network node that is to make the entry in the database can be, for example, the SGSN. If a multicast message is now transmitted, a request is first made to this database as to whether and which subscribers belong to the corresponding multicast group.

The advantage of this method is that the affiliation of participants to multicast groups can be queried from a central database.

This avoids additional transmission complexity and the resulting additional bandwidth requirements as for the IGMP, as is practiced on the Internet, for example.

If necessary, the entry in the database can also be made separately from the UMTS network, for example by the network operator.

Design example:

For the exemplary embodiment, it is assumed that subscriber X wants to register with a multicast group. With the help of an appropriate application, he generates a registration request (subscriber message), which contains at least his identity (IMSI, IP address, etc.) and the MC address of the corresponding multicast group. He then sends this subscriber message via the RNC to the SGSN (Serving GPRS Support Node). The SGSN recognizes that this is a registration request and initiates an entry in the central database.

The addresses of the participants of the corresponding MC groups can be queried from the database for the transport of the MC messages to the participants. There is a mapping from subscriber to multicast group or ^" multitcast group to subscriber. With the help of this information from the Database in combination with the location information from the SGSN, which RNC serves the MC participants, the MC messages can now be transmitted to the corresponding SRNC and then to the MC participants.

2. MC context activation

After switching on a UE, the first step is to initiate a registration and authentication procedure. For this, the UE first goes into connected mode. The UE announces itself to the SGSN by establishing an RRC connection to the RNC and signaling to the SGSN.

The SGSN now knows, among other things, the identity of the UE and the RNC that supplies the corresponding UE. If there are no further actions by the UE (call setup, data transfer, etc.), it falls into idle mode. All connections are cleared down and the SGSN only has information about the identity of the UE and the routing area in which it is located.

The method presented here, referred to as "multicast context activation", describes the process flow of how a UE and its MC group affiliations familiarize themselves with the SGSN. After this procedure, the SGSN is still familiar with the identity and location information, but now also with the MC group affiliations of the UE.

One way of activating an MC context is for a UE to switch on its MC group membership to the SGSN ^" by default every time it is switched on and the subsequent registration and authentication procedure ⁽ default). bears (Figure 20). This information is stored in the SGSN and forms the MC context.

If the UE then falls into idle mode (in the event of no further actions by the UE), the SGSN must now also save the MC group membership information in addition to the information about the identity and the routing area of the UE.

It is also conceivable that the MC group membership information is queried by the SGSN from a database (see entry of the MC group membership in a database) by default (default) after switching on a UE and the subsequent registration and authentication procedure (Figure 21). This information is stored in the SGSN and forms the MC context. If the UE then falls into idle mode (if there are no further actions by the UE), the SGSN now stores the MC group information in addition to the information about the identity and the routing area of the UE.

Another possibility is that the MC

Group membership information is requested from the SGSN when a MC message or an MC message request arrives from a database (see entry of the MC group membership in a database) (FIG. 22). This information is stored in the SGSN and forms the MC context. The advantage of this variant is that the MC

Group membership information does not have to be stored permanently in the SGSN, but only when MC messages arrive or are transmitted. A timer can be initialized so that the MC group membership information does not have to be queried anew for each individual MC message of a specific group or even for each individual IP packet of an MC message. If the MC message is retransmitted before the timer has expired, the MC group information does not have to be queried again, since the information is stored during the running time of the timer.

Basically, there is an update of the MC group membership information in the SGSN when new members register for or leave an MC group (see section 1. Entry of the MC group membership in a database).

3. Establishing the connection paths and transmission of the MC messages

I. embodiment

For this example it is assumed that an MC message has been generated in the IP MC Center (MCC) and is now to be sent to the participants in this MC group. This MC message is addressed with the MC address of the corresponding MC group. The IP multicast center has the functionality of an IP MC router.

The MC message is now sent to all SGSNs (1st in Figure 23). Due to the activation of the MC context (see section 2. MC context activation) the SGSN is aware of the UEs and their MC group affiliations. The SGSN knows the UEs that are to receive the MC message and their routing areas (RA) in which the UEs are located.

If a UE that is a member of the corresponding MC group is in idle mode, the SGSN will now send an MC Message request sent to all RNCs in the routing area known to him (2nd in FIG. 23). This MC msg. -Request contains the identity of the UEs (e.g. IMSI. IP address or the like) and the MC address of the corresponding MC group. The RNCs then perform a paging of the UEs that are in the MC-Msg. -Request are named (3rd in Figure 23). These UEs now set up an RRC connection and radio bearer (RB) to the RNC and are then in connected mode (4th in FIG. 23).

If a UE that is a member of the corresponding MC group is already in connected mode, an MC msg. - Request from SGSN sent via the RNCs to the corresponding UEs which are members of the MC group (5th in FIG. 23). This MC msg. -Request contains the identity of the UEs (e.g. IMSI. IP address etc.) and the MC address of the corresponding MC group.

Since the UEs are already in connected mode (RRC connection exists), radio bearers (RB) (if not yet available) must now be set up for the RNC (6th in Figure 23).

Now that all UEs of the MC group are in connected mode and both an RRC connection and a radio bearer have been set up, each RNC that supplies members of the MC group will now set up one MC bearer per RNC for the SGSN ( 7. in Figure 23). An MC msg. -Confirm. , which is sent by the RNC via this MC bearer, now announces the SGSN's readiness of the UEs to be able to receive MC messages. The SGSN now has the information about where the UEs of the MC group are located and can now send the MC message to the corresponding RNCs via the MC bearer that was set up previously (8th in FIG. 23). With the mapping information (UE / MC group) from the MC-Msg. - Request, the MC message can now be transmitted to the UEs of the MC group (9th in Figure 23).

An SGSN that receives an MC message for a specific MC group but does not supply any members of this MC group does not need this message and can reject it. Another possibility is that the SGSN, if it does not have any members of the MC group, sends a Prune message (see RPM) back to the IP multicast center. This SGSN then receives no MC messages for the MC group until:

- the SGSN sends a join message to the IP-MC center, which signals the entry of a subscriber into an MC group (event-triggered).

- A predefined timer has expired.

It is also conceivable that the MC message, after it was generated in the MCC, is not immediately sent to all SGSNs (cf. 1. in FIG. 23). Instead, an MC message request can be sent to the SGSNs first (1st in

Figure 24).

The further procedures for establishing connections for the

Transmission of the MC message from the SGSN to the UEs of the MC group participants then remain the same (2nd to 7th in FIG

24).

After the MC-Msg. -Req. received at the SGSN (7th in Figure 24), a bearer (per SGSN) is now from the SGSN to

MCC established and there is an MC-Msg. -Req. to the MCC (8th in Figure 24).

Only now does the MCC send the MC message to all SGSNs to which bearers are set up and from whom it sends the MC msg. -Req. received ^' (9 ^" . in Figure 24). The further steps (10th and 11th in Figure 24) are again identical to 8th and 9th from Figure 23.

Another possibility is that after the arrival of the MC-Msg. -Req. at the SGSN (7th in FIG. 25) a bearer is now built up per RNC from the SGSN to the MCC (8th in FIG. 25). Via these RNC-specific bearers, the MC messages are now forwarded to the corresponding RNCs via the SGSN (9th in FIG. 25). With the mapping information (UE / MC group) from the MC-Msg. - Request, the MC message can now be transmitted to the UEs of the MC group (10th in Figure 25).

So that the connection paths (bearers) for the transmission of the MC messages to the individual UEs of an MC group do not have to be set up again for each individual MC message of a specific group or even for each individual IP packet of an MC message Timers are initialized. The connections (bearers) are now maintained until the timer has expired. If a MC message is retransmitted before the timer has expired, the MC message is transmitted via the still existing connection paths.

Another option is to dismantle the bearers by explicit signaling from the MCC, SGSN or both.

II. Embodiment

For this example it is again assumed that an MC message has been generated in the IP MC Center and now to

Participants in this MC group should be sent. This MC message is with the MC address of the corresponding MC group addressed. The IP multicast center has the functionality of an IP MC router.

Steps 1 to 6 are identical to those from method I.

Now that all UEs of the MC group are in connected mode and both an RRC connection and a radio bearer have been set up, each RNC that supplies members of the MC group will now set up an Iu bearer for each SGSN

(7th in Figure 26). An MC msg. -Confirm. , which is sent by the RNC via this Iu-Bearer, now announces the SGSN's readiness of the UEs to be able to receive MC messages. The SGSN now has the information on where the UEs of the MC group are located and can now send the MC message to the corresponding UE via the previously set up Iu-Bearer (8th in FIG. 26).

- The SGSN sends a join message to the IP-MC center, which signals the entry of a subscriber into an MC group (event-triggered). - A predefined timer has expired.

It is also conceivable that the MC message, after it was generated in the MCC, is not immediately sent to all SGSNs (see 1. in FIG. 26). Instead, an MC message request can also be sent to the SGSNs first (1st in FIG. 27).

The further procedures for establishing the connections for the transmission of the MC message from the SGSN to the UEs of the MC group participants then remain the same (2nd to 7th in FIG. 27).

After the MC-Msg. -Req. received at the SGSN (7th in Figure 27), a bearer (per SGSN) is now set up from the SGSN to the MCC and an MC-Msg takes place. -Req. to the MCC (8th in figure 27).

Only now does the MCC send the MC message to all SGSNs to which bearers are set up and from whom it sends the MC msg. -Req. received (9th in Figure 27). The transmission of the MC message via the Iu bearer to the UEs of the MC group is now identical to that from FIG. 26.

Another possibility is that after the arrival of the MC-Msg. -Req. with the SGSN (7th in FIG. 28) a bearer is now set up for each UE from the SGSN to the MCC (8th in FIG. 28). Via these UE-specific bearers, the MC messages are now forwarded to the corresponding UEs via the SGSNs and the RNCs (9th in FIG. 28).

So that the connection paths (bearers) for the transmission of the MC messages to the individual UEs of an MC group do not have to be re-established for each individual MC message of a certain group or even for each individual IP packet of an MC message. a timer can be initialized. The connections (bearers) are now maintained until the timer has expired. If the MC message is retransmitted before the timer expires , the MC message is transmitted via the still existing connection paths.

Another option is to dismantle the bearers by means of explicit signaling based on the MCC, SGSN or both.

Further information, definitions, functional information on the radio network elements of UMTS can be found in particular in the following specifications:

• 3G TS 23.002 V3.3.0, Technical Specification Group Services and Systems Aspects, Network architecture, Release 1999

• 3G TR 21.905 V3.2.0, Technical Specification Group Services and Systems Aspects, Vocabulary for 3GPP Specifications, Release 1999

• 3G TS 23.060 V3.4.0, Technical Specification Group Services and Systems Aspects, General Packet Radio Service (GPRS), Service description, Stage 2, Release 1999

The following abbreviations have been used in conjunction with the description of the invention:

Basically: majority formation by appending an 's', e.g. one RB, two RBs

CN Core Network PDP Packet Data Protocol

GGSN Gateway GPRS Support PLMN Public Land Mobile Network

node

GPRS General Packet Radio RNC Radio Network Controller

Service ^" ~

GSM Global- System for Mo- RNS Radio Network Subsystem bile Communications HLR Home Location RegisRPM Reverse Path Multicasting ter

HSS Home Subscriber SerSGSN Serving GPRS Support Node ver

IGMP Internet Group ManaUE User Equipment gement Protocol

IMSI International Mobile UMTS Universal Mobile Telecom Subscriber Identity communication system

IP Internet Protocol UTRAN UMTS Terrestrial Radio Access Network

MC Multicast VLR Velocity Location Register

MCC multicast center

MM Mobility Management

MS Mobile Station

MSC Mobile Switching Center

MSISDN MS International ISDN Number

SM session management

Claims

claims

1. Method for distributing a group message (GNl) to at least one group (A) of subscriber devices of a radio communication system (FN2), the one or more subscriber devices of the respective group (A) in at least one storage device (SP1) under a common identification address (IDA) have been filed and are continuously updated there, with the distribution of the respective group message (GNl) by at least one multicast center (MCC) to the member subscriber devices (UE1, UE2, UE4, UE5) of a selected group (A) this group message (GNl) to be distributed is only sent via a common transmission path (GP) to at least one higher-level radio network control unit (SGSNl), by means of the storage device (SPl) the currently associated subscriber devices (UE1, UE2, UE4, UE5) to be notified this selected group (A) determined, and this of the higher-level radio network control unit (SGSNl) m it, and then this higher-level radio network control unit (SGSNl) at least one transmission path (UP11) for distributing the group message (GNl) to the determined subscriber devices (UE1, UE2, UE4, UE5) of the selected group (A) With the help of one or more subordinate radio network control units (RNCl) is provided.

2nd Method according to Claim 1, characterized in that the distribution of the group message (GNl) in a UMTS (Universal Mobile Telecommunication System), GPRS (General Packet Radio Service), EDGE (enhanced data rates ^" gate GSM ^" ) vironments), and / or OFDM (Orthogonal Frequency Division Multiplexing) radio communication system is carried out ^' .

3. The method as claimed in one of the preceding claims, that a serving GPRS support node from UMTS is used in each case as a higher-level radio network control unit (SGSNl).

4. The method according to any one of the preceding claims, that a radio network controller from UMTS is used as the subordinate radio network control unit (RNCl).

5. The method as claimed in one of the preceding claims, that the respective subordinate radio network control unit (RNCl) initiates a connection setup to the base station (BS11, BS12) in its coverage area in whose radio cell the subscriber device (UE4) to be notified is located.

6. The method as claimed in one of the preceding claims, so that only a single, common transmission path (GP11) is set up for the transmission of the group message (GNl) from the higher-level radio network control unit (SGSNl) to the respectively assigned, lower-level radio network control unit (RNCl).

7. The method according to any one of the preceding claims, characterized in that that the at least one storage device (SPl) is managed and managed centrally in the radio communication system (FN2).

8. The method according to any one of the preceding claims, d a d u r c h g e k e n n z e i c h n e t that a mobile device, in particular a cellular telephone, is used as the subscriber device (UEl).

9. Radio communication system (FN2) for distributing a group message (GNl) to at least one group (A) of subscriber devices, in particular according to one of the preceding claims, wherein at least one storage device (SPl) is provided in which one or more subscriber devices (UE1, UE2 , UE4, UE5) of the respective group (A) can be filed under a common identification address (IDA) and continuously updated there, at least one multicast center (MCC) being provided, with the aid of which a new group message (GNl) is sent when a distribution request is made the member subscriber devices (UE1, UE2, UE4, UE5) of a selected group (A) can be sent to at least one higher-level radio network control unit (SGSNl) on a common transmission path (GP), the storage device (SPl) being designed such that the currently associated subscriber devices (UE1, UE2, UE4, UE5) of this selected group (A) to be determined, un d these can be communicated to the higher-level radio network control unit (SGSNl), and the higher-level radio network control unit (SGSNl) and / or its respective operatively connected lower-level radio network control unit (RNCl) are designed such that at least one transmission path (UP11) from this higher-level radio network control unit ^" (SGSNl) for distribution of the ^" group message (GNl) to the determined members member subscriber devices (UE1, UE2, UE4, UE5) can be provided.