WO2005027410A1 - Method and device for a multicast service - Google Patents

Method and device for a multicast service Download PDF

Info

Publication number
WO2005027410A1
WO2005027410A1 PCT/EP2004/051547 EP2004051547W WO2005027410A1 WO 2005027410 A1 WO2005027410 A1 WO 2005027410A1 EP 2004051547 W EP2004051547 W EP 2004051547W WO 2005027410 A1 WO2005027410 A1 WO 2005027410A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
network element
users
command
parameter
Prior art date
Application number
PCT/EP2004/051547
Other languages
German (de)
French (fr)
Inventor
Michael Eckert
Josef Laumen
Holger Schmidt
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2005027410A1 publication Critical patent/WO2005027410A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0219—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave where the power saving management affects multiple terminals
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to a method for a multicast service.
  • Such methods are used, inter alia, in third generation mobile radio devices, such as mobile radio devices of the UMTS (Universal Mobile Telecommunication Standard) standards.
  • UMTS Universal Mobile Telecommunication Standard
  • Distribution addressing is the data to all recipients of the
  • Network or a sub-area thereof regardless of whether they want to receive the message or not.
  • Each of these types of addressing has specific advantages and disadvantages. Single addressing is most efficient when a message only needs to be sent to one participant. If, on the other hand, several subscribers are to receive the same message, group addressing has advantages over individual addressing, since in this way the message does not have to be sent to each recipient individually. This considerably reduces the network load. This is of crucial importance in particular in cellular mobile radio networks, since only a limited bandwidth for transmitting the data via the radio interface Is available and therefore this resource must be used very efficiently.
  • the timing of the procedures for providing the MBMS (Multimedia Broadcast / Multicast Service) service is known from the technical specification TS23.246 "MBMS Architecture and Functional Description, Release 6" of the 3GPP (Third Generation Partnership Project).
  • a user can register for a specific multicast service that can be selected by the user. Users who currently want to receive data from a specific multicast service are combined to form a service-specific multicast group which is clearly identified by a multicast identifier, a so-called "multicast identifier", i.e. an Internet protocol address "IP address" at the network layer level.
  • the registration for a multicast service signifies the consent of a user to receive the corresponding MBMS services of a mobile network operator.
  • service announcement in which the user requests information from the network with the aid of which reception data from an MBMS service is possible.
  • This information includes, among other things, a (possibly comprehensive) list of the available MBMS services, the Internet protocol address of the multicast service or the corresponding multicast group and start time of the service and the radio channel parameters necessary for reception.
  • the user can also obtain this information automatically from the network.
  • a user actively enters an MBMS group.
  • the user signals to the network that he currently wants to receive data from the corresponding group.
  • the so-called “session start” the necessary resources for transferring the MBMS data from the network to the user or to their mobile stations.
  • the MBMS data can be transferred after a defined period of time. Then the data transfer takes place.
  • FIG. 1 shows the chronological sequence of the signaling messages within the MBMS architecture to activate the MBMS service or to receive data from this service and thus the joining procedure.
  • the units involved are a mobile station UE, which is called "User Equipment” in UMTS, a RAN (Radio Access Network), an SGSN (Serving GPRS (General Packet Radio Service) Support Node), a GGSN (Gateway GPRS Support Node) ) and a BM-SC (Broadcast Multicast Service Center).
  • a joining command 2 the so-called "IGMP Join” command, is sent from the terminal UE to the network element GGSN.
  • a joining command 3 the so-called "IGMP Join” command.
  • BMSC signaling between GGSN and BMSC 3.
  • the GGSN then sends an MBMS
  • the SGSN requests the terminal UE to activate an MBMS context 5.
  • the UE then activates the MBMS context 6.
  • Security functions are then exchanged between the UE and SGSN in order to authenticate the UE 7 Next
  • Step the SGSN sends the GGSN a command to generate an MBMS context request 8.
  • the GMSN and BMSC then exchange the BMSC signaling 9.
  • the GGSN then sends a command to generate the MBMS context to the SGSN 10.
  • US Pat. No. 6,078,954 describes a method for managing multicast addresses for a large number of users and for assigning the user into specific multicast groups depending on their multicast address.
  • the method known from this publication has the disadvantage that it is not possible for a user to find out the composition of a multicast group.
  • a user when enrolling in a multicast group, a user does not have the option of deciding who should join the multicast group through a possible query of the multicast group.
  • the present invention is therefore based on the object of providing a method for multicast transmissions which avoids the disadvantages of the prior art.
  • a terminal sends a command to actively join a multicast group to a network element , the command providing at least one parameter which is irrelevant for active entry and in its place information is sent which causes the network element to initiate a user query with regard to user data.
  • querying the members who are registered for this service ie the so-called “subscription”
  • querying the users who are currently receiving data from this MBMS service the so-called “joining”.
  • a user can find out whether one or more other users generally have data on a particular MBMS group, that is, data of the multicast service associated with this group. It is also possible to query whether a user is currently receiving data from this service.
  • the command is preferably a command of the IGMP (Internet Group Management Protocol) or the MLD (Multicast Listener Discovery) protocol.
  • the IGMP protocol is described in the RFC3376 "Internet Group Management Protocol (IGMP)" specification by the IETF (Internet Engineering Task Force).
  • the MLD protocol is described in the technical specification RFC3710 "Multicast Listener Discovery (MLD) for Ipv6" of the IETF. Both protocols are used in a similar way, with the difference that the MLD protocol uses IPv ⁇ message types instead of IPv4
  • the command to actively join the multicast group is preferably the "IPMulticastListen" command of the IGMP (Internet Group Management Protocol) protocol.
  • the communication system is preferably a communication system of the third mobile radio generation, in particular a system based on the UMTS standard.
  • the present invention is not limited to communication systems based on the UMTS standard. Rather, it is also conceivable to extend the present invention to fixed network-based communication systems.
  • the terminal is preferably a terminal according to the UMTS standard. Accordingly, the network elements are preferably elements of a packet-switched core network that is independent of radio access technology, a so-called “core network”.
  • the users registered for a multicast service and / or the users who are from a multicast service are used as user data Receive current data, sent from the core network to the end device.
  • the present invention is not limited to this user data. It is conceivable that the user data contain a complete report on all users of multicast services or groups, ie their entirety.
  • a network element queries the user data in a database and transmits this to the terminal.
  • At least the number of anonymous users is preferably sent as user data from a network element to the terminal.
  • a network element transmits the user data to the terminal with which an anonymity attribute is not connected.
  • the command provides a further parameter which is irrelevant for the active entry and in its place information is sent which signals a network element for which user the user query is to be made. With this information, the user of the terminal can select in advance from which user he is interested in the user data.
  • the task stated at the outset is also achieved by a method for anonymous activation of the reception of messages from a multicast service in a communication system, in which a terminal sends a command to actively join a multicast group to a network element, in which the command is provided at least one parameter which is irrelevant for the active entry, in its place information is sent which causes a network element to carry out the activation anonymously with respect to other users.
  • the command in turn is preferably the command of the IGMP protocol "IPMulticastListen".
  • the terminal or network element is again preferably a terminal according to the UMTS standard or a network element GGSN, the invention again not being limited to communication systems according to the UMTS standard, but being transmitted to any other type of communication system can.
  • the joining of the terminal or its user to the multicast group is preferably not specified when the users or members of the multicast group are queried. This has the advantage that a joining user can be sure that his joining cannot be checked by another user. This promotes the willingness of users to join a multicast group.
  • the invention further relates to a mobile terminal for use in a method according to the invention.
  • FIG. 2 shows the sequence of the query of the members belonging to an MBMS group or of the users who receive data from an MBMS group by means of the IGMP "join"message;
  • Figure 3 shows an embodiment of the data which are transmitted to a terminal;
  • FIG. 4 shows a flow chart for querying multicast groups and for anonymous joining into a multicast group
  • FIG. 5 shows a further flow chart for querying multicast groups and for anonymous joining into a multitask group.
  • FIG. 2 shows the message flow when querying the users who receive data from an MBMS group using the IGMP "join” message.
  • the "join” message is part of the IGMP protocol (Inter Group Management Protocol).
  • the IGMP "join” message has the following syntax:
  • IPMulticastListen (socket, interface, multicast address, exclude, ⁇ ).
  • the “socket” parameter is used to distinguish between different entities, such as programs or processes, within the UE.
  • the "Sockef parameter can therefore represent, for example, a port number, a so-called” port number ".
  • The” Interface “parameter serves to specify the interface at which the terminal UE expects the MBMS messages, for example the interprotocol Address or another unique address of the end device, such as MS-ISDN (Mobile Station International Subscriber Nu ber) or IMSI (International Mobile Subscriber Identifier.)
  • the "multicast address” is the Internet protocol address of the multicast group or the multicast identifier from which the UE wants to receive data. This parameter therefore gives the desired MBMS Service.
  • the last two parameter values "Exclude” and " ⁇ " are not relevant in the 3GPP standard.
  • the IGMP protocol they are used to filter the source of the multicast message. With the aid of these parameters, the IGMP protocol offers the option of receiving only multicast data from certain sources or excluding certain sources from reception.
  • the Internet protocol addresses of the corresponding sources are specified in the "Source List” parameter, the value of which contains an empty amount in the specified IGMP "Join” message.
  • the IGMP messages are transmitted within an Ipv4 datagram.
  • the last two parameters of the "IPMulticastListen" command which are not required within the UMTS system, but still have to be transmitted, are expanded so that they are used to query the members of the MBMS group specified by the "Multicast address" parameter can be used.
  • Another option is the IGMP parameter list
  • FIG. 2 shows the network elements UE, RAN, SGSN, GGSN already explained with reference to FIG. 1 and additionally an MBMS database.
  • the extended IGMP "join” message 2 is sent from the terminal UE to the GGSN via the PDP context.
  • the GGSN recognizes on the basis of the existing message fields that this message is not an activation of data reception, the multicast group specified by the parameter value in the "Multicast address" field, but a user query. Using the information it contains, the GGSN queries the corresponding data in a database. The information requested is then transmitted from the GGSN to the UE.
  • the multicast service associated with the multicast group and the multicast identifier are also preferably part of the list.
  • FIG. 3 shows a possible structure of the data to be transmitted to the terminal UE.
  • the data contain the multicast identifier, the multicast service, the number of user identities, the respective identity of the users and the number of anonymous users. It is also conceivable to specify the first and last name, the MS-ISDN of the user, the Internet protocol address, but also any other unique identification.
  • an anonymous activation of the data reception of an MBMS service should also be possible. It is expedient for the query described that a user can register anonymously for a service and can also receive data of this service anonymously.
  • the IGMP "Join" message ie the specified "IPMulticastListen” -
  • IPMulticastListen is expanded so that the anonymity request of the user can be transmitted.
  • FIG. 4 shows a flowchart for processing a "join” message.
  • the parameters of the last two parameters here “filter mode” and “source list” are not required in the "IPMulticastListen” message in communication systems based on the UMTS standard and are therefore expanded.
  • two additional values are introduced to query the users for the third parameter of the "IPMulticastListen” message “Filter mode” of the IGMP protocol. These values are here with “Subscribe” and
  • “Join” denotes. “Subscribe” stands for the query of the users who are registered for the multicast service, the is associated with the multicast identifier contained in the "multicast address” parameter. “Join” stands for the query of users who receive data from the MBMS service, ie are members of the multicast group specified via the "multicast-address” parameter. If one of these parameters is contained in the "IPMulticastListen” message, the GGSN recognizes that this message is a user query.
  • the "join” message is received first.
  • the "filter mode” parameter is evaluated in the "Join” message. , If this parameter is equal to an “Exclude” value, it is a conventional "join” message. However, if the "filter mode” parameter takes neither the value “Exclude” nor the value “anonymous”, there is an extended “Join” message. If the "filter mode” parameter is now the “join” parameter value, the users of the multicast group associated with the multicast identifier are queried. If the "filter mode” parameter is the "Suscribe” parameter value, the users of the multicast service associated with the multicast identifier are queried. The "Source Filter” parameter is then evaluated.
  • this parameter takes the value " ⁇ "
  • this is a general user query ie all members of the specified multicast group or the associated multicast service are queried.
  • the "Source Filter” parameter contains a list of users, only their affiliation with the specified multicast service or multicast group is queried.
  • the GGSN can then send the user identities back to the terminal UE with which the anonymity attribute is not connected. This is advantageous because an additional specification of the number of anonymously registered users contradicts the basic idea of anonymity.
  • the terminal UE queries only one user. In this case, the UE sends an answer received, which has the value "0" as the value for the parameter "number of user identities” and contains the value "1” for the value "number of anonymous users”, anonymity is no longer guaranteed.
  • the further exemplary embodiment according to FIG. 5 shows a method in which the parameter list of the IGMP "Join” or "IPMulticastListen” command is expanded by two parameters. Furthermore, this exemplary embodiment describes how the “join” message is to be expanded so that a user can register anonymously for an MBMS group.
  • the "join” message is expanded by the parameters designated "query type", “query identity” and “privacy”. The first two parameters are used to query the user and the third parameter is used to implement anonymous registration for a multicast group.
  • the extended IGMP "Join” or "IPMulticastListen” message can be defined as follows:
  • IPMulticastListen ocket, interface, multicast address, exclude, ⁇ , privacy, query type, query identity).
  • the "Privacy” parameter can take the values “anonymous” or "NIL".
  • the values are for the "Query-Type" parameter
  • the parameter “query identity” can contain a list of user identities or can also remain empty, that is to say contain the value "NIL” or " ⁇ ".
  • a "join” message is received.
  • the "Query-Type” parameter is evaluated in the "Join” message. If this parameter is equal to "NIL”, it is recognized that it is a “join” message for registration in a multicast group.
  • the "Privacy” parameter is then evaluated. If this is equal to the value "NIL”, then a non-anonymous enrollment in the specified multi cast group. If this parameter value is "anonymous”, an anonymous registration in the specified multicast group takes place accordingly.
  • the "Receive" message originally received with the "Query-Type” parameter is a value not equal to "NIL", then it is an extended "Join” message for user query.
  • the parameter "Query-Type” is evaluated in this message. If this is equal to "join”, the user of the multicast group associated with this multicast identifier is queried. If the "Query-Type” parameter is "Suscribe”, the users of the multicast service associated with the multicast identifier are queried. The “Query Identity” parameter is then evaluated. If this is not equal to " ⁇ ”, the user specified via this parameter is queried. If the parameter "Query Identity” is equal to the value " ⁇ ”, all members are queried.
  • the expansion of the IGMP protocol described in this exemplary embodiment by additional parameters or information elements is particularly advantageous if the functionality introduced with it is not only used in UMTS communication networks, but is generally used in networks based on the Internet protocol. In this case, the expansion of the IGMP protocol (version 3) explained above is particularly expedient.
  • the described use or extension of already existing parameters has the particular advantage that no change to the IGMP protocol and the MBMS multicast service activation procedure is necessary.
  • the UMTS-specific query of multicast groups can be implemented quickly and easily and thus represents a 3GPP-specific extension of the IGMP protocol.
  • the present invention offers the advantages of introducing a method for querying the members of a multicast or MBMS group and the users who have subscribed to a multicast service.
  • This query can be differentiated into the query of all participants and / or the query of specific participants.
  • the answer to this query can include the desired list of participants and also an indication of the number of anonymously registered participants.
  • the enrollment for a multicast or MBMS group is expanded by an anonymity attribute. This method can be implemented by expanding the IGMP "join" message.

