WO2023065219A1

WO2023065219A1 - Method and apparatus for status reporting for multicast/broadcast service (mbs)

Info

Publication number: WO2023065219A1
Application number: PCT/CN2021/125310
Authority: WO
Inventors: Xin Zhang; Jia SHENG
Original assignee: Huizhou Tcl Cloud Internet Corporation Technology Co., Ltd.
Priority date: 2021-10-21
Filing date: 2021-10-21
Publication date: 2023-04-27
Also published as: CN118140526A

Abstract

Method and apparatus for status reporting for multicast/broadcast service (MBS) in wireless communication. A user equipment (UE) receives a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and transmits a status report including acknowledgement information of data packets accordingly. A base station (BS) transmits a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and receives a status report including acknowledgement information of data packets.

Description

METHOD AND APPARATUS FOR STATUS REPORTING FOR MULTICAST/BROADCAST SERVICE (MBS)

FIELD OF TECHNOLOGY

The present disclosure relates generally to method and apparatus for multicast/broadcast service (MBS) in wireless communication and particularly, but not exclusively, to methods, user equipment and base station for status reporting mechanism for MBS in 5G NR communication system.

BACKGROUND

Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

For 5G NR (New Radio) , multicast and broadcast communications have been deemed to pave the way for resource efficient transmission to multiple end users which have need of receiving same contents. 5G NR did not address multicast and broadcast service in its first phase (Release 15) and second phase (Release 16) packages, with initial focus being on enhanced Mobile Broadband (eMBB) and Ultra-Reliable and Low-Latency Communication (URLLC) . Afterwards in 5G Release 17 (Rel-17) , 3GPP worked on to build functional support of multicast and/or broadcast services abbreviated as MBS over an existing 5G standards framework, and the standardization has been conducted for overall 5G system architecture of Next Generation Radio Access Network (NG-RAN) and 5G Core Network (5GC) perspectives.

MBS in Rel-17 requires significantly less operations, administrations and maintenance effort than its 4G predecessor, called as Evolved Multimedia Broadcast Multicast Service (eMBMS) , as well as improving resource efficiency. MBS for 5G NR is primarily intended to support use cases which require to achieve same levels of high reliability and low latency as available with unicast services. The key feature of reliability enhancement includes mixed unicast/multicast services by dynamically switch between Point-to-Multipoint (PTM) and Point-to-Point (PTP) transmissions for MBS radio bearers (MRB) . An MRB fills the same role as a traditional data radio bearer (DRB) for unicast and delivers IP multicast data to a user equipment (UE) . The MRB may be split into a PTM leg and a PTP leg. Thereby, data loss may occur due to MBS bearer type change, for instance, when UE switches to PTP and stop PTM monitoring immediately upon receiving a PTM/PTP switching command, and the transmission of the packets for PTM are yet to be completed. In addition, data loss may occur due to state variables initialization for MRB configuration. For Packet Data Convergence Protocol (PDCP) state variables initialization when MRB is configured, out-of-order delivery of PDCP Data PDUs and the discarding mechanism for the received PDCP Data PDU may lead to packet loss during data transmission. Likewise, for RLC state variables initialization when MRB is configured, out-of-order delivery of Unacknowledged Mode Data (UMD) PDU and the discarding mechanism for the received UMD PDU may lead to packet loss during data transmission.

BRIEF SUMMARY

The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

An object of the present disclosure is to propose method and apparatus for status reporting mechanism for multicast and/or broadcast service (MBS) in 5G NR wireless communication.

According to a first aspect, one or more embodiments of the present disclosure provide a method for status reporting for MBS, executable in a user equipment (UE) for wireless communication, comprising: receiving a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and transmitting a status report including acknowledgement information of data packets accordingly.

According to a second aspect, one or more embodiments of the present disclosure provide a user equipment (UE) for MBS in wireless communication, comprising: processing circuitry configured to receive a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and transmit a status report including acknowledgement information of data packets accordingly.

According to a third aspect, one or more embodiments of the present disclosure provide a method for status reporting for MBS, executable in a base station (BS) for wireless communication, comprising: transmitting a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and receiving a status report including acknowledgement information of data packets.

According to a fourth aspect, one or more embodiments of the present disclosure provide a base station (BS) for MBS in wireless communication, comprising: processing circuitry configured to transmit a signaling including a request of MBS bearer type change, and/or a request of state variables initialization for at least one MBS radio bearer (MRB) configuration; and receive a status report including acknowledgement information of data packets.

According to a fifth aspect, one or more embodiments of the present disclosure provide a chip. The chip may include a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above methods.

According to a sixth aspect, one or more embodiments of the present disclosure provide a non-transitory machine-readable medium having stored thereon instructions that, when executed by a computer, cause the computer to execute the methods above. The non-transitory machine-readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read-Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read-Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

According to a seventh aspect, one or more embodiments of the present disclosure provide a computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the above methods.

According to an eighth aspect, one or more embodiments of the present disclosure provide a computer program product, comprising a computer program, wherein the computer program causes a computer to execute the above methods.

According to a ninth aspect, one or more embodiments of the present disclosure provide a computer program, which causes a computer to execute the above methods.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present disclosure or related art, the following figures which will be described in the embodiments are briefly introduced. These drawings should not be construed to limit the present disclosure.

FIG. 1 illustrates a schematic view showing the legacy handover (HO) procedure between source gNB (S-gNB) and target gNB (T-gNB) .

FIG. 2 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when MBS bearer type change and PTM/PTP switching command is not included in RRC reconfiguration message.

FIG. 3 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when MBS bearer type change and PTM/PTP switching command is included in RRC reconfiguration message.

FIG. 4 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when MBS bearer type change without RRC reconfiguration message.

FIG. 5 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when MBS bearer type change and PTM/PTP switching command is included in RRC reconfiguration message without the request of a PDCP entity re-establishment or a PDCP data recovery.

FIG. 6 illustrates a schematic view showing the legacy mechanism of triggering PDCP status report and re-transmission of PDCP SDUs by HO.

FIG. 7 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting before the completion of MBS bearer type change.

FIG. 8 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting after the completion of MBS bearer type change.

FIG. 9 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting after the completion of MBS bearer type change and the union of lost PDCP SDUs for the two UEs are to be re-transmitted in PTM mode.

FIG. 10 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting after the completion of MBS bearer type change and the intersection of lost PDCP SDUs for the two UEs are to be re-transmitted in PTM mode.

FIG. 11 illustrates a schematic view showing an embodiment of the disclosed method for triggering RLC status reporting when MBS bearer type change with RLC polling mechanism.

FIG. 12 illustrates a schematic view showing an embodiment of the disclosed method for triggering RLC status reporting when MBS bearer type change without polling mechanism.

FIG. 13 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when PDCP state variables initialization for MRB configuration.

FIG. 14 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when PDCP state variables initialization for HO in MBS data transmission.

FIG. 15 illustrates a schematic view showing an embodiment of the disclosed method for triggering PDCP status reporting when PDCP state variables initialization for MRB configuration under the condition of radio link failure.

FIG. 16 illustrates a schematic view showing an example of a base station (BS) .

FIG. 17 illustrates a schematic view showing an example of a user equipment (UE) .

DETAILED DESCRIPTION

Embodiments of the present disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not limit the scope of the present disclosure.

Reference in the specification to “one embodiment” , “an embodiment” , “one or more embodiments” or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Moreover, the term “embodiment” in various places in the specification is not necessarily referring to the same embodiment. That is, various features are described which may be exhibited by some embodiments and not by other embodiments.

5G NR (New Radio) is on the evolution path with present focus on enabling advanced features and new service capabilities, in which multicast and broadcast service (MBS) is being considered as one of the promising features of the new standard for wireless communication. MBS for 5G NR is primarily intended to support important use cases including mission-critical push-to-talk for public safety, software delivery over wireless, IPTV, Vehicle-to-Everything (V2X) , group communications and IoT applications, which requires to achieve same levels of high reliability and low latency as available with unicast services. In particular, mission-critical delay-sensitive signaling and high-resolution IPTV require to achieve same levels of high reliability and low latency as available with unicast services, and consequently demand for an involved protocol stack design with layers and functionalities which could enhance the reliability and latency performance.

Rel-17 allows for the feature supporting multicast sessions to user equipment (UE) in Radio Resource Control (RRC) connected state, as well as supporting broadcast sessions to UE in RRC connected, inactive and idle states. The feature supporting broadcast sessions for UEs in inactive and idle states is important to support maximum capacity for the broadcast service. Part of the feature is the support for group scheduling, mobility for service continuity and configurable feedback for reliability when needed.

For broadcast services in MBS, it can maintain broadly same requirements like those in Evolved Multimedia Broadcast Multicast Service (eMBMS) , and so inherit many design features.

For multicast service continuity in MBS, dynamic switch between Point-to-Multipoint (PTM) and Point-to-Point (PTP) transmissions has been agreed, and base station (BS) , e.g., gNodeB (gNB) , may dynamically decide whether to deliver multicast data by PTM or PTP for a user equipment (UE) . For instance, the network may adapt the transmissions to the actual link quality and may then take all UEs in a PTM group into account to optimize the transmissions.

MBS radio bearers (MRB) denotes radio bearers carrying both multicast and broadcast sessions. An MRB fills the same role as a traditional data radio bearer (DRB) for unicast and delivers IP multicast data to UEs. The MRB may be split into a PTM leg and a PTP leg. The PTM leg supports true PTM transmission. The PTP leg behaves essentially as traditional bi-directional unicast but is logically separated from the unicast functionality of the DRB, which may be used in parallel. Both legs, PTM and PTP, inherit most parts of the legacy 5G NR protocol stack, with Packet Data Convergence Protocol (PDCP) , Radio Link Control (RLC) , Medium Access Control (MAC) and Physical Layer (PHY) . Dynamic switch of PTM and PTP is supported for a split MRB with a single PDCP entity, while a split MRB may be configured with a PTM leg and a PTP leg. To improve the reliability of MBS delivery, in 5G NR, both PTM legs and PTP legs support re-transmission based on UE feedback. Within PTM leg, re-transmissions can use either PTM or PTP, whichever is the most efficient.

For MBS, data loss may occur under the following THREE scenarios:

The first scenario, MBS bearer type change may lead to data loss. When the multicast service is transferred from the content provider to the gNB, the gNB may choose to deliver the data to the UEs by means of PTP or PTM. For PTP mode, the gNB may allocate dedicated resource to UE, which guarantees high transmission reliability but leads to low resource utilization. For PTM mode, the gNB may allocate shared resource to a group of UEs, and all eligible UEs can receive the service. PTM mode improves the resource utilization, but it is difficult to guarantee the quality of data received by each UE. The gNB can dynamically switch between the two modes. When the PTM receiving quality is low, e.g., due to poor channel state, the gNB may assign a dedicated resource to the UE to transmit in PTP mode. When the UE can receive high quality data through the PTM mode shared resource, the gNB may decide to schedule the UE using the PTM shared resource.

