Method, Apparatus and Computer Program Product for Providing Service Continuity for Multicast and Broadcast Service

Abstract

The present application generally relates to wireless communication technology. More particularly, the present application relates to a method and apparatus for providing service continuity for Multicast and Broadcast Service (MBS). The present application also relates to computer program product adapted for the same purpose. According to one embodiment of the present application, a method in a first RAN node for providing service continuity for Multicast and Broadcast Service (MBS) comprises: receiving (510) from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data associated with an MBS session previously transmitted from a second RAN node to the UE; and handling (520) retransmission of the missing PDUs based on the request.

Description

TECHNICAL FIELD

The present application generally relates to wireless communication technology. More particularly, the present application relates to a method and apparatus for providing service continuity for Multicast and Broadcast Service (MBS). The present application also relates to computer program product adapted for the same purpose.

BACKGROUND

In current New Radio (NR) standards, there is no broadcast/multicast feature support specified and thus no mobility support.

Service continuity in mobility is desired in many applications, not only for RRC_CONNECTED MBS User Equipments (UEs) but also for RRC_INACTIVE UEs, especially for those where UEs are originally scheduled to receive multicast services in RRC_CONNECTED but are temporarily moved to RRC_INACTIVE/RRC_IDLE state during a multicast session, e.g., due to high network load situation.

SUMMARY

It is therefore desirable to enable UEs to be able to continue receiving the same MBS services at a new cell/node with minimal or no data loss and without large interruption time incurred by the mobility. This present disclosure describes efficient solutions to handle MBS data loss for mobility of MBS UEs in RRC_INACTIVE state.

In the present disclosure, the solutions for mobility support, i.e., to enable UEs to continue receiving the same MBS service in a new gNB with minimal data loss are proposed.

According to the present disclosure, the solution as disclosed herein enables RRC_INACTIVE UEs to continue reception of MBS service(s) with reduced/minimal data loss when/while moving to a new Radio Access Network (RAN) node with minimal service interruption taken into consideration.

According to one aspect of the disclosure, it enables an RRC_INACTIVE UE to report data loss to a network when the data loss is detected for an MBS service with minimal/zero data loss being required. The current serving network node then either moves the UE to RRC_CONNECTED for handling data loss by itself or communicates with last serving network node to cooperatively handle data loss.

According to another aspect of the disclosure, it enable efficient communication between source and target network nodes involved in mobility of an RRC_INACTIVE UE with reduced/minimal signaling overhead in support of avoiding/minimizing MBS data loss incurred by the mobility.

According to one embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a User Equipment (UE), comprises: determining whether data loss occurs in MBS data previously transmitted to the UE from a first Radio Access Network (RAN) node; and if the data loss occurs, requesting the first RAN node or a second Radio Access Network (RAN) node to retransmit one or more missing Packet Data Units (PDUs) from the MBS data, wherein the first RAN node is one that previously transmitted the MBS data to the UE, and the second RAN node is one that the UE is able to resume to.

According to another embodiment, a User Equipment (UE) comprises: a processor; memory in communication with the processor; and instructions stored in the memory and operable, when executed by the processor, to cause the UE to perform the method as described above.

According to another embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first Radio Access Network (RAN) node, comprises: receiving from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data associated with a MBS session previously transmitted from a second RAN node to the UE; and handling retransmission of the missing PDUs based on the request.

According to another embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first Radio Access Network (RAN) node, comprises: receiving, from a second RAN node that a UE will resume to, a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first RAN node to the UE; and handling retransmission of the missing PDUs based on the request.

According to another embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first Radio Access Network (RAN) node, is characterized by comprising: receiving, from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first RAN node to the UE; moving the UE to RRC_CONNECTED; and retransmitting the missing PDUs to the UE.

According to another embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first Radio Access Network (RAN) node, comprises: receiving, from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first node to the UE; and requesting, either during a context retrieve procedure or during a handover preparation phase, a second RAN node to retransmit the missing PDUs to the UE.

According to another embodiment, a method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first Radio Access Network (RAN) node, comprises: transmitting MBS data associated with a MBS session to a UE;

• • releasing the UE to RRC_INACTIVE; and informing at least one second RAN node of a reception status of the MBS session at the UE.

According to another embodiment, a Radio Access Network (RAN) node comprises: a processor; memory in communication with the processor; and instructions stored in the memory and operable, when executed by the processor, to cause the RAN node to perform the method as described above.

According to another embodiment, a computer program product for providing service continuity for Multicast and Broadcast Service (MBS), the computer program product being embodied in a computer readable storage medium and comprising computer instructions for perform the method as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features, and advantages would be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which:

FIG. 1 schematically illustrates an example of signaling flow for PTM-PTM mobility for RRC_INACTIVE UE.

FIG. 2 schematically illustrates an example of signaling flow for PTM-PTP mobility for RRC_INACTIVE UE.

FIG. 3 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 4 is a block diagram illustrating a UE according to another embodiment.

FIG. 5 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 6 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 7 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 8 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 9 schematically illustrates a flowchart of the method for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention.

FIG. 10 is a block diagram illustrating a RAN node according to another embodiment.

FIG. 11 is a block diagram of a UE according to another embodiment.

FIG. 12 is a block diagram illustrating a RAN node according to another embodiment.

FIG. 13 is a block diagram illustrating a RAN node according to another embodiment.

FIG. 14 is a block diagram illustrating a RAN node according to another embodiment.

FIG. 15 is a block diagram illustrating a RAN node according to another embodiment.

FIG. 16 is a block diagram illustrating a RAN node according to another embodiment.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term “processor” refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Also, use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

NR_MBS Work Item Objectives

There was no broadcast/multicast feature support is specified in the first two NR releases, i.e. Rel-15 and Rel-16. 3GPP has defined a new work item (WI) on NR support of multicast and broadcast services (NR_MBS).

Specify RAN basic functions for broadcast/multicast for UEs in RRC_CONNECTED state [RAN1, RAN2, RAN3]:

