WO2022028546A1

WO2022028546A1 - Method of broadcast or multicast service and related device

Info

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

Abstract

A method of broadcast or multicast service for a user equipment (UE) is provided. The method includes establishing a multicast broadcast service (MBS) radio bearer corresponding to a first broadcast or multicast service on a first cell, leaving the first cell, and releasing the MBS radio bearer when at least one of conditions is fulfilled, wherein the conditions include receiving, from the first cell, a first dedicated radio resource control (RRC) signaling or first broadcast system information indicating none of neighboring cells of the first cell supports the first broadcast or multicast service, and receiving, from the first cell, a second dedicated RRC signaling for handover from the first cell to a second cell, the second dedicated RRC signaling indicating that the second cell does not support the first broadcast or multicast service.

Description

METHOD OF BROADCAST OR MULTICAST SERVICE AND RELATED DEVICE

CROSS-REFERENCE TO RELATED APPLICATION (S)

The present disclosure claims the benefit of and priority to U.S. Provisional Patent Application Serial No. 63/062361 filed on 8/6/2020, entitled “METHOD AND APPARATUS TO SUPPORT SERVICE CONTINUITY FOR MULTIMEDIA BROADCAST MULTICAST SERVICE, ” (hereinafter referred to as “the ‘361 provisional” ) . The disclosure of the ‘361 provisional is hereby incorporated fully by reference into the present disclosure.

FIELD

The present disclosure is generally related to wireless communications and more specifically, to a method of broadcast or multicast service and a related device.

BACKGROUND

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 for optimizing the network services and types and 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 is a need for further improvements in wireless communication for the next-generation wireless communication system.

SUMMARY

The present disclosure provides a method of broadcast or multicast service and a related device.

According to an aspect of the present disclosure, a method of broadcast or multicast service for a user equipment (UE) is provided. The method includes establishing a multicast broadcast service (MBS) radio bearer corresponding to a first broadcast or multicast service on a first cell, leaving the first cell, and releasing the MBS radio bearer when at least one of conditions is fulfilled, wherein the conditions include receiving, from the first cell, a first dedicated radio resource control (RRC) signaling or first broadcast system information indicating none of neighboring cells of the first cell supports the first broadcast or multicast service, and receiving, from the first cell, a second dedicated RRC signaling for handover from the first cell to a second cell, the second dedicated RRC signaling indicating that the second cell does not support the first broadcast or multicast service.

According to another aspect of the present disclosure, a UE for performing broadcast or multicast service is provided. The UE includes a processor configured to execute a computer-executable program, and a memory coupled to the processor and configured to store the computer-executable program, wherein the computer-executable program instructs the processor to perform the above-described method of broadcast or multicast service.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are best understood from the following detailed disclosure 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 is a flowchart illustrating a first method of broadcast or multicast service, according to an implementation of the present disclosure.

FIG. 2 is a flowchart illustrating a second method of broadcast or multicast service, according to an implementation of the present disclosure.

FIG. 3 is a flowchart illustrating a third method of broadcast or multicast service, according to an implementation of the present disclosure.

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

DESCRIPTION

The following disclosure contains specific information pertaining to exemplary implementations in the present disclosure. The drawings and their accompanying detailed disclosure are directed to exemplary implementations. However, the present disclosure is not limited to these exemplary implementations. Other variations and implementations of the present disclosure will occur to those skilled in the art. Unless noted otherwise, like or corresponding elements in the drawings may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations are generally not to scale and are not intended to correspond to actual relative dimensions.

For consistency and ease of understanding, like features are identified (although, in some examples, not shown) by reference designators in the exemplary drawings. However, the features in different implementations may be different in other respects, and therefore shall not be narrowly confined to what is shown in the drawings.

The phrases “in one implementation, ” and “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 via intervening components, and is not necessarily limited to physical connections. The term “comprising” may mean “including, but not necessarily limited to” and specifically indicate open-ended inclusion or membership in the disclosed combination, group, series, and equivalents.

The term “and/or” herein is only an association relationship for describing associated objects and represents that three relationships may exist, for example, A and/or B may represent that: A exists alone, A and B exist at the same time, and B exists alone. “A and/or B and/or C” may represent that at least one of A, B, and C exists, A and B exist at the same time, A and C exist at the same time, B and C exist at the same time, and A, B and C exist at the same time. Besides, the character “/” used herein generally represents that the former and latter associated objects are in an “or” relationship.

Additionally, any two or more of the following paragraphs, (sub) -bullets, points, actions, behaviors, terms, alternatives, examples, or claims in the present disclosure may be combined logically, reasonably, and properly to form a specific method. Any sentence, paragraph, (sub) -bullet, point, action, behavior, term, or claim in the present disclosure may be implemented independently and separately to form a specific method. Dependency, e.g., “based on” , “more specifically” , “preferably” , “In one embodiment” , “In one implementation” , “In one alternative” , in the present disclosure may refer to just one possible example that would not restrict the specific method.

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

Persons skilled in the art will recognize that any disclosed network function (s) or algorithm (s) may be implemented by hardware, software, or a combination of software and hardware. Disclosed functions may correspond to modules that may be software, hardware, firmware, or any combination thereof. The software implementation may comprise computer- executable instructions stored on a computer-readable medium, such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and carry out the disclosed network function (s) or algorithm (s) . The microprocessors or general-purpose computers may be formed of Application-Specific Integrated Circuits (ASICs) , programmable logic arrays, and/or using one or more Digital Signal Processors (DSPs) . Although some of the disclosed implementations are directed to software installed and executing on computer hardware, nevertheless, alternative implementations as firmware or as hardware or combination of hardware and software are well within the scope of the present disclosure.

The computer-readable medium may include, but may not be 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 (CD) 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 (e.g., a Long Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, an LTE-Advanced Pro system, or a New Radio (NR) system) may typically include at least one base station (BS) , at least one UE, and one or more optional network elements that provide connection with a network. The UE may communicate with the network (e.g., a Core Network (CN) , an Evolved Packet Core (EPC) network, an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) , a Next-Generation Core (NGC) , a 5G Core (5GC) , or an internet) via a Radio Access Network (RAN) established by one or more BSs.

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

A BS may include, but is not limited to, a node B (NB) as in the Universal Mobile Telecommunication System (UMTS) , an evolved node B (eNB) as in the LTE-A, a Radio Network Controller (RNC) as in the UMTS, a Base Station Controller (BSC) as in the Global System for Mobile communications (GSM) /GSM Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN) , a next-generation eNB (ng-eNB) as in an Evolved Universal Terrestrial Radio Access (E-UTRA) BS in connection with the 5GC, a next-generation Node B (gNB) as in the 5G-RAN (or in the 5G Access Network (5G-AN) ) , and any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may connect to serve the one or more UEs via a radio interface to the network.

A BS may be configured to provide communication services according to at least one of the following Radio Access Technologies (RATs) : Worldwide Interoperability for Microwave Access (WiMAX) , GSM (often referred to as 2G) , GERAN, General Packet Radio Service (GRPS) , UMTS (often referred to as 3G) according to basic Wideband-Code Division Multiple Access (W-CDMA) , High-Speed Packet Access (HSPA) , LTE, LTE-A, enhanced LTE (eLTE) , NR (often referred to as 5G) , and/or LTE-A Pro. However, the scope of the present disclosure is not limited to these protocols.

The BS may be operable to provide radio coverage to a specific geographical area using a plurality of cells forming the RAN. The BS may support the operations of the cells. Each cell may be operable to provide services to at least one UE within its radio coverage. More specifically, each cell (often referred to as a serving cell) may provide services to serve one or more UEs within its radio coverage (e.g., each cell schedules the downlink (DL) and optionally UL resources to at least one UE within its radio coverage for DL and optionally UL packet transmissions) . The BS may 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) , LTE SL services, and LTE/NR Vehicle-to-Everything (V2X) services. Each cell may have overlapped coverage areas with other cells. In Multi-RAT Dual Connectivity (MR-DC) cases, the primary cell of a Master Cell Group (MCG) or a Secondary Cell Group (SCG) may be called as a Special Cell (SpCell) . A Primary Cell (PCell) may refer to the SpCell of an MCG. A Primary SCG Cell (PSCell) may refer to the SpCell of an SCG. MCG may refer to a group of serving cells associated with the Master Node (MN) , comprising the SpCell and optionally one or more Secondary Cells (SCells) . An SCG may refer to a group of serving cells associated with the Secondary Node (SN) , comprising the SpCell and optionally one or more SCells.

