WO2022028544A1

WO2022028544A1 - User equipment and method for mbs radio bearer configuration

Info

Publication number: WO2022028544A1
Application number: PCT/CN2021/110933
Authority: WO
Inventors: Yunglan TSENG; Hungchen CHEN; Hengli CHIN
Original assignee: FG Innovation Company Limited
Priority date: 2020-08-05
Filing date: 2021-08-05
Publication date: 2022-02-10

Abstract

A user equipment (UE) and a method for Multicast Broadcast Service (MBS) radio bearer configuration are provided. The method includes receiving, from a serving cell, an MBS radio bearer configuration indicating a multicast bearer and a unicast bearer; and configuring the MBS radio bearer based on the received MBS radio bearer configuration to receive downlink (DL) data via at least one of the multicast bearer and the unicast bearer. The multicast bearer and the unicast bearer are associated with a common Packet Data Convergence Protocol (PDCP) entity. The unicast bearer is always activated in default after the UE configures the unicast bearer based on the received MBS radio bearer configuration.

Description

USER EQUIPMENT AND METHOD FOR MBS RADIO BEARER CONFIGURATION

FIELD

The present disclosure is related to wireless communication, and more particularly, to a method for Multicast Broadcast Service (MBS) radio bearer configuration in cellular wireless communication networks.

BACKGROUND

The acronyms in the present application are defined as follows and unless otherwise specified, the acronyms have the following meanings:

Abbreviation Full name

3GPP 3 ^rd Generation Partnership Project

5G 5 ^th Generation

5GC 5G Core

ARQ Automatic Repeat reQuest

AS Access Stratum

BS Base Station

BWP Bandwidth Part

CA Carrier Aggregation

CAG Closed Access Group

CN Core Network

CSI-RS Channel State Information Reference Signal

CU Central Unit

DAPS Dual Active Protocol Stack

DC Dual Connectivity

DCI Downlink Control Information

DL Downlink

DRB Data Radio Bearer

DU Distributed Unit

E-UTRA (N) Evolved Universal Terrestrial Radio Access (Network)

EN-DC E-UTRA NR Dual Connectivity

EPC Evolved Packet Core

FR Frequency Range

GNSS Global Navigation Satellite System

HARQ Hybrid Automatic Repeat reQuest

IAB Integrated Access and Backhaul

ID Identifier/Identity

IE Information Element

LAN Local Area Network

LTE Long Term Evolution

MAC Medium Access Control

MAC CE MAC Control Element

MBS Multicast Broadcast Service

MCG Master Cell Group

MIB Master Information Block

MN Master Node

MSG Message

MT Mobile Termination

NAS Non-Access Stratum

NE-DC NR -E-UTRA Dual Connectivity

NPN Non-Public Network

NR New Radio

NR-U NR Unlicensed

NW Network

PCell Primary Cell

PCI Physical Cell Identity

PDCCH Physical Downlink Control Channel

PDCP Packet Data Convergence Protocol

PDSCH Physical Downlink Shared Channel

PDU Protocol Data Unit

PHY Physical (layer)

PLMN Public Land Mobile Network

PNI-NPN Public Network Integrated Non-Public Network

PRACH Physical Random Access Channel

PSCell Primary SCG Cell /Primary Secondary Cell

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

QoS Quality of Service

RA Random Access

RAN Radio Access Network

RAR Random Access Response

RAT Radio Access Technology

RF Radio Frequency

RLC Radio Link Control

RNTI Radio Network Temporary Identifier

RRC Radio Resource Control

RS Reference Signal

RSRP Reference Signal Received Power

RSRQ Reference Signal Received Quality

SCell Secondary Cell

SCG Secondary Cell Group

SDAP Service Data Adaptation Protocol

SI System Information

SIB System Information Block

SINR Signal to Interference plus Noise Ratio

SL Sidelink

SN Secondary Node

SNPN Stand-alond Non-Public Network

SRB Signaling Radio Bearer

SSB Synchronization Signal Block

TS Technical Specification

UE User Equipment

UL Uplink

UMTS Universal Mobile Telecommunications System

USIM UMTS Subscriber Identity Module

V2X Vehicle-to-Everything

With the tremendous growth in the number of connected devices and the rapid increase in user/network traffic volume, various efforts have been made to improve different aspects of wireless communication for the next-generation wireless communication system, such as the fifth-generation (5G) New Radio (NR) , by improving data rate, latency, reliability, and mobility. The 5G NR system is designed to provide flexibility and configurability to optimize the network services and types, accommodating various use cases, such as enhanced Mobile Broadband (eMBB) , massive Machine-Type Communication (mMTC) , and Ultra-Reliable and Low-Latency Communication (URLLC) . However, as the demand for radio access continues to increase, there exists a need for further improvements in the art.

SUMMARY

The present disclosure is related to a method performed by a UE in cellular wireless communication network for MBS radio bearer configuration.

In a first aspect of the present application, a method for MBS radio bearer configuration performed by a UE is provided. The method includes receiving, from a serving cell, an MBS radio bearer configuration indicating a multicast bearer and a unicast bearer; and configuring the MBS radio bearer based on the received MBS radio bearer configuration to receive DL data via at least one of the multicast bearer and the unicast bearer. The multicast bearer and the unicast bearer are associated with a common PDCP entity. The unicast bearer is always activated in default after the UE configures the unicast bearer based on the received MBS radio bearer configuration.

In an implementation of the first aspect, the multicast bearer is activated or deactivated in the MBS radio bearer configuration.

In another implementation of the first aspect, the MBS radio bearer configuration is received via dedicated RRC signaling.

In another implementation of the first aspect, the MBS radio bearer configuration is received via broadcast system information.

In another implementation of the first aspect, the MBS radio bearer configuration is generated by a master node or a secondary node.

In another implementation of the first aspect, the UE receives the MBS radio bearer configuration from a master node via a Signaling Radio Bearer 1 (SRB1) or from a secondary node via a Signaling Radio Bearer 3 (SRB3) .

Another implementation of the first aspect further comprises receiving a switch indicator from the serving cell; and determining whether to activate or deactivate the multicast bearer according to the switch indicator.

In another implementation of the first aspect, the switch indicator is received via broadcast system information.

In another implementation of the first aspect, the switch indicator is received via at least one of UE-specific MAC CE and DCI.

Another implementation of the first aspect further comprises storing the MBS radio bearer configuration received from the serving cell; performing a handover procedure to switch from the serving cell to a target cell; identifying whether the stored MBS radio bearer configuration is valid to the target cell; applying the MBS radio bearer configuration upon determining the MBS radio bearer configuration is valid to the target cell after switching to the target cell; and activating the unicast bearer during the handover procedure.

In another implementation of the first aspect, the handover procedure is a conditional handover procedure which is initiated by the UE upon determining at least one triggering condition is fulfilled.

Another implementation of the first aspect further comprises performing a handover procedure to switch from the serving cell to a target cell; and maintaining one of the multicast bearer and the unicast bearer and releasing the other one of the multicast bearer and the unicast bearer after switching to the target cell.

Another implementation of the first aspect further comprises receiving, from the serving cell, a DAPS indicator that indicates which one of the multicast bearer and the unicast bearer is maintained after switching to the target cell.

In another implementation of the first aspect, the unicast bearer supports UE feedback mechanism to the serving cell; and the multicast bearer does not support the UE feedback mechanism to the serving cell.

In a second aspect, a UE for MBS radio bearer configuration is provided. The UE includes one or more processors and at least one memory coupled to at least one of the one or more processors, where the at least one memory stores a computer-executable program that, when executed by the at least one of the one or more processors, causes the UE to receive, from a serving cell, an MBS radio bearer configuration indicating a multicast bearer and a unicast bearer; and configure the MBS radio bearer based on the received MBS radio bearer configuration to receive DL data via at least one of the multicast bearer and the unicast bearer. The multicast bearer and the unicast bearer are associated with a common PDCP entity. The unicast bearer is always activated in default after the UE configures the unicast bearer based on the received MBS radio bearer configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying drawings. Various features are not drawn to scale. Dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

FIG. 1 illustrates a split bearer architecture according to an implementation of the present disclosure.

FIG. 2 illustrates an independent bearer architecture according to an implementation of the present disclosure.

FIG. 3 illustrates a diagram illustrating ranges associated with a base station according to an example implementation of the present disclosure.

FIG. 4 illustrates a process of (conditional) MBS-Bearer configuration according to an example implementation of the present disclosure.

FIG. 5 illustrates a method performed by a UE for MBS radio bearer configuration according to an example implementation of the present disclosure.

FIG. 6 illustrates a method for switching the MBS bearer according to an example implementation of the present disclosure.

FIG. 7 illustrates a method performed by the UE for handling the MBS radio bearer configuration according to an example implementation of the present disclosure.

FIG. 8 illustrates a method performed by the UE for handling the MBS radio bearer configuration according to another example implementation of the present disclosure.

FIG. 9 is a block diagram illustrating a node for wireless communication according to an implementation of the present disclosure.

DESCRIPTION

The following description contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed description are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art.

Unless noted otherwise, like or corresponding elements among the drawings may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present disclosure are generally not to scale and are not intended to correspond to actual relative dimensions.

For the purpose of consistency and ease of understanding, like features may be identified (although, in some examples, not illustrated) by the same numerals in the drawings. However, the features in different implementations may be differed in other respects and shall not be narrowly confined to what is illustrated in the drawings.

The phrases “in one implementation, ” or “in some implementations, ” may each refer to one or more of the same or different implementations. The term “coupled” is defined as connected whether directly or indirectly through intervening components and is not necessarily limited to physical connections. The term “comprising” means “including, but not necessarily limited to” and specifically indicates open-ended inclusion or membership in the so-described combination, group, series or equivalent. The expression “at least one of A, B and C” or “at least one of the following: A, B and C” means “only A, or only B, or only C, or any combination of A, B and C. ”

The terms “system” and “network” may be used interchangeably. The term “and/or” is only an association relationship for describing associated objects and represents that three relationships may exist such that A and/or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character “/” generally represents that the associated objects are in an “or” relationship.

For the purposes of explanation and non-limitation, specific details such as functional entities, techniques, protocols, and standards are set forth for providing an understanding of the disclosed technology. In other examples, detailed description of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the description with unnecessary details.

Persons skilled in the art will immediately recognize that any network function (s) or algorithm (s) disclosed may be implemented by hardware, software or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof.

A software implementation may include computer executable instructions stored on a computer readable medium such as memory or other type of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function (s) or algorithm (s) .

The microprocessors or general-purpose computers may include Applications Specific Integrated Circuitry (ASIC) , programmable logic arrays, and/or using one or more Digital Signal Processor (DSPs) . Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware or as hardware or combination of hardware and software are well within the scope of the present disclosure. The computer readable medium includes but is not limited to Random Access Memory (RAM) , Read Only Memory (ROM) , Erasable Programmable Read-Only Memory (EPROM) , Electrically Erasable Programmable Read-Only Memory (EEPROM) , flash memory, Compact Disc Read-Only Memory (CD-ROM) , magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

A radio communication network architecture such as a Long Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, an LTE-Advanced Pro system, or a 5G NR Radio Access Network (RAN) typically includes at least one BS, at least one UE, and one or more optional network elements that provide connection within a network. The UE communicates with the network such as a Core Network (CN) , an Evolved Packet Core (EPC) network, an Evolved Universal Terrestrial RAN (E-UTRA) , a 5G Core (5GC) , or an internet via a RAN established by one or more BSs.

A UE may include but is not limited to a mobile station, a mobile terminal or device, or a user communication radio terminal. The UE may be portable radio equipment that includes but is not limited to a mobile phone, a tablet, a wearable device, a sensor, a vehicle, or a Personal Digital Assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a RAN.

A BS may be configured to provide communication services according to at least a Radio Access Technology (RAT) such as Worldwide Interoperability for Microwave Access (WiMAX) , Global System for Mobile communications (GSM) that is often referred to as 2G, GSM Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN) , General Packet Radio Service (GPRS) , Universal Mobile Telecommunication System (UMTS) that is often referred to as 3G based on basic wideband-code division multiple access (W-CDMA) , high-speed packet access (HSPA) , LTE, LTE-A, evolved LTE (eLTE) that is LTE connected to 5GC, NR (often referred to as 5G) , and/or LTE-A Pro. However, the scope of the present disclosure is not limited to these protocols.

