WO2015000912A1 - Method for providing multicast/broadcast service continuity for mobile terminals - Google Patents
Method for providing multicast/broadcast service continuity for mobile terminals Download PDFInfo
- Publication number
- WO2015000912A1 WO2015000912A1 PCT/EP2014/063983 EP2014063983W WO2015000912A1 WO 2015000912 A1 WO2015000912 A1 WO 2015000912A1 EP 2014063983 W EP2014063983 W EP 2014063983W WO 2015000912 A1 WO2015000912 A1 WO 2015000912A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- multicast
- broadcast service
- mbms
- mobile terminal
- radio
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/30—Resource management for broadcast 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/1868—Measures taken after transmission, e.g. acknowledgments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0007—Control or signalling for completing the hand-off for multicast or broadcast services, e.g. MBMS
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
- H04W36/0085—Hand-off measurements
- H04W36/0088—Scheduling hand-off measurements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
- H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/51—Allocation or scheduling criteria for wireless resources based on terminal or device properties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
- H04W72/542—Allocation or scheduling criteria for wireless resources based on quality criteria using measured or perceived quality
Definitions
- the present invention relates to a method for providing multicast/broadcast service continuity for mobile terminals in a radio access network, wherein said mobile terminals register with a base station of said radio access network regarding said multicast/broadcast service and wherein said base station transmits multicast/broadcast service related data as group communications to said registered mobile terminals.
- the present invention relates to a corresponding base station and a corresponding mobile terminal.
- eNB Evolved Node B also called base station, RNC, etc.
- E-UTRA Evolved Universal Terrestrial Radio Access
- E-UTRAN Evolved Universal Terrestrial Radio Access Network
- MBMS Multimedia Broadcast Multicast Service
- eMBMS Multimedia Broadcast Multicast Service
- SFN single frequency network
- eMBMS Evolved Multimedia Broadcast/Multicast Service
- It also enables delivery of high-quality content to multiple UEs with enhanced QoS in areas which MBMS services are provisioned.
- a possible deployment option of MBMS service using a pre-defined area is as shown in Fig. 1.
- MBSFN service area is the area where all eNBs can be synchronized to provide MBSFN transmission and could contain multiple MBSFN areas.
- an (e)MBMS service area can include multiple MBSFN areas, but also single eNBs that are not part of any MBSFN area. From a UE perspective, all transmissions from a single MBSFN area eNBs are seen as a single transmission.
- the cells within an MBSFN area will advertise its availability and UEs can consider a subset of MBSFN areas that are configured. As shown in the figure, there could be reserved cells within MBSFN area which does not have any MBSFN transmissions and can use the resource allocated for MBSFN in neighboring cells for other services.
- these reserved cells transmit the (e)MBMS data in different radio resources than the MBSFN area. But the maximum transmit power that can be allocated for such resources are limited so as to not cause interference to MBSFN cells.
- MBMS reception is possible for UEs in RRC_CONNECTED or RRCJDLE states. Whenever receiving MBMS services, a user shall be notified of an incoming call, and can make outgoing calls (as specified in 3GPP TS 36.300, "E-UTRA and E-UTRAN: Overall description; Stage 2," v 1 1.5.0, March 2013, briefly denoted [2] hereinafter).
- MBSFN service area and (e)MBMS service area have different meaning, but in the context of the present invention these terms may be used in an interchangeable manner, i.e. expressing in general an area where the UE receives (e)MBMS data via (e)MBMS bearer service.
- An (e)MBMS bearer service is identified by an IP multicast address, an APN network identifier and also by a TMGI (Temporary Mobile Group Identity) inside one PLMN.
- TMGI Temporary Mobile Group Identity
- the UE can use the TMGI as ID for the (e)MBMS bearer service over certain access technology.
- the UTRAN MBMS bearer service and the E-UTRAN eMBMS bearer service would have 2 different TMGIs.
- Multi- Cell/Multicast Coordination Entity could be a functional entity which could be either stand-alone node or a part of another network node (e.g. eNB as shown in Fig. 3 (b)).
- the MCE takes care of admission control, counting results of MBMS services, and resumption or suspension of MBMS sessions depending in the counting results.
- the M3 reference point is specified for the control plane between MME and E-UTRAN, assuming that the MCE is a part of the E-UTRAN.
- the details of the (e)MBMS reference points and related functional entities can be found in the above mentioned standard document [2].
- Fig. 3 Two possible deployment alternatives that are considered in [2] are shown in Fig. 3, with additional consideration of an X2 interface between eNBs for the present invention.
- the services which are envisioned to be provisioned using MBMS are streaming of audio and video, updates of smartphone applications, etc. (as outlined in [1]). It is also considered that the regions where these services are to be delivered will be pre-planned and service continuity over the MBSFN area is enabled by using careful prior planning of the network.
- the service continuity is enabled as the MBMS service data is delivered in the same radio resources in the cells participating in the MBSFN area. In the boundary area of two cells, the UE can combine the signals coming from the two cells, and therefore, the probability of correct reception is increased.
- MCH Multicast Channel
- the MBMS control information is conveyed using MCCH logical channel and user data using MTCH logical channel which can be used for multiple MBMS services within an MBSFN area.
- MCCH logical channel and user data using MTCH logical channel which can be used for multiple MBMS services within an MBSFN area.
- RAN Radio Access Network
- P2M bearer uses the mechanisms specified in 3GPP for transmission of data from BM-SC to UE.
- the reason for this is that current MBMS applications are mainly streaming applications and short interruption perceived by the user is not critical.
- GCSE_LTE Group Communication System Enablers for LTE
- radio resource efficiency via MBMS transmission and service continuity are key features.
- Radio resource efficiency is “to avoid duplicated/unnecessary radio resources allocated for different group members in a certain cell” and “to minimize impact on signaling plane for the network”. If many UEs are located in the same area, then MBMS is considered as one of the potential technologies to achieve this resource efficiency when transmitting Group Communication (GC) service data (see, for reference S2-131509, "Architecture & functional requirements for GCSE_LTE,” Qualcomm Incorporated). In cells where there are only few UEs, the network may decide to distribute the GC service data in unicast way.
- GC Group Communication
- the aforementioned object is accomplished by a method comprising the features of claim 1.
- a method comprising the features of claim 1.
- a mobile terminal performs multicast/broadcast service related radio measurements and that a decision on actions to be performed by said base station and/or by said mobile terminal for preserving reliable transmission/reception of said multicast/broadcast service related data to/by said mobile terminal is taken based on the results of said multicast/broadcast service related radio measurements.
- a base station comprising the features of claim 22.
- the base station is further configured to receive results of multicast/broadcast service related radio measurements performed by a mobile terminal and, based on the received measurement results, to take a decision on actions to be performed for preserving reliable transmission of said multicast/broadcast service related data to said mobile terminal.
- a mobile terminal comprising the features of claim 24.
- the mobile terminal is further configured to perform multicast/broadcast service related radio measurements and to take a decision on actions to be performed for preserving reliable reception of said multicast/broadcast service related data based on the results of said multicast/broadcast service related radio measurements.
- the present invention together with embodiments as described below deals with all disadvantages of the possible solutions mentioned above.
- the proposed solution is based on network-initiated measures to provide service continuity.
- the described embodiments aim also to meet the system requirements as per document 3GPP TS 22.468, "Group Communication System Enablers for LTE: (GCSE_LTE) Release 12," ver 0.3.0, where it is specified that "When UEs are moving among cells during group communication, service continuity shall be supported".
- the main idea of the present invention is based on the UE-assisted reporting of MBMS-related radio quality conditions (MBMS-related radio measurements) to the radio network node (eNB), and the radio network (eNB) takes a decision how to provide the reliable transmission of the MBMS data to the UE.
- the UE's current/existing radio measurements (used for the mobility procedure) may be extended to additionally include information about the MBMS radio signal quality.
- the eNB may decide based on MBMS service topology (e.g. if the MBMS service, both MBSFN or non-MBSFN, is configured in the neighboring cells or if unicast transmission conditions are possible) which actions to perform in order to guarantee the service continuity of the MBMS service reception in the UE.
- the MBMS-related information (MRB reporting) in the measurement reports from UE to eNB can be e.g. MRB signal strength (similar to the signal strength of pilot signal as reported currently in measurement report), or decoding error of received MRB data, or block error rate of received MRB data and other possible physical layer, MAC layer or RLC layer parameters.
- MRB signal strength similar to the signal strength of pilot signal as reported currently in measurement report
- decoding error of received MRB data or block error rate of received MRB data and other possible physical layer, MAC layer or RLC layer parameters.
- MBSFN carrier symbol there is an MBSFN carrier symbol within the transmission frame as described in [2] (3GPP TS 36.300, section 5.1.4). This MBSFN carrier symbol can be used as referenced signal to generate the MBMS-related information in the UE's measurement reports.
- MBMS multimedia service
- MRB Multicast/Broadcast-Radio
- MRB multicast radio bearer
- a RAN node is able to 1 ) determine whether to configure a UE for measurement reporting for MBMS/MRB-related information and 2) is able to gather information from neighbor cells about their MBMS transmission resources/conditions.
- a RAN node is able to decide based on the measurement reports from a particular UE whether to start transmitting the MBMS data over unicast DRB to this particular UE. Further the eNB is able to decide whether to apply different scheduling priorities for MBMS and non-MBMS data over the same unicast DRB.
- a RAN node is able to determine signal thresholds for the UE and to configure the UE with these thresholds in order to enable the UE to perform, only when needed, the actions for the switch from multicast to unicast delivery of group session data.
- the present invention describes several flavors of the solution for the problem of providing service continuity.
- solutions according to embodiments of the present invention provide the benefits of 1 ) service continuity, i.e. no data flow interruption is perceived by the application layer receiving the MBMS data and 2) the switch from multicast to unicast delivery only if needed (i.e. not too early when the switch can be avoided or not too late when the connection is disrupted).
- Fig. 1 is a schematic view illustrating the general concept of MBMS service provisioning according to prior art
- Fig. 2 is a schematic view illustrating the eMBMS reference architecture according to prior art
- Fig. 3 is a schematic view illustrating eMBMS deployment alternatives according to prior art
- Fig. 4 is a schematic view illustrating channel mapping employed in connection with MBMS according to prior art
- Fig. 5 is a schematic view illustrating a communication system with possible coverage areas during MBMS reception
- Fig. 6 is a signaling diagram of a mobile terminal's MBMS-related reporting in accordance with a first embodiment the present invention
- Fig. 7 is a schematic view illustrating a communication system in which service continuity is achieved based on mapping of MBMS data on unicast radio bearer according to an embodiment of the invention
- Fig. 8 is a flow chart illustrating reporting and action taking functionalities and procedures for the mobile terminal and the base station according to embodiments of the present mention
- Fig. 9 is a signaling diagram of a scenario where service continuity is achieved based on application level signaling in accordance with an embodiment the present invention
- Fig. 10 is a diagram illustrating the LTE data plane protocol stack
- Fig. 1 1 is a diagram illustrating a mechanism of mobile terminal determined thresholds according to another embodiment of the present invention
- Fig. 12 is a diagram illustrating still another embodiment of the present invention where the mobile terminal determines application layer actions based on configurations from a RAN node,
- Fig. 13 is a signaling diagram illustrating mobile terminal initiated GC unicast delivery before handover according to an embodiment of the present invention.
- Fig. 14 is a signaling diagram illustrating a switch scenario from unicast to multicast delivery upon the mobile terminal entering MBSFN area according to an embodiment of the present invention.
- two base stations - denoted eNB1 and eNB2 - are part of the same MBMS service bearer.
- the eNBs transmit the MBMS data over the MRB with the same signal strength and on the same frequency (sub-carrier) for the whole cell, it may happen that the eNB transmit the MRB data with less power strength than the possible maximum power strength used for unicast DRBs in order to keep the interference to neighbor sub-carriers low.
- MRB MBMS
- unicast transmissions Another reason for different coverage areas of MBMS (MRB) transmissions on the one hand and unicast transmissions on the other hand is the fact that the frequency sub-carriers configured for MRB transmission (which cannot be chosen flexibly due to, e.g., MBSFN area configuration) can have worse propagation conditions compared to the dynamic use of sub-carriers for unicast transmission. Due to this fact, the cell coverage (or cell border) for MRB transmission may be smaller than the cell coverage (cell border) for unicast DRBs. In Fig. 5, the MRB transmission cell border is shown by interrupted lines, whereas the unicast transmission cell border is shown with solid lines. In such situation, when a mobile terminal - denoted UE in Fig.
- the UE may not be able to correctly receive MRB transmission while the unicast DRB data can be still received correctly.
- the consequence is that the UE is not able to receive the MBMS data in the cell border, and therefore, the service continuity for the applications receiving the MBMS data is not provided.
- Use case 1 the cells of eNB1 and eNB2 are part of the same MBMS service bearer, but the cell of eNB1 is part of a different MBSFN area than the cell of eNB2.
- ⁇ Use case 2 the cells of eNB1 and eNB2 are part of the same MBMS service bearer, however, eNB1 and eNB2 are not configured with MBSFN.
- the UE when a UE is moving to the edge of the eNB1 cell or the eNB2 cell, and the UE is receiving the MBMS bearer service, the UE would lose the MBMS reception in eNB1 cell and in eNB2 cell, even before reaching the cell borders for handover conditions. For the time duration when the UE is located between the borders of the 'MBMS cell reception borders' of eNB1 and eNB2 cells, the UE would not have MBMS reception. Even in the case when the 'MBMS reception cell border' and 'unicast reception cell border' are nearly overlapping, service continuity is not provided, as the UE needs to find out and synchronize to the MBMS radio resources of the target cell.
- the MBMS service area (MBMS/MRB coverage) within the cell is smaller than cell coverage for unicast transmissions, and therefore, the UE would lose MBMS reception before reaching cell edge as defined for the handover conditions.
- Current state-of-the-art technologies can provide retransmission of MBMS data from the BM-SC to the UE, e.g. as described in File Delivery over Unidirectional Transport (FLUTE) protocol in IETF RFC 3926 (pre-FEC repair Quality of Experience (QoE) metrics report to allow operator to optimize FEC configuration of FLUTE).
- FLUTE File Delivery over Unidirectional Transport
- QoE pre-FEC repair Quality of Experience
- Another state-of-the-art solution is described in section 8.5 in 3GPP TS 26.346 for using MBMS streaming delivery on unicast delivery.
- the retransmission can be performed over a unicast EPS bearer.
- the UE can request the unicast transmission of the received service from the Application Server upon detection of service disruption via MBMS reception.
- the UE's application layer can detect the loss of data packets or frequent request for packet retransmission. This detection can be used as trigger for the UE's application to request via application level signaling to the Application Server (e.g. Public Safety Application Server or any other server which generates the data sent over MBMS bearer service in the 3GPP network) the transmission of the service data via unicast delivery.
- the Application Server e.g. Public Safety Application Server or any other server which generates the data sent over MBMS bearer service in the 3GPP network
- this is an application layer based detection of service disruption and according application layer initiated signaling to application server to request appropriate actions (e.g. unicast transmission of data) to preserve service continuity.
- the 3GPP layers access stratum or non-access stratum implementations
- the 3GPP layers detect that the (e)MBMS data cannot be received correctly, e.g. cannot be demodulated or decoded correctly at the 3GPP's physical, MAC or PDCP layers after reception.
- the 3GPP layers indicate to the Application layer the loss of service, so that the Application layer can take the needed actions.
- the Application layer requests from the GC-AS (via application layer signaling) unicast transmission of the GC session data.
- the Application initiates the application level signaling.
- One disadvantage is that the time duration between the detection of MBMS data loss and re-establishing of the service data reception in a unicast delivery manner (using existing or a new established EPS bearer) depends on the UE implementation, network and service provider conditions. This time duration may be considerable, and thus, obviously, no service continuity is provided. Therefore, reliable solutions are needed to assure service continuity.
- Fig. 6 this figure illustrates a scenario together with the corresponding signaling flow in accordance with a particularly preferred embodiment of the present invention.
- configuration procedure(s) for the mobile terminal (UE), RAN and core network (C-plane, e.g. MME) are carried out in the beginning in order to setup the conditions which allow to perform the solution.
- the configuration procedures include steps (1 ), (2) and (3), as shown in Fig. 6.
- the main part of the illustrated embodiment is based on the entity located in the RAN, preferably it is an eNB, denoted eNB in Fig. 6, which takes care about the service continuity. Based on radio reports sent by the UE the eNB determines that MBMS service is about to be interrupted due to bad radio conditions.
- the eNB determines what actions to perform in order to guarantee the service continuity of the MBMS data.
- the enhanced eNB functionality is shown in steps (5) and (6).
- the UE needs to be extended with functionality to perform procedures conformant to the action(s) decided by the eNB for service continuity.
- the text with bold font in the messages in steps (4) and (6) of Fig. 6 shows possible extensions to the current/existing signaling.
- the UE exchanges capabilities about support of (e)MBMS bearer service continuity.
- This capability exchange may happen either (a) during an Attach procedure, e.g. the UE includes the capability as part of the Attach request message, or (b) when the UE starts receiving (e)MBMS bearer services as an explicit NAS signaling exchange between UE and MME or RRC signaling between UE and serving eNB.
- step (1 ) the UE activates the reception of MBMS bearer service, which can be the GC data/media via a multicast delivery from the content provider (GC-AS) via an (e)MBMS bearer service.
- This step (1 ) includes signaling between UE, MME, and MBMS-related entities in the core network, e.g. MBMS gateway (MBMS GW) and/or BM-SC, as the purpose is to join to the already established MBMS bearer service.
- step (2) after the UE starts receiving (e)MBMS bearer service(s), the UE updates either the MME or the eNB or both about the current actively received eMBMS bearer service(s).
- the UE, or the MME, or both can indicate to eNB the TMGI(s) corresponding to the (e)MBMS bearer service(s).
- the indication can include the type of MBMS service, i.e. whether service continuity for this MBMS bearer (for the given UE or general for all UEs receiving this MBMS bearer) is needed or not. Further, the indication can provide information about the priority of the MBMS service compared to unicast DRB reception.
- two different embodiments - denoted by A and B in Fig. 6 - are envisioned on how information related to the UE's currently received MBMS service can be updated to the eNB or MME. These two embodiments are described as follows:
- step (2.A.1 ) the UE may indicate to the MME the successful joining to the MBMS bearer services (i.e. after successful reception of the MBMS data). This step can be performed optionally if the UE is configured to perform it. The configuration of the UE can be performed e.g. during step (0) described above or during any other NAS procedures as attach or TAU procedures. If the MME can become aware about the successful joining of the MBMS bearer service, then step (2.A.1) may be omitted and the MME can proceed with next step (2.A.2).
- step (2.A.2) after the MME is informed about the successful start of MBMS data reception by the UE (or joining the MBMS bearer service), MME updates its own UE's context, and further, performs UE's context update in the current eNB.
- This update to the eNB can include MBMS bearer service ID (e.g. TMGI), specific UE priorities (ARP) for the MBMS bearer service compared to other UE's unicast bearer(s) and other parameters.
- TMGI MBMS bearer service ID
- ARP specific UE priorities
- the UE can indicate to the eNB the activated reception of the MBMS bearer service (i.e. joining the MBMS bearer or start of successful reception of MBMS data).
- exemplary an RRC signaling can be used to exchange this indication between UE and eNB.
- the indication can include the MBMS bearer service ID (e.g. TMGI), specific UE priorities (ARP) for the MBMS bearer service compared to other UE's unicast bearer(s) and other parameters.
- step (3.1 ) after the eNB has been updated about the activated UE's MBMS bearer reception, the eNB determines whether the UE should be configured to include in its radio measurement reports also information about the quality of the MRB reception (or MBMS radio signal quality). It should be noted that the measurement reports are currently used as tool for the RAN to know whether handover procedure should be initiated, or to estimate the signal power for radio transmission. If the UE has activated multiple MBMS bearers, then the eNB should determine whether to activate the measurement reporting per MBMS bearer. With other words, for one MBMS bearer the reporting may be activated, but for other one it may not be activated. The eNB can use the priority or other criteria (e.g.
- the UE can indicate during step (2.A.1 ) or (2.B.1 ) whether service continuity for a particular MBMS/MRB bearer is needed.
- the eNB can determine whether the current UE measurement reporting should be changed, e.g. from "event-based” reporting to "periodic” reporting, or vice-versa from “periodic” to "event-based” reporting. Further, it is possible to configure the MBMS measurement reporting independently from the measurement reporting configured for handover procedure.
- the eNB may have knowledge about the MBMS service transmission in the neighbor cells, e.g. in which radio resources (frequencies) the MBMS/MRB is transmitted. If such information is available, the eNB can configure the UE with those MBMS resources in the neighbor cells, so that the UE can perform also MRB measurements for the neighbor cells similar to the (unicast) radio measurements for mobility.
- step (3.2) the eNB instructs the UE about the radio measurements including the MRB reporting.
- the MRB reporting can be configured for one or multiple of the currently received MBMS services. Further the MRB reporting can be performed also for neighbor cells.
- This instruction can be performed as an existing or new RRC signaling message, e.g. as reply to step (2.B.1 ), if option B from step (2) has been used.
- the eNB can use RRCConnectionReconfiguration message with extensions to the mobilityControllnformation or a new information e.g. called MBMSControllnformation.
- the UE can be configured to stay in CONNECTED state due to the MRB reporting.
- the UE may be configured with long DRX in order to save uplink resources. Event-based MRB reporting is also possible, as will be described in detail below in connection with Fig. 8.
- step (4) the UE sends enhanced radio measurement reports including MRB/MBMS-related radio signal reports to the eNB.
- the UE needs to re-configure its radio interface to start gathering MRB radio information similar to the unicast radio information measurements performed for the mobility/handover procedure.
- This MRB/MBMS reporting can be a part of the current UE's measurement reports to the eNB, or it can be a separate reporting.
- the measurements reports are sent over RRC signaling (RRC "MEASUREMENT REPORT" message from UE to eNB), so that it is preferable to extend this existing RRC signaling from UE to eNB to include MRB/MBMS reporting.
- the eNB determines the UE's reception quality of the MRB bearer (MBMS data) based on the measurement reports received in step (4). If the eNB determines that data loss of MRB connectivity is possible due to bad radio conditions, the eNB takes measures to preserve the service continuity for this MBMS bearer. It should be noted that for one MBMS bearer the radio conditions may be bad, whereas for other MBMS bearer or unicast bearer(s) received by the same UE the radio conditions can be still good. The eNB determines whether to provide service continuity for the given MBMS bearer with bad radio conditions based on the MBMS bearer type (i.e. importance, QoS parameters or kind of service) configuration during step (2), including the options A or B described above, and step (3.1 ).
- the MBMS bearer type i.e. importance, QoS parameters or kind of service
- the eNB shall determine which actions can be performed in order to assure the service continuity. This is generally shown as step (5.2) in Fig. 6.
- the eNB takes into consideration the MBMS transmission in the neighbor cell(s) according to the measurement report from step (4), but also the unicast bearer radio conditions.
- the eNB can take one or more of the following optional actions:
- step (5.A.2) the eNB decides to send MBMS data to UE via unicast DRB.
- This mapping of MBMS data to unicast DRB could be done as long as handover to a neighbor cell happens (where the UE can continue with the MBMS/MRB reception) or UE returns to better MBMS/MRB radio conditions in the same cell.
- How to map MBMS data to unicast DRB is explained in detail below, in particular in connection with Fig. 7. The indication to the UE is described in step (6).
- Option B In step (5.B.2), the eNB initiates handover (HO) to a neighbor eNB, which is configured with the same MBMS service and where the MBMS/MRB- related corresponding measurement reports have better quality than in the current cell.
- the option B is possible if the UE is configured with measurements for MBMS/MRB transmission resource(s) in the neighbor cells, as described in step (3.1 ).
- the eNB should decide according to the priority of MBMS and unicast services, i.e. if MBMS service(s) has higher priority, then the eNB should decide to perform handover to the neighbor cell, although the normal (unicast, non-MBMS) measurements do not indicate handover.
- the eNB can determine to apply option A from above, i.e. temporary transmission of the MBMS data over unicast DRB bearer, if the normal (non-MBMS, unicast) mobility measurements indicate that handover procedure is not required and/or the unicast transmission has higher priority than the MRB transmission.
- Option C This option, shown in step (5.C.2), is applicable in scenarios where the UE is close to the cell border to another target cell, which is not part of the MBMS service. With other words, the UE is going to leave the MBMS service area soon. As the MBMS data cannot be received in the neighbor cell anyway, the eNB may decide to trigger the UE to send an application level request for unicast delivery. Alternatively, the eNB may simply indicate to the UE that MBMS service continuity cannot be provided by the RAN. This is shown in detail in Fig. 9.
- Option D This option, shown in step (5.D.2), involves the MME in the decision process for the "action" to be taken for service continuity. For example, after the eNB determines the bad radio conditions for MBMS/MRB transmission for the given UE in step (5.1 ), the eNB indicates to the MME that the MBMS/MRB reception for the UE is going to be interrupted (or lost). Then the MME can take actions to avoid this interruption.
- One possible action would be that the MME informs the UE (e.g. via NAS signaling) about the MBMS/MRB reception loss, so that the UE's NAS layer can inform the application layer to take application layer measures to keep the service continuity.
- the indication from MME to UE can use an existing or a new NAS message and can contain the TMGI of the MBMS service. It should be noted that the indication from MME to UE is not shown in Fig. 6. Further, it should be noted that the signaling between eNB and MME involves the M2 and M3 interfaces and possible the MCE entity. This eNB-MME signaling needs to be extended to allow the indication of the new determination of bad MBMS/MRB radio conditions for a given UE.
- Option D can be applied as alternative for signaling exchange from eNB -> MME - > UE to all options A, B, C or other possible options.
- the MME initiates or allows a bearer modification procedure for the DRB only (not the whole EPS bearer) as described in step (5.A.2) above.
- This can be signaled from MME to eNB, so that the eNB can proceed further with step (6).
- the eNB indicates the deternnined action to the UE.
- This step can be done for all options for which the "action" for service continuity is decided in the eNB, as shown in steps (5.A.2), (5.D.2) and (5.C.2).
- the indication from the eNB to the UE can be included in an existing or a new RRC message. The content of the indication depends on the determined action in step (5.2). If eNB determines to apply option B from step (5.2), then no indication is needed.
- the eNB indicates to the UE that the MBMS service will be temporarily delivered over a particular unicast DRB.
- the indication can contain: 1 ) the MBMS service ID (e.g. TMGI, which the eNB stores in the UE's context as described in steps (1 ), (2) or (3)); and/or 2) the unicast bearer ID (DRB ID or EPS bearer ID), and/or 3) modified RRC connection parameters (e.g. DRX parameters, Inactivity timer); etc.
- the indication can contain information to the UE that the MBMS data is going to be transmitted over DRB, so that the UE does not need to perform any MBMS-related signaling/actions due to bad MBMS/MRB reception. With other words the UE may temporarily ignore the reception of the MBMS data over MRB.
- step (5.2) If eNB determined to apply option C from step (5.2), further details about step (6) are described below in connection with Fig. 9.
- step (7) the UE takes the actions according to the indication in step (6).
- step (7) further details about step (7) are described below in connection with Fig. 7.
- option C further details about step (7) are described below in connection with Fig. 9.
- the UE receives the indication from the eNB e.g. via RRC signaling, however the actions to be performed by the UE are on higher layers. Therefore, it is required that the UE implements ability (e.g. internal means or internal interfaces) in order to convey the information obtained in lower layer to the corresponding upper layer or software module.
- ability e.g. internal means or internal interfaces
- the UE needs first to implement means to understand this information and to derive the required action, to derive the concerned application, and also means to internally convey this information to the concerned application.
- the UE implements a kind of dispatcher software/layer/module, so that e.g. the RRC layer sends the indication to the dispatcher software/layer/module, which in turn determines the impacted/concerned application.
- step (5.2) which is not depicted in Fig. 6, is that the eNB can increase the MRB signal strength according to the received MRB measurement report, so that the MBMS data is received with higher quality at the
- the eNB can modify the modulation and coding scheme (MCS) to increase the robustness of the MRB data transmission.
- MCS modulation and coding scheme
- the eNB may decide to schedule the MRB transmission more frequently.
- possible limitations of the MRB scheduling might occur.
- the above solution option of increasing the signal strength would be reasonable as this would allow the UE to combine the MBMS/MRB signals from both cells and to achieve correct reception.
- the eNB processes the UE's measurement reports as part of the mobility procedure, i.e. to decide whether a handover procedure to neighbor cell should be performed.
- the MBMS/MRB-related information in the extended measurement reports is processed by the eNB for providing service continuity (i.e. not for mobility procedure).
- the MBMS/MRB-related information in the extended measurement reports is used for a new "MBMS service continuity" procedure in the eNB.
- Fig.7 this figure shows further details about option A of the possible actions determined by the eNB, i.e. step (5.A.2) as described above in connection with the embodiment of Fig. 6. Specifically, Fig.
- the MBMS-GW sends the data to the eNB via M1 reference point.
- the eNB maps the MBMS data over a MRB and all UEs that have activated the MBMS bearer reception would receive the MBMS data.
- UE_A one of the UEs, denoted UE_A in Fig. 7, has reported bad MRB radio conditions. Therefore, in step (5.1 ) of Fig. 6, based on the mechanism described in steps (2), (3), (4), the eNB determines to apply unicast transmission of the MBMS data to the UE_A in order to keep the MBMS service continuity. For this purpose the eNB maps the MBMS data on a unicast DRB.
- the UE_A can have one or more unicast DRB(s) established simultaneously.
- the eNB should decide which DRB to use based on the MRB's QoS parameters and the DRB's QoS parameters.
- mapping the MBMS data on GBR DRB may be not a good solution because the service already transmitted over the GBR DRB may be impacted. Therefore, it is advisable to map the MBMS data on non-GBR bearer having the Allocation and retention priority (ARP) value which is same or possibly similar to the MRB's ARP.
- the eNB copies/multiplies the MBMS data that is sent over the MRB to the unicast DRB.
- the eNB can temporarily change or upgrade the DRB's QoS parameters (QCI, ARP, etc.) to be the same as the MRB's QoS parameters as long as there is no overload or congestion scenario.
- Such update of the QoS parameters is done locally at the eNB and can be optionally communicated to the UE.
- the eNB can decide to perform this action based on the MBMS data service importance or based on the UE's preference/importance signaled during steps (1 ) or (2) of Fig. 6. If overload or congestion scenario happens, the eNB should restore the original DRB's QoS parameters.
- Whether to restore the original QoS parameters depends on the configuration in the eNB received from UE or MBMS bearer establishment during steps (1 ) or (2) of Fig. 6.
- the determining in the eNB how to transmit the MBMS data to the UE can be performed internally in the eNB.
- eNB does not perform explicit signaling/indication to the UE, but instead internally treats the MBMS packets differently from the data packets coming from the S/P-GW over S1 -U interface correspondingly to the DRB selected to MBMS transmission.
- the eNB can schedule the MBMS data packets with higher priority transmission (similar or same to the QCI used for the original MRB transmission) than the unicast data over the same DRB.
- the UE is not aware about the different treatment of MBMS and unicast packets in the eNB. This differentiated treatment is possible for the downlink transmission; however, it is not possible for the uplink transmission.
- the MBMS data For the transmission of the MBMS data over the DRB, the MBMS data needs to be processed in the eNB according to the processing of the unicast data packets.
- the eNB needs to perform the PDCP (Packet Data Convergence Protocol) layer, RLC (radio link control) layer and MAC (medium access control) layer processing.
- the UE is able to distinguish the MBMS data from the unicast data e.g. based on the destination IP address of the IP packets.
- the MBMS data packets have multicast IP address, so that the UE is able to forward the MBMS to the correct application even though the packets were transmitted over the unicast DRB.
- the UE's Application which receives the MBMS data, would not initiate any application-level signaling or actions to change the reception mode from the App server.
- the UE ignores the reception of the MBMS data over MRB for the time the UE receives the MBMS data over DRB.
- Having the different scheduling treatment of MBMS and non-MBMS data i.e. to treat the data as from different radio bearers
- same radio bearer would allow to fulfill the QoS requirements (e.g. different QCI) of the original MRB and unicast transmissions, whereas the optimal usage of radio resources is guaranteed.
- the eNB is extended to apply sub-division of the packets belonging to the same radio bearer (e.g. can be compared like having one radio bearer with two sub-bearers).
- FIG. 8 is a flow chart illustrating both for the UE and the eNB functionalities/procedures for steps (4), (5.1 ) and (5.A.2), i.e. for Option A from Fig. 6.
- the upper part of Fig. 8 shows the UE part where the UE reports the radio measurements to the eNB depending on the configuration. If event-based reporting is configured in the UE, then the event can be related to the MBMS&MRB reception only, i.e. independent from the unicast radio measurement for the mobility procedure. In such case the measurement report contains only the MBMS/MRB-related measurements.
- the "event" for the event-based reporting for the state-of-the-art mobility procedure is defined by thresholds of the signal strength of the current and neighbor cells.
- the "event” can be the absolute drop of the signal strength/quality of the MRB signal under a pre-defined threshold.
- the UE can apply the state-of-the-art "events” by comparing the MRB signal strength of the current and neighbor cells.
- the eNB determines whether the MBMS/MRB signal quality is poor. If this is the case, the eNB determines which action to perform as described in step (5.1 ) from of Fig. 6.
- Fig. 8 shows only the options A, B and C from step (5.2) in Fig. 6 (i.e. omitting option D). As will be appreciated by those skilled in the art, further options for actions (not shown in Fig. 8) are possible.
- This determination/decision can be influenced by configurations or capabilities during steps (0), (1 ) or (2). For example it may depend on UE's capabilities, MME's capabilities or eNB's capabilities. Further, as described in the different options in step (5.2) of Fig. 6, the eNB decision can depend on the MBMS/MRB and non-MBMS (normal unicast) measurement reports.
- Option A has been described already in more detail in connection with Fig. 7.
- Fig. 8 depicts the two possible branches of Option A depending on whether eNB cell is in congestion or limited radio resources. If there are enough available radio resources, then eNB can decide, if needed, to locally upgrade the radio DRB in order to adapt the QoS parameters to the MRB's QoS parameters. Otherwise the eNB maps and transmits the MBMS data over the unicast DRB without modification of the DRB bearer.
- the UE Since the transmission (or reception, respectively) of the MBMS data over a unicast DRB is meant to be temporal, the UE does not perform MBMS-related signaling with the BM-SC for deregistration, leave, change or other actions for the MBMS session control.
- the UE continues to perform the MBMS/MRB measurements (additionally to the usual radio measurements for mobility procedures), and thus, the UE continues to send measurement reports (event- based or periodic) to the eNB.
- the eNB evaluates the measurement reports and determines how to proceed in order to guarantee service continuity. In accordance with embodiments of the present invention, in this case the eNB may decide one of the following actions:
- the eNB may decide to continue the MBMS transmission over unicast DRB bearer. If the UE continues to experience poor MBMS/MRB transmission conditions and there are no proper neighbor cells, the eNB can keep the mapping of the MBMS data over the unicast DRB for longer time.
- the eNB maps the MBMS data over the unicast DRB for some time, there could be a timer-based solution to trigger the UE to contact the Application server to request unicast transmission using application based signaling.
- the timer can be implemented in the eNB or in the UE. If the timer is implemented in the eNB, then the eNB informs the UE after the timer expirations that the MBMS service cannot be offered any longer over DRB transmission (i.e. the eNB informs the UE to request application layer signaling for service continuity). If the timer is implemented in the UE, then the UE initiates actions upon timer expiration. A possible action can be to initiate application level signaling to request unicast transmission from the App server.
- the UE may inform the eNB and/or MME that the UE no longer receive the MBMS service.
- the UE deregisters with the eNB and/or with the MME regarding the MBMS service reception.
- the UE may also deregister for the given MBMS service with the BM-SC. 3.
- the eNB may resubmit the transmission over the MRB bearer. This is the case if the MRB signal quality improves to such an extent that the UE is able to normally receive the MRB transmission. If the eNB decides that the MRB signal is good enough, the eNB can initiate RRC signaling to inform the UE that the DRB transmission will be terminated and the UE can receive the MBMS service over MBMS/MRB transmission.
- the eNB may trigger handover to neighbor eNB if the conditions to handover procedure are fulfilled based on either normal (non-MBMS) or MBMS measurement reports.
- Fig. 9 is a signaling diagram that illustrates some more details related to step (5.2) of option C from Fig. 6, i.e. Fig. 9 is related to a scenario where service continuity is achieved based on application level signaling.
- the detailed explanation of Fig. 9 is given as follows:
- Steps (0-4), are similar to the ones explained in connection with Fig. 6.
- eNodeB based on measurement reports from the UE determines that (a) UE is having bad radio conditions, (b) determines whether higher level actions are required or whether the reports indicate only a short period of disruption. If the eNB determines that longer-term actions are needed, e.g. the UE is approaching a neighbor cell where the MBMS service is not configured or the UE is a low mobility device which reports bad MRB conditions for long time, the eNB can decide to indicated higher level action to the UE. It should be noted that "higher level action” means that the poor MRB reception cannot be recovered by radio layer 1 or layer 2 procedures, and therefore, e.g. actions from the application in the UE are needed.
- step (6) once eNB determines that actions are required above the radio layers, e.g. to request for unicast delivery from the communication peer, eNB sends explicit indication to the UE.
- This indication from eNB to UE could be in the form of RRC signaling.
- event-based measurement reports are configured for MB MS/ MRB reference signal reporting, events should be configured in such a manner that UE reports poor radio conditions of the MBMS/MRB reference signal appropriately.
- the eNB takes decision for high-level action, if the eNB cannot guarantee MBMS service continuity on the radio layers. This can happen if the eNB is configured with this solution, or the eNB cannot apply other solutions described herein as embodiments of the present invention (e.g. mapping of MBMS-data over unicast DRB, increase signal strength for MRB transmission, etc.).
- the eNB can inform the MME, so that the MME can inform the UE, e.g. via NAS signaling.
- the indication from the MME to UE includes MBMS service ID and appropriate action type, e.g. no longer MRB radio transmission possible, or higher- layer actions needed for service continuity.
- the UE needs to implement internal functionality, similar to the functionality described in connection with step (7) of Fig. 6, where the UE is capable to derive/understand the action as indicated by the eNB, and further is able to convey the indication to the impacted/concerned application or internal module/layer.
- step (7.1 ) once UE receives the indication from the eNB (or MME) about higher-layer actions needed, the UE first determines internally which application is impacted. This can happen e.g. in the NAS layer. With other words, the received indication from eNB in the RRC layer is forwarded to the NAS layer.
- the UE forwards this indication to the application layer which receives the particular MBMS service (according to the MBMS service ID, TMGI).
- the UE's application then generates an application layer message to request unicast service delivery by sending a relevant indication to the application server.
- This application layer message is sent over an existing (or new) EPS bearer to the application server.
- step (7.2) once the App Server receives this request to send data in unicast, it starts sending data over unicast bearer to the UE. This may result in the establishment of new EPS bearer in the 3GPP network.
- step (8) UE starts receiving data via unicast bearer over the serving eNB. If the UE would move out of the coverage footprint of the MBMS reference signal, the UE would keep the service/App data receptions, as the unicast transmission is more flexible (in terms of resource utilization) than the multicast transmission.
- the UE may inform the eNB and/or MME that the UE no longer receive the MBMS service.
- the UE deregisters with the eNB and/or with the MME regarding the MBMS service reception.
- the UE may also deregister for the given MBMS service with the BM-SC.
- the embodiments of the invention described above are based on the concept where the RAN (eNB) determines about switch from multicast to unicast delivery.
- the RAN eNB
- an embodiment is described which is based on an alternative concept where the decision for the service continuity, i.e. for the switch from multicast to unicast delivery, is taken in the UE.
- the solutions how the UE can determine the bad radio conditions for MBMS reception can be separated in two main categories: 1) solutions at the 3GPP radio layers (e.g. Physical or MAC layer) or 2) solutions at a higher layer above the 3GPP layers (Application layer or TCP layer).
- the UE can determine the poor radio conditions of the MBMS reception based on the packet losses at the higher layer above the 3GPP layers (Application layer or TCP layer).
- the layers above the 3GPP layers determine the need to initiate the switch from multicast to unicast delivery.
- the possible mechanisms to determine the need for App layer actions for service continuity are e.g. 1 ) the detection of missing packet, or 2) the triggering of retransmission mechanism in the layers above the 3GPP layers.
- the application layer may have a retransmission mechanism for requesting lost packets. If this retransmission mechanism is triggered for a configurable number of times, then the UE can determine that the radio conditions for MBMS reception are poor and the UE can decide to switch to unicast delivery.
- the data (streaming) codec used between the BM-SC and UE can also determine that retransmissions are needed.
- a similar approach is described in 3GPP TS 26.346 in section F.2 for the switching from MBMS to PSS (Packet- switched Streaming Service), however, this approach detects the need for switch after packet losses have already occurred.
- this is denoted as "MBMS layer” (or protocol stack generally responsible for performing the MBMS-relevant actions). For example, if the "MBMS layer" would request transmission of the MBMS data from the BM-SC, then the MBMS layer instead of requesting the retransmission can indicate the App layer to initiate request for unicast delivery. Based on this determination for retransmission in the MBMS layer, the UE can determine about the poor radio conditions, and consequently, the UE can request the application layer to take actions to switch from multicast to unicast delivery.
- Another embodiment for determining the switching from multicast to unicast delivery at higher layer above the 3GPP layers is to use the sequence number of the IP packets at the transport layer, e.g. TCP or UDP/RTP segments. If the transport layer (or other layer having sequence number of the received packets) determines that a segment/packet is missing, then the transport layer can indicate to the application layer (to which the packets are destined) that there are missing packets and actions from the application layer are needed. In such case, the application layer would request unicast delivery from the application server.
- the detection for switch to unicast delivery at the higher layer above the 3GPP layers may have the following drawback.
- An LTE protocol stack and possible interaction with GCSE is as shown in Fig. 10.
- the detection of the possible loss of data via multicast transmission, and also possible service disruption, in the 3GPP radio layers has the advantage of avoiding packet losses and less delay.
- the UE detects poor radio condition at the 3GPP radio layer(s)
- an indication is sent internally in the UE to the application which receives the MBMS data.
- the application can undertake the needed actions to request from the transmitting server a unicast delivery of the group session data.
- the UE In order for the UE to determine the poor radio conditions at the 3GPP radio layers, the UE needs to be configured with the threshold(s) for the MBMS radio signal strength.
- the configuration of the thresholds in the UE can be performed e.g. in one of the following manners (the list is not exhaustive):
- the network can determine based on various parameters, e.g. used modulation and coding scheme, and/or type of service data service, etc, which are the optimal MBMS signal thresholds for switch from multicast to unicast reception. Then this information is conveyed to the BM-SC and the BM-SC can forward the information to the AS (GCSE-AS) over the GC2 interface. Further, the AS can inform the UE via the application layer signaling about the proper radio parameters for the switch from multicast to unicast delivery. After receiving this information, the UE internally forwards this information to the 3GPP layers (RRC, MAC and/or Phy layer).
- RRC Radio Resource Control
- the mobile network operator determines the optimal radio conditions/thresholds for the switch from multicast to unicast delivery and informs the UE via signaling specified in Open Mobile Alliance (OMA) Device Management (DM) Working group, also known as OMA-DM signaling. This is a kind of semi-static configuration in the UE. The received configuration from the OMA-DM signaling should be stored and forwarded to the Phy layer. 3.
- a RAN node e.g. eNB
- the UE can internally determine the radio signal thresholds for switch from multicast to unicast delivery without any configuration from external entities.
- the thresholds can be pre-configured by the UE vendor.
- the mechanism of UE determined thresholds is described in further details in Fig. 1 1. As shown in this figure, it is assumed that UE internally determines thresholds for various modulation and coding schemes. When the MBMS reference signal or any other measurement which could indicate the signal quality (RSRP, RSSI-RSRP, RSRQ, SINR, BLER measurement of PMCH, etc.) goes below the determined threshold, UE informs the application to initiate unicast service delivery or inform the network using mechanisms described earlier in order to continue receiving group communication data in an uninterrupted manner.
- UE internally determined thresholds is that the UE may not have knowledge about the environment (e.g. urban, rural) and whether the neighbor cells are part of the same MBSFN area. Therefore, in connection with Fig. 12 the configuration of the thresholds via the RAN node (eNB) will be described.
- the eNB can determine the signal thresholds in a similar way as described in the embodiment of Fig. 1 1 , but additionally considering some of the following conditions: the MBMS bearer coverage (e.g.
- the following embodiment describes a mechanism for MBMS reference signal measurement configuration and thresholds in the UE by the eNB.
- This mechanism is basically derived from the embodiment of the invention described in connection with Fig. 6 enabling service continuity based on eNB involvement.
- the main concept of this embodiment is that the UE determines and initiates actions (e.g.
- Step (0) shown in Fig. 12 to (3.1 ) is identical or similar to steps (0) to (3.1 ) described in connection with Fig. 6.
- the detailed explanation of Fig. 12 is as follows:
- Step (0) is similar to the steps (0)-(3.1 ) from Fig. 6, whereby a UE subscribed to group communication services, either in RRCJdle or RRC_Connected mode enters the coverage area of a cell or eNB transmitting group communication services using eMBMS.
- step (1 ) eNB sends MBMS reference signal threshold configurations to the UE, either (a) using system information blocks which could be read by the UEs in idle and connected state or (b) using RRC signaling by the eNB.
- the thresholds could depend on the radio configuration used in the cell for eMBMS transmissions, such as modulation and coding scheme, the channel conditions in the cell, etc.
- the UE also starts receiving group communications data using multicast transmissions from the application server. It should be noted that in step (1 ) in Fig. 12, the order of the reception of multicast service on the one hand and the eNB configuration of MRB measurements on the other hand is arbitrary.
- the eNB is aware about the UE's activated MBMS services (GC services sent over MBMS bearer) and if the UE is in connected state, the eNB can use dedicated RRC signaling to the UE in order to configure the UE with MBMS reference signal thresholds. For this purpose, existing RRC signaling messages or newly defined RRC signaling messages can be used.
- the use of the configured MBMS signal thresholds is described in step (2). Now the scenario is considered where the UE reaches either the cell boundary (with a cell that does not have eMBMS transmissions) or regions where the eMBMS reception is poor.
- step (2) when the MBMS reference signal quality (or any signal from which MBMS reception quality can be estimated) goes below a threshold configured in step (1 ), the UE determines in sub-step (a) that the UE has reached a region where the probability of losing multicast signal reception is high, due to bad MRB radio conditions or any other factors due to which multicast reception could be lost.
- sub-step (b) the UE initiates actions for maintaining the service continuity.
- the exceeding or under- running of the MBMS signal thresholds configured in step (2) is used as a trigger in the UE to perform actions for service continuity for the reception of the MBMS data.
- the UE implements internal functionality, similar to the functionality described in connection with step (7) of Fig. 6, where the UE is capable to derive/understand the action as indicated by the eNB, and further is able to convey the indication to the impacted/concerned application or internal module/layer.
- step (3.1 ) One example of the actions performed by the UE upon detection of step (2), is shown in step (3.1 ) where the UE sends application level signaling using group communications application in the device to trigger unicast service delivery, receiving the response in (3.2).
- the actions performed by the UE are not limited to the one shown in steps (3.1 ) and (3.2).
- the UE may perform signaling to a 3GPP functional entity, e.g. eNB, MME, MBMS-Gateway or BMSC, to inform about losing reception of GC service over MBMS distribution.
- the 3PGG functional entity can initiate actions to keep the reception of GC service data at the UE by performing unicast transmission.
- step (4) the UE starts receiving data via unicast bearer, and stops listening to MBMS radio bearer, once reliable unicast bearer is established.
- the possible options for configuring the triggering criteria for the switch from multicast to unicast service delivery in step (3.2) could be similar to the cell reselection criteria defined for IDLE mode mobility in 3GPP TS 36.304, "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode," 3GPP Technical Specification, v.1 1.5.0, Sept. 2013.
- E-UTRA Evolved Universal Terrestrial Radio Access
- UE User Equipment
- UE User Equipment
- UE User Equipment
- UE User Equipment
- UE User Equipment
- MBMS reference signal levels in terms of reference signal received power (RSRP), or quality (RSRQ), or SINR goes below a configured threshold. It could also depend on other cell specific reference signal quality values as well, in order to avoid UE entering radio link failure conditions.
- the scheme could be implemented by conveying this information through extensions of currently defined system information blocks (for e.g. SIB-3 for cell reselection parameters or SIB-13 by extending already
- Another embodiment of configuring UE with thresholds for triggering the execution of step (3.2) for unicast service delivery involves using extensions of RRC signaling defined in [3].
- eNB using extensions of measurement reporting events currently defined for mobility, could signal to the UE regarding when unicast delivery should be triggered. This could be done by configuring absolute thresholds of signal power or quality (RSRP/RSRQ/SINR), and if the signal level goes below this threshold, the UE can trigger application level bearer modification, or by using relative thresholds when the difference between the neighbor cells' signal levels and the serving cell's signal levels are within a configured limit.
- RSRP/RSRQ/SINR absolute thresholds of signal power or quality
- eNB could apply different MBMS signal thresholds for the switch from multicast to unicast delivery for the different MBMS bearers, e.g. for the different MBSFN configurations or for the transmission of different media types for the same MBMS group.
- the eNB can inform the UE using RRC signaling about the MBMS signal threshold(s) for triggering of unicast service delivery, e.g. this informing is performed for each TMGI (corresponding to received MBMS service).
- MBMS signal thresholds sets are calculated by the eNB and informed to the UEs for different MBMS bearer services (e.g. for different TMGIs). Having this, a single UE receiving multiple MBMS bearers can have different MBMS signal thresholds configurations.
- the eNB could configure a single threshold for all the UEs in the cell using extensions to SIBs or RRC signaling. Extensions of currently defined SIBs could also be used to signal different thresholds for different MBSFN areas, PMCHs, eMBMS sessions or any other radio parameters used for the transmissions.
- the modification for RRC signaling could be done in for e.g. ReportConfigEUTRA defined in [2] for UE measurement and reporting triggering.
- the system information block related signaling could be done by modifying PMCH-lnfoList, MBSFN-SubframeConfig, MBSFN-ArealnfoList or any other eMBMS related signaling configurations considered in [2]. It could also be done along with informing the UE regarding MCS configurations used and could be signaled when there are any changes in radio parameters used for MBMS.
- a variant with minimum impact on the RAN node is proposed in Fig. 1 1.
- the reason is that in same deployments changes/updates to the existing RAN infrastructure should be avoided and the solutions could be implemented in the UE without signaling impacts with the radio access network.
- the thresholds for unicast service triggering could be UE specific, based on internal calculations of thresholds, based on previous history of service disruptions, or based on semi-static configurations by external entities such as OMA-DM or using third part application configurations (for e.g. GC-AS) using application layer (data layer) signaling.
- the main aspect of these embodiments is based on the functionality in the network to decide how to provide service continuity based on the device (UE) and network capabilities. It is described that the UE may have special capabilities to support (e)MBMS service continuity. During the attach procedure the UE indicates its capabilities related to (e)MBMS service continuity. Based on these capabilities and the network capabilities, the network takes decision which solution to apply. In the embodiment described hereinafter the network decides after the attach procedure or after the establishment of the GC session to apply a solution where the eNB indicates to the UE to request unicast delivery.
- a main idea of this embodiment is that prior to the handover the UE initiates unicast delivery from the content provider (GC-AS). It is assumed that the UE is in RRC and NAS CONNECTED state. The initiation of the unicast delivery is an application layer signaling. It is assumed that there is an internal interface between the GC application in the UE and the 3GPP (transport) layer. This internal interface should enable the exchange of information between UE's NAS/AS layer and the application layer.
- GC-AS content provider
- new EPS bearer may be established, or an existing EPS bearer can be modified, or the internal routing of GC data/media in the UE can be modified in order to receive the GC data/media over unicast delivery.
- Fig. 13 illustrates a procedure for a solution where the UE initiates request for unicast delivery of GC data/media upon eNB indication to UE about loss of (e)MBMS service in the target cell.
- the handover decision is taken from the source eNB1 according to the legacy mobility concept in 3GPP.
- the initial assumption is that, the UE receives the GC data/media via a multicast delivery from the content provider (GC-AS) via an (e)MBMS bearer service.
- GC-AS content provider
- eMBMS bearer service The following steps from Fig. 13 describe the details of this solution:
- step (1 ) the UE exchanges capabilities about support of (e)MBMS bearer service continuity.
- This capability exchange may happen either (1 ) during the Attach procedure, e.g. the UE includes the capability as part of the Attach request message, or (2) when the UE starts receiving (e)MBMS bearer services as explicit NAS signaling exchange to MME or RRC signaling to serving eNB.
- step (2) in Fig. 13 the eNB1 maintains information about the (e)MBMS bearer service(s) which the UE currently receives.
- the eNB can obtain this information either from the UE or from the MME.
- the eNB1 stores an enhanced UE context including information of the (e)MBMS bearer service(s) currently received by the UE.
- the eNB1 stores the TMGI(s) of the (e)MBMS services received by the UE.
- the eNB1 does not inform the UE about the (e)MBMS bearer service(s) configuration of the neighbor cells.
- step (3) the UE performs the normal radio measurements of the neighbor cells as part of the mobility procedure in CONNECTED state.
- the UE detects threshold for handover event, the UE sends the measurement reports to the source eNB1. This step does not require any changes to the UE.
- step (4) based on the measurement report, the source eNB detects whether the possible target cell offers the MBMS service which the UE actively listens.
- eNB1 has stored information whether and which MBMS services (TMGIs) are subscribed and actively received by the UE.
- TMGIs MBMS services
- the source eNB1 either maintains information about the neighbor cells and which neighbor cells offer which MBSFN service, or first requests the target eNB2 (according to the measurement report from the UE) or the MME/MCE about the offered MBSFN services. After the reply from the target eNB or MME/MCE, the source eNB determines if the possible target cell offers the MBSFN service.
- step (5) if the source eNB determines that the target cell does not offer the (e)MBMS service(s), the source eNB informs the UE (e.g. via RRC signaling message) about "NO activated eMBMS service in target cell", i.e. the target eNB2 is not part of the MBSFN area.
- the UE forwards this information from eNB1 internally from the RRC layer to the corresponding application (e.g. GC application) using the (e)MBMS service.
- This UE internal forwarding of the eNBI 's indication may be performed in several ways. For instance, a special API between the RRC layer and application layer may be specified.
- the RRC layer may forward the indication to NAS layer; then NAS layer forwards the indication via a special API to the application layer.
- the UE's application initiates application level signaling to request the GC-AS to start unicast delivery of GC data/media.
- the GC-AS either (a) replies with application level signaling to the UE to confirm the reception and processing of the UE's request; or (b) the GC-AS starts sending data/media via unicast and the UE detects via reception of the data that the request was processed in the GC-AS.
- Step (7) can be observed as reply to the indication from step (5).
- the UE indicates to the source eNB1 that the indication from step (5) was successfully received and processed, so that eNB1 can proceed with the handover procedure.
- the eNB1 delays the sending of "Handover" command to the UE in order to give the opportunity to UE and GC-AS to establish (or at least partially establish) the unicast delivery path with corresponding EPS bearer establishment. There could be several options for determining the delay time.
- the eNB1 can wait until the UE indicates that it is "ready" for handover as explained above, or/and the eNB1 can wait for a given configurable time and after expiring of this time, the eNB1 can proceed with the handover procedure, i.e. sending Handover command message to the UE. Applying both options together would avoid waiting too long until the UE acknowledges the processing of the eNBI 's indication from step (5).
- step (8) eNB1 initiates the handover procedure according to 3GPP TS23.401.
- the UE After completing the handover from eNB1 to eNB2, the UE receives the GC data/media via unicast delivery from the GC-AS via the eNB2.
- the UE can use the TMGI to indicate this to the MME or eNB (related to step (2) Fig. 13); • Ability to support the procedure of "NO activated eMBMS service in target cell".
- This procedure includes the ability to receive an indication from the eNB that particular (e)MBMS bearer service(s), which the UE currently receives, are not supported in the target cell.
- the UE supports means to forward internally the indication to the corresponding application, i.e. the AS layer informs the NAS layer and it informs the application. In change, the Application informs the NAS layer and AS layer that the indication has been processed. Further as part of this procedure the UE is able to send a kind of "reply" indication to the eNB1 to indicate that the UE is ready for the handover procedure.
- eNB is able to exchange capabilities information with UE and/or with MME about the UE's capability of (e)MBMS bearer service continuity (related to step (1 ) in Fig. 13).
- eNB is able to store enhanced UE context (for UE is CONNECTED mode) including the UE's currently received (e)MBMS bearer service(s).
- This UE context can be dynamically updated by the UE or by the MME (related to step (2) in Fig. 13).
- eNB is able to exchange information with the neighbor eNBs in order to determine which (e)MBMS bearer service(s) the neighbor eNBs support (related to step (4) in Fig. 13).
- eNB is able to indicate to the UE that in the candidate target cell the currently received (e)MBMS bearer service(s) are not supported, and correspondingly, the eNB1 is able to receive a "reply" indication from the UE. Further, the eNB may implement a timer for delayed triggering the handover procedure after indication to the UE about "NO activated eMBMS service in target cell" (related to steps (5) and (7) in Fig. 13).
- eNB1 sends a modified/extended Handover Command message (which could be an RRC message) to the UE which contains the same or similar indication, i.e. "NO activated eMBMS service in target cell".
- a modified/extended Handover Command message (which could be an RRC message)
- the UE After receiving such an extended Handover Command message, the UE first initiates application level signaling to the GC-AS in order to request unicast delivery of the GC session data.
- This application level signaling may be the same as described above in connection with steps (6.1 ) and (6.2) of Fig. 13.
- the UE executes the handover procedure to eNB2.
- the indication "NO activated eMBMS service in target cell” is provided to the UE in the Handover Command message and the UE performs the application level signaling in steps (6.1 ) and (6.2) before starting the synchronization with the target cell.
- the UE can be pre-configured with neighbor cells info for (e)MBMS services, i.e. whether the neighbor cells support the (e)MBMS service currently received for GC data.
- neighbor cells info for (e)MBMS services i.e. whether the neighbor cells support the (e)MBMS service currently received for GC data.
- Such a configuration in the UE can be performed either by the eNB to which the UE is currently connected (called source eNB) or by the MME to which the UE currently has a NAS connection (usually the MME knows about the configured (e)MBMS services in the E-UTRAN from the MCE). If such a configuration is performed in the UE, then there is no need to use the explicit indication as shown in Fig. 13 or to use an extended Handover Command.
- the eNB1 would send non-modified Handover Command message (i.e.
- GPRS General Packet Radio Service
- E-UTRAN Evolved Universal Terrestrial Radio Access Network
- the main benefits of the above embodiments are 1 ) service continuity, i.e. no data flow interruption is perceived by the application layer and 2) the solution works even in case of (e)MBMS services provided in only one cell or a small number of cells where all cells can be boundary cells. While the embodiments solve the targeted objective of providing service continuity, there are also some shortcomings: First, that may be an increased delay of the handover execution procedure, as the application level signaling, i.e. steps (6.1 ) and (6.2) of Fig. 13, are performed after the handover preparation procedure and before the handover synchronization procedure (i.e. before the UE start the synchronization with the target eNB2). Second, there is no network guarantee for the service continuity, i.e.
- the network doesn't know if the UE has successfully performed the application level signaling.
- One other aspect that considered in the context of embodiments of the present invention is the case where the UE moves into (e)MBMS bearer service (MBSFN area) coverage whereas unicast delivery of the GC session data was used before the movement. In such case it is beneficial if the UE switches from unicast to multicast delivery in order to better utilize the radio resources.
- the problem is how does the UE perceive that the GC service data that is currently received via unicast delivery is also distributed over (e)MBMS bearer service.
- One possible solution would be to configure the UE via application level signaling (i.e. from GC-AS) with cell IDs in which the GC service is distributed via (e)MBMS bearer service. Then an UE internal API between the Access Stratum and the Application layer is needed in order to forward information about the current cell ID from the 3GPP transport layer to the application layer.
- the application layer determines that the UE entered a cell which is a part of the MBSFN area, the UE can initiate application-level signaling to the GC-AS to request multicast delivery and stop the unicast delivery.
- the GC-AS should know the cell IDs in which the (e)MBMS bearer service is configured. This could be a problem as the 3GPP mobile operator may not provide such information outside the 3GPP network and if the GC-AS is a 3 rd party server, the GC-AS would not know the MBSFN configuration area. • There is a need of frequent update which would result in increased signaling load. Each time an (e)MBMS bearer service is activated, deactivated or modified, the 3GPP operator should update the GC-AS application. Consecutively the GC- AS should update all UEs currently receiving the GC service data via unicast delivery. This application-level update is performed and the UEs are required to store this information even if the UEs will never enter the MBSFN area.
- a solution to overcome the above disadvantages is proposed herewith which is based on indication provided to a UE receiving GC service via unicast delivery by the 3GPP network (using 3GPP signaling means like NAS signaling or RRC signaling) when the UE moves into the MBSFN area coverage.
- the UE during GC service setup procedure indicates to the MME the service/session group identifier (GC-ID) identifying the GC service session.
- GC-ID can be the APN used for the GC service, another example can be a special call ID.
- the MME should maintain UE's context storing the currently activate GC-ID. Other UEs using the same GC service should use the same GC- ID.
- the MME should maintain a mapping of the (e)MBMS bearer service's TMGI with the GC-ID.
- the MME determines that the unicast EPS bearer established for GC service over eNB2 is used for the same service as the (e)MBMS bearer service provided by eNB2 as well. Since the MME knows the all cells configured for the (e)MBMS bearer service, when a UE (in CONNECTED state) moves into a cell transmitting the (e)MBMS bearer service having GC-ID same as the UE's currently used GC-ID, the MME determines (based on the GC-ID) that the UE receives the same GC service data over unicast bearer which is also provided over the (e)MBMS bearer service.
- the MME can indicate to the UE that the GC service data is available over (e)MBMS service in the current cell and the MME can indicate (e)MBMS's TMGI to the UE.
- the UE initiates 3GPP procedures, e.g. signaling to BMSC to receive the security parameters and scanning the SIB for (e)MBMS resources as described in 3GPP TS23.246, to start receiving the GC data/media via (e)MBMS bearer service. Additionally the UE would perform application-level signaling to GC-AS to indicate the reception of the GC service over (e)MBMS bearer service and to indicate to GC-AS that the unicast delivery can be terminated.
- 3GPP procedures e.g. signaling to BMSC to receive the security parameters and scanning the SIB for (e)MBMS resources as described in 3GPP TS23.246, to start receiving the GC data/media via (e)MBMS bearer service.
- the UE would perform application-level signaling to GC-
- Fig. 14 shows the solution explained above about maintaining the service continuity when the UE enters MBSFN area and switch from unicast to multicast delivery is performed.
- the thick arrows in Fig. 14 show data flow and the thin arrows show the signaling flow between the functional entities.
- the steps from Fig. 14 are described as follows:
- the UE establishes GC service over eNB1.
- eNB1 is not part of the (e)MBMS bearer service or no (e)MBMS bearer service has been established yet, the GC service data delivery from GC-AS to UE is via unicast bearer.
- the MME may use the APN of the Group communication session as GC-ID.
- the UE optionally may indicate a GC-ID for the specific Group communication session.
- eNB2 is part of (e)MBMS bearer service that can be established before or after the UE established the GC service via unicast delivery.
- the (e)MBMS bearer service can be seen as pre- established prior to the handover procedure.
- the MME maintains the GC-ID of the established (e)MBMS bearer service (e.g. to eNB2).
- the MME is able to map the relation of the GC-ID of the unicast bearers with the GC-ID of the multicast bearers.
- information exchange between the MMEs e.g. via S10 reference point, is exchanged in order to update each other about the available (e)MBMS bearer service (and the corresponding GC-IDs) in the MME pool area.
- the UE performs a handover from eNB1 to eNB2. This is a handover procedure as described in [2].
- step (4) the signaling exchange described in step (4) is performed during the handover procedure step (3) itself, it is possible that the UE starts pretty soon the reception of the GC service data over (e)MBMS bearer in eNB2's cell, and thus, the UE can immediately start to perform steps (6.1 ) and (6.2). With other words, steps (3) and (4) can be integrated during the handover procedure and the GC service reception over unicast delivery can be obsolete, as the UE can quickly join the (e)MBMS bearer service.
- step (4) the MME determines that the unicast EPS bearer established for GC service over eNB2 is used for the same service as the (e)MBMS bearer service provided by eNB2 as well.
- the MME determines that the UE participates the same GC session as the one provided over the (e)MBMS bearer service.
- the MME determines that the GC-ID of the unicast bearer and the (e)MBMS bearer service are the same.
- the MME After determining the relation of the GC services over unicast EPS bearer and (e)MBMS bearer service over eNB2, the MME indicates to the UE that the GC service can be obtained via (e)MBMS bearer service, and more specifically the MME indicates the TMGI of the (e)MBMS bearer service. It is assumed that the GC service received by the UE and the GC service distributed over (e)MBMS bearer service are the same, i.e. if the GC service received by the UE includes multiple public safety groups then the GC service over the (e)MBMS bearer service should include the same public safety groups.
- the MME shall have means to determine the exact mapping of GC service distributed over unicast EPS bearer and (e)MBMS bearer.
- the MME can use NAS signaling message (e.g. NAS Information message) to indicate to the UE the available (e)MBMS bearer service and the corresponding TMGI.
- step (4) can be a separate signaling procedure between MME and UE as described in Fig. 14, but it can also be performed during the handover procedure in step (3). With other words the signaling from MME to UE may be a part of the handover procedure.
- step (5) after the UE has been indicated about the available (e)MBMS bearer service in the current cell of eNB2, the UE starts scanning the broadcasted cell system information (SIB) to discover the radio resources at which the (e)MBMS bearer service is broadcasted. Additionally, the UE may initiate procedures to join the (e)MBMS bearer service as described in 3GPP TS23.246. After steps (5) and (5.1 ) the UE is able to receive the GC service via (e)MBMS bearer service broadcasted over MRB (P2M radio bearer).
- SIB broadcasted cell system information
- steps (6.1 ) the UE uses application-level signaling to inform the GC-AS about the ability to receive GC service data over (e)MBMS bearer service.
- step (6.2) the GC-AS can acknowledge the reception of the message in step (6.1 ) and to terminate the transmission of GC service data over unicast delivery.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A method for providing multicast/broadcast service continuity for mobile terminals in a radio access network, wherein said mobile terminals register with a base station of said radio access network regarding said multicast/broadcast service and wherein said base station transmits multicast/broadcast service related data as group communications to said registered mobile terminals, is characterized in that a mobile terminal performs multicast/broadcast service related radio measurements and that a decision on actions to be performed by said base station and/or by said mobile terminal for preserving reliable transmission/reception of said multicast/broadcast service related data to/by said mobile terminal is taken based on the results of said multicast/broadcast service related radio measurements. Related base stations and mobile terminals are also described.
Description
METHOD FOR PROVIDING MULTICAST/BROADCAST SERVICE CONTINUITY FOR MOBILE TERMINALS
The present invention relates to a method for providing multicast/broadcast service continuity for mobile terminals in a radio access network, wherein said mobile terminals register with a base station of said radio access network regarding said multicast/broadcast service and wherein said base station transmits multicast/broadcast service related data as group communications to said registered mobile terminals.
Furthermore, the present invention relates to a corresponding base station and a corresponding mobile terminal.
Abbreviations as used herein are as follows
APN Access Point Name
BLER Block Error Rate
BM-SC Broadcast Multicast - Service Center
DRB Default Radio Bearer
eMBMS Evolved Multimedia Broadcast Multicast Service
eNB Evolved Node B (also called base station, RNC, etc.)
EPC Evolved Packet Core
E-RAB EUTRAN Radio Access Bearers
EPS Evolved Packet System
E-UTRA Evolved Universal Terrestrial Radio Access
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GBR Guaranteed Bit Rate
GC Group Communication
GC-AS Group Communication - Application Server
GCSE Group Communication System Enabler
IMS IP Multimedia Subsystem
LTE Long Term Evolution
MAC Media Access Control
MBMS Multimedia Broadcast Multicast Service
MBMS-GW MBMS-Gateway
MBSFN Multimedia Broadcast Multicast Service Single Frequency Network
MCE Multi-Cell/Multicast Coordination Entity
MCH Multicast Channel
MCCH Multicast Control Channel
MCS Modulation and Coding Scheme
MME Mobility Management Entity
MRB MBMS Point to Multipoint Radio Bearer
NAS Non-Access Stratum
OMA-DM Open Mobile Alliance - Device Management
PDCP Packet Data Convergence Protocol
PDN-GW Packet Data Network Gateway
PMCH Physical Multicast Channel
RNC Radio Network Controller
RRC Radio Resource Control
RSRP Reference Signal Received Power
RSRQ Reference Signal Received Quality
SIB System Information Block
SINR Signal to Interference Noise Ratio
TMGI Temporary Mobile Group Identity
QCI QoS Class Identifier
QoS Quality of Service
MBMS (Multimedia Broadcast Multicast Service) is a point-to-multipoint service specified by the 3GPP where data can be transmitted from one source to multiple
receivers. Evolved MBMS (eMBMS) was defined in 3GPP LTE Releases 10 and 1 1 to improve the performance using flexible and enhanced bit rates, single frequency network (SFN) operations and physical layer carrier configuration flexibility (see, for reference, D. Lecompte, et al.: "Evolved Multimedia Broadcast/Multicast Service (eMBMS) in LTE-Advanced: Overview and Rel-1 1 Enhancements", IEEE Commun. Mag., vol. 50, no. 1 1 , pp. 68-74, Nov. 2012, briefly denoted [1] hereinafter). It also enables delivery of high-quality content to multiple UEs with enhanced QoS in areas which MBMS services are provisioned. A possible deployment option of MBMS service using a pre-defined area is as shown in Fig. 1.
In Fig. 1 , MBSFN service area is the area where all eNBs can be synchronized to provide MBSFN transmission and could contain multiple MBSFN areas. As seen in Fig. 1 , an (e)MBMS service area can include multiple MBSFN areas, but also single eNBs that are not part of any MBSFN area. From a UE perspective, all transmissions from a single MBSFN area eNBs are seen as a single transmission. The cells within an MBSFN area will advertise its availability and UEs can consider a subset of MBSFN areas that are configured. As shown in the figure, there could be reserved cells within MBSFN area which does not have any MBSFN transmissions and can use the resource allocated for MBSFN in neighboring cells for other services. In other words, these reserved cells transmit the (e)MBMS data in different radio resources than the MBSFN area. But the maximum transmit power that can be allocated for such resources are limited so as to not cause interference to MBSFN cells. MBMS reception is possible for UEs in RRC_CONNECTED or RRCJDLE states. Whenever receiving MBMS services, a user shall be notified of an incoming call, and can make outgoing calls (as specified in 3GPP TS 36.300, "E-UTRA and E-UTRAN: Overall description; Stage 2," v 1 1.5.0, March 2013, briefly denoted [2] hereinafter). As explained, the terms MBSFN service area and (e)MBMS service area have different meaning, but in the context of the present invention these terms may be used in an interchangeable manner, i.e. expressing in general an area where the UE receives (e)MBMS data via (e)MBMS bearer service.
An (e)MBMS bearer service is identified by an IP multicast address, an APN network identifier and also by a TMGI (Temporary Mobile Group Identity) inside one PLMN. With other words, the UE can use the TMGI as ID for the (e)MBMS bearer service over certain access technology. For example the UTRAN MBMS bearer service and the E-UTRAN eMBMS bearer service would have 2 different TMGIs.
The reference architecture of MBMS is as shown in Fig. 2. Here, Multi- Cell/Multicast Coordination Entity (MCE) could be a functional entity which could be either stand-alone node or a part of another network node (e.g. eNB as shown in Fig. 3 (b)). The MCE takes care of admission control, counting results of MBMS services, and resumption or suspension of MBMS sessions depending in the counting results. The M3 reference point is specified for the control plane between MME and E-UTRAN, assuming that the MCE is a part of the E-UTRAN. The details of the (e)MBMS reference points and related functional entities can be found in the above mentioned standard document [2].
Two possible deployment alternatives that are considered in [2] are shown in Fig. 3, with additional consideration of an X2 interface between eNBs for the present invention. Currently, the services which are envisioned to be provisioned using MBMS are streaming of audio and video, updates of smartphone applications, etc. (as outlined in [1]). It is also considered that the regions where these services are to be delivered will be pre-planned and service continuity over the MBSFN area is enabled by using careful prior planning of the network. The service continuity is enabled as the MBMS service data is delivered in the same radio resources in the cells participating in the MBSFN area. In the boundary area of two cells, the UE can combine the signals coming from the two cells, and therefore, the probability of correct reception is increased. The detailed physical layer parameter configurations for the MBMS feature are available in 3GPP TS 36.331 , "E-UTRA: RRC Protocol Specification," v 1 1.2.0, briefly denoted [3] hereinafter). Some of the key features of Multicast Channel (MCH) defined in [2, 3] are the requirement to be broadcast in the entire coverage area of the cell, support for MBSFN combining of MBMS transmission on multiple cells, and support for
semi-static resource allocation e.g. with a time frame of a long cyclic prefix. The mapping of downlink transport and physical channels are as shown in Fig. 4.
Here, the MBMS control information is conveyed using MCCH logical channel and user data using MTCH logical channel which can be used for multiple MBMS services within an MBSFN area. For simplicity we refer to the multicast transmission over the Core network and over the Radio Access Network (RAN) as point-to-multipoint (P2M) bearer. More specifically, the P2M bearer uses the mechanisms specified in 3GPP for transmission of data from BM-SC to UE.
Mobility aspects of UEs moving out from a MBSFN area to other neighboring cells where the MBMS service is broadcasted/multicasted on different radio resources, but still service continuity is expected has not been considered yet. The reason for this is that current MBMS applications are mainly streaming applications and short interruption perceived by the user is not critical. However, for new services, e.g. as currently studied in 3GPP is ongoing related to Group Communication System Enablers for LTE (GCSE_LTE) (see, for reference 3GPP TS 22.468, "Group Communication System Enablers for LTE: (GCSE_LTE) Release 12," ver 0.3.0), radio resource efficiency via MBMS transmission and service continuity are key features. Key criteria for radio resource efficiency is "to avoid duplicated/unnecessary radio resources allocated for different group members in a certain cell" and "to minimize impact on signaling plane for the network". If many UEs are located in the same area, then MBMS is considered as one of the potential technologies to achieve this resource efficiency when transmitting Group Communication (GC) service data (see, for reference S2-131509, "Architecture & functional requirements for GCSE_LTE," Qualcomm Incorporated). In cells where there are only few UEs, the network may decide to distribute the GC service data in unicast way. In view of the above, it is an objective of the present invention to improve and further develop a method for providing multicast/broadcast service continuity for mobile terminals in a radio access network of the initially described type in such a way that MBMS reception losses experienced by the mobile terminal/UE, in
particular when reaching cell edges, are effectively prevented, thereby avoiding the above disadvantages.
In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized in that a mobile terminal performs multicast/broadcast service related radio measurements and that a decision on actions to be performed by said base station and/or by said mobile terminal for preserving reliable transmission/reception of said multicast/broadcast service related data to/by said mobile terminal is taken based on the results of said multicast/broadcast service related radio measurements.
Furthermore, the aforementioned object is accomplished by a base station comprising the features of claim 22. According to this claim such a base station is characterized in that the base station is further configured to receive results of multicast/broadcast service related radio measurements performed by a mobile terminal and, based on the received measurement results, to take a decision on actions to be performed for preserving reliable transmission of said multicast/broadcast service related data to said mobile terminal.
Still further, the aforementioned object is accomplished by a mobile terminal comprising the features of claim 24. According to this claim such a mobile terminal is characterized in that the mobile terminal is further configured to perform multicast/broadcast service related radio measurements and to take a decision on actions to be performed for preserving reliable reception of said multicast/broadcast service related data based on the results of said multicast/broadcast service related radio measurements.
The present invention together with embodiments as described below deals with all disadvantages of the possible solutions mentioned above. The proposed solution is based on network-initiated measures to provide service continuity. The described embodiments aim also to meet the system requirements as per document 3GPP TS 22.468, "Group Communication System Enablers for LTE: (GCSE_LTE) Release 12," ver 0.3.0, where it is specified that "When UEs are
moving among cells during group communication, service continuity shall be supported".
The main idea of the present invention is based on the UE-assisted reporting of MBMS-related radio quality conditions (MBMS-related radio measurements) to the radio network node (eNB), and the radio network (eNB) takes a decision how to provide the reliable transmission of the MBMS data to the UE. The UE's current/existing radio measurements (used for the mobility procedure) may be extended to additionally include information about the MBMS radio signal quality. After receiving the extended measurement reports from the UE, the eNB may decide based on MBMS service topology (e.g. if the MBMS service, both MBSFN or non-MBSFN, is configured in the neighboring cells or if unicast transmission conditions are possible) which actions to perform in order to guarantee the service continuity of the MBMS service reception in the UE.
The MBMS-related information (MRB reporting) in the measurement reports from UE to eNB can be e.g. MRB signal strength (similar to the signal strength of pilot signal as reported currently in measurement report), or decoding error of received MRB data, or block error rate of received MRB data and other possible physical layer, MAC layer or RLC layer parameters. For example, if MBSFN is configured, there is an MBSFN carrier symbol within the transmission frame as described in [2] (3GPP TS 36.300, section 5.1.4). This MBSFN carrier symbol can be used as referenced signal to generate the MBMS-related information in the UE's measurement reports.
Generally, it is important to note that the term "MBMS" as employed in the art implies "multimedia service" which is not necessarily true when the multicast/broadcast service contains public safety services or any other service data. Therefore, in the context of the present invention the term "MBMS" (including the derived forms "MBMS transmission", "MBMS cell boarder" or "MBMS data") is used equivalent to Multicast/Broadcast-Radio (MB-R) or multicast radio bearer (MRB, as analogy to unicast DRB). In this sense the terms MRB transmission and MRB cell border can be used interchangeably with MBMS transmission, etc.
I m porta nt features of the invention together with embodiments are:
1 ) A RAN node (eNB) is able to 1 ) determine whether to configure a UE for measurement reporting for MBMS/MRB-related information and 2) is able to gather information from neighbor cells about their MBMS transmission resources/conditions.
2) A RAN node (eNB) is able to decide based on the measurement reports from a particular UE whether to start transmitting the MBMS data over unicast DRB to this particular UE. Further the eNB is able to decide whether to apply different scheduling priorities for MBMS and non-MBMS data over the same unicast DRB.
3) A RAN node is able to determine signal thresholds for the UE and to configure the UE with these thresholds in order to enable the UE to perform, only when needed, the actions for the switch from multicast to unicast delivery of group session data.
In summary, the present invention describes several flavors of the solution for the problem of providing service continuity. Currently there are no mechanisms that enable a service continuity of broadcast/multicast service(s) when the UE leaves an area of the (e)MBMS transmission coverage, but is still in cell coverage for unicast transmission. Compared to prior arts and the possible solutions described above, solutions according to embodiments of the present invention provide the benefits of 1 ) service continuity, i.e. no data flow interruption is perceived by the application layer receiving the MBMS data and 2) the switch from multicast to unicast delivery only if needed (i.e. not too early when the switch can be avoided or not too late when the connection is disrupted).
There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claims 1 and 19, and 21 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the
drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing
Fig. 1 is a schematic view illustrating the general concept of MBMS service provisioning according to prior art,
Fig. 2 is a schematic view illustrating the eMBMS reference architecture according to prior art, Fig. 3 is a schematic view illustrating eMBMS deployment alternatives according to prior art,
Fig. 4 is a schematic view illustrating channel mapping employed in connection with MBMS according to prior art,
Fig. 5 is a schematic view illustrating a communication system with possible coverage areas during MBMS reception,
Fig. 6 is a signaling diagram of a mobile terminal's MBMS-related reporting in accordance with a first embodiment the present invention,
Fig. 7 is a schematic view illustrating a communication system in which service continuity is achieved based on mapping of MBMS data on unicast radio bearer according to an embodiment of the invention,
Fig. 8 is a flow chart illustrating reporting and action taking functionalities and procedures for the mobile terminal and the base station according to embodiments of the present mention, Fig. 9 is a signaling diagram of a scenario where service continuity is achieved based on application level signaling in accordance with an embodiment the present invention,
Fig. 10 is a diagram illustrating the LTE data plane protocol stack,
Fig. 1 1 is a diagram illustrating a mechanism of mobile terminal determined thresholds according to another embodiment of the present invention,
Fig. 12 is a diagram illustrating still another embodiment of the present invention where the mobile terminal determines application layer actions based on configurations from a RAN node,
Fig. 13 is a signaling diagram illustrating mobile terminal initiated GC unicast delivery before handover according to an embodiment of the present invention, and
Fig. 14 is a signaling diagram illustrating a switch scenario from unicast to multicast delivery upon the mobile terminal entering MBSFN area according to an embodiment of the present invention.
Hereinafter, before describing embodiments of the present invention, first, the general problem underlying the present invention is described in detail with reference to Fig. 5.
Considering a scenario in a communication system as shown in Fig. 5, two base stations - denoted eNB1 and eNB2 - are part of the same MBMS service bearer. As the eNBs transmit the MBMS data over the MRB with the same signal strength and on the same frequency (sub-carrier) for the whole cell, it may happen that the eNB transmit the MRB data with less power strength than the possible maximum power strength used for unicast DRBs in order to keep the interference to neighbor sub-carriers low. Another reason for different coverage areas of MBMS (MRB) transmissions on the one hand and unicast transmissions on the other hand is the fact that the frequency sub-carriers configured for MRB transmission (which cannot be chosen flexibly due to, e.g., MBSFN area configuration) can have worse propagation conditions compared to the dynamic use of sub-carriers for unicast transmission. Due to this fact, the cell coverage (or cell border) for MRB transmission may be smaller than the cell coverage (cell border) for unicast DRBs.
In Fig. 5, the MRB transmission cell border is shown by interrupted lines, whereas the unicast transmission cell border is shown with solid lines. In such situation, when a mobile terminal - denoted UE in Fig. 5 - is moving to the cell border as shown in Fig. 5, the UE may not be able to correctly receive MRB transmission while the unicast DRB data can be still received correctly. The consequence is that the UE is not able to receive the MBMS data in the cell border, and therefore, the service continuity for the applications receiving the MBMS data is not provided.
At the bottom of Fig. 5 two use cases are shows in which the above problem can happen:
• Use case 1 : the cells of eNB1 and eNB2 are part of the same MBMS service bearer, but the cell of eNB1 is part of a different MBSFN area than the cell of eNB2.
· Use case 2: the cells of eNB1 and eNB2 are part of the same MBMS service bearer, however, eNB1 and eNB2 are not configured with MBSFN.
In both cases, when a UE is moving to the edge of the eNB1 cell or the eNB2 cell, and the UE is receiving the MBMS bearer service, the UE would lose the MBMS reception in eNB1 cell and in eNB2 cell, even before reaching the cell borders for handover conditions. For the time duration when the UE is located between the borders of the 'MBMS cell reception borders' of eNB1 and eNB2 cells, the UE would not have MBMS reception. Even in the case when the 'MBMS reception cell border' and 'unicast reception cell border' are nearly overlapping, service continuity is not provided, as the UE needs to find out and synchronize to the MBMS radio resources of the target cell.
To put the problem in other words, the MBMS service area (MBMS/MRB coverage) within the cell is smaller than cell coverage for unicast transmissions, and therefore, the UE would lose MBMS reception before reaching cell edge as defined for the handover conditions.
Current state-of-the-art technologies can provide retransmission of MBMS data from the BM-SC to the UE, e.g. as described in File Delivery over Unidirectional Transport (FLUTE) protocol in IETF RFC 3926 (pre-FEC repair Quality of Experience (QoE) metrics report to allow operator to optimize FEC configuration of FLUTE). Another state-of-the-art solution is described in section 8.5 in 3GPP TS 26.346 for using MBMS streaming delivery on unicast delivery. The retransmission can be performed over a unicast EPS bearer.
The disadvantages of these state-of-the-art solutions are due to the fact that they rely on the application level or service level mechanisms. If the application or service layer notice packet losses and initiate actions for service recovery, some packets can be lost already, which does not guarantee loss-free data reception of application data sent over MBMS service bearer. Another mechanism for MBMS service continuity is described in document [2] (TS 36.300, section 15.4). The specification describes that service continuity is provided when the UE moves within the same MBSFN area. For this purpose the UE in IDLE state can change the prioritization of frequencies in order to keep the reception of the MBMS service in the MBSFN area. A UE in CONNECTED state may indicate its preference in receiving MBMS service compared to unicast reception and the eNB can decide whether and how to map/schedule the frequencies for unicast transmission in order to keep the MBMS service reception.
However, the problem outlined above (i.e. MBMS/MRB coverage within the cell is smaller than cell coverage for unicast transmissions) is not solved by the above described state-of-the art. Service interruption can still happen when the UE leaves the MBSFN area until the UE configures the reception of the MBMS service in the target cell and also depending on the MRB coverage of the MBMS frequencies used in the source and target cells.
One possible solution to solve the problem outlined above is based on UE-initiated and triggered actions on the application layer from UE to the Application Server. The UE can request the unicast transmission of the received service from the Application Server upon detection of service disruption via MBMS reception. For
example, the UE's application layer can detect the loss of data packets or frequent request for packet retransmission. This detection can be used as trigger for the UE's application to request via application level signaling to the Application Server (e.g. Public Safety Application Server or any other server which generates the data sent over MBMS bearer service in the 3GPP network) the transmission of the service data via unicast delivery. With other words, this is an application layer based detection of service disruption and according application layer initiated signaling to application server to request appropriate actions (e.g. unicast transmission of data) to preserve service continuity.
Another alternative of the possible solution for UE-initiated signaling to the application server is that the 3GPP layers (access stratum or non-access stratum implementations) in the UE (instead of the application layer) detect that the (e)MBMS data cannot be received correctly, e.g. cannot be demodulated or decoded correctly at the 3GPP's physical, MAC or PDCP layers after reception. Then, the 3GPP layers indicate to the Application layer the loss of service, so that the Application layer can take the needed actions. In particular, the Application layer requests from the GC-AS (via application layer signaling) unicast transmission of the GC session data. After the Application layer in the UE is aware about the MBMS service/data loss, the Application initiates the application level signaling.
However, there are several disadvantages of such solution. One disadvantage is that the time duration between the detection of MBMS data loss and re- establishing of the service data reception in a unicast delivery manner (using existing or a new established EPS bearer) depends on the UE implementation, network and service provider conditions. This time duration may be considerable, and thus, obviously, no service continuity is provided. Therefore, reliable solutions are needed to assure service continuity.
Turning now to Fig. 6, this figure illustrates a scenario together with the corresponding signaling flow in accordance with a particularly preferred embodiment of the present invention. According to this embodiment, configuration procedure(s) for the mobile terminal (UE), RAN and core network (C-plane, e.g.
MME) are carried out in the beginning in order to setup the conditions which allow to perform the solution. The configuration procedures include steps (1 ), (2) and (3), as shown in Fig. 6. The main part of the illustrated embodiment is based on the entity located in the RAN, preferably it is an eNB, denoted eNB in Fig. 6, which takes care about the service continuity. Based on radio reports sent by the UE the eNB determines that MBMS service is about to be interrupted due to bad radio conditions. Consequently, the eNB determines what actions to perform in order to guarantee the service continuity of the MBMS data. The enhanced eNB functionality is shown in steps (5) and (6). Correspondingly, the UE needs to be extended with functionality to perform procedures conformant to the action(s) decided by the eNB for service continuity. The text with bold font in the messages in steps (4) and (6) of Fig. 6 shows possible extensions to the current/existing signaling.
The detailed explanation of the embodiment illustrated in Fig. 6 is given as follows: During the optional step (0) the UE exchanges capabilities about support of (e)MBMS bearer service continuity. This capability exchange may happen either (a) during an Attach procedure, e.g. the UE includes the capability as part of the Attach request message, or (b) when the UE starts receiving (e)MBMS bearer services as an explicit NAS signaling exchange between UE and MME or RRC signaling between UE and serving eNB.
In step (1 ), the UE activates the reception of MBMS bearer service, which can be the GC data/media via a multicast delivery from the content provider (GC-AS) via an (e)MBMS bearer service. This step (1 ) includes signaling between UE, MME, and MBMS-related entities in the core network, e.g. MBMS gateway (MBMS GW) and/or BM-SC, as the purpose is to join to the already established MBMS bearer service.
ln step (2), after the UE starts receiving (e)MBMS bearer service(s), the UE updates either the MME or the eNB or both about the current actively received eMBMS bearer service(s). For example the UE, or the MME, or both can indicate to eNB the TMGI(s) corresponding to the (e)MBMS bearer service(s). The indication can include the type of MBMS service, i.e. whether service continuity for this MBMS bearer (for the given UE or general for all UEs receiving this MBMS bearer) is needed or not. Further, the indication can provide information about the priority of the MBMS service compared to unicast DRB reception. With respect to step (2), two different embodiments - denoted by A and B in Fig. 6 - are envisioned on how information related to the UE's currently received MBMS service can be updated to the eNB or MME. These two embodiments are described as follows:
Option A:
In step (2.A.1 ), the UE may indicate to the MME the successful joining to the MBMS bearer services (i.e. after successful reception of the MBMS data). This step can be performed optionally if the UE is configured to perform it. The configuration of the UE can be performed e.g. during step (0) described above or during any other NAS procedures as attach or TAU procedures. If the MME can become aware about the successful joining of the MBMS bearer service, then step (2.A.1) may be omitted and the MME can proceed with next step (2.A.2).
In step (2.A.2), after the MME is informed about the successful start of MBMS data reception by the UE (or joining the MBMS bearer service), MME updates its own UE's context, and further, performs UE's context update in the current eNB. This update to the eNB can include MBMS bearer service ID (e.g. TMGI), specific UE priorities (ARP) for the MBMS bearer service compared to other UE's unicast bearer(s) and other parameters. Option B:
Alternatively, in step (2.B.1 ), the UE can indicate to the eNB the activated reception of the MBMS bearer service (i.e. joining the MBMS bearer or start of successful reception of MBMS data). Exemplary an RRC signaling can be used to exchange this indication between UE and eNB. The indication can include the
MBMS bearer service ID (e.g. TMGI), specific UE priorities (ARP) for the MBMS bearer service compared to other UE's unicast bearer(s) and other parameters.
In step (3.1 ), after the eNB has been updated about the activated UE's MBMS bearer reception, the eNB determines whether the UE should be configured to include in its radio measurement reports also information about the quality of the MRB reception (or MBMS radio signal quality). It should be noted that the measurement reports are currently used as tool for the RAN to know whether handover procedure should be initiated, or to estimate the signal power for radio transmission. If the UE has activated multiple MBMS bearers, then the eNB should determine whether to activate the measurement reporting per MBMS bearer. With other words, for one MBMS bearer the reporting may be activated, but for other one it may not be activated. The eNB can use the priority or other criteria (e.g. other QoS parameters like QCI, ARP or type of service over MBMS) of the MBMS bearer service in order to determine whether to activate the MRB/MBMS measurement reporting for a given bearer in the UE. Also, the UE can indicate during step (2.A.1 ) or (2.B.1 ) whether service continuity for a particular MBMS/MRB bearer is needed. The eNB can determine whether the current UE measurement reporting should be changed, e.g. from "event-based" reporting to "periodic" reporting, or vice-versa from "periodic" to "event-based" reporting. Further, it is possible to configure the MBMS measurement reporting independently from the measurement reporting configured for handover procedure.
The eNB may have knowledge about the MBMS service transmission in the neighbor cells, e.g. in which radio resources (frequencies) the MBMS/MRB is transmitted. If such information is available, the eNB can configure the UE with those MBMS resources in the neighbor cells, so that the UE can perform also MRB measurements for the neighbor cells similar to the (unicast) radio measurements for mobility.
In step (3.2) the eNB instructs the UE about the radio measurements including the MRB reporting. The MRB reporting can be configured for one or multiple of the
currently received MBMS services. Further the MRB reporting can be performed also for neighbor cells. This instruction can be performed as an existing or new RRC signaling message, e.g. as reply to step (2.B.1 ), if option B from step (2) has been used. For example, the eNB can use RRCConnectionReconfiguration message with extensions to the mobilityControllnformation or a new information e.g. called MBMSControllnformation. The UE can be configured to stay in CONNECTED state due to the MRB reporting. Depending on the MRB reporting frequency and on the QoS requirements for the activated DRB(s) in parallel in the uplink, the UE may be configured with long DRX in order to save uplink resources. Event-based MRB reporting is also possible, as will be described in detail below in connection with Fig. 8.
In step (4), the UE sends enhanced radio measurement reports including MRB/MBMS-related radio signal reports to the eNB. After the instruction from the eNB in the step (3.2), the UE needs to re-configure its radio interface to start gathering MRB radio information similar to the unicast radio information measurements performed for the mobility/handover procedure. This MRB/MBMS reporting can be a part of the current UE's measurement reports to the eNB, or it can be a separate reporting. Currently, the measurements reports are sent over RRC signaling (RRC "MEASUREMENT REPORT" message from UE to eNB), so that it is preferable to extend this existing RRC signaling from UE to eNB to include MRB/MBMS reporting. Further details about the UE reporting will be described below in connection with Fig. 8. In step (5.1 ) the eNB determines the UE's reception quality of the MRB bearer (MBMS data) based on the measurement reports received in step (4). If the eNB determines that data loss of MRB connectivity is possible due to bad radio conditions, the eNB takes measures to preserve the service continuity for this MBMS bearer. It should be noted that for one MBMS bearer the radio conditions may be bad, whereas for other MBMS bearer or unicast bearer(s) received by the same UE the radio conditions can be still good. The eNB determines whether to provide service continuity for the given MBMS bearer with bad radio conditions based on the MBMS bearer type (i.e. importance, QoS parameters or kind of
service) configuration during step (2), including the options A or B described above, and step (3.1 ).
If service continuity to the UE for the MBMS bearer should be provided, the eNB shall determine which actions can be performed in order to assure the service continuity. This is generally shown as step (5.2) in Fig. 6. The eNB takes into consideration the MBMS transmission in the neighbor cell(s) according to the measurement report from step (4), but also the unicast bearer radio conditions. The eNB can take one or more of the following optional actions:
Option A: In step (5.A.2), the eNB decides to send MBMS data to UE via unicast DRB. This mapping of MBMS data to unicast DRB could be done as long as handover to a neighbor cell happens (where the UE can continue with the MBMS/MRB reception) or UE returns to better MBMS/MRB radio conditions in the same cell. How to map MBMS data to unicast DRB is explained in detail below, in particular in connection with Fig. 7. The indication to the UE is described in step (6).
Option B: In step (5.B.2), the eNB initiates handover (HO) to a neighbor eNB, which is configured with the same MBMS service and where the MBMS/MRB- related corresponding measurement reports have better quality than in the current cell. The option B is possible if the UE is configured with measurements for MBMS/MRB transmission resource(s) in the neighbor cells, as described in step (3.1 ).
A problem can occur if the non-MBMS/non-MRB measurements (i.e. normal radio measurements for mobility procedure) do not indicate to eNB a need for handover, however the MBM/MRB measurements indicate to eNB that handover is required (or may be helpful). In such a case, the eNB should decide according to the priority of MBMS and unicast services, i.e. if MBMS service(s) has higher priority, then the eNB should decide to perform handover to the neighbor cell, although the normal (unicast, non-MBMS) measurements do not indicate handover. However, the eNB can determine to apply option A from above, i.e. temporary transmission of the MBMS data over unicast DRB bearer, if the normal (non-MBMS, unicast)
mobility measurements indicate that handover procedure is not required and/or the unicast transmission has higher priority than the MRB transmission.
Option C: This option, shown in step (5.C.2), is applicable in scenarios where the UE is close to the cell border to another target cell, which is not part of the MBMS service. With other words, the UE is going to leave the MBMS service area soon. As the MBMS data cannot be received in the neighbor cell anyway, the eNB may decide to trigger the UE to send an application level request for unicast delivery. Alternatively, the eNB may simply indicate to the UE that MBMS service continuity cannot be provided by the RAN. This is shown in detail in Fig. 9.
Option D: This option, shown in step (5.D.2), involves the MME in the decision process for the "action" to be taken for service continuity. For example, after the eNB determines the bad radio conditions for MBMS/MRB transmission for the given UE in step (5.1 ), the eNB indicates to the MME that the MBMS/MRB reception for the UE is going to be interrupted (or lost). Then the MME can take actions to avoid this interruption. One possible action would be that the MME informs the UE (e.g. via NAS signaling) about the MBMS/MRB reception loss, so that the UE's NAS layer can inform the application layer to take application layer measures to keep the service continuity. The indication from MME to UE can use an existing or a new NAS message and can contain the TMGI of the MBMS service. It should be noted that the indication from MME to UE is not shown in Fig. 6. Further, it should be noted that the signaling between eNB and MME involves the M2 and M3 interfaces and possible the MCE entity. This eNB-MME signaling needs to be extended to allow the indication of the new determination of bad MBMS/MRB radio conditions for a given UE.
Option D can be applied as alternative for signaling exchange from eNB -> MME - > UE to all options A, B, C or other possible options.
According to another alternative embodiment for option D the MME initiates or allows a bearer modification procedure for the DRB only (not the whole EPS bearer) as described in step (5.A.2) above. This can be signaled from MME to eNB, so that the eNB can proceed further with step (6).
ln step (6) the eNB indicates the deternnined action to the UE. This step can be done for all options for which the "action" for service continuity is decided in the eNB, as shown in steps (5.A.2), (5.D.2) and (5.C.2). The indication from the eNB to the UE can be included in an existing or a new RRC message. The content of the indication depends on the determined action in step (5.2). If eNB determines to apply option B from step (5.2), then no indication is needed.
If the determined action is Option A from step (5.2) then the eNB indicates to the UE that the MBMS service will be temporarily delivered over a particular unicast DRB. For example, the indication can contain: 1 ) the MBMS service ID (e.g. TMGI, which the eNB stores in the UE's context as described in steps (1 ), (2) or (3)); and/or 2) the unicast bearer ID (DRB ID or EPS bearer ID), and/or 3) modified RRC connection parameters (e.g. DRX parameters, Inactivity timer); etc. Additionally or merely the indication can contain information to the UE that the MBMS data is going to be transmitted over DRB, so that the UE does not need to perform any MBMS-related signaling/actions due to bad MBMS/MRB reception. With other words the UE may temporarily ignore the reception of the MBMS data over MRB.
If eNB determined to apply option C from step (5.2), further details about step (6) are described below in connection with Fig. 9.
In step (7) the UE takes the actions according to the indication in step (6). In case of Option A from step (5.2), further details about step (7) are described below in connection with Fig. 7. In case of option C from step (5.2), further details about step (7) are described below in connection with Fig. 9.
Specifically in case of options C and D, the UE receives the indication from the eNB e.g. via RRC signaling, however the actions to be performed by the UE are on higher layers. Therefore, it is required that the UE implements ability (e.g. internal means or internal interfaces) in order to convey the information obtained in lower layer to the corresponding upper layer or software module. For example, in case of option C, if the eNB indicates that Application layer signaling is needed to
request for unicast delivery, the UE needs first to implement means to understand this information and to derive the required action, to derive the concerned application, and also means to internally convey this information to the concerned application. It is also possible that the UE implements a kind of dispatcher software/layer/module, so that e.g. the RRC layer sends the indication to the dispatcher software/layer/module, which in turn determines the impacted/concerned application.
Yet another embodiment for step (5.2), which is not depicted in Fig. 6, is that the eNB can increase the MRB signal strength according to the received MRB measurement report, so that the MBMS data is received with higher quality at the
UE. Optionally in addition or alternatively the eNB can modify the modulation and coding scheme (MCS) to increase the robustness of the MRB data transmission.
However, in this case the problem may arise that the throughput may not be sufficient. As a solution, based on the MRB QoS parameters, the eNB may decide to schedule the MRB transmission more frequently. Here, possible limitations of the MRB scheduling might occur.
If the current eNB cell and the close neighbor eNB cell(s) are part of the same MBSFN area, then the above solution option of increasing the signal strength would be reasonable as this would allow the UE to combine the MBMS/MRB signals from both cells and to achieve correct reception.
It should be noted that currently the eNB processes the UE's measurement reports as part of the mobility procedure, i.e. to decide whether a handover procedure to neighbor cell should be performed. However, the MBMS/MRB-related information in the extended measurement reports, as proposed in accordance with embodiments of the present invention, is processed by the eNB for providing service continuity (i.e. not for mobility procedure). With other words the MBMS/MRB-related information in the extended measurement reports is used for a new "MBMS service continuity" procedure in the eNB.
Turning now to Fig.7, this figure shows further details about option A of the possible actions determined by the eNB, i.e. step (5.A.2) as described above in connection with the embodiment of Fig. 6. Specifically, Fig. 7 shows the MBMS data flow (in the downlink). The MBMS-GW sends the data to the eNB via M1 reference point. The eNB maps the MBMS data over a MRB and all UEs that have activated the MBMS bearer reception would receive the MBMS data. However, it is assumed that one of the UEs, denoted UE_A in Fig. 7, has reported bad MRB radio conditions. Therefore, in step (5.1 ) of Fig. 6, based on the mechanism described in steps (2), (3), (4), the eNB determines to apply unicast transmission of the MBMS data to the UE_A in order to keep the MBMS service continuity. For this purpose the eNB maps the MBMS data on a unicast DRB. The UE_A can have one or more unicast DRB(s) established simultaneously. The eNB should decide which DRB to use based on the MRB's QoS parameters and the DRB's QoS parameters. However, mapping the MBMS data on GBR DRB may be not a good solution because the service already transmitted over the GBR DRB may be impacted. Therefore, it is advisable to map the MBMS data on non-GBR bearer having the Allocation and retention priority (ARP) value which is same or possibly similar to the MRB's ARP. The eNB copies/multiplies the MBMS data that is sent over the MRB to the unicast DRB. The eNB can temporarily change or upgrade the DRB's QoS parameters (QCI, ARP, etc.) to be the same as the MRB's QoS parameters as long as there is no overload or congestion scenario. Such update of the QoS parameters is done locally at the eNB and can be optionally communicated to the UE. The eNB can decide to perform this action based on the MBMS data service importance or based on the UE's preference/importance signaled during steps (1 ) or (2) of Fig. 6. If overload or congestion scenario happens, the eNB should restore the original DRB's QoS parameters. Whether to restore the original QoS parameters depends on the configuration in the eNB received from UE or MBMS bearer establishment during steps (1 ) or (2) of Fig. 6.
The determining in the eNB how to transmit the MBMS data to the UE (i.e. whether to change the QoS parameters or not) can be performed internally in the eNB. With other words, eNB does not perform explicit signaling/indication to the UE, but instead internally treats the MBMS packets differently from the data packets coming from the S/P-GW over S1 -U interface correspondingly to the DRB selected to MBMS transmission. For example, if MBMS reception has higher priority than the unicast data reception, the eNB can schedule the MBMS data packets with higher priority transmission (similar or same to the QCI used for the original MRB transmission) than the unicast data over the same DRB. The UE is not aware about the different treatment of MBMS and unicast packets in the eNB. This differentiated treatment is possible for the downlink transmission; however, it is not possible for the uplink transmission.
For the transmission of the MBMS data over the DRB, the MBMS data needs to be processed in the eNB according to the processing of the unicast data packets. For example, the eNB needs to perform the PDCP (Packet Data Convergence Protocol) layer, RLC (radio link control) layer and MAC (medium access control) layer processing. The UE is able to distinguish the MBMS data from the unicast data e.g. based on the destination IP address of the IP packets. The MBMS data packets have multicast IP address, so that the UE is able to forward the MBMS to the correct application even though the packets were transmitted over the unicast DRB. Having this solution, the UE's Application, which receives the MBMS data, would not initiate any application-level signaling or actions to change the reception mode from the App server. The UE ignores the reception of the MBMS data over MRB for the time the UE receives the MBMS data over DRB.
Having the different scheduling treatment of MBMS and non-MBMS data (i.e. to treat the data as from different radio bearers) for the same radio bearer would allow to fulfill the QoS requirements (e.g. different QCI) of the original MRB and unicast transmissions, whereas the optimal usage of radio resources is guaranteed. This would require extensions to the eNB, more particular to the eNB scheduling mechanism and internal marking of packets belonging to the same
radio bearer to apply different scheduling. With other words, the eNB is extended to apply sub-division of the packets belonging to the same radio bearer (e.g. can be compared like having one radio bearer with two sub-bearers). Fig. 8 is a flow chart illustrating both for the UE and the eNB functionalities/procedures for steps (4), (5.1 ) and (5.A.2), i.e. for Option A from Fig. 6. The upper part of Fig. 8 shows the UE part where the UE reports the radio measurements to the eNB depending on the configuration. If event-based reporting is configured in the UE, then the event can be related to the MBMS&MRB reception only, i.e. independent from the unicast radio measurement for the mobility procedure. In such case the measurement report contains only the MBMS/MRB-related measurements. The "event" for the event-based reporting for the state-of-the-art mobility procedure is defined by thresholds of the signal strength of the current and neighbor cells. For the purpose of even-based triggering for MBMS/MRB transmission, the "event" can be the absolute drop of the signal strength/quality of the MRB signal under a pre-defined threshold. However, if the UE is configured with the information about the MBMS/MRB transmission frequencies (resources) in the neighbor cells, then the UE can apply the state-of-the-art "events" by comparing the MRB signal strength of the current and neighbor cells.
After the eNB receives the UE measurement report(s), the eNB determines whether the MBMS/MRB signal quality is poor. If this is the case, the eNB determines which action to perform as described in step (5.1 ) from of Fig. 6. Fig. 8 shows only the options A, B and C from step (5.2) in Fig. 6 (i.e. omitting option D). As will be appreciated by those skilled in the art, further options for actions (not shown in Fig. 8) are possible.
Which solution option A, B, C, D or other possible, or combination of the options is to be applied needs to be determined by the eNB. This determination/decision can be influenced by configurations or capabilities during steps (0), (1 ) or (2). For example it may depend on UE's capabilities, MME's capabilities or eNB's capabilities. Further, as described in the different options in step (5.2) of Fig. 6, the
eNB decision can depend on the MBMS/MRB and non-MBMS (normal unicast) measurement reports.
Option A has been described already in more detail in connection with Fig. 7. Fig. 8 depicts the two possible branches of Option A depending on whether eNB cell is in congestion or limited radio resources. If there are enough available radio resources, then eNB can decide, if needed, to locally upgrade the radio DRB in order to adapt the QoS parameters to the MRB's QoS parameters. Otherwise the eNB maps and transmits the MBMS data over the unicast DRB without modification of the DRB bearer.
Since the transmission (or reception, respectively) of the MBMS data over a unicast DRB is meant to be temporal, the UE does not perform MBMS-related signaling with the BM-SC for deregistration, leave, change or other actions for the MBMS session control. The UE continues to perform the MBMS/MRB measurements (additionally to the usual radio measurements for mobility procedures), and thus, the UE continues to send measurement reports (event- based or periodic) to the eNB. The eNB evaluates the measurement reports and determines how to proceed in order to guarantee service continuity. In accordance with embodiments of the present invention, in this case the eNB may decide one of the following actions:
1. The eNB may decide to continue the MBMS transmission over unicast DRB bearer. If the UE continues to experience poor MBMS/MRB transmission conditions and there are no proper neighbor cells, the eNB can keep the mapping of the MBMS data over the unicast DRB for longer time.
2. Alternatively, if the eNB maps the MBMS data over the unicast DRB for some time, there could be a timer-based solution to trigger the UE to contact the Application server to request unicast transmission using application based signaling. The timer can be implemented in the eNB or in the UE. If the timer is implemented in the eNB, then the eNB informs the UE after the timer expirations that the MBMS service cannot be offered any longer over DRB transmission (i.e. the eNB informs the UE to request application layer signaling for service
continuity). If the timer is implemented in the UE, then the UE initiates actions upon timer expiration. A possible action can be to initiate application level signaling to request unicast transmission from the App server. After the UE completes action(s) and receives the services reliably over unicast bearer, the UE may inform the eNB and/or MME that the UE no longer receive the MBMS service. With other words the UE deregisters with the eNB and/or with the MME regarding the MBMS service reception. The UE may also deregister for the given MBMS service with the BM-SC. 3. The eNB may resubmit the transmission over the MRB bearer. This is the case if the MRB signal quality improves to such an extent that the UE is able to normally receive the MRB transmission. If the eNB decides that the MRB signal is good enough, the eNB can initiate RRC signaling to inform the UE that the DRB transmission will be terminated and the UE can receive the MBMS service over MBMS/MRB transmission.
4. According to a still further alternative the eNB may trigger handover to neighbor eNB if the conditions to handover procedure are fulfilled based on either normal (non-MBMS) or MBMS measurement reports.
Fig. 9 is a signaling diagram that illustrates some more details related to step (5.2) of option C from Fig. 6, i.e. Fig. 9 is related to a scenario where service continuity is achieved based on application level signaling. The detailed explanation of Fig. 9 is given as follows:
Steps (0-4), are similar to the ones explained in connection with Fig. 6.
In step (5), eNodeB based on measurement reports from the UE determines that (a) UE is having bad radio conditions, (b) determines whether higher level actions are required or whether the reports indicate only a short period of disruption. If the eNB determines that longer-term actions are needed, e.g. the UE is approaching a neighbor cell where the MBMS service is not configured or the UE is a low mobility device which reports bad MRB conditions for long time, the eNB can decide to indicated higher level action to the UE. It should be noted that "higher level action"
means that the poor MRB reception cannot be recovered by radio layer 1 or layer 2 procedures, and therefore, e.g. actions from the application in the UE are needed. In step (6), once eNB determines that actions are required above the radio layers, e.g. to request for unicast delivery from the communication peer, eNB sends explicit indication to the UE. This indication from eNB to UE could be in the form of RRC signaling. If event-based measurement reports are configured for MB MS/ MRB reference signal reporting, events should be configured in such a manner that UE reports poor radio conditions of the MBMS/MRB reference signal appropriately. It should be noted that the eNB takes decision for high-level action, if the eNB cannot guarantee MBMS service continuity on the radio layers. This can happen if the eNB is configured with this solution, or the eNB cannot apply other solutions described herein as embodiments of the present invention (e.g. mapping of MBMS-data over unicast DRB, increase signal strength for MRB transmission, etc.).
Alternatively, after the eNB determines that higher-level actions are appropriate, the eNB can inform the MME, so that the MME can inform the UE, e.g. via NAS signaling. The indication from the MME to UE includes MBMS service ID and appropriate action type, e.g. no longer MRB radio transmission possible, or higher- layer actions needed for service continuity.
Here, it should be noted that the UE needs to implement internal functionality, similar to the functionality described in connection with step (7) of Fig. 6, where the UE is capable to derive/understand the action as indicated by the eNB, and further is able to convey the indication to the impacted/concerned application or internal module/layer. In step (7.1 ), once UE receives the indication from the eNB (or MME) about higher-layer actions needed, the UE first determines internally which application is impacted. This can happen e.g. in the NAS layer. With other words, the received indication from eNB in the RRC layer is forwarded to the NAS layer. Then the UE (NAS layer) forwards this indication to the application layer which receives the
particular MBMS service (according to the MBMS service ID, TMGI). The UE's application then generates an application layer message to request unicast service delivery by sending a relevant indication to the application server. This application layer message is sent over an existing (or new) EPS bearer to the application server.
In step (7.2), once the App Server receives this request to send data in unicast, it starts sending data over unicast bearer to the UE. This may result in the establishment of new EPS bearer in the 3GPP network.
In step (8), UE starts receiving data via unicast bearer over the serving eNB. If the UE would move out of the coverage footprint of the MBMS reference signal, the UE would keep the service/App data receptions, as the unicast transmission is more flexible (in terms of resource utilization) than the multicast transmission.
After step (8), the UE may inform the eNB and/or MME that the UE no longer receive the MBMS service. With other words the UE deregisters with the eNB and/or with the MME regarding the MBMS service reception. The UE may also deregister for the given MBMS service with the BM-SC.
The embodiments of the invention described above are based on the concept where the RAN (eNB) determines about switch from multicast to unicast delivery. Hereinafter, an embodiment is described which is based on an alternative concept where the decision for the service continuity, i.e. for the switch from multicast to unicast delivery, is taken in the UE. The solutions how the UE can determine the bad radio conditions for MBMS reception can be separated in two main categories: 1) solutions at the 3GPP radio layers (e.g. Physical or MAC layer) or 2) solutions at a higher layer above the 3GPP layers (Application layer or TCP layer). The UE can determine the poor radio conditions of the MBMS reception based on the packet losses at the higher layer above the 3GPP layers (Application layer or TCP layer). In such a case the layers above the 3GPP layers determine the need to initiate the switch from multicast to unicast delivery. The possible mechanisms to determine the need for App layer actions for service continuity are e.g. 1 ) the
detection of missing packet, or 2) the triggering of retransmission mechanism in the layers above the 3GPP layers. Actually, the application layer may have a retransmission mechanism for requesting lost packets. If this retransmission mechanism is triggered for a configurable number of times, then the UE can determine that the radio conditions for MBMS reception are poor and the UE can decide to switch to unicast delivery.
Further, the data (streaming) codec used between the BM-SC and UE can also determine that retransmissions are needed. A similar approach is described in 3GPP TS 26.346 in section F.2 for the switching from MBMS to PSS (Packet- switched Streaming Service), however, this approach detects the need for switch after packet losses have already occurred. Hereinafter, this is denoted as "MBMS layer" (or protocol stack generally responsible for performing the MBMS-relevant actions). For example, if the "MBMS layer" would request transmission of the MBMS data from the BM-SC, then the MBMS layer instead of requesting the retransmission can indicate the App layer to initiate request for unicast delivery. Based on this determination for retransmission in the MBMS layer, the UE can determine about the poor radio conditions, and consequently, the UE can request the application layer to take actions to switch from multicast to unicast delivery.
Another embodiment for determining the switching from multicast to unicast delivery at higher layer above the 3GPP layers is to use the sequence number of the IP packets at the transport layer, e.g. TCP or UDP/RTP segments. If the transport layer (or other layer having sequence number of the received packets) determines that a segment/packet is missing, then the transport layer can indicate to the application layer (to which the packets are destined) that there are missing packets and actions from the application layer are needed. In such case, the application layer would request unicast delivery from the application server. The detection for switch to unicast delivery at the higher layer above the 3GPP layers may have the following drawback. An LTE protocol stack and possible interaction with GCSE is as shown in Fig. 10. As we can be inferred from this figure, there is inherent delay between a packet arriving at the PHY (physical layer) to being decrypted, decoded, etc. and reaching the application layer. Hence,
having an application layer trigger for service continuity would essentially mean that there would be significant amount of delay between packet being sent by the GC-AS and the same reaching the group communication application in the UE. Further, there would still be higher delay involved for the completion of bearer modification to unicast if initiated entirely by the GC application in the UE. Whereas, such delays would be absent if the triggering is initiated by the physical layer of the UE by monitoring the link conditions.
Therefore, to overcome the above drawback of delay, the detection of the possible loss of data via multicast transmission, and also possible service disruption, in the 3GPP radio layers (e.g. Physical or MAC layer) has the advantage of avoiding packet losses and less delay. When the UE detects poor radio condition at the 3GPP radio layer(s), an indication is sent internally in the UE to the application which receives the MBMS data. The application can undertake the needed actions to request from the transmitting server a unicast delivery of the group session data. In order for the UE to determine the poor radio conditions at the 3GPP radio layers, the UE needs to be configured with the threshold(s) for the MBMS radio signal strength. The configuration of the thresholds in the UE can be performed e.g. in one of the following manners (the list is not exhaustive):
1. Via application layer signaling from the application server (e.g. GCSE-AS). For example, during the setup of MBMS bearer service, the network can determine based on various parameters, e.g. used modulation and coding scheme, and/or type of service data service, etc, which are the optimal MBMS signal thresholds for switch from multicast to unicast reception. Then this information is conveyed to the BM-SC and the BM-SC can forward the information to the AS (GCSE-AS) over the GC2 interface. Further, the AS can inform the UE via the application layer signaling about the proper radio parameters for the switch from multicast to unicast delivery. After receiving this information, the UE internally forwards this information to the 3GPP layers (RRC, MAC and/or Phy layer).
2. The mobile network operator determines the optimal radio conditions/thresholds for the switch from multicast to unicast delivery and informs the UE via signaling specified in Open Mobile Alliance (OMA) Device Management (DM) Working
group, also known as OMA-DM signaling. This is a kind of semi-static configuration in the UE. The received configuration from the OMA-DM signaling should be stored and forwarded to the Phy layer. 3. A RAN node (e.g. eNB) can determine the optimal conditions/thresholds for the switch from multicast to unicast delivery and informs the UE via RRC or System information signaling. Further details about this embodiment will be described below in connection with Fig. 12. 4. The UE can internally determine the radio signal thresholds for switch from multicast to unicast delivery without any configuration from external entities. Optionally the thresholds can be pre-configured by the UE vendor. The mechanism of UE determined thresholds is described in further details in Fig. 1 1. As shown in this figure, it is assumed that UE internally determines thresholds for various modulation and coding schemes. When the MBMS reference signal or any other measurement which could indicate the signal quality (RSRP, RSSI-RSRP, RSRQ, SINR, BLER measurement of PMCH, etc.) goes below the determined threshold, UE informs the application to initiate unicast service delivery or inform the network using mechanisms described earlier in order to continue receiving group communication data in an uninterrupted manner. For physical layer measurements, work done as part of further MBMS operations support (see for reference RP-131369, "New Work Item Proposal: Further MBMS Operations Support for E-UTRAN") could be reused. The disadvantage of UE internally determined thresholds is that the UE may not have knowledge about the environment (e.g. urban, rural) and whether the neighbor cells are part of the same MBSFN area. Therefore, in connection with Fig. 12 the configuration of the thresholds via the RAN node (eNB) will be described. The eNB can determine the signal thresholds in a similar way as described in the embodiment of Fig. 1 1 , but additionally considering some of the following conditions: the MBMS bearer coverage (e.g. based on the drive test from other UEs), MCSs, radio environment (e.g. urban, rural), type of media, the configuration of the MBMS bearer in the neighbor cells and or whether the neighbor cells are part of the same MBSFN area, etc.
With reference to Fig. 12, the following embodiment describes a mechanism for MBMS reference signal measurement configuration and thresholds in the UE by the eNB. This mechanism is basically derived from the embodiment of the invention described in connection with Fig. 6 enabling service continuity based on eNB involvement. The main concept of this embodiment is that the UE determines and initiates actions (e.g. on the layers above the 3GPP layers, like application layer) to maintain the service continuity based on radio configurations in the UE performed from a RAN node, e.g. eNB. The UE may initiate the actions for service continuity when certain thresholds of the MBMS reference signal measurement are exceeded (e.g. thresholds related to packet, bit and/or block error rates) or under-run (e.g. thresholds related to signal strength). Step (0) shown in Fig. 12 to (3.1 ) is identical or similar to steps (0) to (3.1 ) described in connection with Fig. 6. The detailed explanation of Fig. 12 is as follows:
Step (0) is similar to the steps (0)-(3.1 ) from Fig. 6, whereby a UE subscribed to group communication services, either in RRCJdle or RRC_Connected mode enters the coverage area of a cell or eNB transmitting group communication services using eMBMS.
In step (1 ), eNB sends MBMS reference signal threshold configurations to the UE, either (a) using system information blocks which could be read by the UEs in idle and connected state or (b) using RRC signaling by the eNB. The thresholds could depend on the radio configuration used in the cell for eMBMS transmissions, such as modulation and coding scheme, the channel conditions in the cell, etc. In step (1 ), the UE also starts receiving group communications data using multicast transmissions from the application server. It should be noted that in step (1 ) in Fig. 12, the order of the reception of multicast service on the one hand and the eNB configuration of MRB measurements on the other hand is arbitrary.
As described in connection with Fig. 6, the eNB is aware about the UE's activated MBMS services (GC services sent over MBMS bearer) and if the UE is in connected state, the eNB can use dedicated RRC signaling to the UE in order to configure the UE with MBMS reference signal thresholds. For this purpose,
existing RRC signaling messages or newly defined RRC signaling messages can be used. The use of the configured MBMS signal thresholds is described in step (2). Now the scenario is considered where the UE reaches either the cell boundary (with a cell that does not have eMBMS transmissions) or regions where the eMBMS reception is poor. As shown in step (2), when the MBMS reference signal quality (or any signal from which MBMS reception quality can be estimated) goes below a threshold configured in step (1 ), the UE determines in sub-step (a) that the UE has reached a region where the probability of losing multicast signal reception is high, due to bad MRB radio conditions or any other factors due to which multicast reception could be lost. In sub-step (b) the UE initiates actions for maintaining the service continuity. With other words, the exceeding or under- running of the MBMS signal thresholds configured in step (2) is used as a trigger in the UE to perform actions for service continuity for the reception of the MBMS data.
Again, it should be noted that the UE implements internal functionality, similar to the functionality described in connection with step (7) of Fig. 6, where the UE is capable to derive/understand the action as indicated by the eNB, and further is able to convey the indication to the impacted/concerned application or internal module/layer.
One example of the actions performed by the UE upon detection of step (2), is shown in step (3.1 ) where the UE sends application level signaling using group communications application in the device to trigger unicast service delivery, receiving the response in (3.2). The actions performed by the UE are not limited to the one shown in steps (3.1 ) and (3.2). For example, the UE may perform signaling to a 3GPP functional entity, e.g. eNB, MME, MBMS-Gateway or BMSC, to inform about losing reception of GC service over MBMS distribution. Then the 3PGG functional entity can initiate actions to keep the reception of GC service data at the UE by performing unicast transmission.
In step (4), the UE starts receiving data via unicast bearer, and stops listening to MBMS radio bearer, once reliable unicast bearer is established.
The possible options for configuring the triggering criteria for the switch from multicast to unicast service delivery in step (3.2) could be similar to the cell reselection criteria defined for IDLE mode mobility in 3GPP TS 36.304, "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode," 3GPP Technical Specification, v.1 1.5.0, Sept. 2013. One possible example would be MBMS reference signal levels in terms of reference signal received power (RSRP), or quality (RSRQ), or SINR goes below a configured threshold. It could also depend on other cell specific reference signal quality values as well, in order to avoid UE entering radio link failure conditions. The scheme could be implemented by conveying this information through extensions of currently defined system information blocks (for e.g. SIB-3 for cell reselection parameters or SIB-13 by extending already available MBMS related parameters). This information could be read by either idle or connected mode UEs, and using explicit signaling by eNB after handover.
Another embodiment of configuring UE with thresholds for triggering the execution of step (3.2) for unicast service delivery involves using extensions of RRC signaling defined in [3]. eNB using extensions of measurement reporting events currently defined for mobility, could signal to the UE regarding when unicast delivery should be triggered. This could be done by configuring absolute thresholds of signal power or quality (RSRP/RSRQ/SINR), and if the signal level goes below this threshold, the UE can trigger application level bearer modification, or by using relative thresholds when the difference between the neighbor cells' signal levels and the serving cell's signal levels are within a configured limit.
Since different modulation and coding schemes can be used for each transport block in LTE, and multicast transmissions have to use the same MCS for a group of users, eNB could apply different MBMS signal thresholds for the switch from multicast to unicast delivery for the different MBMS bearers, e.g. for the different MBSFN configurations or for the transmission of different media types for the same MBMS group. For this purpose the eNB can inform the UE using RRC
signaling about the MBMS signal threshold(s) for triggering of unicast service delivery, e.g. this informing is performed for each TMGI (corresponding to received MBMS service). Thus it is possible that different MBMS signal thresholds sets are calculated by the eNB and informed to the UEs for different MBMS bearer services (e.g. for different TMGIs). Having this, a single UE receiving multiple MBMS bearers can have different MBMS signal thresholds configurations. Optionally, the eNB could configure a single threshold for all the UEs in the cell using extensions to SIBs or RRC signaling. Extensions of currently defined SIBs could also be used to signal different thresholds for different MBSFN areas, PMCHs, eMBMS sessions or any other radio parameters used for the transmissions. The modification for RRC signaling could be done in for e.g. ReportConfigEUTRA defined in [2] for UE measurement and reporting triggering. The system information block related signaling could be done by modifying PMCH-lnfoList, MBSFN-SubframeConfig, MBSFN-ArealnfoList or any other eMBMS related signaling configurations considered in [2]. It could also be done along with informing the UE regarding MCS configurations used and could be signaled when there are any changes in radio parameters used for MBMS.
In another alternative to Fig. 12, a variant with minimum impact on the RAN node (eNB) is proposed in Fig. 1 1. The reason is that in same deployments changes/updates to the existing RAN infrastructure should be avoided and the solutions could be implemented in the UE without signaling impacts with the radio access network. The thresholds for unicast service triggering could be UE specific, based on internal calculations of thresholds, based on previous history of service disruptions, or based on semi-static configurations by external entities such as OMA-DM or using third part application configurations (for e.g. GC-AS) using application layer (data layer) signaling.
Hereinafter, further embodiments will be described that also address the problem of providing service continuity. The main aspect of these embodiments is based on the functionality in the network to decide how to provide service continuity based on the device (UE) and network capabilities. It is described that the UE may have special capabilities to support (e)MBMS service continuity. During the attach procedure the UE indicates its capabilities related to (e)MBMS service continuity.
Based on these capabilities and the network capabilities, the network takes decision which solution to apply. In the embodiment described hereinafter the network decides after the attach procedure or after the establishment of the GC session to apply a solution where the eNB indicates to the UE to request unicast delivery.
A main idea of this embodiment, which is illustrated in Fig. 13, is that prior to the handover the UE initiates unicast delivery from the content provider (GC-AS). It is assumed that the UE is in RRC and NAS CONNECTED state. The initiation of the unicast delivery is an application layer signaling. It is assumed that there is an internal interface between the GC application in the UE and the 3GPP (transport) layer. This internal interface should enable the exchange of information between UE's NAS/AS layer and the application layer. As result of this information exchange between GC application layer and 3GPP NAS/AS layer, new EPS bearer may be established, or an existing EPS bearer can be modified, or the internal routing of GC data/media in the UE can be modified in order to receive the GC data/media over unicast delivery.
Specifically, Fig. 13 illustrates a procedure for a solution where the UE initiates request for unicast delivery of GC data/media upon eNB indication to UE about loss of (e)MBMS service in the target cell. The handover decision is taken from the source eNB1 according to the legacy mobility concept in 3GPP. The initial assumption is that, the UE receives the GC data/media via a multicast delivery from the content provider (GC-AS) via an (e)MBMS bearer service. The following steps from Fig. 13 describe the details of this solution:
During step (1 ) the UE exchanges capabilities about support of (e)MBMS bearer service continuity. This capability exchange may happen either (1 ) during the Attach procedure, e.g. the UE includes the capability as part of the Attach request message, or (2) when the UE starts receiving (e)MBMS bearer services as explicit NAS signaling exchange to MME or RRC signaling to serving eNB.
In step (2) in Fig. 13 the eNB1 maintains information about the (e)MBMS bearer service(s) which the UE currently receives. The eNB can obtain this information
either from the UE or from the MME. As a result of this step (2), the eNB1 stores an enhanced UE context including information of the (e)MBMS bearer service(s) currently received by the UE. For example the eNB1 stores the TMGI(s) of the (e)MBMS services received by the UE. It should be noted that in this embodiment the eNB1 does not inform the UE about the (e)MBMS bearer service(s) configuration of the neighbor cells.
In step (3) the UE performs the normal radio measurements of the neighbor cells as part of the mobility procedure in CONNECTED state. When the UE detects threshold for handover event, the UE sends the measurement reports to the source eNB1. This step does not require any changes to the UE.
In step (4), based on the measurement report, the source eNB detects whether the possible target cell offers the MBMS service which the UE actively listens. In this regard it is important to note that in step (2) eNB1 has stored information whether and which MBMS services (TMGIs) are subscribed and actively received by the UE. For the purpose of determining (e)MBMS bearer support, the source eNB1 either maintains information about the neighbor cells and which neighbor cells offer which MBSFN service, or first requests the target eNB2 (according to the measurement report from the UE) or the MME/MCE about the offered MBSFN services. After the reply from the target eNB or MME/MCE, the source eNB determines if the possible target cell offers the MBSFN service.
In step (5), if the source eNB determines that the target cell does not offer the (e)MBMS service(s), the source eNB informs the UE (e.g. via RRC signaling message) about "NO activated eMBMS service in target cell", i.e. the target eNB2 is not part of the MBSFN area. The UE forwards this information from eNB1 internally from the RRC layer to the corresponding application (e.g. GC application) using the (e)MBMS service. This UE internal forwarding of the eNBI 's indication may be performed in several ways. For instance, a special API between the RRC layer and application layer may be specified. Alternatively, the RRC layer may forward the indication to NAS layer; then NAS layer forwards the indication via a special API to the application layer.
In step (6.1 ), the UE's application initiates application level signaling to request the GC-AS to start unicast delivery of GC data/media. In step (6.2) the GC-AS either (a) replies with application level signaling to the UE to confirm the reception and processing of the UE's request; or (b) the GC-AS starts sending data/media via unicast and the UE detects via reception of the data that the request was processed in the GC-AS.
Step (7) can be observed as reply to the indication from step (5). In step (7), the UE indicates to the source eNB1 that the indication from step (5) was successfully received and processed, so that eNB1 can proceed with the handover procedure. The eNB1 delays the sending of "Handover" command to the UE in order to give the opportunity to UE and GC-AS to establish (or at least partially establish) the unicast delivery path with corresponding EPS bearer establishment. There could be several options for determining the delay time. For instance, the eNB1 can wait until the UE indicates that it is "ready" for handover as explained above, or/and the eNB1 can wait for a given configurable time and after expiring of this time, the eNB1 can proceed with the handover procedure, i.e. sending Handover command message to the UE. Applying both options together would avoid waiting too long until the UE acknowledges the processing of the eNBI 's indication from step (5).
In step (8), eNB1 initiates the handover procedure according to 3GPP TS23.401.
After completing the handover from eNB1 to eNB2, the UE receives the GC data/media via unicast delivery from the GC-AS via the eNB2.
In summary, the main changes required to UE according to the embodiment described in connection with Fig. 13 are:
• Indicate UE capabilities to the MME or eNB for supporting the (e)MBMS bearer service continuity (related to step (1 ) in Fig. 13);
• Indicate to MME or eNB currently received (e)MBMS bearer service(s). For example the UE can use the TMGI to indicate this to the MME or eNB (related to step (2) Fig. 13);
• Ability to support the procedure of "NO activated eMBMS service in target cell". This procedure includes the ability to receive an indication from the eNB that particular (e)MBMS bearer service(s), which the UE currently receives, are not supported in the target cell. The UE supports means to forward internally the indication to the corresponding application, i.e. the AS layer informs the NAS layer and it informs the application. In change, the Application informs the NAS layer and AS layer that the indication has been processed. Further as part of this procedure the UE is able to send a kind of "reply" indication to the eNB1 to indicate that the UE is ready for the handover procedure.
The required changes to the eNB are:
• eNB is able to exchange capabilities information with UE and/or with MME about the UE's capability of (e)MBMS bearer service continuity (related to step (1 ) in Fig. 13).
• eNB is able to store enhanced UE context (for UE is CONNECTED mode) including the UE's currently received (e)MBMS bearer service(s). This UE context can be dynamically updated by the UE or by the MME (related to step (2) in Fig. 13).
• eNB is able to exchange information with the neighbor eNBs in order to determine which (e)MBMS bearer service(s) the neighbor eNBs support (related to step (4) in Fig. 13).
• eNB is able to indicate to the UE that in the candidate target cell the currently received (e)MBMS bearer service(s) are not supported, and correspondingly, the eNB1 is able to receive a "reply" indication from the UE. Further, the eNB may implement a timer for delayed triggering the handover procedure after indication to the UE about "NO activated eMBMS service in target cell" (related to steps (5) and (7) in Fig. 13).
According to another embodiment, which relates to an alternative solution particularly to steps 5 and 7 described above, there is no explicit indication from eNB1 to UE about "NO activated eMBMS service in target cell", but instead the eNB1 sends a modified/extended Handover Command message (which could be
an RRC message) to the UE which contains the same or similar indication, i.e. "NO activated eMBMS service in target cell". After receiving such an extended Handover Command message, the UE first initiates application level signaling to the GC-AS in order to request unicast delivery of the GC session data. This application level signaling may be the same as described above in connection with steps (6.1 ) and (6.2) of Fig. 13. Afterwards the UE executes the handover procedure to eNB2. With other words, the main difference to the embodiment described in Fig. 13 is that the indication "NO activated eMBMS service in target cell" is provided to the UE in the Handover Command message and the UE performs the application level signaling in steps (6.1 ) and (6.2) before starting the synchronization with the target cell.
Another possible alternative is that the UE can be pre-configured with neighbor cells info for (e)MBMS services, i.e. whether the neighbor cells support the (e)MBMS service currently received for GC data. Such a configuration in the UE can be performed either by the eNB to which the UE is currently connected (called source eNB) or by the MME to which the UE currently has a NAS connection (usually the MME knows about the configured (e)MBMS services in the E-UTRAN from the MCE). If such a configuration is performed in the UE, then there is no need to use the explicit indication as shown in Fig. 13 or to use an extended Handover Command. The eNB1 would send non-modified Handover Command message (i.e. according to 3GPP TS23.401 , "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP Technical Specification, v.12.1.0, June 2013) and the UE based on its configuration would decide to first initiate application level signaling to the GC-AS to request unicast deliverofy, and afterwards the UE would start to execute the handover procedure.
The main benefits of the above embodiments are 1 ) service continuity, i.e. no data flow interruption is perceived by the application layer and 2) the solution works even in case of (e)MBMS services provided in only one cell or a small number of cells where all cells can be boundary cells.
While the embodiments solve the targeted objective of providing service continuity, there are also some shortcomings: First, that may be an increased delay of the handover execution procedure, as the application level signaling, i.e. steps (6.1 ) and (6.2) of Fig. 13, are performed after the handover preparation procedure and before the handover synchronization procedure (i.e. before the UE start the synchronization with the target eNB2). Second, there is no network guarantee for the service continuity, i.e. the network doesn't know if the UE has successfully performed the application level signaling. One other aspect that considered in the context of embodiments of the present invention is the case where the UE moves into (e)MBMS bearer service (MBSFN area) coverage whereas unicast delivery of the GC session data was used before the movement. In such case it is beneficial if the UE switches from unicast to multicast delivery in order to better utilize the radio resources. The problem is how does the UE perceive that the GC service data that is currently received via unicast delivery is also distributed over (e)MBMS bearer service.
One possible solution would be to configure the UE via application level signaling (i.e. from GC-AS) with cell IDs in which the GC service is distributed via (e)MBMS bearer service. Then an UE internal API between the Access Stratum and the Application layer is needed in order to forward information about the current cell ID from the 3GPP transport layer to the application layer. When the application layer determines that the UE entered a cell which is a part of the MBSFN area, the UE can initiate application-level signaling to the GC-AS to request multicast delivery and stop the unicast delivery.
Some disadvantages of this possible solution based on the application-level signaling from GC-AS are: «The GC-AS should know the cell IDs in which the (e)MBMS bearer service is configured. This could be a problem as the 3GPP mobile operator may not provide such information outside the 3GPP network and if the GC-AS is a 3rd party server, the GC-AS would not know the MBSFN configuration area.
• There is a need of frequent update which would result in increased signaling load. Each time an (e)MBMS bearer service is activated, deactivated or modified, the 3GPP operator should update the GC-AS application. Consecutively the GC- AS should update all UEs currently receiving the GC service data via unicast delivery. This application-level update is performed and the UEs are required to store this information even if the UEs will never enter the MBSFN area.
A solution to overcome the above disadvantages is proposed herewith which is based on indication provided to a UE receiving GC service via unicast delivery by the 3GPP network (using 3GPP signaling means like NAS signaling or RRC signaling) when the UE moves into the MBSFN area coverage.
In one alternative of the solution, the UE during GC service setup procedure (e.g. during unicast bearer setup for GC session) indicates to the MME the service/session group identifier (GC-ID) identifying the GC service session. One example for GC-ID can be the APN used for the GC service, another example can be a special call ID. The MME should maintain UE's context storing the currently activate GC-ID. Other UEs using the same GC service should use the same GC- ID. When and if an (e)MBMS bearer service is setup in the 3GPP network, the MME should maintain a mapping of the (e)MBMS bearer service's TMGI with the GC-ID. In this way the MME determines that the unicast EPS bearer established for GC service over eNB2 is used for the same service as the (e)MBMS bearer service provided by eNB2 as well. Since the MME knows the all cells configured for the (e)MBMS bearer service, when a UE (in CONNECTED state) moves into a cell transmitting the (e)MBMS bearer service having GC-ID same as the UE's currently used GC-ID, the MME determines (based on the GC-ID) that the UE receives the same GC service data over unicast bearer which is also provided over the (e)MBMS bearer service. The MME can indicate to the UE that the GC service data is available over (e)MBMS service in the current cell and the MME can indicate (e)MBMS's TMGI to the UE. The UE initiates 3GPP procedures, e.g. signaling to BMSC to receive the security parameters and scanning the SIB for (e)MBMS resources as described in 3GPP TS23.246, to start receiving the GC data/media via (e)MBMS bearer service. Additionally the UE would perform application-level signaling to GC-AS to indicate the reception of the GC service
over (e)MBMS bearer service and to indicate to GC-AS that the unicast delivery can be terminated.
Fig. 14 shows the solution explained above about maintaining the service continuity when the UE enters MBSFN area and switch from unicast to multicast delivery is performed. The thick arrows in Fig. 14 show data flow and the thin arrows show the signaling flow between the functional entities. The steps from Fig. 14 are described as follows: In step (1 ) the UE establishes GC service over eNB1. As eNB1 is not part of the (e)MBMS bearer service or no (e)MBMS bearer service has been established yet, the GC service data delivery from GC-AS to UE is via unicast bearer. The MME may use the APN of the Group communication session as GC-ID. During the GC service establishment, the UE optionally may indicate a GC-ID for the specific Group communication session.
It is assumed that eNB2 is part of (e)MBMS bearer service that can be established before or after the UE established the GC service via unicast delivery. Anyway, from the UE's point of view, the (e)MBMS bearer service can be seen as pre- established prior to the handover procedure.
In step (2), the MME maintains the GC-ID of the established (e)MBMS bearer service (e.g. to eNB2). The MME is able to map the relation of the GC-ID of the unicast bearers with the GC-ID of the multicast bearers. In case of MME pool area where multiple MMEs are available, information exchange between the MMEs, e.g. via S10 reference point, is exchanged in order to update each other about the available (e)MBMS bearer service (and the corresponding GC-IDs) in the MME pool area. In step (3) the UE performs a handover from eNB1 to eNB2. This is a handover procedure as described in [2]. Usually after the handover procedure the UE receives the GC service data over unicast delivery via eNB2.
However, if the signaling exchange described in step (4) is performed during the handover procedure step (3) itself, it is possible that the UE starts pretty soon the reception of the GC service data over (e)MBMS bearer in eNB2's cell, and thus, the UE can immediately start to perform steps (6.1 ) and (6.2). With other words, steps (3) and (4) can be integrated during the handover procedure and the GC service reception over unicast delivery can be obsolete, as the UE can quickly join the (e)MBMS bearer service.
In step (4), the MME determines that the unicast EPS bearer established for GC service over eNB2 is used for the same service as the (e)MBMS bearer service provided by eNB2 as well. Say it differently, the MME determines that the UE participates the same GC session as the one provided over the (e)MBMS bearer service. For example the MME determines that the GC-ID of the unicast bearer and the (e)MBMS bearer service are the same. After determining the relation of the GC services over unicast EPS bearer and (e)MBMS bearer service over eNB2, the MME indicates to the UE that the GC service can be obtained via (e)MBMS bearer service, and more specifically the MME indicates the TMGI of the (e)MBMS bearer service. It is assumed that the GC service received by the UE and the GC service distributed over (e)MBMS bearer service are the same, i.e. if the GC service received by the UE includes multiple public safety groups then the GC service over the (e)MBMS bearer service should include the same public safety groups. The MME shall have means to determine the exact mapping of GC service distributed over unicast EPS bearer and (e)MBMS bearer. The MME can use NAS signaling message (e.g. NAS Information message) to indicate to the UE the available (e)MBMS bearer service and the corresponding TMGI.
It should be noted that step (4) can be a separate signaling procedure between MME and UE as described in Fig. 14, but it can also be performed during the handover procedure in step (3). With other words the signaling from MME to UE may be a part of the handover procedure.
ln step (5) after the UE has been indicated about the available (e)MBMS bearer service in the current cell of eNB2, the UE starts scanning the broadcasted cell system information (SIB) to discover the radio resources at which the (e)MBMS bearer service is broadcasted. Additionally, the UE may initiate procedures to join the (e)MBMS bearer service as described in 3GPP TS23.246. After steps (5) and (5.1 ) the UE is able to receive the GC service via (e)MBMS bearer service broadcasted over MRB (P2M radio bearer).
In steps (6.1 ) the UE uses application-level signaling to inform the GC-AS about the ability to receive GC service data over (e)MBMS bearer service. In step (6.2) the GC-AS can acknowledge the reception of the message in step (6.1 ) and to terminate the transmission of GC service data over unicast delivery.
Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Claims
1. Method for providing multicast/broadcast service continuity for mobile terminals in a radio access network, wherein said mobile terminals register with a base station of said radio access network regarding said multicast/broadcast service and wherein said base station transmits multicast/broadcast service related data as group communications to said registered mobile terminals, c h a r a c t e r i z e d i n that a mobile terminal performs multicast/broadcast service related radio measurements and that a decision on actions to be performed by said base station and/or by said mobile terminal for preserving reliable transmission/reception of said multicast/broadcast service related data to/by said mobile terminal is taken based on the results of said multicast/broadcast service related radio measurements.
2. Method according to claim 1 , wherein said multicast/broadcast service is a Multimedia Broadcast Multicast Service (MBMS).
3. Method according to claim 1 or 2, wherein said mobile terminal transmits said multicast/broadcast service related radio measurement results to said base station, preferably periodically in predefined time intervals or triggered by a particular event from a group of predefined events.
4. Method according to claim 1 or 3, wherein said mobile terminal's existing radio measurements used for mobility procedures are extended to additionally include information about the multicast/broadcast service radio signal quality.
5. Method according to any of claim 1 to 4, wherein said multicast/broadcast service related radio measurements include measurements on the multicast/broadcast service radio bearer signal strength, and/or on decoding errors and/or block error rates of received multicast/broadcast service radio bearer data.
6. Method according to any of claim 1 to 5, wherein the MBSFN carrier symbol is employed as reference signal to generate the multicast/broadcast service
related information in mobile terminal's radio measurement reports transmitted to said base station.
7. Method according to any of claim 1 to 6, wherein said mobile terminal transmits the multicast/broadcast service related radio measurement reports to said base station by means of RRC signaling.
8. Method according to any of claim 1 to 7, wherein said base station determines, preferably based on information exchange with MME and/or said mobile terminal, whether to configure said mobile terminal to send multicast/broadcast service related radio measurement reports to said base station.
9. Method according to claim 8, wherein said determination is made for each of said mobile terminal's activated multicast/broadcast service radio bearer individually.
10. Method according to any of claim 1 to 9, wherein said base station configures a mobile terminal, preferably upon said mobile terminal joining the reception of the multicast/broadcast service, with relevant multicast/broadcast service related thresholds, preferably related to radio signal strength, packet error rate and/or block error rate.
1 1. Method according to any of claim 1 to 10, wherein multicast/broadcast service related thresholds are employed by said mobile terminal to trigger actions to avoid packet losses of multicast/broadcast service data.
12. Method according claim 1 1 , wherein said multicast/broadcast service related thresholds are configured by said base station.
13. Method according claim 1 1 or 12, wherein said mobile terminal initiates application layer signaling to request unicast transmission from a sending server upon detection that said configured multicast/broadcast service related thresholds are overrun/underrun.
14. Method according to any of claim 1 to 13, wherein said base station, after said mobile terminal reports poor conditions for multicast/broadcast service reception falling below or exceeding predefined thresholds, determines the actions for preserving the service continuity for multicast/broadcast service data reception.
15. Method according to any of claim 1 to 14, wherein an action determined by said base station includes triggering said mobile terminal to perform application layer signaling for requesting unicast delivery.
16. Method according to any of claim 1 to 15, wherein an action determined by said base station includes mapping of the multicast/broadcast service data over existing unicast radio bearers.
17. Method according to claim 16, wherein said mapping is applied in cases in which said mobile terminal is assumed to recover within a predefined time interval from the poor radio conditions for multicast/broadcast service transmission.
18. Method according to any of claim 1 to 17, wherein said base station informs said mobile terminal about the transmission of the multicast/broadcast service data over a particular default radio bearer.
19. Method according to any of claim 1 to 18, wherein said base station determines and applies different scheduling priorities for the transmission of multicast/broadcast service data and unicast data over the same default radio bearer.
20. Method according to claim 19, wherein said base station dynamically modifies said different scheduling priorities depending on the load situation in the respective radio cell.
21. Method according to any of claim 1 to 20, wherein an action determined by said base station includes handing over said mobile terminal to a base station of a neighbor cell.
22. Base station for providing multicast/broadcast service continuity for mobile terminals in a radio access network, in particular for executing a method according to any of claims 1 to 21 , wherein said base station is configured to transmit multicast/broadcast service related data as group communications to mobile terminals registered with said base station regarding said multicast/broadcast service,
c h a r a c t e r i z e d i n that said base station is further configured to receive results of multicast/broadcast service related radio measurements performed by a mobile terminal and, based on the received measurement results, to take a decision on actions to be performed for preserving reliable transmission of said multicast/broadcast service related data to said mobile terminal.
23. Base station according to claim 21 , being configured to apply a scheduling mechanism that subdivides packets of the same radio bearer in order to enable different scheduling treatments of multicast/broadcast service data on the one hand and unicast data on the other hand.
24. Mobile terminal with multicast/broadcast service continuity support according to any of claims 1 to the 21 , said mobile terminal being configured to register with a base station of a radio access network regarding said multicast/broadcast service and to receive from said base station multicast/broadcast service related data as group communications,
c h a r a c t e r i z e d i n that said mobile terminal is further configured to perform multicast/broadcast service related radio measurements and to take a decision on actions to be performed for preserving reliable reception of said multicast/broadcast service related data based on the results of said multicast/broadcast service related radio measurements.
25. Mobile terminal according to claim 24, wherein said multicast/broadcast service related radio measurements are performed as an extension of said mobile terminal's existing radio measurements used for mobility procedures.
26. Mobile ternninal according to claim 24 or 25, wherein said mobile terminal is configured to initiate application layer signaling for requesting unicast transmission from a sending server upon detection that multicast/broadcast service related thresholds configured in said mobile terminal by said base station, preferably related to radio signal strength, packet error rate and/or block error rate, are overrun/underrun.
27. Mobile terminal according to any of claims 24 to 26, comprising internal functionality for conveying any indication received from said base station to the impacted or concerned application or internal module/layer.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14747308.6A EP3017616B1 (en) | 2013-07-01 | 2014-07-01 | Method for providing multicast/broadcast service continuity for mobile terminals |
US14/902,043 US10219245B2 (en) | 2013-07-01 | 2014-07-01 | Method for providing multicast/broadcast service continuity for mobile terminals |
US16/245,269 US10531430B2 (en) | 2013-07-01 | 2019-01-11 | Method for providing multicast/broadcast service continuity for mobile terminals |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP13174549 | 2013-07-01 | ||
EP13174549.9 | 2013-07-01 | ||
EP13181556.5 | 2013-08-23 | ||
EP13181556 | 2013-08-23 | ||
EP13183988 | 2013-09-11 | ||
EP13183988.8 | 2013-09-11 | ||
EP13190350 | 2013-10-25 | ||
EP13190350.2 | 2013-10-25 |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/902,043 A-371-Of-International US10219245B2 (en) | 2013-07-01 | 2014-07-01 | Method for providing multicast/broadcast service continuity for mobile terminals |
US16/245,269 Continuation US10531430B2 (en) | 2013-07-01 | 2019-01-11 | Method for providing multicast/broadcast service continuity for mobile terminals |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015000912A1 true WO2015000912A1 (en) | 2015-01-08 |
Family
ID=51265652
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2014/063983 WO2015000912A1 (en) | 2013-07-01 | 2014-07-01 | Method for providing multicast/broadcast service continuity for mobile terminals |
Country Status (3)
Country | Link |
---|---|
US (2) | US10219245B2 (en) |
EP (1) | EP3017616B1 (en) |
WO (1) | WO2015000912A1 (en) |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015089312A1 (en) * | 2013-12-13 | 2015-06-18 | Qualcomm Incorporated | Practical implementation aspects of unicast fetch for http streaming over embms |
WO2016195944A1 (en) * | 2015-05-29 | 2016-12-08 | Qualcomm Incorporated | Inter-rat (radio access technology) and intra-rat measurement reporting |
EP3113543A1 (en) * | 2015-06-26 | 2017-01-04 | Intel IP Corporation | Method for processing radio signals and mobile terminal device |
WO2017027043A1 (en) | 2015-08-13 | 2017-02-16 | Nokia Solutions And Networks Oy | Method and apparatus for reducing a service interruption time within a single-cell point-to-multipoint system |
WO2017167838A1 (en) * | 2016-03-31 | 2017-10-05 | British Telecommunications Public Limited Company | Mobile communications network |
WO2017167648A1 (en) * | 2016-03-31 | 2017-10-05 | British Telecommunications Public Limited Company | Mobile communications network |
CN107535011A (en) * | 2015-08-20 | 2018-01-02 | 华为技术有限公司 | Data processing method and equipment |
GB2551751A (en) * | 2016-06-29 | 2018-01-03 | British Telecomm | Mobile communications network |
WO2018022570A1 (en) * | 2016-07-27 | 2018-02-01 | Sharp Laboratories Of America, Inc. | On-demand system information for wireless telecommunications |
CN108886761A (en) * | 2016-03-31 | 2018-11-23 | 英国电讯有限公司 | Mobile communications network |
CN109547944A (en) * | 2017-09-21 | 2019-03-29 | 华为技术有限公司 | The method and device of data transmission |
CN109756846A (en) * | 2017-11-06 | 2019-05-14 | 成都鼎桥通信技术有限公司 | The benefit packet method and system of group communication |
KR20190055157A (en) * | 2016-11-01 | 2019-05-22 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Service interruption reporting |
EP3515128A1 (en) * | 2015-01-30 | 2019-07-24 | Huawei Technologies Co., Ltd. | Apparatus and method for a wireless device to receive data in an eco state |
GB2548893B (en) * | 2016-03-31 | 2020-01-08 | British Telecomm | Mobile communications network |
US10575042B2 (en) | 2015-11-27 | 2020-02-25 | British Telecommunications Public Limited Company | Media content synchronization |
US10771298B2 (en) | 2016-08-04 | 2020-09-08 | British Telecommunications Public Limited Company | Mobile communications network |
WO2021127669A1 (en) * | 2019-12-16 | 2021-06-24 | Qualcomm Incorporated | Measurements for multicast/broadcast service continuity |
WO2021184349A1 (en) * | 2020-03-20 | 2021-09-23 | Qualcomm Incorporated | Techniques for multicast and unicast convergence in wireless communications |
US11234240B2 (en) | 2018-06-08 | 2022-01-25 | British Telecommunications Public Limited Company | Wireless telecommunications network |
WO2022236211A1 (en) * | 2021-05-05 | 2022-11-10 | Qualcomm Incorporated | Multicast-broadcast services configuration exchange for mobility, single-frequency network and interference coordination |
US11510116B2 (en) | 2016-06-29 | 2022-11-22 | British Telecommunications Public Limited Company | Multicast-broadcast mobile communications network |
US11910277B2 (en) | 2021-05-05 | 2024-02-20 | Qualcomm Incorporated | Multicast-broadcast services configuration exchange for mobility, single-frequency network and interference coordination |
Families Citing this family (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3017616B1 (en) * | 2013-07-01 | 2018-12-05 | NEC Corporation | Method for providing multicast/broadcast service continuity for mobile terminals |
WO2015046941A1 (en) * | 2013-09-26 | 2015-04-02 | Lg Electronics Inc. | Method and apparatus for indicating stopping mbms transmission in wireless communication system |
CN104640077B (en) * | 2013-11-08 | 2019-10-11 | 中兴通讯股份有限公司 | A kind of method and system of cluster communication, user equipment and network side equipment |
CN105009638B (en) * | 2014-01-03 | 2019-10-01 | 华为技术有限公司 | A kind of method for user device switching and base station |
US20160323846A1 (en) * | 2014-01-06 | 2016-11-03 | Lg Electronics Inc. | Method and apparatus for providing group communication service enabler (gcse) service in wireless communication system |
JP2015142332A (en) * | 2014-01-30 | 2015-08-03 | ソニー株式会社 | Device |
US10631181B2 (en) * | 2014-01-31 | 2020-04-21 | Nokia Technologies Oy | BLER measurements for MBMS |
CN104955086A (en) * | 2014-03-24 | 2015-09-30 | 中兴通讯股份有限公司 | MBMS error handling method, communication node and communication system |
CN105324971B (en) * | 2014-05-23 | 2019-03-08 | 华为技术有限公司 | A kind of binding registration and data forwarding method, relevant device and network system |
WO2016010390A1 (en) | 2014-07-18 | 2016-01-21 | 삼성전자 주식회사 | Synchronization method and device for device-to-device communication in wireless communication system |
CN104301931A (en) * | 2014-09-24 | 2015-01-21 | 中兴通讯股份有限公司 | Congestion/overload control method, system, device and base station |
US10756914B2 (en) * | 2014-09-26 | 2020-08-25 | Samsung Electronics Co., Ltd. | Broadcast resource congestion control method and apparatus for use in wireless communication system |
CN107027344B (en) | 2014-10-31 | 2021-09-03 | 三星电子株式会社 | Method and apparatus for transmitting control channel in intra-cell carrier aggregation system |
US9763060B2 (en) * | 2014-11-11 | 2017-09-12 | Alcatel Lucent | Streaming unicast services to multiple user equipment |
US10827484B2 (en) | 2014-12-12 | 2020-11-03 | Qualcomm Incorporated | Traffic advertisement in neighbor aware network (NAN) data path |
US10820314B2 (en) | 2014-12-12 | 2020-10-27 | Qualcomm Incorporated | Traffic advertisement in neighbor aware network (NAN) data path |
US9949236B2 (en) * | 2014-12-12 | 2018-04-17 | Qualcomm Incorporated | Traffic advertisement in neighbor aware network (NAN) data path |
US11330573B2 (en) * | 2015-01-08 | 2022-05-10 | Kt Corporation | Method for transmitting and receiving single-cell multi-transmission data and apparatus therefor |
EP3073779A1 (en) * | 2015-03-23 | 2016-09-28 | Gemalto M2M GmbH | Method for operating a wireless device supporting self organizing networks |
WO2017045124A1 (en) * | 2015-09-15 | 2017-03-23 | 华为技术有限公司 | Method and device for receiving and sending application layer parameter information |
US9913249B2 (en) * | 2015-12-09 | 2018-03-06 | At&T Intellectual Property I, L.P. | Method and system for selective paging of wireless devices using a cellular broadcast service |
US9894458B2 (en) * | 2016-04-25 | 2018-02-13 | Verizon Patent And Licensing Inc. | Optimizing MTC updates using MBMS |
ES2777779T3 (en) * | 2016-05-12 | 2020-08-06 | Ericsson Telefon Ab L M | MBMS carrier quality assessment |
US11317250B2 (en) * | 2016-07-11 | 2022-04-26 | Lg Electronics Inc. | Method for transmitting MBMS interest indication message by terminal and device supporting same |
US11218779B2 (en) * | 2017-01-09 | 2022-01-04 | Nokia Technologies Oy | Method and apparatus for coordinated content delivery in multicast/broadcast networks |
CN110249587B (en) | 2017-02-06 | 2022-01-04 | 高通股份有限公司 | Capability and coverage determination for multimedia broadcast multicast services |
US10986531B2 (en) | 2017-05-05 | 2021-04-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device in a radio network |
CN108990112B (en) * | 2017-05-31 | 2021-01-15 | 华为技术有限公司 | Task processing method and communication device in communication network |
US10645228B2 (en) * | 2017-06-26 | 2020-05-05 | Apple Inc. | Adaptability in EVS codec to improve power efficiency |
US20220046505A1 (en) * | 2018-01-17 | 2022-02-10 | T-Mobile Usa, Inc. | Telecommunications Network Bearer Allocation and Deallocation |
CN111771422B (en) * | 2018-02-26 | 2023-05-09 | 诺基亚技术有限公司 | Multicast traffic area management and mobility for wireless networks |
WO2019223005A1 (en) * | 2018-05-25 | 2019-11-28 | Qualcomm Incorporated | Mixed mode multicast architecture |
WO2020101639A1 (en) | 2018-11-12 | 2020-05-22 | Nokia Technologies Oy | Method and apparatus for efficient delivery of source and forward error correction streams in systems supporting mixed unicast multicast transmission |
CN111510964B (en) * | 2019-01-31 | 2021-09-07 | 华为技术有限公司 | Communication method and device |
CN111586084B (en) * | 2019-02-18 | 2023-04-07 | 瑞典爱立信有限公司 | Method and device for discovering application server and/or service of v2x communication |
US11477687B2 (en) * | 2019-08-29 | 2022-10-18 | Qualcomm Incorproated | Delivery of broadcast services using different broadcast/multicast radio bearer modes |
WO2021054674A1 (en) * | 2019-09-20 | 2021-03-25 | 주식회사 케이티 | Mbs data switching method and device |
US11368818B2 (en) * | 2019-12-10 | 2022-06-21 | Indian Institute Of Technology Bombay | Methods and systems for using multi-connectivity for multicast transmissions in a communication system |
EP4084405A4 (en) * | 2020-01-06 | 2023-03-29 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Service switching method, terminal, and network device |
CN113271551B (en) * | 2020-02-17 | 2022-07-05 | 大唐移动通信设备有限公司 | Data stream transmission method, terminal and network side equipment |
CN113452487B (en) * | 2020-03-25 | 2022-09-13 | 展讯通信(上海)有限公司 | Data transmission method and device |
CN113498098B (en) * | 2020-04-03 | 2022-10-18 | 上海朗帛通信技术有限公司 | Method and equipment used for wireless communication |
CN113543038B (en) * | 2020-04-15 | 2022-10-28 | 上海朗帛通信技术有限公司 | Method and device used in node of wireless communication |
WO2021230595A1 (en) * | 2020-05-11 | 2021-11-18 | 삼성전자 주식회사 | Method and device for configuring bwp for continuity of mbs service in wireless communication system |
KR20210138395A (en) * | 2020-05-12 | 2021-11-19 | 삼성전자주식회사 | Method and apparatus for bwp switching for mbs reception in a wireless communication system |
WO2021241663A1 (en) * | 2020-05-28 | 2021-12-02 | 京セラ株式会社 | Communication control method and user equipment |
CN113950042A (en) * | 2020-07-17 | 2022-01-18 | 维沃移动通信有限公司 | Identification method, sending method and related equipment |
WO2022031127A1 (en) * | 2020-08-06 | 2022-02-10 | Samsung Electronics Co., Ltd. | Methods and systems for managing mbs service continuity for a ue |
US20230353986A1 (en) * | 2020-08-07 | 2023-11-02 | JRD Communication (Shenzhen) Ltd. | Apparatus and method for multicast/broadcast service |
US20240064591A1 (en) * | 2020-09-03 | 2024-02-22 | Toyota Jidosha Kabushiki Kaisha | Multicast broadcast service continuity in connected state |
CN114339902B (en) * | 2020-09-29 | 2024-06-18 | 北京紫光展锐通信技术有限公司 | Service switching indication, receiving method and device, storage medium, base station and terminal |
EP4264997A4 (en) * | 2021-01-15 | 2024-06-19 | Samsung Electronics Co., Ltd. | Method and system for measurement operation for multicast and broadcast services in 5g |
US20240187897A1 (en) * | 2021-04-01 | 2024-06-06 | Nokia Technologies Oy | Controlling of quality of experience measurement |
WO2022231303A1 (en) * | 2021-04-27 | 2022-11-03 | Samsung Electronics Co., Ltd. | Method and apparatur for multicast session signaling in wireless communication system |
CN115988426A (en) * | 2021-10-15 | 2023-04-18 | 华为技术有限公司 | Communication method and device |
CN115134834A (en) * | 2022-07-14 | 2022-09-30 | 中国联合网络通信集团有限公司 | Measurement configuration method, device, storage medium and equipment |
CN115052302A (en) * | 2022-07-14 | 2022-09-13 | 中国联合网络通信集团有限公司 | Measurement control method, device and storage medium |
CN115134833A (en) * | 2022-07-14 | 2022-09-30 | 中国联合网络通信集团有限公司 | Measuring method, measuring device, storage medium and equipment |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070011503A1 (en) * | 2005-05-27 | 2007-01-11 | Casio Hitachi Mobile Communications Co., Ltd. | Communication terminal |
WO2008052382A1 (en) * | 2006-10-30 | 2008-05-08 | Huawei Technologies Co., Ltd. | User equipment operations and maintenance measurement concept for multimedia broadcast and multicast services |
EP2107700A1 (en) * | 2007-01-26 | 2009-10-07 | NEC Corporation | Mobile communication system, terminal, base station device, and data communication method |
US20100208707A1 (en) * | 2007-09-26 | 2010-08-19 | Nec Corporation | Radio communication system and method |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030119452A1 (en) * | 2001-10-19 | 2003-06-26 | Samsung Electronics Co., Ltd. | Apparatus and method for controlling transmission power of downlink data channel in a mobile communication system supporting MBMS |
FI20021755A0 (en) * | 2002-10-02 | 2002-10-02 | Nokia Corp | A method and arrangement for expressing reception conditions for a broadcast |
CN101163260B (en) * | 2006-10-14 | 2011-04-13 | 华为技术有限公司 | System, apparatus and method for controlling load variation |
JP4964081B2 (en) * | 2007-10-01 | 2012-06-27 | パナソニック株式会社 | Wireless transmission device |
CN102057594A (en) * | 2008-06-05 | 2011-05-11 | 艾利森电话股份有限公司 | A method and equipment for providing unicast preparation for IPTV |
US8687537B2 (en) * | 2008-07-08 | 2014-04-01 | Sharp Kabushiki Kaisha | Communication system, reception device, and communication method |
CN102075866B (en) * | 2011-01-19 | 2014-06-25 | 大唐移动通信设备有限公司 | Equipment switching method and device |
WO2013024805A1 (en) * | 2011-08-12 | 2013-02-21 | 京セラ株式会社 | Mobile communication method, mobile terminal, wireless base station, and program |
US8644207B1 (en) * | 2011-08-19 | 2014-02-04 | Sprint Spectrum L.P. | Mixed carrier communication channel management |
EP3017616B1 (en) * | 2013-07-01 | 2018-12-05 | NEC Corporation | Method for providing multicast/broadcast service continuity for mobile terminals |
-
2014
- 2014-07-01 EP EP14747308.6A patent/EP3017616B1/en active Active
- 2014-07-01 US US14/902,043 patent/US10219245B2/en active Active
- 2014-07-01 WO PCT/EP2014/063983 patent/WO2015000912A1/en active Application Filing
-
2019
- 2019-01-11 US US16/245,269 patent/US10531430B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070011503A1 (en) * | 2005-05-27 | 2007-01-11 | Casio Hitachi Mobile Communications Co., Ltd. | Communication terminal |
WO2008052382A1 (en) * | 2006-10-30 | 2008-05-08 | Huawei Technologies Co., Ltd. | User equipment operations and maintenance measurement concept for multimedia broadcast and multicast services |
EP2107700A1 (en) * | 2007-01-26 | 2009-10-07 | NEC Corporation | Mobile communication system, terminal, base station device, and data communication method |
US20100208707A1 (en) * | 2007-09-26 | 2010-08-19 | Nec Corporation | Radio communication system and method |
Non-Patent Citations (8)
Cited By (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015089312A1 (en) * | 2013-12-13 | 2015-06-18 | Qualcomm Incorporated | Practical implementation aspects of unicast fetch for http streaming over embms |
US10728845B2 (en) | 2015-01-30 | 2020-07-28 | Huawei Technologies Co., Ltd. | Apparatus and method for a wireless device to receive data in an eco state |
US10849065B2 (en) | 2015-01-30 | 2020-11-24 | Huawei Technologies Co., Ltd. | Apparatus and method for a wireless device to receive data in an eco state |
JP2019198091A (en) * | 2015-01-30 | 2019-11-14 | 華為技術有限公司Huawei Technologies Co.,Ltd. | Apparatus and method for wireless device to receive data in eco state |
US10873905B2 (en) | 2015-01-30 | 2020-12-22 | Huawei Technologies Co., Ltd. | Apparatus and method for a wireless device to receive data in an eco state |
EP3515128A1 (en) * | 2015-01-30 | 2019-07-24 | Huawei Technologies Co., Ltd. | Apparatus and method for a wireless device to receive data in an eco state |
WO2016195944A1 (en) * | 2015-05-29 | 2016-12-08 | Qualcomm Incorporated | Inter-rat (radio access technology) and intra-rat measurement reporting |
EP3113543A1 (en) * | 2015-06-26 | 2017-01-04 | Intel IP Corporation | Method for processing radio signals and mobile terminal device |
US10798623B2 (en) | 2015-06-26 | 2020-10-06 | Apple Inc. | Method for processing radio signals and mobile terminal device |
EP3335442A4 (en) * | 2015-08-13 | 2019-01-16 | Nokia Solutions and Networks Oy | Method and apparatus for reducing a service interruption time within a single-cell point-to-multipoint system |
WO2017027043A1 (en) | 2015-08-13 | 2017-02-16 | Nokia Solutions And Networks Oy | Method and apparatus for reducing a service interruption time within a single-cell point-to-multipoint system |
CN107535011B (en) * | 2015-08-20 | 2020-08-07 | 华为技术有限公司 | Data processing method, device, system and storage medium |
US10826769B2 (en) | 2015-08-20 | 2020-11-03 | Huawei Technologies Co., Ltd. | Data processing method and device |
CN107535011A (en) * | 2015-08-20 | 2018-01-02 | 华为技术有限公司 | Data processing method and equipment |
EP3328124A4 (en) * | 2015-08-20 | 2018-05-30 | Huawei Technologies Co., Ltd. | Data processing method and apparatus |
KR102083814B1 (en) * | 2015-08-20 | 2020-03-03 | 후아웨이 테크놀러지 컴퍼니 리미티드 | Data processing method and device |
KR20180038007A (en) * | 2015-08-20 | 2018-04-13 | 후아웨이 테크놀러지 컴퍼니 리미티드 | Data processing method and apparatus |
US10575042B2 (en) | 2015-11-27 | 2020-02-25 | British Telecommunications Public Limited Company | Media content synchronization |
US10728714B2 (en) | 2016-03-31 | 2020-07-28 | British Telecommunications Public Limited Company | Mobile communications network |
US11477700B2 (en) | 2016-03-31 | 2022-10-18 | British Telecommunications Public Limited Company | Mobile communications network |
US11589269B2 (en) | 2016-03-31 | 2023-02-21 | British Telecommunications Public Limited Company | Mobile communications network |
US20190104389A1 (en) * | 2016-03-31 | 2019-04-04 | British Telecommunications Public Limited Company | Mobile communications network |
GB2548893B (en) * | 2016-03-31 | 2020-01-08 | British Telecomm | Mobile communications network |
WO2017167648A1 (en) * | 2016-03-31 | 2017-10-05 | British Telecommunications Public Limited Company | Mobile communications network |
US20190090163A1 (en) * | 2016-03-31 | 2019-03-21 | British Telecommunications Public Limited Company | Mobile communications network |
WO2017167838A1 (en) * | 2016-03-31 | 2017-10-05 | British Telecommunications Public Limited Company | Mobile communications network |
CN108886761A (en) * | 2016-03-31 | 2018-11-23 | 英国电讯有限公司 | Mobile communications network |
CN108781347A (en) * | 2016-03-31 | 2018-11-09 | 英国电讯有限公司 | Mobile communications network |
CN108702734A (en) * | 2016-03-31 | 2018-10-23 | 英国电讯有限公司 | Mobile communications network |
CN108781347B (en) * | 2016-03-31 | 2022-01-04 | 英国电讯有限公司 | Base station of a mobile communication network, method of operating a base station of a mobile communication network |
GB2551751A (en) * | 2016-06-29 | 2018-01-03 | British Telecomm | Mobile communications network |
US11510116B2 (en) | 2016-06-29 | 2022-11-22 | British Telecommunications Public Limited Company | Multicast-broadcast mobile communications network |
RU2737202C2 (en) * | 2016-07-27 | 2020-11-25 | Шарп Кабусики Кайся | System information on request for wireless communication |
US10687270B2 (en) | 2016-07-27 | 2020-06-16 | Sharp Kabushiki Kaisha | On-demand system information for wireless telecommunications |
WO2018022570A1 (en) * | 2016-07-27 | 2018-02-01 | Sharp Laboratories Of America, Inc. | On-demand system information for wireless telecommunications |
US11284336B2 (en) | 2016-07-27 | 2022-03-22 | Sharp Kabushiki Kaisha | Base station apparatus, a method in a base station apparatus, a user equipment and a method in a user equipment |
US10771298B2 (en) | 2016-08-04 | 2020-09-08 | British Telecommunications Public Limited Company | Mobile communications network |
KR20190055157A (en) * | 2016-11-01 | 2019-05-22 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Service interruption reporting |
KR102174043B1 (en) * | 2016-11-01 | 2020-11-04 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Service interruption report |
AU2018334879B2 (en) * | 2017-09-21 | 2021-05-13 | Huawei Technologies Co., Ltd. | Data transmission method and apparatus |
CN109547944A (en) * | 2017-09-21 | 2019-03-29 | 华为技术有限公司 | The method and device of data transmission |
EP3678390A4 (en) * | 2017-09-21 | 2020-08-26 | Huawei Technologies Co., Ltd. | Method and device for data transmission |
CN109756846A (en) * | 2017-11-06 | 2019-05-14 | 成都鼎桥通信技术有限公司 | The benefit packet method and system of group communication |
US11234240B2 (en) | 2018-06-08 | 2022-01-25 | British Telecommunications Public Limited Company | Wireless telecommunications network |
CN114788343A (en) * | 2019-12-16 | 2022-07-22 | 高通股份有限公司 | Measurement for multicast/broadcast service continuity |
WO2021127669A1 (en) * | 2019-12-16 | 2021-06-24 | Qualcomm Incorporated | Measurements for multicast/broadcast service continuity |
US11627502B2 (en) | 2019-12-16 | 2023-04-11 | Qualcomm Incorporated | Measurements for multicast/broadcast service continuity |
CN114788343B (en) * | 2019-12-16 | 2024-06-21 | 高通股份有限公司 | Measurement for multicast/broadcast service continuity |
CN115244899A (en) * | 2020-03-20 | 2022-10-25 | 高通股份有限公司 | Techniques for multicast and unicast convergence in wireless communications |
WO2021184349A1 (en) * | 2020-03-20 | 2021-09-23 | Qualcomm Incorporated | Techniques for multicast and unicast convergence in wireless communications |
WO2022236211A1 (en) * | 2021-05-05 | 2022-11-10 | Qualcomm Incorporated | Multicast-broadcast services configuration exchange for mobility, single-frequency network and interference coordination |
US11910277B2 (en) | 2021-05-05 | 2024-02-20 | Qualcomm Incorporated | Multicast-broadcast services configuration exchange for mobility, single-frequency network and interference coordination |
Also Published As
Publication number | Publication date |
---|---|
EP3017616A1 (en) | 2016-05-11 |
US10219245B2 (en) | 2019-02-26 |
EP3017616B1 (en) | 2018-12-05 |
US10531430B2 (en) | 2020-01-07 |
US20190166580A1 (en) | 2019-05-30 |
US20160374050A1 (en) | 2016-12-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10531430B2 (en) | Method for providing multicast/broadcast service continuity for mobile terminals | |
US10687179B2 (en) | Service continuity for group communication over LTE eMBMS | |
JP6456941B2 (en) | Service Continuity for Group Communication in Advanced Multimedia Broadcast Multicast Service | |
WO2016119634A1 (en) | Bearer selection for group service communication and service continuity | |
WO2024034567A1 (en) | Communication method | |
US20230362595A1 (en) | Communication control method and user equipment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14747308 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2014747308 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14902043 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |