WO2022016364A1

WO2022016364A1 - Methods and apparatus of multicast and broadcast service reception

Info

Publication number: WO2022016364A1
Application number: PCT/CN2020/103241
Authority: WO
Inventors: Xuelong Wang; Yuanyuan Zhang
Original assignee: Mediatek Singapore Pte. Ltd.
Priority date: 2020-07-21
Filing date: 2020-07-21
Publication date: 2022-01-27
Also published as: EP4169188A1; WO2022017248A1; CN115836497A

Abstract

This disclosure describes methods and apparatus of supporting multicast broadcast reception at UE side. A UE can receive both PTM transmission leg and PTP transmission leg by receiving different logical channels. The multicast broadcast data is subject to duplicated transmission at PTM leg and PTP leg. The UE can combine the data received from both PTM transmission leg and PTP transmission leg and discard the duplicated packets after combining.

Description

METHODS AND APPARATUS OF MULTICAST AND BROADCAST SERVICE RECEPTION

FIELD OF THE INVENTION

The present disclosure relates generally to communication systems, and more particularly, the method of enabling multicast broadcast service reception at UE side to support multicast broadcast service delivery from the wireless network to the UEs.

BACKGROUND

Various cellular systems, including both 4G/LTE and 5G/NR systems, may provide a multicast functionality, which allows user equipments (UEs) in the system to receive multicast services transported by the cellular system. A variety of applications may rely on communication over multicast transmission, such as live stream, video distribution, vehicle-to-everything (V2X) communication, public safety (PS) communication, file download, and so on. In some cases, there may be a need for the cellular system to enable reliable multicast transmission in order to ensure the reception quality at the UE side. In these cases, it may be beneficial for the receiving UE to provide the feedback on its reception of the multicast transmission, which helps the network to perform necessary retransmission of the content to the UE.

SUMMARY

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE receives both PTM transmission leg and PTP transmission leg from the RAN node to enable the reliable multicast reception for a particular multicast Radio Bearer. The multicast broadcast service can be duplicated over both PTM transmission leg and PTP transmission leg. The UE needs to combine the data packets received from both PTM and PTP leg and the duplicated packets are discarded.

In another aspect of the disclosure, the UE establishes a single RLC entity to receive the both PTM transmission leg and PTP transmission leg. The UE monitors different RNTI for the reception of PTM transmission leg and PTP transmission leg, as PTM transmission and PTP transmission are carried by independent logical channels.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 (a) is a schematic system diagram illustrating an exemplary Base Station (i.e. BS) , in accordance with certain aspects of the present disclosure.

FIG. 1 (b) is a schematic system diagram illustrating an exemplary UE, in accordance with certain aspects of the present disclosure.

FIG. 2 illustrates an exemplary NR wireless communication system, in accordance with certain aspects of the present disclosure.

FIG. 3 illustrates four exemplary transmission options for multicast broadcast service reception at UE side, in accordance with certain aspects of the present disclosure.

FIG. 4 illustrates an exemplary protocol stack for multicast broadcast service reception with a HARQ leg for duplicated transmission, in accordance with certain aspects of the present disclosure.

FIG. 5 illustrates an exemplary protocol stack for multicast broadcast service reception with a PDCP leg for duplicated transmission, in accordance with certain aspects of the present disclosure.

FIG. 6 illustrates an exemplary protocol stack for multicast broadcast service reception with a PDCP leg for duplicated transmission, in accordance with certain aspects of the present disclosure.

FIG. 7 illustrates an exemplary protocol stack for multicast broadcast service reception with a RLC leg for retransmission, in accordance with certain aspects of the present disclosure.

FIG. 8 illustrates an exemplary protocol stack for multicast broadcast service reception with a PDCP leg for retransmission, in accordance with certain aspects of the present disclosure.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

