CN120186815A

CN120186815A - User equipment, base station and method thereof

Info

Publication number: CN120186815A
Application number: CN202311759927.9A
Authority: CN
Inventors: 肖芳英; 刘仁茂
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2023-12-20
Filing date: 2023-12-20
Publication date: 2025-06-20
Also published as: WO2025130911A1

Abstract

According to the present invention, a method performed by a user equipment, UE, is proposed, comprising receiving an RRC release message from a base station, and if the RRC release message contains a first field but does not contain a second field for carrying an MBS multicast configuration message, considering any one of all joined MBS multicast sessions as being configured to be receivable in an RRC inactive state, all joined MBS multicast sessions as being receivable in a current serving cell in an RRC inactive state, all joined MBS multicast sessions as being configured to be receivable in a current serving cell in an RRC inactive state, all joined MBS multicast sessions as being receivable in a current serving cell in an RRC inactive state before acquiring a multicast MCCH, and all joined MBS multicast sessions as being configured to be receivable in an RRC inactive state in a current serving cell before acquiring a multicast MCCH.

Description

User equipment, base station and method thereof

Technical Field

The present invention relates to the field of wireless communication technologies, and in particular, to a user equipment, a base station, and a method thereof.

Background

A research project SI (see in particular SP-190625) on the improvement of 5G multicast broadcast service architecture has been approved. One of the goals of this SI (referred to as goal a) is to support generic MBS services in 5GS, and examples of applications that may benefit from this feature include, but are not limited to, public security, V2X applications, transparent IPv4/IPv6 multicast transmissions, IPTV, wireless software transmissions, group communications, and internet of things applications. Accordingly, work items (see non-patent document: RP-193248:New WID:NR Multicast and Broadcast Service) for NR multicast and broadcast services (NRMBS) were proposed and approved at the third generation partnership project (3rd Generation Partnership Project:3GPP) RAN#86. The work item is intended to provide support for target a in the RAN. The objectives of this work project have been substantially met, and specific descriptions of related schemes are found in 3GPP release 17 technical documents, such as TS38.300-h60, TS38.331-h60, TS38.321-h60, etc. An item named enhanced NR broadcast multicast work is approved at 3GPPRAN#94 full meeting (see non-patent document: RP-213568:New WID:Enhancements of NR Multicast and Broadcast Services). This work item is intended to further enhance the MBS broadcast multicast of release 17, one of its targets being to support the user equipment to receive MBS multicast services/sessions in RRC inactive state.

The present invention discusses the problems related to the RAN supporting the reception of MBS multicast services/sessions by a user equipment in RRC inactive state.

Disclosure of Invention

To solve at least some of the above problems, the present invention provides a user equipment, a base station, and a method thereof capable of efficiently handling an established multicast MRB in an RRC inactive state.

In order to achieve the above object, according to the present invention, there is provided a method performed by a user equipment UE, comprising receiving an RRC release message from a base station, and if the RRC release message includes a first field but does not include a second field for carrying an MBS multicast configuration message, considering that any one of all the configured MBS multicast sessions is configured to be receivable in an RRC inactive state, all the configured MBS multicast sessions are configured to be receivable in a current serving cell in an RRC inactive state, all the configured MBS multicast sessions are configured to be receivable in an RRC inactive state in the current serving cell, all the configured MBS multicast sessions are configured to be receivable in an RRC inactive state before acquiring the multicast MCCH, and all the configured MBS multicast sessions are configured to be receivable in an RRC inactive state in the current serving cell before acquiring the multicast MCCH, wherein the first field indicates that the UE is receivable in an RRC inactive state, all the configured MBS multicast sessions are configured to be receivable in an RRC inactive state, and all the configured MBS multicast sessions are receivable in an RRC inactive state before the current serving cell or the multicast MCCH is acquired in an RRC inactive state, and the configured to indicate that the MBS session is receivable in an active state or an inactive state.

Preferably, the configured MBS multicast session is an MBS multicast session configured when the UE is in RRC connected state.

Furthermore, according to the present invention, a method performed by a user equipment UE is proposed, comprising receiving an RRC release message from a base station, and if the RRC release message contains a first field but does not contain a second field for carrying MBS multicast configuration messages, considering that any one of all configured MBS multicast sessions is not configured to be receivable in an RRC inactive state, all configured MBS multicast sessions are not configured to be receivable in an RRC inactive state in a current serving cell before acquiring a multicast MCCH, all joined MBS multicast sessions are not configured to be receivable in an RRC inactive state in a current serving cell before acquiring a multicast MCCH, and all joined MBS multicast sessions are not configured to be receivable in an RRC inactive state in a current serving cell before acquiring a multicast MCCH, wherein the first field indicates that the UE is receivable in a current serving cell or the MBS multicast session is receivable in an RRC inactive state when the first field indicates that the UE is in an RRC inactive state or the MBS multicast session is receivable in an RRC inactive state or the multicast session is receivable or before the MCCH is available for the MBS multicast session or the MBS multicast session is receivable in an inactive state or the multicast service is indicated to be receivable in an RRC inactive state.

In addition, according to the present invention, there is provided a method performed by a user equipment, UE, comprising receiving an RRC release message from a base station, and if the RRC release message contains a first field but does not contain a second field for carrying an MBS multicast configuration message, considering that any one of all configured MBS multicast sessions is indicated to stop detecting G-RNTI, all joined MBS multicast sessions are indicated to stop detecting G-RNTI, all MBS multicast sessions associated with established MRBs are indicated to stop detecting G-RNTI, and all configured MBS multicast sessions are not indicated to stop detecting G-RNTI, wherein the first field indicates an MBS multicast session or service receivable by a current serving cell when the UE is in an RRC inactive state, or indicates an MBS multicast session or service receivable by the UE when the current serving cell is in an inactive state before acquiring a multicast MCCH, or indicates an MBS session or service receivable by the UE when the current serving cell is in an inactive state before acquiring the RRC MCCH.

Furthermore, according to the present invention, a method performed by a user equipment, UE, is proposed, comprising receiving an RRC release message from a base station, and obtaining an MBS multicast configuration message on a multicast MCCH if the RRC release message contains a first field and does not contain at least one PTM configuration configured for MBS multicast sessions received in an RRC deactivated state and not indicated as a stop detection G-RNTI, wherein the first field indicates MBS multicast sessions or services receivable in a current serving cell when the UE is in the RRC deactivated state or for MBS multicast sessions or services receivable in the current serving cell when the UE is in the RRC deactivated state before obtaining the multicast MCCH or for MBS multicast sessions or services receivable in the RRC deactivated state before obtaining the multicast MCCH.

