CN118140526A

CN118140526A - Multicast/broadcast service status reporting method and device

Info

Publication number: CN118140526A
Application number: CN202180103628.2A
Authority: CN
Inventors: 张鑫; 生嘉
Original assignee: Huizhou TCL Cloud Internet Corp Technology Co Ltd
Current assignee: Huizhou TCL Cloud Internet Corp Technology Co Ltd
Priority date: 2021-10-21
Filing date: 2021-10-21
Publication date: 2024-06-04
Also published as: WO2023065219A1

Abstract

A method and apparatus for multicast/broadcast service MBS status reporting in wireless communications. The user equipment receives signaling, including an indication of MBS bearer type change and/or an indication of initialization of state variables of at least one MBS radio bearer MRB configuration; and transmitting a status report, the status report including acknowledgement information for the data packet. The base station sends signaling comprising an indication of MBS bearer type change and/or an indication of state variable initialization of at least one MBS radio bearer MRB configuration; and receives a status report including acknowledgement information for the data packet.

Description

Multicast/broadcast service status reporting method and device

Technical Field

The present invention relates to a method and apparatus for multicast/broadcast services in wireless communications, and in particular, but not exclusively, to a method, user equipment and base station for MBS status reporting mechanism in a 5G NR communication system.

Background

Unless otherwise indicated herein, the approaches described in the background are not prior art to the claims in this application and are not admitted to be prior art by inclusion in the background.

For the 5G New Radio (NR), multicast and broadcast communications are considered to pave the way for resource efficient transmission to multiple end users that need to receive the same content. 5G NR did not address multicast and broadcast service issues in the first (15 th edition) and second (16 th edition) packages, with initial emphasis on enhanced mobile broadband (enhanced Mobile Broadband, eMBB) and Ultra-Reliable and Low-delay communications (Ultra-Reliable and Low-Latency Communication, URLLC). Later, in release 17 of 5G (Rel-17), 3GPP has focused on building functional support for multicast and/or broadcast services over existing 5G standard frameworks and standardized the overall 5G system architecture for the next generation radio access network (Next Generation Radio Access Network, NG-RAN) and the 5G core network (5G Core Network,5GC).

Compared to the 4G precursor, known as evolved multimedia broadcast multicast service (Evolved Multimedia Broadcast Multicast Service, eMBMS), MBS in Rel-17 requires much less operation, management and maintenance effort and improves resource efficiency. The 5G NR oriented MBS is mainly used to support the case where high reliability and low latency of the same level as that of the unicast service are required to be achieved. The main functions of reliability enhancement include mixing unicast/multicast services through dynamic switching between Point-to-Multipoint (PTM) and Point-to-Point (PTP) transmissions of MBS Radio Bearers (MRBs). The MRB plays the same role in unicast as a legacy data radio bearer (Data radio bearer, DRB) and transmits IP multicast data to User Equipment (UE). MRB may be divided into PTM and PTP branches. Therefore, when the UE switches to PTP and immediately stops PTM monitoring after receiving the PTM/PTP switching command, data loss may occur due to MBS bearer type change, while packet transmission of the PTM is not yet completed. Furthermore, data loss may occur due to state variable initialization of the MRB configuration. For packet data convergence protocol (PACKET DATA Convergence Protocol, PDCP) state variable initialization when configuring the MRB, out-of-order delivery of PDCP data PDUs and a discard mechanism for received PDCP data PDUs may result in packet loss during data transmission. Also, for RLC state variable initialization when configuring MRB, a discard mechanism of unordered transfer Unacknowledged Mode Data (UMD) PDUs and received UMD PDUs may result in packet loss during data transmission.

Disclosure of Invention

The following summary is provided for illustrative purposes only and is not intended to be limiting in any way. That is, the following summary is provided to introduce a selection of concepts, advantages, and benefits of the novel and non-obvious techniques described herein. Implementations are further described in the detailed description that follows. Accordingly, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used to identify the scope of the claimed subject matter.

The invention aims to provide a method and a device for a multicast and/or broadcast service (MBS) status reporting mechanism in 5G NR wireless communication.

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

According to a second aspect, one or more embodiments of the present invention provide a user equipment, UE, for multicast and/or broadcast service, MBS, in wireless communication, the UE comprising: processing circuitry to receive signaling including an indication of an MBS bearer type change and/or an indication of an initialization of a state variable of at least one MBS radio bearer MRB configuration; and transmitting a status report, the status report including acknowledgement information for the data packet.

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

According to a fourth aspect, one or more embodiments of the present invention provide a base station BS for MBS wireless communication, comprising: processing circuitry to transmit signaling including an indication of an MBS bearer type change and/or an indication of state variable initialization of at least one MBS radio bearer MRB configuration; and receiving a status report including acknowledgement information for the data packet.

According to a fifth aspect, one or more embodiments of the present invention provide a chip. The chip may include a processor configured to invoke and run a computer program stored in a memory to cause a device on which the chip is installed to perform the above-described method.

According to a sixth aspect, one or more embodiments of the invention provide a non-transitory machine-readable medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the above-described method. The non-transitory machine-readable medium may include at least one of the following group: hard disks, CD-ROMs, optical storage devices, magnetic storage devices, read-only memory, programmable read-only memory, erasable programmable read-only memory, EPROM, electrically erasable programmable read-only memory, and flash memory.

According to a seventh aspect, one or more embodiments of the present invention provide a computer-readable storage medium in which a computer program is stored, wherein the computer program causes a computer to perform the above-described method.

According to an eighth aspect, one or more embodiments of the present invention provide a computer program product comprising a computer program, wherein the computer program causes a computer to perform the above-described method.

According to a ninth aspect, one or more embodiments of the present invention provide a computer program that causes a computer to perform the above-described method.

Drawings

In order to more clearly illustrate the embodiments of the present invention or related art, the drawings that will be described in the embodiments are briefly described below. The drawings should not be construed as limiting the invention.

Fig. 1 is a schematic diagram showing a conventional Handover (HO) procedure between a source gNB (S-gNB) and a target gNB (T-gNB).

Fig. 2 is a diagram showing an embodiment of the present invention for triggering PDCP status reporting when MBS bearer type change and PTM/PTP handover command are not included in RRC reconfiguration message.

Fig. 3 is a schematic diagram showing an embodiment of triggering PDCP status report when the RRC reconfiguration message includes MBS bearer type change and PTM/PTP handover command.

Fig. 4 is a diagram illustrating an embodiment of triggering PDCP status reporting when MBS bearer type is changed without an RRC reconfiguration message.

