Group Communication over LTE eMBMS
Claim Score by NHIP
Abstract
A method of supporting group communication over LTE MBMS is provided. A UE first establishes a unicast Evolved Packet Service (EPS) bearer in an LTE network for group communication. The UE belongs to a communication group having a communication group ID. The UE receives access information from the network for monitoring downlink (DL) multicast traffic of the DL group communication based on a multicast decision. The UE is then ready for monitoring a multicast Multimedia Broadcast Multicast Service (MBMS) bearer for receiving the DL multicast traffic. The multicast MBMS bearer is associated with a Temporary Mobile Group Identifier (TMGI), and wherein the TMGI is associated with the communication group ID. In one embodiment, the access information comprises mapping information between the TMGI and the communication group ID.
Term
7.7 yearsto projected expiry
Projected expiry 15 June 2034, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
21 claims: 2 independent, 19 dependent
- 1Broadest claimClaim Score 54, average(NHIP)A method comprising:establishing a unicast Evolved Packet Service (EPS) bearer by a user equipment (UE) in a Long-Term Evolution (LTE) network for group communication, wherein the UE belongs to a communication group having a communication group ID;receiving access information from the network for monitoring downlink (DL) multicast traffic of the DL group communication based on a multicast decision;and monitoring a multicast Multimedia Broadcast Multicast Service (MBMS) bearer for receiving the DL multicast traffic, wherein the multicast MBMS bearer is associated with a Temporary Mobile Group Identifier (TMGI), and wherein the TMGI is associated with the communication group ID.
- 19A user equipment (UE), comprising:a configuration module that establishes a unicast Evolved Packet Service (EPS) bearer in a Long-Term Evolution (LTE) network, wherein the UE belongs to a communication group having a communication group ID;a receiver that receives access information from the network for monitoring downlink (DL) multicast traffic of the communication group based on a multicast decision;and a group communication module that monitors a multicast Multimedia Broadcast Multicast Service (MBMS) bearer for receiving the DL group communication, wherein the multicast MBMS bearer is associated with a Temporary Mobile Group Identifier (TMGI), and wherein the TMGI is associated with the communication group ID.
Independent claims2
114 paragraphs in 6 sections, as filed
CROSS REFERENCE TO RELATED APPLICATIONS
p-0002This application claims priority under 35 U.S.C. §119 from U.S. Provisional Application No. 61/804,392, entitled “Method for Handover Robustness for PoC DL Traffic Multicasting”, filed on Mar. 22, 2013; U.S. Provisional Application No. 61/804,398, entitled “Method for RRC Idle Mode Reception for PoC DL Traffic Multicasting”, filed on Mar. 22, 2013; U.S. Provisional Application No. 61/804,402, entitled “Method for Radio Resource-Efficient Transmission of PoC DL Traffic”, filed on Mar. 22, 2013; U.S. Provisional Application No. 61/804,405, entitled “Method for Supporting PoC DL Traffic Multicasting”, filed on Mar. 22, 2013, the subject matter of which is incorporated herein by reference.
TECHNICAL FIELD
p-0003The disclosed embodiments relate to group communication over LTE evolved Multimedia Broadcast and Multicast Service (eMBMS).
BACKGROUND
p-0004A Long-Term Evolution (LTE) system offers high peak data rates, low latency, improved system capacity, and low operating cost resulting from simple network architecture. An LTE system also provides seamless integration to older wireless networks, such as Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), and Universal Mobile Telecommunication System (UMTS). In LTE systems, an evolved universal terrestrial radio access network (E-UTRAN) includes a plurality of evolved Node-Bs (eNBs) communicating with a plurality of mobile stations, referred as user equipments (UEs). Over the years, enhancements to LTE systems are considered by the third Generation Partnership Project (3GPP) so that an LTE Advanced (LTE-A) system can meet or exceed International Mobile Telecommunications Advanced (IMT-Advanced) fourth generation (4G) standard.
p-0005Multimedia Broadcast and Multicast Service (MBMS) is a broadcasting service offered via existing GSM and UMTS cellular networks. Recently, evolved MBMS (e-MBMS) has been introduced in the LTE specification for broadcasting or multicasting TV, films, and other information such as overnight transmission of newspapers in a digital form. To facilitate MBMS in LTE systems, a multicast control channel (MCCH) is used for the transmission of MBMS control information in each MBMS Single Frequency Network (MBSFN) area, and a multicast traffic channel (MTCH) is used for the transmission of user traffic to UEs receiving MBMS data packets. MBMS has the major benefit that the network infrastructure already exists for mobile network operators and that deployment can be cost effective compared with building a new network for the service. The broadcast capability enables to reach unlimited number of users with constant network load. The broadcast capability also enables the possibility to broadcast information simultaneously to many cellular subscribers, such as emergency alerts.
p-0006Push-to-talk (PTT) is a type of group communication method of having conversations or talking on half-duplex communication lines, including two-way radio, using a momentary button to switch from voice reception mode to transmit mode. Push to Talk over Cellular (PoC) is a service option for a cellular network to offer mobile subscribers a walkie-talkie type of group communication with unlimited range. A significant advantage of PoC/PTT is the ability for a single mobile user to reach an active talk group with a single button press. The mobile user needs not to make several telephone calls to coordinate the communication group. PoC/PTT has been commonly based on 2.5G or 3G packet-switched networks and uses, for example, SIP and RTP/RTCP protocols. The Open Mobile Alliance (OMA) PoC specifies a PoC server for user management to enable PoC, based on VoIP and relied on IP multimedia Subsystem (IMS) as a service enabler.
p-0007PoC downlink (DL) traffic can be very bursty. In case of a group call, one talks and multiple users listen. Current PoC service realizes one-to-many communication via multi-unicasting. The traffic from one speaker is duplicated for the same number of times as the number of total recipients, i.e., many DL transmissions in response to one UL transmission. For large group size, bursty traffic can cause congestion in the core network. If the number of UEs of a group residing in a cell is big, then bursty traffic can cause network capacity to drop. Furthermore, the current SIP-based PoC service requires long call setup time. With SIP compression, call setup delay can be reduced to ˜1-2 s level. However, such setup delay is still longer than the <300 ms level recommended for public safety applications.
p-0008Therefore, it is beneficial to have more efficient data distribution scheme to ease the loading in the core network, and to have more efficient resource utilization to ease the bursty requirement of radio resource. PoC DL traffic multicasting is used to indicate the general idea of multicast distribution of the PoC DL traffic in the core network, in RAN, or in both the core network and RAN. With PoC DL traffic multicasting, mulitiple UEs can receive PoC DL traffic from the same physical transmission. Within the core network, the same packet is addressed to multiple eNBs via multicast address (PoC DL traffic multicasting in the core network). For efficient radio transmission, multiple UEs can monitor the same DL assignment in RAN (PoC DL traffic multicasting in RAN). It is also beneficial to enable idle mode PoC DL traffic reception from power saving and call setup latency perspectives.
p-0009Another important feature of a mobile wireless system such as LTE is the support for seamless mobility across eNBs and the entire network. Fast and seamless handover (HO) is particularly important for delay-sensitive services such as PoC. For traffic multicasting, PoC group mobility management is required in the core network so that PoC packet can be properly routed to relevant eNBs. For example, UE position to the granularity of cell is required. Otherwise, PoC multicast bearer cannot be handed over to a new target cell.
p-0010In the present invention, it is proposed to utilize MBMS in LTE/LTE-A systems to support PoC DL traffic multicasting, to enable efficient radio resource transmission, to reduce call setup latency via idle mode reception, and to provide PoC group mobility management to maintain PoC service continuity.
SUMMARY
p-0011A method of supporting group communication over LTE MBMS is provided. A UE first establishes a unicast Evolved Packet Service (EPS) bearer in an LTE network for group communication. The UE belongs to a communication group having a communication group ID. The UE receives access information from the network for monitoring downlink (DL) multicast traffic of the DL group communication based on a multicast decision. The UE is then ready for monitoring a multicast Multimedia Broadcast Multicast Service (MBMS) bearer for receiving the DL multicast traffic. The multicast MBMS bearer is associated with a Temporary Mobile Group Identifier (TMGI), and wherein the TMGI is associated with the communication group ID. In one embodiment, the access information comprises mapping information between the TMGI and the communication group ID.
p-0012In a first novel aspect, PoC traffic multicasting is supported to multicast distribution of the POC DL traffic in the core network, in RAN, or in both the core network and RAN. With PoC DL traffic multicasting, a UE can receive PoC DL traffic from the same physical transmission. Within the core network, the same packet can be addressed to multiple eNBs via a multicast address. For radio transmission, multiple UEs are enabled to monitor the same DL assignment in RAN level.
p-0013In a second novel aspect, more efficient radio resource utilization can be achieved by PoC DL traffic multicasting in RAN level. Radio resource efficient transmission of PoC DL traffic can be achieved by sharing radio resources using cell-broadcasting scheme or in cell-multicasting scheme. Cell-broadcasting scheme refers to the use of MBSFN subframe exclusively for PoC DL traffic. Cell-multicasting scheme refers to the dynamic scheduling of PDSCH for multiple UEs by addressing a corresponding PDCCH to a group radio identifier. Furthermore, multiple PoC UEs can share the same PDCCH to reduce control channel loading for PoC DL traffic scheduling.
p-0014In a third novel aspect, long service interruption of PoC DL traffic multicasting during handover is avoided. In one embodiment, a smaller PoC DL multicasting radio coverage is applied for early termination of multicast distribution at cell edge. Furthermore, PoC service continuity is maintained by selecting proper target cell in handover case. In one embodiment, a UE sends an indication of preferred target cells to the network before performing a handover procedure and thereby maintaining multicast service continuity of PoC service.
p-0015In a fourth novel aspect, RRC_IDLE mode reception is supported for PoC DL traffic delivery. PoC DL traffic is delivered via EPS MBMS service in the core network using MBMS broadcasting mode. PoC UEs in RRC_IDLE mode are configured to monitor PoC traffic on MBMS bearers for power saving and reduced call setup latency. Cell broadcasting using LTE MBSM radio transmission and cell multicasting using LTE dynamic scheduling radio transmission may be used for RRC_IDLE mode reception.
p-0016Other embodiments and advantages are described in the detailed description below. This summary does not purport to define the invention. The invention is defined by the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
p-0017The accompanying drawings, where like numerals indicate like components, illustrate embodiments of the invention.
p-0018<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a procedure of supporting group communication using MBMS in an LTE network in accordance with one novel aspect.
p-0019<figref idrefs="DRAWINGS">FIG. 2</figref> is a simplified block diagram of a user equipment in accordance with one novel aspect.
p-0020<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an architecture of an LTE system supporting group communication via MBMS broadcasting mode and using PoC server for group mobility management in accordance with one novel aspect.
p-0021<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a PoC server for PoC group mobility management and PoC multicast decision.
p-0022<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a PoC server making multicast decision for PoC traffic.
p-0023<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates different embodiments of UE reporting MBMS capability to the network.
p-0024<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates different embodiments of UE reporting MBMS reception status to the network.
p-0025<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates one embodiment of establishing a unicast EPS bearer for UL PoC traffic.
p-0026<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates another embodiment of establishing a unicast EPS bearer for UL PoC traffic.
p-0027<figref idrefs="DRAWINGS">FIG. 10A</figref> illustrates one embodiment of reactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS broadcast mode.
p-0028<figref idrefs="DRAWINGS">FIG. 10B</figref> illustrates one embodiment of proactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS broadcast mode.
p-0029<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates an architecture of an LTE system supporting group communication via MBMS multicasting mode and using MBMS gateway for group mobility management in accordance with one novel aspect.
p-0030<figref idrefs="DRAWINGS">FIG. 12A</figref> illustrates one embodiment of reactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS multicast mode.
p-0031<figref idrefs="DRAWINGS">FIG. 12B</figref> illustrates one embodiment of proactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS multicast mode.
p-0032<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow chart of supporting PoC multicast traffic using MBMS in LTE network in accordance with one novel aspect.
p-0033<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates cell broadcasting radio transmission method for PoC service.
p-0034<figref idrefs="DRAWINGS">FIG. 15</figref> illustrates one embodiment of cell broadcasting radio transmission.
p-0035<figref idrefs="DRAWINGS">FIG. 16</figref> illustrates cell multicasting radio transmission method for PoC service.
p-0036<figref idrefs="DRAWINGS">FIG. 17</figref> illustrates one embodiment of cell multicasting radio transmission.
p-0037<figref idrefs="DRAWINGS">FIG. 18</figref> illustrates a method of sharing PDCCH among PoC UEs for PoC DL traffic scheduling.
p-0038<figref idrefs="DRAWINGS">FIG. 19</figref> is a flow chart of radio resource efficient transmission for PoC multicast traffic in accordance with one novel aspect.
p-0039<figref idrefs="DRAWINGS">FIG. 20</figref> illustrates avoiding long service interruption of PoC traffic multicasting during handover.
p-0040<figref idrefs="DRAWINGS">FIG. 21</figref> illustrates one embodiment of early termination of PoC multicast traffic.
p-0041<figref idrefs="DRAWINGS">FIG. 22</figref> illustrates one embodiment of supporting PoC service continuity.
p-0042<figref idrefs="DRAWINGS">FIG. 23</figref> is a flow chart of a method of supporting PoC service continuity in accordance with one novel aspect.
p-0043<figref idrefs="DRAWINGS">FIG. 24</figref> illustrates one embodiment of supporting idle mode reception of PoC traffic.
p-0044<figref idrefs="DRAWINGS">FIG. 25</figref> illustrates one embodiment of monitoring PoC traffic in RRC_IDLE mode.
p-0045<figref idrefs="DRAWINGS">FIG. 26</figref> is a flow chart of a method of supporting idle mode reception for PoC traffic in accordance with one novel aspect.
DETAILED DESCRIPTION
p-0046Reference will now be made in detail to some embodiments of the invention, examples of which are illustrated in the accompanying drawings.
p-0047<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a procedure of supporting group communication using Evolved Multimedia Broadcast and Multicast Service (e-MBMS) service in a mobile cellular communication network in accordance with one novel aspect. The network comprises a user equipment UE <b>101</b>, a radio access network RAN <b>102</b> comprising a plurality of eNBs, a mobility management entity MME <b>103</b>, an MBMS gateway (MBMS-GW) <b>104</b>, a Broadcast Multicast Service Center (BM-SC) <b>105</b>, and a Push to Talk over Cellular (PoC) server <b>106</b>. PoC is a type of group communication service that provides the ability for a single mobile user to reach an active talk group with a single button press. In the following discussion, PoC service is used as an example representing for group communication, and other types of group communication applications, such as data exchange, video sharing, etc. are applicable.
p-0048The Open Mobile Alliance (OMA) PoC specifies a PoC server for user management to enable PoC, based on VoIP and relied on IP multimedia Subsystem (IMS) as a service enabler. PoC users register with the IMS core before using the PoC service. During IMS registration, a UE binds its public user IDs (SIP address) to the IP address at registration, and IMS uses the information for routing the voice call. In OMA IMS-based PoC, Session Initiation Protocol (SIP) is used as a signaling protocol for PoC session setup, Real Time Transport Protocol (RTP) is used for voice data transfer, and RTP Control Protocol (RTCP) is used for floor control.
p-0049Multimedia Broadcast and Multicast Service (MBMS) is a broadcasting service offered for broadcasting or multicasting information in digital form. By design, MBMS service in LTE is integrated with the IMS service based on SIP, similar to PoC service. In MBMS, the BM-SC provides functions for MBMS content provider for MBMS user service provisioning and delivery. As a result, OMA PoC can reuse the functions for PoC traffic delivery. MBMS provides two modes for content distribution. In MBMS broadcast mode, content is delivered to UEs within a predefined area (e.g., Multicast-Broadcast Single-Frequency Network (MBSFN) area). Neither subscription service nor UE mobility management is provided. In EPS, multicast distribution from BM-SC to eNBs is supported by multicast address. In MBMS multicast mode, content is delivered to specific UEs. UE subscription and UE mobility management is required. Multicast distribution from BM-SC to subscribed UEs is supported by multicast address, and routing within the core network can be achieved by unicast distribution. In general, MBMS bearer should be reused for PoC DL traffic multicasting for applying common security among members in a communication group. MBMS data is encrypted in higher layer, but not in RAN, and unicast bearers are encrypted for individual UEs. Currently, EPS supports MBMS broadcast mode only, while GPRS supports both MBMS broadcast and multicast mode.
p-0050In accordance with one novel aspect, PoC DL traffic multicasting is supported for the multicast distribution of PoC DL traffic in the core network and/or in RAN for efficient radio usage. From UE perspective, to support PoC traffic multicasting, two bearers are established for each individual UE. As illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>, in step <b>111</b>, UE <b>101</b> joins a communication group. For example, UE <b>101</b> is interested in PoC service and joins a PoC group. The PoC groups can be semi-statically formed by a central controller in advance, or distributely formed by UEs via a user interface. Each PoC group is assigned with a PoC group ID. In step <b>121</b>, UE <b>101</b> establishes a unicast EPS bearer for group communication. The unicast bearer is at least for UL group communication. For example, UE <b>101</b> may indicates its group communication interest when requesting the unicast bearer, and acquires a Temporary Mobile Group Identifier (TMGI) associated with a multicast MBMS bearer for receiving group traffic. In step <b>131</b>, the multicast MBMS bearer is established when the PoC server or the BM-SC makes a multicast decision for the group communication. The multicast bearer, when appropriate, is used for DL group communication. Alternatively, the MBMS bearer is pre-configured. As depicted in step <b>130</b>, the pre-configured MBMS bearer occurs before the unicast bearer establishment in step <b>121</b>. In step <b>141</b>, UE <b>101</b> applies MBMS bearer configuration and sets up RAN resource for receiving DL group communication traffic.
p-0051<figref idrefs="DRAWINGS">FIG. 2</figref> is a simplified block diagram of a user equipment UE <b>201</b> in accordance with one novel aspect. UE <b>201</b> comprises memory <b>211</b>, a processor <b>212</b>, a radio frequency (RF) module <b>213</b> coupled to antenna <b>214</b>, a protocol stack module <b>215</b> supporting various protocol layers including NAS <b>216</b>, RRC <b>217</b>, RLC <b>218</b>, MAC <b>219</b> and PHY <b>220</b>, and an application layer <b>221</b> including a configuration module <b>222</b>, a measurement module <b>223</b>, a handover module <b>224</b>, an MBMS control module <b>225</b>, a SIP module <b>226</b>, and a group communication module <b>227</b>. The various modules are function modules and may be implemented by software, firmware, hardware, or any combination thereof. The function modules, when executed by processor <b>212</b>, interwork with each other to allow UE <b>201</b> to perform various functionalities accordingly.
p-0052For example, configuration module <b>222</b> applies configuration information received from the network (e.g., for EPS bearer and MBMS bearer configuration) to establish unicast and multicast bearers, measurement module <b>223</b> performs radio signal measurements and reporting, HO module <b>224</b> performs handover or cell reselection procedure for UE mobility, MBMS control module <b>225</b> reports MBMS capability and reception/interest status to the network to support for making multicast decision and for maintaining MBMS service continuity with less MBMS service interruption. SIP module <b>226</b> applies the standard SIP signaling protocol to setup session for group communication service. Group communication module <b>227</b> monitors a multicast MBMS bearer for receiving DL group traffic and de-multiplexes the DL traffic received either from the multicast MBMS bearer or from the unicast EPS bearer into the same group communication application.
p-0053In accordance with one novel aspect, PoC traffic multicasting is supported to multicast distribution of the POC DL traffic in the core network, in RAN, or in both. With PoC DL traffic multicasting, multiple UEs can receive PoC DL traffic from the same physical transmission. Within the core network, the same packet can be addressed to multiple eNBs via a multicast address. For radio transmission, multiple UEs are enabled to monitor the same DL assignment in RAN level. For PoC traffic multicasting, a mobility management entity needs to track the position of relevant UEs, i.e., mobility management for PoC group UEs. The core network needs to know UE positions (e.g., to the granularity of cell) so that the PoC DL traffic can be routed to the eNBs where the UE resides. The mobility management entity needs to know the PoC UE count for deciding radio unicast or multicast.
p-0054The support of PoC traffic multicasting and PoC group mobility management can be achieved using different MBMS delivery modes and management entities. In a first scheme, group mobility management is based on OMA PoC server, and traffic delivery in EPC is based on MBMS broadcast mode (BM) for efficient resource usage. Since MBMS BM is already supported in EPS, this scheme minimizes changes to EPC. In a second scheme, group mobility management is in the core network and traffic delivery in EPC is based on MBMS multicast mode (MM) for efficient resource usage. Although MBMS MM is only supported in GPRS (not supported in EPS currently), this scheme is more sensible because mobility support is in the core network. Different schemes are now described below with details and accompanying drawings.
Group Mobility Support for PoC DL Multicast
p-0055<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an architecture of an LTE system <b>300</b> supporting group communication via MBMS broadcasting mode and using PoC server for group mobility management in accordance with one novel aspect. LTE system <b>300</b> comprises an application network, an evolved packet core (EPC) network, and a radio access network (RAN). The application network comprises a content provider <b>301</b>, a PoC server <b>302</b>, a Broadcast Multicast Service Center (BM-SC) <b>303</b>, and an MBMS gateway (MBMS-GW) <b>304</b> for MBMS control plane and user plane (CP&UP). The EPC network comprises a packet data network gateway (PDN-GW) <b>311</b>, a serving gateway (S-GW) <b>312</b>, a mobility management entity (MME) <b>313</b>, and a multi-cell/multicast coordination entity (MCE) <b>314</b>. The radio access network, for example, is an E-UTRAN that comprises two evolved Node-Bs eNB <b>321</b> and eNB <b>322</b>, and a plurality of user equipments UEs <b>331</b>-<b>334</b>. In the example of <figref idrefs="DRAWINGS">FIG. 3</figref>, UE <b>331</b> is served by eNB <b>321</b>, and UEs <b>332</b>-<b>334</b> are served by eNB <b>322</b>.
p-0056In MBMS broadcast mode, BM-SC <b>303</b> is an entry point for content provider for MBMS transmissions. BM-SC <b>303</b> can use either MBMS bearer or EPS bearer to broadcast MBMS packets to eNB transmitting a corresponding MBMS service. In case of EPS bearer, MBMS services follow normal unicast route. In case of MBMS bearer, MBMS services go through MBMS-GW <b>304</b>. MBMS-GW <b>304</b> is a logical entity that may be standalone or co-located with BM-SC/S-GW/PDN-GW. MBMS-GW <b>304</b> provides MBMS bearer reference point for Control Plane (CP) and User Plane (UP) (i.e., SGmb and SG-imb). U-plane is through M1 to eNBs for IP multicast distribution within a single PLMN. C-plane is supported by MME <b>314</b> for EUTRAN access. MBMS bearer session control for accessing EUTRAN is supported by MME <b>313</b>. IP multicast address is allocated to eNBs through MME <b>313</b> and the multicast group is provided by BM-SC <b>303</b>. MCE <b>314</b> provides session management signaling, and coordinates radio resource configuration of eNBs in an MBMS Single Frequency Network (MBSFN) area, e.g., Physical resource blocks (PRBs) and Modulation and coding scheme (MCS). MCE <b>314</b> is a logical entity, which can be standalone or be part of another network element such as inside an eNB.
p-0057When a UE (e.g., UE <b>331</b>) receives a specific MBMS service, MBMS data packets (U-Plane) are transmitted from content provider <b>301</b>, through BM-SC <b>303</b>, through MBMS-GW <b>304</b>, through eNB <b>321</b>, and then to UE <b>331</b>. On the other hand, MBMS control information (C-Plane) is communicated between PDN-GW <b>311</b> and UE <b>331</b> via MME <b>313</b>, MCE <b>314</b> and eNB <b>321</b>. As illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>, eNB <b>321</b> and eNB <b>322</b> are connected to MBMS-GW <b>304</b> via a pure user plane interface M1. In addition to the M1 interface, two control plane interfaces M2 and M3 are defined in LTE system <b>300</b>. The application part on the M2 interface conveys radio configuration information between the eNBs and MCE <b>314</b>, and the application part on the M3 interface performs MBMS session control signaling on MBMS bearer level between MCE <b>314</b> and MME <b>313</b>.
p-0058In accordance with one novel aspect, the EPS MBMS service is reused for broadcasting PoC DL traffic in selected cells. When using PoC server <b>301</b> as the entity for PoC group mobility management, PoC traffic is delivered in the core network via MBMS broadcast mode to minimize changes to the EPC. For each individual UE, two bearers are established. A first bearer is a unicast EPS bearer used at least for PoC UL traffic, and a second bearer is a multicast MBMS bearer, when appropriate, used for PoC DL traffic. The MBMS bearer can be established proactively (pre-configured) or reactively (dynamically). To support PoC traffic multicasting, the PoC server <b>301</b> makes multicast decision and decides the use of the MBMS bearer for a subset of a group of PoC UEs. For example, for big-enough intra-cell PoC group UEs, the MBMS bearer is used for PoC DL traffic.
p-0059<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a PoC server <b>401</b> for PoC group mobility management and for making multicast decision for PoC DL traffic. PoC group mobility management involves managing the location of PoC group UEs (to the granularity of cell) and managing the mobility status of PoC group UEs (e.g., handover rate). As illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref>, the PoC server takes input of UE position information and UE channel reliability information to perform certain mapping function for group management. The UE position information and UE channel reliability information can be reported to the network periodically, or upon handover or cell reselection, or can be retrieved by the PoC server from MME. Based on the UE position, the PoC server is able to identify the corresponding PoC group and PoC group members and its location.
p-0060In one embodiment, multicast decision is made by a logical node, e.g., in the PoC server. The logical node can constantly/periodically examine all the factors and make decisions at various time resolution. The multicast decision is in general based on at least one of the following factors/criteria: the number of in-cell PoC group members, the number of PoC groups within a cell, UE mobility (handover rate) information, overhead analysis (based on ROHC, repetitive transmission scheme, and limited MCS selection), and the channel reliability indication. Channel reliability information comprises, for example, packet loss rate. It indicates the fitness for multicasting. The channel reliability indication thus can be used to remove or to include certain in-cell PoC UEs out or into an existing multicast group. For example, if the packet loss rate of a UE is high, then the PoC server can terminate multicasting traffic for that UE. The channel reliability indication also indicates that the design of radio parameters does not need to assume cell border. UE can terminate the multicast bearer for PoC multicasting before handover if UE mobility tracking is not supported in the core network.
p-0061<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a PoC server making multicast decision for PoC DL multicast traffic. A multicast group is defined as a subset of PoC UEs from the same PoC group for PoC traffic multicasting. Multicast decision is made for the subset of PoC UEs within the PoC group. As illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, a PoC group A consists of PoC UEs in cells 1-5, and a multicast group #i consists of PoC UEs in cells 1-2. Based on the multicast group, the relevant PoC traffic is delivered to the relevant eNBs based on MBMS service. The delivery to the relevant eNBs can be realized in a multi-unicast or multicast manner. The multicast or multi-unicast decision can be further optimized. For example, multicast group #i can consist of PoC UE clusters from different eNBs (e.g., cell 1 and cell 2), and in-cell PoC UEs in a large PoC group can be clustered into different multicast groups.
p-0062An MBSFN area (e.g., MBSFN area <b>500</b>) can be used to define relevant eNBs corresponding to the multicast group (e.g., group #i). For example, an MBSFN area can be used to differentiate different multicast groups if their geographical coverage areas are not the same. However, if multiple PoC groups whose geographical coverage is the same, then different multicast groups of those PoC groups can be differentiated by TMGI while they share the same MBSFN area ID. Typically, one MBSFN area corresponds to one multicast group and one MBSFN consists of only one cell/eNB. For large PoC groups, however, it is possible to have a few eNBs in an MBSFN area. Currently, the MBSFN area ID are only 0-255, which is not enough. It is proposed that the MBSFN area ID is extended to support more multicast groups. Alternatively, the MBSFN area ID can be managed dynamically, but this is in conflict with the current O&M principles.
p-0063In addition to UE position information and UE channel reliability information, UE MBMS capability information and UE MBMS reception status information can also be used to assist PoC group mobility management and multicast decision.
p-0064<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates different embodiments of UE reporting MBMS capability to the network. In a first embodiment illustrated in the left half of <figref idrefs="DRAWINGS">FIG. 6</figref>, in step <b>611</b>, UE <b>601</b> receives UE capability enquiry from the network. In step <b>612</b>, UE <b>601</b> transmits UE capability information to the network. The UE capability information comprises an RRC feature group indicator, indicating the MBMS capability supported by the UE. In a second embodiment illustrated in the right half of <figref idrefs="DRAWINGS">FIG. 6</figref>, MBMS capability is reported in EMM (EPS Mobility Management) message. In step <b>621</b>, UE <b>601</b> transmits an RRC connection request to the network. In step <b>622</b>, UE <b>601</b> receives an RRC connection setup from the network. In step <b>623</b>, UE <b>601</b> transmits an RRC setup complete message to the network. The RRC setup complete message may contain an Attach Request message or a Tracking Area Update (TAU) message sent to the NAS entity. The Attach message or the TAU message is used to indicate MBMS capability. In step <b>624</b>, UE <b>601</b> receives an RRC security mode command from the network. In step <b>625</b>, UE <b>601</b> sends an RRC security mode complete message to the network. In step <b>626</b>, UE <b>601</b> receives an RRC connection reconfiguration message from the network, which contains an Attach Accept or TAU Accept message. Finally, in step <b>627</b>, UE <b>601</b> sends another RRC Connection Reconfiguration Complete message to the network. In a third embodiment, the MBMS capability information is indicated through application layer messages as illustrated below in <figref idrefs="DRAWINGS">FIG. 9</figref>.
p-0065<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates different embodiments of UE reporting MBMS reception status to the network. In a first embodiment illustrated in the left half of <figref idrefs="DRAWINGS">FIG. 7</figref>, in step <b>711</b>, UE <b>701</b> receives an MBMS counting request from the network. In step <b>712</b>, UE <b>701</b> transmits MBMS counting response to the network. The MBMS counting is to count the number of UEs interested in certain MBMS services within an MBSFN area, i.e., one counting for one MBMS service for one MBSFN area. As a result, the selection of EPS or MBMS bearer can be based on the counting. The selection of EPS or MBMS bearer is directly coupled with the selection of point-to-point or point-to-multipoint radio bearer. In a second embodiment illustrated in the right half of <figref idrefs="DRAWINGS">FIG. 7</figref>, MBMS reception or interest status is reported in RRC or EMM messaging. In step <b>721</b>, UE <b>701</b> transmits an RRC connection request to the network. In step <b>722</b>, UE <b>701</b> receives an RRC connection setup from the network. In step <b>723</b>, UE <b>701</b> transmits an RRC setup complete message to the network. The RRC setup complete message may be used to carry MBMS reception status. In addition, the RRC setup complete message may contain a TAU message or a service request used to carry MBMS reception/interest status. In step <b>724</b>, UE <b>701</b> receives an RRC security mode command from the network. In step <b>725</b>, UE <b>701</b> sends an RRC security mode complete message to the network. In step <b>726</b>, UE <b>701</b> receives an RRC connection reconfiguration message from the network. Finally, in step <b>727</b>, UE <b>701</b> sends another RRC Connection Reconfiguration Complete message to the network. In a third embodiment, the MBMS reception status is indicated through application layer messages as illustrated below in <figref idrefs="DRAWINGS">FIG. 9</figref>.
p-0066To support PoC traffic multicasting, both a unicast EPS bearer and a multicast MBMS bearer need to be already established for the same service before a UE requests for PoC traffic. The unicast EPS bearer is established at least for PoC UL traffic. The multicast MBMS bearer, when appropriate, is used for PoC DL traffic. The selection of the EPS bearer and the MBMS bearer is decided by the BM-SC based on MBMS counting. From UE perspective, UE shall perform the EPS bearer and the MBMS bearer association. UE shall receive data from both bearers and route the data from the multicast bearer and the unicast bearer to the same application. The UE shall perform duplicate detection for the data over the multicast MBMS bearer and the unicast EPS bearer. For example, if the same data (e.g., same sequence number) is sent from both bearers, UE shall regard them as duplication. UE shall not automatically disconnect any of the bearers (radio part of the bearers) when both bearers are receiving data. UE shall not request bearer reestablishment if the unicast bearer is disconnected by the network and the MBMS bearer can still receive data, unless the MBMS bearer is approaching MBMS coverage hole or MBMS coverage boundary.
p-0067<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates one embodiment of establishing a unicast EPS bearer for UL PoC traffic. In step <b>811</b>, UE <b>801</b> sends a PDN connectivity request to the network for establishing the unicast EPS bearer. In general, a UE can indicate the group communication service interest directly when request setting up the unicast bearer. For example, the UE may use a pre-configured APN to request group communication service, and the APN may be configured in SIM, UE storage, or OMA-DM. In the example of <figref idrefs="DRAWINGS">FIG. 8</figref>, the PDN connectivity request indicates the interest of UE <b>801</b> for group communication service. In step <b>812</b>, UE <b>801</b> receives a request from the network to activate default EPS bearer context. If there is a pre-configured MBMS bearer for the corresponding group communication service, then the network can simply assign required information for UE <b>801</b> to receive group traffic from the MBMS bearer. For example, a TMGI list of communication groups is assigned by the network when establishing the MBMS bearers and UE <b>801</b> acquires the TMGI from the TMGI list in step <b>812</b>. In step <b>813</b>, UE <b>801</b> sends an activate default EPS bearer context accept message back to the network.
p-0068<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates another embodiment of establishing a unicast EPS bearer for UL PoC traffic. In step <b>911</b>, UE <b>901</b> sends a PDN connectivity request to the network for establishing the unicast EPS bearer. In step <b>912</b>, UE <b>901</b> receives an activate default EPS bearer context request message from the network. In step <b>913</b>, UE <b>901</b> sends an activate default EPS bearer context accept message back to the network. After the PDN connection setup is completed, UE <b>901</b> starts the SIP protocol for session setup. In step <b>914</b>, UE <b>911</b> sends a SIP Invite to the network. In one example, the SIP Invite message may indicate group communication interest of UE <b>901</b>. In step <b>915</b>, UE <b>901</b> receives a SIP Connect from the network and acquires the TMGI from the SIP Connect message. In both embodiments of <figref idrefs="DRAWINGS">FIGS. 8 and 9</figref>, TMGI is acquired quickly and effectively for MBMS receiving. The application layer SIP protocol can also be used to report UE MBMS capability and MBMS reception status to the network. In the example of <figref idrefs="DRAWINGS">FIG. 9</figref>, the SIP Invite message may contain a New Feature Capability field, which carries UE MBMS capability information as well as MBMS reception status or interest information. In one advantageous aspect, once a PoC session is established using SIP, then it should not be terminated due to long inactivity/silence in the media Path. To avoid long call setup time for PoC traffic, such “long-live” SIP session can only be terminated by sending an explicit SIP BYE request message by any one of the communicating peers.
p-0069The MBMS bearer can be established proactively (pre-configured) or reactively (dynamically). For proactive establishment, MBMS multicast group for a PoC group is established beforehand, and PoC DL traffic is delivered through a corresponding pre-configured MBMS bearer. The pre-configured MBMS bearer is statically established without considering UE mobility information. For reactive establishment, MBMS multicast group for a subset of PoC group is established when a multicast decision is made after identified radio multicast/broadcast opportunity. In one example, a PoC group UE could belong to a PoC group but in deactivated state and has no interest in monitoring PoC traffic. When the UE decides to monitor the PoC traffic, it triggers the multicast decision process, and the MBMS bearer is established for the group UEs that are interested in monitoring PoC group traffic.
p-0070<figref idrefs="DRAWINGS">FIG. 10A</figref> illustrates one embodiment of reactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS broadcast mode. In this embodiment, PoC server <b>1006</b> provides PoC group mobility management, i.e., maintaining PoC UE positions. For example, PoC UE <b>1001</b> belongs to a PoC group having a PoC group ID and regularly reports its position in data plane. PoC UE <b>1001</b> has one unicast bearer/connection established for PoC DL and UL traffic (step <b>1011</b>). In step <b>1021</b>, the PoC server makes multicast decision for a subset of PoC UEs based on factors shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. In step <b>1022</b>, the PoC server triggers BM-SC <b>1005</b> to activate PoC multicast for the subset of PoC UE, and informs BM-SC downstream nodes for traffic delivery by sending a PoC traffic multicast request (step <b>1023</b>). In step <b>1024</b>, the BM-SC initiates MBMS bearer resources for the traffic multicast. In step <b>1025</b>, an MBMS bearer context configuration is passed from the BM-SC to MBMS-GW <b>1004</b> by sending another PoC traffic multicast request. Information of downstream nodes for traffic delivery is passed to the MBMS-GW as well. In step <b>1026</b>, the MBMS-GW creates an MBMS bearer context according to the BM-SC configuration. The MBMS-GW forms a distribution tree of relevant eNBs (the ones with the subset of UEs) for traffic received from the BM-SC, based on the information from the BM-SC. The delivery between the BM-SC and eNBs can be achieved via multiple unicast connections or via a multicast connection. The relevant eNBs corresponding to the UE subset can be defined via an MBSFN area. In step <b>1027</b>, MME <b>1003</b> receives a session request and creates an MBMS bearer context according to the BM-SC configuration (step <b>1028</b>). In step <b>1029</b>, the relevant eNBs in RAN <b>1002</b> receive the session request and create the MBMS bearer context as well (step <b>1031</b>). If BM-SC to eNB routing is achieved via backbone multicasting, an IP multicast address is also delivered to the eNBs.
p-0071From steps <b>1032</b> to <b>1035</b>, MBMS session response and PoC traffic multicast response are sent back from the eNBs, to MME, to MBMS-GW, to BM-SC, and to the PoC server. In step <b>1036</b>, access information required for PoC traffic multicasting is announced to UE <b>1001</b> from BM-SC <b>1005</b>. The access information comprises mapping information between the PoC group ID and the TMGI associated with the MBMS bearer. In step <b>1041</b>, UE <b>1001</b> sets up RAN resource for receiving MBMS data. The relevant eNBs allocate necessary radio resources for the transfer of MBMS data to the interested UEs. The MBMS session for the PoC DL traffic starts when the BM-SC is ready to send PoC traffic using the MBMS bearer service. The PoC server filters PoC DL packets for PoC UEs with multicast decision, and delivers only one packet to the multicast group. After receiving traffic from the MBMS bearer, the UE can indicate to the network that it is successfully receiving DL traffic from the MBMS bearer. In response, the PoC server can terminate PoC DL traffic from the unicast bearer. The unicast bearer is kept for UL only.
p-0072Note that TMGI is linked to PoC group ID as an identifier in RAN. TMGI is required for MBMS bearer services, because MBMS uses TMGI to uniquely identify an MBMS service within a PLMN. The linkage between TMGI and PoC group ID is made by the BM-SC. The PoC UEs should be informed of the linkage between TMGI and PoC group ID (as part of the access information). For example, the linkage may be provided by non-dedicated RRC signaling, i.e., system information broadcasting, by signaling in data plane, or by agreed mapping rule. The association between TMGI and PoC group ID is changed regularly for security. In a first example, the association is changed through application layer protocol (e.g., SIP UPDATE). In a second example, the association is changed through specific NAS message (e.g., ESM “MODIFY EPS BEARER CONTEXT REQUEST” message). Upon receiving a new association, the UE shall continue to monitor the old TMGI to receive the multicast traffic over a period until PoC traffic from the new TMGI can be successfully received.
p-0073<figref idrefs="DRAWINGS">FIG. 10B</figref> illustrates one embodiment of proactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS broadcast mode. In this embodiment, MBMS multicast group for a PoC group is established beforehand, and PoC DL traffic delivery is through a corresponding MBMS bearer. Group UE mobility is no longer important because PoC traffic multicasting is performed anyway. Relevant eNBs allocates necessary radio resources for the transfer of MBMS data via the MBMS bearer. In step <b>1061</b>, new UE <b>1051</b> has one unicast bearer/connection established for PoC DL and UL traffic. In step <b>1062</b>, an MBMS bearer is established beforehand for PoC DL traffic for the PoC group, and individual unicast bearers are established for UL traffic of individual PoC group UEs. When the new UE <b>1051</b> becomes active in monitoring PoC traffic in step <b>1061</b>, access information required for PoC traffic multicast is announced to UE <b>1051</b> by PoC server <b>1056</b> in step <b>1076</b>. The access information comprises mapping information between the PoC group ID and the TMGI associated with the MBMS bearer. In step <b>1081</b>, UE <b>1051</b> applies the MBMS bearer configuration for monitoring the MBMS bearer to receive PoC DL traffic. After successfully receiving PoC DL traffic from the MBMS bearer, PoC server <b>1056</b> can terminate PoC DL traffic from the unicast bearer.
p-0074While MBMS broadcast mode is supported in EPS, MBMS multicast mode is supported only in GPRS. MBMS multicast mode supports multicasting between BM-SC and subscribed UEs. The difference between the broadcast/multicast modes is the awareness of UE interest of certain MBMS services to the granularity of cell. For broadcast mode, MBMS counting is over MBSFN area. For multicast mode, MBMS counting is over cell. When MBMS multicast mode is used as a delivery system in the core network for PoC, PoC group management support is mainly provided in the MBMS-GW, which is used for group mobility management.
p-0075<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates an architecture of an LTE system <b>1100</b> supporting group communication via MBMS multicasting mode and using MBMS gateway for group mobility management in accordance with one novel aspect. Similar to LTE system <b>300</b> illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>, LTE system <b>1100</b> comprises an application network, an evolved packet core (EPC) network, and a radio access network (RAN). The application network comprises a content provider <b>1101</b>, a PoC server <b>1102</b>, a Broadcast Multicast Service Center (BM-SC) <b>1103</b>, and an MBMS gateway (MBMS-GW) <b>1104</b> for MBMS control plane and user plane (CP&UP). The EPC network comprises a packet data network gateway (PDN-GW) <b>1111</b>, a serving gateway (S-GW) <b>1112</b>, a mobility management entity (MME) <b>1113</b>, and a multi-cell/multicast coordination entity (MCE) <b>1114</b>. The radio access network, for example, is an E-UTRAN that comprises eNB <b>1121</b> and eNB <b>1122</b>, and a plurality of user equipments UEs <b>1131</b>-<b>1134</b>. In the example of <figref idrefs="DRAWINGS">FIG. 11</figref>, UE <b>1131</b> is served by eNB <b>1121</b>, and UEs <b>1132</b>-<b>1134</b> are served by eNB <b>1122</b>.
p-0076In accordance with one novel aspect, MBMS multicast mode is applied for PoC DL traffic multicasting in selected cells in EPS. A multicast group consists of multiple UEs and is maintained at the MBMS-GW, which routes MBMS traffic to relevant eNBs with interested UEs. While the PoC server maintains the list of all PoC groups, the MBMS-GW also maintains mobility of PoC groups or the mobility of a set of PoC groups instructed by the PoC server. Mobility tracking is via the assistance of MME. In MBMS multicast mode, multicast decision can be made by the BM-SC, which examines periodically if certain UE fits for multicasting reception. For example, the BM-SC applies factors (as shown in <figref idrefs="DRAWINGS">FIG. 4</figref>) collected from the MBMS-GW and makes the multicast decision. For individual UEs, two bearers are established. One unicast EPS bearer is at least for PoC UL traffic. One multicast MBMS bearer, when appropriate, is used for PoC DL traffic. The MBMS bearer is established proactively or reactively.
p-0077<figref idrefs="DRAWINGS">FIG. 12A</figref> illustrates one embodiment of reactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS multicast mode. In this embodiment, a PoC UE <b>1201</b> has one unicast bearer/connection established for PoC DL and UL traffic (step <b>1211</b>). MBMS-GW <b>1204</b> maintains UE positions of PoC groups (step <b>1222</b>). In step <b>1223</b>, BM-SC <b>1205</b> makes multicast decision for a subset of PoC group UEs based on factors shown in <figref idrefs="DRAWINGS">FIG. 4</figref> that are collected from e.g., MBMS-GW <b>1204</b>. In step <b>1224</b>, the BM-SC identifies PoC DL traffic multicasting opportunity for the subset of PoC group UEs, reserves a multicast IP, and prepares an MBMS bearer context configuration. In step <b>1225</b>, the MBMS bearer context configuration, the subset of PoC UE, and the downstream nodes are passed from the BM-SC to the MBMS-GW via a PoC traffic multicast request. In step <b>1226</b>, the MBMS-GW initiates and maintains a multicast group for delivery of the PoC DL traffic to the subset of PoC UEs. The MBMS-GW generates a PoC traffic distribution tree in IP backbone for the subset of PoC UEs. The distribution is between the BM-SC and relevant eNBs with the subset of PoC UEs. The delivery between the BM-SC and eNBs can be achieved via multiple unicast connections or via a multicast connection. The relevant eNBs corresponding to the subset of UEs can be defined via an MBSFN area. In step <b>1227</b>, MME <b>1003</b> receives a session request and creates an MBMS bearer context according to the BM-SC configuration (step <b>1228</b>). In step <b>1229</b>, the relevant eNBs in RAN <b>1202</b> receive the session request and create the MBMS bearer context as well (step <b>1231</b>). If BM-SC to eNB routing is achieved via backbone multicasting, an IP multicast address is also delivered to the relevant eNBs.
p-0078From steps <b>1232</b> to <b>1234</b>, MBMS session response and PoC traffic multicast response are sent back from the eNBs, to MME, to MBMS-GW, and to the BM-SC. In step <b>1236</b>, access information required for traffic multicast is announced to UE <b>1201</b> from BM-SC <b>1205</b>. The access information comprises mapping information between the PoC group ID and the TMGI associated with the MBMS bearer. In step <b>1241</b>, UE <b>1201</b> setup RAN resource for receiving MBMS data. The relevant eNBs allocate necessary radio resources for the transfer of MBMS data to the interested UEs. The MBMS session for the PoC DL traffic starts when the BM-SC is ready to send PoC traffic using the MBMS bearer service. The BM-SC filters PoC DL packets for PoC UEs with multicast decision, and delivers only one packet addressed to the corresponding multicast address. Alternatively, the PoC server should be informed of the multicasting behavior and only deliver one packet for the multicast group by addressing it to a corresponding multicast IP. After receiving PoC DL traffic from the MBMS bearer, UE <b>1051</b> can terminate PoC DL traffic from the unicast bearer.
p-0079<figref idrefs="DRAWINGS">FIG. 12B</figref> illustrates one embodiment of proactive MBMS bearer establishment for PoC DL multicast traffic based on MBMS multicast mode. In this embodiment, a new UE <b>1251</b> has one unicast bearer/connection established for PoC DL and UL traffic (step <b>1261</b>). MBMS-GW <b>1254</b> maintains UE positions of PoC groups (step <b>1262</b>). For proactive MBMS bearer establishment, MBMS multicast group for a PoC group is established beforehand, and PoC DL traffic delivery is through a corresponding MBMS bearer. In step <b>1263</b>, an MBMS bearer is established for PoC DL traffic for the PoC group, and individual unicast bearers are established for UL traffic of individual PoC group UEs. When the new UE <b>1251</b> becomes active and shows its interest in monitoring PoC traffic in step <b>1261</b>, the PoC server can make the decision of whether or not to include UE <b>1251</b> into the MBMS multicast group. In step <b>1264</b>, BM-SC <b>1255</b> receives a request from the PoC server to include the new UE. The BM-SC passes an MBMS bearer ID corresponding to the PoC group to MBMS-GW <b>1254</b> by sending a PoC traffic multicast request (step <b>1265</b>). The UE identity and downstream nodes for traffic delivery is passed to the MBMS-GW as well. In step <b>1266</b>, the MBMS-GW includes the new UE into the multicast group based on its PoC group. The MBMS-GW updates the PoC traffic distribution tree to include the eNB corresponding to the new UE. In step <b>1267</b>, MME <b>1253</b> receives a session request and an MBMS bearer context is created in the MME corresponding to the new UE if the MBMS bearer context is new to the MME (step <b>1268</b>). In step <b>1269</b>, the relevant eNB in RAN <b>1252</b> receives the session request and creates the MBMS bearer context if the MBMS bearer context is also new to the relevant eNB (step <b>1271</b>).
p-0080From steps <b>1272</b> to <b>1274</b>, MBMS session response and PoC traffic multicast response are sent back from the eNBs, to the MME, to the MBMS-GW, and to the BM-SC. In step <b>1276</b>, access information required for traffic multicast is announced to UE <b>1251</b> from BM-SC <b>1255</b>. The access information comprises mapping information between the PoC group ID and the TMGI associated with the MBMS bearer. In step <b>1281</b>, UE <b>1251</b> setup RAN resource for receiving MBMS data. The relevant eNB allocates necessary radio resources for the transfer of MBMS data to UE <b>1251</b>. After receiving PoC DL traffic from the MBMS bearer, UE <b>1251</b> can terminate PoC DL traffic from the unicast bearer.
p-0081<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow chart of supporting PoC multicast traffic using MBMS in LTE network in accordance with one novel aspect. In step <b>1301</b>, a UE established a unicast EPS bearer in an LTE network for group communication. The UE belongs to a communication group having a communication group ID. In step <b>1302</b>, the UE receives access information from the network for monitoring DL multicast traffic of the communication group based on a multicast decision. In step <b>1303</b>, the UE monitors a multicast MBMS bearer for receiving the DL multicast traffic. The multicast MBMS bearer is associated with a TMGI, and the TMGI is associated with the communication group ID. In one embodiment, the access information comprises mapping information between the TMGI and the communication group ID.
Radio Resource Efficient Transmission for PoC
p-0082To reuse EPS MBMS radio transmission method for delivering PoC DL traffic in selected cells, more efficient radio resource utilization can be achieved by PoC DL traffic multicasting in RAN level. For control region capacity perspective, this can be achieved by enabling multiple UEs to monitor the same control channel used for scheduling DL assignment. For data region capacity perspective, this can be achieved by enabling multiple UEs to monitor the PoC DL traffic from the same DL assignment if the UEs belong to the same PoC group. In one novel aspect, radio resource efficient transmission of PoC DL traffic can be achieved by sharing radio resources using cell-broadcasting scheme or in cell-multicasting scheme. Cell-broadcasting scheme refers to the use of MBSFN subframe exclusively for PoC DL traffic. Cell-multicasting scheme refers to the dynamic scheduling of PDSCH for multiple UEs by addressing a corresponding PDCCH to a group radio identifier. Furthermore, multiple PoC UEs can share the same PDCCH to reduce control channel loading for PoC DL traffic scheduling.
p-0083<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates cell broadcasting radio transmission method for PoC service in LTE network <b>1400</b>. LTE network <b>1400</b> comprises a core network EPC <b>1401</b>, a plurality of base stations eNB <b>1411</b>-<b>1413</b>, and a plurality of user equipments UE <b>1421</b>-<b>1427</b>. In this embodiment, the assumption is that PoC UE mobility has been taken care by a logical entity above RAN (e.g., a PoC server or an MBMS-GW). Multicasting decision for a subset of PoC UEs of the same PoC group within a cell (clustered PoC group UEs) is already made in the network side, e.g., by a BM-SC or by the PoC server. The PoC DL traffic for the clustered PoC group UEs that are decided for multicasting is routed to relevant eNBs by the core network with MBMS delivery system. In the example of <figref idrefs="DRAWINGS">FIG. 14</figref>, UE <b>1422</b>-<b>1424</b> are clustered PoC UEs for receiving PoC traffic from eNB <b>1412</b>, while UE <b>1425</b>-<b>1427</b> are clustered PoC UEs for receiving PoC traffic from eNB <b>1413</b>.
p-0084The PoC DL traffic multicasting in RAN using cell-broadcasting method is achieved via MBMS radio broadcasting method, i.e., same as LTE MBMS radio transmission. The relevant eNBs broadcast PoC DL traffic by using MBSFN subframe. PoC DL traffic shares MBSFN subframes with MBMS services. However, the number of intra-cell PoC groups should be large enough to justify the exclusive usage of MBSFN subframe. If one MBSFN subframe can be shared with MBMS service, then MBSFN subframe resources can be better utilized. TMGI can be used to distinguish traffic from different PoC groups. MBMS PHY transmission method is reused. MBSFN area is used to define relevant eNBs for PoC group traffic distribution.
p-0085From UE perspective, UE needs to receive TMGI to find its allocation. TMGI is assigned by BM-SC and is used to identify an MBMS bearer service within one PLMN. PoC group ID should be linked to TMGI and UE should be informed of the linkage between TMGI and PoC group ID. For example, the linkage may be provided by non-dedicated RRC signaling, i.e., system information broadcasting, by signaling in data plane, or by agreed mapping rule.
p-0086Under current EPS MBMS support, there is no HARQ retransmission for PoC traffic delivery. For radio transmission robustness, PHY layer repetitive transmission can be considered. To allow repetitive transmission for a fixed number of times, additional eNB support is required to distinguish between PoC multicast bearer and MBMS multicast bearer so that the repetitive transmission behavior can be applied. For example, an eNB needs to know which TMGI is linked to PoC traffic so that repetitive transmission can be applied. In addition to distribute repetitive transmission in time domain, the repetitive transmission can be performed in different frequency domain resources. Furthermore, in MBMS, the content provider can adapt codec rate to meet a long-term target packet error rate by higher layer signaling.
p-0087<figref idrefs="DRAWINGS">FIG. 15</figref> illustrates one embodiment of cell broadcasting radio transmission. In step <b>1511</b>, UE <b>1501</b> already belongs to a PoC group, and a unicast EPS bearer for group communication is already established. In step <b>1512</b>, UE <b>1501</b> receives required access information from the network. The access information comprises information required for receiving PoC traffic multicasting, e.g., TMGI corresponding to the PoC group and bearer QoS. The access information also includes MBMS bearer configuration, which is transmitted in a similar manner as for MBMS traffic. In step <b>1513</b>, UE <b>1501</b> applies the MBMS bearer configuration and acquires PoC DL traffic scheduling information based on control information broadcasted in system information block. The control information relevant to the PoC group is identified by the TMGI, and traffic is scheduled in MBSFN subframes similar to MBMS service. In step <b>1514</b>, UE <b>1501</b> gets ready for monitoring the PoC DL traffic via the MBMS bearer. For UEs with both unicast and MBMS bearers, it can monitor its PoC traffic via either the original unicast bearer or the newly established MBMS bearer or both. The PoC traffic is delivered from either the unicast bearer or the MBMS bearer, but not at the same time from both bearers on purpose. UE <b>1501</b> is not configured with feedback channel for HARQ, RLC ARQ, ROHC on the MBMS bearer, the UE shall apply different radio reception method based on the configuration message (e.g., number of repetitive transmission). Furthermore, because UE <b>1501</b> may or may not know which bearer is used to deliver its PoC traffic for a given moment, UE <b>1501</b> de-multiplexes PoC DL traffic received either from the MBMS bearer or from the unicast bearer into the same application port for group communication.
p-0088<figref idrefs="DRAWINGS">FIG. 16</figref> illustrates cell multicasting radio transmission method for PoC service in LTE network <b>1600</b>. LTE network <b>1600</b> comprises a core network EPC <b>1601</b>, a plurality of base stations eNB <b>1611</b>-<b>1613</b>, and a plurality of user equipments UE <b>1621</b>-<b>1627</b>. In this embodiment, the assumption is that PoC UE mobility has been taken care by a logical entity above RAN (e.g., a PoC server or an MBMS-GW). Multicasting decision for a subset of PoC UEs of the same PoC group within a cell (clustered PoC group UEs) is already made by the logical entity. The PoC DL traffic for the clustered PoC group UEs that are decided for multicasting is routed to relevant eNBs by the core network with MBMS delivery system. In the example of <figref idrefs="DRAWINGS">FIG. 16</figref>, UE <b>1622</b>-<b>1624</b> are clustered PoC UEs for receiving PoC traffic from eNB <b>1612</b>, while UE <b>1625</b>-<b>1627</b> are clustered PoC UEs for receiving PoC traffic from eNB <b>1613</b>.
p-0089For cell multicasting radio transmission, PoC DL traffic multicasting in RAN is achieved via dynamic scheduling by a group identifier, e.g., a group Radio Network Temporary identifier (g-RNTI), which is similar to dynamic scheduling scrambled by a C-RNTI in radio unicasting case. For example, UE <b>1621</b> is scheduled to monitor PDCCH by C-RNTI, UE <b>1622</b>-<b>1624</b> are scheduled to monitor PDCCH by a first g-RNTI1, and UE <b>1625</b>-<b>1627</b> are scheduled to monitor PDCCH by a second g-RNTI2. The PoC UEs can acquire PoC DL traffic via PoC radio multicasting or via PoC radio unicasting. The switching between PoC radio multicasting and PoC radio unicasting is supported for PoC UEs, and either g-RNTI or C-RNTI is used for PoC DL traffic transmission via PoC radio multicasting or unicasting respectively.
p-0090From UE perspective, UE needs to receive TMGI to distinguish traffic from different PoC groups. PoC group ID is maintained at PoC server and known in data plane. TMGI is assigned by BM-SC and is used to identify an MBMS bearer service within one PLMN. UE should be informed of the linkage between PoC group ID and TMGI before receiving PoC traffic. For example, the linkage may be provided by non-dedicated RRC signaling, i.e., system information broadcasting, by signaling in data plane, or by agreed mapping rule. In addition, UE should be informed to monitor which g-RNTI, i.e., the linkage between g-RNTI and TMGI. Such linkage information can also be notified to UE via RRC signaling (e.g., system information broadcasting) or by agreed mapping rule.
p-0091For radio transmission robustness, PHY layer repetitive transmission can be considered. To allow repetitive transmission for a fixed number of times, additional eNB support is required to distinguish between PoC multicast bearer and MBMS multicast bearer so that the repetitive transmission behavior can be applied. In addition to distribute repetitive transmission in time domain, the repetitive transmission can be performed in different frequency domain resources.
p-0092To adopt HARQ mechanism, a common feedback channel is used for on-off detection, especially for delay-tolerant PoC data. For ACK PoC UE, nothing is done. For NACK PoC UE, energy is transmitted on a configured resource. A proper threshold is determined by considering the signal cancelation due to destructive interference between multiple NACK signaling. Feedback resource is informed implicitly since UE identity is unknown to eNB. For the common feedback channel, the HARQ process number should all have the same process ID of the PoC retransmission, or should be managed in a way that indicates the specific HARQ process for PoC retransmission. For example, a dedicated HARQ process similar to a broadcast channel can be used.
p-0093<figref idrefs="DRAWINGS">FIG. 17</figref> illustrates one embodiment of cell multicasting radio transmission. In step <b>1711</b>, UE <b>1701</b> already belongs to a PoC group, and a unicast EPS bearer for group communication is already established. In step <b>1712</b>, UE <b>1701</b> receives required access information from the network. The access information comprises information required for receiving PoC traffic multicasting, e.g., TMGI corresponding to the PoC group and bearer QoS. The access information also includes MBMS bearer configuration, which is transmitted in a similar manner as for MBMS traffic. In step <b>1713</b>, UE <b>1701</b> receives signaling of radio identifier (g-RNTI) and mapping between the TMGI and g-RNTI. In step <b>1714</b>, UE <b>1701</b> applies the MBMS bearer configuration and gets ready for acquiring PoC DL traffic addressed to PDCCH scrambled with the received g-RNTI. For UEs with both unicast and MBMS bearers, it can monitor its PoC traffic via either the original unicast bearer or the newly established MBMS bearer or both. The PoC traffic is delivered from either the unicast bearer or the MBMS bearer, but not at the same time from both bearers. UE <b>1701</b> is not configured with feedback channel for HARQ, RLC ARQ, ROHC on the MBMS bearer, the UE shall apply different radio reception method based on the configuration message (e.g., number of repetitive transmission). In step <b>1715</b>, because UE <b>1701</b> may or may not know which bearer is used to deliver its PoC traffic for a given moment, UE <b>1701</b> de-multiplexes PoC DL traffic received either from the MBMS bearer or from the unicast bearer into the same application port for group communication.
p-0094It can be seen that with proper EPC support, three delivery methods can be concurrently used for PoC traffic delivery: radio unicasting, cell broadcasting, and cell multicasting. From UE perspective, PoC DL traffic from the three means is de-multiplexed to the same application port. For the cell multicasting method, signaling reduction for dynamic scheduling of the PoC DL traffic can be achieved. In one novel aspect, one common g-RNTI is used for PoC DL traffic scheduling for different PoC groups within a cell. Furthermore, for PDCCH space reduction, UL PUSCH resource can also be granted through the common g-RNTI for multiple UEs of the PoC groups.
p-0095<figref idrefs="DRAWINGS">FIG. 18</figref> illustrates a method of sharing PDCCH among PoC UEs for PoC DL traffic scheduling. In LTE network <b>1810</b>, a cluster UEs belong to PoC group 1, and another cluster UEs belong to PoC group 2. Both PoC group UEs are served by the same eNB <b>1812</b>. For PoC DL traffic multicasting, EPC establishes MBMS bearer 1 for PoC DL traffic to be delivered to PoC group 1, and MBMS bearer 2 for PoC DL traffic to be delivered to PoC group 2. In RAN cell multicasting, eNB <b>1812</b> dynamically schedules PoC DL traffic to PoC group 1 and PoC group 2 using g-RNTI-1 and g-RNTI-2 respectively. As a result, UEs from PoC group 1 monitors PDSCH and acquires PoC DL traffic addressed to PDCCH scrambled with g-RNTI-1, and UEs from PoC group 2 monitors PDSCH and acquires PoC DL traffic addressed to PDCCH scrambled with g-RNTI-2.
p-0096In LTE network <b>1820</b>, a cluster UEs belong to PoC group 1, and another cluster UEs belong to PoC group 2. Both PoC group UEs are served by the same eNB <b>1822</b>. For PoC DL traffic multicasting, EPC establishes MBMS bearer 1 for PoC DL traffic to be delivered to PoC group 1, and MBMS bearer 2 for PoC DL traffic to be delivered to PoC group 2. MBMS bearer 1 is associated with TMGI-1 and MBMS bearer 2 is associated with TMGI-2. In RAN cell multicasting, eNB <b>1822</b> dynamically schedules PoC DL traffic to PoC group 1 and PoC group 2 using a common g-RNTI. As a result, UEs from PoC group 1 monitors PDSCH and acquires PoC DL traffic addressed to PDCCH scrambled with the common g-RNTI, and find its PoC traffic by looking for MAC PDU sub-header that matches identifier TMGI-1. Similarly, UEs from PoC group 2 monitors PDSCH and acquires PoC DL traffic addressed to PDCCH scrambled with the same common g-RNTI, and finds its PoC traffic by looking for MAC PDU sub-header that matches identifier TMGI-2.
p-0097For further PDCCH space reduction, UE uplink PUSCH resource can also be granted through a common g-RNTI. As depicted by box <b>1830</b>, outstanding g-RNTIs are used for each PoC group, e.g., g-RNTI-1 for PoC group 1 and g-RNTI-2 for PoC group 2. For each individual UE, the MAC sub-header carries UE's C-RNTI linking to the corresponding UL grant. On the other hand, as depicted by box <b>1840</b>, a single g-RNTI is used for all PoC groups. For each individual UE, the MAC sub-header carries each UE's C-RNTI that links to the corresponding UL grant.
p-0098<figref idrefs="DRAWINGS">FIG. 19</figref> is a flow chart of radio resource efficient transmission for PoC multicast traffic in accordance with one novel aspect. In step <b>1901</b>, a UE establishes a unicast EPS bearer in an LTE network for group communication. The UE belongs to a communication group having a group ID. In step <b>1902</b>, the UE receives access information from the network for monitoring a multicast MBMS bearer to receiving DL multicast traffic of the DL group communication. In step <b>1903</b>, the UE monitors and de-multiplexes the DL traffic received from the multicast bearer or from the unicast bearer into a single group communication application. In one embodiment, the UE receives the DL group communication in MBSFN subframes broadcasted in a serving cell. In another embodiment, the UE receives the DL group communication by monitoring a PDCCH scrambled by a g-RNTI.
Method of PoC Multicast Service Continuity
p-0099For PoC traffic multicasting, PoC group UE mobility management is required in the network side so that PoC traffic can be properly routed to relevant eNBs. If PoC group mobility is not managed in the core network, PoC multicast bearer cannot be handed over to a new target cell in case of handover events. After receiving a handover (HO) command, a PoC UE can request to switch back to the unicasting distribution of PoC traffic. By the time the PoC UE receives the HO command, the channel is likely too bad for reliable communication, which causes PoC service interruption. Because the PoC UE most likely requests to switch back to unicasting distribution only after the handover command reception, PoC service interruption time is longer than normal voice call. Such long service interruption of PoC DL traffic multicasting during handover can be avoided. For example, a smaller PoC DL multicasting radio coverage is applied for early termination of multicast distribution at cell edge. The early termination of PoC DL multicasting is triggered by RRC measurement events. Furthermore, PoC service continuity is maintained by selecting proper target cell in handover case.
p-0100<figref idrefs="DRAWINGS">FIG. 20</figref> illustrates a method of avoiding long service interruption of PoC traffic multicasting during handover in LTE network <b>2000</b>. In the example of <figref idrefs="DRAWINGS">FIG. 20</figref>, UE <b>2021</b> belongs to a PoC group and initially receives PoC traffic delivered by eNB <b>2012</b> from an MBMS bearer. Later on, UE <b>2021</b> leaves the MBMS coverage area and is handed over to eNB <b>2011</b>. If UE <b>2021</b> requests to switch to the unicast bearer for PoC traffic delivery after the handover, then the PoC service interruption is very long. Therefore, in accordance with one novel aspect, UE <b>2021</b> requests to switch the PoC traffic from the MBMS bearer to the unicast bearer before handover occurs. <figref idrefs="DRAWINGS">FIG. 20</figref> illustrates a cell boundary <b>2031</b> and an MBMS coverage boundary <b>2041</b> and an MBMS coverage hole <b>2051</b>. The service interruption due to an MBMS coverage hole and due to leaving an MBMS coverage is unbearable. In one embodiment, to remedy long service interruption due to late termination of PoC multicasting, the MBMS coverage boundary <b>2014</b> is defined to be a radio coverage for PoC DL traffic multicasting that is smaller than the cell coverage <b>2031</b>. PoC UE out of the MBMS coverage should request to switch back for traffic unicast. The smaller radio coverage is designed so that PoC UE is switched back to unicast distribution before handover command is received. The restriction of radio coverage for PoC DL traffic can be achieved by limiting DL transmit power and/or by a bit more aggressive modulation and coding scheme for MBMS radio signal as compared to unicast radio signal.
p-0101<figref idrefs="DRAWINGS">FIG. 21</figref> illustrates one embodiment of early termination of PoC multicast traffic. In step <b>2111</b>, a unicast EPS bearer is established for UE <b>2101</b> for PoC traffic in a source cell <b>2102</b>. In step <b>2112</b>, a multicast MBMS bearer is configured by the network for PoC traffic multicasting in the source cell <b>2102</b>. UE <b>2101</b> is then ready to monitor the MBMS bearer for PoC DL traffic multicasting. In step <b>2113</b>, UE <b>2101</b> performs radio signal measurements as configured by the network. In step <b>2114</b>, UE <b>2101</b> detects that it is approaching an MBMS coverage boundary, which is defined as the radio boundary for PoC traffic multicasting. The UE should be able to know when it is approaching the cell boundary. For example, UE <b>2101</b> may use RRC HO-related measurement event triggering to predict that the UE is very likely to be around cell edge. For example, the HO-related RRC measurement events include events A2/A3/A5/A6/B2. Together with the knowledge that MBMS signal strength is decreased, the UE knows that it is around MBMS coverage boundary, rather than a normal MBMS coverage hole. UE <b>2101</b> thus requests to switch back for traffic unicasting in step <b>2115</b>. Later on, in step <b>2116</b>, UE <b>2101</b> performs handover procedure and handovers to a target cell <b>2103</b>. Because the UE switches to traffic unicasting before receiving handover command, PoC service interruption time is reduced.
p-0102<figref idrefs="DRAWINGS">FIG. 22</figref> illustrates one embodiment of supporting PoC multicast service continuity. In step <b>2211</b>, a unicast EPS bearer is established for UE <b>2201</b> for PoC traffic in a source cell <b>2202</b>. In step <b>2212</b>, a multicast MBMS bearer is configured by the network for PoC traffic multicasting in the source cell <b>2202</b>. In step <b>2213</b>, UE <b>2201</b> applies the MBMS bearer configuration and monitors PoC DL traffic from the multicast MBMS bearer. In step <b>2214</b>, UE <b>2201</b> receives system information (e.g., SIB <b>15</b>) broadcasted in cell <b>2202</b>. The system information in SIB <b>15</b> provides the MBMS service availability information in neighboring cells. In RRC idle mode, UE can use this information for cell re-selection (i.e., select cells with MBMS service for PoC multicast service continuity possibility).
p-0103In RRC connected mode, UE can use this information and send indication to its serving eNB its preferred target cell for handover (cells with MBMS services for PoC multicast service continuity). For example, in step <b>2215</b>, UE <b>2201</b> sends an MBMS interest indication to the network. In step <b>2216</b>, UE <b>2201</b> is handed over to a preferred target cell <b>2203</b> based on its MBMS interest indication. In step <b>2217</b>, UE <b>2201</b> continue to monitor the multicast MBMS bearer in the target cell <b>2203</b> if MBMS service is available. However, in case there is no MBMS services in neighboring cells, then UE <b>2201</b> requests to switch PoC traffic from the MBMS bearer to the unicast bearer for service continuity (step <b>2221</b>). In step <b>2222</b>, UE <b>2201</b> performs handover procedure to handover to target cell <b>2203</b>. In step <b>2223</b>, a unicast EPS bearer is established for UE <b>2201</b> in the target cell <b>2203</b> for receiving PoC traffic.
p-0104<figref idrefs="DRAWINGS">FIG. 23</figref> is a flow chart of a method of supporting PoC multicast service continuity in accordance with one novel aspect. In step <b>2301</b>, a UE established a unicast EPS bearer in an LTE network for group communication. The UE belongs to a communication group having a communication group ID. In step <b>2302</b>, the UE receives access information from the network for monitoring DL multicast traffic of the communication group based on a multicast decision. In step <b>2303</b>, the UE monitors a multicast MBMS bearer for receiving the DL multicast traffic. The multicast MBMS bearer is associated with a TMGI, and the TMGI is associated with the communication group ID. In one embodiment, the access information comprise mapping information between the TMGI and the communication group ID. To reduce PoC service interruption time and to maintain PoC service continuity, there are several scenarios. In step <b>2304</b> (scenario 1), the UE requests to switch the DL multicast traffic from the MBMS bearer to the unicast bearer upon detecting that the UE is approaching an MBMS coverage boundary. In step <b>2305</b> (scenario 2), the UE transmits an indication of preferred target cells to the network before performing a handover procedure and thereby maintaining service continuity of the group communication. The indication may be based on MBMS service availability information of neighboring cells broadcasted in SIB <b>15</b>. In step <b>2306</b> (scenario 3), the UE is in RRC idle mode and lost the DL multicast traffic due to an MBMS coverage hole. The UE then requests RRC establishment with a new cause for group communication contained in the RRC request message. The benefit is that when the network is congested, the network can offload traffic from the unicast bearer to the MBMS bearer soon (after UE gets out the MBMS coverage hole) and the unicast resource is freed for other UEs. Following this logic, the network should serve a UE with priority upon receiving connection request with such cause.
Method of RRC Idle Mode Reception for PoC Traffic
p-0105Keeping UEs in connected mode without data transmission is not always favored due to UE power consumption. In EUTRA, connected mode DRX operation can be used for power saving. However, CQI reporting, SRS configuration etc. still causes extra power consumption as compared to idle mode. It is thus beneficial to enable idle mode PoC traffic reception from power saving and call setup latency perspective. For PoC UL traffic, UE needs to be in connected mode anyway. With idle mode reception, call setup latency is experienced at one end (UL side) only for establishing the UL RRC connection. In MBMS broadcast mode, RRC_IDLE mode reception become possible. In one novel aspect, PoC DL traffic is delivered via EPS MBMS service in the core network. EPS uses MBMS broadcast mode, and PoC UEs in RRC_IDLE mode can be configured to monitor PoC traffic on MBMS bearers. Both cell broadcasting using LTE MBSM radio transmission and cell multicasting using LTE dynamic scheduling radio transmission may be used for RRC_IDLE mode reception. In case of PoC UL transmission from a UE, the UE needs to enter RRC_Connected mode before PoC UL transmission.
p-0106<figref idrefs="DRAWINGS">FIG. 24</figref> illustrates one embodiment of supporting idle mode reception of PoC traffic. In step <b>2411</b>, a unicast EPS bearer is established for UE <b>2401</b> for PoC UL traffic. In step <b>2412</b>, a multicast MBMS bearer is configured by the network for PoC DL traffic multicasting. In step <b>2413</b>, UE <b>2401</b> applies the MBMS bearer configuration and monitors PoC DL traffic from the multicast MBMS bearer. In step <b>2414</b>, UE <b>2401</b> enters RRC_IDLE mode. As a result, the radio bearer part of the unicast EPS bearer is released. UE <b>2401</b> continues to monitor the MBMS bearer for PoC DL traffic in RRC_IDLE mode. In one embodiment, EPS MBMS radio transmission for broadcasting PoC DL traffic in selected cells can be reused. As a result, UE <b>2401</b> receives the PoC DL traffic in MBSFN frames broadcasted in its camped cell. In step <b>2415</b>, UE <b>2401</b> receives system information (e.g., SIB <b>15</b>) broadcasted in the network. The system information in SIB <b>15</b> provides the MBMS service availability information of neighboring cells.
p-0107In step <b>2421</b> (scenario #1), UE <b>2401</b> performs cell reselection (i.e., select cells with MBMS service for PoC multicast service continuity possibility) based on the system information in SIB <b>15</b>. UE <b>2401</b> can choose to camp on a new PoC DL traffic-broadcasting cell, and continue the PoC DL traffic reception in idle mode. In step <b>2422</b> (scenario #2), UE <b>2401</b> detects that it is leaving the MBMS coverage. In step <b>2423</b>, UE <b>2401</b> enters RRC_Connected mode and requests to recover the radio bearer part of the unicast EPS bearer for PoC traffic. For example, UE <b>2401</b> performs tracking area update (TAU) to request recovering the radio bearer. In step <b>2424</b> (scenario #3), UE <b>2401</b> encounters an MBMS coverage hole. In step <b>2425</b>, UE <b>2401</b> performs RRC establishment with a new cause of group communication. UE <b>2401</b> resumes the unicast transmission in step <b>2426</b> after RRC establishment. Later on, when UE <b>2401</b> is out of the MBMS coverage hole, in step <b>2427</b>, UE <b>2401</b> switches PoC traffic from the unicast bearer to the MBMS bearer so that the unicast bearer is freed for other UEs if the network is congested.
p-0108In addition to reuse EPS MBMS radio transmission for broadcasting PoC DL traffic to support idle mode reception, EUTRAN dynamic scheduling mechanism for delivering PoC DL traffic to a group of PoC UEs can also be reused to support idle mode reception. In EUTRAN, radio unicast traffic is scrambled by a UE-specific C-RNTI. Similar to PoC traffic, the group of PoC UEs can be informed to monitor scheduling assignment scrambled by a group-specific g-RNTI in idle mode. Since EPS MBMS does not support UE mobility management, eNB is not aware of when UE moves out of the coverage. For applications where the PoC traffic becomes irrelevant when UE moves out of certain area, idle mode reception is still possible. For idle mode reception, PoC UEs should first acquired necessary information before performing idle mode reception. For example, the necessary information includes which g-RNTI to monitor. The PoC UEs can acquired the necessary information via dedicated RRC signaling while UE is in RRC_Connected mode, or via non-dedicated RRC signaling while UE is in RRC_IDLE mode.
p-0109<figref idrefs="DRAWINGS">FIG. 25</figref> illustrates one embodiment of monitoring PoC traffic in RRC_IDLE mode. When using dynamic scheduling for PoC DL traffic, the scheduling assignment (PDCCH) scrambled by g-RNTI for PoC DL traffic can be given within common search space to reduce idle mode UE blind PDCCH decoding attempts. This is similar to scheduling assignment for paging message is given. In addition, the monitoring cycle for g-RNTI can be aligned with paging cycle for power saving. As illustrated in the left part of <figref idrefs="DRAWINGS">FIG. 25</figref>, in RRC_IDLE mode, both group-RNTI and paging-RNTI are monitored during the ON period of the same paging cycle. The paging cycle is tuned to achieve a tradeoff between PoC data plane latency and UE power consumption. For optimization, once PoC DL traffic is received in idle mode, UE should keep monitoring group-RNTI for an extended fixed amount of time as illustrated in the right part of <figref idrefs="DRAWINGS">FIG. 25</figref>. This is because group communication traffic can be bursty depending on traffic type, and UE is likely to receive more group communication traffic during the extended ON period upon traffic detection. With idle mode reception, the network has no idea when UE moves out of current service area for PoC DL traffic. This generates waste when there is no longer any UE interested in the PoC DL traffic. To solve this problem, UE can perform tracking area update (TAU) when it moves out of the service area. The core network can then decide whether to stop PoC transmission to a certain area based on the information.
p-0110<figref idrefs="DRAWINGS">FIG. 26</figref> is a flow chart of a method of supporting idle mode reception for PoC traffic in accordance with one novel aspect. In step <b>2601</b>, a UE established a unicast EPS bearer in an LTE network for group communication. The UE belongs to a communication group having a communication group ID. In step <b>2602</b>, the UE receives access information from the network for monitoring DL multicast traffic of the communication group based on a multicast decision. In step <b>2603</b>, the UE monitors a multicast MBMS bearer for receiving the DL multicast traffic. The multicast MBMS bearer is associated with a TMGI, and the TMGI is associated with the communication group ID. In one embodiment, the access information comprise mapping information between the TMGI and the communication group ID. In step <b>2604</b>, the UE enters RRC_IDLE mode while keep monitoring the MBMS bearer for receiving the DL multicast traffic. In one embodiment, the UE receives the DL group communication in MBSFN subframes broadcasted in a camped cell. In another embodiment, receives the DL group communication via monitoring a Physical Downlink Control Channel (PDCCH) addressed to a group-RNTI.
p-0111Although the present invention has been described in connection with certain specific embodiments for instructional purposes, the present invention is not limited thereto. Accordingly, various modifications, adaptations, and combinations of various features of the described embodiments can be practiced without departing from the scope of the invention as set forth in the claims.
Contents6
21 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2016242216A1 | Cited by | United States of America | Pre-grant |
| US10849065B2 | Cited by | United States of America | Applicant |
| CN105898895A | Cited by | China | Search report |
| US10142800B2 | Cited by | United States of America | Search report |
| EP4080971A4 | Cited by | European Patent Office (EPO) | Search report |
| EP3244643A4 | Cited by | European Patent Office (EPO) | Search report |
| US11234240B2 | Cited by | United States of America | Applicant |
| US2018027528A1 | Cited by | United States of America | Search report |
| US10326544B2 | Cited by | United States of America | Applicant |
| EP3051848A3 | Cited by | European Patent Office (EPO) | Search report |
| JP2017535978A | Cited by | Japan | Search report |
| US10142929B2 | Cited by | United States of America | Applicant |
| US11510116B2 | Cited by | United States of America | Applicant |
| CN105992158A | Cited by | China | Search report |
| US2016150412A1 | Cited by | United States of America | Pre-grant |
| US2016338011A1 | Cited by | United States of America | Pre-grant |
| EP3332567A4 | Cited by | European Patent Office (EPO) | Search report |
| US2018367961A1 | Cited by | United States of America | Search report |
| CN105848113A | Cited by | China | Search report |
| US2017086034A1 | Cited by | United States of America | Pre-grant |
| US9756483B2 | Cited by | United States of America | Applicant |
| US10743231B2 | Cited by | United States of America | Applicant |
| US10271181B2 | Cited by | United States of America | Applicant |
| WO2016119212A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US10051440B2 | Cited by | United States of America | Search report |
| WO2016112678A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US9848332B2 | Cited by | United States of America | Search report |
| US10045164B2 | Cited by | United States of America | Applicant |
| JP2018505610A | Cited by | Japan | Search report |
| US10045328B2 | Cited by | United States of America | Search report |
| US2016241610A1 | Cited by | United States of America | Pre-grant |
| US10091629B2 | Cited by | United States of America | Applicant |
| US10194472B2 | Cited by | United States of America | Search report |
| US10601731B2 | Cited by | United States of America | Applicant |
| US10349225B2 | Cited by | United States of America | Search report |
| US10397937B2 | Cited by | United States of America | Applicant |
| JP2018509054A | Cited by | Japan | Search report |
| US10028107B1 | Cited by | United States of America | Search report |
| EP3332398A4 | Cited by | European Patent Office (EPO) | Search report |
| US11184940B2 | Cited by | United States of America | Search report |
| US2016295413A1 | Cited by | United States of America | Pre-grant |
| US9900761B2 | Cited by | United States of America | Applicant |
| US2019261310A1 | Cited by | United States of America | Search report |
| US10834634B2 | Cited by | United States of America | Search report |
| US10728845B2 | Cited by | United States of America | Applicant |
| US10826769B2 | Cited by | United States of America | Search report |
| CN108377513A | Cited by | China | Search report |
| US10813077B2 | Cited by | United States of America | Search report |
| US11212321B2 | Cited by | United States of America | Search report |
| US10805773B2 | Cited by | United States of America | Search report |
| US11477700B2 | Cited by | United States of America | Applicant |
| US2018176927A1 | Cited by | United States of America | Search report |
| WO2016119634A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| CN107005817A | Cited by | China | Search report |
| WO2017050439A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| TWI609595B | Cited by | Taiwan Province of China | Examiner |
| US10728714B2 | Cited by | United States of America | Applicant |
| EP3358886A4 | Cited by | European Patent Office (EPO) | Search report |
| JP2017535978A | Cited by | Japan | Search report |
| US10993086B2 | Cited by | United States of America | Applicant |
| CN111447572A | Cited by | China | Search report |
| US10893393B2 | Cited by | United States of America | Applicant |
| US10447616B2 | Cited by | United States of America | Applicant |
| WO2020164810A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2018367961A1 | Cited by | United States of America | Search report |
| US11330573B2 | Cited by | United States of America | Search report |
| US10575042B2 | Cited by | United States of America | Applicant |
| EP3243348A4 | Cited by | European Patent Office (EPO) | Search report |
| US2018176927A1 | Cited by | United States of America | Search report |
| EP4233318A4 | Cited by | European Patent Office (EPO) | Search report |
| CN107005903A | Cited by | China | Search report |
| WO2016163820A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP3258713A4 | Cited by | European Patent Office (EPO) | Search report |
| CN107548035A | Cited by | China | Search report |
| US2017264647A1 | Cited by | United States of America | Search report |
| US2017264647A1 | Cited by | United States of America | Search report |
| US10542452B2 | Cited by | United States of America | Search report |
| US2022150997A1 | Cited by | United States of America | Search report |
| US11589269B2 | Cited by | United States of America | Applicant |
| EP3697034A1 | Cited by | European Patent Office (EPO) | Search report |
| WO2018130290A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP3993456A4 | Cited by | European Patent Office (EPO) | Search report |
| CN110049450A | Cited by | China | Search report |
| US10873905B2 | Cited by | United States of America | Applicant |
| US10887356B2 | Cited by | United States of America | Applicant |
| US11368818B2 | Cited by | United States of America | Search report |
| EP4033844A4 | Cited by | European Patent Office (EPO) | Search report |
| US10448218B2 | Cited by | United States of America | Search report |
| US2016234031A1 | Cited by | United States of America | Pre-grant |
| US2019289496A1 | Cited by | United States of America | Search report |
| CN107534911A | Cited by | China | Search report |
| US10271182B2 | Cited by | United States of America | Applicant |
| CN108989972A | Cited by | China | Search report |
| EP3700165A1 | Cited by | European Patent Office (EPO) | Search report |
| US11129059B2 | Cited by | United States of America | Search report |
| US10547985B2 | Cited by | United States of America | Applicant |
| US10771298B2 | Cited by | United States of America | Applicant |
| US2015358853A1 | Cited by | United States of America | Search report |
| US2016381517A1 | Cited by | United States of America | Pre-grant |
| US10506387B2 | Cited by | United States of America | Applicant |
50 members in 6 offices
Priority claims18
| Document | Office | Kind | Date |
|---|---|---|---|
| 201361804392 | United States of America | P | |
| 201361804392 | United States of America | P | |
| 201361804398 | United States of America | P | |
| 201361804398 | United States of America | P | |
| 201361804402 | United States of America | P | |
| 201361804402 | United States of America | P | |
| 201361804405 | United States of America | P | |
| 201361804405 | United States of America | P | |
| 201414221631 | United States of America | A | |
| 61804392 | – | – | – |
| 61804398 | – | – | – |
| 61804402 | – | – | – |
| 61804405 | – | – | – |
| US201361804392P | – | – | – |
| US201361804398P | – | – | – |
| US201361804402P | – | – | – |
| US201361804405P | – | – | – |
| US201414221631 | – | – | – |
Members50
| Document | Office | Kind | |
|---|---|---|---|
| US2014286222A1 | United States of America | A1 | |
| US2014286223A1 | United States of America | A1 | |
| US2014286224A1 | United States of America | A1 | |
| US2014286225A1 | United States of America | A1 | |
| WO2014146615A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2014146616A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2014146617A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2014146618A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP2829088A1 | European Patent Office (EPO) | A1 | |
| EP2829089A1 | European Patent Office (EPO) | A1 | |
| EP2829090A1 | European Patent Office (EPO) | A1 | |
| EP2859741A1 | European Patent Office (EPO) | A1 | |
| CN104813690A | China | A | |
| CN104813691A | China | A | |
| CN104854888A | China | A | |
| CN104871570A | China | A | |
| EP2829089A4 | European Patent Office (EPO) | A4 | |
| EP2859741A4 | European Patent Office (EPO) | A4 | |
| EP2829088A4 | European Patent Office (EPO) | A4 | |
| EP2829090A4 | European Patent Office (EPO) | A4 | |
| US9319851B2 | United States of America | B2 | |
| US9386425B2 | United States of America | B2 | |
| US9445243B2 | United States of America | B2 | |
| US2016286527A1 | United States of America | A1 | |
| US9473906B2 | United States of America | B2 | |
| US2016373902A1 | United States of America | A1 | |
| BR112015024197A2 | Brazil | A2 | |
| BR112015024335A2 | Brazil | A2 | |
| BR112015024337A2 | Brazil | A2 | |
| BR112015024338A2 | Brazil | A2 | |
| US10028109B2 | United States of America | B2 | |
| US10080109B2 | United States of America | B2 | |
| US2018359614A1 | United States of America | A1 | |
| CN104813690B | China | B | |
| CN104854888B | China | B | |
| EP2829088B1 | European Patent Office (EPO) | B1 | |
| CN104871570B | China | B | |
| EP2829090B1 | European Patent Office (EPO) | B1 | |
| CN110035398A | China | A | |
| EP2829089B1 | European Patent Office (EPO) | B1 | |
| EP2859741B1 | European Patent Office (EPO) | B1 | |
| CN110062338A | China | A | |
| CN104813691B | China | B | |
| ES2740849T3 | Spain | T3 | |
| ES2749196T3 | Spain | T3 | |
| ES2751477T3 | Spain | T3 | |
| ES2751481T3 | Spain | T3 | |
| US10687179B2 | United States of America | B2 | |
| CN110062338B | China | B | |
| CN110035398B | China | B |
46 transactions on the USPTO file
Allowed after 1 non-final rejection.
- Non-final rejections
- 1
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Filing Receipt - CorrectedFLRCPT.C | FLRCPT.C | |
| FITF set to YES - revise initial settingFTFS | FTFS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| FITF set to NO - revise initial settingFTFI | FTFI | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Sent to Classification ContractorPGPC | PGPC | |
| Application Is Now CompleteCOMP | COMP | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Cleared by OIPE CSRL194 | L194 | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Entity status set to undiscounted (initial default setting or status change)BIG. | BIG. | |
| Initial Exam Team nnIEXX | IEXX |
5 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 20140286222
- Publication, DOCDB
- 2014286222
- Publication, EPODOC
- US2014286222
- Application
- 14221631
- Application, DOCDB
- 201414221631
- Application, EPODOC
- US201414221631
Titles
- English
- Group Communication over LTE eMBMS
Patent term adjustment
- A delay
- +140 daysthe office missed an examination deadline
- Applicant delay
- −54 days
- Net adjustment
- 86 days
Classification
- CPC, 17
- H04W4/08
- H04W4/10
- H04W36/08
- H04W72/00
- H04W74/006
- H04W36/30
- H04W36/322
- H04W36/32
- H04W36/0007
- H04W76/40
- H04W72/30
- H04W4/06
- H04L5/0037
- H04L12/185
- H04L12/1886
- H04W24/08
- H04W72/121
- IPC, 2
- H04W4 08
- H04W4 10
- USPC, 1
- 370312000