In addition, according to the invention, a method performed by a user equipment UE is proposed, comprising receiving an RRC release message from a base station, and if the RRC release message contains a first field and provides a multicast PTM configuration of at least one MBS multicast session, and the UE selects a cell receiving the RRC release message, performing at least one of applying the multicast PTM configuration contained in the RRC release message, and detecting a multicast MCCH-RNTI if at least one MBS multicast session is not indicated to be not stopped detecting G-RNTI, wherein the first field indicates an MBS multicast session or service receivable at a current serving cell when the UE is in an RRC inactive state, or indicates an MBS multicast session or service receivable at the current serving cell before the UE is in the RRC inactive state, or indicates an MBS multicast session or service receivable at the UE is in the RRC inactive state before the MBS MCCH is acquired.

Furthermore, according to the present invention, a user equipment is presented comprising a processor and a memory storing instructions, wherein the instructions when executed by the processor perform the above-mentioned method.

In addition, according to the invention, a method performed by a base station is proposed, the base station communicating with a user equipment UE, the method comprising sending to the UE an RRC release message comprising a first field but not comprising a second field for carrying an MBS multicast configuration message, wherein the first field indicates an MBS multicast session or service receivable at a current serving cell when the UE is in an RRC inactive state, or indicates an MBS multicast session or service receivable at the UE in the RRC inactive state, or indicates an MBS multicast session or service receivable at the current serving cell when the current serving cell is in the RRC inactive state before acquiring the multicast MCCH, or indicates an MBS multicast session or service receivable at the UE in the RRC inactive state before acquiring the multicast MCCH.

Furthermore, according to the present invention, a base station is presented comprising a processor and a memory storing instructions, wherein the instructions when executed by the processor perform the above-described method.

Effects of the invention

According to the present invention, it is possible to efficiently process the multicast MRB that has been established in the RRC inactive state.

Drawings

The foregoing and other features of the invention will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings in which:

fig. 1 is a flowchart illustrating a method performed by a user equipment according to embodiment 1 of the present invention.

Fig. 2 is a flowchart illustrating a method performed by a user equipment according to embodiment 2 of the present invention.

Fig. 3 is a flowchart showing a method performed by a user equipment according to embodiment 3 of the present invention.

Fig. 4 is a flowchart illustrating a method performed by a user equipment according to embodiment 4 of the present invention.

Fig. 5 is a flowchart showing a method performed by a user equipment according to embodiment 5 of the present invention.

Fig. 6 is a block diagram schematically illustrating a user equipment to which the present invention relates.

Fig. 7 is a block diagram schematically showing a base station to which the present invention relates.

Detailed Description

The following describes some terms related to the present invention, and specific meanings of the terms can be found in 3GPP recently relevant documents, such as TS38.300-h60, TS38.321-h60, TS38.323-h50, TS38.331-h60, etc. In addition, the embodiment of the present invention is described by taking a broadcast/multicast service as an example, but the embodiment of the present invention is not limited to the broadcast/multicast service, and may be applied to other application scenarios.

UE is User Equipment and User Equipment.

RRC, radio Resource Control, radio resource control.

Rrc_connected: RRC CONNECTED state.

Rrc_inactive: RRC INACTIVE state.

Rrc_idle, RRC IDLE state.

RAN Radio Access Network, radio access network.

New RAT, new radio Access technology.

MBS: multicast/Broadcast Services, multicast/broadcast service. Multicasting may also be referred to as multicasting.

AS is Access Stratum, access layer or Access layer.

NAS Non Access Stratum, non-access stratum or non-access stratum.

RB Radio Bearer. The DRB is a data radio bearer.

MRB, MBS radio bearer, i.e. a radio bearer configured for MBS transmission (Aradio bearer that is configured for MBS delivery). MRBs are classified into multicast MRBs, which are radio bearers configured for MBS multicast transmission, and broadcast MRBs, which are radio bearers configured for MBS broadcast transmission.

TMGI Temporary Mobile Group Identity, temporary Mobile group identity, used to identify one MBS session.

And RNTI Radio Network Temporary Identifier, radio network temporary identifier.

PTM: point to Multipoint, point-to-multipoint, a delivery (delivery) mode of MBS service. In the PTM delivery mode, the base station sends an MBS packet to a group of UEs (gNB DELIVERS A SINGLE copy of MBS DATA PACKETS to a set of UEs). The UE receives the PTM transmission using the G-RNTI or the G-CS-RNTI. For example, the base station schedules the same group common physical downlink shared channel PDSCH using G-RNTI using the group common physical downlink control channel PDCCH using G-RNTI.

PTP, point-to-Point, a delivery method of MBS service. In PTP delivery, the gNB transmits a separate copy of the MBS data packet (gNB individually DELIVERS SEPARATE copies of MBS DATA PACKETS to each UEs independently) separately to each UE. For example, a base station uses a UE-specific RNTI scrambled UE-specific PDCCH schedule uses the same UE-specific RNTI scrambled UE-specific PDSCH.

PCell PRIMARY CELL, primary cell, MCG cell, operating on primary frequency, in which the UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

SCell, secondary Cell. For a UE configured with carrier aggregation, the SCell is a cell that provides additional radio resources over a special cell. For dual connectivity operation, the term special cell refers to the PCell of the MCG or the PSCell of the SCG, and in carrier aggregation, the term special cell refers to the PCell. For the dual connectivity operation, PSCell is a secondary cell group SCG cell in which a UE performs random access when performing a synchronization reconfiguration procedure.

G-RNTI Group RNTI, scheduling and transmission of PTM for scrambling one or more MBS multicast services (Used to scramble the scheduling and transmission of PTM for one or more MBS multicast services).

The group configuration scheduling RNTI is used for scrambling a semi-persistent scheduling SPS group public physical downlink shared channel PDSCH and activating/deactivating SPS group public PDSCH of one or more MBS multicast services.

The MTCH MBS TRAFFIC CHANNEL, MBS traffic channel is a PTM downlink channel used to transmit MBS data for a multicast session or broadcast session from the network to the UE. Unless otherwise specified, MTCHs referred to in the embodiments of the present disclosure all refer to multicast MTCHs used for transmitting MBS multicast sessions.

MCCH MBS Control Channel, MBS control channel, is a PTM downlink channel for transmitting MBS broadcast or MBS multicast control information (A PTM downlink channel used for transmitting MBS broadcast or MBS multicast control information associated to one or several MTCH(s)from the network to the UE).MCCH related to one or more MTCHs from the network to the UE including broadcast MCCH and multicast MCCH.

