GB2522043A - Multicast user service delivery - Google Patents

Abstract

A user equipment (UE) in a wireless communication network detects change in an associated bearer configuration for a multicast user service delivered via at least one bearer and transmits a message to a base station identifying the multicast user service generated in accordance with the associated bearer configuration. The base station may calculate the number of UEs receiving a multicast user service over a unicast bearer and if this exceeds a threshold, it may adjust the bearer configuration of at least one UE. By ensuring that a base station (such as an eNodeB) is informed about unicast radio bearers used to deliver a given multicast user service (such as a group call service), the base station functionality concerning delivery of the given multicast user service to one or more user equipment, UE, is modified. Based on information identifying the multicast user service associated with any particular unicast bearer, admission control is adapted for the multicast user service and service continuity in handover and bearer change events is improved.

Description

MULTICAST USER SERVICE DELIVERY

FIELD OF THE INVENTION

[0001] The present invention relates to the delivery of multicast user services. In particular, certain embodiments of the present invention relate to services supporting group call functionality, in a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) or LIE Advanced compliant mobile communications network comprising a mobile terminal (also referred to herein as the User Equipment, UE) and network equipment.

BACKGROUND OF THE INVENTION

[0002] Wireless or mobile (cellular) communications networks in which a mobile terminal (UE, such as a mobile handset) communicates via a radio link to a network of base stations (referred to variously as E-UTRAN Node B, eNodeBs eNBs) or other wireless access points connected to a telecommunications network, have undergone rapid development through a number of generations. Base stations serve one or more "cells", which define respective geographic areas of radio access coverage. Cells in turn are typically split into sectors. The initial deployments of systems using analogue signalling were superseded by Second Generation (2G) digital systems such as Global System for Mobile communications (GSM), which typically use a radio access technology known as GSM Enhanced Data rates for GSM Evolution Radio Access Network (GERAN). combined with an improved core network.

[0003] Second generation systems have themselves been largely replaced by or augmented by Third Generation (3G) digital systems such as the Universal Mobile Telecommunications System (UMTS), which uses a Universal Terrestrial Radio Access Network (UTRAN) radio access technology and a similar core network to GSM. UMTS is specified in standards produced by 3GPP. Third generation standards provide for a greater throughput of data than is provided by second generation systems. This trend is continued with the move towards Fourth Generation (4G) systems.

[0004] 3GPP design, specify and standardise technologies for mobile wireless communications networks. Specifically, 3GPP produces a series of Technical Reports (TR) and Technical Specifications (IS) that define 3GPP technologies.

