WO2021237526A1

WO2021237526A1 - Methods and apparatus of rlc based reliable multicast transmission

Info

Publication number: WO2021237526A1
Application number: PCT/CN2020/092682
Authority: WO
Inventors: Xuelong Wang
Original assignee: Mediatek Singapore Pte. Ltd.
Priority date: 2020-05-27
Filing date: 2020-05-27
Publication date: 2021-12-02

Abstract

Apparatus and methods are provided to support reliable multicast transmission. A new multicast radio bearer structure with associated unicast RLC channel is proposed to enable reliable multicast transmission. The associated unicast RLC channel is used for both uplink feedback and downlink retransmission. During transmission mode switch from multicast to unicast for the UE, the associated unicast RLC channel is transited into uncast RB. Lossless handover is achieved via RLC layer packets based data forwarding during the mobility for the multicast transmission for the UE.

Description

Methods and apparatus of RLC based Reliable Multicast Transmission

BACKGROUND

Field of the Disclosure

Aspects of the present disclosure relate generally to wireless communication systems, and more particularly, to enable reliable multicast transmission for multicast and broadcast service.

Description of the Related Art

3GPP specified the support for MBMS transmission, which is based on UMTS or EUTRAN technology. MBMS technology can be used to transmit both TV broadcast, video streaming, etc. In addition, the software update can be also based on the multicast or broadcast for some mobile devices e.g. IoT devices.

For both UMTS and EUTRAN, the traditional MBMS service is subject to reliable transmission by back of uplink feedback and downlink retransmission. During the study for LTE based MBMS transmission, there is a study on the benefit when supporting HARQ based feedback in order to allow the base station to perform the link adaptation more accurate.

In Dec 2019, 3GPP approved a work item (WI) on the support of NR Broadcast and Multicast Services. The application of NR Broadcast and Multicast technology includes V2X use case, public safety usage, video streaming transmission, software upgrade, etc. Reliable multicast transmission is one of the objectives in the WI.

In this invention, it is sought to achieve reliable multicast transmission for Multicast and Broadcast Service.

BRIEF SUMMARY

A method is provided to support reliable multicast transmission. A new multicast radio bearer structure with associated unicast RLC channel is proposed in the disclosure to enable reliable multicast transmission. The associated unicast RLC channel is used for both uplink feedback and downlink retransmission. During transmission mode switch from multicast to unicast for the UE, the associated unicast RLC channel is transited into uncast RB.

Lossless handover is achieved via RLC layer packets based data forwarding during the mobility for the multicast transmission for the UE. Different scenarios are supported for UE mobility considering the contiguous reception of the multicast sessions.

Specific to multicast to multicast handover, the RLC entity of the associated unicast RLC channel in the source node forwards the unacknowledged RLC packets to the RLC entity of the associated unicast RLC channel in the target node. The RLC entity of the associated unicast RLC channel in the target node performs the transmission of the forwarded RLC packets after handover to the UE.

To ensure needed service continuity and at the same time avoid redundant packet forwarding, a counter may be used to control the amount of packets, which are subject to data forwarding. Alternatively, a timer can be used to serve the same purpose.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description, briefly summarized above, may be had by reference to aspects, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only certain typical aspects of this disclosure and therefore not to be considered limiting of its scope, for the descriptions may admit to other equally effective aspects.

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

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

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

Figure 3 illustrates an exemplary PTM RB reception structure to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 4 illustrates an exemplary PTM RB reception structure to enable inter-RLC entity coordination for reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 5 illustrates an exemplary multicast->unicast switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 6 illustrates an exemplary multicast->unicast switch with multicast RB kept after switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 7 illustrates an exemplary unicast->multicast switch with multicast RB remaining before switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 8 illustrates an exemplary unicast->multicast switch with multicast RB established after switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 9 illustrates an exemplary multicast-> multicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 10 illustrates an exemplary multicast-> unicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 11 illustrates an exemplary unicast -> multicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

Figure 12 illustrates an exemplary unicast -> unicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure.

DETAILED DESCRIPTION

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, such as enhanced mobile broadband targeting wide bandwidth, millimeter wave targeting high carrier frequency, massive machine type communications targeting non-backward compatible MTC techniques, and/or mission critical targeting ultra-reliable low-latency communications. These services may include latency and reliability requirements. These services may also have different transmission time intervals (TTI) to meet respective quality of service (QoS) requirements. In addition, these services may co-exist in the same subframe.