Abstract

The invention relates to a method for calling up users registered for a multicast service or users currently receiving data from a multicast service in a communication system, wherein a command is sent from a terminal (UE) to a network element (GGSN) for active accession to a multicast group. At least one irrelevant parameter for active accession is provided in the command, whereby information is sent in the place thereof, causing the network element (GGSN) to initiate a user inquiry in relation to user data.

Description

Beschreibungdescription
VERFAHREN UND VORRICHTUNG FÜR EINEN MULTICAST-DIENSTMETHOD AND DEVICE FOR A MULTICAST SERVICE
Die vorliegende Erfindung betrifft ein Verfahren für einen Multicast-Dienst .The present invention relates to a method for a multicast service.
Derartige Verfahren werden unter Anderem in Mobilfunkgeräten der dritten Generation, wie beispielsweise Mobilfunkgeräten des UMTS (Universal Mobile Telecommunication Standard) - Standards, eingesetzt.Such methods are used, inter alia, in third generation mobile radio devices, such as mobile radio devices of the UMTS (Universal Mobile Telecommunication Standard) standards.
Um Daten innerhalb eines Netzwerkes effizient zu verteilen, existieren eine Reihe von Adressierungsverfahren. Die meisten Netzwerke unterstützen die drei grundlegenden Arten der Adressierung, das heißt die Einzeladressierung, das sogenannte "Unicast", die Gruppenadressierung, das sogenannte "Multicast", und die Verteiladressierung, das sogenannte "Broad- cast" . Bei der Einzeladressierung werden die Datenpakete an einen Empfänger adressiert und separat zu diesem gesendet, i während bei der Gruppenadressierung ein Datenpaket an einen logischen Verbund von Empfängern verschickt wird. Bei derTo efficiently distribute data within a network, there are a number of addressing methods. Most networks support the three basic types of addressing, that is to say the single addressing, the so-called "unicast", the group addressing, the so-called "multicast", and the distribution addressing, the so-called "broadcast". In the case of individual addressing, the data packets are addressed to a recipient and sent separately to the recipient, i while in group addressing a data packet is sent to a logical group of recipients. In the
Verteiladressierung werden die Daten an alle Empfänger desDistribution addressing is the data to all recipients of the
Netzwerkes oder eines Teilbereiches hiervon gesendet, unab- hängig davon, ob diese die Nachricht empfangen möchten oder nicht. Jede dieser Adressierungsarten weist spezifische Vor- und Nachteile auf. Die Einzeladressierung ist am Effizientesten, wenn eine Nachricht nur an einen Teilnehmer gesendet werden muss. Sollen dahingegen mehrere Teilnehmer ein- und dieselbe Nachricht erhalten, so weist die Gruppenadressierung Vorteile gegenüber der Einzeladressierung auf, da auf diese Weise die Nachricht nicht an jeden Empfänger einzeln verschickt werden muss. Dadurch wird die Netzlast erheblich reduziert. Dies ist insbesondere in zellularen Mobilfunknetzen von entscheidender Bedeutung, da über die Funkschnittstelle nur eine begrenzte Bandbreite zur Übertragung der Daten zur Verfügung steht und somit diese Ressource sehr effizient genutzt werden muss.Network or a sub-area thereof, regardless of whether they want to receive the message or not. Each of these types of addressing has specific advantages and disadvantages. Single addressing is most efficient when a message only needs to be sent to one participant. If, on the other hand, several subscribers are to receive the same message, group addressing has advantages over individual addressing, since in this way the message does not have to be sent to each recipient individually. This considerably reduces the network load. This is of crucial importance in particular in cellular mobile radio networks, since only a limited bandwidth for transmitting the data via the radio interface Is available and therefore this resource must be used very efficiently.
Aus der technischen Spezifikation TS23.246 "MBMS Architecture and Functional Description, Release 6" des 3GPP (Third Generation Partnership Project) ist der zeitliche Ablauf der Prozeduren zur Bereitstellung des MBMS (Multimedia Broad- cast/Multicast Service) -Dienstes bekannt. Dabei kann sich ein Nutzer zu einem bestimmten, durch den Nutzer wählbaren, Mul- ticast-Dienst einschreiben. Nutzer, die aktuell Daten eines bestimmten Multicast-Dienstes empfangen möchten, werden zu einer dienstleistungsspezifischen Multicast-Gruppe zusammen- gefasst, die eindeutig durch eine Multicast-Kennung, einem sogenannten "Multicast-Identifier" , das heißt, z.B. einer In- ternetprotokolladresse "IP-Adresse" auf Ebene der Netzwerkschicht, gekennzeichnet ist. Die Einschreibung zu einem Multicast-Dienst bezeichnet das Einverständnis eines Nutzers, entsprechende MBMS-Dienste eines Mobilfunknetzbetreibers zu emp angen. Anschließend erfolgt eine Dienst-Bekanntgabe- Prozedur (Service Announcement) , innerhalb welcher der Nutzer Informationen vom Netzwerk anfordert, mit deren Hilfe ein Empfang von Daten eines MBMS-Dienstes möglich ist. Diese Informationen enthalten unter Anderem eine (möglicherweise umfassende) Liste der verfügbaren MBMS-Dienste, die Internet- protokoll-Adresse des Multicast-Dienstes beziehungsweise der entsprechenden Multicast-Gruppe und Startzeit des Dienstes und die zum Empfang notwendigen Funkkanalparameter. Alternativ kann der Nutzer diese Informationen auch automatisch vom Netzwerk beziehen.The timing of the procedures for providing the MBMS (Multimedia Broadcast / Multicast Service) service is known from the technical specification TS23.246 "MBMS Architecture and Functional Description, Release 6" of the 3GPP (Third Generation Partnership Project). A user can register for a specific multicast service that can be selected by the user. Users who currently want to receive data from a specific multicast service are combined to form a service-specific multicast group which is clearly identified by a multicast identifier, a so-called "multicast identifier", i.e. an Internet protocol address "IP address" at the network layer level. The registration for a multicast service signifies the consent of a user to receive the corresponding MBMS services of a mobile network operator. Then there is a service announcement procedure (service announcement) in which the user requests information from the network with the aid of which reception data from an MBMS service is possible. This information includes, among other things, a (possibly comprehensive) list of the available MBMS services, the Internet protocol address of the multicast service or the corresponding multicast group and start time of the service and the radio channel parameters necessary for reception. Alternatively, the user can also obtain this information automatically from the network.
In der Beitritts-Prozedur, dem sogenannten "Joining", tritt ein Nutzer aktiv in eine MBMS-Gruppe ein. Mit dem Eintritt des Nutzers in eine Multicast-Gruppe signalisiert der Nutzer dem Netzwerk, dass er aktuell Daten der entsprechenden Gruppe empfangen möchte. Beim anschließenden Start des Modus, dem sogenannten "Session-Start", stehen die notwendigen Ressourcen zur Übertragung der MBMS-Daten vom Netzwerk zu den Nut- zern beziehungsweise zu deren Mobilstationen zur Verfügung. Die Übertragung der MBMS-Daten kann nach einer definierten Zeitspanne erfolgen. Anschließend findet der Datentransfer statt.In the so-called "joining" procedure, a user actively enters an MBMS group. When the user enters a multicast group, the user signals to the network that he currently wants to receive data from the corresponding group. When the mode is started, the so-called "session start", the necessary resources for transferring the MBMS data from the network to the user or to their mobile stations. The MBMS data can be transferred after a defined period of time. Then the data transfer takes place.
Figur 1 zeigt den zeitlichen Ablauf der Signalisierungsnach- richten innerhalb der MBMS-Architektur zur Aktivierung des MBMS-Dienstes beziehungsweise des Empfangs von Daten dieses Dienstes und somit der Beitritts-Prozedur. Die beteiligten Einheiten sind eine Mobilstation UE, welche "User Equipment" in UMTS genannt wird, ein RAN (Radio Access Network) , ein SGSN (Serving GPRS (General Packet Radio Service) Support No- de) , ein GGSN (Gateway GPRS Support Node) und ein BM-SC (Broadcast-Multicast Service Center) .FIG. 1 shows the chronological sequence of the signaling messages within the MBMS architecture to activate the MBMS service or to receive data from this service and thus the joining procedure. The units involved are a mobile station UE, which is called "User Equipment" in UMTS, a RAN (Radio Access Network), an SGSN (Serving GPRS (General Packet Radio Service) Support Node), a GGSN (Gateway GPRS Support Node) ) and a BM-SC (Broadcast Multicast Service Center).
Zuerst erfolgt eine PDP-Kontextaktivierung 1. Anschließend wird ein Beitrittsbefehl 2, der sogenannten "IGMP Join"- Befehl von dem Endgerät UE zu dem Netzwerkelelement GGSN geschickt. Danach erfolgt eine BMSC-Signalisierung zwischen GGSN und BMSC 3. Daraufhin sendet die GGSN eine MBMS-First there is a PDP context activation 1. Subsequently, a joining command 2, the so-called "IGMP Join" command, is sent from the terminal UE to the network element GGSN. This is followed by BMSC signaling between GGSN and BMSC 3. The GGSN then sends an MBMS
Bekanntmachungsanfrage an den SGSN 4. Der SGSN fordert das Endgerät UE danach auf, einen MBMS-Kontext zu aktivieren 5. Daraufhin aktiviert der UE den MBMS-Kontext 6. Anschließend werden Sicherheitsfunktionen zwischen UE und SGSN ausge- tauscht, um das UE zu authentifizieren 7. Als nächsterAnnouncement request to the SGSN 4. The SGSN then requests the terminal UE to activate an MBMS context 5. The UE then activates the MBMS context 6. Security functions are then exchanged between the UE and SGSN in order to authenticate the UE 7 Next
Schritt sendet der SGSN dem GGSN einen Befehl zum Generieren einer MBMS-Kontextanfrage 8. Zwischen GGSN und BMSC erfolgt danach ein Austausch der BMSC-Signalisierung 9. Daraufhin wird vom GGSN ein Befehl zum Generieren des MBMS-Kontextes an den SGSN geschickt 10. Schließlich sendet das SGSN den Befehl "Aktiveren der MBMS-Kontextakzeptierung 11" an das UE . Weitere Einzelheiten der Signalisierung können der oben angegebenen technischen Spezifikation TS23.246 entnommen werde, auf welcher an dieser Stelle verwiesen wird.Step the SGSN sends the GGSN a command to generate an MBMS context request 8. The GMSN and BMSC then exchange the BMSC signaling 9. The GGSN then sends a command to generate the MBMS context to the SGSN 10. Finally sends the SGSN issues the command "Activate MBMS context acceptance 11" to the UE. Further details of the signaling can be found in the technical specification TS23.246 given above, to which reference is made here.
Aus der US 6,078,954 ist ein Verfahren zum Verwalten von Mul- ticast-Adressen für eine Vielzahl von Nutzern und zum Zuord- nen der Nutzer in spezifische Multicast-Gruppen in Abhängigkeit von ihrer Multicast-Adresse bekannt. Das aus dieser Druckschrift bekannte Verfahren hat jedoch den Nachteil, dass es einem Nutzer nicht möglich ist, die Zusammensetzung einer Multicast-Gruppe zu erfahren. Darüber hinaus hat ein Nutzer beim Einschreiben in eine Multicast-Gruppe nicht die Möglichkeit zu entscheiden, wem sein Beitritt in die Multicast- Gruppe durch eine mögliche Abfrage der Multicast-Gruppe sichtbar sein soll.US Pat. No. 6,078,954 describes a method for managing multicast addresses for a large number of users and for assigning the user into specific multicast groups depending on their multicast address. However, the method known from this publication has the disadvantage that it is not possible for a user to find out the composition of a multicast group. In addition, when enrolling in a multicast group, a user does not have the option of deciding who should join the multicast group through a possible query of the multicast group.
Somit liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren für Multicast-Übertragungen bereitzustellen, welches die Nachteile des Standes der Technik vermeidet.The present invention is therefore based on the object of providing a method for multicast transmissions which avoids the disadvantages of the prior art.
Diese Aufgabe wird durch die Verfahren mit den Merkmalen der Patentansprüche 1 und 6 gelöst. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Patentansprüchen.This object is achieved by the method with the features of claims 1 and 6. Advantageous developments of the invention result from the dependent patent claims.
Bei dem erfindungsgemäßen Verfahren zum Abfragen von für einen Mulitcast-Dienst eingeschriebenen Nutzern beziehungsweise von Nutzern, welche von einem Multicast-Dienst aktuell Daten empfangen, in einem Kommunikationssystem, wird von einem Endgerät ein Befehl zum aktiven Beitritt in eine Multicast- Gruppe an ein Netzwerkelement gesendet, wobei in dem Befehl mindestens ein für den aktiven Beitritt irrelevanter Parameter vorgesehen ist, an dessen Stelle Informationen gesendet werden, die das Netzwerkelement veranlassen, eine Nutzerabfrage hinsichtlich von Nutzerdaten zu initiieren.In the method according to the invention for querying users registered for a multicast service or users who are currently receiving data from a multicast service in a communication system, a terminal sends a command to actively join a multicast group to a network element , the command providing at least one parameter which is irrelevant for active entry and in its place information is sent which causes the network element to initiate a user query with regard to user data.
Bei dem erfindungsgemäßen Verfahren kann zwischen der Abfrage der Mitglieder unterschieden werden, die für diesen Dienst eingeschrieben sind, d.h. die sogenannte "Subscription", und der Abfrage der Nutzer, die gerade Daten dieses MBMS-Dienstes empfangen, das sogenannte "Joining". Durch die Einführung dieser Abfrage kann sich ein Nutzer darüber informieren, ob ein oder mehrere andere Nutzer generell Daten einer bestimm- ten MBMS-Gruppe, das heißt Daten des mit dieser Gruppe assoziierten Multicast-Dienstes, erhalten. Darüber hinaus ist es möglich, abzufragen, ob ein Nutzer aktuell Daten dieses Dienstes empfängt.In the method according to the invention, a distinction can be made between querying the members who are registered for this service, ie the so-called "subscription", and querying the users who are currently receiving data from this MBMS service, the so-called "joining". By introducing this query, a user can find out whether one or more other users generally have data on a particular MBMS group, that is, data of the multicast service associated with this group. It is also possible to query whether a user is currently receiving data from this service.
Bevorzugt handelt es sich bei dem Befehl um einen Befehl des IGMP (Internet Group Management Protocol)- oder des MLD (Multicast Listener Discovery) -Protokolls . Das IGMP-Protokoll wird in der Spezifikation RFC3376 "Internet Group Management Protocol (IGMP)" der IETF (Internet Engineering Task Force) beschrieben. Das MLD-Protokoll wird in der technischen Spezifikation RFC3710 "Multicast Listener Discovery (MLD) for Ipv6" des IETF beschrieben. Beide Protokolle werden in einer ähnlichen Art und Weise verwendet, mit dem Unterschied, dass das MLD-Protokoll IPvβ-Nachrichtentypen anstelle von IPv4-The command is preferably a command of the IGMP (Internet Group Management Protocol) or the MLD (Multicast Listener Discovery) protocol. The IGMP protocol is described in the RFC3376 "Internet Group Management Protocol (IGMP)" specification by the IETF (Internet Engineering Task Force). The MLD protocol is described in the technical specification RFC3710 "Multicast Listener Discovery (MLD) for Ipv6" of the IETF. Both protocols are used in a similar way, with the difference that the MLD protocol uses IPvβ message types instead of IPv4
Nachrichtentypen verwendet. Zur näheren Erläuterung wird auf diese Spezifikationen verwiesen. Bei dem Befehl zum aktiven Beitritt in die Multicast-Gruppe handelt es sich bevorzugt um den Befehl "IPMulticastListen" des IGMP (Internet Group Mana- gement Protocol) -Protokolls .Message types used. For a more detailed explanation, reference is made to these specifications. The command to actively join the multicast group is preferably the "IPMulticastListen" command of the IGMP (Internet Group Management Protocol) protocol.
Bei dem Kommunikationssystem handelt es sich bevorzugt um ein Kommunikationssystem der dritten Mobilfunkgeneration, insbesondere ein System nach dem UMTS-Standard. Allerdings ist die vorliegende Erfindung nicht auf Kommunikationssysteme nach dem UMTS-Standard beschränkt. Vielmehr ist es auch denkbar, die vorliegende Erfindung auf festnetzbasierte Kommunikationssysteme zu erweitern. Bei dem Endgerät handelt es sich bevorzugt um ein Endgerät nach dem UMTS-Standard. Entsprechend handelt es sich bei den Netzwerkelementen bevorzugt um Elemente eines von der Funkzugangstechnologie unabhängigen paketvermittelten Kernnetzwerkes, einem sogenannten "Core Netwerk" .The communication system is preferably a communication system of the third mobile radio generation, in particular a system based on the UMTS standard. However, the present invention is not limited to communication systems based on the UMTS standard. Rather, it is also conceivable to extend the present invention to fixed network-based communication systems. The terminal is preferably a terminal according to the UMTS standard. Accordingly, the network elements are preferably elements of a packet-switched core network that is independent of radio access technology, a so-called “core network”.
In einer Weiterbildung der vorliegenden Erfindung werden als Nutzerdaten die für ein Mulitcast-Dienst eingeschriebenen Nutzer und/oder die Nutzer, welche von einem Multicast-Dienst aktuelle Daten empfangen, vom Core Netzwerk an das Endgerät gesendet. Die vorliegende Erfindung ist jedoch nicht auf diese Nutzerdaten beschränkt. Es ist denkbar, dass die Nutzerdaten einen kompletten Bericht über sämtliche Nutzer von Multi- cast-Diensten beziehungsweise -Gruppen, d.h. deren Gesamtheit, enthalten.In a development of the present invention, the users registered for a multicast service and / or the users who are from a multicast service are used as user data Receive current data, sent from the core network to the end device. However, the present invention is not limited to this user data. It is conceivable that the user data contain a complete report on all users of multicast services or groups, ie their entirety.
In einer bevorzugten Ausführungsform fragt ein Netzwerkelement die Nutzerdaten in einer Datenbank ab und übermittelt diese an das Endgerät.In a preferred embodiment, a network element queries the user data in a database and transmits this to the terminal.
Bevorzugt werden als Nutzerdaten mindestens die Anzahl der anonymen Nutzer von einem Netzwerkelement an das Endgerät gesendet. In einer Ausführungsform überträgt ein Netzwerkele- ment die Nutzerdaten an das Endgerät mit denen nicht ein Anonymitätsattribut verbunden ist.At least the number of anonymous users is preferably sent as user data from a network element to the terminal. In one embodiment, a network element transmits the user data to the terminal with which an anonymity attribute is not connected.
In einer Weiterbildung der vorliegenden Erfindung ist in dem Befehl ein weiterer, für den aktiven Beitritt irrelevanter Parameter vorgesehen, an dessen Stelle Informationen gesendet werden, die einem Netzwerkelement signalisieren, für welchen Nutzer die Nutzerabfrage gestellt werden soll. Durch diese Information kann der Nutzer des Endgeräts vorab auswählen, von welchem Nutzer ihn die Nutzerdaten interessieren.In a further development of the present invention, the command provides a further parameter which is irrelevant for the active entry and in its place information is sent which signals a network element for which user the user query is to be made. With this information, the user of the terminal can select in advance from which user he is interested in the user data.
Die eingangs gestellte Aufgabe wird auch durch ein Verfahren zur anonymen Aktivierung des Empfangs von Nachrichten eines Multicast-Dienstes in einem Kommunikationssystem gelöst, bei dem von einem Endgerät ein Befehl zum aktiven Beitritt in ei- ne Multicast-Gruppe an ein Netzwerkelement gesendet wird, wobei in dem Befehl mindestens ein für den aktiven Beitritt irrelevanter Parameter vorgesehen ist, an dessen Stelle Informationen gesendet werden, die ein Netzwerkelement veranlassen, die Aktivierung gegenüber anderen Nutzer anonym durchzu- führen. Bei dem Befehl handelt es sich wiederum bevorzugt um den Befehl des IGMP-Protokolls "IPMulticastListen" . Bei dem Endgerät beziehungsweise Netzwerkelement handelt es sich ebenfalls wiederum bevorzugt um ein Endgerät nach dem UMTS-Standard be- ziehungsweise ein Netzwerkelement GGSN, wobei die Erfindung wiederum nicht auf Kommunikationssystemen nach dem UMTS- Standard beschränkt ist, sondern auf jede andere Art von Kommunikationssystemen übertragen werden kann.The task stated at the outset is also achieved by a method for anonymous activation of the reception of messages from a multicast service in a communication system, in which a terminal sends a command to actively join a multicast group to a network element, in which the command is provided at least one parameter which is irrelevant for the active entry, in its place information is sent which causes a network element to carry out the activation anonymously with respect to other users. The command in turn is preferably the command of the IGMP protocol "IPMulticastListen". The terminal or network element is again preferably a terminal according to the UMTS standard or a network element GGSN, the invention again not being limited to communication systems according to the UMTS standard, but being transmitted to any other type of communication system can.
Bevorzugt wird auf Grund der übertragenen AktivierungsInformationen der Beitritt des Endgeräts bzw. dessen Nutzers zu der Multicast-Gruppe nicht bei einer Abfrage der Nutzer bzw. Mitglieder der Multicast-Gruppe angegeben. Dies hat den Vorteil, dass ein beitretender Nutzer sicher sein kann, dass sein Beitritt von keinem anderen Nutzer durch eine Abfrage überprüft werden kann. Dies fördert die Bereitschaft von Nutzern, einer Multicast-Gruppe beizutreten.Due to the transmitted activation information, the joining of the terminal or its user to the multicast group is preferably not specified when the users or members of the multicast group are queried. This has the advantage that a joining user can be sure that his joining cannot be checked by another user. This promotes the willingness of users to join a multicast group.
Die Erfindung betrifft des Weiteren ein mobiles Endgerät zur Verwendung bei einem erfindungsgemäßen Verfahren.The invention further relates to a mobile terminal for use in a method according to the invention.
Die Erfindung wird im Folgenden unter Hinweis auf die beigefügten Zeichnungen anhand mehrerer Ausführungsbeispiele näher erläutert. Die dort dargestellten Merkmale und auch die be- reits oben beschriebenen Merkmale, können nicht nur in der genannten Kombination, sondern auch einzeln oder in anderen Kombinationen erfindungswesentlich sein. Es zeigen:The invention is explained in more detail below with reference to the accompanying drawings using several exemplary embodiments. The features shown there and also the features already described above can be essential to the invention not only in the combination mentioned, but also individually or in other combinations. Show it:
Figur 1 den Ablauf der Signalisierungsnachrichten innerhalb der MBMS-Architektur;1 shows the course of the signaling messages within the MBMS architecture;
Figur 2 den Ablauf der Abfrage der zu einer MBMS Gruppe gehörenden Mitglieder bzw. der Nutzer, die Daten einer MBMS Gruppe empfangen mittels der IGMP "Join"- Nachricht; Figur 3 ein Ausführungsbeispiel der Daten, welche zu einem Endgerät übertragen werden;2 shows the sequence of the query of the members belonging to an MBMS group or of the users who receive data from an MBMS group by means of the IGMP "join"message; Figure 3 shows an embodiment of the data which are transmitted to a terminal;
Figur 4 ein Flussdiagramm zur Abfrage von Multicast-Gruppen und zum anonymen Beitritt in eine Multicast-Gruppe; undFIG. 4 shows a flow chart for querying multicast groups and for anonymous joining into a multicast group; and
Figur 5 ein weiteres Flussdiagramm zur Abfrage von Multicast-Gruppen und zum anonymen Beitritt in eine Mu- litcast-Gruppe.FIG. 5 shows a further flow chart for querying multicast groups and for anonymous joining into a multitask group.
Figur 1 wurde bereits in der Einleitungsbeschreibung erläutert, so dass an dieser Stelle darauf verwiesen wird.Figure 1 has already been explained in the introductory description, so that reference is made here.
Figur 2 zeigt den Nachrichtenfluss bei der Abfrage der Nutzer, die Daten einer MBMS Gruppe empfangen mittels der IGMP "Join"-Nachricht . Die "Join"-Nachricht ist Bestandteil des IGMP-Protokolls (Inter Group Management Protocol) . Die IGMP "Join"-Nachricht hat den folgenden Syntax:FIG. 2 shows the message flow when querying the users who receive data from an MBMS group using the IGMP "join" message. The "join" message is part of the IGMP protocol (Inter Group Management Protocol). The IGMP "join" message has the following syntax:
IPMulticastListen (Socket, Interface, Multicast-Adresse, Ex- clude, { } ) .IPMulticastListen (socket, interface, multicast address, exclude, {}).
Der "Socket"-Parameter dient zur Unterscheidung von verschie- denen Entitäten, wie zum Beispiel Programmen oder Prozessen, innerhalb des Endgeräts UE. Der "Sockef-Parameter kann also beispielsweise eine Anschlussnummer, eine sogenannte "Port Nummer", darstellen. Der "Interface"-Parameter dient zur Spezifizierung der Schnittstelle, an der das Endgerät UE die MBMS-Nachrichten erwartet, also beispielsweise die Interpro- tokoll-Adresse oder eine andere eindeutige Adresse des Endgeräts, wie beispielsweise MS-ISDN (Mobile Station International Subscriber Nu ber) oder IMSI (International Mobile Subsc- riber Identifier) . Die "Multicast-Adresse" ist die Internet- protokoll-Adresse der Multicast-Gruppe beziehungsweise die Multicast-Kennung, von der das Endgerät UE Daten empfangen möchte. Dieser Parameter gibt somit den gewünschten MBMS- Dienst an. Die beiden letzten Parameterwerte "Exclude" und "{}" sind im 3GPP-Standard nicht relevant. Sie dienen beim IGMP-Protokoll zur Filterung der Quelle der Multicast- Nachricht. Das IGMP-Protokoll bietet mit Hilfe dieser Parame- ter die Möglichkeit, nur Multicast-Daten von bestimmten Quellen zu empfangen beziehungsweise bestimmte Quellen vom Empfang auszuschließen. Die Internetprotokoll-Adressen der entsprechenden Quellen werden im Parameter "Source-List" angegeben, deren Wert in der angegebenen IGMP "Join"-Nachricht eine leere Menge enthält. Die IGMP-Nachrichten werden innerhalb eines Ipv4-Datagramms übertragen.The "socket" parameter is used to distinguish between different entities, such as programs or processes, within the UE. The "Sockef parameter can therefore represent, for example, a port number, a so-called" port number ". The" Interface "parameter serves to specify the interface at which the terminal UE expects the MBMS messages, for example the interprotocol Address or another unique address of the end device, such as MS-ISDN (Mobile Station International Subscriber Nu ber) or IMSI (International Mobile Subscriber Identifier.) The "multicast address" is the Internet protocol address of the multicast group or the multicast identifier from which the UE wants to receive data. This parameter therefore gives the desired MBMS Service. The last two parameter values "Exclude" and "{}" are not relevant in the 3GPP standard. In the IGMP protocol, they are used to filter the source of the multicast message. With the aid of these parameters, the IGMP protocol offers the option of receiving only multicast data from certain sources or excluding certain sources from reception. The Internet protocol addresses of the corresponding sources are specified in the "Source List" parameter, the value of which contains an empty amount in the specified IGMP "Join" message. The IGMP messages are transmitted within an Ipv4 datagram.
Die beiden letzten Parameter des "IPMulticastListen"-Befehls, die innerhalb des UMTS-Systems nicht benötigt werden, aber dennoch übertragen werden müssen, werden so erweitert, dass sie zur Abfrage der Mitglieder der durch den Parameter "Multicast-Adresse" spezifizierten MBMS-Gruppe verwendet werden können .The last two parameters of the "IPMulticastListen" command, which are not required within the UMTS system, but still have to be transmitted, are expanded so that they are used to query the members of the MBMS group specified by the "Multicast address" parameter can be used.
Als weitere Möglichkeit kann die Parameterliste der IGMPAnother option is the IGMP parameter list
"Join"- beziehungsweise "IPMulticastListen"-Nachricht erweitert werden. Figur 2 zeigt wiederum die schon in Bezug auf die Figur 1 erläuterten Netzwerkelemente UE, RAN, SGSN, GGSN und zusätzlich eine MBMS-Datenbank. Zuerst erfolgt wiederum eine PDP-Kontextaktivierung 21. Anschließend wird die erweiterte IGMP "Join"-Nachricht 2 vom Endgerät UE über den PDP- Kontext an das GGSN gesendet. Der GGSN erkennt anhand der vorhandenen Nachrichtenfelder, dass es sich bei dieser Nachricht nicht um die Aktivierung des Datenempfangs, der durch den Parameterwert innerhalb des Feldes "Multicast-Adresse" angegebenen Multicast-Gruppe handelt, sondern um eine Nutzerabfrage. Mittels der enthaltenen Informationen fragt der GGSN die entsprechenden Daten in einer Datenbank ab 23. Die abgefragten Informationen werden anschließend vom GGSN an das UE übertragen 24. Diese enthalten eine Liste von nicht anonymen Nutzern des abgefragten MBMS-Dienstes beziehungsweise der abgefragten MBMS-Gruppe, wobei vorher die Anzahl dieser Infor- mationsfeider angegeben wird. Bevorzugt ist der mit der Multicast-Gruppe assoziierte Multicast-Dienst und die Multicast- Kennung ebenfalls ein Teil der Liste."Join" or "IPMulticastListen" message can be expanded. FIG. 2 in turn shows the network elements UE, RAN, SGSN, GGSN already explained with reference to FIG. 1 and additionally an MBMS database. First, there is again a PDP context activation 21. Subsequently, the extended IGMP "join" message 2 is sent from the terminal UE to the GGSN via the PDP context. The GGSN recognizes on the basis of the existing message fields that this message is not an activation of data reception, the multicast group specified by the parameter value in the "Multicast address" field, but a user query. Using the information it contains, the GGSN queries the corresponding data in a database. The information requested is then transmitted from the GGSN to the UE. These contain a list of non-anonymous users of the queried MBMS service or the queried MBMS group, where previously the number of this information mationsfeider is specified. The multicast service associated with the multicast group and the multicast identifier are also preferably part of the list.
Die Spezifizierung der Nutzer kann auf verschiedene Arten erfolgen. Figur 3 zeigt eine mögliche Struktur der zum Endgerät UE zu übertragenden Daten. Nach diesem Ausführungsbeispiel enthalten die Daten die Multicast-Kennung, den Multicast- Dienst, die Anzahl der Nutzeridentitäten, die jeweilige Iden- tität der Nutzer und die Anzahl der anonymen Nutzer. Denkbar ist aber auch die Angabe des Vor- und Zunamens, der MS-ISDN des Nutzers, der Internetprotokoll-Adresse, aber auch jede andere eindeutige Kennzeichnung.The user can be specified in different ways. FIG. 3 shows a possible structure of the data to be transmitted to the terminal UE. According to this exemplary embodiment, the data contain the multicast identifier, the multicast service, the number of user identities, the respective identity of the users and the number of anonymous users. It is also conceivable to specify the first and last name, the MS-ISDN of the user, the Internet protocol address, but also any other unique identification.
Darüber hinaus soll auch eine anonyme Aktivierung des Datenempfangs eines MBMS-Dienstes möglich sein. Zweckmäßig für die beschriebene Abfrage ist die Möglichkeit, dass sich ein Nutzer anonym zu einem Dienst einschreiben und ebenfalls anonym Daten dieses Dienstes empfangen kann. Die IGMP "Join"- Nachricht, das heißt die angegebene "IPMulticastListen"-In addition, an anonymous activation of the data reception of an MBMS service should also be possible. It is expedient for the query described that a user can register anonymously for a service and can also receive data of this service anonymously. The IGMP "Join" message, ie the specified "IPMulticastListen" -
Nachricht, wird dazu dahingehend erweitert, dass der Datenempfang einer MBMS-Gruppe anonym erfolgen kann. Mindestens einer der beiden letzten Parameter der "IPMulticastListen"- Nachricht wird dabei so erweitert, dass der Anonymitätswunsch des Nutzers übertragen werden kann.Message, is expanded to the effect that the data reception of an MBMS group can take place anonymously. At least one of the last two parameters of the "IPMulticastListen" message is expanded so that the anonymity request of the user can be transmitted.
Figur 4 zeigt ein Flussdiagramm zur Verarbeitung einer "Join"-Nachricht . Bei diesem Ausführungsbeispiel werden bei auf dem UMTS-Standard basierenden Kommunikationssystemen in der "IPMulticastListen"-Nachricht die Parameter der beiden letzten Parameter, hier "Filtermodus" und "Source-List" nicht benötigt und daher erweitert. Hierzu werden zur Abfrage der Nutzer für den dritten Parameter der "IPMulticastListen"- Nachricht "Filtermodus" des IGMP-Protokolls zwei weitere Wer- te eingeführt. Diese Werte werden hier mit "Subscribe" undFIG. 4 shows a flowchart for processing a "join" message. In this exemplary embodiment, the parameters of the last two parameters, here "filter mode" and "source list", are not required in the "IPMulticastListen" message in communication systems based on the UMTS standard and are therefore expanded. For this purpose, two additional values are introduced to query the users for the third parameter of the "IPMulticastListen" message "Filter mode" of the IGMP protocol. These values are here with "Subscribe" and
"Join" bezeichnet. "Subscribe" steht für die Abfrage der Nutzer, die für den Multicast-Service eingeschrieben sind, der mit dem im Parameter "multicast-address" enthaltenden Multi- cast-Identifier assoziiert ist. "Join" steht für die Abfrage der Nutzer, die Daten des MBMS-Dienstes empfangen, also Mitglieder der über den Parameter "multicast-address" angegebe- nen Multicast-Gruppe sind. Ist einer dieser Parameter in der "IPMulticastListen"-Nachricht enthalten, so erkennt der GGSN, dass es sich bei dieser Nachricht um eine Nutzerabfrage handelt ."Join" denotes. "Subscribe" stands for the query of the users who are registered for the multicast service, the is associated with the multicast identifier contained in the "multicast address" parameter. "Join" stands for the query of users who receive data from the MBMS service, ie are members of the multicast group specified via the "multicast-address" parameter. If one of these parameters is contained in the "IPMulticastListen" message, the GGSN recognizes that this message is a user query.
Zuerst wird bei dem Verfahren die "Join"-Nachricht empfangen. In der "Join"-Nachricht wird der "Filtermodus"-Parameter ausgewertet.. Falls dieser Parameter gleich einem Wert "Exclude" ist, so handelt es sich um eine herkömmliche "Join"- Nachricht. Nimmt der "Filtermodus"-Parameter jedoch weder den Wert "Exclude", noch den Wert "anonym" an, so liegt eine erweiterte "Join"-Nachricht vor. Handelt es sich bei dem "Filtermodus"-Parameter nun um den Parameterwert "Join", so werden die Nutzer der mit der Multicast-Kennung assoziierten Multicast-Gruppe abgefragt. Handelt es sich bei dem "Filter- modus"-Parameter um den Paramterwert "Suscribe", so werden die Nutzer des mit der Multicast-Kennung assoziierten Multicast-Dienstes abgefragt. Anschließend wird der "Source Fil- ter"-Parameter ausgewertet. Nimmt dieser Parameter den Wert "{}" an, d.h. dem Parameter sind keine Werte zugeordnet, so handelt es sich um eine allgemeine Nutzerabfrage, d.h. alle Mitglieder der spezifizierten Multicast-Gruppe, bzw. des damit assoziierten Multicast Services, werden abgefragt. Enthält der "Source Filter"-Parameter hingegen eine Liste von Nutzern, so wird nur deren Zugehörigkeit zum angegebenen Mul- ticast-Service bzw. zur Multicast-Gruppe abgefragt. Das GGSN kann anschließend nach einer entsprechenden Datenbankabfrage die Nutzeridentitäten an das Endgerät UE zurücksenden, mit denen nicht das Anonymitätsattribut verbunden ist. Dies ist vorteilhaft, da eine zusätzliche Angabe der Anzahl von anonym eingeschriebenen Nutzern der Grundidee der Anonymität entgegenspricht. Im Extremfall fragt das Endgerät UE nur einen Nutzer ab. Wird in diesem Fall vom Endgerät UE eine Antwort empfangen, die als Wert für den Parameter "Anzahl der Nutzeridentitäten" den Wert "0" aufweist und für den Wert "Anzahl anonymer Nutzer" den Wert "1" enthält, so ist die Anonymität nicht mehr gewährleistet.In the process, the "join" message is received first. The "filter mode" parameter is evaluated in the "Join" message. , If this parameter is equal to an "Exclude" value, it is a conventional "join" message. However, if the "filter mode" parameter takes neither the value "Exclude" nor the value "anonymous", there is an extended "Join" message. If the "filter mode" parameter is now the "join" parameter value, the users of the multicast group associated with the multicast identifier are queried. If the "filter mode" parameter is the "Suscribe" parameter value, the users of the multicast service associated with the multicast identifier are queried. The "Source Filter" parameter is then evaluated. If this parameter takes the value "{}", ie no values are assigned to the parameter, then this is a general user query, ie all members of the specified multicast group or the associated multicast service are queried. If, however, the "Source Filter" parameter contains a list of users, only their affiliation with the specified multicast service or multicast group is queried. After a corresponding database query, the GGSN can then send the user identities back to the terminal UE with which the anonymity attribute is not connected. This is advantageous because an additional specification of the number of anonymously registered users contradicts the basic idea of anonymity. In an extreme case, the terminal UE queries only one user. In this case, the UE sends an answer received, which has the value "0" as the value for the parameter "number of user identities" and contains the value "1" for the value "number of anonymous users", anonymity is no longer guaranteed.
Das weitere Ausführungsbeispiel gemäß Figur 5 zeigt ein Verfahren, bei dem die Parameterliste des IGMP "Join"- beziehungsweise "IPMulticastListen"-Befehls um zwei Parameter erweitert wird. Weiterhin wird in diesem Ausführungsbeispiel beschrieben, wie die "Join"-Nachricht zu erweitern ist, damit sich ein Nutzer anonym zu einer MBMS-Gruppe einschreiben kann. Die "Join"-Nachricht ist in diesem Ausführungsbeispiel um die mit "Query-Type", "Query-Identity" und "Privacy" bezeichneten Parameter erweitert. Die ersten beiden Parameter dienen zur Nutzerabfrage und der dritte Parameter dient zur Realisierung der anonymen Einschreibung zu einer Multicast- Gruppe. Dabei lässt sich die erweiterte IGMP "Join"- beziehungsweise "IPMulticastListen"-Nachricht wie folgt definieren:The further exemplary embodiment according to FIG. 5 shows a method in which the parameter list of the IGMP "Join" or "IPMulticastListen" command is expanded by two parameters. Furthermore, this exemplary embodiment describes how the “join” message is to be expanded so that a user can register anonymously for an MBMS group. In this exemplary embodiment, the "join" message is expanded by the parameters designated "query type", "query identity" and "privacy". The first two parameters are used to query the user and the third parameter is used to implement anonymous registration for a multicast group. The extended IGMP "Join" or "IPMulticastListen" message can be defined as follows:
IPMulticastListen (Socket, Interface, Multicast-Adresse, Exclude, {}, Privacy, Query-Type, Query-Identity).IPMulticastListen (socket, interface, multicast address, exclude, {}, privacy, query type, query identity).
Der Parameter "Privacy" kann die Werte "anonym" oder "NIL" annehmen. Für den Parameter "Query-Type" sind die WerteThe "Privacy" parameter can take the values "anonymous" or "NIL". The values are for the "Query-Type" parameter
"Subscribe", "Join" und "NIL" möglich. Der Parameter "Query- Identity" kann eine Liste von Nutzeridentitäten enthalten o- der ebenfalls leer bleiben, das heißt den Wert "NIL" beziehungsweise "{}" enthalten."Subscribe", "Join" and "NIL" possible. The parameter "query identity" can contain a list of user identities or can also remain empty, that is to say contain the value "NIL" or "{}".
Zuerst wird eine "Join"-Nachricht empfangen. In der "Join"- Nachricht wird der Parameter "Query-Type" ausgewertet. Ist dieser Parameter gleich "NIL" so wird erkannt, dass es sich um eine "Join"-Nachricht zur Einschreibung in eine Multicast- Gruppe handelt. Anschließend wird der "Privacy"-Parameter ausgewertet. Ist dieser gleich dem Wert "NIL", so erfolgt eine nicht anonyme Einschreibung in die spezifizierte Multi- cast-Gruppe. Ist dieser Parameterwert gleich "anonym", so erfolgt entsprechend eine anonyme Einschreibung in die spezifizierte Multicast-Gruppe.First, a "join" message is received. The "Query-Type" parameter is evaluated in the "Join" message. If this parameter is equal to "NIL", it is recognized that it is a "join" message for registration in a multicast group. The "Privacy" parameter is then evaluated. If this is equal to the value "NIL", then a non-anonymous enrollment in the specified multi cast group. If this parameter value is "anonymous", an anonymous registration in the specified multicast group takes place accordingly.
Handelt es sich bei der ursprünglich empfangenen "Join"- Nachricht bei dem Parameter "Query-Type" um einen Wert ungleich "NIL", so handelt es sich um eine erweiterte "Join"- Nachricht zur Nutzerabfrage. In dieser Nachricht wird der Parameter "Query-Type" ausgewertet. Ist dieser gleich "Join", so erfolgt eine Abfrage der Nutzer, der mit dieser Multicast- Kennung assoziierten Multicast-Gruppe. Ist der Parameter "Query-Type" gleich "Suscribe", so erfolgt eine Abfrage der Nutzer des mit der Multicast-Kennung assoziierten Multicast- Dienstes. Anschließend erfolgt eine Auswertung des "Query- Identity"-Parameters . Ist dieser ungleich "{}", so erfolgt eine Abfrage der über diesen Parameter spezifizierten Nutzer. Ist der Parameter "Query-Identity" gleich dem Wert "{}", so erfolgt eine Abfrage aller Mitglieder.If the "Receive" message originally received with the "Query-Type" parameter is a value not equal to "NIL", then it is an extended "Join" message for user query. The parameter "Query-Type" is evaluated in this message. If this is equal to "join", the user of the multicast group associated with this multicast identifier is queried. If the "Query-Type" parameter is "Suscribe", the users of the multicast service associated with the multicast identifier are queried. The "Query Identity" parameter is then evaluated. If this is not equal to "{}", the user specified via this parameter is queried. If the parameter "Query Identity" is equal to the value "{}", all members are queried.
Die in diesem Ausführungsbeispiel beschriebene Erweiterung des IGMP-Protokolls um zusätzliche Parameter beziehungsweise Informationselemente ist besonders vorteilhaft, sofern die damit eingeführte Funktionalität nicht ausschließlich in UMTS-Kommunikationsnetzen Anwendung findet, sondern allgemein in auf dem Internetprotokoll basierten Netzwerken verwendet wird. In diesem Fall ist die vorstehend erläuterte Erweiterung des IGMP-Protokolls (Version 3) besonders zweckmäßig.The expansion of the IGMP protocol described in this exemplary embodiment by additional parameters or information elements is particularly advantageous if the functionality introduced with it is not only used in UMTS communication networks, but is generally used in networks based on the Internet protocol. In this case, the expansion of the IGMP protocol (version 3) explained above is particularly expedient.
Die beschriebene Verwendung beziehungsweise Erweiterung be- reits existierender Parameter hat den besonderen Vorteil, dass keine Änderung des IGMP-Protokolls und der MBMS Multicast-Dienst Aktivierungsprozedur notwendig ist. Die UMTS- spezifische Abfrage von Multicast-Gruppen kann schnell und einfach eingeführt werden und stellt damit eine 3GPP- spezifische Erweiterung des IGMP-Protokolls dar.The described use or extension of already existing parameters has the particular advantage that no change to the IGMP protocol and the MBMS multicast service activation procedure is necessary. The UMTS-specific query of multicast groups can be implemented quickly and easily and thus represents a 3GPP-specific extension of the IGMP protocol.
Die vorliegende Erfindung bietet die Vorteile der Einführung eines Verfahrens zur Abfrage der Mitglieder einer Multicast- beziehungsweise MBMS-Gruppe und der Nutzer, die sich zu einem Multicast-Service eingeschrieben haben. Diese Abfrage kann unterschieden werden in der Abfrage aller Teilnehmer und/oder der Abfrage von bestimmten Teilnehmern. Die Antwort auf diese Abfrage kann die gewünschte Liste der Teilnehmer und zusätzlich eine Angabe über die Anzahl der anonym eingeschriebenen Teilnehmer enthalten. Darüber hinaus wird bei der vorliegenden Erfindung die Einschreibung zu einer Multicast- beziehungsweise MBMS-Gruppe um ein Anonymitätsattribut erweitert. Die Realisierung dieses Verfahrens kann durch die Erweiterung der IGMP "Join"-Nachricht erfolgen. The present invention offers the advantages of introducing a method for querying the members of a multicast or MBMS group and the users who have subscribed to a multicast service. This query can be differentiated into the query of all participants and / or the query of specific participants. The answer to this query can include the desired list of participants and also an indication of the number of anonymously registered participants. In addition, in the present invention, the enrollment for a multicast or MBMS group is expanded by an anonymity attribute. This method can be implemented by expanding the IGMP "join" message.