A BS may include but is not limited to a node B (NB) in the UMTS, an evolved node B (eNB) in LTE or LTE-A, a radio network controller (RNC) in UMTS, a BS controller (BSC) in the GSM/GERAN, a ng-eNB in an E-UTRA BS in connection with 5GC, a next generation Node B (gNB) in the 5G-RAN, or any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may serve one or more UEs via one or more radio interface.

The BS is operable to provide radio coverage to a specific geographical area using a plurality of cells forming the RAN. The BS supports the operations of the cells. Each cell is operable to provide services to at least one UE within its radio coverage.

Each cell (often referred to as a serving cell) provides services to serve one or more UEs within its radio coverage such that each cell schedules the downlink (DL) and optionally uplink (UL) resources to at least one UE within its radio coverage for DL and optionally UL packet transmissions. The BS can communicate with one or more UEs in the radio communication system via the plurality of cells.

A cell may allocate sidelink (SL) resources for supporting Proximity Service (ProSe) (e.g., (ProSe) direct communication services and (ProSe) direct discovery services) or V2X services (e.g., E-UTRA V2X sidelink communication services) or sidelink service (e.g., NR sidelink communication services) . Each cell may have overlapped coverage areas with other cells.

As discussed previously, the frame structure for NR supports flexible configurations for accommodating various next generation (e.g., 5G) communication requirements such as Enhanced Mobile Broadband (eMBB) , Massive Machine Type Communication (mMTC) , and Ultra-Reliable and Low-Latency Communication (URLLC) , while fulfilling high reliability, high data rate and low latency requirements. The Orthogonal Frequency-Division Multiplexing (OFDM) technology in the 3rd Generation Partnership Project (3GPP) may serve as a baseline for an NR waveform. The scalable OFDM numerology such as adaptive sub-carrier spacing, channel bandwidth, and Cyclic Prefix (CP) may also be used.

Two coding schemes are considered for NR, specifically Low-Density Parity-Check (LDPC) code and Polar Code. The coding scheme adaption may be configured based on channel conditions and/or service applications.

At least DL transmission data, a guard period, and UL transmission data should be included in a transmission time interval (TTI) of a single NR frame. The respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable based on, for example, the network dynamics of NR. Sidelink resources may also be provided in an NR frame to support ProSe services, V2X services (e.g., E-UTRA V2X sidelink communication services) or sidelink services (e.g., NR sidelink communication services) . In contrast, sidelink resources may also be provided in an E-UTRA frame to support ProSe services, V2X services (e.g., E-UTRA V2X sidelink communication services) or sidelink services (e.g., NR sidelink communication services) .

Implementations regarding how a Radio Access Network (RAN) configures radio bearer configurations to support Multicast Broadcast Service (MBS) are disclosed in the present disclosure. For dynamic and adaptive Quality of Service (QoS) management to support MBS on varying channel qualities, the RAN may configure different radio bearer configurations (e.g., Multicast radio bearer (M-Bearer) or Unicast radio bearer (U-Bearer) , which includes different configurations in Access Stratum (AS) Layers respectively) to a UE. The UE may receive the packets of one or more target MBS (s) via the configured U-Bearer (s) and/or M-Bearer (s) . Moreover, to one or more target MBS (s) , the UE may switch the radio bearer configurations of MBS packet receptions in different conditions. Implementations of RAN and UE for MBS radio bearer configurations and switches (e.g., from U-bearer to M-Bearer or from M-Bearer to U-Bearer) are disclosed in the present disclosure.

Examples of some selected terms are provided as follows.

Network (NW) , Radio Access Network (RAN) , cell, camped cell, serving cell, base station, gNB, eNB and ng-eNB may be used interchangeably in the present disclosure. In some implementations, some of these terms may refer to the same network entity.

Serving Cell: For a UE in RRC_CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell. For a UE in RRC_CONNECTED configured with CA/DC the term ‘serving cells’ is used to denote the set of cells comprising of the Special Cell (s) and all secondary cells.

Special Cell: For Dual Connectivity operation the term Special Cell refers to the PCell of the MCG or the PSCell of the SCG, otherwise the term Special Cell refers to the PCell.

The disclosed implementations may be applied to any RAT. The RAT may be (but not limited to) NR, NR-U, LTE, E-UTRA connected to 5GC, LTE connected to 5GC, E-UTRA connected to EPC, and LTE connected to EPC. The disclosed implementations may be applied to UEs in public networks, or in private network (e.g., NPN such as SNPN and PNI-NPN) .

The disclosed implementations may be used for licensed frequency and/or unlicensed frequency.

System information (SI) may refer to MIB, SIB1, and other SI. Minimum SI may include MIB and SIB1. Other SI may refer to SIB3, SIB4, SIB5, and other SIB (s) (e.g., SNPN-specific SIB, PNI-NPN-specific SIB) .

Dedicated signaling may refer to (but not limited to) RRC message (s) . For example, RRC (Connection) Setup Request message, RRC (Connection) Setup message, RRC (Connection) Setup Complete message, RRC (Connection) Reconfiguration message, RRC Connection Reconfiguration message including the mobility control information, RRC Connection Reconfiguration message without the mobility control information inside, RRC Reconfiguration message including the configuration with sync, RRC Reconfiguration message without the configuration with sync inside, RRC (Connection) Reconfiguration complete message, RRC (Connection) Resume Request message, RRC (Connection) Resume message, RRC (Connection) Resume Complete message, RRC (Connection) Reestablishment Request message, RRC (Connection) Reestablishment message, RRC (Connection) Reestablishment Complete message, RRC (Connection) Reject message, RRC (Connection) Release message, RRC System Information Request message, UE Assistance Information message, UE Capability Enquiry message, and UE Capability Information message. RRC message may be one type of dedicated signaling. The UE may receive the RRC message from the network via unicast/broadcast/groupcast.

The RRC_CONNECTED UE, RRC_INACTIVE UE, and RRC_IDLE UE may apply the disclosed implementations.

An RRC_CONNECTED UE may be configured with an active BWP with common search space configured to monitor system information or paging.

The disclosed implementations may be applied to the PCell and the UE. In some implementations, the disclosed implementations may be applied to the PSCell and the UE. The disclosed short message and/or paging DCI may be transmitted by the PSCell (or secondary node) to the UE. The UE may monitor the PDCCH monitoring occasions for paging configured by the PSCell (or secondary node) .

Allowed CAG list: a per-PLMN list of CAG Identifiers the UE is allowed to access.

CAG cell: A cell broadcasting at least one CAG Identifier.

CAG Member Cell: for a UE, a cell broadcasting the identity of the selected PLMN, registered PLMN or equivalent PLMN, and for that PLMN, a CAG identifier belonging to the Allowed CAG list of the UE for that PLMN.

CAG Identifier: CAG Identifier identifies a CAG within a PLMN.

Network Identifier: Network Identifier identifies an SNPN in combination with a PLMN ID.

Non-Public Network: A network deployed for non-public use.

NPN-only Cell: A cell that is only available for normal service for NPNs’s ubscriber. An NPN-capable UE determines that a cell is NPN-only Cell by detecting that the cellReservedForOtherUse IE is set to true while the npn-IdentityInfoList IE is present in CellAccessRelatedInfo IE.

PNI-NPN identity: an identifier of a PNI-NPN comprising of a PLMN ID and a CAG -ID combination.

Registered SNPN: This is the SNPN on which certain Location Registration outcomes have occurred.

Selected SNPN: This is the SNPN that has been selected by the NAS (e.g., the NAS of the UE, the NAS of the CN) , either manually or automatically.

SNPN Access Mode: mode of operation in which the UE only selects SNPNs.

SNPN identity: an identifier of an SNPN comprising of a PLMN ID and an NID combination.

SNPN-only cell: a cell that is only available for normal service for SNPN subscribers.

An NPN-capable UE may correspond to a UE supporting CAG (or NPN) .

Child node: IAB-node-DU’s next hop neighbour node; the child node is also an IAB-node.

Parent node: IAB-node-MT’s next hop neighbour node; the parent node can be IAB-node or IAB-donor-DU.

Downstream: Direction toward child node or UE in IAB-topology.

Upstream: Direction toward parent node in IAB-topology.

IAB-donor: gNB that provides network access to UEs via a network of backhaul and access links.

IAB-DU: gNB-DU functionality supported by the IAB-node to terminate the NR access interface to UEs and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in 3GPP TS 38.401, on the IAB-donor.

IAB-MT: IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviours specified for UEs unless stated otherwise. IAB-MT function used in 38series of 3GPP Specifications corresponds to IAB-UE function defined in 3GPP TS 23.501.

IAB-node: RAN node that supports NR access links to UEs and NR backhaul links to parent nodes and child nodes. The IAB-node may or may not support backhauling via LTE.

Multi-hop backhauling: Using a chain of NR (and/or LTE) backhaul links between an IAB-node and an IAB-donor-gNB.

NR backhaul link: NR link used for backhauling between an IAB-node and an IAB-donor-gNB, and between IAB-nodes in case of a multi-hop backhauling.

LTE backhaul link: LTE link used for backhauling between an IAB-node and an IAB-donor-gNB, and between IAB-nodes in case of a multi-hop backhauling.

Multi-Radio Dual Connectivity (MR-DC) : Dual Connectivity between E-UTRA and NR nodes, or between two NR nodes. MR-DC may include E-UTRA-NR Dual Connectivity (EN-DC) , NR-E-UTRA Dual Connectivity (NE-DC) , NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC) , and NR-NR Dual Connectivity (NR-DC) .

Master Cell Group: in MR-DC, a group of serving cells associated with the Master Node, comprising of the SpCell (PCell) and optionally one or more SCells.

Master node: in MR-DC, the radio access node that provides the control plane connection to the core network. It may be a Master eNB (in EN-DC) , a Master ng-eNB (in NGEN-DC) or a Master gNB (in NR-DC and NE-DC) .

Secondary Cell Group: in MR-DC, a group of serving cells associated with the Secondary Node, comprising of the SpCell (PSCell) and optionally one or more SCells.

Secondary node: in MR-DC, the radio access node, with no control plane connection to the core network, providing additional resources to the UE. It may be an en-gNB (in EN-DC) , a Secondary ng-eNB (in NE-DC) or a Secondary gNB (in NR-DC and NGEN-DC) .

MeNB: Master eNB, an eNB as a master node associated with an MCG (Master Cell Group) in MR-DC scenarios.

SgNB: Secondary gNB, a gNB as a secondary node associated with an SCG (Secondary Cell Group) in MR-DC scenarios.

A first indication may be associated with NR, LTE connected to EPC, and/or LTE connected to 5GC. A second indication may be associated with NR, LTE connected to EPC, and/or LTE connected to 5GC. The first indication and the second indication may be associated with the same RAT (e.g., NR, LTE connected to EPC, LTE connected to 5GC) or different RATs. The UE supporting one RAT (e.g., IAB functionality via NR and/or NPN functionality via NR, if the one RAT is NR) may apply the first indication associated with NR and/or the second indication associated with NR. The UE supporting the one RAT may apply (or ignore) the first indication not associated with NR and/or the second indication not associated with NR.

In some implementations, if the UE considers itself barred by a cell or if the UE bars a cell, the UE may bar the cell for a period of time (e.g., 300s) . The UE may not consider the cell as a candidate cell for cell (re) selectin for a period of time (e.g., 300s) .

In some implementations, if the UE changes from the SNPN access mode to the PLMN access mode, (the NAS entity of) the UE may release (or delete or discard) the (stored or maintained) list of SNPN ID (s) if any.

In some implementations, if the UE changes from the PLMN access mode to the SNPN access mode, (the NAS entity of) the UE may release (or delete or discard) the (stored or maintained) list of PLMN ID (s) if any.

Downlink Control Information (DCI) : DCI may refer to a PDCCH resource with Cyclic Redundancy Check (CRC) scrambled by an Radio Network Temporary Identifier (RNTI) . The RNTI may relate to IAB. Implementations regarding DCI may be applied for a physical signal.