As disclosed previously, the frame structure for NR is to support flexible configurations for accommodating various next-generation (e.g., 5G) communication requirements, such as eMBB, mMTC, and URLLC, while fulfilling high reliability, high data rate, and low latency requirements. The orthogonal frequency-division multiplexing (OFDM) technology, as agreed in the 3rd Generation Partnership Project (3GPP) , may serve as a baseline for an NR waveform. The scalable OFDM numerology, such as the adaptive sub-carrier spacing, the channel bandwidth, and the cyclic prefix (CP) , may also be used. Additionally, two coding schemes are applied for NR: (1) low-density parity-check (LDPC) code and (2) polar code. The coding scheme adaption may be configured based on the channel conditions and/or the service applications.

Moreover, in a transmission time interval of a single NR frame, at least DL transmission data, a guard period, and UL transmission data should be included. The respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable, for example, based on the network dynamics of NR. An SL resource may also be provided via an NR frame to support ProSe services or V2X services.

LTE MBMS

LTE Multimedia Broadcast Multicast Service (MBMS) aims to provide an efficient mode of delivery for both broadcast and multicast services over the core network. Typically, broadcast service is provided via a DL-only point-to-multipoint transmission from the network to multiple UEs. The content of broadcast service is transmitted once to all UEs in a geographical area, and UEs are free to choose whether or not to receive the broadcast service. On the other hand, multicast service is provided via a DL-only point-to-multipoint transmission from the network to a managed group of UEs. The content of multicast service is transmitted once to the whole group, and only the UEs belonging to the managed group can receive the multicast service.

A UE can receive MBMS (from the network) in RRC_IDLE state. Alternatively, a UE can receive MBMS (from the network) in RRC_CONNECTED state (if the UE is not a Narrow Band Internet of Things (NB-IoT UE) , Bandwidth reduced Low complexity (BL) UE or UE in enhanced coverage) .

Transmission of a MBMS in E-UTRAN uses either Multicast Broadcast Single Frequency Network (MBSFN) transmission or Single Cell Point to Multipoint (SC-PTM) transmission. A Multi-cell/multicast Coordination Entity (MCE) makes the decision on whether to use SC-PTM or MBSFN for each MBMS session.

LTE MBMS transmitted via MBSFN transmission

MBSFN transmission includes the following characteristics:

Characteristic 1: Synchronous transmission of MBMS within corresponding MBSFN Area;

Specifically, a geographical area of the network where MBMS can be transmitted is called an MBMS Service Area.

Specifically, a geographical area where all eNBs can be synchronized and can perform MBSFN transmissions is called an MBSFN Synchronization Area.

Specifically, all eNBs in a given MBSFN Synchronization Area have a synchronized radio frame timing such that the radio frames are transmitted at the same time with the same system frame number (SFN) .

Specifically, the area within an MBSFN Synchronization Area, covered by a group of cells participating in an MBSFN transmission, is called an MBSFN Area. An MBSFN Synchronization Area may support several MBSFN Areas. Moreover, a cell within an MBSFN Synchronization Area may form a part of multiple MBSFN Areas, where each MBSFN Area is characterized by a MBMS transmitted content and a set of participating cells.

Characteristic 2: Combining of MBMS transmission from multiple cells is supported;

Characteristic 3: Scheduling of each Multicast Channel (MCH) is determined by the MCE;

Specifically, all eNBs have the same configuration of radio link control (RLC) layer/Medium Access Control (MAC) layer /Physical (PHY) layer for each MBMS service, and identical information (e.g., time information, transmission order/priority information) such that synchronized MCH scheduling in the eNBs is ensured. These configuration and information are indicated in advance by the MCE.

Specifically, MCH is mapped to Physical Multicast Channel (PMCH) .

Specifically, SIB2 defines the subframes that includes resources for MBSFN transmission in DL (e.g., MBSFN subframe) . In other words, an MBSFN subframe is the subframe that includes the PMCH resource.

Specifically, the MBSFN subframes indicated by SIB2 can be used by all MBSFN areas.

Specifically, in an MBSFN subframe (e.g., a subframe that includes resources for MBSFN transmissions) , the MCH uses all the resources in the frequency domain, so MCH-related scheduling only relates to the subframe allocation in the time domain.

Specifically, MBMS does not use the PDCCH for dynamic scheduling.

Characteristic 4: Multicast Traffic Channel (MTCH) and Multicast Control Channel (MCCH) are logical channels used for transmission of MBMS with MBSFN;

Specifically, MTCH and MCCH can be multiplexed on the same MCH and are mapped on MCH for point-to-multipoint transmission. Moreover, MTCH and/or MCCH can be mapped on a Multimedia Broadcast Multicast Service Point to Multipoint Radio Bearer (MRB) .

Specifically, MRB is a radio bearer used for reception of MBMS service (transmitted via MBSFN transmission) .

Characteristic 5: A single Transport Block (TB) is used per Transmission Time Interval (TTI) for MCH transmission, that TB uses all the MBSFN resources in that subframe;

Characteristic 6: A single transmission is used for MCH;

Specifically, neither blind Hybrid Automatic Repeat Request (HARQ) repetitions nor RLC quick repeat is supported (for transmission on MCH) .

Characteristic 7: MTCH and MCCH use the RLC Unacknowledged Mode (UM) mode; and

Characteristic 8: The MAC subheader indicates the Logical Channel identity (LCID) for MTCH and MCCH.

Specifically, multiple MBMS services can be mapped to the same MCH and one MCH contains data belonging to only one MBSFN Area. An MBSFN Area contains one or more MCHs. An MCH specific MCS is used for all subframes of the MCH that do not use the MCS indicated in Broadcast Control Channel (BCCH) . All MCHs have the same coverage area.

Specifically, for MCCH and MTCH, the UE shall not perform RLC re-establishment at cell change between cells of the same MBSFN area. Within the MBSFN subframes, all MCHs within the same MBSFN area occupy a pattern of subframes, not necessarily adjacent in time, that is common for all these MCHs and is therefore called the Common Subframe Allocation (CSA) pattern. The CSA pattern is periodically repeated with the CSA period. The actual MCH subframe allocation (MSA) for every MCH carrying MTCH is defined by the CSA pattern, the CSA period, and the MSA end, that are all signaled on MCCH. The MSA end indicates the last subframe of the MCH within the CSA period. Consequently, the MCHs are time multiplexed within the CSA period that defines the interleaving degree between the MCHs. MCHs may not use all MBSFN resources signaled as a part of the MBSFN signaling defined in the 3GPP Rel-8. Further, such MBSFN resource can be shared for more than one purpose (e.g., MBMS, positioning) . During one MCH scheduling period (MSP) that is configurable per MCH, the eNB applies MAC multiplexing of different MTCHs and optionally MCCH to be transmitted on this MCH.

Specifically, MCH scheduling information (MSI) is provided per MCH to indicate which subframes are used by each MTCH during the MSP, and to indicate whether transmission for an MTCH is going to be, or has been, suspended by the eNB. The following principles are used for the MSI.

Principle 1: The MSI is used when services are multiplexed onto the MCH and when only a single service is transmitted on the MCH;

Principle 2: The MSI is generated by the eNB and provided once at the beginning of the MSP;

Principle 3: The MSI has higher scheduling priority than the MCCH, and, when needed, the MSI appears first in a Protocol Data Unit (PDU) ;

Principle 4: The MSI allows the receiver to determine what subframes are used by every MTCH, sessions are scheduled in the order in which MTCH are included in the MCCH session list;

Principle 5: The MSI is carried in a MAC control element that cannot be segmented;