• • Specify a group scheduling mechanism to allow UEs to receive Broadcast/Multicast service [RAN1, RAN2]
    • This objective includes specifying necessary enhancements that are required to enable simultaneous operation with unicast reception.
  • Specify support for dynamic change of Broadcast/Multicast service delivery between multicast (Point-to-Multipoint, PTM) and unicast (Point-to-Point, PTP) with service continuity for a given UE [RAN2, RAN3]
  • Specify support for basic mobility with service continuity [RAN2, RAN3]
  • Assuming that the necessary coordination function (like functions hosted by MCE, if any) resides in the gNB-CU, specify required changes on the RAN architecture and interfaces, considering the results of the SA2 SI on Broadcast/Multicast (SP-190625) [RAN3]
  • Specify required changes to improve reliability of Broadcast/Multicast service, e.g. by UL feedback. The level of reliability should be based on the requirements of the application/service provided.[RAN1, RAN2]
  • Study the support for dynamic control of the Broadcast/Multicast transmission area within one gNB-DU and specify what is needed to enable it, if anything [RAN2, RAN3]

Specify RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states [RAN2, RAN1]:

• • Specify required changes to enable the reception of Point to Multipoint transmissions by UEs in RRC_IDLE/RRC_INACTIVE states, with the aim of keeping maximum commonality between RRC_CONNECTED state and RRC_IDLE/RRC_INACTIVE state for the configuration of PTM reception. [RAN2, RAN1].

Note the possibility of receiving Point to Multipoint transmissions by UEs in RRC_IDLE/RRC_INACTIVE states, without the need for those UEs to get the configuration of the PTM bearer carrying the Broadcast/Multicast service while in RRC_CONNECTED state beforehand, is subject to verification of service subscription and authorization assumptions during the WI.

Among the objectives, it is required to specify changes to enable the reception of multicast services by UEs in RRC_IDLE/RRC_INACTIVE states, with the aim of keeping maximum commonality between RRC_CONNECTED state and RRC_IDLE/RRC_INACTIVE state for the configuration of PTM reception. Another objective is to specify support for basic mobility with service continuity, primarily defined for RRC_CONNECTED.

3GPP Progress

In RAN, the topic of MBS reception by UEs in RRC_IDLE/INACTIVE was first discussed in RAN2 #111-e but no agreements were reached. The companies then progress with an email discussion after the meeting:

• • [Post111-e][906][MBS] Idle mode support (CATT)
    • Scope: MBS support in Idle Inactive modes. Focus on Control Plane aspects. Collect and describe understanding of the consequences of the main solutions on the table: A) reuse Conn Mode solution vs B) reuse EUTRA solution. At limited level of detail, Identify further main sub-options if any (e.g. low high ambition level).
    • Intended outcome: Report

In one of the potential solutions being discussed for multicast reception in RRC_IDLE/INACTIVE, MBS/PTM configuration acquired while UE is in RRC_CONNECTED can be (re)used for reception of multicast services by UE in RRC_IDLE/INACTIVE. This includes also the scenario where network congestion occurs due to large number of multicast UEs in RRC_CONNECTED leading to the need for network to schedule a number of UEs to transit to temporally stay in RRC_IDLE/INACTIVE for multicast reception.

Handling Data Loss in Mobility for Legacy Unicast

In legacy unicast, for mobility in RRC_CONNECTED, i.e., handover, for radio bearers with Radio Link Control (RLC) Acknowledged Mode (AM) mode, Packet Data Convergence Protocol (PDCP) sublayer can either be re-established or initiate a data recovery procedure. Whereas, for radio bearers with RLC Unacknowledged Mode (UM) mode, PDCP can be re-established. For AM radio bearers, PDCP re-establishment and PDCP data recovery both trigger PDCP status report and retransmission of unsuccessfully delivered PDCP PDUs. But in case of UM radio bearers, there is no PDCP status reporting and the PDCP re-establishment only allows for transmission of PDCP Service Data Units (SDUs) which are already assigned PDCP sequence number (SN) but have not been submitted to lower layers.

In the PDCP status reporting for Downlink (DL) transmission, the UE sends a PDCP Ctrl PDU containing the report that includes the first missing COUNT (FMC) as the 32-bit COUNT value of the first missing PDCP SDUs within the reordering window, i.e., RX_DELIV (TS38.323). The status report can optionally include a bitmap with variable length to indicate which PDCP SDUs are missing and which SDUs are correctly received.

To minimize data loss during mobility, it is assumed that the stream of PDCP packets of MBS data and corresponding sequence numbering are the same at both the source and target nodes.

In one embodiment of the invention, when the lossless is required for an MBS service for a particular UE, the UE is prioritized to be kept in RRC_CONNECTED for receiving the MBS service. That is, in case network needs to schedule one or more UEs in the multicast group to transit from RRC_CONNECTED to RRC_INACTIVE/IDLE, the UE with lossless requirement will be the last to be forced to leave RRC_CONNECTED.

In one embodiment, UE locally maintains PDCP sequence number (SN)/COUNT of the received PDCP PDUs of MBS data while in RRC_INACTIVE. This is to allow the UE to inform network, if needed, when it detects missing data packets of an MBS session that has a requirement on minimal/no data loss. Such a requirement on data loss may be signaled to UE when it subscribes to the MBS service or joins the session, i.e., while in RRC_CONNECTED state.

Missing Data Packets Triggered by UE

In one embodiment, when an RRC_INACTIVE UE resumes to a new or target cell/gNB, i.e., different from the source node where its Radio Resource Control (RRC) connection was suspended, it indicates to the new cell/gNB the sequence number (SN) or part of SN of a PDCP PDU as the first expected SN or first expected COUNT (FEC) for (re)retransmission by the new cell/gNB. Note that FEC may correspond to a PDCP PDU whose SN is smaller than or equal to the last received PDCP PDU. In addition, in case of no missing PDU identified by the UE, FEC can be set to the SN of the last received PDCP PDU+1. With this indication, the target node knows that at least those missing PDCP PDUs need to be delivered to the UE.

Given that the grant size for Msg3 with RRCResumeRequest(1) may not be sufficient to include the whole SN/COUNT, which can be up to 18/32 bits long according to current PDCP specifications, several solutions are proposed for using the amount of X available bits in Msg3 for indicating PDUs to be retransmitted:

• • the UE can include only X least significant bits of the SN/COUNT as the FEC in Msg3. For example, when X is equal to 3 bits, the network can handle the recovery of up to 8 recently missed PDUs at UE.
    • To indicate the value of X, the network can broadcast this value via system information. Alternatively, this value can be included as part of common MBS configuration information signaled to UEs, i.e. either via dedicated signaling or common signaling.
    • UE and network need to agree on where to encode the X bits. One option is to use the padding bits in Msg3, if available. Another option is to define a new field in the RRCResumeRequest(1) message.
    • There needs a possibility to indicate that there is no missing PDCP PDUs to be delivered again. For example, this can be indicated by another 1-bit field in Msg3. Or A special value of FEC/SN in Msg3 can be defined for this.
  • The UE reports only an index into the range of most recently received SN/COUNT. This is a generalization of the above method. In both methods the network and the UE need to have a common understanding of the range. In the above method, the network and the UE need to have a common understanding of the SN/COUNT most significant bits that the UE does not address in Msg3. The range addressable by the UE therefore has to be large enough to ensure that the UE has not lost more PDUs than that belong to the range.
  • If e.g. the extended method should allow the recovery of up to 2{circumflex over ( )}Z lost PDUs but there are only X bits in Msg3, then each of the 2{circumflex over ( )}X values Y can represent one of the 2{circumflex over ( )}Z PDUs, e.g. in a linear fashion:

PDU number in the range=2{circumflex over ( )}Z/2{circumflex over ( )}X*Y

In another embodiment, when an RRC_INACTIVE UE detects missing data packets of an MBS session, instead of selecting a new cell, it performs resume procedure at current servicing node to request for data loss handling by the current node.

• • Similar to the previous case (resume to a new node), the UE needs to indicate to the source gNB that some PDCP PDUs are missing. This indication can be in form of a field in RRCResumeRequest(1) in Msg3 or in RRCResumeComplete in Msg5. In case of indication in Msg3, the UE can include only X least significant bits of the PDCP COUNT as the FEC.

In another embodiment, when an RRC_INACTIVE UE resumes to a new or target cell/gNB, i.e., different from the source node where its RRC connection was suspended, it performs random access procedure to enter RRC_CONNECTED. The UE then sends an PDCP status report indicating the status of missing PDCP PDUs from source cell/gNB without being triggered by the target cell/gNB.

• • Without a trigger from target, to make network understand the PDCP control PDU, the UE can indicate to the target in Msg3 or Msg5 of the random access procedure that it wants to be able to send a PDCP status report, for example, by being configured with AM RLC Multicast Radio Bearer (MRB). This indication can be done via an unused bit in Msg3/Msg5, such as a reserved bit in RRCResumeRequest(1). As another example, an 1-bit flag/field in Msg3 Medium Access Control (MAC) PDU or within the RRCResumeRequest(1) can be defined for this purpose.
  • In the UE, an additional triggering condition for PDCP status report can be specified based on the detection of missing data packets from previous cell/gNB. This trigger can be applicable to only AM MRB or both AM and UM MRB radio bearers.
  • The target once received the status report from UE, shall retransmit missing PDCP PDUs depending on the case, as described below.

Possible Changes at Target Node for Handling Data Loss

In one embodiment, the target node once is has received the indication from the UE (or from the source) learns that it is expected to start either delivering missing PDCP PDUs or delivering new MBS data to the UE. However, the expected MBS data might not be available at the target node due to either no ongoing MBS session at the target or the missing MBS data is not (or no longer) available in its local buffer. Thus, the target node may behave differently depending on the case.

• • Case 1: In case the FEC indicated by the UE is greater than the value corresponding to respective X least significant bits of the current PDCP COUNT of the same MBS data stream, i.e., target node is ahead in delivering MBS data compared to source node, the target only needs to locally restore/retransmit all the PDCP PDUs in the gap between current COUNT and FEC to the UE. Those missing PDUs may or may not be available in the local buffer of the target node. Therefore, to avoid the need to fetch data again, the RAN node can keep a number of already delivered PDCP PDUs in local buffer. FIG. 1 shows an example of signaling flow for this case.
    • Even with local buffering of delivered data, some or all the requested PDCP PDUs may be unavailable at the target. In this case, the target can request the retransmission of corresponding MBS packets from (MB)-User Plane Function (UPF) or other nodes in the same service area including source node.
      • Fetching data from source can be triggered by the target indicating the smallest PDCP COUNT to be forwarded from source, i.e., first forwarded COUNT (FFC). In addition, either the number of PDCP PDUs or the largest PDCP COUNT, i.e., last forwarded COUNT (LFC) should also be indicated. Alternatively, data forwarding keeps taking place until further notification from the target. To facilitate the data forwarding, as in legacy unicast, the Xn-Address can be included in the same retrieve UE MBS context procedure. The same applies to the MBS configuration at target cell/gNB.
      • The Xn-AP retrieve UE MBS context procedure can be extended for the target to cover such indication(s).
    • Case 2: In case the FEC indicated by the UE is smaller than the value corresponding to respective X least significant bits of the current PDCP COUNT of the same MBS data stream, i.e., source node is ahead in delivering MBS data compared to target node, the target can choose to skip one or several packets by starting to deliver PDCP PDU corresponding to FEC to the UE. In this case, there is no need for data forwarding from source. Hence, the target can inform the source by an indication in the retrieve UE MBS context procedure. This indication can be in form of a special predefined value of the smallest expected PDCP COUNT (described earlier), e.g., where all bits are set to 1. Alternatively, an additional 1-bit flag in the context retrieve request can be defined.
  • Case 3: In case the target supports MBS feature but there is no current COUNT for the MBS data stream, i.e., no ongoing MBS session at target node, the target can indicate this to the source so that data forwarding can take place until the target receives data from core i.e., (MB)-UPF and determines that it has all MBS data to maintain service continuity. In this context, service continuity means no gap between the first packet received from the core and the data forwarded from the source. FIG. 2 shows an example of signaling flow for this case.
    • The indication to the source is in the retrieve UE MBS context request and can include the FEC requested by the UE and an additional 1-bit flag, i.e., to indicate MBS session is not available (NA indication). Alternative to the 1-bit flag, the absence of MBS/PTM configuration in the retrieve UE MBS context can be an implicit indication (see also FIG. 2).
      • In this case, the target once established the session and received data from the core, it indicates to the source for stopping the data forwarding. This can be done by extending an existing Xn-AP procedure, e.g., Xn-AP UE context release or defining a new Xn-AP procedure for this purpose.
  • Case 4: In case the target does not support MBS feature, the target can indicate this to the source node as well as coordinating with the core for establishing a PDU session to deliver MBS data with the individual delivery method instead. The indication to the source node can be done by target sending the UE context release message with the FEC requested by the UE. Once received such a context release request, the source forwards all related MBS data to the target and releases the UE MBS context. Note that there is no context retrieval in this case. The handling of data forwarded from the source and newly arrived data through PDU session is outside the scope of this invention.