Claims

Patentansprüche claims
1. Verfahren zum Abfragen von für einen Multicast-Dienst eingeschriebenen Nutzern bzw. von Nutzern, welche von einem Multicast-Dienst aktuell Daten empfangen, in einem Kommunikationssystem, bei dem von einem Endgerät (UE) ein Befehl zum aktiven Beitritt in eine Multicast-Gruppe (IPMul- ticastListen) an ein Netzwerkelement (GGSN) gesendet wird, wobei in dem Befehl mindestens ein für den aktiven Bei- tritt irrelevanter Parameter vorgesehen ist, an dessen Stelle Informationen gesendet werden, die das Netzwerkelement (GGSN) veranlassen, eine Nutzerabfrage hinsichtlich von Nutzerdaten zu initiieren.1. Method for querying users registered for a multicast service or users who are currently receiving data from a multicast service, in a communication system in which a command from an end device (UE) for active entry into a multicast group (IPMulticastListen) is sent to a network element (GGSN), the command providing at least one parameter which is irrelevant for the active entry, in its place information is sent which causes the network element (GGSN) to prompt a user for Initiate user data.
2. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem als Nutzerdaten die für einen Multicast-Dienst eingeschriebenen Nutzer und/oder die Nutzer, welche von einem Multicast-Dienst aktuell Daten empfangen, von dem Netzwer- kelelement (GGSN) an das Endgerät (UE) gesendet wird.2. The method as claimed in one of the preceding claims, in which, as user data, the users registered for a multicast service and / or the users who are currently receiving data from a multicast service from the network element (GGSN) to the terminal (UE) ) is sent.
3. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Netzwerkelement (GGSN) die Nutzerdaten in einer Datenbank abfragt und an das Endgerät (UE) übermittelt.3. The method according to any one of the preceding claims, wherein the network element (GGSN) queries the user data in a database and transmits it to the terminal (UE).
4. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Netzwerkelement (GGSN) die Nutzerdaten an das Endgerät (UE) überträgt mit denen nicht ein Anonymitätsattribut verbunden ist.4. The method according to any one of the preceding claims, in which the network element (GGSN) transmits the user data to the terminal (UE) to which an anonymity attribute is not connected.
5. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem in dem Befehl ein weiterer für den aktiven Beitritt irrelevanter Parameter vorgesehen ist, an dessen Stelle Informationen gesendet werden, die dem Netzwerkelement signalisieren, für welche Nutzer die Nutzerabfrage ge- stellt werden soll. 5. The method as claimed in one of the preceding claims, in which the command provides a further parameter which is irrelevant for the active entry and in its place information is sent which signals the network element for which users the user query is to be made.
6. Verfahren zur anonymen Aktivierung des Empfangs von Nachrichten eines Multicast-Dienstes in einem Kommunikationssystem, bei dem von einem Endgerät (UE) ein Befehl zum ak- tiven Beitritt in eine Multicast-Gruppe (IPMulti- castListen) an ein Netzwerkelement (GGSN) gesendet wird, wobei in dem Befehl mindestens ein für den aktiven Beitritt irrelevanter Parameter vorgesehen ist, an dessen Stelle Informationen gesendet werden, die das Netzwerkele- ment veranlassen, die Aktivierung gegenüber anderen Nutzer anonym durchzuführen.6. A method for anonymous activation of the reception of messages from a multicast service in a communication system, in which a terminal (UE) sends a command to actively join a multicast group (IPMulticastListen) to a network element (GGSN) at least one parameter which is irrelevant for the active entry is provided, in its place information is sent which causes the network element to carry out the activation anonymously with respect to other users.
7. Verfahren gemäß Anspruch 6, bei dem das Netzwerkelement aufgrund der Informationen den Beitritt des Endgeräts (UE) zu der Multicast-Gruppe nicht bei einer Abfrage von Nutzern bzw. Mitgliedern der Multicast-Gruppe angibt.7. The method according to claim 6, wherein the network element does not indicate the joining of the terminal (UE) to the multicast group on the basis of the information when querying users or members of the multicast group.
8. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem es sich bei dem Befehl um einen Befehl des IGMP- oder MLD-Protokolls handelt.8. The method according to any one of the preceding claims, wherein the command is an IGMP or MLD protocol command.
9. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Kommunikation in einem mobilen Kommunikationssystem der dritten Generation, insbesondere UMTS, stattfin- det.9. The method according to any one of the preceding claims, in which the communication takes place in a third generation mobile communication system, in particular UMTS.
10. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem der in dem Befehl vorgesehene Parameter für den UMTS Standard irrelevant ist.10. The method according to any one of the preceding claims, wherein the parameter provided in the command is irrelevant for the UMTS standard.
11.Mobiles Endgerät (UE) zur Verwendung bei einem Verfahren nach einem der vorhergehenden Ansprüche. 11. Mobile terminal (UE) for use in a method according to one of the preceding claims.
PCT/EP2004/051547 2003-09-11 2004-07-20 Method and device for a multicast service WO2005027410A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10342029.0 2003-09-11
DE10342029A DE10342029A1 (en) 2003-09-11 2003-09-11 Method for a multicast service