Aspects of the present disclosure provide methods, apparatus, processing systems, and computer readable mediums for NR (new radio access technology, or 5G technology) or other radio access technology. NR may support various wireless communication services. These services may have different quality of service (QoS) requirements e.g. latency and reliability requirements. Figure 1 (a) is a schematic system diagram illustrating an exemplary Base Station (i.e. BS) . The BS may also be referred to as an access point, an access terminal, a base station, a Node-B, an eNode-B, a gNB, or by other terminology used in the art. As an example, base stations serve a number of mobile stations within a serving area, for example, a cell, or within a cell sector. The Base Station has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signals, and sends them to processor. RF transceiver also converts received baseband signals from processor, converts them to RF signals, and sends out to antenna. Processor processes the received baseband signals and invokes different functions. Memory stores program instructions and data to control the operations of Base Station. Figure 1 (b) is a schematic system diagram illustrating an exemplary UE. The UE may also be referred to as a mobile station, a mobile terminal, a mobile phone, smart phone, wearable, an IoT device, a table let, a laptop, or other terminology used in the art. UE has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signal, and sends them to processor. RF transceiver also converts received baseband signals from processor, converts them to RF signals, and sends out to antenna. Processor processes the received baseband signals and invokes different functional modules to perform features in UE. Memory stores program instructions and data to control the operations of mobile station. Figure 2 illustrates an exemplary NR wireless communication system. Different protocol split options between Central Unit and Distributed Unit of gNB nodes may be possible. In one embodiment, SDAP and PDCP layer are located in the central unit, while RLC, MAC and PHY layers are located in the distributed unit.

The described invention operates in the context of multicast transmission in a cellular system. In certain systems, such as NR systems, NR multicast/broadcast is transmitted in the coverage of a cell. From logical channel perspective, MCCH provides the information of a list of NR multicast/broadcast services with ongoing sessions transmitted on MTCH (s) . At physical layer, MTCH is scheduled by gNB in the search space of PDCCH with G-RNTI scrambled. UE decodes the MTCH data for a multicast session in the multicast PDSCH.

In legacy system supporting MBMS/eMBMS, the radio bearer structure for multicast and broadcast transmission is modelled in an independent way from unicast transmission. Because of the unidirectional transmission for legacy MBMS/eMBMS service, RLC UM node is used for the transmission of multicast/broadcast session. In this case there is no need to make the interaction between multicast and unicast for a particular UE which is in RRC Connected state.

There are two delivery methods for the transmission of MBS packet flows over radio. Point-to-Multipoint (PTM) delivery method means a RAN node delivers a single copy of MBS data packets over radio to a set of UEs. Point-to-Point (PTP) delivery method means a RAN node delivers separate copies of MBS data packet over radio to individual UE.

The RAN node (i.e. gNB) may use PTM, PTP or a combination of PTP/PTM mode to deliver the MBS data of a particular MBS service to the interested UEs within a cell. The support of the simultaneous PTP/PTM delivery method is to cater for the diverse handling for the UEs for the MBS service reception e.g. radio resource utilization scheme, different QoS requirements. In addition, taking account of the requirement to support reliable multicast transmission, a companion PTP delivery leg may be used to perform UE specific retransmissions. Then from the RAN node perspective, there are four delivery modes available to deliver MBS data over the air interface: PTM only transmission, PTP only transmission, PTM and PTP (with PTP for initial transmission) and PTM and PTP (with PTP only for retransmission) .

It should be noted that when the RAN node configures both PTM leg and leg for MBS data delivery for a particular MBS session, some UEs may only receive the PTM leg, some UEs may only receive PTP, and some UEs may receive both PTM and PTP. From UE reception perspective, corresponding to the delivery modes adopted by the RAN node, there are also different options to model the reception behavior, which is shown in Figure 3.

Option 1 (only receiving PTM leg) : UE only receives the PTM leg regardless if there is any other PTP legs established by the network for other UEs. From UE perspective, the reliable reception is not expected in this case. This option requires the RAN node to establish a PTM leg for the transmission of a particular MBS session.

Option 2 (only receiving PTP leg) : UE only receives the PTP leg regardless if there is ongoing PTM legs established for other UEs by the network. From UE perspective, the reliable reception can be expected if required in this case. This option requires the RAN node to establish UE specific PTP leg (s) for the transmission of a particular MBS session.