In another embodiment, when the data forwarding from source node is needed, the target node keeps the UE in RRC_CONNECTED after the resume procedure and configures AM RLC mode for the MBS radio bearer for improved reliability and service continuity.

Possible Changes at Source Node for Handling Data Loss

In one embodiment, in response to the MBS context request from the target, the source cell/gNB shall check if there is any MBS-related indication/parameter and behave accordingly:

• • In case there is no such a need to forward any missing PDCP PDUs (case 2 above), i.e., no FFC or FEC, the source does not even forward any pending PDCP PDUs which have been constructed but have not been yet delivered to RLC sublayer. This is because the target should be able to locally construct and deliver the same data packets to the UE.
  • In case there is FEC or FFC indicated by the target, the source forwards those missing PDCP PDUs that may include constructed but not yet delivered PDCP PDUs.
    • If the requested PDCP PDUs are no longer available at the source, the source can request the retransmission of corresponding MBS packets from (MB)-UPF or other NG-RAN nodes in the same service area.

In another embodiment, if the RRC_INACTIVE UE performs random access and indicates FEC to the source:

• • The source can move the UE to RRC_CONNECTED for retransmission of missing PDUs.
    • Depending on expected level of reliability, the gNB can configure respective MBS radio bearer with either AM or UM RLC mode for the UE while in RRC_CONNECTED and delivers again the missing PDUs.
    • After successful delivery of the missing data packets, the current gNB can release the UE to RRC_INACTIVE. The UE can select another cell/gNB and continue MBS reception with the new cell/gNB either in RRC_CONNECTED or RRC_INACTIVE.
      • Alternatively, the UE can indicate that it intends to move to a specific cell/gNB so that the current serving gNB can redirect the UE by performing handover procedure. Such an indication can be either in Msg3, in Msg5 during the random access or in another message while in RRC_CONNECTED (e.g., measurement procedure).
  • Alternative to retransmission of missing PDCP PDUs at the source, the source can store the FEC in the UE context and provide to the target during either during the context retrieve procedure (when UE is resuming to target) or during handover preparation phase when UE is in RRC_CONNECTED. In this case, target shall handle the missing PDUs as described above.

In another embodiment, when the source cell/gNB releases a UE to RRC_INACTIVE, the source informs potential target cells/gNBs of the UE's reception status of the MBS session. This is to enable potential target cells/gNBs to be prepared for the case the UE moves to their area and requests for retransmission. Such a preparation in advance can help get rid of data forwarding between source and target. Example of potential target nodes can be similar to nodes in RAN notification area (RNA), e.g., neighboring nodes. The communication between source and potential target nodes can be in form of pre-population of UE MBS context, i.e., the source sends UE MBS context to potential targets after/during the connection release. In this case, PDCP COUNT/SN of the last PDCP PDU can be included in the UE MBS context so that the target knows which PDUs should not be discarded in case retransmission is needed. If the target does not have the MBS session ongoing, it can establish the session in advance and get MBS data packet from core starting from the indicated COUNT/SN.

A flowchart of a method 300 for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention is shown in FIG. 3. FIG. 3 is described with reference to a “first node” and a “second node”. In certain embodiments, the first node is a first radio access network (RAN) node. In certain embodiments, the second node is a second RAN node.

The flowchart as shown in FIG. 3 comprises the following steps performed, e.g., at UE side:

Step 310: A UE determines whether data loss occurs in MBS data previously transmitted to the UE from a first node (e.g. a source node); and

Step 320: if the data loss occurs, the UE requests a first or second Radio Access Network (RAN) node to retransmit one or more missing Packet Data Units (PDUs) in the MBS data. The first node is one that previously transmitted the MBS data to the UE (i.e. a source node), and the second node is one that the UE will resume to (i.e. a target node), or one that the UE might resume to (in case the UE resumes to the source node instead of the target node).

In this embodiment, preferably, at the step of requesting, the UE sets a first expected count (FEC) based on a sequence number corresponding to a PDCP PDU last received from the first node. Afterwards, when the UE resumes to the first or second node, it sends the FEC to the first or second node.

In this embodiment, preferably, the FEC is set based on the whole of the sequence number.

In this embodiment, preferably, the FEC is set based on X least significant bits of the sequence number, and the value of X is notified to the UE by broadcasting via system information or by common MBS configuration information signaled to the UE.

In this embodiment, preferably, the FEC is included in RRCResumeRequest or RRCResumeRequest(1) sent to the first or second node.

In this embodiment, preferably, the FEC is included in RRCResumeComplete sent to the first node.

In this embodiment, preferably, the FEC is set to be equal to the sequence number plus 1 if no data loss occurs.

In this embodiment, preferably, at the step of requesting, when the UE resumes to the second node, it sends to the second node a PDCP status report indicating the missing PDUs.

In this embodiment, the step of requesting can further comprise indicating, to the second node, in a random access procedure that a PDCP status report is to be sent by the UE.

In this embodiment, the step of indicating can comprise indicating to the second node in a Msg3 or Msg5 message of the random access procedure.

FIG. 4 is a block diagram illustrating a UE according to another embodiment.

With reference to FIG. 4, the UE 40 comprises memory 410 and a processor 420 coupled to the memory 410. The memory 410 is configured to store a computer program 430 comprising computer instructions. The processor 420 is configured to execute the computer instructions to perform some or all of the method steps as shown in FIG. 3, including none, any, or all of the above-described optional and/or preferred features associated with that method. More generally, the UE 40 can be configured to perform the method steps as shown in FIG. 3, and none, any, or all of the above-described optional and/or preferred features associated with that method.

A flowchart of a method 500 for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in FIG. 5. FIG. 5 is described with reference to a “source node” and a “target node”. In certain embodiments, the source node is a source radio access network (RAN) node. In certain embodiments, the target node is a target RAN node.

The flowchart as shown in FIG. 5 comprises the following steps performed at RAN side or a RAN node, e.g., a source node (previously serving node) which transmits MBS data associated with a MBS session previously to a UE, or a target node (current serving node) which the UE will resume to.

Step 510: The target node receives from the UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data associated with a MBS session previously transmitted from the source node to the UE.