Fig. 5 is a diagram illustrating an embodiment of triggering PDCP status reporting when an RRC reconfiguration message includes MBS bearer type change and PTM/PTP handover command without requiring a request for PDCP entity re-establishment or PDCP data recovery.

Fig. 6 is a diagram illustrating a legacy mechanism for HO triggering PDCP status reporting and retransmitting PDCP SDUs.

Fig. 7 is a diagram illustrating an embodiment of triggering PDCP status reporting before MBS bearer type change is completed.

Fig. 8 is a diagram illustrating an embodiment of triggering PDCP status reporting after MBS bearer type modification is completed.

Fig. 9 is a schematic diagram showing an embodiment of the present invention for triggering PDCP status reporting after MBS bearer type modification is completed, and the association of lost PDCP SDUs for two UEs will be retransmitted in PTM mode.

Fig. 10 illustrates an embodiment of a method for triggering PDCP status reporting after MBS bearer type modification is completed, and the intersection of two UE missing PDCP SDUs will be retransmitted in PTM mode.

Fig. 11 is a diagram illustrating an embodiment of the present invention for triggering RLC status reporting when MBS bearer type changes with RLC polling mechanism.

Fig. 12 illustrates an embodiment of a method for triggering RLC status reporting when the MBS bearer type is changed without a polling mechanism.

Fig. 13 is a diagram illustrating an embodiment of the present invention for triggering PDCP status reporting upon initialization of PDCP status variables.

Fig. 14 is a diagram illustrating an embodiment of the present invention for triggering PDCP status reporting when initializing PDCP status variables for a HO in MBS data transmission.

Fig. 15 is a diagram illustrating an embodiment of triggering PDCP status reporting when PDCP status variables are initialized for MRB configuration under radio link failure conditions.

Fig. 16 is a schematic diagram of an example of a base station.

Fig. 17 is a schematic diagram of an example of a user equipment.

Detailed Description

Technical matters, structural features, achieved objects and effects of the embodiments of the present invention are described in detail with reference to the accompanying drawings as follows. In particular, the terminology used in the embodiments of the invention is for the purpose of describing certain embodiments only and is not intended to limit the scope of the invention.

Reference in the specification to "one embodiment," "an embodiment," "one or more embodiments," etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Furthermore, the term "embodiment" in various places in the specification are not necessarily referring to the same embodiment. That is, various features of the descriptions may be exhibited by some embodiments and not by others.

The 5G NR (new radio) is developing, and the current emphasis is on implementing advanced functions and new service capabilities, where Multicast and Broadcast Services (MBS) are considered as one of the promising functions in the new standard for wireless communication. The 5G NR oriented MBS is mainly used to support important use cases, including public safety critical task push-to-talk, wireless software delivery, IPTV, internet of vehicles (V2X), group communication, and internet of things applications, which need to achieve the same high reliability and low latency level as unicast services. In particular, mission critical delay sensitive signaling and high resolution IPTV are required to achieve the same high reliability and low delay level as unicast services, and thus a protocol stack design with layers and functions is required to enhance reliability and delay performance.

Rel-17 allows supporting multicast sessions to User Equipments (UEs) in a Radio Resource Control (RRC) connected state and supporting broadcast sessions to UEs in RRC connected, inactive and idle states. The function of supporting a broadcast session of a UE in an inactive and idle state is very important for supporting the maximum capacity of a broadcast service. Part of this functionality is configurable feedback that supports group scheduling, mobility for service continuity, and provides reliability when needed.

For broadcast services in MBS, it can maintain approximately the same requirements as in evolved multimedia broadcast multicast service (eMBMS), thus inheriting many design functions.

In order to achieve multicast service continuity in MBS, dynamic switching between point-to-multipoint (PTM) and point-to-point (PTP) transmissions has been agreed, and a Base Station (BS) may dynamically decide whether to provide multicast data to User Equipment (UE) per PTM or PTP. For example, the network may adapt the transmission to the actual link quality and then may consider all UEs in the PTM group to optimize the transmission.

MBS Radio Bearers (MRBs) denote radio bearers carrying multicast and broadcast sessions. MRB plays the same role in unicast as a legacy Data Radio Bearer (DRB) and transmits IP multicast data to UEs. MRB may be divided into PTM and PTP branches. The PTM leg supports true PTM transmission. The PTP leg is essentially the same as the conventional bi-directional unicast but logically separated from the unicast function of the DRB, which can be used in parallel. Both the PTM and PTP legs inherit a large portion of the conventional 5GNR protocol stack, including Packet Data Convergence Protocol (PDCP), radio Link Control (RLC), medium Access Control (MAC), and physical layer (PHY). Splitting the MRB with a single PDCP entity supports dynamic switching of PTM and PTP, whereas splitting the MRB may configure PTM and PTP legs. In order to improve the reliability of MBS transmission, in 5G NR, both the PTM leg and the PTP leg support retransmission based on UE feedback. In the PTM leg, PTM or PTP retransmissions may be used, whichever is most efficient.

For MBS, data loss may occur in the following three cases:

In the first case, MBS bearer type changes may result in data loss. When the multicast service is transmitted from the content provider to the gNB, the gNB may choose to transmit the data to the UE via PTP or PTM. For PTP mode, the gNB may allocate dedicated resources for the UE, thus guaranteeing high reliability of transmission, but resulting in low resource utilization. For PTM mode, the gNB may allocate shared resources to a group of UEs, allowing all eligible UEs to receive the service. The PTM mode improves the resource utilization, but it is difficult to guarantee the quality of data received by each UE. The gNB may switch dynamically between the two modes. When the PTM reception quality is low, for example, due to poor channel conditions, the gNB may allocate dedicated resources for the UE to transmit in PTP mode. When the UE may receive high quality data over the PTM mode shared resources, the gNB may decide to schedule the UE using the PTM shared resources.

