GB2406752A - Providing information related to a multicast or broadcast service - Google Patents
Providing information related to a multicast or broadcast service Download PDFInfo
- Publication number
- GB2406752A GB2406752A GB0323084A GB0323084A GB2406752A GB 2406752 A GB2406752 A GB 2406752A GB 0323084 A GB0323084 A GB 0323084A GB 0323084 A GB0323084 A GB 0323084A GB 2406752 A GB2406752 A GB 2406752A
- Authority
- GB
- United Kingdom
- Prior art keywords
- mbms
- service
- multicast
- pmm
- session start
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
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
-
- 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
- H04L12/1877—Measures taken prior to transmission
-
- 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
- H04W76/00—Connection management
- H04W76/40—Connection management for selective distribution or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Abstract
A method of providing information related to a multicast or broadcast service in a mobile telecommunications network, wherein a mobile terminal takes action to enable reception of required information related to said multicast or broadcast service.
Description
Mobile Communications
1. Introduction
Discussions are still ongoing in several groups regarding which RNC's the PS CN needs to contact when for an MBMS multicast service a new session starts. In this contribution we would like to take a "bottom-up" approach: see what information is required on the Uu and thus which RNC's at minimum need to be informed about a new session by the PS CN.
The contribution is split in three sections: Section 2: discusses what we assume to be some of the main architecture assumptions" in RAND Section 3: attempts to indicate why these current working assumptions are insufficient for handling UEs which are in RRC-Connccted PMM-ldle state.
Section 4: describes two solutions for handling the UEs in RRC Connected PMM-ldle state, and requests RAN2 to make a choice amongst these two solutions.
2. Assumed Current Understanding in RAN In this section, we would like to describe what we assume to be the current understanding in RAN groups regarding which RNC's need to receive the SESSION START message. It is attempted to capture this understanding . . . . . . in 4 guidelines. First we will look at what is the main MBMS service related configuration information to be transmitted over Uu.
2.1. Information over Uu We assume that whenever a session has started/is about to start, the following information needs to be transmitted by the UTRAN over the Uu (somehow): 1) Support for Service-X (e.g. absence/presence of the TMGI) - Indicates that this cell is part of the broadcast/multicast area for l 0 service-X; - Indicates that Service-X is currently providing, or is close to starting, a session; 2) PTM configuration - In case the service is currently already provided by a PTM configuration, the PTM configuration needs to be transmitted; 3) PMM-CONNECTED state required - This indicator indicates if the UE is required to go to PMM CONNECTED state (+RRC connection).
- Sometimes this indicator is still called "RRC connection required", but we assume that it is generally understood/agreed that we don't want just any RRC connection (e.g. not an RRC comlection without signalling connection, or an RRC connection with a CS signalling connection only) I,, I. . . . since the main purpose of this indicator is to enable counting based on MBMS UE LINKING REQUEST messages from the PS CN.
Notes: l.lf Indication 1) indicates support for the service, and indication 2 indicates no PTM configuration, indication 3) should typically always indicate that PMM-CONNECTED state is required. The detailed interaction with the counting mechanism is FFS.
2. In several other contributions, separate indications for service support, usage of ptm, and usage of ptp were suggested. However, in our understanding, when a service is not provided ptm, a UE does not care whether the service is already provided to other UEs by ptp or not.
3. We assume that cells not part of BC/MC-area of Service-X do not transmit any of the indicated information.
4. As far as we know, it is currently still unclear which NAS message the UE will sent when going to PMM-CONNECTED due to receiving the third indicator (open issue for SA2/CNI). We assume that this existing/new message does not include any MBMS service id's. As a result, the CN will sent linking information to RAN for all MBMS services the UE has joined and for which a session has/is about to start.
2.2. RRC-Idle mode UE's RRC-ldle mode UEs moving within an RA do not infonn the network about a change in location. Therefore the CN needs to ensure that whenever 1 1 I I . . . I 1 there is an idle mode UE registered in a certain RA who has joined a certain service, all cells in that RA transmit the correct setting of the 3 indicators listed above. It is our current understanding that in order to do so, an RNC at least needs to have received a SESSION START. Therefore the following guideline is proposed: Guideline 1: The PS CN shall send a SESSION START message for MBMS Service-X to all RNCs handling an RNS which contains at least one cell which: Is part of the MC-area of MBMS Service-X, and - Is part of an RA in which at least one UE is present in PMM-IDLE state that has joined MBMS Service-X.
Figure I shows the simple case of only having 1 Idle mode UE in an RA (RA2). In this case, guideline I will trigger the SESSION START message to be sent to RNC2.
Guideline I will also handle the mobility case of an Idle mode UE moving into an RA where up to that point, no interested UE was present. This is shown in figure 2.
As far as we know, the NAS message part of step 2 has not been standardised yet. In this case, the NAS message could be a RAU but this should be further investigated by SA2/CNI.
I 1 2.3. RRC-Connected, PMM-CONNECTED UE's The situation is different for PMM- CONNECTED UE's. For these UE's there exists a PS signalling comlection, and the PS CN can sent an MBMS UE LINKING REQUEST to the SRNC.
The SRNC will inform the DRNC of the UE's interest in the MBMS service. Currently, RAN3 assumes that if the DRNC is not aware of the service yet, the DRNC will sent an MBMS REGISTRATION REQUEST to the PS CN, thus making the PS CN aware that the RNC is required to receive the SESSION START. This MBMS REGISTRATION REQUEST message is triggered by appropriate signalling over fur (ATTACH), Which iS again triggered by the receipt of the MBMS UE LINKING REQUEST message from the PS CN.
Note that it is important that the SRNC will always receive this MBMS UE LINKING REQUEST, since otherwise a situation may arise in which the DRNC is not aware ofthe session start.
This results in the following proposed guidehnes: Guideline 2: The PS CN shall send an MBMS UE LINKING REQUEST message for MBMS Service-X to the SRNC for every UE which is in PMM-CONNECTED state and has joined MBMS Service-X.
Guideline 3: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that indicates its interest in MBMS Service-X by means of an MBMS REGISTRATION REQUEST message.
I. ... , . 1 1 1 1 r I Should the PS CN now sent a SESSION START to all RNC's handling cells in a same RA as the RNC from which the MBMS REGISTRATION REQUEST message was received ? In principle we think this is not required, since when the UE enters a next RNC, again the ATTACH over lur can trigger the MBMS REGISTRATION REQ to the PS CN.
Also the SRNC itself needs to receive the SESSION START message (and possibly establish a user plane) e.g. for the case it decides to handle the MBMS service by a pip transmission. Thus: Guideline 4: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that is acting as an SRNC for a UE which has joined MBMS Service-X and which is in PMM-CONNECTED state.
An example scenario for a PMM-CONNECTED UE is shown in figure 3.
2.4. Summary
In summary, the following is assumed to resect the current RAN 1. Uu: On the Uu, we have a "PMM-CONNECTED state required" indicator.
If not already in this state, the UE shall transit to PMM-CONNECTED state and sent an appropriate NAS message. . .
. 1 1, 2. Guidelines: The following guidelines represent the current understanding regarding to which minimum set of RNC's the CN needs to transmit a SESSION START message and a UE LINKING REQUEST message: Guideline 1: The PS CN shall send a SESSION START message for MBMS Service-X to all RNCs handling an RNS which contains at least one cell which: - Is part of the MC-area of MBMS Service-X, and - Is part of an RA in which at least one UE is present in PMM-IDLE state that has joined MBMS Service-X.
Guideline2: The PS CN shall send an MBMS UE LINKING REQUEST message for MBMS Service-X to the SRNC for every UE which is in PMM-CONNECTED state and has joined MBMS Service-X.
Guideline 3: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that indicates its interest in NIBMS Service-X by means of an MBMS REGISTRATION REQUEST message.
Guideline 4: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that is acting as an SRNC for a UE which has joined MBMS Service-X and which is in PMM-CONNECTED state.
1 i, . , I 1 3. RRC-Connected PMM Idle state: Problem description The situation is again different for UEs which are RRC connected, but in PMM-IDLE state (e. g. UE's performing a voice call).
For these UE's, - The SRNC might be outside the MC-area. Thus these SRNC's will not be informed about the Session Start due to guideline I above.
- The UE is not PMM-CONNECTED and will also not transit to PMM-CONNECTED state if the session start is not signalled on Uu in the DRNC. This will occure if the DRNC is not informed about the session start due to guidelines 1,3 and 4. As a result, the SRNC will not receive an MBMS UE LINKING REQUEST message and the DRNC will not perform a registration.
Figure 4 shows an example situation in which this problem occurs: Both RNC4 and RNC5 are not informed about the Session Start due to any of the previous guidelines. As a result, the right most UE would not be aware of the session start.
Note that the concerning UEs will not at all be aware of the started session. This will be a main drawback for the user that has an advanced UE which is capable of parallel reception, as well as for the user with the simpler UE which would prefer to end his CS activity and receive the MBMS service when the session starts.
These limitations are not in line with the requirements stated in TS22. 246 v6.2.0, section 5.2.2: 1 1 I :: ; . '. .' :.
Dependent on terminal capabilities, it shall be possible for the user to participate in other services, while simultaneously participating in MBMS services. For example the user can originate or receive a call or send and receive messages whilst receiving MBMS video content.
4. RRC-Connected PMM Idle state: Possible solutions In general, we see two solution directions for handling this situation: A) Initiative from PS CN In these solutions, the PS CN will take the initiate and e.g. page all UEs that have joined MBMS Service-X, in order to know where their SRNC is, and to subsequently deliver an MBMS UE LINKING REQUEST message and SESSION START message to this SRNC.
B) Initiative from UE In this solution direction, the UE when in RRCConnected PMM-idle state will take the necessary action to enable reception of the MBMS service availability information and possibly the MBMS service itself.
Solution direction A is not considered preferable due to the significant signalling load solution that such a solution is expected to cause. In these solutions, the PS CN will have to find out for any PMM-IDLE UE that has joined the service if it already has an RRC conection. Therefore both solutions proposed below are based on solution direction B).
/ . . . . . . . . 4.1. Solution 1: UE receives information on MCCH
4.1.1. Description
A UE in RRC-Connected PMM Idle state could, depending on its capabilities, still respond to information on MCCI]. E.g. a UE in a voice call, capable of receiving the S-CCPCH/MCCH in parallel to a DPCH, could move to PMM-CONNECTED state when it detects a session start indicated on the MCCH.
When this UE goes to PMM-CONNECTED and indicates its interest in the MBMS service, the PS CN can deliver an MBMS LINKING REQUEST message to the SRNC. When the service would be provided by ptm, depending on the UE capabilties the UE would be able to receive the service.
One benefit of this solution is that UEs which are not capable of common channel activity in parallel to other ongoing activity (like a voice call) will also not be counted, since they don't transit to PMM-CONNECTED state.
One precondition for this solution to work is that a cell which supports the service, indicates this support regardless whether the network is aware of any Idle/Connected UE in the neighbourhood (e.g. same RA). Therefore the following guideline 5: Guideline 5: The PS CN shall send a SESSION START message for Service-X to all RNCs handling an RNS which contains at least one cell which is part of the MC-area of service-X.
I 1 I,I I I I I. II 11 Figure 5 shows the scenario in which the UE detecting the session started information over Uu (whicl1 was realised by the SESSION START in step 1), transmits a NAS message which triggers the subsequent SESSION START and MBMS UE LINKING REQUEST messages.
Note that in this case the NAS message triggering the MBMS UE LINKING REQUEST could potentially still be a RAU message (indicating the RA where the UE went to RRC-connected mode), however the message would have to be triggered without a change in RA.
4.1.2. Solution 1: Summary
In summary, based on the above considerations, the following would be the result if solution I is accepted: 1. Uu: On the Uu, we have a "PMMCONNECTED state required" indicator.
If not already in this state, the UE shall transit to PMM-CONNECTED state and sent an appropriate NAS message.
2. Guidelines: If guideline 5 is agreed, guidelines I and 3 are no longer needed since these guidelines address a subset of the RNC's of guideline 5. The resulting set of guidelines will consist of guidelines 2,4 and 5: Guideline2: The PS CN shall send an MBMS UE LINKING REQUEST message for MBMS Service-X to the SRNC for every UE which is in PMM-CONNECTED state and has joined MBMS Service-X.
i. . ...
I 1 1 1 . . Guideline 4: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that is acting as an SRNC for a UE which has joined MBMS Service-X and which is in PMM-CONNECTED state.
Guideline 5: The PS CN shall send a SESSION START message for Service-X to all RNCs handling an RNS which contains at least one cell which is part of the MC-area of service-X.
A drawback of solution 1 is that less advanced UEs not capable of receiving the MCCH in parallel to a DPCH will not be aware of the session start. Such a user will not be informed about the service availability and thus not have the option to release the voice call and receive the MBMS service.
This limitation is overcome in solution 2.
Solution 1 is architecturally considered simpler, but requires all RNC's handling cells which are part of the MC-area to receive the SESSION START. Note however that in this respect, it will align the handling of Broadcast Services and Multicast Services.
Area of Applicability
The IPR proposal is applicable to UMTS, in the area of the Multimedia Multicast / Broadcast Service (MBMS). It concerns the answer to the question: to which RNC's shall the CN transmit a SESSION START message.
The context of this IPR proposal is described in a.o. [MBMS Architecture and Functional Description 3GPP TS23.246 V.2.0.0].
. .. . ..
State of the Art When an MBMS session starts, the CN needs to inform the correct RNC's about this event. Currently the assumption is that a SESSION START message will be used for this purpose, but also another message might be used for this purpose in the future.
In this IPR proposal, we will speak about the "SESSION START message" as the way for the CN to inform the UTRAN about a session start.
Problem description
Up to now there is no common view in 3GPP regarding to which RNCs the Core Network should sent a SESSION START message. Different groups in 3GPP currently have different opinions. E.g. currently SA2 assumes that an SGSN shall transmit a SESSION START message to all its RNCs.
However RAN3 does not agree with this view as expressed in liaison [LS Response on a new question about RAN assumption 3GPP R3-031240].
Improvement proposal If the CN wants to enable MBMS reception in UE states: - RRC-ldle state, and - RRC-Connected, PMM-CONNECTED state, the CN shall obey to the following rules when determining which RNC's shall be informed about the start of an MBMS session: Guideline 1: The PS CN shall send a SESSION START message for MBMS Service-X to all RNCs handling an RNS which contains at least one cell which: ., . . ...
I 1 1 1, I Is part of the MC-area of MBMS Service-X, and - Is part of an RA in which at least one UE is present in PMM-IDLE state that has joined MBMS Service-X.
Guideline 2: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that indicates its interest in MBMS Service-X by means of an MBMS REGISTRATION REQUEST message.
Guideline 3: The PS CN shall send a SESSION START message for MBMS Service-X to any RNC that is acting as an SRNC for a UE which has joined MBMS Service-X and which is in PMM-CONNECTED 1 0 state.
If the CN wants to enable MBMS reception in UE states: - RRC-Tdle state, and - RRC-Connected, PMM-CONNECTED state, and - RRC-Connccted, PM M-ID LE state the CN shall obey to the following rules when determining which RNC's shall be informed about the start of an MBMS session: Guideline 3: The PS CN shall send a SF,SSION START message for MBMS Service-X to any RNC that is acting as an SRNC for a UE which has joined MBMS Service-X and which is in PMM-CONNECTED state.
Guideline 4: The PS CN shall send a SESSION START message for Service-X to all RNCs handling an RNS which contains at least one cell which is part of the MC-area of service-X.
. .. . ... .
The motivation for these guidelines is described in the attached draft contribution.
Benefits of proposal The proposed guidelines indicate the minimum set of RNC's that need to be informed about a session start if the CN wants to support MBMS reception certain in certain RRC/PMM states.
i. . . . . . 1 1 1 I . . .
Claims (5)
1. A method of providing information related to a multicast or broadcast service in a mobile telecommunications network, wherein a mobile terminal takes action to enable reception of required information related to said multicast or broadcast service.
2. A method of determining the destination for required information related to a multicast or broadcast service in a mobile telecommunications network, wherein a mobile terminal takes action to enable reception of required information related to said multicast or broadcast service.
3. A method according to claim 1 or 2, wherein the mobile terminal receives information and responds to information on the multicast control channel.
4. A method according to claim 1, 2 or 3, wherein the mobile terminal is in a radio resource control concocted and a pac;Kei mobility management idle state when taking action.
5. A method according to any preceding claim, wherein the mobile terminal moves to a packet mobility management connected state when taking action.
I . . . .. . .. . .
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0323084A GB2406752B (en) | 2003-10-02 | 2003-10-02 | Mobile communications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0323084A GB2406752B (en) | 2003-10-02 | 2003-10-02 | Mobile communications |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| GB0323084D0 GB0323084D0 (en) | 2003-11-05 |
| GB2406752A true GB2406752A (en) | 2005-04-06 |
| GB2406752B GB2406752B (en) | 2008-02-27 |
Family
ID=29415373
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB0323084A Expired - Fee Related GB2406752B (en) | 2003-10-02 | 2003-10-02 | Mobile communications |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2406752B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2448128A (en) * | 2007-03-26 | 2008-10-08 | Nec Corp | Indicating a preferred radio access technology for delivery of an MBMS service |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003036908A1 (en) * | 2001-10-24 | 2003-05-01 | Nokia Corporation | Ciphering as a part of the multicast concept |
| US20030119533A1 (en) * | 2001-11-26 | 2003-06-26 | Sinikka Sarkkinen | Multicast location management in a universal terrestrial radio access network |
| EP1359774A1 (en) * | 2002-05-03 | 2003-11-05 | Samsung Electronics Co., Ltd. | Apparatus and method for multimedia broadcast/multicast service in a mobile communication system |
| EP1363467A2 (en) * | 2002-05-17 | 2003-11-19 | Samsung Electronics Co., Ltd. | Method for setting up signaling connection in a mobile communication system |
| EP1363466A1 (en) * | 2002-05-13 | 2003-11-19 | Samsung Electronics Co., Ltd. | Method for providing broadcast service in a CDMA mobile communication system |
| WO2003098842A1 (en) * | 2002-05-18 | 2003-11-27 | Lg Electronics Inc. | Method for managing multicast group in mobile communication system |
| EP1372350A1 (en) * | 2002-06-14 | 2003-12-17 | Samsung Electronics Co., Ltd. | Soft handover of a common channel in an asynchronous CDMA mobile communication system providing MBMS services |
| WO2004002184A1 (en) * | 2002-06-20 | 2003-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Multimedia broadcast/multicast service (mbms) support in utran |
-
2003
- 2003-10-02 GB GB0323084A patent/GB2406752B/en not_active Expired - Fee Related
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003036908A1 (en) * | 2001-10-24 | 2003-05-01 | Nokia Corporation | Ciphering as a part of the multicast concept |
| US20030119533A1 (en) * | 2001-11-26 | 2003-06-26 | Sinikka Sarkkinen | Multicast location management in a universal terrestrial radio access network |
| EP1359774A1 (en) * | 2002-05-03 | 2003-11-05 | Samsung Electronics Co., Ltd. | Apparatus and method for multimedia broadcast/multicast service in a mobile communication system |
| EP1363466A1 (en) * | 2002-05-13 | 2003-11-19 | Samsung Electronics Co., Ltd. | Method for providing broadcast service in a CDMA mobile communication system |
| EP1363467A2 (en) * | 2002-05-17 | 2003-11-19 | Samsung Electronics Co., Ltd. | Method for setting up signaling connection in a mobile communication system |
| WO2003098842A1 (en) * | 2002-05-18 | 2003-11-27 | Lg Electronics Inc. | Method for managing multicast group in mobile communication system |
| EP1372350A1 (en) * | 2002-06-14 | 2003-12-17 | Samsung Electronics Co., Ltd. | Soft handover of a common channel in an asynchronous CDMA mobile communication system providing MBMS services |
| WO2004002184A1 (en) * | 2002-06-20 | 2003-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Multimedia broadcast/multicast service (mbms) support in utran |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2448128A (en) * | 2007-03-26 | 2008-10-08 | Nec Corp | Indicating a preferred radio access technology for delivery of an MBMS service |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2406752B (en) | 2008-02-27 |
| GB0323084D0 (en) | 2003-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7400593B2 (en) | Method for distinguishing MBMS service request from other service requests | |
| EP1763263B1 (en) | Methods of transmitting information related to a multicast service in a mobile telecommunications network | |
| JP4647685B2 (en) | Method, apparatus and computer program for terminating reception by a mobile station of a multimedia broadcast / multimedia service (MBMS) service bearer | |
| KR100594101B1 (en) | System and method for supporting multimedia broadcast/multicast service in non tracking area | |
| US8170556B2 (en) | Method for initiating uplink signaling proactively by MBMS UE | |
| US7197333B2 (en) | Paging system and method for providing multicast multimedia broadcast/multicast service | |
| AU2005201942B2 (en) | Apparatus and method for giving notification of a multimedia broadcast/multicast service while considering a transmission mode in a mobile communication system | |
| EP2512160B1 (en) | Receiving method, receiving equipment and user equipment for multicast control channels (mcchs) information | |
| JP5275320B2 (en) | Asynchronous signaling and data distribution in wireless communication systems | |
| JP5425633B2 (en) | Apparatus and method for multicasting | |
| US20100329167A1 (en) | Method for counting a number of mobile stations in a radio access network | |
| US8050221B2 (en) | Method and apparatus for dispersing user equipments to non-preferred frequencies in a multimedia broadcast/multicast service system | |
| AU2006213219B2 (en) | Apparatus and method for transmitting information for MBMS | |
| AU2005204205A1 (en) | Method for transmitting messages related to a broadcast or multicast service in a cellular communications system | |
| CA2578425A1 (en) | Optimistic talk-permit reliability enhancement in a push-to-talk system | |
| JP5056857B2 (en) | Mobile communication system, radio control apparatus, mobile terminal, and message transmission method | |
| US20030202487A1 (en) | Method and apparatus for reducing call setup time | |
| CN105376717B (en) | Method for establishing LTE cluster communication bearer, user equipment and first network element equipment | |
| EP1874050A1 (en) | Method for providing mobile television information in MBMS | |
| US20070232308A1 (en) | Method for Multimedia Broadcast Multicast Service Linking for Pmm Idle Mobiles | |
| US9294294B2 (en) | Method and arrangement for efficient group communication | |
| CN103945339B (en) | The release of broadband cluster communication system resource, method for building up, terminal and base station | |
| GB2406752A (en) | Providing information related to a multicast or broadcast service | |
| AU2008202179B2 (en) | Method for transmitting messages related to a broadcast or multicast service in a cellular communications system | |
| GB2456930A (en) | method of providing resources for a multicast service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PCNP | Patent ceased through non-payment of renewal fee |
Effective date: 20141002 |