Medium Access Control (MAC) Control Element (CE) : A MAC CE is a bit string that is byte aligned (e.g., multiple of 8 bits) in length.

In some implementations, if the UE with IAB functionality determines itself to be an IAB node or operate as an IAB node, and/or if the UE performs the design for IAB, and/or if the UE operates the IAB functions, the UE may transmit an indication to inform the network via dedicated signaling.

DAPS bearer: a bearer whose radio protocols are located in both the source gNB and the target gNB during DAPS handover to use both source gNB and target gNB resources.

Radio Bearer Configurations to support MBS (MBS-Bearer)

In the NR Multicast Broadcast Service (MBS) , one UE may be configured with one (or more) multicast bearer (which is called M-Bearer in the present disclosure) and/or one (or more) unicast bearer (which is called U-Bearer in the present disclosure) to receive the packets of target service from the serving cell (s) in the DL direction. In addition, the M-Bearer and the U-Bearer may be configured with different features in Layer 2/Layer 1. Implementations of the MBS radio bearer configurations and U-Bearer configuration are provided below.

In some implementations, the UE may be configured with M-Bearer configuration and U-Bearer configuration to support MBS packet reception under different conditions. For example, M-Bearer is configured as one-directional (DL direction) multicast radio bearer configuration to the UE and no additional UE feedback mechanism to the serving cell (s) . In contrast, the U-Bearer may be configured as bi-directional radio bearer configuration, which supports the UE to transmit feedback information to the serving cell (s) and so the serving cell can adjust the Layer1/Layer2 radio resources to enhance the QoS of target MBS (s) at the UE side. In the present disclosure, the feedback information transmitted by the UE may include the application-level feedback information, Layer-2 feedback information (e.g., PDCP status report (by PDCP control PDU transmission) , RLC Automatic Repeat reQuest (ARQ) ACK/NACK report, RLC status report, MAC buffer status report) , and Layer-1 feedback information (e.g., Hybrid Automatic Repeat reQuest ACK/NACK report) . In some implementations, the UE may deliver the uplink packet transmissions through the bi-directional radio bearer configuration. It should be noted that the difference between the M-Bearer and the U-Bearer may not be limited by the feedback information reporting mechanisms.

In some implementations, the M-Bearer configuration may be common to all of the UEs. For example, the M-Bearer configuration may be common to UEs of one serving cell (cell-specific) . In some implementations, the M-Bearer configuration may be common to UEs of one serving PLMN (NW-specific) . In some implementations, the M-Bearer configuration may be common to UEs that want to receive the target MBS (service-specific) .

In some implementations, the UE may be configured with multiple MBS-Radio Bearer configurations, where each of the MBS-Radio Bearer configurations may be associated with one index (e.g., MBS-ConfigIndex) .

In some implementations, the MBS-Bearer configuration (M-Bearer/U-Bearer configuration) may be associated with one MBS-service ID, which may be predefined by the service provider or the network operator. In some implementations, the UE may receive the MBS-Bearer configuration via dedicated RRC signaling.

Table 1 illustrates an example M-bearer configuration.

Table 1

Table 2 illustrates an example U-bearer configuration.

Table 2

MRB-ConfigIndex: This field indicates the index of MBS-Bearer configuration.

To support one target MBS, the serving RAN (e.g., based on the service provider’s (or the network operator’s ) requests/assistance information or the content of the corresponding service) or the service provider may configure one or more MBS-Bearers, where each MBS-Bearer may be associated with one MBS-Bearer Identifier (e.g., MBS-ID) . In some implementations, the MBS-Bearer configuration may be delivered to the UE through an application level packet if the MBS-Bearer configuration is provided by the (MBS) service provider. In some implementations, the MBS-Bearer configuration may be delivered to the UE through a Non-Access Stratum (NAS) signaling if the MBS-Bearer configuration is provided by the network operator.

In addition, the serving RAN may also provide one or more MBS-Bearer configurations, where each MBS-Bearer configuration may be associated with one MRB-ConfigIndex. Each MBS-Bearer may be associated with one MRB-ConfigIndex for the AS layer configuration for one MBS-Bearer.

In some implementations, the M-Bearer configuration and the U-Bearer configuration may be designated with two (and the only two) MBS-Bearer configuration and so the serving cell may indicate one target MBS (e.g., one target MBS may be associated with one MBS application ID) to be associated with {M-Bearer, U-Bearer} to realize MBS-Bearer switch instruction (in this condition, the MRB-ConfigIndex allocation may not be configured) .

In some implementations (e.g., there may be more than one M-Bearer and/or more than one U-Bearer configuration provided by the serving RAN) , MRB-Configindex may be configured (e.g., along with the MBS-MRBConfig or MBS-URBConfig) to be associated with each MBS-Bearer configuration. In the MBS-Bearer switch procedure, the UE may receive the instruction to change the associated MRB-Configindex of one MBS-Bearer (e.g., from MRB-Configindex#1 to MRB-Configindex#2) . After receiving the instruction to change the MRB-Configindex of one MBR-Bearer, the UE may reconfigure the AS layer configuration of the concerned MRB-Bearer by using the AS layer configuration associated with the new MRB-Configindex (e.g., the AS layer configuration associated with the MRB-Configindex) .

MRB-SDAP-Config: This field indicates the Service Data Adaptation Protocol (SDAP) parameters for the associated MBS-Bearer, which may include any combination of:

- PDU Session ID associated with the MBS.

- In some implementations, one Boolean value “default radio bearer= {true} ” may be configured in the MRB-SDAP-Config to indicate that the associated MBS-Bearer is the default radio bearer for this target MBS. Otherwise (e.g., if default radio bearer= {false} or absent) , the associated MBS-Bearer may not be the default radio bearer for this target MBS. In some implementations, there may be only one SDAP entity configured for the MBS-Bearer and both of the M-Bearer and the U-Bearer may share the same SDAP entity. In some implementations, the M-Bearer may be configured with one SDAP entity and the U-Bearer may be configured with another SDAP entity independently.

- Other configurations (e.g., the sdap-HeaderDL= {present, absent} or mappedQoS-FlowsToAdd/mappedQoS-FlowsToRelease list) may also be provided in the MRB-SDAP-Config.

In some implementations, the MBS-Bearer configuration (e.g., M-Bearer or U-Bearer) may be provided without MRB-SDAP-Config or MRB-SDAP-Config may be an optional configuration in the MRB-Bearer configuration. In some implementations, the MRB-SDAP-Config may be an empty entity or may not be present in the MBS-Bearer configuration.

MRB-PDCP-Config: This field indicates the PDCP parameters for the associated MBS-Bearer, which may include any combination of:

- In some implementations, the Robust Header Compression (ROHC) configuration of the associated MBS-Bearer is provided in the MRB-PDCP-Config. Table 3 illustrates an example ROHC configuration.

Table 3

- In some implementations, there is no header compression configuration in the MRB-PDCP-Config since the compression is achieved by the upper layers (e.g., the application layer) . In this case, the “headerCompression = notUsed” in the MRB-PDCP-Config.

- In some implementations, MRB-ContinueROHC (e.g., MRB-ContinueROHC = ENUMERATED {true} ) may also be configured in the MRB-PDCP-Config. The MRB-ContinueROHC indicates whether the PDCP entity continues or resets the ROHC header compression protocol during PDCP reestablishment (e.g., when the MBS-Bearer switch between the M-Bearer and the U-Bearer occurs for the target MBS) .

- In some implementations, Ethernet header compression configured for the MBS may be implemented in the PDCP layer and one IE “ethernetHeaderCompression= {true} ” may be configured in the MBS-Bearer. In some implementations, ethernetHeaderCompression= {notUsed} may be configured in the MBS-Bearer configuration if Ethernet header compression is not used in the associated MBS-Bearer. In some implementations, the Ethernet header compression may also indicate whether the PDCP entity continues (e.g., by configuring MRB-ContinueEHC-DL = ENUMERATED {true} ) or resets the ethernet header compression protocol during PDCP reestablishment (e.g., when the MBS-Bearer switch between the M-Bearer and the U-Bearer occurs for the target MBS) .

- In some implementations, the pdcp sequence length (e.g., pdcp-SN-SizeDL = ENUMERATED {len12bits, len18bits} ) may be configured in the MRB-PDCP-Config.

- In some implementations, the discardTimer (e.g., discardTimer=ENUMERATED {ms10, ms20, ms30, ms40, ms50, ms60, ms75, ms100, ms150, ms200, ms250, ms300, ms500, ms750, ms1500, infinity} ) may be configured in the MRB-PDCP-Config.

- The integrity protection configuration (e.g., integrityProtection ={enabled} may be optionally configured in the MRB-PDCP-Config. In addition, the ciphering procedure may be disabled in the associated MBS-Bearer (e.g., by configuring cipheringDisabled= {true} in the PDCP configuration) .

- In some implementations, the serving cell may instruct the UE to provide PDCP status report to the serving cell. Therefore, one IE statusReportRequired = {true} may be configured in the MRB-PDCP-Config while the associated MBS-Bearer is configured as AM mode. The UE may provide the PDCP status report to the serving cell if the IE statusReportRequired is configured as ‘true’ .

- In some implementations, the serving cell may configure outOfOrderDelivery = true in the MRB-PDCP-Config. However, the serving cell may configure the IE as true only if the UE supports out of order delivery in downlink packet reception. The UE may report whether the UE supports out of order reception for the MBS packet reception in the UE capability report. In some implementations, there may be only one PDCP entity configured for the MBS-Bearer and both of the M-Bearer and the U-Bearer may share the same PDCP entity. In some implementations, the M-Bearer may be configured with one PDCP entity and the U-Bearer may be configured with another PDCP entity independently.

- In some implementations, the MBS-Bearer may be configured with one RLC bearer in the MRB-PDCP-Config. In addition, one IE ‘primaryPath’ may be configured to be mapped to one associated cellgroup (e.g., cellGroup=MCG or SCG while UE is configured with EN-DC, NE-DC, NGEN-DC, or MR-DC configuration) or the mapped logical Channel (e.g., the logical channel identity associated with the MBS-Bearer in the MAC layer) may also be configured (e.g., within the MRB-PDCP-Config or in the RLC Bearer configuration associated with the MBS-Bearer) .

- In some implementations, t-Reordering may be configured in the PDCP configuration, such as: t-Reordering ENUMERATED {ms0, ms1, ms2, ms4, ms5, ms8, ms10, ms15, ms20, ms30, ms40, etc} .

In some implementations, one MBS-Bearer configuration (e.g., M-Bearer or U-Bearer) may be provided without MRB-PDCP-Config. MRB-PDCP-Config may be an optional configuration in the MBS-Bearer configuration. In some implementations, the MRB-PDCP-Config may be an empty entity or may not be present in the MBS-Bearer configuration.

MRB-RLCBearer-Config: In some implementations, the RLC-Bearer associated with the MBS-Bearer may be configured in the MRB-RLCBearer-Config. The following information elements may be provided in the MRB-RLCBearer-Config:

- Logical Channel Identity (LCID) : the LCID of the MBS-Bearer may be configured by the LCID. In some implementations, One LCID may also be configured to be associated with one logical channel configuration.

- In some implementations, the following uplink specific parameters, such as the priority level (e.g., INTEGER (1.. 16) ) , prioritisedBitRate (e.g., ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512, etc} ) , bucketSizeDuration (e.g., ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000, etc} ) , allowedServingCells (e.g., SEQUENCE (SIZE (1.. maxNrofServingCells-1) ) OF ServCellIndex) , allowedSCS-List (e.g., SEQUENCE (SIZE (1.. maxSCSs) ) OF SubcarrierSpacing) , maxPUSCH-Duration (e.g., ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, etc} ) , configuredGrantType1Allowed (e.g., ENUMERATED {true} ) , logicalChannelGroup (e.g., INTEGER (0.. maxLCG-ID) ) , schedulingRequestID, logicalChannelSR-Mask, logicalChannelSR-DelayTimerApplied, bitRateQueryProhibitTimer (e.g., ENUMERATED {s0, s0dot4, s0dot8, s1dot6, s3, s6, s12, s30} ) , allowedCG-List (allowed configured grant list) , and allowedPHY-PriorityIndex-r16n (e.g., ENUMERATED {p0, p1} ) may be configured to be associated with one MBS-Bearer configuration (e.g., MRB-MAC-Config) . In some implementations, the uplink parameters may be provided for the UE to provide uplink feedback information to the serving cell. In some implementations, the U-Bearer configuration may be provided with associated uplink parameters. The M-Bearer configuration may be provided without associated uplink parameters since the NW may not instruct the UE to provide feedback information while the UE is receiving the target MBS packets via the M-Bearer. In some implementations, there may be only one MAC entity configured for the MBS-Bearer and both of the M-Bearer and the U-Bearer may share the same MAC entity. In some implementations, different MAC functions may be configured to the M-Bearer and U-Bearer respectively. The MAC function of the M-Bearer and the MAC function of the U-Bearer may operate independently even if both of the MAC functions (for the M-Bearer and for the U-Bearer) operate in the same MAC entity. In some implementations, the M-Bearer may be configured with one MAC entity and the U-Bearer may be configured with another MAC entity independently. In some implementations, one MBS RLC Bearer (configured for the M-Bearer or for the U-Bearer) may be associated with one unique logical channel, which is configured via MRB-MAC-Config, in the MAC layer.