Principle 6: The MSI carries the mapping of MTCHs to the subframes of the associated MSP. This mapping is based on the indexing of subframes belonging to one MSP; and

Principle 7: The MSI carries an indication of whether the transmission of an MTCH is to be suspended by the eNB.

LTE MBMS transmitted via SC-PTM transmission

SC-PTM transmission includes the following characteristics:

Characteristic 1: MBMS is transmitted in the coverage of a single cell;

Characteristic 2: One Single Cell Multicast Control Channel (SC-MCCH) and one or more SC-MTCH (s) can be mapped on DL-SCH;

Specifically, DL-SCH is mapped to PDSCH.

Specifically, SC-MCCH and SC-MTCH are logical channels.

Specifically, SC-MCCH is a point-to-multipoint downlink channel used for transmitting MBMS control information (e.g., SCPTMConfiguration message) from the network to the UE, for one or several SC-MTCHs. This channel is used by UEs that receive or are interested in receiving MBMS via SC-PTM.

Specifically, SC-MTCH is a point-to-multipoint downlink channel used for transmitting traffic data from the network to the UE via SC-PTM transmission. This channel is used by UEs that receive MBMS via SC-PTM.

Characteristic 3: SC-MCCH and/or SC-MTCH can be mapped on SC-MRB;

Specifically, SC-MRB is a radio bearer used for reception of MBMS service (transmitted via SC-PTM transmission) .

Characteristic 4: Scheduling is determined by the eNB;

Characteristic 5: SC-MCCH and SC-MTCH transmissions (e.g., PDSCH used for transmission of SC-MCCH information and PDSCH used for transmission of SC-MTCH information) are scheduled/indicated by a logical channel specific Radio Network Temporary Identifier (RNTI) on PDCCH (e.g., a one-to-one mapping between Temporary Mobile Group Identity (TMGI) and Group Radio Network Temporary Identifier (G-RNTI) used for the reception of the DL-SCH to which a SC-MTCH is mapped) ;

Specifically, PDCCH (DCI) associated (e.g., CRC scrambled) with SC-RNTI can be used to indicate the transmission of SC-MCCH (e.g., the PDSCH on which SC-MCCH is mapped) .

Specifically, PDCCH (DCI) associated (e.g., CRC scrambled) with G-RNTI can be used to indicate the transmission of a SC-MTCH (e.g., the PDSCH on which SC-MTCH is mapped) .

Specifically, the value of SC-RNTI is set with a value of FFFB.

Specifically, the value of a G-RNTI and a mapping (e.g., one-to-one mapping) between the G-RNTI and the corresponding TMGI/MBMS session is indicated via SCPTMConfiguration message (e.g., SC-MCCH) . A single SCPTMConfiguration message can indicate a list of one or multiple G-RNTIs and the corresponding TMGIs/MBMS sessions.

Characteristic 6: A single transmission is used for DL-SCH (e.g., neither blind HARQ repetitions nor RLC quick repeat) on which SC-MCCH or SC-MTCH is mapped; and

Characteristic 7: SC-MCCH and SC-MTCH use the RLC-UM.

LTE MBMS signaling on BCCH (e.g., SIB)

BCCH only points to the resources where the MCCH (s) /SC-MCCH can be found. In other words, BCCH does not indicate the availability of the services.

For each MCCH, BCCH indicates independently the scheduling of the MCCH for multi-cell transmission on MCH, the MCCH modification period, repetition period radio frame offset and subframe allocation, an MCS that applies for the subframes indicated for MCCH scheduling and for the first subframe of all MSPs in that MBSFN Area.

For the notification commonly used for all MCCH, BCCH configures the position of the MCCH change notification subframe and the number of occasions monitored by the UE, indicates the mapping between the PDCCH bit (s) carried in the notification and the MCCH (s) .

BCCH indicates the SC-MCCH modification period, SC-MCCH repetition period and SC-MCCH subframe offset.

LTE MCCH information validity and notification of changes

Change of MCCH information occurs at specific radio frames. In other words, the concept of a modification period is applied. Within the modification period, the same MCCH information may be transmitted a number of times, as defined by its scheduling that is based on a repetition period. The modification period boundaries are defined by SFN values for which SFN mod m= 0, where ‘m’ is the number of radio frames including the modification period. The modification period is configured via SystemInformationBlockType13.

When the network changes (some of) the MCCH information, the network notifies the UEs about the change during a first modification period. In the next modification period, the network transmits the updated MCCH information. Upon receiving a change notification, the UE interested in receiving MBMS services acquires the new MCCH information immediately from the start of the next modification period. The UE applies the previously acquired MCCH information until the UE acquires the new MCCH information.

Indication of an MBMS specific RNTI, namely M-RNTI, on PDCCH is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about an MCCH information change. When receiving an MCCH information change notification, the UE knows that the MCCH information will be changed at the next modification period boundary. The notification on PDCCH indicates the MCCHs that will be changed, which may be indicated by an 8-bit bitmap. Within this bitmap, the bit at the position indicated by the notificationIndicator field is used to indicate changes for that MBSFN area. If the bit is set to ‘1’ , the corresponding MCCH will be changed. The MCCH information change notification is used to inform the UE about a change of MCCH information upon session start or about the start of MBMS counting.

LTE SC-MCCH information validity and notification of changes

Change of SC-MCCH information occurs at specific radio frames. In other words, the concept of a modification period is applied. Within a modification period, the same SC-MCCH information may be transmitted a number of times, as defined by its scheduling that is based on a repetition period. The modification period boundaries are defined by SFN values for which SFN mod m= 0, where ‘m’ is the number of radio frames comprising the modification period. The modification period is configured via SystemInformationBlockType20.

When the network changes (some of) the SC-MCCH information, the network notifies the UEs, other than BL UEs, UEs in CE or NB-IoT UEs, about the change in the first subframe that can be used for SC-MCCH transmission in a repetition period. LSB bit in 8-bit bitmap set to ‘1’ indicates the change in SC-MCCH. Upon receiving a change notification, a UE interested in receiving MBMS services transmitted via SC-PTM acquires the new SC-MCCH information starting from the same subframe. The UE applies the previously acquired SC-MCCH information until the UE acquires the new SC-MCCH information.

When the network changes (some of) the SC-MCCH information for start of new MBMS service (s) transmitted via SC-PTM, the network notifies BL UEs, UEs in CE or NB-IoT UEs about the change in every PDCCH that schedules the first SC-MCCH in a repetition period in the current modification period. The notification is transmitted with 1 bit. The bit set to ‘1’ indicates the start of the new MBMS service (s) . Upon receiving a change notification, a BL UE, UE in CE or NB-IoT UE interested in receiving MBMS services transmitted via SC-PTM acquires the new SC-MCCH information scheduled by the PDCCH. The BL UE, UE in CE or NB-IoT UE applies the previously acquired SC-MCCH information until the BL UE, UE in CE or NB-IoT UE acquires the new SC-MCCH information.

LTE MRB establishment procedure and MRB release procedure

The UE applies the MRB establishment procedure to start receiving a session of a service that the UE has interested in. The MRB establishment procedure may be initiated upon the start of the MBMS session, upon (re-) entry of the corresponding MBSFN area, upon becoming interested in the MBMS service, or upon removal of UE capability limitations inhibiting reception of the concerned service.

For the MRB establishment procedure, the UE shall perform at least one of the following actions:

Action 1: Establish an RLC entity in accordance with the MCCH and MTCH configuration, as specified in Table 1;

Action 2: Configure an MTCH logical channel in accordance with the received locgicalChannelIdentity applicable for the MRB, as included in the MBSFNAreaConfiguration message;

Action 3: Configure the physical layer in accordance with the pmch-Config applicable for the MRB, as included in the MBSFNAreaConfiguration message; and

Action 4: Inform an upper layer (e.g., non-access stratum (NAS) layer) about the establishment of the MRB by indicating the corresponding TMGI and sessionId.

Table 1

The UE applies the MRB release procedure to stop receiving a session. The MRB release procedure may be initiated upon stop of the MBMS session, upon leaving the corresponding MBSFN area, upon losing interest in the MBMS service, or when capability limitations start inhibiting reception of the concerned service.