The RRC resume request message RRCResumeRequest or RRCResumeRequest1 is used to request the resume of the suspended RRC connection or to perform a RAN-based notification area RNA update. When the UE initiates the RRC connection recovery request, if a useFullResumeID field is contained in the SIB1, a RRCResumeRequest message is used and a resumeIdentity field in the RRCResumeRequest message is set as fullI-RNTI stored by the UE, otherwise, RRCResumeRequest is used and a resumeIdentity field in the RRCResumeRequest message is set as shortI-RNTI stored. The RRC release message RRCRELEASE is used to command release of one RRC connection or suspension of one RRC connection. The RRC reconfiguration message RRCReconfiguration is used to command modification of the RRC connection. The RRC resume message RRCResume is used to resume the suspended RRC connection. In the present disclosure, useFullResumeID fields indicate recovery identity and recovery request messages used, fullI-RNTI and RRCResumeRequest messages are used when the fields are contained in SIB1, and shortI-RNTI and RRCResumeRequest messages are used when the fields are not contained in SIB 1. shortI-RNTI uses fewer bits than I-RNTI-Value to identify the suspended UE context of the UE in the RRC inactive state. The RRC recovery procedure (i.e., RRC connection recovery procedure) is used to recover the suspended RRC connection, including recovering SRBs(s), DRBs(s), and multicast MRBs(s), or to perform RNA update, or to implement MBS multicast reception request, or to initiate small data transmission SDT in rrc_inactive state, etc. In the RRC recovery procedure, the UE transmits an RRC recovery request message to the base station, and may receive an RRC recovery message RRCResume or an RRC setup message RRCSetup or an RRC release message RRCRELEASE or an RRC reject message RRCReject from the base station.

In the present invention, the network, the base station and the RAN are used interchangeably, and the network may be a long term evolution LTE network, an NR network, an enhanced long term evolution eLTE network, or other networks defined in a later evolution version of 3 GPP.

Currently, the NR MBS service includes MBS broadcasting (also referred to as MBS broadcasting session or broadcasting MBS or MBS broadcasting service) and MBS multicasting (also referred to as MBS multicasting session or multicasting MBS or MBS multicasting service). The MBS broadcast service facing low quality of service QoS provides a downlink MBS transmission mode only, so that the UE in the RRC connection state, the RRC idle state and the RRC non-activated state can receive the MBS service. And the UE acquires MBS broadcast configuration information of the network broadcast through an MBS control channel MCCH.

In release 17 the UE is not supported to receive MBS multicast sessions in RRC inactive state. Therefore, the UE needs to establish an RRC connection with the base station before receiving MBS multicast services (i.e. MBS multicast sessions), then the base station (i.e. network) configures resources or PTM configuration for the UE to receive MBS multicast services through dedicated RRC signaling (also referred to as RRC messages, e.g. RRC reconfiguration messages), MBS radio bearers MRBs to receive these MBS multicast services are also configured for the UE through dedicated RRC signaling (DEDICATED RRC SIGNALING) by the base station, and only the UE in RRC connected state and configured with MRBs can receive the corresponding MBS multicast services. Therefore, when one MBS multicast session is activated by the core network or the base station has MBS multicast session data to transmit, the network supporting MBS multicast notifies the UE in the RRC idle state or the RRC inactive state through the group notification mechanism. Upon receiving the group notification, the UE that has joined or is interested in the MBS multicast session establishes or resumes an RRC connection with the network to receive the corresponding MBS multicast session. The group notification uses P-RNTI addressing (the group notification IS ADDRESSED WITH P-RNTI on PDCCH) on the physical downlink control channel PDCCH, and the UE detects the (monitor) Paging (Paging) channel. The paging message for group notification contains an MBS session identifier TMGI, which is used to page all UEs that have joined the relevant MBS multicast session and are in RRC idle state or RRC inactive state. In other words, the base station does not page the UE alone (for the purpose of receiving MBS multicast sessions for the UE).

In release 18 the UE is supported to receive MBS multicast sessions in RRC inactive state. For MBS multicast sessions configured to be received in the RRC inactive state, the base station may provide or configure PTM configuration information (also referred to as configuration information of MBS multicast sessions or PTM configuration of MBS multicast sessions or MBS multicast configuration) for receiving said MBS multicast sessions for the UE through dedicated RRC signaling (e.g. RRCRELEASE message) or through multicast MBS control channel MCCH (i.e. multicast MCCH). The information required for acquiring the multicast MCCH (or multicast MCCH configuration) may be configured for the UE through a dedicated RRC signaling or system information block (denoted as SIBx), i.e., the SIBx includes information required for acquiring the multicast MCCH/MTCH (i.e., MCCH and/or MTCH) configuration of MBS multicast received in the RRC inactive state. The PTM configuration information may include configuration information of MRB corresponding to the MBS multicast session and/or a field of configuration information such as an identifier TMGI of the MBS multicast session and a corresponding G-RNTI/G-CS-RNTI and/or DRX. For example, the PTM configuration of a certain MBS multicast session is information related to reception of said MBS multicast session contained in an MBS multicast configuration MBSMulticastConfiguration message. Wherein the MBSMulticastConfiguration message contains control information (contains the control information applicable for MBS multicast services transmitted via multicast MRBs for RRC_INACTIVE UEs). applied to rrc_inactive UE receiving MBS multicast through multicast MRB the MBSMulticastConfiguration message may be transmitted in multicast MCCH or RRC release message. wherein the multicast MCCH is a PTM downlink channel, and is used to transmit control information (A PTM downlink channel used for transmitting control information of MBS multicast session associated to one or several MTCH(s)from the network to the UE in RRC_INACTIVE state). of an MBS multicast session associated with one or more MTCHs from a network to a UE in an RRC INACTIVE state for an MBS multicast session received in an rrc_inactive state, in the embodiment of the present disclosure, the MBS multicast session being active or being activated means that the MBS multicast session is in progress or about to start, the UE starts to receive (or is receiving) the MBS multicast session or the UE starts to detect a G-RNTI corresponding to the MBS multicast session or the UE starts to detect (monitor) a multicast-MCCH-RNTI of the multicast MCCH. The network may instruct the UE that the MBS multicast is activated or resumes data transmission through RRC signaling (e.g., RRC release message) or through paging message (e.g., including the TMGI of the MBS multicast session in paging message indicates that the MBS multicast session is activated or resumes data transmission), and the UE starts receiving the MBS multicast session after receiving the indication (i.e., the UE starts detecting the G-RNTI corresponding to the MBS multicast session). The activated MBS multicast in the embodiments of the present disclosure is also applicable to the case of recovering the data transmission of the MBS multicast session, and will not be described in detail below. In the embodiment of the disclosure, the MBS multicast session being in an inactive state or deactivated refers to that the MBS multicast session has ended or suspends data transmission or the UE stops receiving the MBS multicast session (i.e. the UE stops detecting the G-RNTI corresponding to the MBS multicast session). The network may inform the UE by multicast MCCH messages (e.g. if the PTM configuration of the MBS multicast session or a specific part of its PTM configuration does not appear in the multicast MCCH messages, indicating that the MBS multicast session is deactivated, or associating an indication identity for each MBS multicast session to explicitly indicate that the MBS multicast session is deactivated or to stop detecting the G-RNTI corresponding to the MBS multicast session) or by scheduling the physical downlink control channel PDCCH (or downlink control information DCI) of the multicast MCCH (or multicast MCCH message), e.g. using 1 bit in the DCI of the PDCCH to indicate that the MBS multicast is deactivated or to suspend data transmission. And the UE stops receiving the MBS multicast session after receiving the indication. The UE stopping receiving the MBS multicast session may be that the UE does not detect a G-RNTI or a G-CS-RNTI corresponding to the MBS multicast session. Thus, in the present disclosure, the indication of deactivation or stopping of data transmission of the MBS multicast session is an indication of stopping detection of the G-RNTI or G-CS-RNTI associated with the MBS multicast session by the UE. In addition, the indication that the MBS multicast session is activated or resumes data transmission is an indication to start detecting the G-RNTI corresponding to the MBS multicast session. The MBS multicast session being deactivated includes a case where the MBS multicast session has temporarily no data transmission, and the MBS multicast session being activated includes a case where the MBS multicast session resumes data transmission.