- ServedRadioBearer: The served radio bearer of the RLC bearer may be MBS-Bearer. One MBS-Bearer Identifier (or MBS-ID) may be configured in this field for MBS packet reception. In some implementations, one MBS-Bearer may be configured to be associated with one target MBS.

- RLC-configuration (please refer to MRB-RLC-Config) . In some implementations, the IE ‘reestablishRLC= ENUMERATED {true} ’ may also be included to indicate that RLC (e.g., RLC sublayer or RLC entity) should be reestablished. Network sets the IE to true at least whenever the security key used for the radio bearer associated with this RLC entity changes. In some conditions, the IE is also set to true during the resumption of the RRC connection (e.g., for UEs in RRC inactive state) or the first reconfiguration after (RRC) reestablishment (e.g., for UEs in RRC connected state) .

MRB-RLC-Config: This field indicates the RLC parameters for the MBS-Bearer

- In some implementations, the MRB-RLC-Config may include the RLC mode for the associated MBS-Bearer. For example, the MBS-Bearer may be configured as {Acknowledge Mode (AM) , Un-acknowledge Mode (UM) , Transparent Mode (TM) } . In addition, the AM/UM/TM configuration represent different configurations for ARQ protocols in the RLC entity (or RLC layer) of each RLC Bearer.

- For the MBS-Bearer of AM, Table 4 illustrates an example configuration that may be provided in the RLC-configuration.

Table 4

The IE “sn-FieldLength” indicates the RLC sequence number (SN) field size in bits.

The IE “t-Reassembly” indicates the timer for re-assembly.

The IE “t-StatusProhibit” indicates the timer for status reporting. The UE may be prohibited to transmit RLC status report while the prohibit timer is running. In some implementations, the timer may be reset and started when one RLC status report is sent from the UE side.

- For the MBS-Bearer of UM, Table 5 illustrates an example configuration that may be provided in the RLC-configuration.

Table 5

MRB-ReceptionRange: This field indicates the valid range of the associated MBS-Bearer.

Default MBS-Bearer configuration

Based on the MBS-Bearer configurations disclosed previously, the UE may need to switch the operating MBS-Bearer while more MBS-Bearer configurations are configured to the UE. In some implementations, one of the configured MBS-Bearer configurations may be considered as ‘default MBS-Bearer’ at the UE side.

In some implementations, the UE may be configured with at least one (e.g., one or two) default MBS-Bearer to receive one target MBS. The default MBS-Bearer may be configured in explicit signaling. In some implementations, a common ‘default MBS-Bearer’ may be configured to the UE (e.g., via broadcast system information) and the UE may apply the common ‘default MBS-Bearer’ to all of the active MBS (s) operating at the UE side (e.g., when one MBS is triggered by the upper layers at the UE side) ) .

In some implementations, the default MBS-Bearer may be directed to one radio bearer ID (e.g., RB-ID) provided by the UE in the downlink control signaling (e.g., DL RRC signaling or system information) and the range of RB-ID may be shared with other radio bearers (e.g., DRB/SRB) . In some implementations, a specific MRB-ID may be defined independently with the RB-ID and the MRB-ID may be applied to identify different MBS-Bearers.

In some implementations, the default MBS-Bearer may be directed to the type of radio bearer (e.g., default radio bearer = {M-Bearer, U-Bearer} ) in the downlink control signaling.

In some implementations, the default MBS-Bearer may be configured in at least one of the SDAP-layer configuration, the MRB-PDCP-Config, the MRB-RLC-Config, and the MRB-RLC-Bearer Config.

In some implementations, the default MBS-Bearer in different conditions may be configured to the UE in the downlink control signaling. Different conditions may correspond to different ranges (e.g., range-based MBS-Bearer configuration) .

FIG. 1 illustrates a split bearer architecture 100 according to an implementation of the present disclosure. The hierarchical structure illustrated in FIG. 1 includes the application layer 110, SDAP 120, PDCP 130, RLC 140 and RLC 142 associated with the PDCP 130, MAC 150 associated with the RLC 140, MAC 152 associated with the RLC 142, PHY 160 associated with the MAC 150, and PHY 162 associated with the MAC 152. Two split bearers are associated to the common PDCP 130. The two split bearers may also be referred as two legs in the present disclosure. The leg configured as the M-bearer may be referred as a point-to-multipoint (PTM) leg in the present disclosure. The leg configured as the U-bearer may be referred as a point-to-point (PTP) leg in the present disclosure. The leg including the RLC 140, the MAC 150, the PHY 160 may be configured with MRB-ID #1 (which may be an M-bearer or a U-Bearer) . The leg including the RLC 142, the MAC 152, the PHY 162 may be configured with MRB-ID #2 (which may be an M-bearer or a U-Bearer) . The UE may receive DL data via at least one of the two split bearers (legs) . For example, each bearer may be activated or deactivated and the UE may receive DL data via an activated (split) bearer. In some implementations, one of the two split bearers may be predefined/configured as the default MBS-Bearer. The default MBS-Bearer is activated by default. In some implementations, the U-Bearer (which is also the PTP leg in the MBS bearer) is predefined as the default MBS-Bearer for DL MBS packets reception. The PTP leg may be always activated in default. In some implementations, the bearer other than the default MBS-Bearer may be activated or deactivated by the UE. In some implementations, the PTM leg (e.g., the M-Bearer) may be activated or deactivated by the UE (e.g., based on DL control signaling) .

For example, the bearer with MRB-ID #1 may be the M-Bearer and the bearer with MRB-ID #2 may be the U-Bearer. The U-Bearer may be always activated in default and the M-Bearer may be activated or deactivated by the UE. In some implementations, the M-Bearer may be indicated as activated or deactivated in the MBS-Bearer configuration. In contrast, in the MBS Bearer configuration, the U-Bearer may not be associated with any indicator to activate/deactivate the U-Bearer. In some implementations, the PHY sublayers (or PHY functions) associated with the (split) bearer (e.g., the M-Bearer or the U-Bearer) may also be activated/deactivated with the activation/deactivation of the M-Bearer/U-Bearer. In some implementations, the PHY function associated with the M-Bearer (e.g., PHY 160) may be configured with one MBS-specific RNTI (such as MBS-RNTI) . In contrast, the PHY function associated with the U-Bearer (e.g., PHY 162) may be configured with another RNTI (such as C-RNTI) which is different from the MBS-RNTI. Based on the configured RNTIs in PHY 160 and PHY 162 respectively, in some implementations, the PHY function of the U-Bearer (e.g., the PHY 162) may always monitor/decode the PDCCHs configured in the DL radio subframes for possible MBS packet receptions. In contrast, the PHY function of the M-Bearer (e.g., the PHY 160) may or may not monitor/decode the PDCCHs configured in the DL radio subframes for possible MBS packet receptions based on the given MBS-RNTI depending on whether the M-Bearer is activated or deactivated. In some cases, the PHY 160 may monitor/decode the PDCCHs with the MBS-RNTI only when the M-Bearer is activated and the PHY 160 may not monitor/decode the PDCCHs with the MBS-RNTI when the M-Bearer is deactivated.

In some implementations, the MBS-Bearer (e.g., M-Bearer/U-Bearer and the default MBS-Bearer) may be configured as one RLC-Bearer in the PDCP configuration of the MBS-Bearer for the target MBS. In other words, one SDAP configuration (referring to SDAP 120 in FIG. 1) and one PDCP configuration (referring to PDCP 130 in FIG. 1) may be configured for the MBS-Bearer and two split RLC bearers (referring to RLC 140 and RLC 142 in FIG. 1) may be configured to the UE to receive the target MBS. In some implementations, one IE (e.g., “primary path” or “default Bearer” ) may be included in the PDCP configuration of the MBS-Bearer. In some implementations, the UE may switch the path between U-Bearer/M-Bearer based on the instructions in the downlink control signaling (e.g., via UE-specific DL RRC signaling, system information, DCI received from common search space, DCI received from UE-specific search space, or a MAC CE) from the serving cell. In some implementations, the IE (e.g., “primary path” or “default Bearer” ) may be configured in the PDCP configuration of the MBS-Bearer. In some implementations, the UE may switch the activation status of the M-Bearer (e.g., activated or deactivated) based on the instructions in the downlink control signaling (e.g., via UE-specific DL RRC signaling, broadcast system information, DCI received from common search space, DCI received from UE-specific search space, or a MAC CE) from the serving cell.

In the Dual-Connectivity scenario (e.g., EN-DC, NE-DC, NG-ENDC, MR-DC scenario) , in some implementations, the UE may receive the UE-specific DL RRC signaling (for the reception of switch indication) from the master node (e.g., MeNB/MgNB) via Signaling Radio Bearer 1 (SRB1) or Signaling Radio Bearer 2 (SRB2) . In some implementations, the UE may receive the UE-specific DL RRC signaling (for the reception of switch indication) from the secondary node (e.g., SeNB/SgNB) via Signaling Radio Bearer 3 (SRB3) . In some implementations, the UE may receive the DCI or MAC CE (for switch indication) from the Master Node (MN) or the Secondary Node (SN) . In some implementations, the UE may receive the DL RRC signaling/MAC CE/DCI (for the reception of switch indication) only from the Network Node (e.g., MN or SN) which maintains the AS layer connection (e.g., the MBS session configured by the CN and the upper layers in the UE side) between the UE and the target MBS server (which may be deployed in the CN) supported by the MBS Bearer.

FIG. 2 illustrates an independent bearer architecture 200 according to an implementation of the present disclosure. The hierarchical structure illustrated in FIG. 2 includes the application layer 210, a first independent bearer configured with MRB-ID #1, and a second independent bearer configured with MRB-ID #2. The first independent bearer is associated with SDAP 220, PDCP 230, RLC 240, MAC 250, and PHY 260. The second independent bearer is associated with SDAP 222, PDCP 232, RLC 242, MAC 252, and PHY 262.

In some implementations, the M-Bearer and the U-Bearer may be configured as independent radio bearers, as illustrated in FIG. 2, in the downlink control signaling (e.g., in the DL RRC signaling or system information) . For example, the bearer with MRB-ID #1 may be the M-Bearer and the bearer with MRB-ID #2 may be the U-Bearer.

Each of the M-Bearer and U-Bearer may be configured with independent Layer 2 (e.g., SDAP/PDCP/RLC/MAC configurations) and/or Layer 1 (e.g., PHY layer) configurations. An IE “default bearer” may be provided in the downlink control signaling (e.g., RRC signaling or system information) to configure the M-Bearer or U-Bearer as the default radio bearer for MBS packet reception.

- In some implementations, the disclosed MBS-Bearer configurations may be common to all of the MBS configured at the UE side. The disclosed MBS-Bearer configurations may be included in one MBS-common configuration in the downlink control signaling, such as RRC signaling or system information and the MBS-common configuration may be applied to all of the Multicast Broadcast services.