Step 520: The target node handles retransmission of the missing PDUs based on the request.

In this embodiment, preferably, the step of handling is performed as follows:

Based on a first expected count (FEC) included in the request, the target node determines whether the missing PDUs are available at the target node. The FEC is set based on a sequence number corresponding to a PDCP PDU last received from the source node.

Then, if the missing PDUs are unavailable at the target node, the target node requests the source node to transmit the missing PDUs to the first node. This request can be sent by Retrieve UE MBS context.

An MBS session can be established at the target node for the UE.

Afterwards, the target node continues the MBS session by transmitting to the UE the missing PDUs along with MBS data that the first node receives from an MB-UPF.

In this embodiment, preferably, the FEC is set based on the whole of the sequence number or X least significant bits of the sequence number, and the value of X is notified to the UE by broadcasting via system information or by common MBS configuration information signaled to the UE.

In this embodiment, preferably, the FEC is included in RRCResumeRequest/RRCResumeRequest(1) sent to the target node.

In this embodiment, preferably, the step of handling is performed as follows:

If the target node determines the MBS session is unavailable at the target node, it requests the source node to forward MBS data received from an MB-UPF to the source node until the target node receives MBS data from the MB-UPF.

An MBS session can be established at the target node for the UE.

Then, the target node continues the MBS session by transmitting to the UE the MBS data forwarded by the source node and the MBS data received from the MB-UPF.

In this embodiment, preferably, the flowchart further comprises the following step: The target node informs the source node to stop forwarding the MBS data after receiving the MBS data from the MB-UPF.

In this embodiment, preferably, the step of handling is performed as follows:

If the target node determines the MBS session is not supported by the target node, it requests the source node to release the MBS session and forward MBS data from an MB-UPF to the target node.

Then, the target node coordinates with the MB-UPF to establish a PDU session instead of the MBS session.

A flowchart of a method 600 for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in FIG. 6. FIG. 6 is described with reference to a “source node” and a “target node”. In certain embodiments, the source node is a source radio access network (RAN) node. In certain embodiments, the target node is a target RAN node.

The flowchart as shown in FIG. 6 comprises the following steps performed at RAN side or a RAN node, e.g., a source node (previously serving node) which transmits MBS data associated with a MBS session previously to a UE.

Step 610: The source node receives from a target node that the UE will resume to, a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the source node to the UE.

Step 620: The source node handles retransmission of the missing PDUs based on the request.

In this embodiment, preferably, the step of handling is performed as follows:

Based on a first expected count (FEC) included in the request, the source node determines whether the missing PDUs are available at the source node. The FEC was set based on a sequence number corresponding to a PDCP PDU last received from the source node at the UE.

Then, if unavailable, the source node requests an MB-UPF or other nodes belonging to the same service area as the source node to transmit the missing PDUs to the target node.

A flowchart of a method 700 for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in FIG. 7. FIG. 7 is described with reference to a “source node” and a “target node”. In certain embodiments, the source node is a source radio access network (RAN) node. In certain embodiments, the target node is a target RAN node.

The flowchart as shown in FIG. 7 comprises the following steps performed at RAN side or a RAN node, e.g., a source node (previously serving node) which transmits MBS data associated with a MBS session previously to a UE.

Step 710: The source node receives, from the UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the source node to the UE.

Step 720: The source node moves the UE to RRC_CONNECTED.

Step 730: The source node retransmits the missing PDUs to the UE.

In this embodiment, preferably, the retransmitting is carried out by configuring MBS radio bearers with either Acknowledged Mode (AM) or

Unacknowledged Mode (UM) Radio Link Control (RLC) mode based on expected level of reliability.

In this embodiment, preferably, the flowchart further comprises the following step: the source node redirects the UE to a target node by performing handover procedure.

A flowchart of a method 800 for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in FIG. 8. FIG. 8 is described with reference to a “source node” and a “target node”. In certain embodiments, the source node is a source radio access network (RAN) node. In certain embodiments, the target node is a target RAN node.

The flowchart as shown in FIG. 8 comprises the following steps performed at RAN side or a RAN node, e.g., a source node (previously serving node) which transmits MBS data associated with a MBS session previously to a UE.

Step 810: The source node receives, from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the source node to the UE.

Step 820: The source node requests, either during a context retrieve procedure or during a handover preparation phase, a target node, which the UE will resume to, to retransmit the missing PDUs to the UE.

In this embodiment, preferably, the requesting is carried out by sending a first expected count (FEC) from the source node to the target node, the FEC is set based on a sequence number corresponding to a PDCP PDU last received from the source node.

A flowchart of a method 900 for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in FIG. 9. FIG. 9 is described with reference to a “source node” and a “target node”. In certain embodiments, the source node is a source radio access network (RAN) node. In certain embodiments, the target node is a target RAN node.

The flowchart as shown in FIG. 9 comprises the following steps performed at RAN side or a RAN node, e.g., a source node (previously serving node) which transmits

MBS data associated with a MBS session previously to a UE.

Step 910: The source node transmits MBS data associated with an MBS session to the UE.

Step 920: The source node releases the UE to RRC_INACTIVE.

Step 930: The source node informs at least one node, which the UE possibly resumes to, of a reception status of the MBS session at the UE.

In this embodiment, preferably, the at least node has the same RAN notification area (RNA) as the source node.

In this embodiment, preferably, the informing is carried out by sending a UE MBS context to the at least node after or during the releasing of the UE, and the UE MBS context includes a sequence number corresponding to a PDCP PDU last received from the source node.

FIG. 10 is a block diagram illustrating a RAN node according to another embodiment.

With reference to FIG. 10, the RAN node 1000 comprises memory 1010 and a processor 1020 coupled to the memory 1010. The memory 1010 is configured to store a computer program 1030 comprising computer instructions. The processor 1020 is configured to execute the computer instructions to perform some or all of the method steps as shown in FIGS. 5-9, including none, any, or all of the above-described optional and/or preferred features associated with that method. More generally, the UE 40 can be configured to perform the method steps as shown in any of FIGS. 5-9, and none, any, or all of the above-described optional and preferred features associated with those methods.

FIG. 11 is a block diagram illustrating a UE 1100 according to another embodiment. FIG. 11 illustrates functional modules or units in a UE which may execute examples of the method in FIG. 3, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 11 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The UE 1100 comprises a determining unit 1102 that is configured to determine whether data loss occurs in MBS data previously transmitted to the UE from a first RAN node