Each MBS multicast session is identified with one TMGI and associated with one G-RNTI or G-CS-RNTI. The UE receives one MBS multicast session by detecting a G-RNTI or a G-CS-RNTI associated with the MBS multicast session.

For UEs that are configured with MBS multicast sessions that can be received in rrc_inactive state, when an MBS multicast session is activated or data transmission resumed, the MBS multicast session can be received directly without having to establish an RRC connection with the base station if the MBS multicast session is configured and/or allowed to be received in rrc_inactive state and/or the UE is in (active) PTM configuration with the MBS multicast session. The network may configure the UE with PTM configuration information (e.g., contained in MBSMulticastConfiguration message) of the MBS multicast session received in rrc_inactive state through multicast MCCH and/or proprietary RRC signaling (e.g., RRC release message, RRC reconfiguration message). The MBS multicast configuration message MBSMulticastConfiguration may be transmitted on a multicast MCCH (referred to as a multicast MCCH message) or may be included in an RRC release message. If the UE is configured with the PTM configuration information of the MBS multicast session received in rrc_inactive state using the RRC release message, the network may include the MBSMulticastConfiguration message in the RRC release message sent to the UE.

In the disclosed embodiments, the Multicast MCCH-RNTI (i.e., multicast MCCH-RNTI) is used for dynamically scheduling Multicast MCCH signaling and/or Multicast MCCH change notification (DYNAMICALLY SCHEDULED MULTICAST MCCH SIGNALLING AND/or Multicast MCCH CHANGE notification) or is used for scrambling CRC of DCI or DCI format (format) or is used for scrambling PDCCH for MBS Multicast transmission purpose or is used for scrambling CRC of DCI or DCI format (format) for MBS Multicast purpose or is used for scheduling PDSCH of transmitting MBS Multicast session. The DCI or DCI format may be DCI format 4_0 or DCI format 4_1.

The UE in rrc_inactive, upon receiving a paging message from a base station, if the paging message contains the TMGI of one or more MBS sessions to which the UE has joined (the TMGI being contained in pagingGroupList fields in the paging message), further if the UE is not configured to receive MBS multicast in rrc_inactive (i.e. no multicastConfigInactive fields are contained in the RRC release message received last time) or there is at least one MBS multicast session to which the UE has joined indicated by the TMGI contained in the paging message is not indicated by the paging message as receivable in rrc_inactive (i.e. no inactiveReceptionAllowed fields corresponding to sessions to which the TMGI contained in the paging message to which the at least one UE has joined) if PagingRecordList fields are not contained in the paging message or any pagingRecord fields contained in the PagingRecordList fields in the paging message are not matched with UE identities allocated at the upper layer and full-stored by the UE, then initiates an RRC connection resume procedure. The PagingRecordList domain is a pagingRecord list, the pagingRecord domain contains a UE-Identity domain, the UE-Identity domain is used for indicating ng-5G-S-TMSI or fullI-RNTI of the paged UE, the fullI _rnti domain carries a suspension UE context allocated by the base station to the UE through an RRC release message and used for identifying the UE in the rrc_inactive, and the ng-5G-S-TMSI contains a 5G temporary mobile subscription identifier 5G-S-TMSI used for uniquely identifying a temporary UE identifier provided by the 5GC in the tracking area (TRACKING AREA).

The UE receives an RRC release message from the base station, and the multicastConfigInactive field included in the RRC release message indicates a multicast session or service that the UE may receive in the current serving cell (i.e., the cell receiving the RRC release message) when the UE is in rrc_inactive. Optionally, the multicastConfigInactive fields also contain the corresponding configurations of these multicast sessions, which are valid in the current serving cell. When the multicastConfigInactive field is included in the received RRC release message, indicating that the UE has been configured to receive MBS multicast at rrc_inactive.

In the present disclosure, an embodiment in which the effect of multicastConfigInactive domains is replaced with one of the following is also included in the present disclosure:

The multicastConfigInactive field is used to indicate a multicast session or service that the UE can receive when in rrc_inactive, or the multicastConfigInactive field is used to indicate a multicast session or service that the UE can receive when the current serving cell is in rrc_inactive before acquiring the multicast MCCH, or the multicastConfigInactive field is used to indicate a multicast session or service that the UE can receive when in rrc_inactive before acquiring the multicast MCCH.

The multicastConfigInactive domain may include two domains, namely INACTIVEPTM-Config domain and INACTIVEMCCH-Config domain. The INACTIVEPTM-Config field carries MBSMulticastConfiguration messages. The INACTIVEMCCH-Config field carries system information SIBx, which contains information required to acquire the multicast MCCH/MTCH configuration for MBS multicast reception while in rrc_inactive.

When the UE receives the RRC release message from the base station, if the RRC release message includes at least multicastConfigInactive fields and INACTIVEPTM-Config fields, in other words, at least one MBS multicast session is configured to be received in rrc_inactive, or at least one MBS multicast session is configured to be received in rrc_inactive in the current serving cell before receiving the multicast MCCH, the UE suspends all multicast MRBs associated with MBS multicast sessions not configured to be received in rrc_inactive. But how the UE handles the already established multicast MRB is a problem to be solved if the RRC release message contains multicastConfigInactive fields but no INACTIVEPTM-Config fields.

The following provides examples to address this problem. In addition, the following examples are merely examples and are not intended to limit the present invention. The disclosure is described taking RRC release messages as an example, and the related information may also be carried in other RRC signaling to achieve similar effects as RRC release messages.

Example 1

As shown in fig. 1, in step 101, the user equipment receives an RRC release message from the base station.