- In some implementations, the disclosed MBS-Bearer configurations may be service-oriented, which means the serving RAN may provide Layer-2 configuration to each MBS respectively. For example, in the AS layer, one MBS may be associated with one “MBS Application ID” , which may be unique to each MBS (in one or more PLMNs) . Then, in the downlink control signaling (e.g., RRC signaling or system information) , each of the given MBS-Bearer configurations for associated target MBS (s) may be delivered by the serving RAN with different MBS Application ID (s) . The UE may construct the AS configurations for one target MBS based on the received MBS-Bearer configuration (s) associated with the target MBS. In some implementations, the MBS may be associated more than one MBS-Identifier (e.g., MBS-IDs) . In this condition, each MBS Application ID may be associated with more MBS-Bearer (s) to support different QoS flows for the associated MBS.

- In some implementations, different Layer 2/Layer 1 configurations may be provided to different MBS-Bearer configurations. For example, the M-Bearer may not support the UE reporting/feedback mechanisms to the serving cell. For example, the M-Bearer may not configure PDCP-status report, RLC ARQ ACK/NACK report, RLC-status report, Buffer-Status Report, ARQ ACK/NACK feedback message, and/or HARQ ACK/NACK feedback message. In contrast, the U-Bearer may support (all or a subset of) the UE reporting/feedback mechanisms to the serving cell. In some implementations, the U-Bearer (e.g., MRB-ID#2) may be always activated in default and the M-Bearer (e.g., MRB-ID#1) may be activated or deactivated by the UE. In some implementations, the M-Bearer may be indicated as activated or deactivated in the MBS-Bearer configuration. In contrast, in the MBS Bearer configuration, the U-Bearer may not be associated with any indicator to activate/deactivate the U-Bearer. In some implementations, the PHY sublayers (or PHY functions) associated with the (split) bearer (e.g., the M-Bearer or the U-Bearer) may also be activated/deactivated with the activation/deactivation of the M-Bearer/U-Bearer. In some implementations, the PHY function associated with the M-Bearer (e.g., PHY 260) may be configured with one MBS-specific RNTI (such as MBS-RNTI) . In contrast, the PHY function associated with the U-Bearer (e.g., PHY 262) may be configured with another RNTI (such as C-RNTI) which is different from the MBS-RNTI. Based on the configured RNTIs in PHY 260 and PHY 262 respectively, in some implementations, the PHY function of the U-Bearer (e.g., the PHY 262) may always monitor/decode the PDCCHs configured in the DL radio subframes for possible MBS packet receptions. In contrast, the PHY function of the M-Bearer (e.g., the PHY 260) may or may not monitor/decode the PDCCHs configured in the DL radio subframes for possible MBS packet receptions based on the given MBS-RNTI depending on whether the M-Bearer is activated or deactivated. In some cases, the PHY 260 may monitor/decode the PDCCHs with the MBS-RNTI only when the M-Bearer is activated and the PHY 260 may not monitor/decode the PDCCHs with the MBS-RNTI when the M-Bearer is deactivated. In some implementations, the UE may switch the activation status of the M-Bearer (e.g., MRB-ID#1 in the FIG. 2 being activated or deactivated) based on the instructions in the downlink control signaling (e.g., via UE-specific DL RRC signaling, broadcast system information, DCI received from common search space, DCI received from UE-specific search space, or a MAC CE) from the serving cell.

MBS-Bearer Configuration Delivery via System Information

In some implementations, the MBS-Bearer configuration (which may indicate the M-Bearer and the U-Bearer) may be configured via broadcast system information.

In some implementations, the system information including the MBS-Bearer configuration may be broadcast continuously by the serving cell. The system information may include a SIB including the MBS-Bearer configuration. The SIB may be referred to as MBS-SIB in the present disclosure.

The MBS-Bearer configuration (e.g., M-Bearer and/or the U-Bearer) may be delivered in the system information continuously.

The UE triggered to start an MBS service reception may first monitor the broadcast MBS-SIB to build/establish the associated MBS-Bearer. In some implementations, the UE may need to monitor and retain the latest version of the MBS-SIB (e.g., based on the value tag, which may be broadcast in the SIB1 to be associated with the MBS-SIB scheduling information) for MBS reception.

In some implementations, the system information may not be broadcast continuously (e.g., the MBS-SIB may be indicated by the serving cell, through the SIB-scheduling information in SIB, with the information element MBS-Bearer = ‘NotBroadcast’ ) . Instead, the UE may need to request the MBS-SIB from the serving cell. The UE (e.g., UE in RRC inactive state or RRC idle state) may initiate a random access procedure, based on the random access resource configuration provided by the serving cell, to request the MBS-SIB. The UE may request the MBS-SIB by sending an MBS-SIB-Request message to the serving cell in MSG1 or MSG3 or MSG5 (e.g., the UE may request the network slice construction for the target MBS. “MBS Application ID” (or the network slice ID of the target MBS, which is pre-defined by the telecom service provider) of the requested MBS may be included in the MSG5 for service request. Then, the serving cell may deliver MBS-SIB (e.g., through broadcast approach or the UE-specific DL-RRC signaling delivery) or UE-specific dedicated control signaling (for UE-specific dedicated configuration) for service construction for the target MBS (during a four-step random access procedure or through MSGA during a two-step random access procedure) . After receiving the MBS-SIB Request message from the UE, the serving cell may start to broadcast the requested MBS-SIB for a period of time.

In some implementations, the UE (e.g., UE in RRC Connected state) may send an MBS-SIB Request message to the serving cell via the UE-specific uplink control signaling (e.g., the UL RRC signaling) to the serving cell. After receiving the MBS-SIB Request message from the UE, the serving cell may transmit the requested MBS-SIB to the UE through UE-specific downlink control signaling (e.g., the DL RRC signaling) to the UE or the UE may start monitoring the other system information search space for receiving the required MBS SIB.

Area-specific MBS-SIB

In some implementations, the MBS-MIB may be generally applicable to a specific area, which may cross the coverage of one or more cells configured by a RAN.

For example, one base station may further indicate that the MBS-SIB is associated with one system information area ID, which may be broadcast by the base station in system information (e.g., SIB1) .

One or more cells may share the same systeminformationareaID in the SIB1 broadcast by each cell respectively. The UE may keep the configured MBS-Bearer after the UE moves to another cell that shares the same systeminformationareaID associated with the MBS- SIB.

The UE may store the received MBS-SIB (and the associated system information area ID) in the memory module of the UE. While the UE is (re) selecting (or handover) to one target cell, the UE may check the system information area ID broadcast by the target cell (if there is any) . The UE may keep the stored MBS-SIB if the received systeminformationareaID is identical to the stored systeminformationareaID associated with the stored MBS-SIB. Otherwise, the UE may release the stored MBS-SIB (and the stored system information area ID) if the systeminformationareaID obtained from the target cell is different from the stored systeminformationareaID or the target cell does not broadcast any systeminformationareaID. In some conditions, the active MBS-Bearer configurations may also be released automatically.

In some implementations, without using the systeminformationareaID, one MBS-Area ID may be configured to define the validity area of MBS-SIB and the MBS-Area ID may also be broadcast by the serving RAN (e.g., being attached in the MBS-SIB or in SIB1) . The UE may implement the disclosed procedure by using the MBS-Area ID instead of the systeminformationareaID. In some implementations, an MBS-Area ID of a cell may be broadcast in the system information. In some implementations, an MBS service and its associated MBS-Area ID (s) may be broadcast in the system information or provided in dedicated signaling (e.g., an RRC message) . In some implementations, different MBS-Area IDs may be provided to be associated with different MBS (e.g., associated with different MBS-Identifiers) . In the serving RAN, such systeminformationareaID/MBS-Area ID may be delivered by the Transmission/Reception Points (TRP) connected with the same base station (or TRPs connected with different base stations respectively) . By doing so, service continuity for the associated MBS may also be achieved under the multi-TRP architecture. In some implementations, the MBS-SIB may be valid only to the serving cell (or camped cell for UEs in RRC Inactive state or RRC Idle state) . In this condition, the validity area of the MBS-SIB may be presented by the cellidentity (or Physical Cell Identity) of the serving cell/camped cell.

In some implementations, the UE may not release the MBS-Bearer (and so the stored MBS-Bearer configuration while the UE is moving to a target cell in which the MBS-SIB is still valid) . In addition, the Layer-1/Layer-2 buffer associated with the MBS-Bearer may also be retained, which means the packet re-assembly procedure in the Layer-2/Layer-1 (and so the packets pending in the soft buffer) may still be maintained (or be applicable) after the UE moves from the source cell to the target cell (e.g., through the cell (re) selection procedure or through handover procedure or conditional handover procedure) .

In some implementations, the running timers (e.g., the timers disclosed in the present disclosure) associated with the MBS-Bearer may not be reset (or be released) when the UE moves from the source cell to the target cell (the MBS-Bearer is still retained) .

In some implementations, the running timers associated with the MBS-Bearer may still be released (or reset) when the UE moves from the source cell to the target cell (even if the MBS-Bearer is still retained) .

In some implementations, different MBS (s) may be configured to be associated with one MBS-service-specific area configuration (For example, one systeminformationareaID_MBS may be configured to be associated with one MBS) . Moreover, in the target cell, the target cell may also deliver systeminformationareaID_MBS of different MBS(s) through broadcast system information and so the UE may still check whether the running MBS-Bearer (and the running timers associated with the MBS-Bearer) may be maintained (or be applicable) respectively (e.g., the check may be implemented respectively per-MBS) .

In some implementations, the UE may still release/suspend the active MBS-bearer configured to support one target MBS while the UE is moving to another cell (no matter whether the target cell shares the same systeminformationareaID with the source cell in the MBS-SIB configuration) . In addition, the UE may rebuild the radio bearer based on the stored MBS-SIB (e.g., while the stored MBS-SIB is still valid to the selected cell/target cell) . The UE may rebuild an MBS-Bearer (e.g., based on the configured default Bearer or primary path) to support one target MBS. In some implementations, the UE may need to rebuild the MBS-Bearer by the instructions from the target cell (e.g., which is delivered to the UE through DL RRC signaling or broadcast system information) . In some implementations, the U-Bearer (of the MBS-Bearer) may always be activated while the UE is moving to another cell (no matter whether the target cell shares the same systeminformationareaID with the source cell in the MBS-SIB configuration) . However, after the serving cell changes, the UE may be configured with a different RNTI in the PHY function of the U-Bearer for MBS packets reception.

MBS-Bearer switch instruction via system information

In some implementations, the serving cell may instruct UEs to switch the MBS-Bearer configuration (associated with one target MBS) from one configuration to another through system information delivery.

In some implementations, the cell may deliver the information element, such as default Bearer= {U-Bearer/M-Bearer} (or primary path = {U-Bearer/M-Bearer} ) , in the delivered system information (through broadcast approach or unicast approach) .

In some implementations, the serving cell may configure one or more MBS-Bearer configurations and each MBS-Radio Bearer configuration may be associated with one MRB-ConfigIndex (e.g., MRB-ConfigIndex#1～K) . In the (broadcast/unicast) system information, the cell may configure the IE ‘primary path= MRB-ConfigIndex#1’ or ‘default bearer=MRB-ConfigIndex#K’ in the broadcast system information.

After receiving the MBS-Bearer switch instruction in the broadcast system information, the UE may reconfigure the MBS-Bearer based on the MBS-Bearer configuration (e.g., the M-Bearer and U-Bearer) associated with the MRB-ConfigIndexID. In some implementations, the system information (which includes MBS-Bearer switch instruction) may be delivered by the serving cell to the UE through UE-specific control signaling (e.g., DL RRC signaling) .

Modification of MBS-SIB (with or without the MBS-Bearer switch instruction)

In some implementations, the base station (e.g., the eNB in E-UTRAN or the gNB in the NR-RAN) may change the MBS-SIB (e.g., the instructions to switch the MBS-Bearer between the M-Bearer/U-Bearer or the update of the MBS-Bearer configuration) . In some implementations, the MBS-SIB may be changed without the system information modification mechanism. The base station (or the serving cell of the UE) may need not to modify the MBS-SIB by following the limitation of the system information modification periods.

In some implementations, the base station may update the MBS-SIB by following the system information modification mechanisms (and the limitations of system information modification periods) .

In some implementation, the serving cell may transmit paging messages (e.g., in the short message in the PDCCH or in the paging message/paging records in the PDSCH) , which contains one indicator to inform the UE that the MBS-SIB is modified (or MBS-Bearer switch is triggered) , to the UE.

The disclosed mechanism may be applicable to UEs in RRC connected state/RRC inactive state/RRC idle state. In addition, during the MR-DC scenario, the UE may obtain the MBS-SIB (with or without MBS-Bearer switch instruction) from a secondary node (or the PSCell) through broadcast system information or through UE-specific dedicated control signaling (e.g., through Signaling Radio Bearer 3) .

In some implementations, one MBS-SIB may be segmented into several sub-MBS-SIB(s) for MBS-SIB broadcasting. In this condition, each sub-MBS-SIB may be delivered with one associated sub-MBS-SIB-ID (e.g., sub-MBS-SIB-ID#0 ～ sub-MBS-SIB-ID#K mapped to the sub-MBS-SIBs respectively) . In addition, to the last piece of the sub-MBS-SIBs (e.g., sub-MBS-SIB-ID#K in this example) , one additional end-marker may be further indicated with the sub-MBS-SIB. The UE may need to reassemble a whole sub-MBS-SIB only by receiving all of the sub-MBS-SIB (s) broadcast by the serving RAN. The UE may know the number of sub-MBS-SIB (s) that the UE needs to collect by checking the end-marker during the sub-MBS-SIB collection procedure. The UE may collect the sub-MBS-SIB (s) delivered by different base stations (or different cells) to re-assemble the whole MBS-SIB while these cells are located in the same area defined by MBS-AreaID or systeminformationareaID (in other words, the stored sub-MBS-SIBs may not be dropped during the mobility event, such as cell (re) selection procedure or (conditional) handover procedure) . The cells in the same systeminformationareaID or MBS-Area ID may segment the MBS-SIB in the same approach (e.g., each sub-MBS-SIB delivered by these cells may have the same content with the same sub-MBS-SIB-ID) .

The UE may not be able to configure/establish any MBS-Bearer based on the MBS-SIB only after the whole MBS-SIB is reassembled by the UE successfully through these stored sub-MBS-SIBs (in other words, the stored sub-MBS-SIBs are not considered as a valid SIB unless the whole MBS-SIB is obtained successfully from these stored sub-MBS-SIBs) .

MBS Radio Bearer Configuration Delivery through UE-specific dedicated control signaling (e.g., RRC signaling)

In some implementations, the UE may obtain the MBS-Bearer configuration (with or without the MBS-Bearer switch instruction) via DL-UE specific control signaling (e.g., RRC signaling) . The MBS-Bearer configuration may be generated by a master node or a secondary node. The UE may receive the MBS radio bearer configuration from a master node via a Signaling Radio Bearer 1 (SRB1) or from a secondary node via a Signaling Radio Bearer 3 (SRB3) .

In some implementations (e.g., while the UE is configured with EN-DC or NG-ENDC configuration) , the serving primary cell of the UE may be an E-UTRA cell and the primary secondary cell of the UE may be an NR cell. The master node of the UE may be an eNB or ng-eNB and the secondary node of the UE may be a gNB. The master node may forward the MBS-Bearer configuration, which may be generated by the secondary node, to the UE through DL control signaling (e.g., through the SRB1 between the PCell and the UE) . In some implementations, while the UE is configured with MR-DC (Multi-RAT) , the secondary node (or PSCell) may transmit the MBS-Bearer configuration to the UE through SRB3.

DAPS Configuration for MBS-Bearer

In some implementations, one MBS-Bearer (e.g., the M-Bearer or the U-Bearer) may be configured as DAPS-bearer by the serving cell. For example, during the handover procedure (or conditional handover procedure) , the serving cell may configure one IE “DAPSConfig = ENUMERATED {true} ” to be associated with the MBS-Bearer configuration in the DL RRC signaling (e.g., RRC signaling with reconfigurationwithsync or conditionalreconfigurationwithsync signaling) . In some implementations, the serving cell may configure “DAPSConfig = ENUMERATED {true} ” to be associated only with U-Bearer or M-Bearer (so the DAPSConfig may be included only in the M-Bearer configuration or the U-Bearer configuration) .

If dapsConfig= {true} is configured to the MBS-Bearer, then

- The UE may create a MAC entity to be associated with the target cell based on the same configuration as the MAC entity associated with the source cell.

- The UE may reconfigure the RLC entity or entities for the target cell in accordance with the received RLC-configuration associated with the MBS-Bearer.

- The UE may reconfigure the logical channel for the target cell in accordance with the received logical channel configurations associated with the MBS-Bearer.

- The UE may use values for the target cell’s timers T301, T310, T311 and the target cell’s constants N310, N311, as included in ue-TimersAndConstants received in SIB1 (associated with the target cell) . In addition, the UE may configure the value of the target cell’s timers and the target cell’s constants in accordance with received rlf-TimersAndConstants.

- The UE may implement SRB addition or re-configuration associated with the target cell accordingly.

- In some implementations, no additional new configurations may be provided to the DAPS-Bearer associated with the target cell. Instead, the UE may configure the DAPS-Bearer (associated with one target MBS) based on the same Layer2/Layer1 configurations with the original MBS-Bearer configuration.

- In some implementations, there may be one default MBS-Bearer configuration for the DAPS-Bearer associated with the target cell. For example, the M-Bearer (or the U-Bearer) may be the default MBS-Bearer configuration for the DAPS-Bearer of one target MBS-Bearer (the UE may apply the stored U-Bearer configuration to build the associated DAPS-Bearer for the target MBS) . The same concept (default MBS-Bearer configuration for the DAPS-Bearer construction) may also be applied to the M-Bearer configuration. In some implementations, the U-Bearer may be the default (active) MBS-Bearer (without explicit indication from the serving RAN) during the DAPS handover procedure and the M-Bearer may be activated/deactivated (e.g., indicated by UE-specific RRC signaling or by a preconfigured/predefined default setting) during the DAPS handover procedure.

- In some implementations, the serving cell may explicitly indicate the ‘default MBS-Bearer configuration for DAPS-Bearer construction’ to the UE (e.g., ‘default DAPS-Bearer configuration= {M-Beaer/U-Bearer} ’ or MRB-ID#K) to the UE via DL control signaling (e.g., UE-specific DL RRC signaling or through system information delivery) . In some implementations, the default DAPS-Bearer may be predefined in the technical specification or pre-installed in the USIM.

To the MBS-Bearer configuration, the serving cell may not configure ‘reestablishPDCP= {true} ’ or ‘recoverPDCP= {true} ’ in the DL control signaling (e.g., when the serving cell wants to modify the configuration of MBS-Bearer by sending an MRB-ToAddMod list in the downlink control signaling to the UE) . The serving cell may not configure ‘conditionalReconfiguration’ to the UE if dapsConfig= {true} has been configured for any MBS-Bearer or DRB.

To the MBS-Bearer configuration, some parameters (e.g., parameters in PDCP layers) may not be changed during the reconfiguration with sync procedure when dapsConfig= {true} is configured to the associated MBS-Bearer. For example, the “discardTimer” , “pdcp-SN-SizeDL” , “t-Reordering” associated with the MBS-Bearer may not be changed while dapsConfig= {true} is configured to the MBS-Bearer.

In some implementations, one dapsConfig= {true} may be configured to be applied to all of the active MBS-Bearers at the UE side. In some implementations, each MBS-Bearer may be associated with one dapsConfig= {true} . In some implementations, the dapsConfig may be MBS-service specific and it may be applied to more MBS-Bearers associated with one MBS.

In some implementations, the dapsConfig may be configured to be associated with MBS-Bearer configuration in the system information, which may be delivered through broadcast approach or unicast approach.

Range-based MBS-Bearer Configuration &Conditional Reconfiguration (or conditional switch) for MBS-Bearer

In some implementations, the configured MBS-Bearer (e.g., the M-Bearer and/or the U-Bearer or one MBS-Bearer configuration) may be further configured with one associated with a valid range. FIG. 3 illustrates a diagram 300 illustrating ranges associated with a base station according to an example implementation of the present disclosure. The base station 310 may configure one or more cells to serve one or more UEs within a certain physical distance. Because the channel quality may depend on the distance between the base station and the UE, the BS may instruct the UE to apply range-based MBS-Bearer configuration. For example, the UE may apply a first MBS-Bearer configuration within the range R1 and apply a second MBS- Bearer configuration within the range R2.

Range-based MBS-Bearer Configuration

In some implementations, the UE may receive a predefined range associated with the MBS-Bearer configuration (e.g., MRB-ReceptionRange) .

The MRB-ReceptionRange may be defined with meters in physical distance. For example, MRB-ReceptionRange= {m100} , where m100 means 100 meters physical distance.

In some implementations, the MRB-ReceptionRange indicates an upper bound for the MBS-Bearer configuration, which means the UE may apply the MBS-Bearer configuration for one or more MBS-Bearer (s) to receive target MBS packets (and/or to transmit uplink feedback information) only when the physical distance between the BS (or the serving cell) and the UE is shorter than (or equal to) the given MRB-ReceptionRange (e.g., 100 meters) . In some implementations, the UE may estimate the physical distance with the serving Base Station (e.g., eNB/gNB) via the DL Reference Signaling Reception (e.g., DL Synchronization Signal Block Set reception) and pathloss estimation.

In some implementations, the MRB-ReceptionRange indicates a lower bound for the MBS-Bearer configuration, which means the UE may apply the MBS-Bearer configuration for MBS packet reception (and/or the uplink feedback information transmission) only when the physical distance between the BS and the UE is larger than (or equal to) the given MRB-ReceptionRange (e.g., 100 meters) .

In some implementations, the MRB-ReceptionRange may cover an upper bound and a lower bound. For example, MRB-ReceptionRange_LowBound=m100, MRB-ReceptionRange_UpBound=m300} may be configured in the MBS-Bearer configuration to the UE.The UE may apply the MBS-Bearer configuration when the physical distance between the UE and the BS is between the MRB-ReceptionRange_LowBound and the MRB-ReeceptionRange_UpBound.

The disclosed implementations above may not be limited only to the M-Bearer configuration but may also be applicable to the U-Bearer configuration or any one of MBS-Bearer configuration (e.g., one MRB-ReceptionRange may be associated with one MRB-ConfigIndex) .

In some implementations, the UE may apply the default MBS-Bearer configuration (e.g., U-Bearer configuration or M-Bearer configuration) when the other given MBS-Bearer configuration is not applicable (based on the given range associated with these not-applicable MBS-Bearer configuration) . In this condition, the default MBS-Bearer configuration may not be associated with any range requirement. For example, when the UE is configured with an M- Bearer and a U-Bearer, the U-Bearer may be the default bearer that is always activated in default. When the UE switches from a source cell to a target cell during a handover procedure, the UE may activate the U-Bearer during the handover procedure.

The UE may estimate the physical distance between itself and the serving BS based on 3GPP-based approach (e.g., NR positioning technique in the 3GPP Release-16 TS) or non-3GPP-based approach (e.g., GNSS approach or Wi-Fi approach) .

Definition of Range

In some implementations, the range may be defined by the DL signal strength (e.g., DL-RSRP/DL-RSRQ/DL-SINR) monitored by the UE (e.g., by monitoring the SSB burst set or CSI-RS broadcast by the serving cell) .

In some implementations, the MRB-ReceptionRange/MRB-ReceptionRange_LowBound/mrb-ReceptionRange_UpBound may be defined by a value within RSRP-Range. In 3GPP specification, the RSRP-Range (e.g., RSRP-Range : : =INTEGER (0.. 127) ) specifies the value range used in RSRP measurements and thresholds. For measurements, integer value for RSRP measurements is according to Table 10.1.6.1-1 in 3GPP TS 38.133. For thresholds, the actual value is (IE value –156) dBm, except for the IE value 127, in which case the actual value is infinity.

In some implementations, the MRB-ReceptionRange/MRB-ReceptionRange_LowBound /MRB-ReceptionRange_UpBound may be defined by a value within RSRQ-Range. In 3GPP specification, the RSRQ-Range (e.g., RSRQ-Range : : =INTEGER (0.. 127) ) specifies the value range used in RSRQ measurements and thresholds. For measurements, integer value for RSRQ measurements is according to Table 10.1.11.1-1 in 3GPP TS 38.133. For thresholds, the actual value is (IE value –87) /2 dB.

In some implementations, the MRB-ReceptionRange/MRB-ReceptionRange_LowBound/mrb-ReceptionRange_UpBound may be defined by a value within SINR-Range. In 3GPP specification, the SINR-Range (e.g., SINR-Range : : =INTEGER (0.. 127) ) specifies the value range used in SINR measurements and thresholds. For measurements, integer value for SINR measurements is according to Table 10.1.16.1-1 in TS 38.133. For thresholds, the actual value is (IE value –46) /2 dB.

(Conditional) MBS-Bearer Configuration/MBS-Bearer Switch Signaling

Based on the provided range-based MBS-Bearer configuration (but not be limited by the range-based MBS-Bearer configuration) , conditional MBS-Bearer configuration/switch mechanism is disclosed. FIG. 4 illustrates a process 400 of (conditional) MBS-Bearer configuration according to an example implementation of the present disclosure.

In action 412, the serving RAN 404 (e.g., the serving cell of the UE 402) may transmit MBS-Bearer configuration (which may include M-Bearer configuration/U-Bearer configuration and other additional MBS-Bearer configurations) to the UE 402. In some implementations, the serving RAN 404 may transmit conditional MBS-Bearer configuration to the UE 402 (e.g., the disclosed range-based MBS-Bearer configuration) with the associated triggering events (e.g., the defined MRB-ReceptionRange/MRB-ReceptionRange_LowBound/MRB-ReceptionRange_UpBound associated with one MBS-Bearer configuration) . The (conditional) MBS-Bearer configuration in action 412 may be transmitted via DL RRC signaling (e.g., RRCReconfiguration message with the IE ‘conditional reconfiguration’ ) or system information (through broadcast approach or SI on-demand procedure) .

In action 414, after receiving the (conditional) MBS-Bearer configuration message from the serving RAN 404, the UE 402 may determine whether the triggering event of an associated MBS-Bearer configuration is fulfilled (e.g., when the measurement results of (at least) one of the candidate cells observed by the UE fulfill the triggering requirements (associated with the candidate cell (s) ) of a conditional handover procedure) . In some implementations, the candidate cell list, the MBS-Bearer configuration associated with the enlisted candidate cells, and the measurement approaches with triggering events (for the UE to initiate the handover procedure with one of the candidate cells selected by the UE) may be included in the IE ‘conditional reconfiguration’ , which may be transmitted by the source cell to the UE via DL RRC signaling or system information.

For example, the serving RAN 404 may instruct the UE 402 to switch the MBS-Bearer configuration to M-Bearer configuration or U-Bearer configuration in the MBS-Bearer configuration message. In some implementations, the triggering event may be a direct instruction (e.g., the source cell may instruct the UE 402 to directly handover to a specific target cell determined by the serving cell) from the serving RAN 404.

In some implementations, the serving RAN 404 may configure the ranges associated with the MBS-Bearer configurations. In this condition, the UE 402 may identify whether any triggering event is fulfilled by the UE 402 itself (e.g., the UE 402 may estimate the physical distance to the serving cell or the measured DL-RSRP/RSRQ/SINR in the serving cell) . The UE 402 may select the operating MBS-Bearer (for MBS packet reception with or without uplink packet transmission) when one or more triggering events is fulfilled. It may depend on UE implementations to select the operating MBS-Bearer configuration when multiple triggering events are fulfilled.

In some implementations, in action 416, the UE 402 may reply a feedback message to the serving RAN 404. For example:

- The UE 402 may reply with an RRCReconfigurationComplete message to the serving RAN 404 if the UE 402 receives the MBS-Bearer configuration from the serving RAN 404 via a DL RRC signaling.

- The UE 402 may reply with a conditional RRCReconfigutrationComplete message to the serving RAN 404 after the UE 402 (re) selects one MBS-Bearer configuration based on the fulfilled triggering events.

- In some implementations, the UE 402 may further inform which MBS-Bearer configuration (e.g., the M-Bearer/U-Bearer or a given MRB-ConfigIndex) is the operating MBS-Bearer configuration to the serving RAN 404. In this condition, the UE 402 may not report (e.g., the UE 402 may skip the reporting procedure) to the serving RAN 404 if the UE is operating on the pre-defined ‘default MBS-Bearer configuration’ .

- In some conditions, the cell that transmits the (conditional) MBS-Bearer configuration message (to the UE 402) in action 412 and the cell that receives the (conditional) MBS-Bearer configuration complete message (from the UE 402) in action 416 may not be the same cell. For example, the UE 402 may receive the (conditional) MBS-Bearer configuration within a conditional handover message. Then, the UE 402 may re-select the operating MBS-Bearer configuration while conditional handover event is triggered. The UE 402 may reply with the (conditional) MBS-Bearer configuration complete message to the selected target cell within the conditional handover complete message. Moreover, in some implementations, both of the cells may operate in different RATs respectively (e.g., one is an E-UTRA cell and the other one is an NR cell during inter-RAT handover procedure) .

- In some implementations, the cell that transmits the (conditional) MBS-Bearer configuration message in action 412 and the cell that receives the (conditional) MBS-Bearer configuration complete message in action 416 may be the same cell.

In some implementations, the UE 402 may not reply with the (conditional) MBS-Bearer configuration complete message to the serving RAN 404 after the UE 402 (re) selects the operating MBS-Bearer configuration (e.g., when the UE receives the (conditional) MBS-Bearer configuration message via broadcast system information) .

In some implementations, in the action 414, the UE 402 may apply the (conditional) MBS-Bearer configuration associated with the selected target cell (which may be determined by the UE 402 among one or more candidate cells of which measurement results fulfill the (handover) triggering condition nearly at the same time) directly after the UE 402 initiates the handover procedure to the target cell in the action 414. In some implementations, the U-Bearer of the MBS-Bearer (associated with the target cell) may be activated in default.

The serving cell may already keep delivering downlink packets on all of the candidates of MBS-Bearer (s) configured to the UE 402 (before the conditional MBS-Bearer configuration instruction is delivered to the UE 402) . The UE 402 may be able to keep receiving the downlink packets continuously (e.g., the soft buffers and the HARQ process IDs associated with the MBS-Bearer may not be flushed) after the (conditional) MBS-Bearer configuration is triggered by the UE 402.

RRC Reconfiguration Failure and Full Configuration

In some implementations, the UE may trigger RRCReconfiguration Failure event when a failure event occurs to the MBS-Bearer configuration. In some implementations, the RRC Reconfiguration Failure report procedure may be only enabled to UEs in the RRC Connected state.

In some implementations, the UE may not trigger RRCReconfiguration Failure event when a failure event occurs to the MBS-Bearer configuration.

In some implementations, the UE may initiate a full configuration procedure to the MBS-Bearer when the RRC Reconfiguration Failure event occurs at the UE side. In some implementations, the U-Bearer/M-Bearer may become the default (active) MBS-Bearer (or default split bearer) during the full configuration procedure. In addition, after the full configuration procedure, the UE may receive the MBS packets only by using the default U-Bearer/M-Bearer. In contrast, after the full configuration procedure, the M-Bearer (or the U-Bearer) may be deactivated by the UE directly (e.g., as a default implementation preconfigured/predefined to the UE) .

In some implementations, the UE may not trigger (RRC) Reconfiguration failure report to the serving cell if the failed MBS-Bearer configuration is received via system information reception. The system information may be delivered to the UE through a broadcast approach or a UE-specific dedicated control signaling. In some implementations, the UE may trigger (RRC) Reconfiguration Failure report to the serving cell only when the failed MBS-Bearer configuration is received via UE-specific DL control signaling (e.g., DL RRC signaling) .

In some implementations, the UE may fallback to apply the default MBS-Bearer configuration when the RRC Reconfiguration Failure Event occurs (no matter whether the RRC Reconfiguration Failure is caused by MBS-Bearer configuration failure or not) . In some implementations, the UE may receive the default MBS-Bearer configuration from its serving cell by receiving the system information delivered by the serving cell (e.g., through broadcast approach or UE-specific RRC signaling reception) . In some implementations, the U-Bearer (or the M-Bearer) may become the default (active) MBS-Bearer (or default split bearer) after the reconfiguration failure event. In addition, after the reconfiguration failure event, the UE may receive the MBS packets only by using the default U-Bearer (or M-Bearer) . In contrast, after the reconfiguration failure event, the M-Bearer (or the U-Bearer) may be deactivated by the UE directly (e.g., as a default implementation preconfigured/predefined to the UE) .

MAC Reset and soft-buffer refresh

In some implementations, the UE may not reset the logical channels in the MAC entity (associated with the running MBS (s) at the UE side) after receiving an MBS-Bearer switch instruction from the serving RAN (e.g., via broadcast system information or UE-specific dedicated control signaling) or when the UE triggers MBS-Bearer switch based on the received (conditional) MBS-Bearer configuration message.

In some implementations, the UE may not flush the soft buffers for the DL HARQ processes (and/or the ARQ processes) associated with the MBS-Bearers after the MBS-Bearer is switched/re-configured.

The disclosed implementations in the present disclosure may be applicable to UEs in RRC connected state/RRC inactive state/RRC idle state. In addition, the disclosed implementations may be applicable to 3GPP NR or E-UTRA. However, the disclosed implementations are not limited to the NR/E-UTRA RAT and may be applicable to other 3GPP/Non-3GPP RATs as well.

FIG. 5 illustrates a method 500 performed by a UE for MBS radio bearer configuration according to an example implementation of the present disclosure. In action 502, the UE receives, from a serving cell, an MBS radio bearer configuration indicating a multicast bearer and a unicast bearer, where the multicast bearer and the unicast bearer are associated with a common PDCP entity. The split bearer architecture including the multicast bearer and the unicast bearer may be referred to FIG. 1. For example, the MRB-ID #1 may be the multicast bearer, which may also be referred to as the PTM leg (or M-Bearer) . The MRB-ID #2 may be the unicast bearer, which may also be referred to as the PTP leg (or U-Bearer) . In action 504, the UE configures the MBS radio bearer based on the received MBS radio bearer configuration to receive DL data via at least one of the multicast bearer and the unicast bearer, where the unicast bearer is always activated in default after the UE configures the unicast bearer based on the received MBS radio bearer configuration (or after the UE starts DL MBS packet reception based on the configured MBS-Bearer configuration) .

In some implementations, the unicast bearer supports UE feedback mechanism to the serving cell (e.g., HARQ processes in the PHY/MAC layer and/or ARQ processes in the RLC layer) . The multicast bearer does not support the UE feedback mechanism to the serving cell (e.g., HARQ processes in the PHY/MAC layer and/or ARQ processes in the RLC layer) . The UE feedback mechanism may include at least one of PDCP-status report, RLC-status report, Buffer-Status Report, ARQ ACK/NACK feedback message, and HARQ ACK/NACK feedback message.

In some implementations, the unicast bearer may be predefined as activated by default. On the other hand, the multicast bearer may be activated or deactivated in the MBS radio bearer configuration. For example, the MBS radio bearer configuration received in action 502 may indicate whether the multicast bearer is activated or deactivated.

In some implementations, the MBS radio bearer configuration may be received via dedicated RRC signaling. In some implementations, the MBS radio bearer configuration may be received via broadcast system information.

In some implementations, the MBS radio bearer configuration may be generated by a master node or a secondary node. In some implementations, the UE may receive the MBS radio bearer configuration from a master node via a SRB1 or from a secondary node via a SRB3.

FIG. 6 illustrates a method 600 for switching the MBS bearer according to an example implementation of the present disclosure. In action 602, the UE receives a switch indicator from the serving cell. In action 604, the UE determines whether to activate or deactivate the multicast bearer according to the switch indicator. In some implementations, action 602 may be performed by the UE after action 502 and action 504. In some implementations, the switch indicator in action 602 may be received via broadcast system information. In some implementations, the switch indicator in action 602 may be received via at least one of UE-specific MAC CE and DCI.

FIG. 7 illustrates a method 700 performed by the UE for handling the MBS radio bearer configuration according to an example implementation of the present disclosure. In some implementations, the method 700 may be performed by the UE after action 502 and action 504. In action 702, the UE stores the MBS radio bearer configuration received from the serving cell (e.g., received in action 502) . In action 704, the UE performs a handover procedure (e.g., a conventional handover procedure/conditional handover procedure/DAPS handover procedure) to switch from the serving cell to a target cell. In action 706, the UE identifies whether the stored MBS radio bearer configuration is valid to the target cell (or whether there is any stored MBS radio bearer configuration associated with the target cell) .

In some implementations, the UE may determine whether the stored MBS radio bearer configuration is valid to the target cell according to at least one of a range (e.g., a physical distance between the UE and the target cell and/or DL signal strength monitored by the UE, such as DL-RSRP/DL-RSRQ/DL-SINR) and a validity area (e.g., based on a system information area ID) in action 706. In some implementations, the serving cell may configure the association of a target cell/candidate cell with one (or more) MBS radio bearer configuration via the DL RRC signaling (e.g., via handover instruction or conditional handover instruction in the RRCReconfiguration message) . For example, in the RRCReconfiguration message, the cell identity of one (target/candidate) cell may be indicated with one MBS radio bearer ID, which is used to identify one of the stored MBS radio bearer configurations and so the UE may determine which MBS radio bearer configuration to apply during the handover procedure with one selected target cell based on the cell identity of the target cell. Therefore, in some implementations, the UE may store more than one MBS radio bearer configuration and each MBS radio bearer configuration may be associated with one or more cell identity (which may be the candidate cell or target cell of the UE to implement handover procedure) . However, in some implementations, one target cell/candidate cell may only be associated with one MBS radio bearer configuration. The MBS radio bearer configuration may be determined by the target cell/candidate cell (or base station (BS) which manages the target cell/candidate cell, which is called the selected BS in this example) . Before the handover procedure, the source cell (or the source base station) of the UE may select one or more candidate cell/target cell for handover preparation. Then, the source base station may implement handover negotiation procedure with the selected base station (s) to request the possibility to handover the concerned UE to the selected base station (s) (and so handover the UE to the target cell/candidate cell managed by these selected base station (s) ) . The handover negotiation procedure may be implemented via backhaul connections (e.g., X2 interface in E-UTRA protocols and/or Xn interface in New Radio protocols) between the source BS and the selected BS (s) . During the handover preparation procedure, the source base station may transmit (part of) the (Access Stratum) UE context (e.g., the original MBS radio bearer configuration in the UE side when the UE is connecting with the source base station) to the selected base station (s) . Then, the selected base station may reply whether the selected base station accepts the handover request of this UE. In addition, the selected base station may also decide/configure and reply an updated AS configuration (e.g., an updated MBS radio bearer configuration) , which the UE should apply after the UE handovers to the selected BS, to the source BS (via backhaul connection) . After receiving the reply from the selected base station (and the source cell may gather the response from one or more selected base stations) , the source base station may summarize all of the selected base stations (and the candidate cell (s) /target cell (s) which accept the handover request for the UE) and the updated AS configurations decided by these base stations. Finally, the source base station (or the source cell) may deliver the summarized configuration (e.g., the target cell (s) /candidate cell (s) and updated AS configuration (e.g., updated MBS radio bearer configuration) associated with these target cell (s) /candidate cell (s) ) to the UE via a UE-specific DL control signaling (e.g., RRCReconfiguration message with the IE ‘reconfigurationwithsyc’ or ‘conditionalreconfiguration’ or ‘DAPSconfiguration’ ) for the UE to implement handover procedure/conditional handover procedure/DAPS handover procedure.

In some implementations, there may be one common MBS radio bearer configuration that is applicable to all of the candidate cells (and/or target cell) . For the common MBS radio bearer configuration, the serving RAN may just indicate ‘common MBS radio bearer configuration’ without further indicating the cell identity list associated with this common MBS radio bearer configuration.

In action 708, the UE applies the MBS radio bearer configuration upon determining the MBS radio bearer configuration is valid to the target cell (or there is one stored MBS radio bearer configuration associated with the target cell) after switching to the target cell. In action 710, the UE activates the unicast bearer during the handover procedure. In some implementations, the handover procedure in action 704 is a conditional handover procedure that is initiated by the UE upon determining at least one triggering condition is fulfilled.

It should be noted that

actions

702, 704, 706, 708, and 710 should not be construed as necessarily order dependent in their performance. The order in which the process is described is not intended to be construed as a limitation, and any number of the described actions may be combined in any order to implement the method or an alternate method. Moreover, one or more of the actions illustrated in FIG. 7 may be omitted in some implementations.

FIG. 8 illustrates a method 800 performed by the UE for handling the MBS radio bearer configuration according to another example implementation of the present disclosure. In some implementations, the method 800 may be performed by the UE after action 502 and action 504. In action 802, the UE performs a handover procedure to switch from the serving cell to a target cell. In some implementations, the handover procedure is a conditional handover procedure that is initiated by the UE upon determining at least one triggering condition is fulfilled. In action 804, the UE receives, from the serving cell, a DAPS indicator that indicates which one of the multicast bearer and the unicast bearer is maintained after switching to the target cell. In action 806, the UE maintains one of the multicast bearer and the unicast bearer and releases the other one of the multicast bearer and the unicast bearer after switching to the target cell. Action 804 illustrated in FIG. 8 may be omitted in some implementations. For example, the UE may not receive the DAPS indicator and the UE may determine by itself which one of the multicast bearer (e.g., M-Bearer) and the unicast bearer (e.g., U-Bearer) is maintained after switching to the target cell. In some implementations, the UE may be predefined/preconfigured to maintain the (active) unicast bearer directly (e.g., as a default setting) during the DAPS handover procedure. In contrast, the M-Bearer may be deactivated/activated by the UE during the DAPS handover procedure.

FIG. 9 is a block diagram illustrating a node 900 for wireless communication according to an implementation of the present disclosure. As illustrated in Fig. 9, a node 900 may include a transceiver 920, a processor 928, a memory 934, one or more presentation components 938, and at least one antenna 936. The node 900 may also include a Radio Frequency (RF) spectrum band module, a BS communications module, a network communications module, and a system communications management module, Input /Output (I/O) ports, I/O components, and a power supply (not illustrated in Fig. 9) .

Each of the components may directly or indirectly communicate with each other over one or more buses 940. The node 900 may be a UE or a BS that performs various functions disclosed with reference to FIGS. 1 through 8.

The transceiver 920 has a transmitter 922 (e.g., transmitting/transmission circuitry) and a receiver 924 (e.g., receiving/reception circuitry) and may be configured to transmit and/or receive time and/or frequency resource partitioning information. The transceiver 920 may be configured to transmit in different types of subframes and slots including but not limited to usable, non-usable and flexibly usable subframes and slot formats. The transceiver 920 may be configured to receive data and control channels.

The node 900 may include a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the node 900 and include both volatile and non-volatile media, removable and non-removable media.

The computer-readable media may include computer storage media and communication media. Computer storage media include both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or data.

Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Computer storage media do not include a propagated data signal. Communication media typically embody computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media.

The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the previously listed components should also be included within the scope of computer-readable media.

The memory 934 may include computer-storage media in the form of volatile and/or non-volatile memory. The memory 934 may be removable, non-removable, or a combination thereof. Example memory includes solid-state memory, hard drives, optical-disc drives, etc. As illustrated in Fig. 9, the memory 934 may store computer-readable, computer-executable instructions 932 (e.g., software codes) that are configured to cause the processor 928 to perform various disclosed functions, for example, with reference to FIGS. 1 through 8. Alternatively, the instructions 932 may not be directly executable by the processor 928 but be configured to cause the node 900 (e.g., when compiled and executed) to perform various disclosed functions.

The processor 928 (e.g., having processing circuitry) may include an intelligent hardware device, e.g., a Central Processing Unit (CPU) , a microcontroller, an ASIC, etc. The processor 928 may include memory. The processor 928 may process data 930 and the instructions 932 received from the memory 934, and information transmitted and received via the transceiver 920, the base band communications module, and/or the network communications module. The processor 928 may also process information to be sent to the transceiver 920 for transmission via the antenna 936 to the network communications module for transmission to a core network.

One or more presentation components 938 present data indications to a person or another device. Examples of presentation components 938 include a display device, a speaker, a printing component, and a vibrating component, etc.

In view of the present disclosure, it is obvious that various techniques may be used for implementing the concepts in the present disclosure without departing from the scope of those concepts. Moreover, while the concepts have been disclosed with specific reference to certain implementations, a person of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of those concepts. As such, the disclosed implementations are to be considered in all respects as illustrative and not restrictive. It should also be understood that the present disclosure is not limited to the particular implementations disclosed and many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.

Claims

A method performed by a user equipment (UE) for Multicast Broadcast Service (MBS) radio bearer configuration, the method comprising:

receiving, from a serving cell, an MBS radio bearer configuration indicating a multicast bearer and a unicast bearer; and

configuring the MBS radio bearer based on the received MBS radio bearer configuration to receive downlink (DL) data via at least one of the multicast bearer and the unicast bearer, wherein:

the multicast bearer and the unicast bearer are associated with a common Packet Data Convergence Protocol (PDCP) entity; and

the unicast bearer is always activated in default after the UE configures the unicast bearer based on the received MBS radio bearer configuration.
The method of claim 1, wherein the multicast bearer is activated or deactivated in the MBS radio bearer configuration.
The method of claim 1, wherein the MBS radio bearer configuration is received via dedicated Radio Resource Control (RRC) signaling.
The method of claim 1, wherein the MBS radio bearer configuration is received via broadcast system information.
The method of claim 1, wherein the MBS radio bearer configuration is generated by a master node or a secondary node.
The method of claim 1, wherein the UE receives the MBS radio bearer configuration from a master node via a Signaling Radio Bearer 1 (SRB1) or from a secondary node via a Signaling Radio Bearer 3 (SRB3) .
The method of claim 1, further comprising:

receiving a switch indicator from the serving cell; and

determining whether to activate or deactivate the multicast bearer according to the switch indicator.
The method of claim 7, wherein the switch indicator is received via broadcast system information.
The method of claim 7, wherein the switch indicator is received via at least one of UE-specific Medium Access Control (MAC) Control Element (CE) and Downlink Control Information (DCI) .
The method of claim 1, further comprising:

storing the MBS radio bearer configuration received from the serving cell;

performing a handover procedure to switch from the serving cell to a target cell;

identifying whether the stored MBS radio bearer configuration is valid to the target cell;

applying the MBS radio bearer configuration upon determining the MBS radio bearer configuration is valid to the target cell after switching to the target cell; and

activating the unicast bearer during the handover procedure.
The method of claim 10, wherein the handover procedure is a conditional handover procedure that is initiated by the UE upon determining at least one triggering condition is fulfilled.
The method of claim 1, further comprising:

performing a handover procedure to switch from the serving cell to a target cell; and

maintaining one of the multicast bearer and the unicast bearer and releasing the other one of the multicast bearer and the unicast bearer after switching to the target cell.
The method of claim 12, further comprising:

receiving, from the serving cell, a dual active protocol stack (DAPS) indicator that indicates which one of the multicast bearer and the unicast bearer is maintained after switching to the target cell.
The method of claim 1, wherein:

the unicast bearer supports UE feedback mechanism to the serving cell; and

the multicast bearer does not support the UE feedback mechanism to the serving cell.
A user equipment (UE) for Multicast Broadcast Service (MBS) radio bearer configuration, the UE comprising:

one or more processors; and

at least one memory coupled to at least one of the one or more processors, wherein the at least one memory stores a computer-executable program that, when executed by the at least one of the one or more processors, causes the UE to perform the method of any of claims 1 to 14.