Option 3 (receiving both PTM and PTP leg) : UE receives the initial transmission of the MBS data from both PTM leg and PTP leg. It assumes the RAN node establishes both PTM leg and UE specific leg for the UE. The RAN node delivers the data in a duplicated manner to both PTM leg and UE specific leg. During MBS reception, UE combines the received data from two legs and discards the duplicated data if any.

Option 4 (receiving both PTM and PTP leg with PTP for only retransmission) : UE receives the initial transmission of the MBS data from PTM leg. UE receives the retransmission of MBS data from PTP leg. It assumes the RAN node establishes both PTM leg and UE specific leg for the UE. However the PTP leg is only used for data retransmission based on UE specific uplink feedback. During MBS reception, UE combines the received data from two legs.

Depending on the protocol layer to handle the uplink feedback, duplicated reception or the reception on the retransmitted data at PTM leg and/or PTP leg, the following alternatives can be obtained for UE reception of the multicast broadcast service (MBS) :

■ Alt-1A: PTM only reception without provisioning of UL feedback, which is legacy PTM reception;

■ Alt-1B: PTM only reception with HARQ layer uplink feedback;

■ Alt-2A: PTP only reception without provisioning of UL feedback, which is legacy PTP reception;

■ Alt-2B: PTP only reception with HARQ layer uplink feedback, which is legacy PTP reception;

■ Alt-2C: PTP only reception with RLC layer uplink feedback, which is legacy PTP reception;

■ Alt-2D: PTP only reception with PDCP layer uplink feedback, which is legacy PTP reception;

■ Alt-3B: PTM/PTP reception with duplicated HARQ reception over PTM/PTP leg

■ Alt-3C: PTM/PTP reception with duplicated RLC reception over PTM/PTP leg

■ Alt-3D: PTM/PTP reception with duplicated PDCP reception over PTM/PTP leg

■ Alt-4B: PTM/PTP reception with HARQ layer uplink feedback (the reception of the PTP leg is for HARQ retransmission)

■ Alt-4C: PTM/PTP reception with RLC layer uplink feedback (the reception of the PTP leg is for RLC retransmission)

■ Alt-4D: PTM/PTP reception with PDCP layer uplink feedback (the reception of the PTP leg is for PDCP retransmission)

For Alt-1A, there are cases where only PTM based reception without UL feedback is allowed for MBS reception, for example, the reception of the delivery of the broadcast application. In this option, no feedback is provided from the UE. The network may perform one shot transmission or perform blind retransmission at HARQ or L2. Following the general principle of legacy PTM RB reception, this option requires the UE to establish a single PDCP entity and RLC entity for downlink reception and the RLC entity runs in receiving only mode.

Alt-1B follows the general principle of Alt-1A. However, in this option, the UE needs to provide the HARQ feedback according to the resource allocation by the RAN node. The HARQ feedback may be used by the network to determine the needed retransmission. The details of this alternative (e.g. HARQ feedback methods based on a group of UEs) is subject to RAN1 discussion.

In case of PTP reception (Alt-2A/2B/2C/2D) , the UE fully follows the legacy behaviour of unicast reception. The network needs to establish an independent UE specific PTP RB for the UE.

The protocol stack of Alt-3B is depicted in Figure 4. As can be seen from Figure 4, UE receives both PTM leg and PTP leg from the perspective of HARQ. For example, UE monitors the G-RNTI scrambled PDCCH for PTM reception and monitors the C-RNTI scrambled PDCCH for PTP reception. In this case, the UE may receive the same TB from both legs. More specifically, the UE may receive the same or different RV version of the same TB from the two legs and then HARQ combining can take place at physical layer. The UE can provide its uplink HARQ feedback to the network based on the result of the HARQ combining for a particular TB, with the expectation to receive the HARQ retransmission for the same TB. From RAN node side, the multicast data will be duplicated over PTM and PTP legs at HARQ layer with different HARQ entities or different HARQ process.