For the MRB release procedure, the UE shall perform at least one of the following actions:

Action 1: Release the RLC entity as well as the related MAC and physical layer configuration; and

Action 2: Inform an upper layer (e.g., NAS layer) about the release of the MRB by indicating the corresponding TMGI and sessionId.

LTE SC-MRB establishment procedure and SC-MRB release procedure

The UE applies the SC-MRB establishment procedure to start receiving a session of a MBMS service that the UE has interested in. The SC-MRB establishment procedure may be initiated upon the start of the MBMS session, upon entering a cell providing via SC-MRB a MBMS service in which the UE has interested, upon becoming interested in the MBMS service, or upon removal of UE capability limitations inhibiting reception of the concerned service.

For the SC-MRB establishment procedure, the UE shall perform at least one of the following actions:

Action 1: Establish an RLC entity in accordance with the SC-MCCH and SC-MTCH configuration, as specified in Table 2;

Action 2: Configure a SC-MTCH logical channel applicable for the SC-MRB and instruct MAC to receive DL-SCH on the cell where the SCPTMConfiguration message was received for the MBMS service for which the SC-MRB is established and using G-RNTI and sc-mtch-SchedulingInfo (if included) in this message for this MBMS service;

Action 3: Configure the physical layer in accordance with the sc-mtch-InfoList applicable for the SC-MRB, as included in the SCPTMConfiguration message; and

Action 4: Inform upper layers about the establishment of the SC-MRB by indicating the corresponding TMGI and sessionId.

Table 2

Name	Value
PDCP configuration	N/A

RLC configuration	UM
sn-FieldLength	Size5
t-Reordering	0

The UE applies the SC-MRB release procedure to stop receiving a session. The SC-MRB release procedure may be initiated upon stop of the MBMS session, upon leaving the cell where a SC-MRB is established, upon losing interest in the MBMS service, or when capability limitations start inhibiting reception of the concerned service.

For the SC-MRB release procedure, the UE shall perform at least one of the following actions:

Action 2: Inform an upper layer (e.g., NAS layer) about the release of the SC-MRB by indicating the corresponding sessionId.

NR SIB validity

The UE shall acquire system information (SI) by applying the SI acquisition procedure upon cell selection (e.g. upon power on) , cell-reselection, return from out of coverage, after reconfiguration with synchronization completion, after entering the network from another RAT, upon receiving an indication that the system information has changed, upon receiving a Public Warning System (PWS) notification, or when the UE does not have a valid version of a stored SIB.

When the UE acquires a MIB, a SIB1, or an SI message in a serving cell based on the SI acquisition procedure, and if the UE stores the acquired SIB, the UE shall store at least one of the associated areaScope, the first PLMN-Identity in the PLMN-IdentityInfoList, the cellIdentity, the systemInformationAreaID, and the valueTag, as indicated in the si-SchedulingInfo for the SIB. The UE may use a valid stored version of the SI except MIB, SIB1, SIB6, SIB7 or SIB8 after cell re-selection, upon return from out of coverage, or after the reception of SI change indication.

The UE shall perform the following actions:

1> delete any stored version of a SIB after 3 hours from the moment it was successfully confirmed as valid;

1> For each stored version of a SIB:

2> if the areaScope is associated and its value for the stored version of the SIB is the same as the value received in the si-SchedulingInfo for that SIB from the serving cell:

3> if the first PLMN-Identity included in the PLMN-IdentityInfoList, the systemInformationAreaID and the valueTag that are included in the si-SchedulingInfo for the SIB received from the serving cell are identical to the PLMN-Identity, the systemInformationAreaID and the valueTag associated with the stored version of that SIB:

4> consider the stored SIB as valid for the cell;

2> if the areaScope is not present for the stored version of the SIB and the areaScope value is not included in the si-SchedulingInfo for that SIB from the serving cell:

3> if the first PLMN-Identity in the PLMN-IdentityInfoList, the cellIdentity and valueTag that are included in the si-SchedulingInfo for the SIB received from the serving cell are identical to the PLMN-Identity, the cellIdentity and the valueTag associated with the stored version of that SIB:

4> consider the stored SIB as valid for the cell.

NR broadcast/multicast services are introduced in NR Rel-17. Service continuity of broadcast/multicast services across multiple cells is disclosed.

If NR broadcast/multicast service adopts LTE-based MBSFN transmission as a baseline, the serving continuity may be guaranteed because LTE-based MBSFN transmission already supports service continuity across several cells. For LTE-based MBSFN transmission, the synchronous transmission of broadcast/multicast service within a geographical area (e.g., MBSFN synchronization area) that includes one or multiple cells/gNBs is supported. Moreover, all the cells/gNBs within the geographical area may have a synchronized radio frame timing, such that the radio frames are transmitted at the same time with the same SFN.

However, if NR broadcast/multicast service adopts LTE-based SC-PTM transmission as a baseline, new mechanisms may be required to ensure service continuity across multiple cells. The reason is that LTE-based SC-PTM transmission does not support service continuity across multiple cells. Hence, if a UE has established SC-MRB under a cell for the reception of broadcast/multicast service (s) via LTE-based SC-PTM transmission, the UE needs to apply a SC-MRB release procedure upon leaving the cell (e.g., due to cell re-selection, handover, etc. ) . Subsequently, if the UE is still interested in receiving broadcast/multicast service (s) after entering a new/target cell (e.g., target cell) , the UE may need to apply a new SC-MRB establishment procedure to establish SC-MRB at the new/target cell (e.g., target cell) .

To improve service continuity of NR broadcast/multicast service (s) via LTE-based SC-PTM transmission, some new conditions are introduced in the present disclosure to release the NR broadcast/multicast service radio bearer. A NR broadcast/multicast service radio bearer may also be referred to as a multicast broadcast service (MBS) radio bearer or a NR MBS radio bearer. It is noted that the introduced mechanisms may not be limited to NR system. It may also be applied to LTE system.

Mechanisms to support service continuity of broadcast/multicast service

In some implementations, the UE may perform a NR broadcast/multicast service radio bearer release procedure to release a NR broadcast/multicast service radio bearer established in a cell (e.g., the cell 1) when at least one of the following conditions (e.g., condition 1 and condition 2) has been satisfied.

Condition 1: Upon the UE enters a new/target cell (e.g., the cell 2)

In LTE, the established radio bearers (e.g., SC-MRB) under a cell for the reception of broadcast/multicast service (s) via LTE-based SC-PTM transmission may be released by the UE when leaving the cell due to cell re-selection, handover, etc. However, based on condition 1, the UE is allowed to keep the established NR broadcast/multicast service radio bearer under a cell when the UE leaves the cell (e.g., the cell 1) . In other words, the UE may not perform the NR broadcast/multicast service radio bearer release procedure (e.g., SC-MRB release procedure) when leaving the cell (e.g., the cell 1) . Instead, the radio bearer release procedure (e.g., SC-MRB release procedure) may be performed when the UE enters a new/target cell (e.g., the cell 2) .

In one example, the UE may enter a new/target cell (e.g., the cell 2) upon performing connection with the new/target cell (e.g., the cell 2) , upon cell-reselection, after reconfiguration with sync completion (e.g., after completion of handover) , etc.

Moreover, based on condition 1, the UE is enabled to check whether a new/target cell that the UE enters (e.g., the cell 2) also supports (the same) broadcast/multicast service. If the new/target cell that the UE enters (e.g., the cell 2) also supports (the same) broadcast/multicast service (e.g., the SC-MCCH related information or the broadcast/multicast service related SIB provided by the new/target cell indicates the supporting of the broadcast/multicast service) , the UE may not re-establish the NR broadcast/multicast service radio bearer (e.g., perform a NR broadcast/multicast service radio bearer establishment procedure) after entering the new/target cell (e.g., the cell 2) .

In some implementations, the UE may determine whether to re-establish the NR broadcast/multicast service radio bearer (e.g., perform a NR broadcast/multicast service radio bearer establishment procedure) after entering the new/target cell (e.g., the cell 2) based on the received dedicated signaling (e.g., a RRC message) or based on the received system information.

In some implementations, the UE may release the NR broadcast/multicast service radio bearer that was established at the old/source cell (e.g., the cell 1) when entering a new/target cell (e.g., the cell 2) .

In some implementations, the UE may release the NR broadcast/multicast service radio bearer that was established at the old/source cell (e.g., the cell 1) when entering a new/target cell (e.g., the cell 2) and at least one of the following criteria have been satisfied:

Criterion 1: The specific SIB (s) stored at the UE is not considered valid at the new/target cell (e.g., the cell 2) ; and

In some implementations, the specific SIB (s) may be referred to as the SIB (s) that includes information related to broadcast/multicast configuration.

In one example, the specific SIB (s) may include the information required to acquire the control information associated with the transmission of broadcast/multicast service (e.g., SIB20) .

In one example, the information required to acquire the control information associated with the transmission of broadcast/multicast service (e.g., SIB20) may include the time/frequency domain occasion of the resource where the control information is monitored.

In one example, the control information associated with the transmission of broadcast/multicast service may include information required to receive the broadcast/multicast service (e.g., SCPTMConfiguration message) , such as the scheduling information of the broadcast/multicast service (e.g., the identity of the broadcast/multicast service, the time/frequency domain occasion where the broadcast/multicast service may be scheduled, the RNTI associated with the DL assignment that schedules the broadcast/multicast service, the DRX information for the broadcast/multicast service, the BWP information (e.g., BWP ID) where the broadcast/multicast service is scheduled.

In some implementations, when entering the new/target cell (e.g., the cell 2) , the UE may determine whether the specific SIB that the UE stores is valid at the new/target cell (e.g., the cell 2) (e.g., based on the receive system information of the target cell via the SI acquisition procedure and/or based on the system information of the target cell received via the dedicated RRC signaling) . If the UE determines that the specific SIB that the UE stores is valid at the new/target cell (e.g., the cell 2) , the UE may not release the NR broadcast/multicast service radio bearer established at the old cell (e.g., the cell 1) . In contrast, if the UE determines that the specific SIB that the UE stores is invalid at the new/target cell (e.g., the cell 2) , the UE may release the NR broadcast/multicast service radio bearer established at the old cell (e.g., the cell 1) .

In some implementations, during/before the SI acquisition procedure, the UE may check whether the areaScope is associated/configured and the value for the stored version of the SIB is the same as the value received in the si-SchedulingInfo for the specific SIB from the new/target cell (e.g., the cell 2) . If so, the UE may further check whether first PLMN-Identity included in the PLMN-IdentityInfoList, the systemInformationAreaID and the valueTag that are included in the si-SchedulingInfo for the specific SIB received from the new serving cell (e.g., the cell 2) are identical to the PLMN-Identity, the systemInformationAreaID and the valueTag associated with the stored version of the specific SIB. If so, the UE may consider the specific SIB as valid at the new/target cell (e.g., the cell 2) .

In some implementations, if the UE does not have a valid version of a stored SIB, the UE may apply the SI acquisition procedure or apply the on-demand SI request procedure.

Criterion 2: The new/target cell (e.g., the cell 2) does not support multicast/broadcast service.

In some implementations, the new/target cell (e.g., the cell 2) may indicate a capability/assistance information to the served UE. The capability/assistance information may indicate whether the network supports (a specific) broadcast/multicast service.

In some implementations, the new/target cell (e.g., the cell 2) may transmit an indication to the served UE via broadcast system information (e.g., SIB1, SIB2, SIB20, etc. ) .

In some implementations, the new/target cell (e.g., the cell 2) may transmit a capability indication to the served UE via dedicated signaling (e.g., RRC signaling) (e.g., for UE (s) in RRC_CONNECTED state) .

In some implementations, the capability indication may be a flag, an enumerate format (e.g., ENUMERATE {TRUE} , ENUMERATE {TRUE, FALSE} ) , a bit indication, etc. For example, a value “0” may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell. In contrast, a value “1” may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell.

In some implementations, the capability indication may be a “TRUE” indication. For example, if this capability indication is present (and with a value “TRUE” ) , (a specific) broadcast/multicast service is supported for the corresponding serving cell. In contrast, the absence (or a value “FALSE” ) of this capability indication value (for a period) may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell.

In some implementations, when a UE enters a new/target cell, the UE may determine whether the new/target cell (e.g., the cell 2) supports multicast/broadcast service based on the presence of a specific broadcast system information (e.g., SIB20) . Specifically, the absence of a specific broadcast system information at the new/target cell (e.g., the cell 2) (for a period) may imply that multicast/broadcast service is not supported at the new/target cell (e.g., cell 2) .

In some implementations, the old/source cell (e.g., the cell 1) may indicate that the new/target cell (e.g., the cell 2) does not support (a specific) broadcast/multicast service. An indication may be provided via neighboring cell information. In other words, the old/source cell (e.g., the cell 1) may provide neighboring cell information to indicate whether and/or which specific broadcast/multicast service is supported by its neighboring cells.

In one example, the UE may release (all) NR broadcast/multicast service radio bearer (s) , which was established at the old/source cell (e.g., the cell 1) , when entering a new/target cell (e.g., the cell 2) that does not support multicast/broadcast service. In contrast, the UE may not release (any) NR broadcast/multicast service radio bearer of a certain service, which was established at the old/source cell (e.g., the cell 1) , when entering a new/target cell (e.g., the cell 2) that supports multicast/broadcast the service.

In one example, the UE may release the NR broadcast/multicast service radio bearer that corresponds to a broadcast/multicast service, which was established at the old/source cell (e.g., the cell 1) , when entering a new/target cell (e.g., the cell 2) that does not support the corresponding multicast/broadcast service. In contrast, the UE may not release the NR broadcast/multicast service radio bearer that corresponds to a specific service, which was established at the old/source cell (e.g., the cell 1) , when entering a new/target cell (e.g., the cell 2) that supports the corresponding multicast/broadcast the service.

Condition 2: The UE has left an old/source cell (e.g., the cell 1) and specific criterion (s) has been satisfied

In LTE, the established radio bearers (e.g., SC-MRB) under a cell for the reception of broadcast/multicast service (s) via LTE-based SC-PTM transmission may always be released by the UE when leaving the cell (e.g., due to cell re-selection, handover, etc. ) . However, based on condition 2, the UE is allowed to release a NR broadcast/multicast service radio bearer, as established at a cell, when leaving the cell (e.g., the cell 1) only if some specific conditions have been satisfied.

In some implementations, the UE may be considered as leaving a cell due to UE mobility (e.g., the UE moves out of the cell coverage of the cell 1) , Radio Link Failure (RLF) , etc.

In some implementations, the UE may be considered as leaving a cell upon cell-reselection or upon the camping cell is changed.

In some implementations, the UE may be considered as leaving a cell if the UE performs reconfiguration with synchronization procedure (e.g., handover procedure) , etc.

In some implementation, the UE may be considered as leaving a cell after reconfiguration with synchronization completion or when receiving a reconfiguration with synchronization message.

In some implementations, if a UE has established a NR broadcast/multicast service radio bearer at a cell (e.g., the cell 1) , the UE may release the NR broadcast/multicast service radio bearer when leaving the cell (e.g., the cell 1) if at least one of following criteria has been satisfied:

Criterion 1: The neighboring cell (s) of the cell (e.g., the cell 1) that the UE leaves does not support (certain) broadcast/multicast service; and

In some implementations, the neighboring cell information of a cell may be indicated via broadcast system information (e.g., SIB) or dedicated signaling (e.g., RRC signaling) .

In some implementations, a list may be used to identify the neighboring cell (s) that support (or do not support) the broadcast/multicast service.

In some implementations, the list may include the identity (e.g., cell ID) of one or more neighboring cell (s) .

In some implementations, the list may be specific to a broadcast/multicast service (e.g., the list may identify the neighboring cell (s) that support (or do not support) a specific broadcast/multicast service) . In some implementations, elements in the list may include a cell ID, area ID, frequency ID, and/or a specific broadcast/multicast service ID (e.g., session ID) . An example of a list indicating neighboring cells that support NR broadcast/multicast service (s) is illustrated in Table 3 and Table 4.

Table 3

Service ID (e.g., session ID)	Neighboring cell IDs that support the service
Service#1	Cell#2, Cell#3
Service#2	Cell#2, Cell#4

Table 4

Neighboring Cell ID (e.g., session ID)	Services that are supported by the neighboring cell
Cell#2	Service#2, Service#3
Cell#3	Service#2, Service#4

In one example, if a UE has established a NR broadcast/multicast service radio bearer at a cell (e.g., the cell 1) , and the UE has been indicated by the cell 1 that none of the neighboring cells of the cell 1 supports NR broadcast/multicast service, the UE may release the NR broadcast/multicast service radio bearer when leaving the cell 1.

In one example, if a UE has established a NR broadcast/multicast service radio bearer at a cell (e.g., the cell 1) , and the UE has been indicated by the cell 1 that none of the neighboring cells of the cell 1 supports a certain NR broadcast/multicast service, the UE may release the NR broadcast/multicast service radio bearer of the NR broadcast/multicast service when leaving the cell 1.

Criterion 2: The handover command message does not include broadcast/multicast service information of the new/target cell.

Based on criterion 2, the UE leaves the old/source cell (e.g., the cell 1) to a new/target cell due to a handover procedure. It is noted that the UE may receive a RRCReconfiguration message (e.g., a handover command) from the old/source cell. Furthermore, the RRCReconfiguration message may include the information related to the new/target cell that the UE is intended to perform handover to. The information may include at least the following:

1. Radio bearer configuration to be used at the new/target cell;

Specifically, a radio bearer configuration to be used at the new/target cell may be included in RadioBearerConfig IE of the RRCReconfiguration message.

2. Cell-Radio Network Temporary Identifier (C-RNTI) value to be used at the new/target cell;

Specifically, the C-RNTI value to be used at the new/target cell may be included in ReconfigurationWithSync IE.

Specifically, ReconfigurationWithSync IE may be included in spCellConfig IE.

Specifically, spCellConfig IE may be included in CellGroupConfig IE of the RRCReconfiguration message.

3. Random access channel (RACH) configuration for performing RA with the new/target cell; and

Specifically, the RACH configuration for performing RA with the new/target cell may be a set of dedicated RACH resources.

Specifically, the association between RACH resources and SSB (s) and/or UE-specific CSI-RS may be provided.

4. SI of the new/target cell.

To support service continuity of NR broadcast/multicast service, a UE may not release a NR broadcast/multicast service radio bearer when performing handover to a new/target cell, if the UE determines that broadcast/multicast service is supported at the new/target cell. Furthermore, the UE may determine whether broadcast/multicast service is supported at the new/target cell based on the received RRCReconfiguration message as part of the handover procedure (e.g., the RRCReconfiguration message that includes a ReconfigurationWithSync IE) .

In some implementations, if a UE receives a RRCReconfiguration message as part of the handover procedure to a new/target cell (e.g., the RRCReconfiguration message that includes a ReconfigurationWithSync IE) , the UE may not release a NR broadcast/multicast service radio bearer if the RRCReconfiguration message includes at least one of the following information:

1. A configuration related to the broadcast/multicast service; and

In some implementations, a configuration that corresponds to the broadcast/multicast service may be the configuration related to the NR broadcast/multicast service radio bearer. Moreover, a configuration related to the NR broadcast/multicast service radio bearer may be the configuration that corresponds to a NR broadcast/multicast service radio bearer.

In some implementations, a configuration related to a NR broadcast/multicast service radio bearer may be the Service Data Adaptation Protocol (SDAP) (e.g., SDAP-Config IE) , PDCP (e.g., PDCP-Config IE) , RLC (e.g., RLC-BearerConfig IE, rlc-Config IE, etc. ) , and/or MAC configuration (e.g., mac-LogicalChannelConfig IE, LogicalChannelConfig IE, etc. ) that associates with the NR broadcast/multicast service radio bearer.

In one example, if a UE has established the NR broadcast/multicast service radio bearer 1 at an old/source cell (e.g., the cell 1) , the UE may determine whether the received RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) includes configurations related to the NR broadcast/multicast service radio bearer 1 when performing the handover procedure to the new/target cell. If so, the UE may not release NR broadcast/multicast service radio bearer that has been established at the source/old cell. Otherwise, the UE may release the NR broadcast/multicast service radio bearer 1 that has been established at the source/old cell. In one example, a configuration related to the NR broadcast/multicast service radio bearer 1 may be the SDAP, PDCP, RLC, and/or MAC configuration that associates with the NR broadcast/multicast service radio bearer 1.