For radio resource control (Radio Resource Control, RRC) signaling, one MRB may configure PTM only or PTP only, or both PTM and PTP. Whether only PTM, PTP, or ptm+ptp is configured, it is possible to change from one configuration to the other by RRC signaling. For example, one UE receives packets (# 1 to # 3) from the gNB in PTP mode, and the other UE receives packets (# 1 to # 4) from the gNB in PTP mode. Then, both UEs perform a handover from PTP to PTM mode according to the request. When the gNB starts transmitting data packets in PTM mode (# 2) in PTM mode, this will result in the data packet for the first UE (# 1) being lost when no latest status report is acquired from both UEs. In addition, when the UE switches to PTP and stops PTM monitoring immediately after receiving a PTM/PTP switching command, data loss may also occur because the data packets of the PTM leg are still being transmitted over the air. For a packet for the PDCP sublayer, "packet" may refer to a PDCP PDU and/or SDU, and for a packet for the RLC sublayer, "packet" may refer to an RLC PDU and/or SDU. Or RRC signaling for MBS bearer type changes may be replaced by mechanisms operating in other layers or sublayers (e.g., MAC sublayers), which may provide higher efficiency.

In the present invention, MBS bearer type change may include the following six modes:

configuration of ptm→ptp only (ptm→ptp);

configuration of PTP only→configuration of PTM only (PTP→PTM);

only ptm→ptm+ptp (ptm→ptm+ptp) is configured;

only ptp→ptm+ptp (ptp→ptm+ptp) is configured;

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

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

In the second case, initialization of PDCP state variables of the MRB configuration may result in data loss. For initialization of PDCP state variables when configuring MRBs, out-of-order delivery of PDCP data PDUs from RLC to PDCP and a discard mechanism based on COUNT values of received PDCP data PDUs may enable data loss. PDCP sequence numbers (PDCP SNs) may be appended to each PDCP data PDU as part of the COUNT value, and the transmitting PDCP entity may hold a state variable. For the PTM PDCP state variable settings at configuration, the SN portion of the COUNT value of these variables is set (if needed) based on the SN of the first received packet (set by the UE) and the Number of superframes (HYPER FRAME Numbers, HFNs) indicated by gNB. As with the reception operation rule specified in 3GPP TS 38.323V16.5.0, when receiving PDCP data PDUs from a lower layer, the discard mechanism includes that, under certain conditions, if rcvd_count < rx_ DELIV, the received PDCP entity should discard PDCP data PDUs. Specifically, rcvd_count refers to the COUNT value of the received PDCP data PDU, and rx_ DELIV is a state variable indicating that the COUNT value of the first PDCP SDU is not delivered to an upper layer but is still waiting to be delivered. The COUNT value consists of HFN and PDCP SN.

Due to the out-of-order delivery of PDCP data PDUs from RLC to PDCP, PDCP data PDUs of the SN that were sent before the first received PDCP data PDU are discarded even if received correctly, and thus may result in data loss at MRB configuration.

In a third scenario, initialization of the RLC state variables of the MRB configuration may result in data loss. For initialization of RLC state variables when MRB is configured, unacknowledged mode data (Unacknowledged Mode Data, UMD) PDUs are transferred from MAC/PHY out of order to RLC, and data may be lost according to a discard mechanism that receives rx_next_ Highest and rx_next_ Reassembly values of the UMD PDUs. The values of RX_Next_ Highest and RX_Next_ Reassembly are set according to the SN of the first received packet containing the SN when initializing the MRB configured PTM RLC entity. As with the reception operation rules specified in 3GPP TS 38.322V16.2.0, when Unacknowledged Mode Data (UMD) PDUs are received from the lower layer, the discard mechanism includes that under certain conditions, if (rx_next_ Highest-um_window_size) <=sn < rx_next_ Reassembly, the receiving UM RLC entity should discard the received UMD PDUs. Specifically, RX_Next_ Highest is a state variable that holds the Sequence Number (SN) value after the SN of the RLC Service Data Unit (SDU) with the highest SN in the received RLC SDU, UM_Window_Size is a constant used by the receiving UM RLC entity to define the SNs of UMD SDUs that can be received without causing the advancement of the receive Window, RX_Next_ Reassembly is a state variable that contains the value of the earliest SN that still takes into account reassembly.

Because of the unordered transfer of UMD PDUs from the MAC/PHY to the RLC, UMD PDUs of the SN sent before the first received UMD PDU are discarded even if received correctly, thus possibly resulting in a loss of data when switching from PTP to PTM.

Further, for a multicast session, the gNB provides the UE with one or more MRB configurations through dedicated RRC signaling, which only support Downlink (DL) UMRLC configurations of PTM, DL and Uplink (UL) AM RLC configurations of PTP, DL UMRLC configurations of PTP only. And the RLC state variable of the PTP RLC receive window may be set to an initial value due to the MRB configuration.

The main idea of the present invention is to provide a method and apparatus for MBS status reporting mechanism to solve the data loss problem that may be caused by the above scenario, including but not limited to MBS bearer type change, PDCP status variable initialization and RLC status variable initialization. The status reporting mechanism may be provided by PDCP status reporting and/or RLC status reporting. By triggering PDCP status reports and/or RLC status reports upon MBS bearer type change, PDCP status variable initialization and/or RLC status variable initialization, the problem of packet loss during data transmission may be solved.

According to the method of the invention, when the MBS bearing type is changed and/or the state variable of the MRB configuration is initialized, the PDCP state report and/or the RLC state report are triggered, which is beneficial to solving the problem of data loss in the MBS, improving the reliability of the MBS, ensuring the continuity of MBS service and being suitable for user scenes with higher reliability and lower time delay requirements.

The PDCP sublayer provides services to upper layers including an RRC layer or a Service Data Adaptation Protocol (SDAP) layer. The PDCP sublayer is configured by RRC for Radio Bearers (RBs) on logical channels corresponding to dedicated control channels (DEDICATED CONTROL CHANNEL, DCCH), dedicated traffic channels (DEDICATED TRAFFIC CHANNEL, DTCH), side chain control channels (Sidelink Control Channel, SCCH) and side chain traffic channels (SIDELINK TRAFFIC CHANNEL, STCH) types. Each RB may be associated with one PDCP entity located in the PDCP sublayer. The multicast mode supports traffic continuity and lossless mobility. When a UE changes its serving cell due to mobility, such as Handover (HO), support of service continuity is important for the user not to experience ongoing service interruption or performance degradation. The service continuity of the 5G MBS is achieved based on packet-level Sequence Number (SN) synchronization, wherein the same packet has the same PDCP SN in the region supporting the service continuity. Assuming that the UE can receive data packets out of order from lower layers, PDCP is used to support functions including, but not limited to, maintaining PDCP SNs, reordering and in-order delivery, and discarding duplicate items.

For the PDCP status report specified in 3GPP TS 38.323V16.5.0, for an AM DRB that the upper layer is configured to transmit the PDCP status report in the uplink, the receiving PDCP entity should trigger the PDCP status report when the upper layer operates under preset conditions, as follows:

-the upper layer requesting re-establishment of the PDCP entity;

-upper layer requesting PDCP data recovery;

-an upper layer requesting an uplink data exchange;

The upper layer reconfigures the PDCP entity to release the dual active protocol stack (Dual Active Protocol Stack,

DAPS)。

For example, for an AM DRB in which the upper layer is configured to transmit a PDCP status report in the uplink, the receiving PDCP entity should trigger the PDCP status report when the upper layer requests re-establishment of the PDCP entity. The PDCP status report message is transmitted from the receiving PDCP entity to the transmitting PDCP entity to inform the transmitting PDCP entity of the PDCP PDUs received or not received by the receiving PDCP entity, thereby retransmitting the PDCP PDUs not received.

Further, for UM DRBs where the upper layer is configured to send PDCP status reports in the uplink, the receiving PDCP entity should trigger PDCP status reports when the upper layer requests uplink data handover. For AM DRBs in the side chain, the receiving PDCP entity should trigger a PDCP status report when the upper layer requests the PDCP entity to reestablish.

When the PDCP status report is triggered, the receiving PDCP entity should compile the PDCP status report as needed.

As shown in fig. 1, the UE 20 performs a Handover (HO) procedure between a source gNB (S-gNB) 11 and a target gNB (T-gNB) 12. After the HO is completed between the S-gNB and the T-gNB, the upper layer requests the PDCP entity to reestablish or request the PDCP data recovery through the RRC reconfiguration message, and then the UE transmits a PDCP status report to the T-gNB after the HO is completed. As for Rel-17, completion of ho may also trigger RLC status reporting.

For RLC STATUS reporting, the AM RLC entity sends STATUS PDUs to its peer AM RLC entity, as described in 3GPP TS 38.322V16.2.0, to provide positive and/or negative acknowledgements to the RLC SDU (or portion thereof). The trigger to initiate RLC status reporting may include a poll from its peer AM RLC entity. The AM RLC entity may poll its peer AM RLC entity to trigger a status report of the peer AM RLC entity. The sender of the AM RLC entity should include a poll in AMD PDU with the following preset conditions:

pdu_wide_poll > = POLL PDU;

-BYTE_WITHOUT_POLL>＝pollByte；

-an empty transmission buffer and an empty retransmission buffer, e.g. no RLC SDUs for transmission by an AM RLC entity;

Failure to transmit new RLC SDUs, e.g. due to window stall;

-an expiration time of t-PollRetransmit.

For example, when pdu_window_poll > = pollPDU, the transmitting end of the AM RLC entity should include the POLL in the AMD PDU. Specifically, pdu_window_poll counts the number of AMD PDUs transmitted since the last POLL bit transmission, and the transmitting end of each AM RLC entity uses pollPDU to trigger the polling of each POLL PDU.

In addition, the trigger to initiate RLC status reporting may also include detecting a failure of reception of an AMD PDU. When t-Reassembly expires, the receiving end of the AM RLC entity should trigger a status report. Specifically, t-Reassembly refers to a timer used by a receiving end of the AM RLC entity and the receiving um RLC entity for detecting loss of the lower layer RLC PDU.

When the STATUS report is triggered, the receiver of the AM RLC entity should construct a STATUS PDU and submit it to the lower layer as needed. For Rel-17, the RLC status reporting mechanism may also be applied to multicast services of the UM RLC entity.

In one or more embodiments below, a status reporting mechanism for a first scenario where MBS bearer type changes may result in data loss is described.

Fig. 2 is a flow chart of an embodiment of a method 100 in which PDCP status reporting is triggered when an MBS bearer type changes and signaling including a PTM/PTP handover command is not included in an RRC reconfiguration message and a PDCP entity is requested to re-establish or PDCP data recovery. The method 100 begins at step 110, where the gNB 10 sends RRC signaling, including PTM/PTP handover commands, to inform the UE 20 of MBS bearer type changes. At step 120, the gNB transmits an RRC reconfiguration message to the UE, the RRC reconfiguration message including a request for a PDCP entity to reestablish or PDCP data recovery. At step 130, the UE performs a handoff of PTM and PTP as needed. At step 140, the UE sends PDCP status reports to the gNB after completing the handoff of PTM and PTP. Thus, PDCP status reports are transmitted by the UE in the "new" mode, e.g. when a PTM/PTP handover command is used for a change of MBR bearer type from PTM to PTP. Since the channel state of PTM transmission is poor, the UE may be required to switch from PTM to PTP, so the UE may be helpful to transmit a status report in PTP mode to obtain better data transmission quality.

It should be noted that the PTM/PTP switching command is a command for notifying the UE to perform switching of PTM and PTP, and includes six mode changes of the MBS bearer type described above, which is applicable to all embodiments of the present invention.

As an alternative to the above-described embodiments, the UE may perform the switching of PTM and PTP as needed after receiving the RRC signaling including the PTM/PTP switching command, which means that the switching of PTM and PTP may be performed before receiving the RRC reconfiguration message.

As an alternative to the above embodiments, the RRC reconfiguration message may include a request for uplink data exchange in order to trigger PDCP status reporting. Also, the RRC reconfiguration may instruct the PDCP entity to reconfigure to release the DAPS to trigger the PDCP status report.

Fig. 3 is a flow chart of an embodiment of a method 200 in which PDCP status reporting is triggered when an MBS bearer type changes and signaling including a PTM/PTP handover command is included in an RRC reconfiguration message and requests PDCP entity re-establishment or PDCP data recovery. The method 200 begins at step 210, wherein the gNB 10 transmits an RRC reconfiguration message to the UE 20, the RRC reconfiguration message including a PTM/PTP handover command and a request for a PDCP entity to reestablish or PDCP data recovery. At step 220, the UE performs a handoff of PTM and PTP as needed. At step 230, the UE sends PDCP status reports to the gNB after completing the handoff of PTM and PTP.

Fig. 4 is a flow chart of an embodiment of a method 300 in which PDCP status reporting is triggered when MBS bearer types change without an RRC reconfiguration message. The method 300 begins at step 310, where the gNB 10 sends RRC signaling, including PTM/PTP handover commands, to inform the UE 20 of MBS bearer type changes. At step 320, the UE performs a handoff of PTM and PTP as needed. At step 330, the UE sends a PDCP status report to the gNB. Thus, no RRC reconfiguration is required in method 300, indicating that the gNB does not have to send an RRC reconfiguration message to the UE, including a request for PDCP entity re-establishment or PDCP data recovery, to trigger PDCP status reporting. Considering that in some cases PDCP entity re-establishment or PDCP data restoration is unnecessary for MBS bearer type modification and additional resources may be consumed, the procedure of triggering PDCP status report without re-establishment of PDCP entity or PDCP data restoration may be simplified and more efficient.

As an alternative to the above embodiments, the UE may not be able to perform the switching of PTM and PTP as required before transmitting the PDCP status report. And switching of PTM and PTP can be completed after transmitting PDCP status report.

Fig. 5 is a flow chart of an embodiment of a method 400 in which PDCP status reporting is triggered when an MBS bearer type changes and signaling including PTM/PTP exchange commands is included in an RRC reconfiguration message without requiring PDCP entity re-establishment or PDCP data recovery. The method 400 begins at step 410, wherein the gNB 10 transmits an RRC reconfiguration message to the UE 20, the RRC reconfiguration message including a PTM/PTP handover command, but not including a request for a PDCP entity re-establishment or a PDCP data recovery. At step 420, the UE transmits a PDCP status report to the gNB. Thus, the RRC reconfiguration message is transmitted without PDCP entity re-establishment or PDCP data restoration request, which indicates that the gNB does not have to transmit a request for PDCP entity re-establishment or PDCP data restoration to the UE to trigger PDCP status reporting. At step 430, the UE performs a handoff of PTM and PTP as needed. Therefore, under certain conditions where the MBS bearer type change does not require PDCP entity re-establishment or PDCP data recovery, the RRC reconfiguration message may exclude the PDCP entity re-establishment or PDCP data recovery request, thereby making the process of triggering PDCP status reporting simpler and more efficient. Thus, the PDCP status report is transmitted before the UE switches to the "new" mode, e.g. when a PTM/PTP switch command is used for the MBR bearer type to switch from PTP to PTM, the PDCP status report is transmitted by the UE in PTP mode. For the case where the UE transmits status reports in "old" mode, the gNB may receive status reports as early as possible (if channel status is allowed), which is advantageous for making subsequent procedures (e.g. retransmissions) timely efficient.

As an alternative to the above embodiments, the UE may perform the switching of PTM and PTP as needed before sending the PDCP status report. In addition, the switching of PTM and PTP can be completed after the PDCP status report is sent.

In one or more of the following embodiments, the mechanism of triggering of PDCP status reports and retransmission of PDCP SDUs is described in more detail for the first case where MBS bearer type changes may lead to data loss. The PDCP SDU may have a corresponding PDCP data PDU.

As shown in fig. 6, a legacy mechanism that triggers PDCP status reporting and retransmission of PDCP SDUs by HO is illustrated. For example, the S-gNB 11 transmits PDCP SDUs of SNs #1 to #5 to the UE 20, which successfully receives PDCP SDUs of SNs #3 and # 5. The UE transmits an RLC status report to the S-gNB, which retransmits PDCP SDUs with SN #1, #2, and #4 accordingly. When the UE receives the PDCP SDU with sn#1, the UE delivers the PDCP SDU with sn#1 to an upper layer. Meanwhile, the S-gNB transmits an HO command to the UE as required, and before the HO command, does not transmit an RLC status report to the S-gNB, indicating whether PDCP SDUs of SN#1, #2 or #4 are received. Then, the S-gNB forwards retransmission requests of PDCP SDUs of SNs #1, #2 and #4 to the T-gNB even though PDCP SDUs of SN #1 are well received by the UE. After the HO is completed, the UE transmits a PDCP status report to the T-gNB 12 informing the T-gNB that PDCP SDUs with sn#1 have been received, but PDCP SDUs with sn#2 and #4 have not been received. And then, the T-gNB retransmits the PDCP SDUs of the SNs #2 and #4 to the UE according to the PDCP status report. Since the UE successfully receives PDCP SDUs of SN #2 and #4, the UE needs to deliver PDCP SDUs of SN #2 to #5 to an upper layer.

Fig. 7 is a flow chart of an embodiment of a method 500 in which PDCP status reporting is triggered before two UEs complete MBS bearer type change from PTP to PTM. The two UEs comprise a first UE 21 and a second UE 22, which are to be grouped into a PTM group. The method 500 starts at step 511, where the gNB 10 transmits PDCP SDUs with SN # 1- #5 to the first UE 21 in PTP mode, and the method 500 also starts at step 512, where the gNB 10 transmits PDCP SDUs with SN # 1- #5 to the second UE 22 in PTP mode. At step 521, the first UE successfully receives PDCP SDUs with sn#3 and #5, and at step 522, the second UE successfully receives PDCP SDUs with sn#2 and # 5. Upon requesting a handover from PTP to PTM, the gNB sends RRC signaling including a PTM/PTP handover command to the first UE at step 531, and also sends RRC signaling including a PTM/PTP handover command to the second UE at step 532. At step 541, the first UE sends a PDCP status report to the gNB upon receipt of the PTM/PTP handover command, and at step 542 the second UE also sends a PDCP status report to the gNB upon receipt of the PTM/PTP handover command. At step 551, the gNB retransmits the PDCP SDUs of SNs #1, #2, and #4 to the first UE, respectively, and at step 552, the gNB retransmits the PDCP SDUs of SNs #1, #3, and #4 to the second UE, respectively. At step 561, the first UE receives PDCP SDUs of sn#1, #2, and #4 and delivers PDCP SDUs of sn#1 to #5 to an upper layer, and at step 562, the second UE receives PDCP SDUs of sn#1, #3, and #4 and delivers PDCP SDUs of sn#1 to #5 to an upper layer. At step 571, the first UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. The second UE also performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed, step 572. At step 580, the gNB transmits PDCP SDUs to the first UE and the second UE simultaneously in PTM mode.

It should be noted that steps 511 and 512, 521 and 522, 531 and 532, 541 and 542, 551 and 552, 561 and 562, and/or 571 and 572 need not be performed entirely simultaneously.

As an alternative to the above embodiments, the gNB may send RRC reconfiguration messages including PTM/PTP handover commands to the first UE and the second UE, respectively.

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

As an alternative to the above embodiments, the first UE and/or the second UE may not send a message to the gNB indicating "handover complete" after completing the handover from PTP to PTM.

Fig. 8 is a flow chart of an embodiment of a method 600 in which PDCP status reporting is triggered after MBS bearer types of two UEs are completed from PTP to PTM. The two UEs comprise a first UE 21 and a second UE 22, which are to be grouped into a PTM group. The method 600 starts at step 611, where the gNB 10 transmits PDCP SDUs of SNs # 1- #5 to the first UE 21 in PTP mode, and the method 600 also starts at step 612, where the gNB transmits PDCP SDUs of SNs # 1- #5 to the second UE 22 in PTP mode. At step 621, the first UE successfully receives PDCP SDUs with sn#3 and #5, and at step 622, the second UE successfully receives PDCP SDUs with sn#2 and # 5. Upon requesting a handoff from PTP to PTM, the gNB sends RRC signaling including a PTM/PTP handoff command to the first UE at step 631, and also sends RRC signaling including a PTM/PTP handoff command to the second UE at step 632. At step 641, the first UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. At step 642, the second UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. In step 651, the first UE sends PDCP status reports to the gNB in PTM mode, and in step 652, the second UE sends PDCP status reports to the gNB in PTM mode. At step 660, the gNB retransmits the lost PDCP SDU to the first UE and the second UE simultaneously in PTM mode.

It should be noted that steps 611 and 612, 621 and 622, 631 and 632, 641 and 642 and/or 651 and 652 need not be performed entirely simultaneously.

Alternatively, fig. 9 is a flow chart of an embodiment of a method 700 in which PDCP status reports are triggered after the completion of a change in MBS bearer type from PTP to PTM for both UEs, and the association of the lost PDCP SDUs for both UEs is to be retransmitted in PTM mode. The two UEs comprise a first UE 21 and a second UE 22, which are to be grouped into a PTM group. The method 700 starts at step 711, where the gNB 10 transmits PDCP SDUs with sn#1 to #5 to the first UE 21 in PTP mode, and the method 700 also starts at step 712, where the gNB 10 transmits PDCP SDUs with sn#1 to #5 to the second UE 22 in PTP mode. In step 721, the first UE successfully receives PDCP SDUs of sn#3 and #5, and in step 722, the second UE successfully receives PDCP SDUs of sn#2 and # 5. Upon requesting a handoff from PTP to PTM, the gNB sends RRC signaling including a PTM/PTP handoff command to the first UE at step 731, while the gNB also sends RRC signaling including a PTM/PTP handoff command to the second UE at step 732. At step 741, the first UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. At step 742, the second UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. At step 751, the first UE sends PDCP status reports to the gNB in PTM mode, and at step 752, the second UE sends PDCP status reports to the gNB in PTM mode. The association of lost PDCP SDUs is PDCP SDUs of SN # 1- #4 according to status reports transmitted by the first UE and the second UE. Accordingly, at step 760, the gNB retransmits PDCP SDUs of SNs # 1- #4 to the first UE and the second UE simultaneously in the PTM mode. At step 771, the first UE successfully receives PDCP SDUs of SN #1 to #4, discards PDCP SDUs of SN #3, and delivers PDCP SDUs of SN #1 to #5 to an upper layer. At step 772, the second UE successfully receives PDCP SDUs of SNs #1 to #4, discards PDCP SDUs of SN #2, and delivers PDCP SDUs of SNs #1 to #5 to an upper layer.

It should be noted that steps 711 and 712, 721 and 722, 731 and 732, 741 and 742, 751 and 752, and/or 771 and 772 need not be performed at the same time. Furthermore, one PTM group may include more than two UEs for PTM transmission, and the union of the missing PDCP SDUs refers to the missing PDCP SDUs of all UEs in the PTM group.

As an alternative to the above embodiments, figures are shown. Fig. 10 is a flow chart of an embodiment of a method 800 in which PDCP status reports are triggered after MBS bearer types of two UEs are completed from PTP to PTM, and an intersection of lost PDCP SDUs of the two UEs is to be retransmitted in PTM mode. The two UEs comprise a first UE 21 and a second UE 22, which are to be grouped into a PTM group. The method 800 starts at step 811 where the gNB 10 transmits PDCP SDUs with SN #1 to #5 to the first UE 21 in PTP mode, and the method 800 also starts at step 812 where the gNB 10 transmits PDCP SDUs with SN #1 to #5 to the second UE 22 in PTP mode. At step 821, the first UE successfully receives PDCP SDUs with sn#3 and #5, and at step 822, the second UE successfully receives PDCP SDUs with sn#2 and # 5. Upon requesting a handover from PTP to PTM, the gNB sends RRC signaling including a PTM/PTP handover command to the first UE at step 831, and also sends RRC signaling including a PTM/PTP handover command to the second UE at step 832. At step 841, the first UE performs a handover and sends a message to the gNB after the handover is completed, and at step 842, the second UE performs a handover from PTP to PTM and sends a message to the gNB after the handover is completed. In step 851, the first UE sends PDCP status reports to the gNB in PTM mode, and in step 852, the second UE sends PDCP status reports to the gNB in PTM mode. The intersection of the lost PDCP SDUs is PDCP SDUs of SN #1 and #4 according to the status report transmitted by the first UE and the second UE. Accordingly, at step 860, the gNB retransmits PDCP SDUs having SNs #1 and #4 to the first UE and the second UE simultaneously in the PTM mode. At step 871, the first UE successfully receives PDCP SDUs with sn#1 and #4 and delivers PDCP SDUs with sn#1 to an upper layer. At step 872, the second UE successfully receives PDCP SDUs with sn#1 and #4 and delivers PDCP SDUs with sn#1 and #2 to an upper layer.

It should be noted that steps 811 and steps 821 and 822, steps 831 and 832, steps 841 and 842, steps 851 and 852 and/or steps 871 and 872 need not be performed simultaneously. Furthermore, one PTM group may include more than two UEs for PTM transmission, and the intersection of missing PDCP SDUs refers to the intersection of all UEs in the PTM group with missing PDCP SDUs. Furthermore, the complementary set of PDCP SDUs lost by each UE, e.g., PDCP SDU of sn#2 of the first UE and PDCP SDU of sn#3 of the second UE, may be retransmitted by the unicast service and/or other MRBs in PTP mode.

Fig. 11 is a flow chart of an embodiment of a method 900 in which RLC status reporting is triggered when MBS bearer type changes with RLC polling mechanism. Method 900 begins at step 910, where gNB 10 sends RRC signaling, including PTM/PTP handover commands, to inform UE 20 of MBS bearer type changes. At step 920, the gNB transmits an AMD PDU including the poll to the UE. At step 930, the UE performs a handoff of PTM and PTP as needed. At step 940, the UE sends an RLC status report to the gNB after the handover is completed.

As an alternative to the above embodiments, the UE may perform switching of PTM and PTP as needed after transmitting the RLC status report. In addition, the switching of PTM and PTP may be completed after transmitting RLC status report.

Fig. 12 is a flow chart of an embodiment of a method 1000 in which RLC status reporting is triggered when MBS bearer type changes without a polling mechanism. Method 1000 begins at step 1010, where gNB 10 sends RRC signaling, including PTM/PTP handover commands, to inform UE 20 of MBS bearer type changes. At step 1020, the UE performs a handoff of PTM and PTP as needed. In step 1030, the ue sends an RLC status report to the gNB after the handover is completed. Thus, there is no need to include a polled AMD PDU in the method 1000, which indicates that the UE does not have to trigger RLC status reporting when polling from the gNB, thereby simplifying the process of triggering RLC status reporting and reducing resource consumption.

As an alternative to the above embodiments, the UE may perform switching of PTM and PTP as needed after transmitting the RLC status report. In addition, after the RLC status report is sent, the switching of PTM and PTP may be completed.

In one or more embodiments below, a status reporting mechanism is described for the second case, where PDCP state variable initialization for MRB configuration may result in data loss, and/or for the third case, where RLC state variable initialization for MRB configuration may result in data loss. The MRB configuration may be used for MRB setup requests of the PTM leg (including split MRBs configured with PTM leg and PTP leg) and/or HO in MBS data transmission, and/or re-establishment of MRB due to radio link failure.

Figure 13 is a flow chart of one embodiment of a method 1100 in which PDCP status reporting is triggered for MRB configuration upon initialization of PDCP state variables. Method 1100 begins at step 1110, where gNB 10 sends RRC signaling to UE 20, including an MRB establishment request for a PTM leg. At step 1120, the UE receives RRC signaling and performs MRB establishment for the PTM leg using PDCP state variable initialization. At step 1130, the UE sends PDCP status report to the gNB after MRB establishment is complete.

As an alternative to the above embodiments, the UE may send an RLC status report to the gNB instead of the PDCP status report after establishing the MRB of the PTM leg, e.g. upon initializing the PTM RLC entity for MRB configuration.

Fig. 14 is a flow chart of an embodiment of a method 1200 in which PDCP status reporting is triggered when PDCP state variables initialize HO in MBS data transmission. The method 1200 begins with step 1210, wherein the S-gNB 11 performs MBS data transmission to the UE 20. At step 1220, the S-gNB sends a HO request to the T-gNB 12. In step 1230, the T-gNB sends an acknowledgement message of the HO request to the S-gNB. At step 1240, the S-gNB sends a HO command and an RRC reconfiguration message to the UE, the RRC reconfiguration message including a request for a PDCP entity re-establishment or a PDCP data recovery. At step 1250, the UE performs an HO from S-gNB to T-gNB using PDCP state variables initialization. In step 1260, the UE sends a PDCP status report to the T-gNB after completing the HO from the S-gNB to the T-gNB.

As an alternative to the above embodiments, the HO command may also trigger RLC status reports, and the UE may send RLC status reports instead of PDCP status reports to the gNB after completing HO from S-gNB to T-gNB.

Fig. 15 is a flow chart of an embodiment of a method 1300 in which PDCP status reporting triggers PDCP state variable initialization for MRB configuration in the event of a radio link failure. The method 1300 begins at step 1310, where a radio link between the gNB 10 and the UE 20 fails. At step 1310, the UE performs MRB re-establishment using PDCP state variable initialization. At step 1320, the UE sends a PDCP status report to the gNB after the MRB re-establishment is complete.

As an alternative to the above embodiments, the UE may send an RLC status report instead of a PDCP status report to the gNB after the MRB re-establishment is completed, for example, upon initializing the PTM RLC entity for MRB configuration.

Here, for all the above embodiments, the PDCP status report may refer to a conventional PDCP status report for PDCP status report as described above, or any other form of data packet that may be used for the PDCP entity to provide positive and/or negative acknowledgements for PDCP PDUs, PDCP SDUs, or the like.

Here, for all the above embodiments, the RLC STATUS report may refer to STATUS PDUs for RLC STATUS report as described above, or any other form of data packet that may be used for the RLC entity to provide positive and/or negative acknowledgements to RLC SDUs (or portions thereof) or RLC PDUs, etc.

As shown in fig. 16, a Base Station (BS) 10 for status reporting of MBS in 5G NR wireless communication includes a processing circuit 13 configured to support base station functions including, but not limited to, handover, RRC signaling, RRC reconfiguration, handover of PTM and PTP, automatic repeat request (ARQ) procedures and polling. The BS10 also includes a Radio Frequency (RF) interface 14 coupled to the processing circuit 13. The RF interface 14 is configured to transmit and receive communications with one or more UEs and/or one or more other BSs. More specifically, the processing circuitry 13 is configured to send signals including an indication of a change in MBS bearer type, and/or an indication of an initialization of a state variable for at least one MBS Radio Bearer (MRB) configuration; and receives a status report including acknowledgement information for the data packet. The processing circuit 13 is further configured to retransmit the data packet corresponding to the acknowledgement information, respectively.

As shown in fig. 17, a User Equipment (UE) 20 for MBS status reporting in 5G NR wireless communication includes processing circuitry 23 configured to support functions of the UE including, but not limited to, handover from S-gNB to T-gNB, handover of PTM and PTP, MRB configuration, PDCP/RLC status reporting. The UE 20 also includes a Radio Frequency (RF) interface 24 coupled with the processor circuit 23. The RF interface 24 is configured to transmit and receive communications with one or more other BSs and/or one or more UEs. The UE 20 may be a mobile device, for example, a smart phone or a mobile communication module provided in a vehicle. More specifically, the processing circuitry 23 is configured to receive signals, including an indication of a change in MBS bearer type, and/or an indication of an initialization of a state variable, for at least one MBS Radio Bearer (MRB) configuration; and correspondingly sends a status report including acknowledgement information for the data packet. The processing circuit 23 is further configured to perform a handoff of the PTM and PTP to correspond to the indication comprising the MBS bearer type change. The processing circuit 23 is further configured to send a status report comprising packet acknowledgement information after the PTM and PTP handover is completed or to send a status report comprising packet acknowledgement information before the PTM and PTP handover is completed.

Here, as described above, the status report may refer to a message that the receiving entity provides positive and/or negative acknowledgements for data packets transmitted by the sending entity. The status report may be a PDCP status report and/or an RLC status report.

Although various aspects of the present invention and its 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 invention as defined by the appended claims. Furthermore, the scope of the present application is not intended to be limited 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 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 figures may be implemented in various forms of hardware, software or combinations thereof. These components may be implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces. Moreover, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of a system and apparatus embodying the principles of the invention.

As used herein, various terms are used for the purpose of describing a particular implementation only and are not intended to limit the implementation. For example, ordinal terms (e.g., "first," "second," etc.) as used herein are used to modify an element, e.g., a scene, a structure, a component, an operation, etc., that does not by itself represent any priority or order of the element relative to another element, but rather merely distinguish the element from another element having the 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 also be referred to as a datagram, segment, block, cell, or frame, depending on the protocol used to transmit the data. The structure of the data packet depends on the type and protocol of the data packet. Typically, a data packet has a header and a payload. The term "coupled," although not necessarily directly, and not necessarily mechanically, is defined as connected; the two "coupled" items may be unified with each other. The terms "a" and "an" are defined as one or more unless the invention expressly requires otherwise. The phrase "and/or" means "and" or ". For example, A, B and/or C include: only a, only B, only C, A and B combinations, a and C combinations, B and C combinations or A, B and C combinations. In other words, "and/or" operates as an "or" comprising. Furthermore, the phrase "A, B, C or a combination thereof" or "A, B, C or any combination thereof" includes: aalone, balone, calone, 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 invention may contain background information about the problem or environment of the present invention rather than the prior art described by others. Accordingly, inclusion of materials in the background section does not represent an admission of the applicant's prior art.

Claims

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

Receiving signaling, including an indication of an MBS bearer type change, and/or an indication of an initialization of state variables of at least one MBS radio bearer MRB configuration; and

Transmitting a status report, the status report including acknowledgement information for the data packet.

2. The method as recited in claim 1, further comprising:

And performing switching of the point-to-multipoint PTM and the point-to-point PTP corresponding to the signaling, wherein the signaling comprises an indication of MBS bearing type change.

3. The method according to claim 2, wherein after said performing the handoff of the point-to-multipoint PTM and the point-to-point PTP corresponding to the signaling, the method further comprises sending a status report containing packet acknowledgment information, or wherein before said performing the handoff of the point-to-multipoint PTM and the point-to-point PTP corresponding to the signaling, the method further comprises sending a status report containing packet acknowledgment information.

4. The method according to claim 1, wherein the status report is a PDCP status report and/or an RLC status report.

5. The method of claim 1, wherein the initialization of the state variables is an initialization of PDCP state variables and/or RLC state variables.

6. The method according to claim 1, characterized in that the signaling is RRC signaling and/or RRC reconfiguration message.

7. The method of claim 6 wherein the RRC signaling includes a PTM/PTP switch command and/or an MRB configuration request.

8. The method of claim 6, wherein the RRC reconfiguration message includes a PTM/PTP exchange command and/or requests PDCP entity re-establishment and/or PDCP data recovery and/or uplink data exchange and/or PDCP entity reconfiguration to release a dual active protocol stack DAPS.

9. A user equipment, UE, for multicast and/or broadcast service, MBS, in wireless communication, the UE comprising:

Processing circuitry configured to:

10. The UE of claim 9, wherein the processing circuitry is further configured to:

11. The UE of claim 10, wherein the processing circuitry is further configured to:

And after the switching of the point-to-multipoint PTM and the point-to-point PTP corresponding to the signaling is performed, sending a status report containing the data packet acknowledgement information, or before the switching of the point-to-multipoint PTM and the point-to-point PTP corresponding to the signaling is performed, sending a status report containing the data packet acknowledgement information.

12. The UE of claim 9, wherein the status report is a PDCP status report and/or an RLC status report.

13. The UE of claim 9, wherein the initialization of the state variables is an initialization of PDCP state variables and/or RLC state variables.

14. The UE of claim 9, wherein the signaling is RRC signaling and/or RRC reconfiguration message.

15. The UE of claim 14, wherein the RRC signaling includes a PTM/PTP handover command and/or an MRB configuration request.

16. The UE of claim 14, wherein the RRC reconfiguration message includes a PTM/PTP exchange command, and/or a request of a PDCP entity to re-establish and/or a PDCP data recovery and/or an uplink data exchange and/or a reconfiguration of a PDCP entity to release a dual active protocol stack DAPS.

17. A method for multicast and/or broadcast service MBS status reporting, executable in a wireless communication base station BS, comprising: transmission signaling including an indication of an MBS bearer type change and/or an indication of an initialization of state variables of at least one MBS radio bearer MRB configuration; and

A status report is received, the status report including acknowledgement information for the data packet.

18. The method of claim 17, wherein the status report is a PDCP status report and/or an RLC status report.

19. The method of claim 17, wherein the initialization of the state variables is an initialization of PDCP state variables and/or RLC state variables.

20. The method according to claim 17, wherein the signaling is RRC signaling and/or RRC reconfiguration message.

21. The method of claim 20 wherein the RRC signaling includes a PTM/PTP switch command and/or an MRB configuration request.

22. The method of claim 20 wherein the RRC reconfiguration message includes a PTM/PTP exchange command and/or requests PDCP entity re-establishment and/or PDCP data recovery and/or uplink data exchange and/or PDCP entity reconfiguration to release DAPS.

23. The method of claim 17, further comprising:

And retransmitting the data packet according to the confirmation information.

24. The method of claim 23 wherein the data packet is a union of missing data packets for all UEs in the PTM group.

25. The method of claim 23 wherein the data packet is an intersection of missing data packets for all UEs in the PTM group.

26. A base station, BS, for multicast and/or broadcast services, MBS, in wireless communication, the base station comprising:

Processing circuitry configured to:

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

A status report is received including acknowledgement information for the data packet.

27. The BS of claim 26, wherein the status report is a PDCP status report and/or an RLC status report.

28. The BS of claim 26, wherein the initialization of the state variables is the initialization of PDCP state variables and/or RLC state variables.

29. The BS of claim 26, wherein the signaling is RRC signaling and/or RRC reconfiguration message.

30. The BS of claim 29, wherein the RRC signaling comprises a PTM/PTP switch command and/or an MRB configuration request.

31. The BS of claim 29, wherein the RRC reconfiguration message includes a PTM/PTP exchange command and/or requests PDCP entity re-establishment and/or PDCP data recovery and/or uplink data exchange and/or PDCP entity reconfiguration to release DAPS.

32. The BS of claim 26, wherein the processing circuit is configured to:

And retransmitting the data packet according to the confirmation information.

33. The BS of claim 32, wherein the data packet is a union of missing data packets for all UEs in the PTM group.

34. The BS of claim 28, wherein the data packet is an intersection of missing data packets for all UEs in the PTM group.

35. A chip, comprising:

a processor configured to invoke and run a computer program stored in a memory to cause a chip-mounted device to perform the method of any of claims 1-8 or 17-25.

36. A non-transitory machine-readable storage medium storing instructions which, when executed by a computer, cause the computer to perform the method of any of claims 1-8 or 17-25.

37. A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to perform the method of any one of claims 1-8 or 17-25.

38. A computer program product comprising a computer program, characterized in that the computer program causes a computer to perform the method of any one of claims 1-8 or 17-25.

39. A computer program, characterized in that the computer program causes a computer to perform the method of any one of claims 1-8 and 17-25.