The protocol stack of Alt-3C is depicted in Figure 5. As can be seen from Figure 3, UE receives both PTM leg and PTP leg from the perspective of RLC in a single DRB. In this case, the UE may receive the same PDCP packets from both transmission legs. The UE uses two RLC entities to receive the two legs since the packets are allocated SN by different RLC entities at network side. The UE reception behavior is a bit like the DC based reception. At PDCP layer, the UE can combine the received data packets and discard the duplicated packets if any. The UE can provide its independent uplink HARQ feedback to the network based on the reception of each transmission leg, then there is no HARQ combination between the two legs. From RAN node side, the multicast data will be duplicated over PTM and PTP legs like the handling of DC. There is a variant implementation of Alt-3C, where the RLC SN allocation functionality of the PTM leg and PTP leg can be combined together, and then the RLC data packets delivered over PTM leg and PTP leg shares consistent RLC SN. In this variant implementation, the UE can use a single RLC entity to receive both PTM leg and PTP leg and discard the redundant RLC data packets based on the examination of the RLC SN of the data packets.

The protocol stack of Alt-3D as depicted in Figure 6 follows the same principle of Alt-3C. The difference is that the multicast data will be duplicated over PTM and PTP legs at PDCP layer. The UE performs the PTP and PTM reception together. From the UE reception perspective, the UE should use two RLC entities to receive the data from PTM and PTP legs. There is unified SN allocation for the PDCP packets at the network side, so then the UE’s PDCP entity can combine the packets received from PTM leg and PTP leg. From RAN node side, the multicast data will be duplicated over PTM and PTP legs at PDCP layer.

The protocol stack of Alt-4B is the same as Alt-3B, as depicted in Figure 4. The difference is that from PTP leg the UE can only receive the HARQ retransmission of a TB. Then the UE always receive different RV version of the same TB from the two legs. HARQ combining can take place at physical layer. The UE can provide its uplink HARQ feedback to the network based on the result of the HARQ combining for a particular TB, with the expectation to receive the HARQ retransmission for the same TB from PTP leg. From RAN node side, the initial transmission of the TB for the multicast data take place at PTM leg and the retransmission of the RB takes place at PTP leg. The HARQ transmission may be supported by different HARQ entities or different HARQ process. The details of this alternative is subject to RAN1 discussion.

As depicted in Figure 7 for Alt-4C, at UE side, the UE performs the PTP and PTM reception together. Monitoring the PTP leg is only for purpose of the reception of the retransmitted RLC packets. The UE establishes a single/combined DRB and a single PDCP entity to receive both PTM leg and PTP leg. The UE can establish a single RLC entity to receive the two legs. UE monitors two independent LCHs (one for PTM data and the other for PTP data) via different RNTIs. UE assembles the data packets from two independent LCHs at RLC, since it assumes the SN is aligned, as the SN is supposed to be allocated by a single RLC SN allocation function block at network side. In uplink, UE provides the uplink feedback (i.e. RLC status report) to the network, when there is a Polling Request received for the multicast transmission. From network side. There are independent RLC functions supported at network side for each UE. It should be noted that the PTP RLC functions only part of RLC entity functions as there is no SN allocation function. The PDCP packets are delivered to a common RLC SN allocation function block at RLC layer. The PTM RLC entity runs for initial PTM transmission. Any transmission in PTP (or unicast manner) is for PTP Retransmission. There may be retransmission buffer implemented at each UE specific RLC AM entity following legacy principle.

As depicted in Figure 8 for Alt-4D, at UE side, the UE performs the PTP and PTM reception together like Alt-4C. Monitoring the PTP leg is only for purpose of the reception of the retransmitted PDCP packets. The UE establishes a single/combined DRB and a single PDCP entity to receive both PTM leg and PTP leg. The UE can establish a two RLC entities to receive the two legs and both runs in RLC UM mode. UE monitors two independent LCHs (one for PTM data and the other for PTP data) via different RNTIs. UE assembles the data packets from two independent LCHs at PDCP, since it assumes the SN is aligned, as the SN is supposed to be allocated by a single PDCP SN allocation function block at network side. In uplink, UE provides the uplink feedback (i.e. PDCP status report) to the network, when there is a Polling Request received for the multicast transmission. From network side. There are independent PDCP functions supported at network side for each UE. It should be noted that the PTP PDCP functions only part of RLC entity functions as there is no SN allocation function. The SDAP packets are delivered to a common PDCP SN allocation function block at PDCP layer. The PTM PDCP entity runs for initial PTM transmission. Any transmission in PTP (or unicast manner) is for PTP Retransmission. There may be retransmission buffer implemented at each UE specific PDCP AM entity following legacy principle.