2. An indication indicating whether (a specific) broadcast/multicast service is supported by the new/target cell.

In some implementations, the new/target cell may indicate whether the new/target cell supports (a specific) broadcast/multicast service via a capability indication.

In some implementations, the capability indication that is signaled by the new/target cell may be a flag, an enumerate format (e.g., ENUMERATE {TRUE} , ENUMERATE {TRUE, FALSE} ) , a bit indication, etc. For example, a value “0” may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell. In contrast, a value “1” may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell.

In some implementations, the capability indication that is signaled by the new/target cell may be a “TRUE” indication. For example, if the capability indication is presented (and with a value “TRUE” ) , (a specific) broadcast/multicast service is supported for the corresponding serving cell. In contrast, the absence (or a value “FALSE” ) of the capability indication value (for a period) may imply that (a specific) broadcast/multicast service is not supported for the corresponding serving cell.

In one example, if a UE has established NR broadcast/multicast service radio bearer (s) at an old/source cell (e.g., the cell 1) , the UE may determine whether broadcast/multicast service is supported at the new/target cell based on the capability indication included in the received RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) when performing the handover procedure to the new/target cell. If the UE determines that broadcast/multicast service is supported at the new/target cell, the UE may not release (all) the NR broadcast/multicast service radio bearer (s) that has been established at the source/old cell (e.g., the cell 1) . Otherwise, the UE may release (all) the NR broadcast/multicast service radio bearer (s) that has been established at the source/old cell (e.g., the cell 1) .

In some implementations, the new/target cell may identify the specific broadcast/multicast service that the new/target cell supports. For example, the new/target cell may indicate the broadcast/multicast session ID (e.g., an ID that identifies a broadcast/multicast session) and/or the mobile group identity (e.g., TMGI) of the broadcast/multicast service that the new/target cell supports.

In one example, if a UE has established NR broadcast/multicast service radio bearer (s) at an old/source cell (e.g., the cell 1) , the UE may determine whether a specific broadcast/multicast service is supported at the new/target cell based on the identification of the supported broadcast/multicast service in the received RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) when performing the handover procedure to the new/target cell. If the UE determines that a specific broadcast/multicast service is supported at the new/target cell, the UE may not release the NR broadcast/multicast service radio bearer (s) associated with the specific broadcast/multicast service. Otherwise, the UE may release the NR broadcast/multicast service radio bearer (s) associated with the specific broadcast/multicast service. It is noted that the NR broadcast/multicast service radio bearer (s) associated with the specific broadcast/multicast service may have been established at the source/old cell (e.g., the cell 1) before the handover procedure.

In some implementations, the new/target cell may identify the NR broadcast/multicast service radio bearer that the new/target cell supports. Specifically, the new/target cell may provide the identity (s) of the NR broadcast/multicast service radio bearer (s) that the new/target cell supports (or does not support) .

In some implementations, the identity (s) of the NR broadcast/multicast service radio bearer (s) that the new/target cell supports may be included in a list.

In some implementations, the identity (s) of the NR broadcast/multicast service radio bearer (s) that the new/target cell supports may be included in a specific IE. In one example, the specific IE may be referred to as the IE that is used for additional and/or reconfiguration of a NR broadcast/multicast service radio bearer.

In one example, if a UE has established NR broadcast/multicast service radio bearer (s) at an old/source cell (e.g., the cell 1) , the UE may determine whether a specific NR broadcast/multicast service radio bearer is supported at the new/target cell based on a list of the NR broadcast/multicast service radio bearer (s) that the new/target cell supports when performing the handover procedure to the new/target cell. Moreover, the list may be included in the RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) .

Alternatively, the UE may determine that a specific NR broadcast/multicast service radio bearer is supported at the new/target cell if the identity of the specific NR broadcast/multicast service radio bearer is included in a specific IE that is used for additional and/or reconfiguration of a NR broadcast/multicast service radio bearer. Moreover, the specific IE may be included in the RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) .

Alternatively, the UE may determine that a specific NR broadcast/multicast service radio bearer is not supported at the new/target cell if the identity of the specific NR broadcast/multicast service radio bearer is included in a specific IE that is used for releasing a NR broadcast/multicast service radio bearer. Moreover, the specific IE may be included in the RRCReconfiguration message of the handover procedure (e.g., RRCReconfiguration message that includes a ReconfigurationWithSync IE) .

In some implementations, if the UE determines that a specific NR broadcast/multicast service radio bearer (s) is supported at the new/target cell, the UE may not release the specific NR broadcast/multicast service radio bearer (s) when performing the handover procedure from the old/source cell to the new/target cell. Otherwise, the UE may release the specific NR broadcast/multicast service radio bearer (s) when performing the handover procedure from the old/source cell to the new/target cell. Moreover, the UE may establish a unicast radio bearer (e.g., DRB (s) that corresponds to the specific NR broadcast/multicast service radio bearer (s) that has been released. A mapping (e.g., one-to-one mapping) between the unicast radio bearer (e.g., DRB) and the corresponding NR broadcast/multicast service radio bearer may be provided by the network.

Condition 3: An old/source cell (e.g., the cell 1) no longer supports broadcast/multicast service

Based on condition 3, the UE may stay in the old/source cell (e.g., the cell 1) without performing mobility procedure.

In some implementations, the cell may indicate capability information to the served UE. The capability information may indicate whether the network supports (a specific) broadcast/multicast service.

In some implementations, the cell may transmit such an indication to the served UE via broadcast system information (e.g., SIB1, SIB2, etc. ) for UE (s) .

In some implementations, the network may transmit a capability indication to the served UE via dedicated signaling (e.g., RRC signaling) (for UE (s) in RRC_CONNECTED state) .

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports broadcast/multicast service via a capability indication, the UE may release (all) NR broadcast/multicast service radio bearer (s) .

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports a specific broadcast/multicast service via a capability indication, the UE may release the specific NR broadcast/multicast service radio bearer (s) .

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports broadcast/multicast service via a capability indication, the UE in RRC_IDLE may initiate a RRC connection establishment procedure and transit to RRC_CONNECTED to establish unicast bearer (e.g., DRB) for the continuation of the service.

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports broadcast/multicast service via a capability indication, the UE in RRC_IDLE may select another cell to camp (e.g., based on the system information) for continuation receiving data of the service. The system information may indicate which neighboring cell or carrier frequency supports the same service. In some examples, the UE may first try to select another cell to camp for continuation receiving data of the service. However, if there is no qualified cell to be reselected for continuously receiving data of the service, the UE may initiate a RRC connection establishment procedure and transit to RRC_CONNECTED to establish unicast bearer (e.g., DRB) for the continuation of the service.

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports broadcast/multicast service via a capability indication, the UE in RRC_INACTIVE may initiate a RRC connection resume procedure and transit to RRC_CONNECTED to establish unicast bearer (e.g., DRB) for the continuation of the service.

In one example, if the cell (e.g., the cell 1) indicates that the cell no longer supports broadcast/multicast service via a capability indication, the UE in RRC_INACTIVE may select another cell to camp (e.g., based on the system information) for continuously receiving data of the service. The system information may indicate which neighboring cell or carrier frequency supports the same service. In some examples, the UE may first try to select another cell to camp for continuation receiving data of the service. However, if there is no qualified cell to be reselected for continuously receiving data of the service, the UE may initiate a RRC connection establishment procedure and transit to RRC_CONNECTED to establish unicast bearer (e.g., DRB) for the continuation of the service.

NR broadcast/multicast service radio bearer release procedure

In some implementations, if the previously mentioned condition (s) for a UE to release a NR broadcast/multicast service radio bearer has been satisfied, the UE may perform the NR broadcast/multicast service radio bearer release procedure that includes at least one of the following actions. It is noted that a NR broadcast/multicast service radio bearer may be referred to as a bearer that is used for exchanging control signaling and/or data traffic that corresponds to a broadcast/multicast service with the network. In some implementations, a NR broadcast/multicast service radio bearer may be mapped to one or more LCHs. In some implementations, a NR broadcast/multicast service radio bearer may be associated with a PDCP, SDAP, RLC, MAC, and/or PHY entity/configuration) .

Action 1: Release the PDCP entity/configuration;

In some implementations, if a PDCP entity associated with a NR broadcast/multicast service radio bearer is configured, the UE may release the PDCP entity associated with the NR broadcast/multicast service radio bearer.

In some implementations, the PDCP entity is associated with a NR broadcast/multicast service radio bearer if the RLC entity associated with the NR broadcast/multicast service radio bearer is set to RLC AM or RLC UM.

Action 2: Release the SDAP entity/configuration;

In some implementations, if a SDAP entity associated with a NR broadcast/multicast service radio bearer is configured, the UE may release the SDAP entity associated with the NR broadcast/multicast service radio bearer.

Action 3: Release the RLC entity/configuration;

Action 4: Release the MAC entity/configuration;

Action 5: Release the PHY entity/configuration; and

Action 6: Inform an upper layer (e.g., NAS layer) about the release of the NR broadcast/multicast service radio bearer.

In some implementations, the UE may indicate the corresponding sessionId.

FIG. 1 is a flowchart illustrating a first method 100 for a UE to perform broadcast or multicast service, according to an implementation of the present disclosure. FIG. 1 illustrates the previously mentioned condition 2 where the UE has left an old/source cell and specific criterion (s) has been satisfied. In action 102, the UE establishes a MBS radio bearer corresponding to a first broadcast or multicast service on a first cell (e.g., an old/source cell or the cell 1) . In action 104, the UE leaves the first cell. In action 106, the UE releases the MBS radio bearer when at least one of conditions is fulfilled, the conditions including receiving, from the first cell, a first RRC signaling or first broadcast system information indicating none of neighboring cells of the first cell supports the first broadcast or multicast service, and receiving, from the first cell, a second dedicated RRC signaling for handover from the first cell to a second cell (e.g., a new/target cell or the cell 2) , the second dedicated RRC signaling indicating that the second cell does not support the first broadcast or multicast service.

In some examples, the UE may not release the MBS radio bearer when none of the conditions is fulfilled.

In some examples, the first dedicated RRC signaling or the first broadcast system information identifies at least one serving cell that supports a multicast service or a broadcast service.

In some examples, the second dedicated RRC signaling includes at least one of information for identifying a multicast service or a broadcast service supported by the second cell, and an indication for indicating whether a MBS is supported by the second cell.

In some examples, when the UE releases the MBS radio bearer, the UE may releasing a SDAP configuration associated with the MBS radio bearer, and informing, to the NAS layer, the releasing of the MBS radio bearer.

FIG. 2 is a flowchart illustrating a second method 200 for a UE to perform broadcast or multicast service, according to an implementation of the present disclosure. FIG. 2 illustrates the previously mentioned condition 1 where the UE enters a new/target cell. In action 202, the UE establishes a MBS radio bearer corresponding to a first broadcast or multicast service on a first cell (e.g., an old/source cell or the cell 1) . In action 204, the UE releases the MBS radio bearer after performing a cell selection, a cell reselection, or a handover to a second cell (e.g., a new/target cell or the cell 2) .

In some examples, the UE may release the MBS radio bearer after performing the cell selection, the cell reselection, or the handover to the second cell, and when at least one of the following conditions is fulfilled:

Condition 1: Determine that a stored SIB including information of the first broadcast or multicast service is not valid at the second cell; and