The UE 1100 also comprises a requesting unit 1104 that is configured to request the first RAN node or a second RAN node to retransmit one or more missing PDUs from the MBS data if the data loss occurs. The first RAN node is one that previously transmitted the MBS data to the UE, and the second RAN node is one that the UE is able to resume to.

FIG. 12 is a block diagram illustrating a first RAN node 1200 according to another embodiment. FIG. 12 illustrates functional modules or units in an example of a first RAN node 1200 which may execute examples of the method in FIG. 5, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 12 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The RAN node 1200 comprises a receiving unit configured to receive from a UE a request for retransmitting one or more missing PDUs in MBS data associated with an MBS session previously transmitted from a second RAN node to the UE.

The RAN node 1200 also comprises a handling unit configured to handle retransmission of the missing PDUs based on the request.

FIG. 13 is a block diagram illustrating a first RAN node 1300 according to another embodiment. FIG. 13 illustrates functional modules or units in an example of a first RAN node 1300 which may execute examples of the method in FIG. 6, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 13 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The RAN node 1300 comprises a a receiving unit configured to receive, from a second RAN node that a UE will resume to, a request for retransmitting one or more missing PDUs in MBS data previously transmitted from the first RAN node to the UE.

The RAN nodes 1300 also comprises a handling unit configured to handle retransmission of the missing PDUs based on the request.

FIG. 14 is a block diagram illustrating a first RAN node 1400 according to another embodiment. FIG. 14 illustrates functional modules or units in an example of a first RAN node 1400 which may execute examples of the method in FIG. 7, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 14 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The first RAN node 1400 comprises a receiving unit configured to receive, from a UE a request for retransmitting one or more missing PDUs in MBS data previously transmitted from the first RAN node to the UE;

The first RAN node 1400 also comprises a moving unit configured to move the UE to RRC_CONNECTED.

The first RAN node 1400 also comprises a retransmitting unit configured to retransmit the missing PDUs to the UE.

FIG. 15 is a block diagram illustrating a first RAN node 1500 according to another embodiment. FIG. 15 illustrates functional modules or units in an example of a first RAN node 1500 which may execute examples of the method in FIG. 8, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 15 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The first RAN node 1500 comprises a receiving unit configured to receive, from a UE a request for retransmitting one or more missing PDUs in MBS data previously transmitted from the first RAN node to the UE.

The first RAN node 1500 also comprises a requesting unit configured to request, either during a context retrieve procedure or during a handover preparation phase, a second RAN node to retransmit the missing PDUs to the UE.

FIG. 16 is a block diagram illustrating a first RAN node 1600 according to another embodiment. FIG. 16 illustrates functional modules or units in an example of a first RAN node 1600 which may execute examples of the method in FIG. 9, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in FIG. 16 are functional units, and may be realized in hardware, software, or any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

The first RAN node 1600 comprises a transmitting unit configured to transmit MBS data associated with an MBS session to a UE.

The first RAN node 1600 also comprises a releasing unit configured to release the UE to RRC_INACTIVE.

The first RAN node 1600 also comprises an informing unit configured to inform at least one second RAN node of a reception status of the MBS session at the UE.

It should be noted that the aforesaid embodiments are illustrative instead of restricting, substitute embodiments may be designed by those skilled in the art without departing from the scope of the claims enclosed. The wordings such as “include”, “including”, “comprise” and “comprising” do not exclude elements or steps which are present but not listed in the description and the claims. It also shall be noted that as used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise. Embodiments can be achieved by means of hardware including several different elements or by means of a suitably programmed computer. In the unit claims that list several means, several ones among these means can be specifically embodied in the same hardware item. The use of such words as first, second, third does not represent any order, which can be simply explained as names.

The following series of statements set out various exemplary and non-limiting embodiments of the techniques described herein:

1. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a User Equipment (UE), be characterized in comprising:

• • determining whether data loss occurs in MBS data previously transmitted to the UE from a first node; and
  • if the data loss occurs, requesting a first or second Radio Access Network (RAN) node to retransmit one or more missing Packet Data Units (PDUs) in the MBS data, wherein the first node is one that previously transmitted the MBS data to the UE, and the second node is one that the UE will resume to.

2. The method according to statement 1, wherein the step of requesting comprising:

• • setting a first expected count (FEC) based on a sequence number corresponding to a PDCP PDU last received from the first node; and
  • when the UE resumes to the first or second node, sending the FEC to the first or second node.

3. The method according to statement 2, wherein the FEC is set based on the whole of the sequence number.

4. The method according to statement 2, wherein the FEC is set based on X least significant bits of the sequence number, and the value of X is notified to the UE by broadcasting via system information or by common MBS configuration information signaled to the UE.

5. The method according to statement 2, wherein the FEC is included in RRCResumeRequest(1) sent to the first or second node.

6. The method according to statement 2, wherein the FEC is included in RRCResumeComplete sent to the first node.

7. The method according to statement 2, wherein the FEC is set to be equal to as the sequence number plus 1 if no data loss occurs.

8. The method according to statement 1, wherein the step of requesting:

• • when the UE resumes to the second node, sending to the second node a PDCP status report indicating the missing PDUs.

9. A User Equipment (UE), be characterized in comprising:

• • a processor;
  • memory in communication with the processor; and
  • instructions stored in the memory and operable, when executed by the processor, to cause the apparatus to perform the method according to anyone of statements 1-8.

10. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first node, be characterized in comprising:

• • receiving from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data associated with an MBS session previously transmitted from a second node to the UE; and
  • handling retransmission of the missing PDUs based on the request.

11. The method according to statement 10, wherein the first node is one that the UE will resume to, and the step of handling comprising:

• • based on a first expected count (FEC) included in the request, determining whether the missing PDUs are available at the first node, wherein the FEC being set based on a sequence number corresponding to a PDCP PDU last received from the second node;
  • if unavailable, requesting the second node to transmit the missing PDUs to the first node; and
  • continuing the MBS session by transmitting to the UE the missing PDUs along with MBS data that the first node receives from an MB-UPF.

12. The method according to statement 11, wherein the FEC is set based on the whole of the sequence number or X least significant bits of the sequence number, and the value of X is notified to the UE by broadcasting via system information or by common MBS configuration information signaled to the UE.