Publications (1)

Publication Number Publication Date
WO2005027410A1 true WO2005027410A1 (en) 2005-03-24

Family

ID=34258570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/051547 WO2005027410A1 (en) 2003-09-11 2004-07-20 Method and device for a multicast service

Country Status (2)

Country Link
DE (1) DE10342029A1 (en)
WO (1) WO2005027410A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6385461B1 (en) * 1998-11-16 2002-05-07 Ericsson Inc. User group indication and status change in radiocommunications systems

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5793365A (en) * 1996-01-02 1998-08-11 Sun Microsystems, Inc. System and method providing a computer user interface enabling access to distributed workgroup members
JP2001521716A (en) * 1997-04-23 2001-11-06 モトローラ・インコーポレイテッド System, device and method for managing multicast group membership in a multicast network
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
WO2001042942A1 (en) * 1999-12-10 2001-06-14 Myteam.Com, Inc. Tools for administering leagues and accessing and populating a community website structure
SE520129C2 (en) * 2000-10-27 2003-05-27 Terraplay Systems Ab Communication infrastructure device in and a computer-readable software product for a multi-user application data processing system
GB2375004A (en) * 2001-02-22 2002-10-30 Nokia Networks Oy Collecting, storing and using information associated with user equipment
US7386000B2 (en) * 2001-04-17 2008-06-10 Nokia Corporation Packet mode speech communication
US6993327B2 (en) * 2001-10-29 2006-01-31 Motorola, Inc. Multicast distribution of presence information for an instant messaging system
US8150922B2 (en) * 2002-07-17 2012-04-03 Research In Motion Limited Voice and text group chat display management techniques for wireless mobile terminals

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6385461B1 (en) * 1998-11-16 2002-05-07 Ericsson Inc. User group indication and status change in radiocommunications systems