Based on UE reception options as mentioned, the UE reception option can be switched according to the decision made by the network. There are different cases for PTM/PTP switch from UE reception perspsective and each case needs different handling in order to enable service continuity during the PTM/PTP switch for the UE.

Case 1 is Option 1 (only receiving PTM leg) -> Option 2 (only receiving PTP leg) . During the PTM/PTP switch based on case 1, the data packets as delivered by the PTP leg needs to be consistent with the data packets as previously delivered by PTM leg, in order to ensure the service continuity. Specifically, if the PTM/PTP switch is implemented at HARQ, the next multicast TB from upper layer needs to deliver to PTP HARQ entity and the UE needs to monitor C-RNTI scrambled PDCCH for the PTP leg reception. If the PTM/PTP switch is implemented at L2, the next L2 packets transmitted to the UE via PTP leg needs to inherit the Sequence Numbering from PTM leg. In order to keep service continuity, the UE is expected to receive the non-successfully received data packets (from previous leg) after the switch from the new leg.

Case 2 is Option 2 (only receiving PTP leg) -> Option 1 (only receiving PTM leg) . During the PTM/PTP switch based on case 2, the data packets as delivered by the PTM leg needs to be consistent with the data packets as previously delivered by UE specific PTP leg, in order to ensure the service continuity. The challenge here is that the network cannot ensure the service continuity for multiple UEs simultaneously. If the RAN node has already established PTM leg for other UEs, the precondition for service continuity for the current UE is that the PTM HARQ entity and the PTP HARQ entity always transmit the same TB if the PTM/PTP switch is implemented at HARQ, or PTM leg and PTP leg shares the Sequence Numbering at L2 if the PTM/PTP switch is implemented at L2. If the RAN node has to establish the PTM leg for multiple UEs, the precondition for service continuity for all of the involved UE is that all of the UE specific PTP HARQ entities transmit the next multicast TB (as supposed to go to PTM HARQ entity) from upper layer if the PTM/PTP switch is implemented at HARQ, or all of the UE specific PTP legs transmit the next L2 packet (as supposed to go to PTM leg) if the PTM/PTP switch is implemented at L2. In order to keep service continuity, the UE is expected to receive the non-successfully received data packets (from previous leg) after the switch from the new leg.

Case 3 is Option 2 (only receiving PTP leg) -> Option 3 (receiving both PTM and PTP) . During the PTM/PTP switch based on case 3, it is required that the UE is able to combine the data packets from both PTM leg and PTP leg after the PTM/PTP switch. As the PTP leg is still kept, the case is in a better position to keep the service continuity, since the UE can receive the non-successfully received data packets after the switch from the PTP leg. The data transmission consistency requirement is the same as Case 2.

Case 4 is Option 2 (only receiving PTP leg) -> Option 4 (receiving PTM&PTP but PTP is only for retransmission) . During the PTM/PTP switch based on case 4, it is required that the UE is able to combine the data packets from both PTM leg and PTP leg (for retransmission) after the PTM/PTP switch. As the PTP leg is still kept for retransmission, the case is in a better position to keep the service continuity, since the UE can receive the non-successfully received data packets after the switch from the PTP leg. The data transmission consistency requirement is the same as Case 2. The data transmission consistency requirement is the same as Case 2.

Case 5 is Option 3 (receiving both PTM and PTP) -> Option 2 (only receiving PTP leg) . During the PTM/PTP switch based on case 5, the PTP leg is still kept, the case is in a better position to keep the service continuity, since the UE can receive the non-successfully received data packets after the switch from the PTP leg. The data transmission consistency requirement is the same as Case 1.