13. The method according to statement 11, wherein the FEC is included in RRCResumeRequest(1) sent to the first node.

14. The method according to statement 10, wherein the first node being one that the UE will resume to and the step of handling comprising:

• • if determining the MBS session is unavailable at the first node, requesting the second node to forward MBS data received from an MB-UPF to the second node until the first node receives MBS data from the MB-UPF; and
  • continuing the MBS session by transmitting to the UE the MBS data forwarded by the second node and the MBS data received from the MB-UPF.

15. The method according to statement 14, further comprising:

• • informing the second node to stop forwarding the MBS data after receiving the MBS data from the MB-UPF.

16. The method according to statement 10, wherein the step of handling comprising:

• • if determining the MBS session is not supported, requesting the second node to release the MBS session and forward MBS data from an MB-UPF to the first node; and
  • coordinating with the MB-UPF to establish a PDU session instead of the MBS session.

17. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first node, be characterized in comprising:

• • receiving, from a second node that a UE will resume to, a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first node to the UE; and
  • handling retransmission of the missing PDUs based on the request.

18. The method according to statement 17, wherein the step of handling comprising:

• • based on a first expected count (FEC) included in the request, determining whether the missing PDUs are available at the first node, wherein the FEC being set based on a sequence number corresponding to a PDCP PDU last received from the first node at the UE; and
  • if unavailable, requesting an MB-UPF or other nodes in the same service area as the first node to transmit the missing PDUs to the second node.

19. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first node, be characterized in comprising:

• • receiving, from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first node to the UE;
  • moving the UE to RRC_CONNECTED; and
  • retransmitting the missing PDUs to the UE.

20. The method according to statement 19, wherein the retransmitting is carried out by configuring MBS radio bearers with either AM or UM RLC mode based on expected level of reliability.

21. The method according to statement 19, further comprising:

• • redirecting the UE to a second node by performing handover procedure.

22. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first node, be characterized in comprising:

• • receiving, from a UE a request for retransmitting one or more missing Packet Data Units (PDUs) in MBS data previously transmitted from the first node to the UE; and
  • requesting a second node to retransmit the missing PDUs to the UE either during a context retrieve procedure or during a handover preparation phase.

23. The method according to statement 22, wherein the requesting is carried out by sending a first expected count (FEC) to the second node, the FEC being set based on a sequence number corresponding to a PDCP PDU last received from the first node.

24. A method for providing service continuity for Multicast and Broadcast Service (MBS), which is carried out by a first node, be characterized in comprising:

• • transmitting MBS data associated with an MBS session to a UE;
  • releasing the UE to RRC_INACTIVE; and
  • informing at least one second node a reception status of the MBS session at the UE.

25. The method according to statement 24, wherein the second node has the same RAN notification area (RNA) as the first node.

26. The method according to statement 24, wherein the informing is carried out by sending a UE MBS context to the second node after or during the releasing of the UE, the UE MBS context including a sequence number corresponding to a PDCP PDU last received from the first node.

27. A node, be characterized in comprising:

• • a processor;
  • memory in communication with the processor; and
  • instructions stored in the memory and operable, when executed by the processor, to cause the apparatus to perform the method according to anyone of statements 10-27.

28. The node according to statement 27, wherein the node is a base station, an eNodeB or gNodeB.

29. A computer program product for providing service continuity for Multicast and Broadcast Service (MBS), the computer program product being embodied in a computer readable storage medium and comprising computer instructions for perform the method according to anyone of statements 1-8.

30. A computer program product for providing service continuity for Multicast and Broadcast Service (MBS), the computer program product being embodied in a computer readable storage medium and comprising computer instructions for perform the method according to anyone of statements 10-27.

Claims

1.-113. (canceled)

114. A method for a User Equipment (UE) configured to support service continuity for Multicast and Broadcast Service (MBS), the method comprising: determining whether data loss occurred in MBS data previously transmitted by a first Radio Access Network (RAN) node while the UE was in an RRC_INACTIVE state; andsending to a second RAN node a request to resume the UE's Radio Resource Control (RRC) connection from the RRC_INACTIVE state, wherein when it is determined that the data loss occurred, the request to resume includes a request for retransmission of one or more missing Packet Data Units (PDUs) from the MBS data.

115. The node of claim 114, wherein the request to resume includes a first expected count (FEC) based on a sequence number corresponding to a last Packet Data Convergence Protocol (PDCP) PDU received by the UE from the first RAN node.

116. The node of claim 115, further comprising setting the FEC according to the following: when it is determined that the data loss occurred, a value less than or equal to the sequence number corresponding to the last PDCP PDU received by the UE from the first RAN node; andwhen it is determined that the data loss did not occur, a value greater than the sequence number corresponding to the last PDCP PDU received by the UE from the first RAN node.

117. The node of claim 116, wherein setting the FEC is based on one of the following: all bits of the sequence number, or X least significant bits of the sequence number.

118. The node of claim 114, further comprising, after resuming the UE's RRC connection with the second RAN node, sending to the second RAN node a Packet Data Convergence Protocol (PDCP) status report indicating the one or more missing PDUs.

119. A method for a first radio access Network (RAN) node to provide service continuity for Multicast and Broadcast Service (MBS), the method comprising: receiving from a User Equipment (UE) a request to resume the UE's Radio Resource Control (RRC) connection from an RRC_INACTIVE state, wherein the request to resume includes a request for retransmission of one or more missing Packet Data Units (PDUs) in MBS data associated with an MBS session, wherein the one or missing PDUs were previously transmitted by a second RAN node while the UE was in the RRC_INACTIVE state; andhandling retransmission of the missing PDUs according to the request for retransmission.

120. The node of claim 119, wherein the FEC is based on one of the following: all bits of the sequence number, or X least significant bits of the sequence number.

121. The node of claim 119, wherein handling retransmission of the missing PDUs according to the request for retransmission comprises: based on a first expected count (FEC) included in the request, determining whether the missing PDUs are available at the first RAN node, wherein the FEC is based on a sequence number corresponding to a last PDCP PDU received by the UE;when it is determined that the missing PDUs are unavailable at the first RAN node, requesting the second RAN node to transmit the missing PDUs to the first RAN node;establishing an MBS session at the first RAN node for the UE; andcontinuing the MBS session by transmitting to the UE the missing PDUs along with MBS data that the first RAN node receives from a Multicast Broadcast User Plane Function (MB-UPF).