In step 103, if the RRC release message contains multicastConfigInactive fields but does not contain INACTIVEPTM-Config fields for carrying MBS multicast configuration messages, then (the UE considers) all the joined multicast sessions are configured to be receivable at rrc_inactive. Wherein the multicastConfigInactive field indicates a multicast session or service that the UE can receive in the current serving cell when the UE is in rrc_inactive, or indicates a multicast session or service that the UE can receive when the current serving cell is in rrc_inactive before acquiring the multicast MCCH, or indicates a multicast session or service that the UE can receive when the UE is in rrc_inactive before acquiring the multicast MCCH. Optionally, the multicastConfigInactive field further contains a PTM configuration of the indicated multicast session, which is valid in the current serving cell.

Optionally, the UE further performs at least one of:

Operation 1-1 it is considered that no indication of a stop detection G-RNTI for all configured MBS multicast sessions is received.

Operation 1-2 the MBSMulticastConfiguration message is acquired from the multicast MCCH of the associated (concerned) cell in the next repetition period.

Operations 1-3 the ue does not suspend any MRBs of the configured MBS multicast session.

Operations 1-4 consider that an indication of a stop detect G-RNTI for all configured or joined MBS multicast sessions is received.

[ Variant of example 1]

The embodiment in which (UE considers) all joined multicast sessions in embodiment 1 are configured to be available at rrc_inactive reception instead of one of that UE considers all configured MBS multicast sessions to be available at rrc_inactive reception, UE considers all joined multicast sessions to be configured to be available at rrc_inactive reception at the current serving cell, UE considers all configured multicast sessions to be configured to be available at rrc_inactive reception at the current serving cell, UE considers all joined multicast sessions to be configured to be available at rrc_inactive reception at the current serving cell before acquiring the multicast MCCH, UE considers all configured multicast sessions to be available at rrc_inactive reception at the current serving cell before acquiring the multicast MCCH.

It should be noted that, the configured MBS multicast session in the embodiment of the present disclosure refers to an MBS multicast session configured when the UE is in an RRC connected state. In this disclosure, a multicast session or service is an MBS multicast session or service.

Furthermore, it may be provided that if the user equipment receives an RRC release message from the base station, where the RRC release message includes multicastConfigInactive fields and INACTIVEPTM-Config fields for carrying MBS multicast configuration messages, then (the UE considers) an indication of a stop detection G-RNTI for all multicast sessions that have joined but not included in the INACTIVEPTM-Config fields (i.e. the TMGI of the multicast session is not included in the INACTIVEPTM-Config fields) is received. Wherein the multicastConfigInactive field indicates a multicast session or service that the UE can receive in the current serving cell when the UE is in rrc_inactive, or indicates a multicast session or service that the UE can receive when the current serving cell is in rrc_inactive before acquiring the multicast MCCH, or indicates a multicast session or service that the UE can receive when the UE is in rrc_inactive before acquiring the multicast MCCH. Optionally, the multicastConfigInactive field further contains a PTM configuration of the indicated multicast session, which is valid in the current serving cell.

Example 2

As shown in fig. 2, in step 201, the user equipment receives an RRC release message from the base station.

In step 203, if the RRC release message contains multicastConfigInactive fields but does not contain INACTIVEPTM-Config fields for carrying MBS multicast configuration messages, then (the UE considers) all configured multicast sessions are not configured to be receivable at rrc_inactive. Wherein the multicastConfigInactive field indicates a multicast session or service that the UE can receive in the current serving cell when the UE is in rrc_inactive, or indicates a multicast session or service that the UE can receive when the current serving cell is in rrc_inactive before acquiring the multicast MCCH, or indicates a multicast session or service that the UE can receive when the UE is in rrc_inactive before acquiring the multicast MCCH. Optionally, the multicastConfigInactive field further contains a PTM configuration of the indicated multicast session, which is valid in the current serving cell.

Optionally, the UE further performs at least one of:

Operation 2-1 it is considered that an indication of a stop detection G-RNTI for all configured MBS multicast sessions is received.

Operation 2-2 it is considered that an indication of the stop detection G-RNTI of all the joined MBS multicast sessions is received.

Operation 2-3 the ue suspends all MRBs of the configured MBS multicast session.

The multicast session not being configured to be receivable at rrc_inactive in the present disclosure means that either the multicast session is configured to be unable to be received at rrc_inactive or the multicast session is configured to be received only at rrc_connected.

[ Variant of example 2]

The embodiment in which the UE in embodiment 2 considers that all configured multicast sessions are not configured to be available at rrc_inactive reception is replaced with one of that the UE considers that all configured MBS multicast sessions are not configured to be available at rrc_inactive reception at the current serving cell, that the UE considers that all configured MBS multicast sessions are not configured to be available at rrc_inactive reception at the current serving cell before acquiring the multicast MCCH, that the UE considers that all joined multicast sessions are not configured to be available at rrc_inactive reception at the current serving cell, and that the UE considers that all joined multicast sessions are not configured to be available at rrc_inactive reception at the current serving cell before acquiring the multicast MCCH.

The manner in which the UE may perform for a configured multicast MRB upon receipt of the RRC release message is described in detail below.

In a first mode, the UE receives an RRC release message from the base station, and if the RRC release message contains INACTIVEPTM-Config field, suspends multicast MRBs of all MBS multicast sessions not configured for RRC_INACTIVE reception, and optionally indicates PDCP suspension to lower layers of all multicast MRBs associated with all MBS sessions not configured for RRC_INACTIVE reception. Alternatively, otherwise (the RRC release message does not include INACTIVEPTM-Config field), the UE does not suspend any multicast MRB. Mode one is applicable to embodiment 1.

The second mode is that the UE receives the RRC release message from the base station, if the RRC release message contains INACTIVEPTM-Config domain, all multicast MRBs of MBS multicast sessions which are not configured to be received by RRC_INACTIVE are suspended, and optionally, PDCP suspension is indicated to the lower layer of all multicast MRBs which are associated with all multicast sessions which are not configured to be received by RRC_INACTIVE, otherwise (the RRC release message does not contain INACTIVEPTM-Config domain), all multicast MRBs are suspended, and optionally, PDCP suspension is indicated to the lower layer of all multicast MRBs. Mode two is applicable to embodiment 1.

Example 3

As shown in fig. 3, in step 301, the user equipment receives an RRC release message from the base station.

In step 303, if the RRC release message contains multicastConfigInactive fields but does not contain INACTIVEPTM-Config fields for carrying MBS multicast configuration messages, the UE considers that all configured multicast sessions are indicated to stop detecting G-RNTIs, or the UE considers that all joined multicast sessions are indicated to stop detecting G-RNTIs, or the UE considers that all multicast sessions associated with established MRBs are indicated to stop detecting G-RNTIs, or the UE considers that all configured multicast sessions are not indicated to stop detecting G-RNTIs. Wherein the multicastConfigInactive field indicates a multicast session or service that the UE can receive in the current serving cell when the UE is in rrc_inactive, or indicates a multicast session or service that the UE can receive when the current serving cell is in rrc_inactive before acquiring the multicast MCCH, or indicates a multicast session or service that the UE can receive when the UE is in rrc_inactive before acquiring the multicast MCCH. Optionally, the multicastConfigInactive field further contains a PTM configuration of the indicated multicast session, which is valid in the current serving cell.