Case 6 is Option 4 (receiving PTM&PTP but PTP is only for retx) -> Option 2 (only receiving PTP leg) . During the PTM/PTP switch based on case 6, the PTP leg is still kept, and the UE can receive the non-successfully received data packets after the switch from the PTP leg. The data transmission consistency requirement is the same as Case 1.

At the first place, the dynamic PTM/PTP switch can be handled by HARQ. For example, specific to Case 1 based PTM->PTP Switch, the UE specific PTP transmission leg can be established with a UE specific HARQ entity and the multicast TB is going to the PTP HARQ if there is no valid PTM transmission leg. In this case, the Multicast transmission block (TB) should be transmitted in a duplicated manner over multiple HARQ entity if multiple UEs receive their specific PTP leg (potentially including the PTM HARQ entity serving other UEs in PTM mode) . When the UE did not correctly receive the previous multicast RB via PTM mode before PTM->PTP Switch, there is a risk for the UE to miss this TB when he switches to receive the PTP leg. Then the performance of the service continuity during dynamic PTM/PTP switch is subject to the detailed HARQ operation (e.g. HARQ feedback based HARQ retransmission) during the period, which can be coordinated with RAN1 for its further evaluation.

Secondly, the dynamic PTM/PTP switch can be handled by RLC layer. In this case, we need take the advantage of the RLC layer based uplink feedback. For example, specific to Case 1 based PTM->PTP Switch, the UE specific PTP transmission leg can be established as a RLC transmission leg. During Case 1 based PTM->PTP Switch, the PTM RLC functions at the RAN node can be simply disabled and then the common RLC SN allocation function delivers the new data packets to each UE specific RLC function established. From UE perspective, the protocol stack for data reception is kept but the monitoring on the PTM leg is not needed. The RAN node needs to notify this switch to the UE to perform such adaption from UE side. There may be a case that the multicast RB is kept at RAN node after the switch from PTM->PTP, in order to support the PTM transmission to other UEs. For both RAN node and the UE, the same PDCP entity is used after the switch. During Case 6 based PTM/PTP delivery mode switch (Option 4 -> Option 2) , the PTP leg was already existing for L2 based retransmission. Then it requires to transit the PTP leg to be used for initial transmission. If there is any RLC packets that is subject to retransmission, they should be transmitted over this PTP leg after the delivery mode switch.

Thirdly, the dynamic PTM/PTP switch can be handled by PDCP layer. In this case, we need take the advantage of the PDCP layer based uplink feedback. For example, specific to Case 1 based PTM->PTP Switch, the UE specific PTP transmission leg can be established as a PDCP transmission leg. During Case 1 based PTM->PTP Switch, the PTM PDCP functions at the RAN node can be simply disabled and then the common PDCP SN allocation function delivers the new data packets to each UE specific PDCP function established. From UE perspective, the protocol stack for data reception is kept but the monitoring on the PTM leg is not needed. For both RAN node and the UE, the operation at PDCP is consistent after PTM/PTP switch since the PDCP SN allocation function is maintained. The PDCP feedback should be supported for PDCP based PTM/PTP Switch in order to allow the PDCP based retransmission after PTM/PTP Switch (e.g. for case 6) .

It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes /flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

While aspects of the present disclosure have been described in conjunction with the specific embodiments thereof that are proposed as examples, alternatives, modifications, and variations to the examples may be made. Accordingly, embodiments as set forth herein are intended to be illustrative and not limiting. There are changes that may be made without departing from the scope of the claims set forth below.

Claims

A method of wireless communication comprising:

Reliable multicast broadcast service reception at UE side to support MBS transmission by the network.
The method of claim 1, wherein the UE receives both PTM transmission leg and PTP transmission leg.
The method of claim 1, wherein the UE combines the data packets received from both PTM transmission leg and PTP transmission leg and discard the redundant data packets.
The method of claim 1, wherein the data packets can be RLC layer packets and PDCP packets.
The method of claim 1, wherein the data packets shares consistent RLC SN.