122. The node of claim 119, wherein handling retransmission of the missing PDUs according to the request for retransmission comprises: when it is determined that the MBS session is unavailable at the first RAN node, requesting the second RAN node to forward MBS data received from a Multicast Broadcast User Plane Function (MB-UPF), to the first RAN node until the first RAN node receives MBS data from the MB-UPF;establishing an MBS session at the first RAN node for the UE; andcontinuing the MBS session by transmitting to the UE the MBS data forwarded by the second RAN node and the MBS data received from the MB-UPF.

123. The node of claim 119, wherein handling retransmission of the missing PDUs according to the request for retransmission comprises: when it is determined that MBS is not supported by the first RAN node, requesting the second RAN node to release the MBS session and forward MBS data from a Multicast Broadcast User Plane Function (MB-UPF) to the first RAN node; andcoordinating with the MB-UPF to establish a PDU session instead of the MBS session.

124. The node of claim 119, wherein handling retransmission of the missing PDUs according to the request for retransmission comprises: based on a first expected count (FEC) included in the request, determining whether the missing PDUs are available at the first RAN node, wherein the FEC is based on a sequence number corresponding to a Packet Data Convergence Protocol (PDCP) PDU last received from the first RAN node at the UE; andwhen it is determined that the missing PDUs are unavailable, requesting one of the following to transmit the missing PDUs to the second RAN node: a Multicast Broadcast User Plane Function (MB-UPF), or other RAN nodes in the same service area as the first RAN node.

125. The node of claim 119, wherein the second RAN node is part of a same RAN notification area (RNA) as the first RAN node.

126. A User Equipment (UE) configured to support service continuity for Multicast and Broadcast Service (MBS), the UE comprising: a processor; anda memory operably coupled to the processor and containing instructions that, when executed by the processor, configure the UE to: determine whether data loss occurred in MBS data previously transmitted by a first Radio Access Network (RAN) node while the UE was in an RRC_INACTIVE state; andsend to a second RAN node a request to resume the UE's Radio Resource Control (RRC) connection from the RRC_INACTIVE state, wherein when it is determined that the data loss occurred, the request to resume includes a request for retransmission of one or more missing Packet Data Units (PDUs) from the MBS data.

127. The UE of claim 126, wherein the request to resume includes a first expected count (FEC) based on a sequence number corresponding to a last Packet Data Convergence Protocol (PDCP) PDU received by the UE from the first RAN node.

128. The UE of claim 127, wherein execution of the instructions further configures the UE to set the FEC according to the following: when it is determined that the data loss occurred, a value less than or equal to the sequence number corresponding to the last PDCP PDU received by the UE from the first RAN node; andwhen it is determined that the data loss did not occur, a value greater than the sequence number corresponding to the last PDCP PDU received by the UE from the first RAN node.

129. The UE of claim 128, wherein execution of the instructions configures the UE to set the FEC based on one of the following: all bits of the sequence number, or X least significant bits of the sequence number.

130. The UE of claim 126, wherein execution of the instructions further configures the UE to, after resuming the UE's RRC connection with the second RAN node, send to the second RAN node a Packet Data Convergence Protocol (PDCP) status report indicating the one or more missing PDUs.

131. A first radio access Network (RAN) node configured to provide service continuity for Multicast and Broadcast Service (MBS), the first RAN node comprising: a processor;a processor; anda memory operably coupled to the processor and containing instructions that, when executed by the processor, configure the first RAN node to: receive from a User Equipment (UE) a request to resume the UE's Radio Resource Control (RRC) connection from an RRC_INACTIVE state, wherein the request to resume includes a request for retransmission of one or more missing Packet Data Units (PDUs) in MBS data associated with an MBS session, wherein the one or missing PDUs were previously transmitted by a second RAN node while the UE was in the RRC_INACTIVE state; andhandle retransmission of the missing PDUs according to the request for retransmission.

132. The first RAN node of claim 131, wherein the FEC is based on one of the following: all bits of the sequence number, or X least significant bits of the sequence number.

133. The first RAN node of claim 131, wherein execution of the instructions configures the first RAN node to handle retransmission of the missing PDUs according to the request for retransmission based on: determining, based on the FEC included in the request, whether the missing PDUs are available at the first RAN node, wherein the FEC is based on a sequence number corresponding to a last PDCP PDU received by the UE;when it is determined that the missing PDUs are unavailable at the first RAN node, requesting the second RAN node to transmit the missing PDUs to the first RAN node;establishing an MBS session at the first RAN node for the UE; andcontinuing the MBS session by transmitting to the UE the missing PDUs along with MBS data that the first RAN node receives from a Multicast Broadcast User Plane Function (MB-UPF).

134. The first RAN node of claim 131, wherein execution of the instructions configures the first RAN node to handle retransmission of the missing PDUs according to the request for retransmission based on: based on determining that the MBS session is unavailable at the first RAN node, requesting the second RAN node to forward MBS data received from a Multicast Broadcast User Plane Function (MB-UPF), to the first RAN node until the first RAN node receives MBS data from the MB-UPF;establishing an MBS session at the first RAN node for the UE; andcontinuing the MBS session by transmitting to the UE the MBS data forwarded by the second RAN node and the MBS data received from the MB-UPF.

135. The first RAN node of claim 131, wherein execution of the instructions configures the first RAN node to handle retransmission of the missing PDUs according to the request for retransmission based on: based on determining that MBS is not supported by the first RAN node, requesting the second RAN node to release the MBS session and forward MBS data from a Multicast Broadcast User Plane Function (MB-UPF) to the first RAN node; andcoordinating with the MB-UPF to establish a PDU session instead of the MBS session.

136. The first RAN node of claim 131, wherein handling retransmission of the missing PDUs according to the request for retransmission comprises: based on a first expected count (FEC) included in the request, determining whether the missing PDUs are available at the first RAN node, wherein the FEC is based on a sequence number corresponding to a Packet Data Convergence Protocol (PDCP) PDU last received from the first RAN node at the UE; andwhen it is determined that the missing PDUs are unavailable, requesting one of the following to transmit the missing PDUs to the second RAN node: a Multicast Broadcast User Plane Function (MB-UPF), or other RAN nodes in the same service area as the first RAN node.

137. The first RAN node of claim 131, wherein the second RAN node is part of a same RAN notification area (RNA) as the first RAN node.