Figure 1 (a) is a schematic system diagram illustrating an exemplary Base Station (i.e. BS) , in accordance with certain aspects of the present disclosure. 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, in accordance with certain aspects of the present disclosure. 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, in accordance with certain aspects of the present disclosure. 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.

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 common 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/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 is a clear requirement on the reliable transmission for NR multicast/broadcast services. But the characteristics of multicast/broadcast transmission does not allow the network to ensure all the UEs to make successful reception for the services. Otherwise, the network should apply very conservative link adaptation, which may impact the radio resource utilization efficiency.

The current RLC UM node cannot be used to support reliable transmission for multicast/broadcast transmission from L2 perspective, as there is no feedback mechanism and reliable transmission is difficult to achieve. If RLC AM node is used for multicast/broadcast transmission, the transmission window may face the difficulty to slide the transmission window at RLC, since different feedback may be reported by the UEs and the TX window may be stalled because of the repeated retransmission for the acknowledged packets for some particular UEs.

In order to support the reliable transmission for NR multicast/broadcast service, a feedback channel in the uplink is needed for each UE receiving the service, which can be used by the receiving UE to feedback its reception status on the service. Based on the feedback, the network may perform necessary retransmission to improve the transmission reliability. From uplink feedback perspective, the feedback channel may be used for both HARQ feedback and L2 feedback (i.e. ARQ feedback) . In addition, the feedback should be a bidirectional channel between the UE and the network, with the assumption that the network may take that channel to perform needed packet retransmission. The packet retransmission can be HARQ retransmission or RLC ARQ retransmission or both of them.

In one embodiment, The UE’s HARQ feedback on the reception of the point-to-multipoint HARQ transmission can be sent over the unicast feedback channel to the network. The network can retransmit the transmission block (TB) according to the reception of the HARQ feedback for a particular UE. In this manner, the point-to-multipoint HARQ transmission can continue even though there is a need to perform HARQ retransmission on a particular point-to-multipoint transmission block (TB) towards a particular UE. A threshold can be configured on the maximum HARQ retransmission that can be performed at the unicast channel for the point-to-multipoint transmission block (TB) . If the UE still did not successfully receive the point-to-multipoint transmission block (TB) after the maximum HARQ retransmission, the L2 based retransmission can be used.

In one embodiment, The UE’s ARQ feedback on the reception of the point-to-multipoint ARQ transmission at RLC layer can be sent over the unicast feedback channel to the network. The network can retransmit the RLC packets or its segmentation according to the reception of the ARQ feedback for a particular UE. In this manner, the point-to-multipoint RLC packets can continue even though there is a need to perform RLC retransmission on a particular point-to-multipoint towards a particular UE. A threshold can be configured on the maximum RLC retransmission that can be performed at the unicast channel for the point-to-multipoint transmission. If the UE reaches the maximum RLC retransmission, UE can be switched from multicast transmission to unicast transmission.

This said bidirectional feedback channel should be created in unicast manner per UE. The benefit to establish separate unicast channels for the UEs is that when there is a need for performing retransmission for multicast packets, the packets can be delivered over the unicast channel specific to the UE. In this manner, the downlink multicast transmission is not delayed/stalled by the potential retransmission required by a limited number of UEs.

There are different ways to construct the unicast channel for each UE participating the reception of the multicast radio bearer. In this disclosure, the unicast channel is an RLC channel associated with the point-to-multipoint radio bearer for the UE.

Figure 3 illustrates an exemplary PTM RB reception structure to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. Specific to the NR multicast/broadcast service requiring reliable transmission, a separate associated RLC unicast channel is established between each UE and the network to assist the point-to-multipoint transmission. The associated unicast RLC channel should be in RLC AM mode. It is used for Uplink RLC feedback, i.e. the UE can report RLC Status Report, the reception status of the RLC packets received from the point-to-multipoint (i.e. PTM) radio bearer (s) . It can also be used by the gNB to perform the downlink retransmission for unacknowledged PTM packets according to the uplink RLC Status Report. The base station can also use this channel to poll the particular UE to report the reception status of the RLC packets received from the air interface for the NR multicast/broadcast service (s) .