In addition, when receiving the RRC release message from the base station, if the UE is configured to receive MBS multicast at rrc_inactive, but the RRC release message does not include at least one PTM configuration of the multicast session that is not indicated as stopping detecting G-RNTI, the UE acquires MBSMulticastConfiguration message on the multicast MCCH. But how the UE can determine whether to acquire MBSMulticastConfiguration message from multicast MCCH is a problem to be solved when multicastConfigInactive domain is included in the RRC release message but INACTIVEPTM-Config domain is not included.

The following provides examples to address this problem.

Example 4

As shown in fig. 4, the ue receives an RRC release message from the base station in step 401.

In step 403, if the RRC release message configures the UE to receive an MBS multicast session in rrc_inactive (i.e. the RRC release message includes multicastConfigInactive fields) and the RRC release message does not include at least one PTM configuration of the MBS multicast session configured to be received in rrc_inactive and not indicated to stop detecting G-RNTIs, a MBSMulticastConfiguration message is acquired on the multicast MCCH.

[ Variant of example 4 ]

An embodiment wherein the condition in embodiment 4 that the RRC release message does not include at least one PTM configuration of MBS multicast sessions configured for rrc_inactive reception and not indicated to stop detecting G-RNTIs is replaced with one of the following:

condition 4-1. The RRC release message does not contain at least one PTM configuration of MBS multicast sessions that have joined and are not indicated as stopped detecting G-RNTI.

Condition 4-2 the RRC release message contains INACTIVEPTM-Config field but does not contain at least one PTM configuration of MBS multicast session configured for rrc_inactive reception and not indicated as stop detection of G-RNTI.

Condition 4-3. The RRC release message does not include at least one PTM configuration of MBS multicast sessions received as rrc_inactive configured by the RRCRELEASE message and not indicated as stopped detecting G-RNTI.

Condition 4-PTM configuration of MBS multicast session not including at least one TMGI in the RRC release message included in the RRCRELEASE message (i.e. included in INACTIVEPTM-Config field) and not indicated as stop detecting G-RNTI.

Condition 4-5 there is (or has been established) at least one multicast MRB in the ue, the RRC release message does not include in the PTM configuration of the MRB associated multicast session and the MRB associated multicast session is not indicated as stopped detecting G-RNTI.

It should be noted that, in this disclosure, acquiring MBSMulticastConfiguration a message on the multicast MCCH may refer to acquiring MBSMulticastConfiguration a message from the multicast MCCH of the related (concerned) cell in the next repetition period. The cell or related cell may refer to a serving cell or a cell where the UE receives the RRC release message or a PCell where the UE receives the RRC release message. The UE configured to receive MBS multicast in rrc_inactive means that the UE includes MBSMulticastConfiguration message in the received (i.e., previously or last received) RRC release message. Accordingly, the UE not being configured to receive MBS multicast in rrc_inactive means that the UE does not include MBSMulticastConfiguration message in the received (i.e. previously or last received) RRC release message or does not include any TMGI in the MBSMulticastConfiguration message although MBSMulticastConfiguration message is included.

Note that, the MulticastConfigInactive field of suspendConfig fields included in the RRC release message includes a MBSMulticastConfiguration message. Wherein suspendConfig field indicates configuration of RRC_INACTIVE state, multicastConfigInactive field is used for indicating one or more MBS multicast services which can be received in RRC_INACTIVE (or one or more MBS multicast services which can be received in RRC_INACTIVE for a current serving cell), optionally, configuration of the MBS multicast service (or configuration of the MBS multicast service for or configuration of the MBS multicast service valid for the current serving cell), and the current serving cell refers to a cell in which the UE receives the RRC release message. The serving cell or the cell in which the UE has last or previously received the RRC release message may refer to the primary cell PCell in which the UE has last or previously received the RRC release message. If the RRC release message received by the UE contains MBSMulticastConfiguration messages or MulticastConfigInactive fields, the UE is considered to be configured to receive MBS multicast in rrc_inactive, or if the RRC release message received by the UE (or MBSMulticastConfiguration messages contained in the RRC release message) contains TMGIs, the UE is considered to be configured to receive MBS multicast in rrc_inactive.

Currently, when receiving an RRC release message, if the RRC release message includes multicastConfigInactive fields, and a PTM configuration of a multicast session that is not indicated to stop detecting G-RNTIs is provided in the RRC release message, and the UE selects a cell that receives the RRC release message, the UE applies the multicast PTM configuration included in the RRC release message, and detects the multicast MCCH-RNTIs. However, if the multicast PTM configuration contained in the RRC release message is not applied when the RRC release message is received because the condition is not satisfied, when the UE receives a paging message, and the paging message contains the TMGI of the MBS multicast session to which the UE has joined and its corresponding inactiveReceptionAllowed field, and the PTM configuration of the MBS multicast session indicated by the TMGI is contained in the RRC release message that was previously received, if the multicast MCCH is not provided in the current serving cell, the UE will not be able to receive the MBS multicast session in rrc_inactive. Wherein the inactiveReceptionAllowed field is used to indicate whether a UE with a valid PTM configuration of the TMGI indicated in pagingGroupList (i.e., pagingGroupList-r 17) contained in the paging message is camping on rrc_inactive to receive the MBS multicast session indicated by the TMGI.

The following provides examples to address this problem.

Example 5

As shown in fig. 5, in step 501, the ue receives an RRC release message from the base station.

In step 503, if the RRC release message configures the UE to receive MBS multicast sessions in rrc_inactive (i.e. the RRC release message includes multicastConfigInactive fields), and the RRC release message provides multicast PTM configuration of at least one MBS multicast session, and the UE selects (selects) a cell to receive the RRCRELEASE, the UE performs at least one of the following operations:

Operation 5-1. Apply the multicast PTM configuration contained in the RRC release message.

Operation 5-2. If at least one MBS multicast session is not indicated to not stop detecting the G-RNTI, detecting the multicast MCCH-RNTI.

In embodiment five, the UE applies the PTM configuration of the MBS multicast session received in the RRC release message when it receives the RRC release message. The UE may also apply the PTM configuration of the MBS multicast session received in the RRC release message upon receiving the paging message. Specifically, a UE in RRC_INACTIVE receives a paging message from a base station, and if the UE joins one or more MBS sessions indicated by TMGIs contained in the paging message and does not satisfy inactiveReceptionAllowed that the UE is not configured to receive multicast in RRC_INACTIVE or that the paging message does not contain at least one of the TMGIs (i.e., the TMGIs of the MBS multicast session the UE has joined in the paging message), then performing the following operations:

If the UE is informed to stop detecting G-RNTIs of all multicast sessions that have been joined and configured to be not received by RRC-INACTIVE or if the UE is not detecting multicast MCCH-RNTIs, the UE starts detecting multicast MCCH-RNTIs and/or retrieving MBS multicast configuration messages from the multicast MCCH, otherwise if the UE is informed to stop detecting G-RNTIs of at least one multicast session, the PTM configuration of said multicast session is contained in a most recently or previously received RRC release message and/or the cell selected by the UE is a serving cell and/or the UE does not select or reselect to other cells for which the serving cell is after receiving the RRC release message, further, if the UE does not apply said PTM configuration when receiving said RRC release message, said PTM configuration is applied.

The serving cell is a cell in which the UE receives the RRC release message. The TMGI contained in the paging message refers to a TMGI contained in the pagingGroupList-r17 domain contained in the paging message. When a TMGI is included in the pagingGroupList-r17 field, an MBS multicast session indicating the TMGI indication is activated or data transmission is started. For an MBS multicast session configured to be received in an rrc_inactive state, when the UE receives a TMGI of the MBS multicast session included in a paging message, the UE further determines whether the paging message includes a inactiveReceptionAllowed field corresponding to the TMGI, and if the paging message includes a inactiveReceptionAllowed field corresponding to the TMGI or a inactiveReceptionAllowed field corresponding to the TMGI included in the paging message is set to "true", it indicates that the UE may receive the MBS multicast session in the rrc_inactive state when receiving the paging message. The inactiveReceptionAllowed field is contained in the pagingGroupList-v18xy field in the paging message, where x and y can be any natural number, e.g., xy is "00". pagingGroupList-v18xy and pagingGroupList-r17 have the same number and order of elements, a first element in pagingGroupList-v18xy corresponds to a first TMGI in pagingGroupList-r17, a second element in pagingGroupList-v18xy corresponds to a second TMGI in pagingGroupList-r17, and so on. The inactiveReceptionAllowed field is used to indicate whether a UE with a valid PTM configuration of the TMGI indicated in pagingGroupList (i.e., pagingGroupList-r 17) is camping on rrc_inactive to receive an MBS multicast session indicated by the TMGI.

For a UE configured with rrc_inactive to receive MBS multicast, when the UE performs an RRC restoration procedure, if the UE receives an RRC restoration message from a base station after transmitting an RRC restoration request message to the base station, the UE will restore the suspended multicast MRB. But how to handle those MRBs configured for MBS multicast sessions received at rrc_inactive when performing the RRC recovery procedure, which are not suspended, is a problem to be solved.

Example 6 is described in detail below.

Example 6

The UE receives the RRC resume RRCResume message from the base station, and the UE performs at least one of the following operations:

Operation 6-1 releases the multicast MRB that was not suspended. For UEs in rrc_inactive, the non-suspended multicast MRBs are those configured for MBS multicast sessions received in rrc_inactive. In addition, upon releasing the non-suspended multicast MRB, the UE may perform releasing the PDCP entity, RLC entity, and related MAC and physical layer configurations, and/or further perform releasing the SDAP entity and/or indicating user plane resources releasing the MBS multicast session ms-session id to an upper layer (e.g., NAS layer) if the SDAP entity associated with the released MRB does not have an associated MRB (i.e., no other MRB than the released MRB) for the corresponding MBS multicast session (i.e., the MBS-session id).

Operation 6-2-resume the suspended multicast MRB. After the UE previously received the RRC release message, MRBs for MBS multicast sessions that are not configured for rrc_inactive reception will be suspended. Thus, the recovered multicast MRB is the multicast MRB that was suspended after the RRC release message was previously received.

It may be provided that the UE performs operation 6-2 after performing operation 6-1.

It should be noted that, the RRC release message in each embodiment may be the same RRC release message.

In this disclosure, fields, information elements are used interchangeably.

It should be noted that, embodiments performed by the UE or the base station in the present disclosure may be performed by an RRC entity in the UE or the base station or performed at an RRC layer. In addition, the UE may receive an RRC release message before receiving the paging message.

Modification example

Next, a user equipment that can perform the method performed by the user equipment described in detail above of the present invention as a modification will be described with reference to fig. 6.

Fig. 6 is a block diagram showing a user equipment UE according to the present invention.

As shown in fig. 6, the user equipment UE60 comprises a processor 601 and a memory 602. The processor 601 may include, for example, a microprocessor, microcontroller, embedded processor, or the like. The memory 602 may include, for example, volatile memory (such as random access memory RAM), a Hard Disk Drive (HDD), non-volatile memory (such as flash memory), or other memory. The memory 602 has stored thereon program instructions. Which, when executed by the processor 601, may perform the above-described method performed by the user equipment as described in detail herein.

Next, a base station that can execute the method executed by the base station described above of the present invention as a modification will be described with reference to fig. 7.

Fig. 7 is a block diagram showing a base station according to the present invention.

As shown in fig. 7, the base station 70 includes a processor 701 and a memory 702. The processor 701 may include, for example, a microprocessor, microcontroller, embedded processor, or the like. The memory 702 may include, for example, volatile memory (such as random access memory RAM), a Hard Disk Drive (HDD), non-volatile memory (such as flash memory), or other memory. The memory 702 has stored thereon program instructions. Which, when executed by the processor 701, may perform the above-described method performed by the base station described in detail herein.

Specifically, the base station according to the present invention communicates with the user equipment UE. The base station sends an RRC release message to the UE, wherein the RRC release message comprises a first domain and does not comprise a second domain for carrying an MBS multicast configuration message, and the first domain indicates a multicast session or service which can be received in a current service cell when the UE is in an RRC inactive state, or indicates a multicast session or service which can be received when the current service cell is in an RRC inactive state before the UE acquires a multicast MCCH, or indicates a multicast session or service which can be received when the UE is in an RRC inactive state before the UE acquires the multicast MCCH. See above for details.

The method of the present disclosure and the apparatus involved have been described above in connection with the preferred embodiments. It will be appreciated by those skilled in the art that the methods shown above are merely exemplary and that the embodiments described above can be combined with one another without contradiction. The method of the present invention is not limited to the steps and sequences shown above.

In the embodiment of the present disclosure, in the case of including a plurality of operations, the embodiment of the present disclosure exemplarily lists the execution order of each operation, and an embodiment obtained by changing the execution order of each operation is also the protection scope of the present disclosure. In addition, in the case where a plurality of judgment conditions are included, an embodiment in which the execution order of each judgment condition is changed is also the scope of the present disclosure. Furthermore, in the present disclosure, the meaning of a field defined in one embodiment may also be applied to corresponding fields involved in other embodiments, unless specifically stated. In addition, in the embodiments of the present disclosure, "if the same is used", "when the same is met", "or" condition "can be replaced with" in the case of the same ". In embodiments of the present disclosure, embodiments in which "and" in some or all conditions is replaced with "or" are also within the scope of the protection of the present disclosure; embodiments resulting from "or" substitution of "and" in part or all of the conditions are also within the scope of the disclosure