Condition 2: Receive, from the second cell, a dedicated radio resource control (RRC) signaling or broadcast system information indicating that the second cell does not support the first broadcast or multicast service.

In some examples, the UE may determine that the stored SIB is not valid at the second cell if a value of a areaScope IE in the stored SIB is not the same as a value of a areaScope IE broadcasted by the second cell.

In some examples, the UE may not re-establishing the MBS radio bearer for the first broadcast or multicast service when none of the conditions is fulfilled.

In some examples, when releasing the MBS radio bearer, the UE may release a SDAP configuration associated with the MBS radio bearer, and inform the NAS layer about the releasing of the radio bearer.

FIG. 3 is a flowchart illustrating a third method 300 for a UE to perform broadcast or multicast service, according to an implementation of the present disclosure. FIG. 3 illustrates the previously mentioned condition 3 where an old/source cell no longer supports broadcast/multicast service. In action 302, the UE establishes a MBS radio bearer corresponding to a first broadcast or multicast service on a first cell (e.g., an old/source cell or the cell 1) . In action 304, the UE receives, from the first cell, a dedicated RRC signaling or broadcast system information indicating that the first cell does not support the first broadcast or multicast service. In action 306, the UE releases the MBS radio bearer after receiving the dedicated RRC signaling or broadcast system information.

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

As illustrated in FIG. 4, the node 400 may include a transceiver 420, a processor 426, a memory 428, one or more presentation components 434, and at least one antenna 436. The node 400 may also include a Radio Frequency (RF) spectrum band module, a BS communications module, a network communications module, a system communications management module, input/output (I/O) ports, I/O components, and a power supply (not illustrated in FIG. 4) .

Each of these components may be in communication with each other, directly or indirectly, over one or more buses 440. The node 400 may be a UE or a BS that performs various disclosed functions illustrated in FIG. 1, FIG. 2 and FIG. 3 and examples in this disclosure.

The transceiver 420 may include a transmitter 422 (with transmitting circuitry) and a receiver 424 (with receiving circuitry) and may be configured to transmit and/or receive time and/or frequency resource partitioning information. The transceiver 420 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 400 may include a variety of computer-readable media. Computer-readable media may be any media that can be accessed by the node 400 and include both volatile (and non-volatile) media and removable (and non-removable) media. Computer-readable media may include computer storage media and communication media. Computer storage media may include both volatile (and/or non-volatile) , as well as removable (and/or non-removable) , media implemented according to any method or technology for storage of information such as computer-readable media.

Computer storage media may include RAM, ROM, EPROM, EEPROM, flash memory (or other memory technology) , CD-ROM, Digital Versatile Disk (DVD) (or other optical disk storage) , magnetic cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices) , etc. Computer storage media do not include a propagated data signal.

Communication media may 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 mechanisms and include any information delivery media. The term “modulated data signal” may mean 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 may 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 disclosed media should be included within the scope of computer-readable media.

The memory 428 may include computer-storage media in the form of volatile and/or non-volatile memory. The memory 428 may be removable, non-removable, or a combination thereof. For example, the memory 428 may include solid-state memory, hard drives, optical-disc drives, etc. As illustrated in FIG. 4, the memory 428 may store computer-readable and/or computer-executable instructions 432 (e.g., software codes) that are configured to, when executed, cause the processor 426 (e.g., processing circuitry) to perform various disclosed functions. Alternatively, the instructions 432 may not be directly executable by the processor 426 but may be configured to cause the node 400 (e.g., when compiled and executed) to perform various disclosed functions.

The processor 426 may include an intelligent hardware device, a central processing unit (CPU) , a microcontroller, an ASIC, etc. The processor 426 may include memory. The processor 426 may process the data 430 and the instructions 432 received from the memory 428, and information received through the transceiver 420, the baseband communications module, and/or the network communications module. The processor 426 may also process information to be sent to the transceiver 420 for transmission via the antenna 436, and/or to the network communications module for transmission to a CN.

One or more presentation components 434 may present data to a person or other devices. Presentation components 434 may include a display device, a speaker, a printing component, a vibrating component, etc.

From the present disclosure, it is evident that various techniques can be utilized for implementing the disclosed concepts without departing from the scope of those concepts. Moreover, while the concepts have been disclosed with specific reference to specific implementations, a person of ordinary skill in the art would recognize that changes can be made in form and detail without departing from the scope of those concepts. As such, the present disclosure is 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 specific disclosed implementations, but that many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.

Claims

A method of broadcast or multicast service for a user equipment (UE) , the method comprising:

establishing a multicast broadcast service (MBS) radio bearer corresponding to a first broadcast or multicast service on a first cell;

leaving the first cell; and

releasing the MBS radio bearer when at least one of conditions is fulfilled, wherein the conditions include:

receiving, from the first cell, a first dedicated radio resource control (RRC) signaling or first broadcast system information indicating none of neighboring cells of the first cell supports the first broadcast or multicast service, and

receiving, from the first cell, a second dedicated RRC signaling for handover from the first cell to a second cell, the second dedicated RRC signaling indicating that the second cell does not support the first broadcast or multicast service.
The method of claim 1, further comprising:

not releasing the MBS radio bearer when none of the conditions is fulfilled.
The method of claim 1, wherein the first dedicated RRC signaling or the first broadcast system information identifies at least one serving cell that supports a multicast service or a broadcast service.
The method of claim 1, wherein the second dedicated RRC signaling includes at least one of information for identifying a multicast service or a broadcast service supported by the second cell, and an indication for indicating whether a MBS is supported by the second cell.
The method of claim 1, wherein releasing the MBS radio bearer comprises at least one of:

releasing a service data adaptation protocol (SDAP) configuration associated with the MBS radio bearer, and

informing, to a non-access stratum (NAS) layer, the releasing of the MBS radio bearer.
A method of broadcast or multicast service for a user equipment (UE) , the method comprising:

establishing a multicast broadcast service (MBS) radio bearer corresponding to a first broadcast or multicast service on a first cell;

releasing the MBS radio bearer after performing a cell selection, a cell reselection, or a handover to a second cell;
The method of claim 6, wherein the releasing the MBS radio bearer comprises:

releasing the MBS radio bearer after performing the cell selection, the cell reselection, or the handover to the second cell, and when at least one of conditions is fulfilled, the conditions including:

determining that a stored system information block (SIB) including information of the first broadcast or multicast service is not valid at the second cell, and

receiving, from the second cell, a dedicated radio resource control (RRC) signaling or broadcast system information indicating that the second cell does not support the first broadcast or multicast service.
The method of claim 7, wherein determining that the stored SIB is not valid at the second cell comprises:

determining that the stored SIB is not valid at the second cell if a value of a areaScope information element (IE) in the stored SIB is not the same as a value of a areaScope IE broadcasted by the second cell.
The method of claim 7, further comprises:

not re-establishing the MBS radio bearer for the first broadcast or multicast service when none of the conditions is fulfilled.
The method of claim 7, wherein releasing the MBS radio bearer comprises at least one of:

releasing a service data adaptation protocol (SDAP) configuration associated with the MBS radio bearer, and

informing a non-access stratum NAS layer about the releasing of the radio bearer.
A method of broadcast or multicast service for a user equipment (UE) , the method comprising:

establishing a multicast broadcast service (MBS) radio bearer corresponding to a first broadcast or multicast service on a first cell;

receiving, from the first cell, a dedicated radio resource control (RRC) signaling or broadcast system information indicating that the first cell does not support the first broadcast or multicast service; and

releasing the MBS radio bearer after receiving the dedicated RRC signaling or broadcast system information.
The method of claim 11, wherein releasing the MBS radio bearer comprises at least one of:

releasing a service data adaptation protocol (SDAP) configuration associated with the MBS radio bearer, and

informing a non-access stratum NAS layer about the releasing of the radio bearer.
A user equipment (UE) for performing broadcast or multicast service, comprising:

a processor; and

a memory coupled to the processor, wherein the memory stores a computer-executable program that when executed by the processor, causes the processor to perform the method of any of claims 1 to 12.