In this disclosure, point-to-multipoint radio bearer , point-to-multipoint RB, PTM RB, PTM Radio Bearer, Multicast Radio Bearer, Multicast RB, and MRB are used, which are identical by the mean.

As depicted in Figure 3, each UE participating the reception of the service monitors the PDCCH via both G-RNTI corresponding to the NR multicast/broadcast service and its C-RNTI. Both new data coming from multicast RB and the retransmitted data coming from the associated unicast RLC channel will be combined at the PDCP entity at each UE (UE 1 and UE 2 in Figure 3) . From UE perspective, there exists two leg, one is MRB and the other is RLC channel.

The transmission model for reliable multicast transmission in Figure 3 can be seen as intra-UE DC operation. The PDCP entity within each UE is responsible to reorder the packets coming from different legs before delivering to higher layer.

Figure 4 illustrates an exemplary PTM RB reception structure to enable inter-RLC entity coordination for reliable multicast transmission, in accordance with certain aspects of the present disclosure. On top of Figure 3, there should be a direct interaction between the RLC entity of the associated RLC unicast channel and the RLC entity of the multicast RB for each UE. The RLC entity of the multicast RB needs to send the copy of the RLC packets to the RLC entity of the unicast RLC channel in order to allow it to buffer the packets. The copy of the said RLC packets can be segmented or unsegmented packets coming from PDCP entity of MRB. The copy of the said RLC packets can be the RLC SDU, RLC PDU or the packets handled at RLC layer at any other form. The RLC entity of the unicast RLC channel can remove the buffered packets when they are acknowledged e.g. via RLC status report. The RLC entity of the unicast RLC channel can retransmit the unacknowledged packets to the UE.

From configuration perspective, the same RLC configuration (e.g. the length of RLC SN) is applied to both RLC entities of the multicast RB and the associated unicast RLC channel (s) .

At some point of time, the network may decide to use unicast transmission to transmit the multicast flow to the UE in order to improve the resource utilization efficiency. When there is a need to switch the multicast/broadcast transmission to unicast transmission for the NR multicast/broadcast service, the PDCP entity of multicast flow (s) at the network can simply disable the multicast RB and its corresponding RLC entity. Then the PDCP entity of the network established specific to the NR multicast/broadcast service delivers the new data packets coming from the multicast flow (s) to each RLC entity established for associated RLC unicast channel. In other words, the associated RLC unicast channel can be transited to a unicast RB. When there are multiple UEs, the PDCP entity at the gNB are shared among the UEs from downlink transmission perspective for the multicast flow (s) . From reliable multicast transmission perspective, service continuity is expected during the transmission mode switch.

Figure 5 illustrates an exemplary multicast->unicast switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. As depicted in Figure 5, the multicast RB is removed after the switch from multicast->unicast. Then from UE perspective, the monitoring on the multicast RB is not needed. The network needs to notify this switch to the UE to perform such adaption from UE side. The notification can be any form of RRC message, MAC CE, or L1 DCI.

Figure 6 illustrates an exemplary multicast->unicast switch with multicast RB kept after switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. Figure 6 described the case that the multicast RB is kept after the switch for UE1 from multicast->unicast, in order to support the p-t-m transmission to UE2. This scenario is enabled when UE1 experience problem to follow the p-t-m transmission and more robustness unicast transmission needs to be established for it.

As can be seen from both Figure 5 and Figure 6, the UEs (both UE1 and UE2) inherit the same PDCP entity after the switch from multicast->unicast. It is assumed that the same security handling and ROHC is performed as before the switch. After the switch from multicast to unicast, the associated unicast RLC channel is transited into a unicast RB to support the data transmission for the multicast session in point-to-point (i.e. p-t-p) manner. Specific to the switch from multicast->unicast, the buffered RLC packets in the associated unicast RLC channel can be transmitted after switch by the unicast RB to the UE.

Figure 7 illustrates an exemplary unicast->multicast switch with multicast RB remaining before switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. Figure 7 described the case where the multicast RB is existing before the switch from unicast to multicast. When there is a need to switch the p-t-p transmission to p-t-m transmission for the NR multicast/broadcast service, the PDCP entity of available multicast RB at the network needs to stop sending the data to the unicast RB of UE1. The unicast RB of UE1 is transited into an associated unicast RLC channel to assist the reliable multicast transmission.