Also Published As

Publication number Publication date
DE10342029A1 (en) 2005-04-07

Similar Documents

Publication Publication Date Title
DE60127423T2 (en) METHOD AND DEVICE FOR COVER CONTROL OF MULTICAST SERVICES IN A WIRELESS NETWORK
DE112005003798B4 (en) A method of transmitting messages related to a broadcast or group call service in a radio cell communication system
EP1597935B1 (en) Method for managing communication sessions
DE60222158T2 (en) MULTICAST SUPPORT IN PACKAGED WIRELESS NETWORKS
DE602005004206T2 (en) Method and apparatus for selecting a frequency layer for a subscriber terminal in connected state in an MBMS mobile communication system
DE69911264T2 (en) METHOD AND NETWORK ELEMENT FOR FORWARDING MULTIPLE MESSAGES
DE602005006095T2 (en) Providing information about the relationships of individual carriers to mobile terminals receiving a multicast or broadcast service
EP1415496B1 (en) Method for transmitting data from an emitter to a plurality of receivers
DE102005033667B4 (en) Communication session server unit, communication terminal, broadcast server unit, network unit, method for controlling a communication session with a plurality of communication terminals, method for establishing a communication session, method for transmitting data in the context of a communication session by means of a broadcast server Unity and computer program elements
DE10235470B4 (en) Method, subscriber device and radio communication system for transmitting user data messages
DE60111431T2 (en) METHOD FOR PROVIDING MULTICAST AND / OR ROUND SERVICE TO USER DEVICES
EP1283648A1 (en) Method, Terminal and radiocommunications system for transmission of group messages
WO2006086939A1 (en) Management of dynamic groups in a push-to-talk over cellular communication system
EP1504619B1 (en) Method for transmitting at least one group message, associated radio communications network, subsystem and mobile radio device
DE10064107A1 (en) Method for distributing a group message in a radio communication system and associated radio communication system
DE10320418B3 (en) Operating radio communications system for which data service is provided involves adjusting radio parameters for transmitting data depending on performance characteristics of user stations
WO2005027410A1 (en) Method and device for a multicast service
DE10132795B4 (en) Method and apparatus for distributing multicast messages in circuit or packet switched telecommunications networks
EP1922894B1 (en) Mobile radio system for handling group calls
DE10141813A1 (en) Data transmission to groups of recipients
EP1437011A2 (en) Method for carrying out instant messaging with packet switched data
DE10158747B4 (en) Method for transmitting multicast messages and corresponding devices
DE102004008392A1 (en) Management of communication sessions e.g. for PTT services, by establishing two communication sessions and managing them based on transmitted session priority
WO2004056147A2 (en) Method for signalling the ability of mobile radio devices to receive point to multipoint services and corresponding radio communication system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GM HR HU ID IL IN IS JP KE KG KP KZ LC LK LR LS LT LU LV MA MD MK MN MW MX MZ NA NI NO NZ PG PH PL PT RO RU SC SD SE SG SK SY TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SZ TZ UG ZM ZW AM AZ BY KG MD RU TJ TM AT BE BG CH CY DE DK EE ES FI FR GB GR HU IE IT MC NL PL PT RO SE SI SK TR BF CF CG CI CM GA GN GQ GW ML MR SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase