WO2024130598A1

WO2024130598A1 - Notifying method of multicast session deactivation and apparatus

Info

Publication number: WO2024130598A1
Application number: PCT/CN2022/140749
Authority: WO
Inventors: Xin Zhang
Original assignee: Shenzhen Tcl New Technology Co., Ltd.
Priority date: 2022-12-21
Filing date: 2022-12-21
Publication date: 2024-06-27

Abstract

A notifying method of multicast session deactivation performed by a user equipment (UE) includes if the UE is in a radio resource control (RRC) inactive state and is configured to receive a multicast session in the inactive state, the UE is notified through a multicast/broadcast service (MBS) control channel (MCCH), an MCCH change notification, or a medium access control-control element (MAC CE) when the multicast session is deactivated.

Description

NOTIFYING METHOD OF MULTICAST SESSION DEACTIVATION AND APPARATUS

BACKGROUND OF DISCLOSURE

1. Field of the Disclosure

The present disclosure relates to the field of wireless communication systems such as multicast/broadcast service (MBS) systems, and more particularly, to notifying methods of multicast session deactivation and apparatuses.

2. Description of the Related Art

To enable resource-efficient delivery of multicast/broadcast services, 3GPP has developed NR broadcast/multicast in Rel-17 according to a work item (WID) , aiming to enable general MBS services over 5GS. The use cases identified that could benefit from this feature include public safety and mission critical, V2X applications, IPTV, live video, software delivery over wireless and IoT applications, etc. Two delivery modes have been agreed for Rel-17 MBS with delivery mode 1 (only for multicast) capable of addressing higher QoS services and delivery mode 2 (only for broadcast) focusing on lower QoS services. Given that Rel-17 MBS already provide the basic function to support MBS services, the general main goal for Rel-18 should be to enable better deployment of MBS, such as improvement of resource efficiency and capacity based on Rel-17 MBS.

In Rel-17, RAN only specifies multicast for UEs in RRC_CONNECTED state, which may not fully fulfil the requirements of, e.g., mission critical services, especially for cells with a large number of UEs according to TR 23.774. Also, to always keep UEs in RRC_CONNECTED state is not power efficient. It is therefore important to support multicast for UEs in RRC_INACTIVE.

In LTE SC-PTM, SC-PTM Stop Indication MAC CE was introduced to notify that the UE stops monitoring the PDCCH for a G-RNTI, whereby the MAC CE is multiplexed with SC-MTCH associated with the G-RNTI. This light-weight signalling could work under the restriction of one-to-one mapping between TMGI and G-RNTI. On the other hand, NR MBS allows many-to-one mapping between TMGI and G-RNTI, so the MAC CE, if introduced, needs to indicate the TMGI (s) which is deactivated. Since the MAC CE is sent together with MTCH, it’s expected to minimize the delay between the reception of last multicast data and the stop of MTCH monitoring.

Therefore, there is a need for notifying methods of multicast session deactivation and apparatuses.

SUMMARY

An object of the present disclosure is to propose notifying methods of multicast session deactivation and apparatuses, which can deal with the issue how the multicast session deactivation is notified to a UE in an RRC inactive state.

In a first aspect of the present disclosure, a notifying method of multicast session deactivation performed by a user equipment (UE) includes if the UE is in a radio resource control (RRC) inactive state and is configured to receive a multicast session in the inactive state, the UE is notified through a multicast/broadcast service (MBS) control channel (MCCH) , an MCCH change notification, or a medium access control-control element (MAC CE) when the multicast session is deactivated.

In a second aspect of the present disclosure, a user equipment (UE) comprises a memory, a transceiver, and a processor coupled to the memory and the transceiver. The processor is configured to perform the above method.

In a third aspect of the present disclosure, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above method.

In a fourth aspect of the present disclosure, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above method.

In a fifth aspect of the present disclosure, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above method.

In a sixth aspect of the present disclosure, a computer program product includes a computer program, and the computer program causes a computer to execute the above method.

In a seventh aspect of the present disclosure, a computer program causes a computer to execute the above method.

BRIEF DESCRIPTION OF DRAWINGS

In order to illustrate the embodiments of the present disclosure or related art more clearly, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

FIG. 1 is a block diagram of one or more user equipments (UEs) and a base station (e.g., gNB) of communication in a communication network system according to an embodiment of the present disclosure.

FIG. 2 is a flowchart illustrating a notifying method of multicast session deactivation performed by a user equipment (UE) according to an embodiment of the present disclosure.

FIG. 3 is a flowchart illustrating a notifying method of multicast session deactivation according to an embodiment of the present disclosure.

FIG. 4 is a block diagram of a system for wireless communication according to an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the present disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

In some embodiments of this disclosure, we are going to deal with the issue how a multicast session deactivation is notified to a UE in an RRC inactive state.

FIG. 1 illustrates that, in some embodiments, one or more user equipments (UEs) 10 and a base station (e.g., gNB) 20 for communication in a communication network system 40 according to an embodiment of the present disclosure are provided. The communication network system 40 includes the one or more UEs 10 and the base station 20. The one or more UEs 10 may include a memory 12, a transceiver 13, and a processor 11 coupled to the memory 12 and the transceiver 13. The base station 20 may include a memory 22, a transceiver 23, and a processor 21 coupled to the memory 22 and the transceiver 23. The

processor

11 or 21 may be configured to implement proposed functions, procedures and/or methods described in this description. Layers of radio interface protocol may be implemented in the

processor

11 or 21. The

memory

12 or 22 is operatively coupled with the

processor

11 or 21 and stores a variety of information to operate the

processor

11 or 21. The

transceiver

13 or 23 is operatively coupled with the

processor

11 or 21, and the

transceiver

13 or 23 transmits and/or receives a radio signal.

The

processor

11 or 21 may include application-specific integrated circuit (ASIC) , other chipset, logic circuit and/or data processing device. The

memory

12 or 22 may include read-only memory (ROM) , random access memory (RAM) , flash memory, memory card, storage medium and/or other storage device. The

transceiver

13 or 23 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the

memory

12 or 22 and executed by the

processor

11 or 21. The

memory

12 or 22 can be implemented within the

processor

11 or 21 or external to the

processor

11 or 21 in which case those can be communicatively coupled to the

processor

11 or 21 via various means as is known in the art. Further, in some embodiments, the processor 11 is configured to perform the following methods.

FIG. 2 is a flowchart illustrating a notifying method 200 of multicast session deactivation performed by a user equipment (UE) according to an embodiment of the present disclosure. In some embodiments, the method 200 includes: a step 202, if the UE is in a radio resource control (RRC) inactive state and is configured to receive a multicast session in the inactive state, the UE is notified through a multicast/broadcast service (MBS) control channel (MCCH) , an MCCH change notification, or a medium access control-control element (MAC CE) when the multicast session is deactivated.

In some embodiments, the UE is notified through an information element (IE) /bit of the MCCH when the multicast session is deactivated. In some embodiments, the IE/bit of the MCCH or a content of the MCCH comprises a message or IE related to the MCCH. In some embodiments, the message or IE related to the MCCH comprises an MCCH-message, an MBSBroadcastConfiguration message, an MBS-sessioninfolist IE, or a new defined, added, or varied message or IE related to the MCCH. In some embodiments, if the MCCH is used to provide a PTM configuration, the UE is notified through a removal of the PTM configuration from the multicast session when the multicast session is deactivated. In some embodiments, the PTM configuration comprises an initially PTM configuration provision, a PTM configuration update within a cell, and/or a point-to-multipoint (PTM) configuration acquiring due to mobility.

In some embodiments, the MCCH change notification is used to notify the UE in the RRC inactive state when the multicast session is deactivated and the MCCH is used to notify the UE in the RRC inactive state which multicast session is deactivated. In some embodiments, the UE is configured to acquire the MCCH through a system information block 20 (SIB20) , and the SIB20 contains information required to acquire an MCCH configuration for MBS broadcast. In some embodiments, a class of the MCCH-message is a set of RRC messages sent received by the UE on an MCCH logical channel.

In some embodiments, the MBSBroadcastConfiguration message contains a control information applicable for MBS broadcast services transmitted via broadcast MBS radio bearer (MRB) . In some embodiments, the MBS-sessioninfolist IE provides a list of ongoing MBS broadcast sessions transmitted via broadcast MRB and for each MBS broadcast session, an associated group radio network temporary identifier (G-RNTI) and scheduling information. In some embodiments, the UE is notified with the MCCH change notification through a downlink control information (DCI) format 4_0. In some embodiments, in the MCCH change notification, 2 bits are defined if a cyclic redundancy check (CRC) of the DCI format 4_0 is scrambled by an MCCH-RNTI, or otherwise, a bit field is reserved.

FIG. 3 is a flowchart illustrating a notifying method of multicast session deactivation according to an embodiment of the present disclosure. FIG. 3 illustrates that, in some embodiments, if the UE is in a radio resource control (RRC) inactive state and is configured to receive a multicast session in the inactive state, the UE is notified by a network (NW) through a multicast/broadcast service (MBS) control channel (MCCH) , an MCCH change notification, or a medium access control-control element (MAC CE) when the multicast session is deactivated.

In some embodiments, the UE is notified by the network through an information element (IE) /bit of the MCCH when the multicast session is deactivated. In some embodiments, the IE/bit of the MCCH or a content of the MCCH comprises a message or IE related to the MCCH. In some embodiments, the message or IE related to the MCCH comprises an MCCH-message, an MBSBroadcastConfiguration message, an MBS-sessioninfolist IE, or a new defined, added, or varied message or IE related to the MCCH. In some embodiments, if the MCCH is used to provide a PTM configuration, the UE is notified through a removal of the PTM configuration from the multicast session when the multicast session is deactivated. In some embodiments, the PTM configuration comprises an initially PTM configuration provision, a PTM configuration update within a cell, and/or a point-to-multipoint (PTM) configuration acquiring due to mobility.

In some embodiments, an overall solution includes an MCCH or MCCH change notification is used to notify UEs in an inactive state when a multicast session is deactivated.

Embodiments

In R17 MBS, MCCH means a point-to-multipoint downlink channel used for transmitting MBS broadcast control information associated to one or several MTCH (s) from the network to the UE.

MBS broadcast can be received by UEs in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state. A UE can receive the MBS configuration for broadcast session (e.g., parameters needed for MTCH reception) via MCCH in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state. The parameters needed for the reception of MCCH are provided via System Information.

The following principles govern the MCCH structure:

1. MCCH provides the list of all broadcast services with ongoing sessions transmitted on MTCH (s) and the associated information for broadcast session includes MBS session ID, associated G-RNTI scheduling information and information about neighbouring cells providing certain service on MTCH (s) . MCCH content is transmitted within periodically occurring time domain windows, referred to as MCCH transmission window defined by MCCH repetition period, MCCH window duration and radio frame/slot offset.

2. MCCH uses a modification period and MCCH contents are only allowed to be modified at each modification period boundary; A notification mechanism is used to announce the change of MCCH contents due to broadcast session start, modification or stop and due to neighboring cell information modification.

3. When the UE receives a MCCH change notification, it acquires the updated MCCH in the same MCCH modification period where the change notification is sent.

SIB20 contains MCCH configuration. MCCH-RNTI is used for Identifying transmissions of MCCH and MCCH change notification.

Therefore, MCCH is kind of a “broadcast” channel which can be received by UEs in inactive state and can be used for indication of multicast session deactivation.

Embodiment 1: MCCH is used to notify UEs in inactive state when multicast session is deactivated.

Embodiment 1 discusses how to acquire MCCH and the content of MCCH.

How to acquire MCCH:

SIB20 contains the information required to acquire the MCCH configuration for MBS broadcast.

SIB20 information element

The content of MCCH:

The MCCH-Message class is the set of RRC messages that may be sent from the network to the UE on the MCCH logical channel.

The MBSBroadcastConfiguration message contains the control information applicable for MBS broadcast services transmitted via broadcast MRB.

Signalling radio bearer: N/A

RLC-SAP: UM

Logical channel: MCCH

Direction: Network to UE

MBSBroadcastConfiguration message

The IE MBS-SessionInfoList provides the list of ongoing MBS broadcast sessions transmitted via broadcast MRB and, for each MBS broadcast session, the associated G-RNTI and scheduling information.

MBS-SessionInfoList information element

Embodiment 1-1: New IE/bit is added in MCCH (any message or IE related to MCCH, such as MCCH-message, MBSBroadcastconfiguration, MBS-sessioninfolist, or any other new defined/added/varied IE/message) to explicitly notify UE the deactivation the multicast session.

The possible ASN. 1 could be as the following.

Example1: Multicast related IE is added in MCCH-msg, and Multicast session deactivation related IE is added in the new IE.

MBSMulticastConfiguration message

Example 2: Multicast related IE is added in MBSBroadcastconfiguration or it variants (since the existing name seems related to “Broadcast” only and might be updated due to the introduction of Multicast later) .

MBSBroadcastConfiguration message

Example 3: Multicast related IE is added in MBS-SessionInfolist, or it variants (since the existing name seems related to “Broadcast” only and might be updated due to the introduction of Multicast later) .

MBS-SessionInfoList information element

Embodiment 1-2: In case MCCH is used for providing the PTM configuration (including initially PTM configuration provision, PTM configuration update within a cell, and/or PTM configuration acquiring due to mobility) , gNB can remove the PTM configuration of the Multicast session to implicitly notify UE the deactivation the multicast session.

In case MCCH is used for PTM configuration provision, the ASN. 1 of MCCH might be like the following.

MBSMulticastConfiguration message

When UEs receive the updated configuration and find out that the configuration of Multicast session is removed, UEs will be aware of that the multicast session has been deactivated. With this solution, gNB will send MCCH change notification first to require UE to receive the updated configuration first.

1. gNB sends MCCH change notification first to require UE to receive the updated configuration first.

2. UEs receive the updated configuration and find out that the configuration of Multicast session is removed, UEs will be aware of that the multicast session has been deactivated.

Embodiment 2: MCCH change notification is used to notify UEs in inactive state when multicast session is deactivated and MCCH is used to notify UEs which multicast session is deactivated.

In some embodiments, DCI format 4_0 is used for MCCH-RNTI.

DCI format 4_0 is used for the scheduling of PDSCH for broadcast in DL cell.

The following information is transmitted by means of the DCI format 4_0 with CRC scrambled by MCCH-RNTI or G-RNTI configured by MBS-SessionInfo:

Frequency domain resource

bits where

equals to

as given by clause 7.3.1.0 of [6, TS38.214] .

Time domain resource assignment –4 bits as defined in Clause 5.1.2.1 of [6, TS38.214] .

VRB-to-PRB mapping –1 bit according to Table 7.3.1.2.2-5 of [6, TS38.214] .

Modulation and coding scheme –5 bits as defined in Clause 5.1.3 of [6, TS38.214] .

Redundancy version –2 bits as defined in Table 7.3.1.1.1-2 of [6, TS38.214] .

MCCH change notification –2 bits as defined in some embodiments of the present disclosure if the CRC of the DCI format 4_0 is scrambled by MCCH-RNTI. Otherwise, this bit field is reserved.

Padding bits, if required.

MCCH change notification consists of two bits as follows:

1 ^st bit: indicate the MCCH change is due to the session start.

2nd bit: indicate the MCCH change is due to the modification of ongoing session, session stop, or the neighbor cell list update.

Regarding how to use MCCH change notification to notify UE about the Multicast session deactivation, and acquire UE to receive the updated MCCH, we have the following options.

Option 1: Removing the configuration of multicast session or indication explicitly of a multicast session deactivation in MCCH/other types of PTM configuration messages can be assumed as one scenario of “modification of ongoing session” , therefore the current MCCH change notification design is enough. This is also embodiment1.

2 ^nd bit is used for the indication of Multicast session deactivation. Multicast session deactivation can be assumed as one scenario of “modification of ongoing session” , or listed as a separate reason.

Option 1-1: Stay the same.

2 ^nd bit: indicate the MCCH change is due to the modification of ongoing session, session stop, or the neighbor cell list update.

Option 1-2:

2nd bit: indicate the MCCH change is due to the modification of ongoing session, Multicast session deactivation, session stop, or the neighbor cell list update.

Option 2: 1st bit is used for indication of Multicast session deactivation

1st bit: indicate the MCCH change is due to the session start, and session deactivation.

Option 3: use a spare bit for the Multicast session deactivation

Spare bit: indicate the MCCH change is due to Multicast session deactivation.

Embodiment 3: MAC CE can be used for Multicast session deactivation indication

A new MAC CE can be introduced to notify UE about the multicast session deactivation. Regarding how to transmit MAC CE, it depends on how a gNB transmits multicast data to a UE, e.g., if in R18, the gNB would still use MTCH for multicast transmission, an MAC CE can also be transmitted by an MTCH.