The focus of 3GPP is currently the specification of standards beyond 3G, and in particular an Evolved Packet System (EPS) offering enhancements over 3G networks, including higher data rates. The set of specifications for the EPS comprises two work items: Systems Architecture Evolution (SAE, concerning the core network) and LTE concerning the air interface. The first set of EPS specifications were released as 3GPP Release 8 in December 2008. LTE uses an improved radio access technology known as Evolved UTRAN (E-UTRAN), which offers potentially greater capacity and additional features compared with previous standards. SAE provides an improved core network technology referred to as the Evolved Packet Core (EPC). Despite LTE strictly referring only to the air interface, LTE is commonly used to refer to the whole of the EPS, including by 3GPP themselves. LTE is used in this sense in the remainder of this specification, including when referring to LTE enhancements, such as [TE Advanced. LTE is an evolution of UMTS and shares certain high level components and protocols with UMTS. LTE Advanced offers still higher data rates compared to LTE and is defined by 3GPP standards releases from 3GPP Release 10 up to and including 3GPP Release 12. LTE Advanced is considered to be a 4G mobile communication system by the International Telecommunication Union (ITU).

[0005] Multicast user services, where the services may be supplied to more than one user simultaneously, are facilitated by Multimedia Broadcast Multicast Services, MBMS, in LTE. MBMS was introduced as a component of UMTS where the standard specified support for the delivery of broadcast services such as the transmission of television services and the transmission of multimedia content (e.g. audio, video, still images, text, etc.). While MBMS is a radio service that employs a broadcast mechanism at the radio interface, the provision of security features can ensure that only particular UE5 receive a service (i.e. UE5 belonging to a multicast group). An area in which data of a specified MBMS service is transmitted (when such data is scheduled for transmission) is referred to as an MBMS service area.

[0006] MBMS has been developed from its UMTS roots to allow the synchronisation of the delivery of multicast user services across a plurality of cells. The introduction of MBMS over Single Frequency Network (MBSFN) means that it is possible to simultaneously transmit identical data streams across more than one cell using the same radio frequency (ri) carrier: with MBSFN, identical content (control and payload) is transmitted at substantially the same time across the or each participating cell. MBSFN has been configured to make exclusive use of the radio resources for certain subframes within each radio frame.

[0007] MBSFN relies upon synchronisation between an MBMS service centre and each base station providing a participating cell and a SYNC protocol has been specified (in 3GPP TS 25.446). A group of base stations can be synchronised to define an MBSFN Synchronisation Area: each MBSFN Synchronisation Area may support one or more MBSFN Areas (i.e. groups of cells within the MBSFN Synchronisation Area that, together, provide an MBSFN transmission for a given MBMS service). It is possible that a given cell may provide support for up to eight different MBSFN Areas allowing the concurrent broadcast of a plurality of MBMS services.

Furthermore a single MBSFN area can also support more than one service.

[0008] Multicast user services may nevertheless be delivered to UEs using unicast bearers (i.e. Data Radio Bearer -DRB) as well as multicast bearers (Multicast Radio Bearer -MRB). These unicast bearers are typically established using unicast transmissions on the same carrier as MBMS: since MBMS uses only specific subframes of any radio frame, the unicast bearers are established in the non-MBMS subframes. Alternatively, where carrier aggregation is available, unicast bearers may be received on a first component carrier while MBMS may be received on a second component carrier.

[0009] There are circumstances where more efficient use of network resources requires multicast user services to be delivered by one or more unicast bearers rather than use the multicast bearers established under MBMS. Since MBMS is a multicastlbroadcast system that provides the same information to multiple users, the data rate that is possible in any MBSFN area is limited by the radio link conditions for the MBSFN transmission at the worst placed UE, as no user-specific adaptation of transmission parameters is available. Thus it may be more effective to deliver a given multicast user service to a subscriber using unicast bearers, not multicast bearers, which can be configured to make more efficient use of the access network for certain UE5. As the transfer delay in using a unicast bearer may be significantly lower (up to l2Oms; corresponding to the sum of a synchronisation delay and a scheduling period in LTE) than when using multicast bearer, switching to the unicast bearer may actually result in the loss of up to 6 multicast user service data packets.

[0010] The delivery of multicast user services by one or more unicast bearers is conveniently referred to as unicast mode: whereas the delivery of multicast user services by MBMS/multicast bearers is referred to as multicast mode. Both unicast and multicast modes are examples of transfer modes (also referred to as "modes of operation"). Often the selection of which of these transfer modes should be deployed for any given service is characterised as a threshold number of unicast bearers, above which migration to an MBMS bearers for at least some UE5 would be recommended.

[0011] From 3GPP Release 10, a counting procedure has been introduced in MBMS to allow the network to quantify the number of active UEs in each cell that are receiving (or interested in receiving) a given MBMS service via a multicast bearer, MRB, (described in 3GPP TS 36.443). Naturally, certain UEs will not capable of receiving the multicast bearer and will prioritise on-going services using unicast bearer, DRB, as a result. Such UEs are only "interested in" receiving MBMS via unicast bearer and should not be counted in the above counting procedure.

[0012] It is conventional to refer informally to a communication session over a telecommunications network as a "call", whether that call is a voice call or a user data communication exchange. The analogue to a "call" in an MBMS service is referred to as an "MBMS session'. MBMS sessions may be transmitted more than once and each session has an associated identifier by which repeated transmissions may be identified. This session identifier is useful in cases when the UE has already correctly received a certain part of a multicast user service, such as a video clip: once identified by the session ID the UE can skip that repeated data.

[0013] The use of counting procedures to determine which transfer mode is most optimal for a particular MBMS service/group call increases complexity and signalling. Even in simple implementations, there is still complexity and additional signalling due to need to perform periodic counting in the entire service area throughout the entire session.

[0014] Multicast user services, such as group call services, are in development. One working group in 3GPP is concerned with the standardisation of the service enablers for Group Call. This working group has defined a group call service enablers, GCSE, architecture which uses the architecture of MBMS within [TE networks. Within the Release 12 time frame, 3GPP groups SA2 and RAN2 have studied how to support group calls, with the findings documented in the following reports: TR 23.768 Study on architecture enhancements to support Group Communication System Enablers for [TE (GCSE_LTE) (Release 12, 5A2) and TR 36.868 Study on Group Communication for E-UTRA (Release 12, RAN2).

[0015] In a submission to the 3GPP TSG-SA WG2 meeting #99, (S2-133776), a number of challenges to the delivery of GCSE in LTE are summarised. Amongst the challenges, it is seen as important to ensure service continuity and resource efficiency.

[0016] Service continuity relates to scenarios when UE5 move among different cells that each provide multicast user services (sometimes referred to as "mobility") and/or scenarios when the delivery of group communications changes mode of operation (as might be necessary for resource efficiency). Without careful management, such scenarios can lead to significant interruption in group service delivery. In addition to issues of data loss upon change of mode of operation (i.e. transfer mode), there may be service interruption if the target cell of a handover event employs MRB while the UE acquires cell configuration and/or radio resources information from multicast system information blocks (SIB) and multicast control channels (MCCH). In an alternative handover scenario, the source cell may employ MRB while the target cell uses DRB to deliver multicast user services.

[0017] As noted above, it is often desirable to allow the network to switch between modes of operation so that more efficient use is made of resources. This can be performed dynamically on part or all of an MBMS service area, additionally or alternatively mode selection may be determined statically in accordance with the type of cell or the forecast usage within the MBMS service area (whether throughout the whole service area or in part or parts thereof).

BRIEF SUMMARY OF THE DISCLOSURE

[0018] It is an aim of certain embodiments to address at least some of the issues identified above. One particular aim of certain embodiments is to provide a relatively simple means to support group call, that uses radio resources efficiently and avoids service interruption upon change of transfer mode (both upon UE mobility and upon E-UTRAN switching the mode).

[0019] In accordance with certain embodiments, there is provided a method of managing the delivery of a multicast user service to at least one user equipment, UE, in a wireless communication network, the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the method comprising: detecting a change in the associated bearer configuration; and receiving, at a base station, a message indicating the change, the message including service information identifying the multicast user service.

[0020] Additionally or alternatively, the service information may comprise at least one of multicast user service information, multicast bearer service information, or information identifying downlink user data packets.

[0021] Conveniently, the multicast bearer service information may include an identity allocated to multicast bearers to be used for the multicast user service, such as a TMGI. Alternatively or additionally, the multicast user service information may include one or more identities allocated to the multicast user service itself. Note that the signalling of the multicast bearer service identity corresponds to a given instance of a multicast bearer and not necessarily the multicast bearer service (i.e. can be mapped to the user service only when there is one multicast user service on the bearer).

[0022] Thus, the service information identifying the multicast user service, may be selected from: the MBMS user service/group call identity; the multicast bearer identity; information needed to identify the DL user data packets associated with a particular MBMS service/group call; or a combination of these.

[0023] In certain embodiments, the multicast user service may be selected from a group including: an MBMS service, and a group call service.

[0024] Additionally or alternatively, in accordance with certain of these embodiments, the method may further comprise: upon receiving a request for admission of a new or modified unicast bearer, calculating a predicted system load; and, adjusting the predicted system load in accordance with which multicast user service the unicast bearer is associated. This results in an admission control scheme that adapts according to the presence of unicast bearers for multicast user services.

[0025] The predicted system load may be adjusted by changing a weight factor to reflect the traffic characteristics of multicast user services. In general, multicast user services such as group calls have a lower voice activation factor per UE.

[0026] The weighting factor may be further changed to reflect statistical multiplexing gains if the unicast bearer's multicast user service corresponds to a multicast user service that is not already delivered via a unicast bearer, since a lower load is estimated for such unicast bearers. If there is already a unicast bearer, to another UE, for the same multicast user service, packets will need to be transmitted at substantially the same time so statistical multiplexing opportunities are lower and thus impact on load is higher. The base station may perform the step of changing the weight factor.

[0027] The weighing factor is thus adjusted firstly to account for the new unicast bearer being for an MBMS service/group call service rather than "normal" speech but also because the base station has knowledge about other UE5 on same MBMS service/group call service (it being assumed that these services should allow less conservative multiplexing).

[0028] Additionally or alternatively, the method may further comprise: for each UE, determining from the service information, whether the UE is receiving a multicast user service and, if so, which particular multicast user service is being received; calculating from the results of said determination, the number of UE5 receiving a given multicast user service over a unicast bearer; determining whether that number exceeds a predetermined threshold; and adjusting the associated bearer configuration for at least one UE receiving the given multicast user service when the number of UE5 receiving the given multicast user service over a unicast bearer exceeds the predetermined threshold.

[0029] As a result, the base station may apply dynamic transfer mode selection between Point To Point transfer mode (PTP) and Point To Multipoint transfer mode (PTM) for the or each UE. For example, adjusting the associated bearer configuration may comprise changing the bearer for user data packets of a given multicast user service from unicast bearer to multicast bearer for a specific UE.

[0030] Additionally or alternatively, in accordance with certain of these embodiments, the associated bearer configuration may include, for a given UE, a multicast bearer and a suspended unicast bearer. The unicast bearer may thus be kept alive indefinitely or for a predetermined duration but unused.

[0031] Where the change in the associated bearer configuration arises from a handover of the given UE to the base station, the method may further comprise resuming transmission of multicast user service data over the suspended unicast bearer to the given UE.

[0032] Additionally or alternatively, in accordance with certain of these embodiments, the at associated bearer configuration may include, for a given UE, a unicast bearer, and the method may further include requesting I P multicast from a multicast service provider.

[0033] Additionally or alternatively, in accordance with certain of these embodiments, where a multicast transmission synchronisation protocol is specified for the delivery of multicast user services over multicast bearers, the associated bearer configuration may include, for a given UE, a unicast bearer, and the method may further comprise applying the multicast transmission synchronisation protocol to the transmission timings of the unicast bearer, thereby substantially synchronising the unicast bearer transmission timings with the transmission timings used by multicast bearers.

[0034] Additionally or alternatively, in accordance with certain of these embodiments, the associated bearer configuration may include, for a given UE, a unicast bearer, the method further comprising receiving multicast user service data over IP multicast from a multicast service provider and delivering the multicast user service data to the given UE over the unicast bearer.

S

[0035] The above steps address possible service interruption arising from differences in transfer delays within a cell between a unicast mode and a multicast mode.

Furthermore, these steps also address possible service interruption arising from handover between a source cell and a target cell that employs multicast bearers (since the target cell and source cell may use different configurations or radio resources (i.e. different system information blocks, SIB13 and/or multicast control channels, MCCH) to provide the same multicast bearer). In the latter case, the base station in the target cell initially provides the multicast user service to the new UE via a unicast bearer (to reduce service interruption), and then once sufficient time has elapsed for the UE to acquire cell configuration and/or radio resource information from SIB13, MCCH and/or multicast transport channels, MTCH, suspends the unicast bearer and provides the multicast user service to the new UE via the multicast bearer.

[0036] Conveniently the associated bearer configuration includes, for a given UE, a unicast bearer and the application layer encryption/ciphering applied to the multicast user service data for delivery to the UE over the unicast bearer may be the same as that used in the delivery of the multicast user service data over IF multicast. As a result, the base station can relate packets received via both bearers and hence align transmission timing (regardless of which bearer it forwards the packets from).

[0037] Additionally or alternatively, in accordance with certain of these embodiments, the associated bearer configuration may include, for a given UE, a unicast bearer, and the unicast bearer may carry multicast user service data exclusively for the multicast user service.

[0038] In accordance with certain of these embodiments, the service information may be received from the UE at the base station using access stratum, AS, signalling.

[0039] Alternatively, in accordance with certain of these embodiments, where a given UE is handed over from a source base station to the base station and the service information may be received from the UE at the source base station and forwarded to the base station.

[0040] Alternatively, in accordance with certain of these embodiments, the service information may be received from the UE at the base station via an MME using non-access stratum, NAS, signalling.

[0041] As a result, certain embodiments provide the additional signalling options to facilitate delivery of multicast user services, whereby a base station (e.g. an eNB) is informed about the bearer and/or multicast user service currently used or required by each user. The multicast user service may be an MBMS service/group call service whose user data is transferred across a particular unicast bearer. The base station is only informed about multicast user services received via a unicast bearer when the configuration of associated bearers changes (i.e. the signalling is exchanged upon setup/change of the unicast bearer). When the unicast bearer is kept alive (but suspended) while the UE receives via multicast, the base station always has this service information.

[0042] Certain embodiments thus provide a solution for supporting group calls that uses dedicated unicast bearers when there few UE5 in a cell that (are interested to) receive the group call and multicast bearers otherwise.

[0043] In accordance with certain other embodiments, there is provided a base station in a wireless communication network, adapted to manage the delivery of a multicast user service to at least one user equipment, UE, in a wireless communication network, the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the base station comprising: a receiver adapted to receive a message indicating a change in the associated bearer configuration, the message including service information identifying the multicast user service; and a processor adapted to process the received information to determine characteristics of the multicast user service. Certain embodiments of the base station may be further arranged to implement the above described method.

[0044] In accordance with certain other embodiments, there is provided a user equipment, UE, for receiving a multicast user service via a base station in a wireless communication network, the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the UE comprising: a receiver adapted to receive user data packets and/or messages for the multicast user service over the at least one bearer; a processor adapted to: detect a change in the associated bearer configuration; process the received user data packets and/or messages to obtain service information identifying the multicast user service; and to generate a message including said service information identifying the multicast user service; and a transmitter adapted to transmit the message to the base station.

[0045] In accordance with yet other embodiments, there is provided a computer program comprising instructions arranged, when executed, to implement a method and/or base station in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.

BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which: Figure 1 schematically illustrates an overview the GCSE architecture in an LTE mobile communication network; Figure 2 illustrates the provision of information identifying group call and/or MBMS bearer service directly to the eNB; Figure 3 illustrates the provision of information identifying group call and/or MBMS bearer service to the MME and then forwarding to the eNB; Figure 4 illustrates the signal flow during the setup of an MBMS E-RAB in

accordance with the MBMS specification;

Figure 5 illustrates certain steps in a conventional admission control scheme; Figure 6 illustrates the signal flow during handover between a source eNB (SeNB) and a Target eNB (TeNB); Figure 7 illustrates the signal flow used in providing network initiated bearer establishment; and Figure 8 illustrates the signal flow used in providing UE initiated bearer establishment.

DETAILED DESCRIPTION

[0047] There are circumstances where more efficient use of network resources requires multicast user services to be delivered by one or more unicast bearers rather than use the bearers established under MBMS.

[0048] Multicast user services, such as group call services, are in development. One working group in 3GPP is concerned with the standardisation of the service enablers for Group Call. This working group has defined a group call service enablers, GCSE, architecture which uses the architecture of MBMS within LTE networks.

[0049] An overview of a GCSE architecture based upon an LTE network implementing MBMS, suitable for delivery of multicast user services is shown in Figure 1. As for a generic LTE network, the GCSE architecture comprises three high level components: at least one UE 100, the E-UTRAN 130 and the EPC 199. The EPC 199 communicates with Packet Data Networks (PDNs) and servers in the outside world. Figure 1 shows the key component parts of the EPC 199. It will be appreciated that Figure 1 is a simplification and a typical implementation of LTE will include further components. In Figure 1, interfaces between different parts of the LIE system are shown.

[0050] The E-UTRAN 130 comprises a plurality of eNBs (E-UTRAN Node B) 110 which is responsible for handling radio communications between the UE 100 and the EPC 199 across an air interface, Uu 105 (only on eNB is shown for simplicity). An eNB controls UEs 100 in one or more cell. LTE is a cellular system in which the eNBs provide coverage over one or more cells. Typically there is a plurality of eNBs 110 within an LTE system. In general, a UE 100 in LTE communicates with one eNB through one cell at a time.

[0051] Key components of the EPC 199 are shown in Figure 1. It will be appreciated that in an LTE network there may be more than one of each component according to the number of UE5 100, the geographical area of the network and the volume of data to be transported across the network. Data traffic is passed between each eNB 110 and a corresponding Serving Gateway (S-GW) 150 which routes data between the eNB 110 and a PDN Gateway (P-GW) 160. The P-GW 160 is responsible for connecting a UE 100 to one or more servers or PDNs (not shown) in the outside world. A Mobility Management Entity (MME) 140 controls the high-level operation of the UE 100 through signalling messages exchanged with the UE 100 through the E-UTRAN 130. Each UE 100 is registered with a single MME 140.

There is no direct signalling pathway between the MME 140 and the UE 100 (communication with the UE 100 being across the air interface 105 via the E-UTRAN 130). Signalling messages between the MME 140 and the UE 100 comprise EPS Session Management (ESM) protocol messages controlling the flow of data from the UE to the outside world and EPS Mobility Management (EMM) protocol messages controlling the rerouting of signalling and data flows when the UE 100 moves between eNBs 110 within the E-UIRAN 130 while in connected state (i.e. during "handover"), or moves between tracking areas (in idle/connected state) etc.. The MME 140 exchanges signalling traffic with the S-GW 150 to assist with routing data traffic. The MME 140 also communicates with a Home Subscriber Server, HSS, (not shown) which stores information about users registered with the network.

[0052] Multicast user services, where the services may be supplied to more than one user simultaneously, are facilitated by Multimedia Broadcast Multicast Services, MBMS, in LIE.

[0053] MBMS services may be received by both active and idle UEs 100. Active UEs are those in an RRC_CONNECTED (Radio Resource Control Connected) state; while idle UE5 are those in RRC_IDLE state.

[0054] MBMS has been developed to allow the synchronisation of the delivery of multicast user services across a plurality of cells. The introduction of MBMS over Single Frequency Network (MBSFN) means that it is possible to simultaneously transmit identical information streams (both user plane and control plane) across more than one cell using the same radio frequency (if) carrier.

[0055] Figure 1 also illustrates further network elements that facilitate the implementation of MBMS (and thus also GCSE) in LTE. Within the EPC 199, there is therefore an entity known as the MBMS Gateway, MBMS GW 170 and an entity known as a Broadcast Multicast Service Centre, BM-SC 180.

[0056] The SM-SC 180 is the point in the EPC 199 where the content for transmission via MBMS is inserted. The SM-SC 180 also manages the MSMS services by controlling star and stop procedures for MBMS sessions, allocating a session identity and a temporary mobile group identity (TMGI) to each MBMS session, specifying suitable quality of service (QoS) parameters to each session and transmitting MBMS data using the SYNC protocol (specified in 3GPP TS 25.446).

MBSFN relies upon synchronisation between the SM-SC 180 and each eNS 110.

It is remarked that the TMGI identifies an MBMS/multicast bearer (and that more than one may be allocated for the same session of any given user service).

[0057] The MBMS GW 170 is configured to allocate an IP multicast address for the transmission of MBMS data to participating eNBs 110, to transmit MBMS data using the allocated IP multicast address and to mediate in control plane signalling procedures between the SM SC and the radio access network, E-UTRAN 130.

The IP multicast technique in MBMS allows a single transmission to send an IP packet to a plurality of receiving network nodes (i.e. eNBs) via the MBMS GW 170 to the cells where MBMS transmission is being provided (i.e. participating cells).

[0058] The E-UTRAN 130 comprises a multi-cell/multicast coordination entity, MCE 120.

The MCE 120 may either be a standalone entity or a logical component of an eNB.

In Figure 1, the MCE 120 is shown as a standalone entity: typically there would be a plurality of eNSs 110 each with a respective M2 interface 112 to the MCE in the standalone case but this has been omitted for brevity. The (standalone) MCE 120 serves to ensure inter-eNB coordination of MBSFN transmissions and in particular coordinates the usage of the same radio resources in each cell of each MBSFN service area. Whether standalone or incorporated within respective eNBs 110, the MCE 120 operates to allocate radio resources (in both time and frequency domain) to MBMS data transmission, to control admission to those resources, to initiate the counting procedure (described in 3GPP TS 36.443), and based upon the results of the counting procedure to determine whether MBMS services should be delivered or not.

[0059] An Application Server (the GCSE-AS node 200) governs the set-up, maintenance and release of group sessions in the GCSE architecture. This GCSE-AS node 200 provides the application layer of GCSE, setting up and controlling group membership and arbitrating floor control in group services such as Push To Talk (PTT). Each Group Communication Session (or "group call') has a corresponding unique identifier -the GCS ID; this is used at the application layer between GCSE-AS and UE client application to identify the particular multicast user service.

[0060] Within an LTE network, user data is transferred between different components of the network using bearers. An EPS bearer serves to transfer data between a UE and a P-GW 160. The data flow is bi-directional, thereby establishing user plane connectivity. Data carried by an EPS bearer comprises one or more service data flows carrying data for a particular service, for instance streamed media.

Each service data flow comprises one or more packet flows.

[0061] An initial EPS bearer known as the "default" EPS bearer provides an always-on connectivity between a given UE and PDN Gateway. Further EPS bearers may be between the UE and other PDN Gateways or indeed between the same UE and PDN Gateway at a different Quality of Service (QoS) level: to contrast with the default EPS bearer these additional EPS bearers are referred to as dedicated" EPS bearers.

[0062] An EPS bearer is itself constructed from a combination of an 55/58 bearer (which provides connectivity between an S-GW 150 (either in the home network of the UE or in a visited network) and a home PDN Gateway 160) and an E-UTRAN Radio Access Bearer, E-RAB (which links the UE 100 to a S-GW 150). The process for set-up of an E-RAB is described below in relation to Figure 4.

[0063] MBMS data is transferred in the downlink direction only (i.e. from eNB to UE) using an MBMS E-RAB but may also be transferred using a unicast E-RAB instead.

[0064] The challenges to the delivery of GCSE in LTE include the need to ensure service continuity and resource efficiency.

[0065] Service continuity relates to scenarios when UE5 move among different cells that each provide multicast user services (sometimes referred to as "mobility") and/or scenarios when the delivery of group communications changes mode of operation (e.g. from unicast mode to multicast mode or vice versa, as might be necessary for resource efficiency).

[0066] Group calls may use dedicated unicast bearers, for example when there few UE5 in a cell receive the group call, and/or multicast bearers. The mode where dedicated unicast bearers are used is referred to as Point To Point transfer mode (PTP), while the alternative mode using multicast bearers is referred to as Point To Multipoint (FTM). There are a number of variants upon PTM including Single Cell Point To Multipoint (SC-PTM) and Multiple Cell Point To Multipoint (MC-PTM).

[0067] It is often desirable to allow the network to switch between modes of operation (i.e. transfer modes) so that more efficient use is made of resources. This can be performed dynamically on part or all of a group call service area: indeed, as noted above, the counting procedure described in 3GPP TS 36.443 may be used to determine optimal transfer mode. Additionally or alternatively, mode selection may be determined statically in accordance with the type of cell or the forecast usage of the service area.

[0068] When performing admission control upon the establishment of a dedicated bearer to be used for a group call, E-UTRAN may consider its impact to the system load to be the same as for a normal call, depending of the bearer attributes indicated by the Core Network (CN). For group calls used for public safety (i.e. Push To Talk, PTT, applications), speech frames are however transmitted less frequently i.e. the voice activation factor is typically lower than for normal speech calls. This could be reflected by introducing one or more bearer attribute values (i.e. a QoS class of identifier, QCI, value) specifically for group calls.

[0069] As a given cell may provide support for the concurrent broadcast of a plurality of MBMS services: it is contemplated that such cells may carry more than one group call at a time. When multiDle group calls are in parallel progress, it is unlikely that speech frames of different group calls are to be transferred simultaneously. Thus, when performing admission control, E-UTRAN may apply a weight factor reflecting the statistical multiplexing options. The statistical multiplexing gains are however limited between bearers concerning the same group call. In cases where E-UTRAN is not aware of which bearers are used for which group calls, it will have to assume a conservative value for the weight factor reflecting the statistical multiplexing gains.

[0070] Multicast delivery (i.e. Point to Multipoint, PTM) using MBSFN is typically more efficient than unicast delivery (also referred to as Point To Point) when on average the number of users exceeds a certain threshold. The value of this threshold depends, amongst other things, on the number of cells participating in the MBSFN transmission. Some studies have shown that the overall system cost of a solution involving Multi-Cell Point To Multipoint (MC-PTM) is not significantly lower than a solution employing Single Cell Point To Multipoint (SC-PTM). The latter solution avoids the complexity of deciding which cells are to participate in an MBSFN transmission (and to dynamically adjust this upon on changes in density of UEs interested to receive the service). For the purposes of the following discussion, PTM refers to both forms of PTM; however certain embodiments illustrate PTM using the "simpler" case of SC-PTM.

[0071] It should be noted that the dynamic transfer mode selection (i.e. based on density of UE5 interested to receive the service) may be used in a semi-statically configured part of the service area, while other semi-statically configured service area pads always use a predetermined transfer mode e.g. always use MC-PTM during certain hours in a shopping mall area, always use PTP in more isolated rural areas.

[0072] The GCSE architecture of Figure 1 assumes that the GCSE-AS node decides whether to use unicast or multicast transfer mode, based on a mechanism by which the location of a GCSE enabled UE is reported at cell level. Such location reporting procedures may however introduce quite a bit of complexity and signalling.

[0073] On admission control, it has been realised that the impact to the system load of the bearer to be admitted may depend upon whether or not it is related to group call for which dedicated bearers are established already. To date, the eNB would be required to assume a conservative value for the weight factor reflecting the statistical multiplexing gains.

[0074] Often the selection of which mode of operation should be deployed for any given service is characterised as a threshold number of unicast bearers, above which migration to an MBMS bearer would be recommended.

[0075] A relatively simple way to support dynamic transfer mode selection concerns one in which each eNB decides whether to employ (SC-)PTM or unicastlPTP. It is noted that the MBMS architecture assumes the transfer mode is decided by the MCE, based on a procedure by which E-UTRAN can count the connected mode UEs (interested in) receiving a service via FTM from a particular eNB (i.e. not at the level of a cell). In the simple solution (i.e. SC-PTM), the MCE logical entity would be implemented in the eNB, and there would be no inter-eNB coordination of MBSFN transmissions. From 3GPP Release 10, a counting procedure has been introduced in MEMS to allow the network to quantify the number of active UE5 in each cell that are receiving (or interested in receiving) a given MBMS service (described in 3GPP IS 36.443).

[0076] The known solution however involves significant amounts of signalling i.e. all eNBs in the MBMS service area will need to periodically perform counting during the entire duration of the MBMS session (starting immediately following the receipt of session start).

[0077] For the sake of completeness it is noted that in this known solution, the session start signalling is used to inform the eNB about the RAB QoS parameters, session start/duration, service area and the information needed to initiate an IP multicast session towards the BM-SC.

[0078] Furthermore, in this known solution, all UEs receiving the MBMS service/group call via unicast bearer are assumed to be in RRC connected mode. The counting procedure is not supported in RRC idle mode so this assumption avoids any additional difficulties.

[0079] In MBMS, the TMGI, together with the session identifier, typically identifies the transmission of a specific MBMS session. Delivery of MBMS sessions/group calls (using MBMS and unicast bearers) adds further complexity since the same unicast bearer may be used to carry more than one MBMS session/group call. Moreover, it is possible that multiple MBMS sessions/group calls may be mapped to the same multicast bearer. In the latter case, the TMGI would identify a set of MBMS sessions/group calls rather than an individual MBMS session/group call.

[0080] To inform the E-UIRAN about the bearers used, the eNB may be provided with information identifying the or each MBMS service/group call and/or identifying the MBMS bearer service. This information corresponds to at least one of: a pre-allocated identity for the multicast bearer to be used for a given group call (i.e. the TMGI -identifying the group call or set of group calls with which the multicast bearer is associated); a group call identity (GCS Id); and/or information needed to identify the DL user data packets associated with a particular MBMS service/group call.

[0081] In accordance with certain embodiments, the information necessary to perform effective dynamic transfer mode selection requires E-UTRAN to be provided with additional service information based on which it can identify the downlink (DL) user data packets associated with a particular MBMS service/group call. In certain embodiments, the E-UIRAN (i.e. the eNB) is informed about the actual bearer used to transfer user data of the concerned MBMS service/group call, whenever a unicast bearer is used in the network for an MBMS service/group call.

[0082] The eNB should be kept up to date, so ideally the information should be provided whenever the delivery of an MBMS service or group call involves starting (and releasing) a unicast bearer as well as when changing to another bearer.

[0083] In particular, the E-UTRAN is informed about the unicast bearer used to transfer user data of an MBMS service/group call upon any one of the following events: * start of the use of a unicast bearer for transferring user data for a specific service, * change in bearer (unicast to multicast; unicast to multicast AND unicast, etc.) used for transferring user data for a specific service, and * termination of use of a unicast bearer for transferring user data for a specific service.

[0084] The additional service information may be provided to the eNS by the core network itself, or by each participating UE. There are two routes by which the service information may be provided by the UE: to the eNB directly; and to the MME, which forwards it to the eNB. These two routes are considered in the following discussion.

[0085] Specifically, the E-UTRAN (i.e. the eNB) is informed about the unicast bearer used to transfer user data of an MBMS service/group call: by signalling on the Uu interface only (between UE and eNB) or by signalling across Uu and Si interfaces (between eNB and MME).

[0086] Where the additional service information is provided to the eNB by the core network (ON), this involves adding the service information to the messages that are exchanged upon bearer request, bearer modification and bearer release from GCSE-AS via PORE, PDN GW, Serving GW, MME to eNS. This information is stored by the eNB as part of E-RAB/bearer context, thus may be transferred upon handover events.

[0087] The provision of additional service information to the eNS by each participating UF offers an alternative route that nevertheless delivers this information when it is needed. In addition, this alternative route has the advantage that fewer interfaces need to be adapted and fewer specifications need to be changed to implement the delivery of this information.

[0088] As discussed above, the impact on system load of a new bearer (i.e. a bearer yet to be established) depends on whether or not that new bearer is related to group call for which session data has already been transferred via a unicast bearer. That established bearer may be the default bearer and/or a dedicated bearer. If the eNB can determine the MBMS service(s)/group call service(s) whose user data is to be carried by the prospective new bearer, it can take that information into account when determining the weight factor reflecting the statistical multiplexing options: ideally, the eNB can apply a more optimal value for this factor.

[0089] For this reason, certain embodiments require that, whenever admitting a new bearer, the E-UTRAN applies the information about the bearer used to transfer user data of MBMS service(s)/group call(s) to determine the impact on system load. In particular instances, the bearer information may be used by applying a weight factor reflecting the statistical multiplexing options.

[0090] Even in the simple solution using only SC-FTM, known use of counting procedures to determine whether to employ SC-PTM or unicastlPTP, adds complexity and signalling.

[0091] However, providing the eNB knows the MBMS service(s)/group call(s) whose user data is carried by any prospective new bearer, the provision of the additional service information is all that is required for the eNB to infer the number of UE5 receiving a given service by means of a unicast bearer and there is no need to perform counting.

[0092] Put another way, the E-UTRAN applies the information about a bearer used to transfer user data of MBMS service(s)/group call(s) to determine the number of UEs receiving a particular service/group call. That number is then used to decide the transfer mode (PTP or PTM). The MBMS counting procedure is no longer needed.

[0093] According to existing MBMS procedures, a UE originally receiving an MBMS service via a unicast bearer initiates release of this unicast bearer upon receiving the concerned service via an MBMS bearer.

[0094] In case of group calls provided via an MBMS bearer, the network could alternatively merely suspend DL data transmission via the concerned unicast bearer, i.e. without actually releasing it. This latter approach has the advantage that the information about the MBMS service(s)/group call(s) whose user data is transferred by the bearer is maintained and can be forwarded upon handover, for instance.

[0095] This information could be useful to avoid any service interruption that may occur upon handover from source cell to target cell. Such service interruption may result as it will take some time before the UE is able to: * continue MBMS reception according to the configuration applicable in the destination cell; and/or * initiate resumption of unicast transfer (e.g. due to the time to acquire MBMS specific System Information Blocks -SIB13, the Multicast Control Channel -MCCH, the Multicast Traffic Channel, MTCH).

[0096] To address service interruption issues, certain embodiments require that DL data transmission via the concerned unicast bearer is merely suspended, i.e. without actually releasing it, when the UE switches receipt of an MBMS service/group call from unicast (PTP) to multicast (PTM).

[0097] In addition, certain embodiments allow the E-UTRAN to request IP multicast (i.e. between BM-SC and eNB) even when on Uu (still) using a unicast bearer to transfer the user data of the concerned MBMS service/group call FTP.

[0098] Furthermore, in certain embodiments, when transmitting packets across the unicast bearer, E-UTRAN may roughly apply the transmission timing stipulated by the SYNC protocol, e.g. radio frame level. This would normally be used only for multicast bearer transmission.

[0099] Alternatively or in addition, certain embodiments allow the E-UTRAN to forward packets received via IP multicast, i.e. via the MBMS E-RAB (using SYNC protocol), via unicast bearer to the UE.

[00100] Where DL data transmission is suspended and following a handover event, certain embodiments enable the E-UTRAN to initiate temporary resumption of transmission of user data of an MBMS service/group call via the suspended unicast bearer to the UE.

[00101] Where user data of multiple MBMS services/group calls is transferred by the same bearer, further steps may be needed to ensure an effective solution to service interruption. It is contemplated, for instance, that the eNB might have to perform Deep Packet Inspection (DPI) when wishing to apply the rough timing stipulated by the SYNC protocol to particular PDU5, or when replacing packets received via a dedicated bearer across Si by packets received via an MBMS bearer; either outcome would add unwanted complexity.

[00102] For this reason, certain embodiments require that the P-GW avoids multiplexing user data of a particular MBMS service/group call with user data of other services on the same unicast bearer.

[00103] Further steps may also be necessary in cases where the payload included in MBMS service/group call related user data packets depends on whether the packet is transferred across a multicast bearer or a unicast bearer towards the E-UTRAN.

One particular aspect concerns the encryption/ciphering of the user data. It is contemplated that, for group calls, the application layer handles group management. Consequently, the corresponding GCSE-AS node is generally assumed to handle security (rather than BM-SC, as in the case of MBMS). It is possible that this does not apply for both transfer modes, i.e. both for the case the data is transferred via a unicast and for the case the data is transferred via a multi-cast bearer.

[00104] Consequently, in certain embodiments, the network is configured to avoid approaches that result in payload being dependent on the transfer mode to the extent that this dependency makes it difficult or impossible for the E-UTRAN to forward data received via a multicast bearer via a unicast bearer. For instance, the network ensures that the application layer encryption/ciphering is the same for both transfer modes.

[00105] The reader will readily appreciate that the embodiments above require changes that affect the UE procedures and the information exchanged between UE and E-UTRAN. These procedures are specified in 3GPP TS 36.331, Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol

specification.

[00106] Certain changes to the message flows/signalling resulting from the items included in the previous section are considered below: in particular, the procedures relating to starting and stopping receipt of user data via a unicast bearer and to changing the bearer used.

[00107] In the case where the network starts receiving user data of an MBMS service/group call via a unicast bearer, there are two distinct possibilities.

[00108] Firstly, a new unicast bearer may be established, either using the network initiated bearer establishment procedure (for instance, according to 5.4.1 of 3GPP TS 23.401: "Technical Specification Group Services and System Aspects; GPRS enhancements for E-UTRAN access", see Figure 7) or the UE initiated bearer establishment procedure (for instance, according to 5.4.5 of TS 23.401, see Figure 8).

[00109] Alternatively, an existing unicast bearer is used (such as the suspended unicast bearer mentioned above). In this case, a bearer modification may still be necessary; for example, to increase the resources allocated and/or to modify the uplink (UL) traffic flow template (TFT). This modification could be network initiated (according to 5.4.3 of TS 23.401) or UE initiated (according to 5.4.5 of TS 23.401).

[00110] The network may change the bearer used for the transferring the user data of an MBMS service/group call for other reasons. In this case, there might again be a bearer modification procedure as in the preceding bullet (but network initiated case only -according to 5.4.3 of TS 23.401).

[00111] In the case where the network stops receiving user data of an MBMS service/group call via a unicast bearer. There are two further distinct possibilities.

[00112] In the first instance, the unicast bearer is released, either using the network initiated bearer release procedure (according to 5.4.4 of TS 23.401) or the UE initiated bearer establishment procedure (according to 5.4.5 of IS 23.401) [00113] In the second instance, the bearer is kept (maintained). A bearer modification may nevertheless be needed: for example, to reduce the resources allocated and/ or to modify the UL TEl. This modification could be network initiated (according to 5.4.3 of TS 23.401) or UE initiated (according to 5.4.5 of TS 23.401).

[00114] In certain network initiated cases, signalling is initiated by the GOSE-AS, which initiates a procedure towards the PORE.

[00115] As indicated above, there are two routes by which the service information may be provided by the UE: to the eNB directly; and to the MME, which forwards it to the eNB.

[00116] The situation where each UE provides additional service information to the eNB directly is summarised in Table 1. The table shows exemplary candidate RRC messages used in the different RRC signalling procedures outlined above.

Case Potential uplink RRC message Start recevng RRCConiiectkrnfleconfigurationComplete, group call OR ULhiforniationlransfer, new message Network chaiiges IJLlnformatkrnTraiisfer, flew message bearer St op receivrng RRCConnectionReconfigurationComplete.

group call OR U LhiIormationlransfer, new message

Table 1

[00117] Figure 2 illustrates the basic message sequence for the "direct" route from UE to eNB, where the message signalling uses only signalling using Access Stratum (AS) protocols, such as RRC messages. In certain embodiments, the uplink RRC message includes additional service information (e.g. Data Radio Bearer-DRB identifier, TMGI, etc.).

[00118] When providing the additional service information to the eNB, the UE provides a list identifying one or more unicast bearers, and information indicating the MBMS bearer service, i.e. the TMGI, GCS ID etc.. The UE could either always provide a full list; alternatively the UE may provide the value(s) to add and/or release (i.e. delta signalling).

[00119] The additional service information is included in one of: a new RRC message; an existing RRCConnectionReconfigurationComplete message, or a ULlnformationTransfer message.

[00120] Consider first the case where the network starts to transmit user data of an MBMS service/group call via a new unicast bearer. The additional service information is provided in either a new RRC message or an RRCConnectionReconfigurationComplete message. In case of network initiated establishment (and for either possibility': new or existing bearer), the UE only becomes aware of the bearer used when receiving DL data. It is nevertheless possible that the UE could infer (from the UL TFT, say) that any user data would be carried by a known bearer (i.e. when it is transmitted).

[00121] In network initiated cases where an existing bearer is used, ULlnformationTransfer might be available (in addition to the new RRC message or the existing RRCConnectionReconfigurationComplete message) provided the network initiates NAS procedure to modify UL TFT.

[00122] Similarly, in the case where the network alters the bearer used to transfer user data packets of an MBMS service/group call, a ULlnformationTransfer message might be available provided the network initiates NAS procedure to modify UL TFT.

Otherwise a new RRC message will be used to provide the additional service information.

[00123] Finally, consider the case where the network stops receiving user data of an MBMS service/group call via a unicast bearer. If the bearer is released, i.e. not used for transfer of any other user data, either a new RRC message or an existing RRCConnectionReconfigurationComplete message may be used to provide the additional service information.

[00124] If, on the other hand, the bearer remains, a ULinformationTransfer message might, in addition, be available to carry the additional service information to the eNB if network initiates NAS procedure to modify UL TFT.

[00125] When the UE detects (a change in) the bearer used to transfer user data of an MBMS service! group call, it initiates the procedure to inform the eNB. Examples of techniques for detection of the change in bearer include: * Receiving user data via a particular bearer (network initiated establishment with a change of bearer) * Receiving a reconfiguration message establishing a new bearer following the UE initiated bearer establishment. It should be noted that based on the Procedure Transaction Identity (P11) used at Non-Access Stratum (NAS), the UE can be sure this bearer is used for the group call, i.e. that the reconfiguration procedure is related to a preceding NAS Bearer Resource Modification request * Receiving an indication from upper layers to stop receipt of user data for an MBMS service/group call * Receiving an indication from upper layers, the indication reflecting an inference from the newly received UL TFT, such as by assuming that any user data in UL would be carried by the same bearer.

[00126] It is noted that the option to re-use an existing message (such as RRCConnectionReconflgurationComplete) applies in case the UE needs to transfer the concerned message in any case when providing the information, which depends on the particular scenario.

[00127] The following table (Table 2) illustrates how the contents of a number of different RRC messages in implementing certain embodiments of the invention.

Item Item Location

1 Field indicahng whether UB-EUTRA-Capabffity

UE supports (y/n) providrng the additional service information

2 Field (on/off) flag RRCCoimectionReconfiguration

indicating whether the UB is configured to provide the additional service information 3 Field/ IisL including for RRCConneclionReconfigurationCornplele, one or more unicast ULlnformationTransfer, bearers, the information new message identifying the MBMS bearer service e.g. the

____ TMGT __________________________

Table 2

[00128] The situation where each UE provides additional service information to the MME, which forwards it to the eNB is summarised in Table 3. The table shows exemplary candidate messages used in the different signalling procedures outlined above.

Case Polenlial uplinkNAS PoLential downlinksl ____________ message message Stan 1: Activate DedicaLed BPS 1: B-RAB Selup Response, receiving Beirer Context Accept, 2: B-RAB Modify Response, group call 2: Modify BPS Bearer 3: New message Context Accept, 3: New message ______________________________ Network 1: Modify BPS Bearer 1: B-RAB Modify Response, changes Context Accepl, 2: New message bearer 2: New message ______________________________ Stop 1: Deactivate Dedicated BPS 1: B-RAB Release Response, receiving Bearer Conlext Accepl, 2: B-RAB Modify Response, group call 2: Modify BPS Bearer 3: New message Context Accept, 3: New message ____________________________

Table 3

[00129] Figure 3 illustrates the basic message sequence for the route from UE to eNS via the MME, in other words the message signalling uses Non Access Stratum (NAS) protocols, such as messages between eNS and MME. In certain embodiments, the uplink NAS message includes additional service information (e.g. Data Radio Bearer-DRB identifier, TMGI, etc.).

[00130] When providing the additional service information in a NAS message, the UE provides a list identifying one or more unicast bearers (e.g. EPS bearer Ids), and information indicating the MBMS user service, e.g. the TMGI, GCS ID etc.. The UE could either always provide a full list; alternatively the UE may provide the value(s) to add and/or release (i.e. delta signalling).

[00131] The additional service information is included in either a ULlnformationTransfer message that includes a new NAS message or a ULlnformationTransfer message that includes a modified version of one of: the existing Activate Dedicated EPS Bearer Context Accept, a Modify EPS Bearer Context Accept message; or Deactivate Dedicated EPS Bearer Context Accept message.

[00132] Consider first the case where the network starts to receive user data of an MBMS service/group call via a unicast bearer. In case of network initiated establishment, UE only becomes aware of bearer used when receiving DL data (unless UE can infer something from the UL TFT, such as by assuming that any user data in UL would be carried by the same bearer).

[00133] In case of UE initiated establishment and when the UE can determine the newly established bearer related to the preceding request, it is possible to use a ULlnformationTransfer message that includes a modified version of Activate Dedicated EPS Bearer Context Accept. In other cases, when using a new bearer, a new NAS message is used.

[00134] In cases where an existing bearer is used, it may be possible to use a ULlnformationTransfer message that includes a modified version of Modify EPS Bearer Context Accept (e.g. if network initiates NAS procedure to modify UL TFT).

Otherwise a new NAS message is used.

[00135] Similarly, in the case where the network changes the bearer, a ULlnformationTransfer message that includes a modified version of Modify EPS Bearer Context Accept may be available (e.g. if network initiates NAS procedure to modify UL TFT). Otherwise a new NAS message is used.

[00136] Finally, consider the case where the network stops receiving user data of an MBMS service/group call via a unicast bearer. It is possible to use a ULlnformationTransfer message that includes a modified Deactivate Dedicated EPS Bearer Context Accept, provided the bearer is released, i.e. not used for transfer of any other user data.

[00137] If, on the other hand, the bearer remains, a ULinformationiransfer message that includes a modified Modify EPS Bearer Context Accept might, in addition, be available (e.g. if network initiates NAS procedure to modify UL lET). Otherwise a new NAS message is used.

[00138] When the UE detects (a change in) the bearer used to transfer user data of an MBMS service! group call, it initiates the procedure to inform the MME. Examples of techniques for detection of the change in bearer are analogous to those in the case where the UE informs the eNB directly. They include: * Receiving user data via a particular bearer (network initiated establishment with a change of bearer) * Receiving a reconfiguration message establishing a new bearer following the UE initiated bearer establishment. It should be noted that based on the Procedure Transaction Identity (P11) used at Non-Access Stratum (NAS), the UE can be sure this bearer is used for the group call, i.e. that the reconfiguration procedure is related to a preceding NAS Bearer Resource Modification request * Receiving an indication from upper layers to stop receipt of user data for an MBMS service!group call * Receiving an indication from upper layers, the indication reflecting an inference from the newly received UL TFT, such as by assuming that any user data in UL would be carried by the same bearer [00139] Itis noted that while the ULlnformationTransfer is directed to the eNB over the Uu interface, the eNB transparently forwards the NAS message to the MME. In turn, the MME forwards the (additional service) information provided by the UE to the eNB. The information forwarded by the MME includes a list including information identifying one or more unicast bearers (EPS Bearer Id), and information indicating the MBMS bearer service, e.g. the TMGI. The MME includes this information either in the ULlnformationTransfer message, including a new Si message, or a modified version of one of: an existing E-RAB Setup Response, E-RAB Modify Response or E-RAB Release Response message (as shown in the column headed Potential downlink Si message" of Table 3).

[00140] It is noted that the option to re-use an existing message applies in cases where the UE needs to transfer the concerned message regardless when providing the information, which depends on the particular scenario.

[00141] Figure 4 illustrates the signal flow during the setup of an MBMS E-RAB in

accordance with the MBMS specification.

[00142] In the first step, 401, of the setup of an MBMS E-RAB used for a multicast user service (e.g. group call), the CN (by means of the MME 140) indicates the TMGI.

[00143] In particular, the eNB 110 performs admission control using QoS information provided for each of the E-RABs to be setup (see Figure 5). Provided within E-RAB to be setup item are a number of information elements, lEs, including OCI, ARP, GBR QoS information (MBR & GBR for UL/DL). For MBMS bearers, the MME 140 additionally provides the TMGI.

[00144] The eNB 110 then transmits the RRC connection reconfiguration message, step 402 to the UE 100 including the details of the new bearer(s).

[00145] The UE 100 responds, step 403, by transmitting the RRC connection reconfiguration complete message.

[00146] Finally, the eNB 110 responds to the CN by returning the E-RAB Setup Response message to the MME 140, step 404.

[00147] Figure 5 illustrates certain steps in a conventional admission control scheme. The admission control step in Figure 4 uses this scheme.

[00148] Upon receiving a request to establish one or more new E-RAB5 or to increase the resources used by an existing E-RAB, the eNB 110 performs the following steps: [00149] Firstly the eNB 110 estimates whether there are any remaining resources that can be allocated to the new or modified bearer, step 501. Note that the bearer may be modified when an additional service is mapped to that bearer.

[00150] The eNB 110 then estimates the required additional resources, step 502, for the new or modified bearer. It does so by estimating the additional radio resource usage, taking into account the QoS information. The QoS information includes parameters indicating the type of service (QCI) and may additionally include parameters indicating a bitrate to be guaranteed (GBR) and/or a maximum bitrate (MBR).

[00151] In the estimation step, the eNB 110 may take into account statistical multiplexing gains. In cases where a new bearer is to be used for a group call, there will be no multiplexing gains with other UE5 engaged in the same call as all participating UE5 should receive the same user data at substantially the same time. There will however be multiplexing gains between different group calls, as it is unlikely that the user data (typically infrequent in group calls) will be transmitted at the same time.

[00152] At step 503, it is determined whether sufficient resources are available. In cases where the required additional resources are not available, the eNB 110 may either deny the E-RAB establishmeni/modification (step 506), or modify the allocation of some other E-RAB5 (i.e. having a lower Allocation Retention Priority).

[00153] Where resources are available, the eNB reserves the required resources for the new bearer(s), step 505.; [00154] Figure 6 illustrates the signal flow during handover between a Source eNB (SeNB) 610 and a Target eNB (TeNB) 620. In handover events between eNBs, the UE 100 may assist the handover by issuing measurement reports, step 601.

[00155] Upon initiating handover of a UE receiving a multicast user service, the source eNB 610 provides information including the TMGI to the target eNB 620 during handover preparation, step 602. This handover request is acknowledged, step 603.

[00156] The target eNS 620 performs admission control as outlined in Figure 5.

Admission control here, may utilise the service information, such as the TMGI, to identify bearers for the multicast user service in the target cell.

[00157] The source eNB 610 commands the UE 110 to perform handover to the target cell, using existing procedure (UE behaviour is not affected), step 604. This existing procedure makes use of the Random Access Channel (RACH), step 605.

[00158] When the existing procedure is complete, the UE acknowledges completion, step 606.

[00159] Figure 7 illustrates the signal flow used in providing network initiated bearer establishment and corresponds to the according to Figure 5.4.1 of 3GPP TS 23.401: whereas Figure 8 illustrates the signal flow used in providing UE initiated bearer establishment and corresponds to Figure 5.4.5 of 3GPP TS 23.401.

[00160] It will be appreciated that embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention. Accordingly, embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium including a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.

[00161] Throughout the description and claims of this specification, the words "comprise" and "contain" and variations of them mean "including but not limited to", and they are not intended to (and do not) exclude other components, integers or steps.

Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.

[00162] Features, integers or characteristics described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. It will be also be appreciated that, throughout the description and claims of this specification, language in the general form of "X for Y" (where Y is some action, activity or step and X is some means for carrying out that action, activity or step) encompasses means X adapted or arranged specifically, but not exclusively, to do Y. [00163] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[00164] The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

[00165] Thus, whilst the embodiments described above relate primarily to release 12 (REL-12) and beyond of the Evolved Universal Terrestrial Radio Access (E-UTRA).

However, the reader will readily appreciate that application of the solutions described above may equally be extended to other releases of 3GPP standards and indeed to other (radio access) systems without significant adaptation.

Claims (24)

1. CLAIMS: 1. A method of managing the delivery of a multicast user service to at least one user equipment, UE, in a wireless communication network, the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the method comprising: detecting a change in the associated bearer configuration; and receiving, at a base station, a message including service information identifying the multicast user service, the message being generated in accordance with the associated bearer configuration.
2. 2. A method as claimed in claim 1, wherein the service information comprises at least one of multicast user service information; multicast bearer service information; or information identifying downlink user data packets.
3. 3. A method as claimed in claim 2, wherein the multicast bearer service information includes an identity allocated to multicast bearers to be used for the multicast user service.
4. 4. A method as claimed in claim 2 or claim 3, wherein the multicast user service information includes one or more identities allocated to the multicast user service itself.
5. 5. A method as claimed in any one of claims 1 to 4, further comprising: upon receiving a request for admission of a new or modified unicast bearer, calculating a predicted system load; and, adjusting the predicted system load in accordance with which multicast user service the unicast bearer is associated.
6. 6. A method as claimed in claim 5, wherein the predicted system load is adjusted by changing a weight factor to reflect the traffic characteristics of multicast user services.
7. 7. A method as claimed in claim 6, wherein the predicted system load is further adjusted by changing the weighting factor to reflect statistical multiplexing gains, a lower load being estimated for unicast bearers associated with the delivery of multicast user services that are not already delivered via a unicast bearer.
8. 8. A method as claimed in any one of claims ito 7, further comprising: for each UE, determining from the service information, whether the UE is receiving a multicast user service and, if so, which particular multicast user service is being received; calculating from the results of the determination step, the number of UE5 receiving a given multicast user service over a unicast bearer; determining whether that number exceeds a predetermined threshold; and adjusting the associated bearer configuration for at least one UE receiving the given multicast user service when the number of UE5 receiving the given multicast user service over a unicast bearer exceeds the predetermined threshold.
9. 9. A method as claimed in any preceding claim, wherein the associated bearer configuration includes, for a given UE, a multicast bearer and a suspended unicast bearer.
10. 10. A method as claimed in claim 8, wherein the change in the at least one associated bearer configuration arises from a handover of the given UE to the base station, the method further comprising resuming transmission of multicast user service data over the suspended unicast bearer to the given UE.
11. 11. A method as claimed in any preceding claim, wherein the associated bearer configuration includes, for a given UE, a unicast bearer, the method further including requesting IP multicast from a multicast service provider.
12. 12. A method as claimed in any preceding claim, wherein a multicast transmission synchronisation protocol is specified for the delivery of multicast user services over multicast bearers, and wherein the associated bearer configuration includes, for a given UE, a unicast bearer, the method further comprising applying the multicast transmission synchronisation protocol to the transmission timings of the unicast bearer, thereby substantially synchronising the unicast bearer transmission timings with the transmission timings used by multicast bearers.
13. 13. A method as claimed in any preceding claim, wherein the associated bearer configuration includes, for a given UE, a unicast bearer, the method further comprising receiving multicast user service data over IP multicast from a multicast service provider and delivering the multicast user service data to the given UE over the unicast bearer.
14. 14. A method as claimed in any preceding claim, wherein the associated bearer configuration includes, for a given UE, a unicast bearer, and wherein the application layer encryption! ciphering applied to the multicast user service data for delivery to the UE over the unicast bearer is the same as that used in the delivery of the multicast user service data over IP multicast.
15. 15. A method as claimed in any preceding claim, wherein the associated bearer configuration includes, for a given UE, a unicast bearer, and wherein the unicast bearer carries multicast user service data exclusively for the multicast user service.
16. 16. A method as claimed in any one of the preceding claims, wherein the service information is received from the UE at the base station using access stratum, AS, signalling.
17. 17. A method as claimed in any one of claims ito 15, wherein a given UE is handed over from a source base station to the base station and wherein the service information is received from the UE at the source base station and forwarded to the base station.
18. 18. A method as claimed in any one of claims 1 to 15, wherein the service information is received from the UE at the base station via an MME using non-access stratum, NAS, signalling.
19. 19. A base station in a wireless communication network, adapted to manage the delivery of a multicast user service to at least one user equipment, UE, , the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the base station comprising: a receiver adapted to receive a message including service information identifying the multicast user service, the message being generated in accordance with the associated bearer configuration; and a processor adapted to process the received information to determine characteristics of the multicast user service.
20. 20. A user equipment, UE, for receiving a multicast user service via a base station in a wireless communication network, the multicast user service being delivered via at least one bearer in accordance with an associated bearer configuration, the UE comprising: a receiver adapted to receive user data packets and/or messages for the multicast user service over the at least one bearer; a processor adapted to: detect a change in the associated bearer configuration; process the received user data packets and/or messages to obtain service information identifying the multicast user service; and to generate a message including said service information identifying the multicast user service; and a transmitter adapted to transmit the message to the base station.
21. 21. A method of managing the delivery of a multicast user service substantially as described herein, with reference to Figures 1-3.
22. 22. A base station substantially as described herein, with reference to Figures 1-3.
23. 23. A user equipment substantially as described herein, with reference to Figures 1-3.
24. 24. A computer program comprising instructions arranged, when executed, to implement the method of any one of claims ito 18 or 21.