In addition, the user equipment shown above may include more modules, for example, modules that may be developed or developed in the future that may be used for a base station, MME, or UE, and so on. The various identifiers shown above are merely exemplary and are not limiting, and the present disclosure is not limited to specific cells as examples of such identifiers. Many variations and modifications may be made by one of ordinary skill in the art in light of the teachings of the illustrated embodiments.

It should be understood that the above-described embodiments of the present disclosure may be implemented by software, hardware, or a combination of both software and hardware. For example, the various components within the base station and user equipment in the above embodiments may be implemented by a variety of devices including, but not limited to, analog circuit devices, digital Signal Processing (DSP) circuits, programmable processors, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), programmable logic devices (CPLDs), and the like.

In addition, the computer-executable instructions or programs running on the apparatus according to the present invention may be programs that cause a computer to implement the functions of the embodiments of the present invention by controlling a Central Processing Unit (CPU). The program or information processed by the program may be temporarily stored in a volatile store such as a random access memory RAM, a Hard Disk Drive (HDD), a nonvolatile store such as a flash memory, or other memory system.

Computer-executable instructions or programs for implementing the functions of the embodiments of the present invention may be recorded on a computer-readable storage medium. The corresponding functions can be realized by causing a computer system to read programs recorded on the recording medium and execute the programs. The term "computer system" as used herein may be a computer system embedded in the device and may include an operating system or hardware (e.g., peripheral devices). The "computer-readable storage medium" may be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a recording medium storing a program dynamically at a short time, or any other recording medium readable by a computer.

The various features or functional modules of the apparatus used in the embodiments described above may be implemented or performed by circuitry (e.g., single-chip or multi-chip integrated circuits). Circuits designed to perform the functions described herein may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The circuit may be a digital circuit or an analog circuit. Where new integrated circuit technologies are presented as an alternative to existing integrated circuits due to advances in semiconductor technology, one or more embodiments of the present invention may also be implemented using these new integrated circuit technologies.

Furthermore, the present invention is not limited to the above-described embodiments. Although various examples of the embodiments have been described, the present invention is not limited thereto. Fixed or non-mobile electronic devices installed indoors or outdoors may be used as terminal devices or communication devices such as AV devices, kitchen devices, cleaning devices, air conditioners, office devices, vending machines, and other home appliances, etc.

As above, the embodiments of the present invention have been described in detail with reference to the accompanying drawings. The specific structure is not limited to the above-described embodiment, but the present invention also includes any design modification without departing from the gist of the present invention. In addition, various modifications can be made to the present invention within the scope of the claims, and embodiments obtained by appropriately combining the technical means invented by the different embodiments are also included in the technical scope of the present invention. Further, the components having the same effects described in the above embodiments may be replaced with each other.

Claims

1. A method performed by a user equipment, UE, comprising:

receiving an RRC release message from the base station, and

If the RRC release message includes the first domain but does not include the second domain for carrying the MBS multicast configuration message, any of the following is considered to be true:

All the joined MBS multicast sessions are configured to be receivable in the RRC inactive state;

All configured MBS multicast sessions may be received in RRC inactive state;

all the added MBS multicast sessions are configured to be receivable in the RRC inactive state in the current serving cell;

all configured MBS multicast sessions are configured to be receivable in RRC inactive state at the current serving cell;

all the joined MBS multicast sessions are configured to be receivable in RRC inactive state in the current serving cell before acquiring the multicast MCCH, and

All configured MBS multicast sessions are configured to be receivable in RRC inactive state at the current serving cell before acquiring the multicast MCCH,

Wherein the first field indicates an MBS multicast session or service receivable in a current serving cell when the UE is in an RRC inactive state, or indicates an MBS multicast session or service receivable when the UE is in an RRC inactive state, or for indicating the MBS multicast session or service that the UE may receive when the current serving cell is in the RRC inactive state before the multicast MCCH is acquired, or for indicating the MBS multicast session or service that the UE may receive when the UE is in the RRC inactive state before the multicast MCCH is acquired.

2. The method of claim 1, wherein,

The configured MBS multicast session is an MBS multicast session configured when the UE is in an RRC connected state.

3. A method performed by a user equipment, UE, comprising:

receiving an RRC release message from the base station, and

All configured MBS multicast sessions are not configured to be receivable in RRC inactive state;

All configured MBS multicast sessions are not configured to be receivable in the RRC inactive state in the current serving cell;

All configured MBS multicast sessions are not configured to be receivable in RRC inactive state in the current serving cell before acquiring the multicast MCCH;

all the joined MBS multicast sessions are not configured to be receivable in RRC inactive state in the current serving cell, and

All the joined MBS multicast sessions are not configured to be receivable in RRC inactive state at the current serving cell before the multicast MCCH is acquired,

4. A method performed by a user equipment, UE, comprising:

receiving an RRC release message from the base station, and

all configured MBS multicast sessions are indicated to stop detecting G-RNTIs;

all the added MBS multicast sessions are indicated to stop detecting G-RNTIs;

All established MRB-associated MBS multicast sessions are indicated to stop detecting G-RNTI, and

All configured MBS multicast sessions are not instructed to stop detecting G-RNTIs,

5. A method performed by a user equipment, UE, comprising:

receiving an RRC release message from the base station, and

If the RRC release message contains the first field and does not contain at least one PTM configuration of an MBS multicast session configured for RRC inactive state reception and not indicated as stopped detection of G-RNTI, an MBS multicast configuration message is acquired on the multicast MCCH,

6. A method performed by a user equipment, UE, comprising:

receiving an RRC release message from the base station, and

If the RRC release message includes a first field and provides a multicast PTM configuration for at least one MBS multicast session, and the UE selects a cell to receive the RRC release message, performing at least one of:

Applying multicast PTM configuration contained in said RRC release message, and

If at least one MBS multicast session is not indicated to not stop detecting G-RNTI, detecting a multicast MCCH-RNTI,

7. A user equipment, comprising:

Processor, and

A memory in which instructions are stored,

Wherein the instructions, when executed by the processor, perform the method of any one of claims 1 to 6.

8. A method performed by a base station in communication with a user equipment, UE, the method comprising:

An RRC release message is sent to the UE,

The RRC release message includes a first domain but does not include a second domain for carrying MBS multicast configuration messages,

9. A base station, comprising:

Processor, and

A memory in which instructions are stored,

Wherein the instructions, when executed by the processor, perform the method of claim 8.