The existing MAC CE is illustrated in TS 38.321 clause 6.2.1. a new LCID can be introduced for multicast session deactivation indication MAC CE, such as we can change following the first table into the second table.

Table 6.2.1-1c Values of LCID for MBS broadcast on DL-SCH

Codepoint/Index	LCID values
0	MCCH
1–32	Identity of the logical channel of broadcast MTCH
33–63	Reserved

Table 6.2.1-1c Values of LCID for MBS on DL-SCH

Codepoint/Index	LCID values
0	MCCH
1–32	Identity of the logical channel of broadcast MTCH
33	Multicast session deactivation
34–63	Reserved

FIG. 4 is a block diagram of an example system 700 for wireless communication according to an embodiment of the present disclosure. Embodiments described herein may be implemented into the system using any suitably configured hardware and/or software. FIG. 4 illustrates the system 700 including a radio frequency (RF) circuitry 710, a baseband circuitry 720, an application circuitry 730, a memory/storage 740, a display 750, a camera 760, a sensor 770, and an input/output (I/O) interface 780, coupled with each other at least as illustrated. The application circuitry 730 may include a circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general-purpose processors and dedicated processors, such as graphics processors, application processors. The processors may be coupled with the memory/storage and configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems running on the system.

While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

A notifying method of multicast session deactivation performed by a user equipment (UE) , comprising:

if the UE is in a radio resource control (RRC) inactive state and is configured to receive a multicast session in the inactive state, the UE is notified through a multicast/broadcast service (MBS) control channel (MCCH) , an MCCH change notification, or a medium access control-control element (MAC CE) when the multicast session is deactivated.
The method according to claim 1, wherein the UE is notified through an information element (IE) /bit of the MCCH when the multicast session is deactivated.
The method according to claim 2, wherein the IE/bit of the MCCH or a content of the MCCH comprises a message or IE related to the MCCH.
The method according to claim 3, wherein the message or IE related to the MCCH comprises an MCCH-message, an MBSBroadcastConfiguration message, an MBS-sessioninfolist IE, or a new defined, added, or varied message or IE related to the MCCH.
The method according to any one of claims 1 to 4, wherein if the MCCH is used to provide a PTM configuration, the UE is notified through a removal of the PTM configuration from the multicast session when the multicast session is deactivated.
The method according to claim 5, wherein the PTM configuration comprises an initially PTM configuration provision, a PTM configuration update within a cell, and/or a point-to-multipoint (PTM) configuration acquiring due to mobility.
The method according to any one of claims 1 to 6, wherein the MCCH change notification is used to notify the UE in the RRC inactive state when the multicast session is deactivated and the MCCH is used to notify the UE in the RRC inactive state which multicast session is deactivated.
The method according to any one of claims 1 to 7, further comprising the UE acquiring the MCCH through a system information block 20 (SIB20) , wherein the SIB20 contains information required to acquire an MCCH configuration for MBS broadcast.
The method according to any one of claims 4 to 8, wherein a class of the MCCH-message is a set of RRC messages sent received by the UE on an MCCH logical channel.
The method according to any one of claims 4 to 9, wherein the MBSBroadcastConfiguration message contains a control information applicable for MBS broadcast services transmitted via broadcast MBS radio bearer (MRB) .
The method according to any one of claims 4 to 10, wherein the MBS-sessioninfolist IE provides a list of ongoing MBS broadcast sessions transmitted via broadcast MRB and for each MBS broadcast session, an associated group radio network temporary identifier (G-RNTI) and scheduling information.
The method according to any one of claims 4 to 11, wherein the UE is notified with the MCCH change notification through a downlink control information (DCI) format 4_0.
The method according to claim 12, wherein in the MCCH change notification, 2 bits are defined if a cyclic redundancy check (CRC) of the DCI format 4_0 is scrambled by an MCCH-RNTI, or otherwise, a bit field is reserved.
A user equipment, comprising:

a memory;

a transceiver; and

a processor coupled to the memory and the transceiver;

wherein the processor is configured to execute the method of any one of claims 1 to 13.
A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 13.
A chip, comprising:

a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 13.
A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 13.
A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 13.
A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 13.