It has been agreed that, for Radio Resource Control (RRC) signaling, one MRB may be configured with PTM only or PTP only or both PTM and PTP. Whether PTM only, PTP only or PTM+PTP may be changed from one to other via RRC signaling. For instance, one UE receives data packets (#1～#3) from a gNB in PTP mode and the other UE receives data packets (#1～#4) from the gNB in PTP mode. Then both UEs perform the switch from PTP to PTM mode as requested. When the gNB starts transmission with data packet (#5) in PTM mode without obtaining the latest status reports from these two UEs, it will lead to the loss of data packet (#4) for the first UE. In addition, when UE switches to PTP and stop PTM monitoring immediately upon receiving a PTM/PTP switching command, data loss may also occur because the packets of PTM leg are still in the air. For the packet used for PDCP sublayer, the “data packet” may refer to PDCP PDU and/or SDU, while for the packet used for RLC sublayer, the “data packet” may refer to RLC PDU and/or SDU. Alternatively, RRC signaling for MBS bearer type change may be replaced by the mechanism operated in other layers or sublayers, e.g. MAC sublayer, which may provide higher efficiency.

In the present disclosure, MBS bearer type change may include SIX modes as follows:

PTM only → PTP only (PTM → PTP) ;

PTP only → PTM only (PTP → PTM) ;

PTM only → PTM + PTP (PTM → PTM + PTP) ;

PTP only → PTM + PTP (PTP → PTM + PTP) ;

PTM + PTP → PTM only (PTM + PTP → PTM) ;

PTM + PTP → PTP only (PTM + PTP → PTP) .

The second scenario, PDCP state variables initialization for MRB configuration may lead to data loss. For PDCP state variables initialization when MRB is configured, out-of-order delivery of PDCP Data PDUs from RLC to PDCP and the discarding mechanism according to the COUNT value of the received PDCP Data PDU may make data loss possible. PDCP sequence number (PDCP SN) , as a part of the COUNT value, is attached to each PDCP Data PDU and the transmitting PDCP entity may maintain the state variables. It has been agreed that, for PTM PDCP state variables setting while configured, the SN part of COUNT values of these variables are set according to the SN of the first received packet (by the UE) and the Hyper Frame Number (HFN) indicated by the gNB, if needed. And as the clause of receive operation which is specified in 3GPP TS 38.323 V16.5.0, when a PDCP Data PDU is received from lower layers, the discarding mechanism includes that, under certain conditions, if RCVD_COUNT < RX_DELIV, the receiving PDCP entity shall discard the PDCP Data PDU. Specifically, RCVD_COUNT refers to the COUNT value of the received PDCP Data PDU, and RX_DELIV is a state variable indicating the COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for, and the COUNT value is composed of a HFN and the PDCP SN.

Due to the out-of-order delivery of PDCP Data PDUs from RLC to PDCP, the PDCP Data PDUs with SNs sent before the first received PDCP Data PDU are to be discarded even if they are correctly received, thus probably causing data loss while MRB configuration.

The third scenario, RLC state variables initialization for MRB configuration may lead to data loss. For RLC state variables initialization when MRB is configured, out-of-order delivery of Unacknowledged Mode Data (UMD) PDU from MAC/PHY to RLC and the discarding mechanism according to the RX_Next_Highest and RX_Next_Reassembly value of the received UMD PDU may make data loss possible. It has been agreed that, when initializing the PTM RLC entity for an MRB configuration, the value of RX_Next_Highest and RX_Next_Reassembly are set according to the SN of the first received packet containing an SN. And as the clause of receive operations which is specified in 3GPP TS 38.322 V16.2.0, when an Unacknowledged Mode Data (UMD) PDU is received from lower layer, the discarding mechanism includes that, under certain conditions, if (RX_Next_Highest –UM_Window_Size) <= SN < RX_Next_Reassembly, the receiving UM RLC entity shall discard the received UMD PDU. Specifically, RX_Next_Highest is the state variable which holds the value of the Sequence Number (SN) following the SN of the RLC Service Data Unit (SDU) with the highest SN among received RLC SDUs, and UM_Window_Size is the constant which is used by the receiving UM RLC entity to define SNs of those UMD SDUs that can be received without causing an advancement of the receiving window, and RX_Next_Reassembly is the state variable which holds the value of the earliest SN that is still considered for reassembly.

Due to the out-of-order delivery of UMD PDU from MAC/PHY to RLC, the UMD PDUs with SNs sent before the first received UMD PDU are to be discarded even if they are correctly received, thus probably causing data loss when switching from PTP to PTM.

Besides, it has been agreed, for multicast session, gNB provides one or more MRB configuration (s) to the UE via dedicated RRC signaling, which supports downlink (DL) only UM RLC configuration for PTM, both DL and uplink (UL) AM RLC configuration for PTP, DL only UM RLC configuration for PTP. And RLC state variables of PTP RLC reception window can be set to initial value due to MRB configuration.

The main idea of this present disclosure is to provide method and apparatus for status reporting mechanism for MBS to address the issue of data loss which may be caused by the above scenarios, including but not limited to MBS bearer type change, PDCP state variables initialization and RLC state variables initialization. The status reporting mechanism may be provided by PDCP status reporting and/or RLC status reporting. By triggering PDCP status reporting and/or RLC status reporting upon MBS bearer type change, PDCP state variables initialization, and/or RLC state variables initialization, the loss of data packet (s) can be resolved during data transfer procedures.

The disclosed methods wherein PDCP status reporting and/or RLC status reporting is triggered when MBS bearer type change and/or state variables initialization for MRB configuration, which is beneficial for resolving the issue of data loss in MBS, and for improving the reliability of MBS, and for guaranteeing MBS service continuity for miscellaneous user cases with higher reliability and lower latency requirements.

PDCP sublayer provides its services to upper layers including the RRC or Service data adaptation protocol (SDAP) layers. PDCP sublayer is configured by RRC and is used for radio bearers (RBs) mapped on Dedicated Control Channel (DCCH) , Dedicated Traffic Channel (DTCH) , Sidelink Control Channel (SCCH) , and Sidelink Traffic Channel (STCH) type of logical channels. Each RB may be associated with one PDCP entity which is located in the PDCP sublayer. Service continuity and lossless mobility is supported in multicast mode. When UE changes its serving cell due to the mobility, e.g., handover (HO) , the support of service continuity is important for users not to experience interruption or performance degradation of the ongoing services. The service continuity of 5G MBS is achieved based on packet-level sequence number (SN) synchronization where the same packet has the same PDCP SN over the area supporting the service continuity. Under an assumption that a UE may receive packets out of order from lower layers, PDCP is used to support the functionality including, but not limiting to, maintenance of PDCP SNs, reordering and in-order delivery, and discarding of duplicates.

For PDCP status reporting, as specified in 3GPP TS 38.323 V16.5.0, for AM DRBs configured by upper layer to send a PDCP status report in the uplink, the receiving PDCP entity shall trigger a PDCP status report when upper layer operates in presupposed conditions as follows:

- upper layer requests a PDCP entity re-establishment;

- upper layer requests a PDCP data recovery;

- upper layer requests an uplink data switching;

- upper layer reconfigures the PDCP entity to release Dual Active Protocol Stack (DAPS) .

For instance, for AM DRBs configured by upper layers to send a PDCP status report in the uplink, the receiving PDCP entity shall trigger a PDCP status report when upper layer requests a PDCP entity re-establishment. The PDCP status report message is transmitted from the receiving PDCP entity to the transmitting PDCP entity in order to inform the transmitting PDCP entity about the PDCP PDUs received or not received by the receiving PDCP entity, and thereby non-received PDCP PDUs are to be re-transmitted.

In addition, for UM DRBs configured by upper layers to send a PDCP status report in the uplink, the receiving PDCP entity shall trigger a PDCP status report when upper layer requests an uplink data switching. And for AM DRBs in the sidelink, the receiving PDCP entity shall trigger a PDCP status report when upper layer requests a PDCP entity re-establishment.

When a PDCP status report is triggered, the receiving PDCP entity shall compile a PDCP status report as required.

As shown in FIG. 1, the legacy handover (HO) procedure of a UE 20 between source gNB (S-gNB) 11 and target gNB (T-gNB) 12 is illustrated. After the completion of a HO between S-gNB and T-gNB, the upper layer requests a PDCP entity re-establishment or requests a PDCP data recovery via RRC reconfiguration message, and then UE will transmit a PDCP status report to T-gNB upon the completion of the HO to T-gNB. As to Rel-17, the completion of HO may trigger a RLC status report as well.

For RLC status reporting, as specified in 3GPP TS 38.322 V16.2.0, an AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative acknowledgements of RLC SDUs (or portions of them) . Triggers to initiate RLC status reporting may include polling from its peer AM RLC entity. An AM RLC entity can poll its peer AM RLC entity in order to trigger status reporting at the peer AM RLC entity. The transmitting side of an AM RLC entity shall include a poll in the AMD PDU according to several presupposed conditions as follows:

- PDU_WITHOUT_POLL >= pollPDU;

- BYTE_WITHOUT_POLL>=pollByte;

- empty transmission buffer and empty re-transmission buffer, e.g., no RLC SDU to transmit for AM RLC entity;

- no new RLC SDU can be transmitted, e.g. due to window stalling;

- Expiry of t-PollRetransmit.

For instance, when PDU_WITHOUT_POLL >= pollPDU, the transmitting side of an AM RLC entity shall include a poll in the AMD PDU. Specifically, PDU_WITHOUT_POLL counts the number of AMD PDUs sent since the most recent poll bit was transmitted, and pollPDU is used by the transmitting side of each AM RLC entity to trigger a poll for every pollPDU PDUs.

In addition, triggers to initiate RLC status reporting may also include detection of reception failure of an AMD PDU. The receiving side of an AM RLC entity shall trigger a status report when t-Reassembly expires. Specifically, t-Reassembly refers to the timer used by the receiving side of an AM RLC entity and receiving UMRLC entity in order to detect loss of RLC PDUs at lower layer.

When status reporting has been triggered, the receiving side of an AM RLC entity shall construct a STATUS PDU and submit it to lower layer as required. As to Rel-17, RLC status reporting mechanism may be applied to UM RLC entity for multicast service as well.

In one or more embodiments as below, status report mechanism is described for the first scenario in which MBS bearer type change may lead to data loss.

FIG. 2 is a flowchart of one embodiment of a method 100 in which PDCP status reporting triggers when MBS bearer type change and the signaling including a PTM/PTP switching command is not included in RRC reconfiguration message with a request of a PDCP entity re-establishment or a PDCP data recovery. The method 100 begins at block 110 where a gNB 10 transmits a RRC signaling including a PTM/PTP switching command to inform a UE 20 for MBS bearer type change. At block 120, the gNB transmits RRC reconfiguration message to the UE, and RRC reconfiguration message includes the request of a PDCP entity re-establishment or a PDCP data recovery. At block 130, the UE performs a switch of PTM and PTP as required. At block 140, the UE transmits a PDCP status report to the gNB upon the completion of the switch of PTM and PTP. Thus, the PDCP status report is transmitted by the UE in the “new” mode, for instance, when the PTM/PTP switching command is for MBR bearer type changing from PTM to PTP, the PDCP status report is transmitted by the UE in PTP mode. A UE may be requested to switch from PTM to PTP due to the poor channel state for PTM transmission, thus it may be beneficial for a UE to transmit a status report in PTP mode for better quality of data transmission.

It should be noted that a PTM/PTP switching command is to notify a UE to perform a switch of PTM and PTP, including the SIX modes of MBS bearer type change described above, which may be applied to all the embodiments in present disclosure.

As an alternative to the embodiment described above, the UE may perform a switch of PTM and PTP as required once receiving the RRC signaling including a PTM/PTP switching command, which means that the switch of PTM and PTP may be performed before receiving the RRC reconfiguration message.

As an alternative to the embodiment described above, RRC reconfiguration message may include a request of an uplink data switching in order to trigger a PDCP status report as well. Likewise, RRC reconfiguration may indicate a PDCP entity reconfiguration to release DAPS in order to trigger a PDCP status report.

FIG. 3 is a flowchart of one embodiment of a method 200 in which PDCP status reporting triggers when MBS bearer type change and the signaling including a PTM/PTP switching command is included in RRC reconfiguration message with a request of a PDCP entity re-establishment or a PDCP data recovery. The method 200 begins at block 210 where a gNB 10 transmits RRC reconfiguration message to a UE 20, and RRC reconfiguration message includes a PTM/PTP switching command as well as the request of a PDCP entity re-establishment or a PDCP data recovery. At block 220, the UE performs a switch of PTM and PTP as required. At block 230, the UE transmits a PDCP status report to the gNB upon the completion of the switch of PTM and PTP.

FIG. 4 is a flowchart of one embodiment of a method 300 in which PDCP status reporting triggers when MBS bearer type change without RRC reconfiguration message. The method 300 begins at block 310 where a gNB 10 transmits a RRC signaling including a PTM/PTP switching command to inform a UE 20 for MBS bearer type change. At block 320, the UE performs a switch of PTM and PTP as required. At block 330, the UE transmits a PDCP status report to the gNB. Thus, RRC reconfiguration is not required in method 300, which shows that it is unnecessary of the gNB to transmit RRC reconfiguration message including a request of a PDCP entity re-establishment or a PDCP data recovery to the UE for triggering a PDCP status report. Considering under certain conditions that a PDCP entity re-establishment or a PDCP data recovery is unnecessary for MBS bearer type change and may consume extra resources, the procedure of triggering a PDCP status report without a PDCP entity re-establishment or a PDCP data recovery may be simplified and be more efficient.

As an alternative to the embodiment described above, the UE may not perform a switch of PTM and PTP as required before transmitting a PDCP status report. And a switch of PTM and PTP may be completed after transmitting a PDCP status report.

FIG. 5 is a flowchart of one embodiment of a method 400 in which PDCP status reporting triggers when MBS bearer type change and the signaling including a PTM/PTP switching command is included in RRC reconfiguration message without a request of a PDCP entity re-establishment or a PDCP data recovery. The method 400 begins at block 410 where a gNB 10 transmits RRC reconfiguration message to a UE 20, and RRC reconfiguration message includes a PTM/PTP switching command but excludes a request of a PDCP entity re-establishment or a PDCP data recovery. At block 420, the UE transmits a PDCP status report to the gNB. Thus, RRC reconfiguration message is transmitted without the request of a PDCP entity re-establishment or a PDCP data recovery, which shows that it is unnecessary of the gNB to transmit a request of a PDCP entity re-establishment or a PDCP data recovery to the UE for triggering a PDCP status report. At block 430, the UE performs a switch of PTM and PTP as required. Thus, under certain conditions that a PDCP entity re-establishment or a PDCP data recovery is not required for MBS bearer type change, RRC reconfiguration message may exclude the request of a PDCP entity re-establishment or a PDCP data recovery, making the procedure of triggering a PDCP status report simpler and more efficient. Thus, the PDCP status report is transmitted before the UE switches to the “new” mode, for instance, when the PTM/PTP switching command is for MBR bearer type changing from PTP to PTM, the PDCP status report is transmitted by the UE in PTP mode. For the case of a UE transmitting a status report in an “old” mode, a gNB may receive the status report as early as possible (if channel state is allowed) , which is beneficial for making following procedures, e.g., re-transmission, timely and efficient.

As an alternative to the embodiment described above, the UE may perform a switch of PTM and PTP as required before transmitting a PDCP status report. Furthermore, a switch of PTM and PTP may be completed after transmitting a PDCP status report.

In one or more embodiments as below, the mechanism of triggering of PDCP status report and re-transmission of PDCP SDUs is described in more details for the first scenario in which MBS bearer type change may lead to data loss. A PDCP SDU may have a corresponding PDCP Data PDU.

As shown in FIG. 6, the legacy mechanism of triggering PDCP status report and re-transmission of PDCP SDUs by a HO is illustrated. For instance, S-gNB 11 transmits PDCP SDUs with SN #1～#5 to a UE 20 and the UE successfully receives the PDCP SDUs with SN #3 and #5. The UE transmits a RLC status report to S-gNB and accordingly S-gNB re-transmits PDCP SDUs with SN #1, #2 and #4. As the UE receives PDCP SDU with SN #1, the UE is to deliver PDCP SDU with SN #1 to upper layer. Meanwhile, S-gNB transmits a HO command as required to the UE and before HO command no RLC status report has been transmitted to S-gNB indicating whether PDCP SDUs with SN #1, #2 or #4 is received or not. Then S-gNB forwards the re-transmission request of PDCP SDUs with SN #1, #2 and #4 to T-gNB even if PDCP SDU with SN #1 is well received by the UE. Upon the completion of the HO, the UE transmits a PDCP status report to T-gNB 12, thereby notifying T-gNB that PDCP SDU with SN #1 is received and PDCP SDUs with SN #2 and #4 is not received yet. Afterwards, T-gNB re-transmits PDCP SDUs with SN #2 and #4 to the UE according to the PDCP status report. As the UE successfully received PDCP SDUs with SN #2 and #4, the UE is to deliver PDCP SDUs with SN #2～#5 to upper layer.

FIG. 7 is a flowchart of one embodiment of a method 500 in which PDCP status reporting triggers before the completion of MBS bearer type change from PTP to PTM for two UEs. The two UEs include the first UE 21 and the second UE 22, which are to be grouped in a PTM group. The method 500 begins at block 511 where a gNB 10 transmits PDCP SDUs with SN #1～#5 to the first UE 21 in PTP mode while the method 500 also begins at block 512 where the gNB 10 transmits PDCP SDUs with SN #1～#5 to the second UE 22 in PTP mode. At block 521 the first UE successfully receives PDCP SDUs with SN #3 and #5 while at block 522 the second UE successfully receives PDCP SDUs with SN #2 and #5. Upon the request of switching from PTP to PTM, at block 531 the gNB transmits a RRC signaling including a PTM/PTP switching command to the first UE while at block 532 the gNB also transmits a RRC signaling including a PTM/PTP switching command to the second UE.At block 541 the first UE transmits a PDCP status report to the gNB upon the receiving of the PTM/PTP switching command while at block 542 the second UE also transmits a PDCP status report to the gNB upon the receiving of the PTM/PTP switching command. At block 551 the gNB re-transmits PDCP SDUs with SN #1, #2 and #4 to the first UE accordingly while at block 552 the gNB re-transmits PDCP SDUs with SN #1, #3 and #4 to the second UE accordingly. At block 561 the first UE receives PDCP SDUs with SN #1, #2 and #4 and delivers PDCP SDUs with SN #1～#5 to upper layer while at block 562 the second UE receives PDCP SDUs with SN #1, #3 and #4 and delivers PDCP SDUs with SN #1～#5 to upper layer. At block 571 the first UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 572 the second UE also performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 580 the gNB transmits PDCP SDUs to the first UE and the second UE simultaneously in PTM mode.

It should be noted that block 511 and block 512, block 521 and block 522, block 531 and block 532, block 541 and block 542, block 551 and block 552, block 561 and block 562, and/or block 571 and block 572 are not required to be performed at precisely the same time.

As an alternative to the embodiment described above, the gNB may transmit RRC reconfiguration message including a PTM/PTP switching command to the first UE and the second UE respectively.

As an alternative to the embodiment described above, RRC reconfiguration message may include a request of a PDCP entity re-establishment or a PDCP data recovery.

As an alternative to the embodiment described above, the first UE and/or the second UE may not transmit a message indicating “the completion of the switch” to the gNB after the completion of the switch from PTP to PTM.

FIG. 8 is a flowchart of one embodiment of a method 600 in which PDCP status reporting triggers after the completion of MBS bearer type change from PTP to PTM for two UEs. The two UEs include the first UE 21 and the second UE 22, which are to be grouped in a PTM group. The method 600 begins at block 611 where a gNB 10 transmits PDCP SDUs with SN #1～#5 to the first UE 21 in PTP mode while the method 600 also begins at block 612 where the gNB transmits PDCP SDUs with SN #1～#5 to the second UE 22 in PTP mode. At block 621 the first UE successfully receives PDCP SDUs with SN #3 and #5 while at block 622 the second UE successfully receives PDCP SDUs with SN #2 and #5. Upon the request of switching from PTP to PTM, at block 631 the gNB transmits a RRC signaling including a PTM/PTP switching command to the first UE while at block 632 the gNB also transmits a RRC signaling including a PTM/PTP switching command to the second UE. At block 641 the first UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 642 the second UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 651 the first UE transmits a PDCP status report to gNB in PTM mode while at block 652 the second UE transmits a PDCP status report to gNB in PTM mode. At block 660 the gNB re-transmits lost PDCP SDUs to the first UE and the second UE simultaneously in PTM mode.

It should be noted that block 611 and block 612, block 621 and block 622, block 631 and block 632, block 641 and block 642, and/or block 651 and block 652 are not required to be performed at precisely the same time.

As an alternative to the embodiment described above, FIG. 9 is a flowchart of one embodiment of a method 700 in which PDCP status reporting triggers after the completion of MBS bearer type change from PTP to PTM for two UEs and the union of lost PDCP SDUs for the two UEs are to be re-transmitted in PTM mode. The two UEs include the first UE 21 and the second UE 22, which are to be grouped in a PTM group. The method 700 begins at block 711 where a gNB 10 transmits PDCP SDUs with SN #1～#5 to the first UE 21 in PTP mode while the method 700 also begins at block 712 where the gNB 10 transmits PDCP SDUs with SN #1～#5 to the second UE 22 in PTP mode. At block 721 the first UE successfully receives PDCP SDUs with SN #3 and #5 while at block 722 the second UE successfully receives PDCP SDUs with SN #2 and #5. Upon the request of switching from PTP to PTM, at block 731 the gNB transmits a RRC signaling including a PTM/PTP switching command to the first UE while at block 732 the gNB also transmits a RRC signaling including a PTM/PTP switching command to the second UE. At block 741 the first UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 742 the second UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 751 the first UE transmits a PDCP status report to gNB in PTM mode while at block 752 the second UE transmits a PDCP status report to gNB in PTM mode. According to the status reports transmitted by the first UE and the second UE, the union of lost PDCP SDUs are PDCP SDUs with SN #1～#4. Therefore, at block 760 the gNB re-transmits PDCP SDUs with SN #1～#4 to the first UE and the second UE simultaneously in PTM mode. At block 771 the first UE successfully receives PDCP SDUs with SN #1～#4, and discards PDCP SDU with SN #3, and delivers PDCP SDUs with SN #1～#5 to upper layer. At block 772 the second UE successfully receives PDCP SDUs with SN #1～#4, and discards PDCP SDU with SN #2, and delivers PDCP SDUs with SN #1～#5 to upper layer.

It should be noted that block 711 and block 712, block 721 and block 722, block 731 and block 732, block 741 and block 742, block 751 and block 752, and/or block 771 and block 772 are not required to be performed at precisely the same time. In addition, a PTM group may include more than two UEs for PTM transmission, and the union of lost PDCP SDUs refers to the lost PDCP SDUs of all the UEs in a PTM group.

As an alternative to the embodiment described above, FIG. 10 is a flowchart of one embodiment of a method 800 in which PDCP status reporting triggers after the completion of MBS bearer type change from PTP to PTM for two UEs and the intersection of lost PDCP SDUs for the two UEs are to be re-transmitted in PTM mode. The two UEs include the first UE 21 and the second UE 22, which are to be grouped in a PTM group. The method 800 begins at block 811 where a gNB 10 transmits PDCP SDUs with SN #1～#5 to the first UE 21 in PTP mode while the method 800 also begins at block 812 where the gNB 10 transmits PDCP SDUs with SN #1～#5 to the second UE 22 in PTP mode. At block 821 the first UE successfully receives PDCP SDUs with SN #3 and #5 while at block 822 the second UE successfully receives PDCP SDUs with SN #2 and #5. Upon the request of switching from PTP to PTM, at block 831 the gNB transmits a RRC signaling including a PTM/PTP switching command to the first UE while at block 832 the gNB also transmits a RRC signaling including a PTM/PTP switching command to the second UE. At block 841 the first UE performs a switch and transmits a message to the gNB after its completion of the switch while at block 842 the second UE performs a switch from PTP to PTM and transmits a message to the gNB after its completion of the switch. At block 851 the first UE transmits a PDCP status report to gNB in PTM mode while at block 852 the second UE transmits a PDCP status report to gNB in PTM mode. According to the status reports transmitted by the first UE and the second UE, the intersection of lost PDCP SDUs are PDCP SDUs with SN #1 and #4. Therefore, at block 860 the gNB re-transmits PDCP SDUs with SN #1 and #4 to the first UE and the second UE simultaneously in PTM mode. At block 871 the first UE successfully receives PDCP SDUs with SN #1 and #4, and delivers PDCP SDUs with SN #1 to upper layer. At block 872 the second UE successfully receives PDCP SDUs with SN #1 and #4, and delivers PDCP SDUs with SN #1 and #2 to upper layer.

It should be noted that block 811 and block 812, block 821 and block 822, block 831 and block 832, block 841 and block 842, block 851 and block 852, and/or block 871 and block 872 are not required to be performed at precisely the same time. In addition, a PTM group may include more than two UEs for PTM transmission, and the intersection of lost PDCP SDUs refers to the intersection of lost PDCP SDUs of all the UEs in a PTM group. Furthermore, the complementary set of lost PDCP SDUs for each UE, for instance, PDCP SDUs with SN #2 for the first UE and PDCP SDUs with SN #3 for the second UE, may be re-transmitted by unicast service and/or other MRB in PTP mode.

FIG. 11 is a flowchart of one embodiment of a method 900 in which RLC status reporting triggers when MBS bearer type change with RLC polling mechanism. The method 900 begins at block 910 where a gNB 10 transmits a RRC signaling including a PTM/PTP switching command to inform a UE 20 for MBS bearer type change. At block 920, the gNB transmits an AMD PDU including a poll to the UE. At block 930, the UE performs a switching of PTM and PTP as required. At block 940, the UE transmits a RLC status report to the gNB upon the completion of the switch.

As an alternative to the embodiment described above, the UE may perform the switch of PTM and PTP as required after transmitting a RLC status report. Moreover, the switch of PTM and PTP may be completed after transmitting a RLC status report.

FIG. 12 is a flowchart of one embodiment of a method 1000 in which RLC status reporting triggers when MBS bearer type change without polling mechanism. The method 1000 begins at block 1010 where a gNB 10 transmits a RRC signaling including a PTM/PTP switching command to inform a UE 20 for MBS bearer type change. At block 1020, the UE performs a switch of PTM and PTP as required. At block 1030, the UE transmits a RLC status report to the gNB upon the completion of the switch. Thus, the AMD PDU including a poll is not required in method 1000, which shows that it is unnecessary of the UE to trigger a RLC status report upon a polling from the gNB, making the procedure of triggering a RLC status report simplified and efficient and reducing the consumption of resources.

As an alternative to the embodiment described above, the UE may perform a switch of PTM and PTP as required after transmitting a RLC status report. Moreover, a switch of PTM and PTP may be completed after transmitting a RLC status report.

In one or more embodiments as below, status report mechanism is described for the second scenario in which PDCP state variables initialization for MRB configuration may lead to data loss, and/or for the third scenario in which RLC state variables initialization for MRB configuration may lead to data loss. MRB configuration may be for a request of MRB establishment for PTM leg (including a split MRB configured with a PTM leg and a PTP leg) , and/or a HO in MBS data transmission, and/or a MRB re-establishment due to radio link failure.

FIG. 13 is a flowchart of one embodiment of a method 1100 in which PDCP status reporting triggers when PDCP state variables initialization for MRB configuration. The method 1100 begins at block 1110 where a gNB 10 transmits a RRC signaling including a request of MRB establishment for PTM leg to a UE 20. At block 1120, the UE receives the RRC signaling and performs MRB establishment for PTM leg with PDCP state variables initialization. At block 1130, the UE transmits a PDCP status report to the gNB upon the completion of MRB establishment.

As an alternative to the embodiment described above, for instance, when initializing a PTM RLC entity for MRB configuration, the UE may transmit a RLC status report instead of a PDCP status report to the gNB after the MRB for PTM leg is established.

FIG. 14 is a flowchart of one embodiment of a method 1200 in which PDCP status reporting triggers when PDCP state variables initialization for a HO in MBS data transmission. The method 1200 begins at block 1210 where S-gNB 11 performs MBS data transmission to a UE 20. At block 1220, S-gNB transmits a HO request to T-gNB 12. At block 1230, T-gNB transmits an acknowledgement message of HO request to S-gNB. At block 1240, S-gNB transmits a HO command and RRC reconfiguration message to the UE, and RRC reconfiguration message includes a request of a PDCP entity re-establishment or a PDCP data recovery. At block 1250, the UE performs a HO from S-gNB to T-gNB with PDCP state variables initialization. At block 1260, the UE transmits a PDCP status report to the T-gNB upon the completion of the HO from S-gNB to T-gNB.

As an alternative to the embodiment described above, a HO command may trigger a RLC status report as well, and a UE may transmit a RLC status report instead of a PDCP status report to a gNB after the completion of a HO from S-gNB to T-gNB.

FIG. 15 is a flowchart of one embodiment of a method 1300 in which PDCP status reporting triggers when PDCP state variables initialization for MRB configuration under the condition of radio link failure. The method 1300 begins at block 1310 where radio link fails between a gNB 10 and a UE 20.At block 1310 the UE performs MRB re-establishment with PDCP state variables initialization. At block 1320, the UE transmits a PDCP status report to the gNB upon the completion of MRB re-establishment.

As an alternative to the embodiment described above, for instance, when initializing a PTM RLC entity for MRB configuration, the UE may transmit a RLC status report instead of a PDCP status report to the gNB after the completion of MRB re-establishment.

Herein, for all embodiments described above, a PDCP status report may refer to a legacy PDCP status report as described above for PDCP status reporting, or any other form of data packet which may be used for a PDCP entity to provide positive and/or negative acknowledgements of PDCP PDUs or PDCP SDUs, etc.

Herein, for all embodiments described above, a RLC status report may refer to a STATUS PDU as described above for RLC status reporting, or any other form of data packet which may be used for an RLC entity to provide positive and/or negative acknowledgements of RLC SDUs (or portions of them) , or RLC PDUs, etc.

As shown in FIG. 16, a base station (BS) 10, for status reporting for MBS in 5G NR wireless communication, includes a processing circuitry 13 configured to support the functionality of the base station, including but not limited to handover, RRC signaling, RRC reconfiguration, switching of PTM and PTP, Automatic Repeat request (ARQ) procedures and polling. The BS 10 also includes radio frequency (RF) interface 14 that is coupled with the processing circuitry 13. The RF interface 14 is configured to transmit and receive communication with one or more UEs, and/or one or more other BSs. More specifically, the processing circuitry 13 is configured to transmit a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and receive a status report including acknowledgement information of data packets. The processing circuitry 13 is further configured to re-transmit data packets correspondingly to the acknowledgement information.

As shown in FIG. 17, a user equipment (UE) 20, for status reporting for MBS in 5G NR wireless communication, includes a processing circuitry 23 configured to support the functionality of the UE, including but not limited to a handover from S-gNB to T-gNB, switching of PTM and PTP, MRB configuration, PDCP/RLC status reporting. The UE 20 also includes radio frequency (RF) interface 24 that is coupled with the processor circuitry 23. The RF interface 24 is configured to transmit and receive communication with one or more other BSs, and/or one or more UEs. The UE 20 may be a mobile device, e.g., a smart phone or a mobile communication module disposed in a vehicle. More specifically, the processing circuitry 23 is configured to receive a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and transmit a status report including acknowledgement information of data packets accordingly. The processing circuitry 23 is further configured to perform a switch of PTM and PTP correspondingly to the signaling including an indication of MBS bearer type change. The processing circuitry 23 is further configured to transmit a status report including acknowledgement information of data packets after the completion of the switch of PTM and PTP, or transmit a status report including acknowledgement information of data packets before the completion of the switch of PTM and PTP.

Herein, as described above, a status report may refer to the message for a receiving entity to provide positive and/or negative acknowledgements of data packets transmitted by a transmitting entity. A status report may be a PDCP status report, and/or a RLC status report.

Although the aspects of the present disclosure and their advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit of the disclosure as defined by the appended claims. Moreover, the scope of the present disclosure is not intended to be limiting to the particular implementations of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the present disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

It should be understood that the elements shown in the FIGs, may be implemented in various forms of hardware, software, or combinations thereof. These elements may be implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, a memory and input/output interfaces. And, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of systems and devices embodying the principles of the present disclosure.

As used herein, various terminology is for the purpose of describing particular implementations only and is not intended to be limiting of implementations. For instance, as used herein, an ordinal term (e.g., “first” , “second” , etc. ) used to modify an element, such as a scenario, a structure, a component, an operation, etc., does not by itself indicate any priority or order of the element with respect to another element, but rather merely distinguishes the element form another element having a same name (but for use of the ordinal term) . The term “data packet” is a basic unit of communication over a digital network. A packet may be also called a datagram, a segment, a block, a cell or a frame, depending on the protocol used for the transmission of data. The structure of a packet depends on the type of packet it is and on the protocol. Normally, a packet has a header and a payload. The term “coupled” is defined as connected, although not necessarily directly, and not necessarily mechanically; two items that are “coupled” may be unitary with each other. The terms “a” and “an” are defined as one or more unless this disclosure explicitly requires otherwise. The phrase “and/or” means and or. To illustrate, A, B, and/or C includes: A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B, and C. In other words, “and/or” operates as an inclusive or. Additionally, the phrase “A, B, C, or a combination thereof” or “A, B, C, or any combination thereof” includes: A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B, and C.

The Background section of the present disclosure may contain background information about the problem or environment of the present disclosure rather than describe prior art by others. Thus, inclusion of material in the Background section is not an admission of prior art by the Applicant.

Claims

A method for status reporting for multicast and/or broadcast service (MBS) , executable in a user equipment (UE) for wireless communication, comprising:

receiving a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and

transmitting a status report including acknowledgement information of data packets accordingly.
The method of claim 1, further comprising:

performing a switch of Point-to-Multipoint (PTM) and Point-to-Point (PTP) correspondingly to the signaling including an indication of MBS bearer type change.
The method of claim 2, wherein transmitting a status report including acknowledgement information of data packets is after the completion of performing the switch of PTM and PTP, or wherein transmitting a status report including acknowledgement information of data packets is before the completion of performing the switch of PTM and PTP.
The method of claim 1, wherein the status report is a PDCP status report and/or a RLC status report.
The method of claim 1, wherein the state variables initialization is the initialization of PDCP state variables and/or RLC state variables.
The method of claim 1, wherein the signaling is a RRC signaling and/or RRC reconfiguration message.
The method of claim 6, wherein the RRC signaling comprises a PTM/PTP switching command and/or a request of MRB configuration.
The method of claim 6, wherein the RRC reconfiguration message comprises a PTM/PTP switching command, and/or a request of a PDCP entity re-establishment and/or a PDCP data recovery and/or an uplink data switching and/or a PDCP entity reconfiguration to release DAPS.
A user equipment (UE) for multicast and/or broadcast service (MBS) in wireless communication, the UE comprising:

processing circuitry configured to:

receive a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and

transmit a status report including acknowledgement information of data packets accordingly.
The UE of claim 9, wherein the processing circuitry is further configured to:

perform a switch of Point-to-Multipoint (PTM) and Point-to-Point (PTP) correspondingly to the signaling including an indication of MBS bearer type change.
The UE of claim 10, wherein the processing circuitry is further configured to:

transmit the status report including acknowledgement information of data packets after the completion of the switch of PTM and PTP, or transmit the status report including acknowledgement information of data packets before the completion of the switch of PTM and PTP.
The UE of claim 9, wherein the status report is a PDCP status report and/or a RLC status report.
The UE of claim 9, wherein the state variables initialization is the initialization of PDCP state variables and/or RLC state variables.
The UE of claim 9, wherein the signaling is a RRC signaling and/or RRC reconfiguration message.
The UE of claim 14, wherein the RRC signaling comprises a PTM/PTP switching command and/or a request of MRB configuration.
The UE of claim 14, wherein the RRC reconfiguration message comprises a PTM/PTP switching command, and/or a request of a PDCP entity re-establishment and/or a PDCP data recovery and/or an uplink data switching and/or a PDCP entity reconfiguration to release DAPS.
A method for status reporting for multicast and/or broadcast service (MBS) , executable in a base station (BS) for wireless communication, comprising:

transmitting a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and

receiving a status report including acknowledgement information of data packets.
The method of claim 17, wherein the status report is a PDCP status report and/or a RLC status report.
The method of claim 17, wherein the state variables initialization is the initialization of PDCP state variables and/or RLC state variables.
The method of claim 17, wherein the signaling is a RRC signaling and/or RRC reconfiguration message.
The method of claim 20, wherein the RRC signaling comprises a PTM/PTP switching command and/or a request of MRB configuration.
The method of claim 20, wherein the RRC reconfiguration message comprises a PTM/PTP switching command, and/or a request of a PDCP entity re-establishment and/or a PDCP data recovery and/or an uplink data switching and/or a PDCP entity reconfiguration to release DAPS.
The method of claim 17, further comprising:

re-transmitting data packets correspondingly to the acknowledgement information.
The method of claim 23, wherein the data packets are the union of lost data packets of all the UEs in a PTM group.
The method of claim 23, wherein the data packets are the intersection of lost data packets of all the UEs in a PTM group.
A base station (BS) for multicast and/or broadcast service (MBS) in wireless communication, the BS comprising:

processing circuitry configured to:

transmit a signaling including an indication of MBS bearer type change, and/or an indication of state variables initialization for at least one MBS radio bearer (MRB) configuration; and

receive a status report including acknowledgement information of data packets.
The BS of claim 26, wherein the status report is a PDCP status report and/or a RLC status report.
The BS of claim 26, wherein the state variables initialization is the initialization of PDCP state variables and/or RLC state variables.
The BS of claim 26, wherein the signaling is a RRC signaling and/or RRC reconfiguration message.
The BS of claim 29, wherein the RRC signaling comprises a PTM/PTP switching command and/or a request of MRB configuration.
The BS of claim 29, wherein the RRC reconfiguration message comprises a PTM/PTP switching command, and/or a request of a PDCP entity re-establishment and/or a PDCP data recovery and/or an uplink data switching and/or a PDCP entity reconfiguration to release DAPS.
The BS of claim 26, wherein the processing circuitry is further configured to:

re-transmit data packets correspondingly to the acknowledgement information.
The BS of claim 32, wherein the data packets are the union of lost data packets of all the UEs in a PTM group.
The BS of claim 28, wherein the data packets are the intersection of lost data packets of all the UEs in a PTM group are re-transmitted.
A chip, comprising:

a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 8 and 17～25.
A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to execute the method of any one of claims 1 to 8 and 17～25.
A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 8 and 17～25.
A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 8 and 17～25.
A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 8 and 17～25.