Patent Description:
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.

"<CIT> discloses a method in which first multicast/broadcast traffic data is received, buffered and transmitted via a first downlink channel; a retransmission request is received via an uplink channel; second multicast/broadcast traffic data is determined in dependence on the buffered first multicast data and in dependence on the received retransmission request; and the second multicast/broadcast traffic data is transmitted via a second downlink channel.

<CIT> discloses a method that includes, inter alia, receiving multicast data via a unicast data radio bearer or a multicast data radio bearer; receiving, by a user device located in a first cell, from the base station, a connection suspend message; entering, by the user device, a low activity state in response to the connection suspend message; and, receiving, by the user device, the multicast data via the multicast data radio bearer.

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.

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:.

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. 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.

There was no broadcast/multicast feature support is specified in the first two NR releases, i.e. Rel-<NUM> and Rel-<NUM>. 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 RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states [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.

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

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.

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 <NUM>-bit COUNT value of the first missing PDCP SDUs within the reordering window, i.e., RX_DELIV (TS38. 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.

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 + <NUM>. 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(<NUM>) may not be sufficient to include the whole SN/COUNT, which can be up to <NUM>/<NUM> 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:.

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.

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.

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.

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.

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 another embodiment, if the RRC_INACTIVE UE performs random access and indicates FEC to the source:.

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 <NUM> for providing service continuity for Multicast and Broadcast Service (MBS) according to one embodiment of the present invention is shown in <FIG> 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> comprises the following steps performed, e.g., at UE side:.

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(<NUM>) 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 <NUM> 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> is a block diagram illustrating a UE according to another embodiment.

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

A flowchart of a method <NUM> for providing service continuity for Multicast and Broadcast Service (MBS) according to another embodiment of the present invention is shown in <FIG> 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> 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 <NUM>: 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 <NUM>: 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(<NUM>) 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.

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.

The flowchart as shown in <FIG> 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 <NUM>: 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 <NUM>: 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.

Step <NUM>: 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 <NUM>: The source node moves the UE to RRC_CONNECTED.

Step <NUM>: 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.

Step <NUM>: 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 <NUM>: 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.

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

Step <NUM>: The source node releases the UE to RRC_INACTIVE.

Step <NUM>: 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> is a block diagram illustrating a RAN node according to another embodiment.

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

<FIG> is a block diagram illustrating a UE <NUM> according to another embodiment. <FIG> illustrates functional modules or units in a UE which may execute examples of the method in <FIG>, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in <FIG> 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 <NUM> comprises a determining unit <NUM> that is configured to determine whether data loss occurs in MBS data previously transmitted to the UE from a fist RAN node.

The UE <NUM> also comprises a requesting unit <NUM> 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> is a block diagram illustrating a first RAN node <NUM> according to another embodiment. <FIG> illustrates functional modules or units in an example of a first RAN node <NUM> which may execute examples of the method in <FIG>, for example according to computer readable instructions received from a computer program. It will be understood that the modules or units illustrated in <FIG> 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 <NUM> 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 <NUM> also comprises a handling unit configured to handle retransmission of the missing PDUs based on the request.

The RAN node <NUM> 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 <NUM> also comprises a handling unit configured to handle retransmission of the missing PDUs based on the request.

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

The first RAN node <NUM> 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 <NUM> 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.

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

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

The first RAN node <NUM> 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.

Claim 1:
A method for providing service continuity for Multicast and Broadcast Service, MBS, which is carried out by a User Equipment, UE, that is receiving MBS data while in a RRC_INACTIVE state, the method characterized in comprising:
determining (<NUM>) 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 (<NUM>), in a request to resume a Radio Resource Control, RRC, connection, the first RAN node or a second 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 the RRC connection to.