Figure 8 illustrates an exemplary unicast->multicast switch with multicast RB established after switch to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. When there is a need to switch the p-t-p transmission to p-t-m transmission for the NR multicast/broadcast service, the network needs to establish a new multicast RB sharing the same the PDCP entity that is performing p-t-p transmission. As depicted in Figure 8, the multicast RB is established after the switch from unicast to multicast. The multicast RB shares the same PDCP entity that is available for p-t-p transmission. And then the PDCP entity in the network side needs to deliver the new data packets to the multicast RLC entity to enable p-t-m based transmission.

For the cases in both Figure 7 and Figure 8, from UE1 perspective, the monitoring on the PDCCH scheduling on the multicast RB is needed after the switch. The network needs to notify this switch to the UE to perform such additional monitoring from UE side. Specific to the switch from unicast to multicast, the undelivered or unacknowledged packets of the RLC entity of the unicast RB for UE1 can be transmitted by the associated unicast RLC channel to the UE after the unicast RB is transited into an associated unicast RLC channel.

After the transmission mode switch from unicast to multicast, or from multicast to unicast, the associated unicast RLC channel or unicast RB can be subject to RRC reconfiguration. During the dynamic transmission mode switch, the SDAP configuration is seen unchanged as there is no change for Multicast session. During the reconfiguration, the same RLC configuration is applied.

The UE (s) with reception of the Multicast/Broadcast services may be subject to movements. If no handover procedure is specified then it is likely that there will be regular interruptions for the reception of these Multicast/Broadcast services. Then it cannot satisfy the QoS requirement of the Multicast/Broadcast service that is expected to take reliable transmission.

There are various scenarios for service continuity specific to the UE receiving the Multicast/Broadcast services. When the target cell does not support or start the multicast transmission for the Multicast/Broadcast service, switching the UE from the source cell to the target cell may enable the target cell to transmit the Multicast/Broadcast service to the UE in unicast manner. Otherwise, the UE can join the available multicast /Broadcast service in the target cell and continue its reception of that service in multicast manner.

Depending on the way (multicast or unicast) for the UE to receive the Multicast/Broadcast service in the source cell, different handling needs to be performed to ensure the service continuity during handover. Overall, according to the description above, there are four different scenarios for UE handover during reception of the Multicast/Broadcast services. The service continuity should be guaranteed for all these scenarios in case of reliable transmission required for the Multicast/Broadcast service. The first scenario is Multicast-> Multicast handover. The second scenario is Multicast->Unicast handover. The third scenario is Unicast-> Multicast handover. The fourth scenario is Unicast-> Unicast handover.

Figure 9 illustrates an exemplary multicast-> multicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. During multicast->multicast switch, it is assumed that the multicast transmission for the NR multicast/broadcast service is already available in the target cell. This means that the p-t-m radio bearer with multicast PDCP entity is already established, and it is running in the target node. Logically, there should be a gap between the reception of the multicast transmission from the source node and the reception of the multicast transmission from the target node. The UE may miss some of the packets of multicast session during that gap when performing handover.

In order to remove the possibility of packet loss during the gap for cell switch for the UE, the undelivered or non-acknowledged packets can be forwarded from source node to the target node, if there is such reliability requirement. The characteristics of the forwarded packets is subject to the radio bearer structure adopted for multicast mobility.

As depicted in Figure 9, the associated unicast RLC channel is available at source node for the UE to support reliable multicast/broadcast transmission. The RLC entity of the multicast RB always sends the copy of the RLC packets to the RLC entity within this unicast RLC channel for the UE. The RLC entity buffers the RLC packets. During multicast-> multicast handover, a new associated unicast RLC channel is established at target node for the UE. The RLC entity buffering the RLC packets from source side needs to forward the unacknowledged and/or undelivered RLC packets to the associated unicast RLC entity in the target node. The configuration of the RLC entities for associated unicast RLC channel between source node and target node should be aligned.

There is a possibility that some packets are forwarded to target and be transmitted to the UE via unicast manner. However, the same data may be transmitted to the UE via multicast radio bearer at the target node. This case will occur if the handover procedure is performed very quickly and the UE immediately joins the multicast reception in the target cell. The reason is that both source node and target node are receiving the data from UPF. It would helpful to make a correct decision at the source node on how many packets are subject to forwarding. Forwarding too many packets to target node will lead to redundant reception at UE side. Forwarding too few packets to target node will lead to reception interruption for the service at UE side. It may be a trade-off between service continuity and resource utilization efficiency.

A counter can be used to control the amount of packets, which are subject to data forwarding. Alternatively, a timer can be used to serve the same purpose. The precise selection of the counter or timer may ensure needed service continuity and at the same time avoid redundant packet forwarding.

Figure 10 illustrates an exemplary multicast-> unicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. During multicast->unicast switch, the target node needs to establish a new unicast radio bearer to transmit the multicast data to the concerned UE. This scenario may be enabled when there is no other UE in the target cell participating the reception of the multicast/broadcast service. In this scenario, it is assumed that the multicast session can be still kept at the source node after UE switch. However, it is also possible that after the handover, the source node switch its p-t-m transmission to p-t-p transmission for the UEs serving by source node if there are only limited number of UEs after the handover.

As depicted in Figure 10, the associated unicast RLC channel is available at source node for the UE to support reliable multicast/broadcast transmission. Then the same RLC packets based data forwarding is performed as the case of multicast-multicast handover. The only difference is that the recipient of the RLC packets is the RLC entity of the new unicast radio bearer established at the target node for the UE. These packets can be transmitted to the UE ahead of any new data coming from the PDCP entity established common to the multicast flow (s) .

In this scenario, from the network perspective, a new N3 GTP-U tunnel needs to be established to deliver the data flow of the multicast/broadcast service from UPF to the target node. Meanwhile, the previous N3 GTP-U tunnel between source cell and UPF may be kept if there are other UEs in that cell receiving that multicast /broadcast service. Hence, the path switch handling for legacy handover operation should not be performed in this case. This means the source side will continue to receive the data flow for that multicast /broadcast service from UPF after data forwarding. Same as multicast-multicast handover, a counter or timer based approach may be used to control the amount of packets which are subject to data forwarding.

Figure 11 illustrates an exemplary unicast -> multicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. During unicast->multicast switch, it is assumed that the transmission for the NR multicast/broadcast service is already available in the target cell. The existing transmission in target node can be in multicast manner serving a large number of UEs. The existing transmission in target node can be also in unicast manner serving a limit number of UEs but the addition of the switched UE triggers the target to transit the unicast transmission for NR multicast/broadcast service to p-t-m radio bearer based transmission.

As depicted in Figure 11, the unicast RB is available at source node for the UE to support reliable multicast/broadcast transmission. Then the same RLC packets based data forwarding is performed as the case of multicast-multicast handover. The only difference is that the sender of the RLC packets is the RLC entity of unicast radio bearer.

If the source node needs to keep the data path from UPF e.g. to support the multicast transmission for other UEs, a counter may be used to control the amount of packets which are subject to data forwarding. Alternatively, a timer can be used to serve the same purpose.

Figure 12 illustrates an exemplary unicast -> unicast handover to enable reliable multicast transmission, in accordance with certain aspects of the present disclosure. In case of unicast-> unicast handover, UE receives the multicast data via unicast manner in both source node and target node.

As depicted in Figure 12, the same RLC packets based data forwarding is performed as the case of multicast-multicast handover. These packets should be transmitted to the UE ahead of any new data coming from the PDCP entity established common to the multicast flow.

If the source node needs to keep the data path from UPF e.g. to support the multicast transmission for other UEs, a counter or timer based approach may be used to control the amount of packets which are subject to data forwarding.

During unicast-> unicast switch, it is possible that the multicast transmission is actually already available in the target cell in unicast manner e.g. only serving another UE. The handover UE joining the multicast reception in the target node does not enable the p-t-m transmission. In this case, there is no multicast path switch over N3 interface.

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 for wireless communications, comprising:

Performing reliable multicast transmission between the UE and the Base Station for Multicast and Broadcast Service (MBS) .
The method of claim 1, wherein the Base Station establishes an associated unicast RLC channel to assist the reliable multicast transmission.
The method of claim 1, wherein the Base Station transit associated unicast RLC channel to a unicast radio bearer during multicast to unicast switch for the transmission of a Multicast and Broadcast Service.
The method of claim 1, wherein the reliable multicast transmission is supported by data forwarding during handover.
The method of claim 4, wherein the data forwarding is performed based on unacknowledged or undelivered RLC packets.