User equipment, method executed by user equipment, base station, and method executed by base station

Abstract

Provided in the present disclosure are a user equipment (UE), a method executed by a UE, a base station, and a method executed by a base station. The UE comprises a processor, which processor is configured to: receive an RRC message, and stop an MBS multicast DRX timer if the UE is configured with a multicast reception in RRC_INACTIVE, wherein the RRC message is an RRCSetup message for setting up an SRB1, or an RRC recovery message for recovering a suspended RRC connection.

Description

User equipment, method executed by the user equipment, base station, and method executed by the base station Technical Field

[0001] The present invention relates to the technical field of wireless communications, and more particularly, to a method executed by a user equipment and the user equipment. Background Art

[0002] A research project (SI) on improving the 5G multicast broadcast service architecture (see SP-190625) has been approved. One of the objectives of this SI (referred to as Objective A) is to support universal MBS services in the 5GS. Use cases that could benefit from this feature include (but are not limited to) public safety, vehicle-to-everything (V2X) applications, transparent IPv4 / IPv6 multicast transmission, IPTV, wireless software delivery, group communications, and IoT applications. Accordingly, at the 3rd Generation Partnership Project (3GPP) RAN#86 plenary meeting, a work item on NR multicast and broadcast service (NR MBS) was proposed and approved (see non-patent document RP-193248: New WID: NR Multicast and Broadcast Service). This work item aims to provide support for Objective A in the RAN. The objectives of this work item have been largely achieved, and the relevant solutions are described in 3GPP Release 17 technical documents such as TS 38.300-h70, TS 38.331-h70, and TS 38.321-h70. At the 3GPP RAN#94 plenary meeting, a work item titled Enhanced NR Multicast and Broadcast Services was approved (see non-patent literature: RP-213568: New WID: Enhancements of NR Multicast and Broadcast Services). This work item aims to further enhance MBS Multicast and Broadcast Services in Release 17, with one of its goals being to support user equipment receiving MBS multicast services / sessions even when RRC is not active.

[0003] The present invention discusses issues related to RAN supporting user equipment to receive MBS multicast services / sessions in an RRC inactive state. Summary of the Invention

[0004] In order to solve at least part of the above problems, the present invention provides a method performed by a user equipment and the user equipment.

[0005] According to a first aspect of the present disclosure, a method performed by a user equipment (UE) is provided, comprising: the UE receiving a radio resource control (RRC) message from a base station; and when the UE is configured to receive an MBS multicast session in RRC_INACTIVE, the UE performing a multicast media access control (MAC) reset.

[0006] In the method of the first aspect above, the multicast MAC reset includes at least one of the following operations:

[0007] Operation 1-1: Stop all MBS multicast discontinuous reception (DRX) timers.

[0008] Operation 1-2: Clear the soft buffers of all downlink DL HARQ processes that meet the following condition: the downlink allocation most recently received by the DL HARQ process is a G-RNTI for a MAC entity.

[0009] Operation 1-3: Clear the soft buffers of all DL HARQ processes (except the soft buffers of the DL HARQ processes whose most recently received downlink allocation is for the C-RNTI or CS-RNTI of the MAC entity).

[0010] Operation 1-4: For each DL HARQ process that meets the following condition, consider the next received downlink allocation to be the first transmission: the downlink allocation most recently received by the DL HARQ process is the G-RNTI for the MAC entity.

[0011] In the method of the first aspect above, the RRC message is an RRC recovery message or an RRC establishment message.

[0012] According to a second aspect of the present disclosure, a method performed by a user equipment (UE) is provided, comprising: the UE receiving a radio resource control (RRC) message from a base station; and, when the RRC message includes an mrb-ToAddModList field, performing at least one of the following operations on each element in the mrb-ToAddModList arranged in order of entries:

[0013] Operation 2-1: If at least one multicast MRB among the multicast MRBs configured by the UE is not configured with an MRB identifier, and / or the mrb-ToAddModList contains the MRB identifier of the multicast MRB not configured with an MRB identifier, associate the MRB identifier with the corresponding multicast MRB.

[0014] Operation 2-2: The MRB identifier is considered to be part of the UE configuration, or the MRB identifier associated with the multicast MRB that is not configured with the MRB identifier is considered to be part of the UE configuration.

[0015] According to a third aspect of the present disclosure, a method performed by a user equipment (UE) is provided, comprising: the UE receiving a radio resource control (RRC) message from a base station; and if the RRC message includes a fullConfig field, performing at least one of the following operations for each mbs-SessionId that is part of a current UE configuration and associated with a multicast MRB:

[0016] Operation 3-1: Release the service data adaptation protocol entity.

[0017] Operation 3-2: For each multicast MRB associated with the MBS multicast session configured for RRC_INACTIVE reception, if the multicast MRB release is caused by full configuration and / or the full configuration occurs during the RRC recovery procedure, release the PDCP entity.

[0018] According to a fourth aspect of the present disclosure, a user equipment (UE) is proposed, comprising: a processor; and a memory storing instructions; wherein the instructions, when executed by the processor, execute the method described in the context.

[0019] Effects of the Invention

[0020] According to the method performed by the user equipment and the user equipment of the present disclosure, when the user equipment UE recovers or establishes an RRC connection, it is possible to manage / process a multicast MRB configured for RRC_INACTIVE reception of MBS multicast. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] FIG1 is a schematic flow chart showing a method executed by a user equipment in embodiment 1 of the present invention.

[0023] FIG2 is a schematic flow chart showing a method executed by a user equipment in embodiment 2 of the present invention.

[0024] FIG3 is a schematic flowchart showing a method executed by a user equipment in embodiment 3 of the present invention.

[0025] FIG4 is a block diagram showing a user equipment UE according to the present invention. DETAILED DESCRIPTION

[0026] The following describes some of the terms involved in the present invention. For specific meanings, please refer to the latest relevant 3GPP documents, such as TS38.300, TS38.321, TS38.323, and TS38.331. Furthermore, the embodiments of the present invention are described using broadcast / multicast services as an example. However, the embodiments of the present invention are not limited to broadcast / multicast services and can also be applied to other application scenarios.

[0027] UE: User Equipment.

[0028] RRC: Radio Resource Control.

[0029] RRC_CONNECTED: RRC connected state.

[0030] RRC_INACTIVE: RRC inactive state.

[0031] RRC_IDLE: RRC idle state.

[0032] RAN: Radio Access Network.

[0033] NR: New RAT, new radio access technology.

[0034] MBS: Multicast / Broadcast Services. Multicast can also be called multicast.

[0035] AS: Access Stratum, access layer or access layer.

[0036] NAS: Non Access Stratum, non-access layer or non-access layer.

[0037] RB: Radio Bearer. DRB is a data radio bearer.

[0038] MBS Radio Bearer (MRB): A radio bearer configured for MBS delivery. MRBs are classified into multicast MRBs and broadcast MRBs. A multicast MRB is a radio bearer configured for MBS multicast transmission, while a broadcast MRB is a radio bearer configured for MBS broadcast transmission.

[0039] TMGI: Temporary Mobile Group Identity, used to identify an MBS session.

[0040] RNTI: Radio Network Temporary Identifier, wireless network temporary identifier.

[0041] PTM: Point to Multipoint, a delivery method for MBS services. In PTM, the gNB delivers a single copy of MBS data packets to a group of UEs. UEs use a G-RNTI or G-CS-RNTI to receive PTM transmissions. For example, the gNB uses the G-RNTI-based group-common physical downlink control channel (PDCCH) to schedule the same G-RNTI-based group-common physical downlink shared channel (PDSCH).

[0042] PCell: Primary Cell, MCG cell, operates on the primary frequency, in which the UE performs the initial connection establishment process or initiates the connection re-establishment process.

[0043] G-RNTI: Group RNTI, group RNTI, used to scramble the scheduling and transmission of PTM for one or more MBS multicast services.

[0044] G-CS-RNTI: Group configuration scheduling RNTI, used to scramble the semi-static scheduling SPS group common physical downlink shared channel PDSCH of one or more MBS multicast services and activate / deactivate the SPS group common PDSCH.

[0045] MTCH: MBS Traffic Channel, MBS traffic channel, is a PTM downlink channel used to transmit MBS data of a multicast session or broadcast session from the network to the UE. Unless otherwise specified, the MTCH involved in the embodiments of the present disclosure refers to the multicast MTCH used to transmit MBS multicast sessions.

[0046] MCCH: MBS Control Channel, MBS control channel, is 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 includes broadcast MCCH and multicast MCCH.

[0047] RLC: Radio Link Control. An RLC entity can be configured in one of three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). The corresponding RLC entities are referred to as TM RLC entities, UM RLC entities, and AM RLC entities. Typically, an AM RLC entity or UM RLC entity is associated or configured for a multicast MRB, or a UM RLC entity is associated or configured for a multicast MRB receiving an RRC_INACTIVE MBS multicast session.

[0048] The RRC recovery request message RRCResumeRequest or RRCResumeRequest1 is used to request the resumption of a suspended RRC connection or to perform a RAN-based notification area RNA update. When the UE initiates an RRC connection recovery request, if the SIB1 contains the useFullResumeID field, the RRCResumeRequest1 message is used and the resumeIdentity field in the RRCResumeRequest1 message is set to the fullI-RNTI stored by the UE, otherwise RRCResumeRequest is used and the resumeIdentity field in the RRCResumeRequest message is set to the stored shortI-RNTI. The RRC release message RRCRelease is used to command the release of an RRC connection or suspend an RRC connection. The RRC reconfiguration message RRCReconfiguration is used to command the modification of the RRC connection. The RRC establishment message RRCSetup is used to establish SRB1. SRBl is used for RRC messages (the RRC messages may contain piggybacked NAS messages) and NAS messages before establishing SRB2, both of which use the dedicated control channel DCCH logical channel. The RRC recovery message RRCResume is used to restore a suspended RRC connection. In the present disclosure, the useFullResumeID field indicates the recovery identifier and recovery request message used. When the field is included in SIB1, fullI-RNTI and RRCResumeRequest1 message are used. When the field is not included in SIB1, shortI-RNTI and RRCResumeRequest message are used. ShortI-RNTI uses fewer bits than I-RNTI-Value to identify the suspended UE context of a UE in an RRC inactive state. The RRC recovery process (i.e., the RRC connection recovery process) is used to restore a suspended RRC connection, including restoring SRB(s), DRB(s) and multicast MRB(s), or performing RNA updates, or implementing MBS multicast reception requests, or initiating small data transmission SDT in the RRC_INACTIVE state, etc. During the RRC recovery process, the UE sends 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 rejection message RRCReject from the base station.

[0049] In the present invention, network, base station and RAN can be used interchangeably. The network can be a long-term evolution LTE network, a NR network, an enhanced long-term evolution eLTE network, or other networks defined in subsequent evolution versions of 3GPP.

[0050] Currently, NR MBS services include MBS broadcast (also known as MBS broadcast session, broadcast MBS, MBS broadcast service, or MBS broadcast service) and MBS multicast (also known as MBS multicast session, multicast MBS, MBS multicast service, or MBS multicast service). MBS broadcast provides a downlink-only MBS transmission mode for services with low quality of service (QoS), allowing UEs in RRC connected, RRC idle, and RRC inactive states to receive the MBS service. UEs obtain MBS broadcast configuration information broadcast by the network through the MBS control channel (MCCH).

[0051] Release 17 does not support UEs receiving MBS multicast sessions in the RRC inactive state. Therefore, before receiving MBS multicast services (i.e., MBS multicast sessions), the UE needs to establish an RRC connection with the base station. The base station (i.e., the network) then configures the resources or PTM configuration for the UE to receive MBS multicast services through dedicated RRC signaling (also known as RRC messages, such as RRC reconfiguration messages). The MBS radio bearer (MRB) for receiving these MBS multicast services is also configured for the UE by the base station through dedicated RRC signaling. Only UEs in the RRC connected state and configured with MRBs can receive the corresponding MBS multicast services. Therefore, when an MBS multicast session is activated by the core network or the base station has MBS multicast session data to send, the network that supports MBS multicast notifies UEs in the RRC idle state or RRC inactive state through a group notification mechanism. Upon receiving the group notification, UEs that have joined the MBS multicast session or are interested in the MBS multicast session establish or resume an RRC connection with the network to receive the corresponding MBS multicast session. The group notification is addressed using the P-RNTI on the Physical Downlink Control Channel (PDCCH), and the UE monitors the paging channel. The paging message used for group notification contains the MBS session identifier (TMGI), which is used to page all UEs that have joined the relevant MBS multicast session and are in RRC Idle or RRC Inactive state. In other words, the base station does not page UEs individually (for the purpose of UEs receiving the MBS multicast session).

[0052] Release 18 supports UEs receiving MBS multicast sessions in an RRC-inactive state. For MBS multicast sessions configured for reception in an RRC-inactive state, the base station can provide or configure PTM configuration information (also known as MBS multicast session configuration information or MBS multicast session PTM configuration or MBS multicast configuration) for the UE to receive the MBS multicast session through dedicated RRC signaling (e.g., RRCRelease message) or through the multicast MBS control channel MCCH (i.e., multicast MCCH). The information required to obtain the multicast MCCH (or multicast MCCH configuration) can be configured for the UE through dedicated RRC signaling or a system information block (denoted as SIB24). That is, SIB24 contains the information required to obtain the multicast MCCH / MTCH (i.e., MCCH and / or MTCH) configuration for MBS multicast reception in an RRC-inactive state. The PTM configuration information may include configuration information of the MRB corresponding to the MBS multicast session and / or the identifier TMGI of the MBS multicast session and its corresponding G-RNTI / G-CS-RNTI and / or fields of DRX configuration information. For example, the PTM configuration of a certain MBS multicast session is information related to the reception of the MBS multicast session contained in the MBS multicast configuration MBSMulticastConfiguration message. The MBSMulticastConfiguration message contains the control information applicable for MBS multicast services transmitted via multicast MRBs for RRC_INACTIVE UEs. The MBSMulticastConfiguration message may be transmitted on the multicast MCCH or included in the RRC release message. The multicast MCCH is 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.For an MBS multicast session received in the RRC_INACTIVE state, in the embodiments of the present disclosure, the MBS multicast session being in an active state or being activated means that the MBS multicast session is ongoing or about to start, the UE starts receiving (or is receiving) the MBS multicast session, or the UE starts detecting the G-RNTI corresponding to the MBS multicast session, or the UE starts detecting (monitoring) the multicast-MCCH-RNTI of the multicast MCCH. The network can instruct the UE that the MBS multicast is activated or data transmission is resumed through RRC signaling (e.g., an RRC release message) or through a paging message. For example, including the TMGI of the MBS multicast session in a paging message indicates that the MBS multicast session is activated or data transmission is resumed, and not including the stopMonitoringRNTI field for indicating the stop of detection of the corresponding G-RNTI for the MBS multicast session in the RRC release message indicates that the MBS multicast session is activated or data transmission is resumed. After receiving the indication, the UE starts receiving the MBS multicast session (i.e., the UE starts detecting the G-RNTI corresponding to the MBS multicast session). The MBS multicast activation described in the embodiments of the present disclosure also applies to the case of resuming data transmission of an MBS multicast session, which will not be described in detail below. In the embodiments of the present disclosure, the MBS multicast session being in an inactive state or being deactivated means that the MBS multicast session has ended or suspended data transmission or the UE has stopped receiving the MBS multicast session (i.e., the UE has stopped detecting the G-RNTI corresponding to the MBS multicast session). The network associates an indication identifier with each MBS multicast session in the multicast MCCH message to explicitly indicate that the MBS multicast session is deactivated or stops detecting the G-RNTI corresponding to the MBS multicast session. After receiving the indication, the UE stops receiving the MBS multicast session. The UE stopping receiving the MBS multicast session may be the UE stopping detecting the G-RNTI or G-CS-RNTI corresponding to the MBS multicast session. Therefore, in the present disclosure, the indication of deactivation of the MBS multicast session or stopping data transmission is an indication instructing the UE to stop detecting the G-RNTI or G-CS-RNTI associated with the MBS multicast session. Furthermore, an indication that an MBS multicast session is activated or data transmission resumes is an indication to begin detecting the G-RNTI corresponding to the MBS multicast session. Deactivation of an MBS multicast session includes a situation where the MBS multicast session is temporarily not transmitting data, and activation of an MBS multicast session includes a situation where the MBS multicast session resumes data transmission. In this disclosure, a multicast session or service is an MBS multicast session or service. The following embodiments use G-RNTI as an example. Embodiments where G-RNTI is replaced with G-CS-RNTI are also within the scope of this disclosure.

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

[0054] For a UE configured with an MBS multicast session that can be received in the RRC_INACTIVE state, when the MBS multicast session is activated or data transmission is resumed, if the MBS multicast session is configured and / or allowed to be received in the RRC_INACTIVE state and / or the UE has a (valid) PTM configuration for the MBS multicast session, the MBS multicast session can be directly received without establishing an RRC connection with the base station. The network can configure the PTM configuration information (for example, contained in an MBSMulticastConfiguration message) for the MBS multicast session received in the RRC_INACTIVE state for the UE via the multicast MCCH and / or dedicated RRC signaling (for example, an RRC release message, an RRC reconfiguration message). The MBS multicast configuration message MBSMulticastConfiguration can be transmitted on the multicast MCCH (in this case, the MBSMulticastConfiguration message can be called a multicast MCCH message) or included in an RRC release message. If the RRC release message is used to configure the PTM configuration information of the MBS multicast session received in the RRC_INACTIVE state for the UE, the network may include the MBSMulticastConfiguration message in the RRC release message sent to the UE.

[0055] In the disclosed embodiments, a multicast MCCH-RNTI (i.e., Multicast MCCH-RNTI) is used for dynamically scheduled multicast MCCH signaling and / or multicast MCCH change notification, or for dynamically scheduled MCCH signaling and / or MCCH change notification, or for scrambling a DCI or a CRC of a DCI format, or for scrambling a PDCCH for MBS multicast transmission, or for scrambling a DCI or a CRC of a DCI format for MBS multicast transmission, or for scheduling a PDSCH for transmission of an MBS multicast session. The DCI or DCI format may be DCI format 40 or DCI format 4_1.

[0056] When a UE in RRC_INACTIVE receives a paging message from a base station, if the paging message includes the TMGI of one or more MBS sessions to which the UE has joined (the TMGI is included in the pagingGroupList field in the paging message), and further, if the UE is not configured to receive MBS multicast in RRC_INACTIVE (that is, the most recently received RRC release message does not include the multicastConfigInactive field), or there is at least one MBS multicast session to which the UE has joined, indicated by the TMGI included in the paging message, which is not indicated by the paging message as receivable in RRC_INACTIVE (that is, the paging message does not include the inactiveReceptionAllowed field corresponding to at least one MBS session indicated by the TMGI included in the paging message to which the UE has joined), and if it is also satisfied that the paging message does not include the PagingRecordList field or the ue-Identity included in any pagingRecord in the PagingRecordList field contained in the paging message does not match the UE identity allocated by an upper layer and the full-RNTI stored by the UE, then the RRC connection recovery procedure is initiated. Among them, the PagingRecordList domain is a pagingRecord list, and the pagingRecord domain contains the ue-Identity domain. The ue-Identity domain is used to indicate the ng-5G-S-TMSI or fullI-RNTI of the UE being paged. The fullI_RNTI domain carries the suspended UE context allocated by the base station to the UE through the RRC release message for identifying the UE in RRC_INACTIVE. The ng-5G-S-TMSI contains a 5G temporary mobile subscription identity 5G-S-TMSI, which is a temporary UE identity provided by the 5GC and is used to uniquely identify a UE in the tracking area.

[0057] The UE receives an RRC release message from the base station, and the multicastConfigInactive field included in the RRC release message indicates that the UE can receive multicast sessions or services in the current serving cell (i.e., the cell receiving the RRC release message) when the UE is in RRC_INACTIVE. When the multicastConfigInactive field is included in the received RRC release message, it indicates that the UE has been configured to receive MBS multicast in RRC_INACTIVE.

[0058] In the present disclosure, embodiments in which the function of the multicastConfigInactive field is replaced by one of the following are also within the scope of the present disclosure:

[0059] The multicastConfigInactive field indicates the multicast sessions or services that the UE can receive in the current serving cell when it is in RRC_INACTIVE, or the multicastConfigInactive field is used to indicate the multicast sessions or services that the UE can receive when it is in RRC_INACTIVE, or the multicastConfigInactive field is used to indicate the multicast sessions or services that the UE can receive when the current serving cell is in RRC_INACTIVE before obtaining the multicast MCCH, or the multicastConfigInactive field is used to indicate the multicast sessions or services that the UE can receive when it is in RRC_INACTIVE before obtaining the multicast MCCH.

[0060] Optionally, the multicastConfigInactive field also contains the corresponding configurations for these multicast sessions, which are valid in the current serving cell. The multicastConfigInactive field may contain two fields: the inactivePTM-Config field and the inactiveMCCH-Config field. The inactivePTM-Config field carries the MBSMulticastConfiguration message. The inactiveMCCH-Config field carries the system information SIB24.

[0061] For a UE configured to receive an MBS multicast session in RRC_INACTIVE, the UE receives a paging message to learn whether the MBS multicast session it has joined is activated and allowed to be received in the RRC_INACTIVE state. Specifically, if the paging message contains the TMGI of the MBS multicast session the UE has joined (the UE considers the MBS multicast session to be activated at this time) and its corresponding inactiveReceptionAllowed field, the UE considers the MBS multicast session to be activated and allowed to be received in RRC_INACTIVE, or the UE can receive the MBS multicast session in RRC_INACTIVE, or the UE starts to detect the G-RNTI of the MBS multicast session in RRC_INACTIVE. It should be noted that whether the UE receives the MBS multicast session in RRC_INACTIVE also depends on whether, when the UE receives the paging message, all other MBS multicast sessions to which the UE has joined, which are included in the paging message, are indicated as being receivable in RRC_INACTIVE. If at least one of the MBS multicast sessions to which the UE has joined, as indicated by the TMGI contained in the paging message, is not indicated by the paging message as being receivable in RRC_INACTIVE (i.e., the paging message does not include an inactiveReceptionAllowed field corresponding to at least one MBS session to which the UE has joined, as indicated by the TMGI contained in the paging message), then for other MBS multicast sessions to which the UE has joined, as indicated by the TMGI contained in the paging message, even if the paging message includes their corresponding inactiveReceptionAllowed fields, the UE will not receive these MBS sessions in RRC_INACTIVE. In other words, only when the inactiveReceptionAllowed fields corresponding to all MBS multicast sessions to which the UE has joined, as indicated by the TMGI contained in the paging message, are included in the paging message, will the UE receive in RRC_INACTIVE the MBS multicast sessions to which the UE has joined, as indicated by the TMGI contained in the paging message. The inactiveReceptionAllowed field is used to indicate whether a UE with a valid PTM configuration of the TMGI indicated in the pagingGroupList (ie, pagingGroupList-r17) included in the paging message stays in RRC_INACTIVE to receive the MBS multicast session indicated by the TMGI.

[0062] Currently, the UE can be instructed to start detecting the G-RNTI of the MBS multicast session by including the TMGI of the MBS multicast session in the paging message (that is, if the paging message received by the UE contains a TMGI of the MBS multicast session allowed / configured for reception in RRC_INACTIVE, it indicates that the UE has received an instruction to start detecting the G-RNTI of the MBS multicast session). Alternatively, whether to stop detecting the G-RNTI corresponding to the MBS multicast session can be indicated in the MBSMulticastConfiguration message. Specifically, for an MBS multicast session whose TMGI is included in the MBSMulticastConfiguration message, if the MBSMulticastConfiguration message also includes a stopMonitoringRNTI field for the MBS multicast session, this indicates that the UE has received an instruction to stop detecting the G-RNTI for the MBS multicast session (i.e., to stop detecting the G-RNTI for the MBS multicast session). Otherwise (i.e., the MBSMulticastConfiguration message does not include a stopMonitoringRNTI field for the MBS multicast session), this indicates that the UE has not received an instruction to stop detecting the G-RNTI for the MBS multicast session. The stopMonitoringRNTI field instructs the UE to stop detecting the G-RNTI for the corresponding MBS multicast session. Stopping detection of the G-RNTI for the MBS multicast session is indicated by associating / configuring a stopMonitoringRNTI field for each MBS multicast session. If an MBS multicast session is not associated / configured with a corresponding stopMonitoringRNTI field, this indicates that the MBS multicast session has not been instructed to stop detecting the G-RNTI. The MBSMulticastConfiguration message may be transmitted on the multicast MCCH, or may be included in an RRC release message for transmission. Specifically, the MBSMulticastConfiguration message may be included in the MulticastConfigInactive field in the suspendConfig field in the RRC release message.Among them, the suspendConfig field indicates the configuration of the RRC_INACTIVE state; the MulticastConfigInactive field is used to indicate one or more MBS multicast services that can be received in RRC_INACTIVE (or one or more MBS multicast services that can be received in RRC_INACTIVE for the current serving cell or one or more MBS multicast services that can be received in RRC_INACTIVE for the current serving cell before obtaining the multicast MCCH). Optionally, it also includes the configuration of the MBS multicast service (or the configuration of the MBS multicast service for the current serving cell or the configuration of the MBS multicast service that is valid for the current serving cell). The current serving cell refers to the cell in which the UE receives the RRC release message. The serving cell or the cell in which the UE last or previously received the RRC release message may refer to the cell in which the UE last or previously received the RRC release message or the primary cell PCell. If the RRC release message received by the UE contains the MBSMulticastConfiguration message or the MulticastConfigInactive field, the UE is considered to be configured to receive MBS multicast or multicast session in RRC_INACTIVE mode; or if the RRC release message received by the UE (or the MBSMulticastConfiguration message contained in the RRC release message) contains the TMGI, the UE is considered to be configured to receive MBS multicast in RRC_INACTIVE mode. It should be noted that the UE obtaining the multicast MCCH means that the UE obtains the MBSMulticastConfiguration message from the multicast MCCH.

[0063] For a UE configured to receive an MBS multicast session in RRC_INACTIVE, when the UE recovers from RRC_INACTIVE to RRC_CONNECTED (i.e., the UE initiates the RRC connection recovery process to restore the UE to the RRC connected state), how to handle the multicast MRBs configured for RRC_INACTIVE reception is a problem that needs to be solved. If the multicast MRBs are deleted when the RRC connection is restored (e.g., when an RRC recovery message is received), but the soft buffer of the downlink DL HARQ process for the multicast session received in RRC_INACTIVE may contain data for the multicast session, and the downlink DL HARQ process NDI is stateful, when the UE enters the RRC connected state, the state of the MAC entity or HARQ process of the UE and the base station will be inconsistent. If the UE retains the multicast MRB when resuming the RRC connection (e.g., receiving an RRC resume message), since the MRB configured for the RRC_INACTIVE MBS multicast session does not need to be configured with the MRB identifier mrb-Identity, but the base station manages (including adding, modifying, deleting, etc.) the multicast MRB of the UE in RRC_CONNECTED through the MRB identifier. Therefore, how to manage the MRB configured for the RRC_INACTIVE MBS multicast session of the UE in RRC_CONNECTED is also a problem that needs to be solved.

[0064] In response to the above-mentioned problems in the prior art, the present disclosure proposes the following embodiments, but the following embodiments are only for illustration and are not intended to limit the scope of protection of the present invention.

[0065] The following embodiments are provided to solve the above problems. In addition, the following embodiments are merely examples and are not intended to limit the present invention.

[0066] Example 1

[0067] Embodiment 1 of the present disclosure is described in detail below with reference to the accompanying drawings. FIG1 is a schematic diagram illustrating the basic process of a method performed by a user equipment UE in embodiment 1 of the present disclosure. As shown in FIG1 , the method performed by the user equipment in embodiment 1 may generally include the following steps:

[0068] Step 101: The UE receives a radio resource control (RRC) message from a base station. The RRC message may be an RRC resume message or an RRC setup message.

[0069] Step 103: If the UE is configured to receive the MBS multicast session in RRC_INACTIVE, the UE performs a multicast Media Access Control (MAC) reset.

[0070] In the embodiment of the present disclosure, the multicast MAC reset is performed by the UE's RRC layer (or entity) instructing the MAC layer (or entity). The multicast MAC reset includes at least one of the following operations (or if the upper layer requests to perform the multicast MAC reset, the MAC entity performs at least one of the following operations):

[0071] Operation 1-1: Stop all MBS multicast discontinuous reception DRX timers. Specifically, stop all timers associated with MBS multicast sessions or MBS multicast sessions or G-RNTIs configured for RRC_INACTIVE reception, or stop all timers started for MBS multicast session reception under RRC_INACTIVE, or stop all timers related to receiving MBS multicast sessions under RRC_INACTIVE. The timers may include one or more of the following: a timer drx-HARQ-RTT-TimerDL-PTM for the minimum duration before the MAC entity expects DL multicast allocation for HARQ retransmission, a timer drx-onDurationTimerPTM for the duration at the start of the discontinuous reception DRX cycle, a timer drx-RetransmissionTimerDL-PTM for the maximum duration before receiving a DL multicast retransmission, and a timer drx-InactivityTimerPTM for the duration after the PDCCH opportunity for the PDCCH to indicate a new DL multicast transmission of the MAC entity. It should be noted that the operation of stopping the timer is performed only when the timer is running.

[0072] Operation 1-2: Clear the soft buffers of all downlink DL HARQ processes that meet the following conditions: the data or transport block TB or downlink assignment (DL assignment) most recently received by the DL HARQ process is the G-RNTI (or G-RNTI scrambled or G-RNTI addressed) for the MAC entity. Optionally, the G-RNTI is the G-RNTI associated with the MBS multicast session configured for RRC_INACTIVE reception.

[0073] Operation 1-3: Clear the soft buffers of all downlink DL HARQ processes (except the soft buffers of the DL HARQ processes whose most recently received data or transport block TB or downlink allocation is for the C-RNTI or CS-RNTI of the MAC entity (or scrambled by C-RNTI or CS-RNTI or addressed by C-RNTI or CS-RNTI)).

[0074] Operation 1-4: For each downlink DL HARQ process that meets the following conditions, the next received TB or downlink allocation is considered to be the first transmission (first transmission): the TB or downlink allocation most recently received by the downlink DL HARQ process is for the G-RNTI of the MAC entity (or scrambled by the G-RNTI of the multicast session or addressed by the G-RNTI). Optionally, the G-RNTI is the G-RNTI associated with the MBS multicast session configured for RRC_INACTIVE reception.

[0075] Optionally, before step 101, the base station configures the UE to receive the MBS multicast session in RRC_INACTIVE through an RRC message, such as an RRC release message.

[0076] [Variation of Example 1]

[0077] An embodiment obtained by replacing step 103 with one of steps 103a-103d:

[0078] Step 103a: If the RRC message is a response message to an RRC resume request message, and further, if the UE is configured to receive an MBS multicast session in RRC_INACTIVE, the UE performs a multicast MAC reset.

[0079] Step 103b: If the RRC message is a response message to the RRC resume request message, and further, if the UE is configured to receive the MBS multicast session in RRC_INACTIVE, the UE performs a MAC reset.

[0080] Step 103c: If the RRC message is a response message to an RRC resume request message, and further, if the UE is configured to receive the MBS multicast session in RRC_INACTIVE, a predefined MAC cell group configuration is applied. The predefined (default) MAC cell group configuration may be the following configuration (for the meaning of the fields involved in the following configuration, see TS 38.331-h60):

[0081] Step 103d: If the UE is configured to receive the MBS multicast session in RRC_INACTIVE, the UE performs a MAC reset.

[0082] Optionally, in step 103 or 103a-103d, if the UE is configured to receive the MBS multicast session in RRC_INACTIVE and / or the UE is configured with a multicast MRB for receiving the multicast session in RRC_INACTIVE, the multicast MRB configured for receiving the multicast session in RRC_INACTIVE is released.

[0083] In the embodiment of the present disclosure, the UE performing multicast MAC reset may be replaced by one of the following: the UE performing MAC reset and applying a predefined MAC cell group configuration (default MAC Cell Group configuration).

[0084] Example 2

[0085] Embodiment 2 of the present disclosure is described in detail below with reference to the accompanying drawings. FIG2 is a schematic diagram illustrating the basic process of a method performed by a user equipment UE in embodiment 2 of the present disclosure. As shown in FIG2 , the method performed by the user equipment in embodiment 2 may generally include the following steps:

[0086] Step 201: The UE receives an RRC message from a base station. The RRC message may be an RRC recovery message or an RRC reconfiguration message. The RRC reconfiguration message may be included in the RRC recovery message.

[0087] Step 203: If the RRC message contains the mrb-ToAddModList field, the UE shall perform at least one of the following operations for each element in the order of entry in the list mrb-ToAddModList:

[0088] Operation 2-1: If at least one multicast MRB among the multicast MRBs configured by the UE is not configured with an MRB identifier (i.e., mrb-Identity), and / or if the mrb-ToAddModList contains the MRB identifier of the multicast MRB not configured with an MRB identifier (this is indicated by the multicast session or TMGI associated with the multicast MRB not configured with an MRB identifier, i.e., the mrb-ToAddModList contains the MRB identifier of the multicast MRB associated with the MBS multicast session indicated by the TMGI), then the MRB identifier is associated with the corresponding multicast MRB. Specifically, if the TMGI included in the mrb-ToAddModList is the same as the TMGI of the MBS multicast session associated with the multicast MRB not configured with an MRB identifier, then the UE sequentially associates the MRB identifiers for the TMGIs included in the mrb-ToAddModList with the multicast MRBs not configured with an MRB identifier (or configured multicast MRBs) of the MBS multicast session indicated by the TMGI. For example, the MRB identifiers for the TMGI included in the mrb-ToAddModList are associated with the multicast MRBs that are not configured with MRB identifiers in ascending order, and the MRBs that are not configured with MRB identifiers may be arranged in the order configured by MBSMulticastConfiguration. The multicast MRBs that are not configured with MRB identifiers may be MRBs associated with an MBS multicast session that is configured for RRC_INACTIVE reception.

[0089] Operation 2-2: The MRB identifier is considered to be part of the UE configuration, or the MRB identifier associated with the multicast MRB that is not configured with the MRB identifier is considered to be part of the UE configuration.

[0090] Among them, the mrb-ToAddModList field contains the configuration information of a group of multicast MRBs that need to be added or modified, and the configuration information of the multicast MRB may include at least one of the following: mbs-SessionId field, mrb-Identity, mrb-IdnentityNew, reestablishPDCP, recoverPDCP, and PDCP-Config for indicating the multicast MBS session associated with the bearer (i.e., the multicast MRB).

[0091] In the disclosed embodiments, the mrb-Identity field is used by the UE to identify a multicast MRB. The mrb-IdnentityNew field is used to indicate the changed identity (i.e., the new identity) when the mrb-Identity of a multicast MRB needs to be changed. reestablishPDCP is used to indicate that a Packet Data Convergence Protocol (PDCP) entity needs to be reestablished. recoverPDCP instructs the PDCP entity to perform recovery. PDCP-Config is used to set configurable PDCP parameters for signaling bearers, MBS multicast bearers, and data bearers.

[0092] Example 3

[0093] Embodiment 3 of the present disclosure is described in detail below with reference to the accompanying drawings. FIG3 is a schematic diagram illustrating the basic process of a method performed by a user equipment UE in embodiment 3 of the present disclosure. As shown in FIG3 , the method performed by the user equipment in embodiment 3 may generally include the following steps:

[0094] Step 301: The UE receives an RRC message from a base station, where the RRC message may be an RRC recovery message.

[0095] Step 303: If the RRC message contains the fullConfig field, a full configuration operation process is performed. The full configuration operation process may include the following operations:

[0096] For each mbs-SessionId that is part of the current UE configuration and associated with a multicast MRB, perform at least one of the following:

[0097] Operation 3-1: Release the Service Data Adaptation Protocol (SDAP) entity.

[0098] Operation 3-2: Release each multicast MRB associated with the mbs-SessionId. Specifically, the release of each multicast MRB associated with the mbs-SessionId may be: (1) for the release of the multicast MRB caused by full configuration, release of the PDCP entity and / or release of the mrb-Identity, or (2) for each multicast MRB associated with the MBS multicast session configured for RRC_INACTIVE reception, if the multicast MRB release is caused by full configuration and / or the full configuration occurs during the RRC recovery process (i.e., triggered by receiving an RRC recovery message), release of the PDCP entity.

[0099] The mbs-SessionId field indicates the MBS session identifier received by the UE in RRC_INACTIVE. The fullConfig field is used to instruct the UE to perform the full configuration process.

[0100] [Variation of Example 3]

[0101] An embodiment obtained by replacing step 303 with the following step 303a:

[0102] Step 303a: If the RRC message includes a TMGI-ToRleaseList field, then for each mbs-SessionId included in the TMGI-ToRleaseList field that is part of the current UE configuration and associated with a multicast MRB, perform at least one of the following operations:

[0103] Operation 3-1a: Release the Service Data Adaptation Protocol (SDAP) entity.

[0104] Operation 3-2a: Release each multicast MRB associated with the mbs-SessionId. Specifically, releasing each multicast MRB associated with the mbs-SessionId may be releasing a PDCP entity.

[0105] The TMGI-ToRleaseList field is an indicator identifier used to instruct the UE to release the multicast MRB of the MBS multicast session configured for RRC_INACTIVE reception, or is a TMGI list, where the TMGI is the TMGI of the MBS multicast session configured for RRC_INACTIVE reception. Upon receiving the TMGI-ToRleaseList field, the UE releases all multicast MRBs of the MBS multicast session configured for RRC_INACTIVE reception, or releases all multicast MRBs that are not configured with an MRB identifier, or releases all multicast MRBs associated with the MBS multicast session indicated by the TMGI contained in the TMGI-ToRleaseList field. The mbs-SessionId field can indicate the MBS session identifier or the MBS session identifier received by the UE in RRC_INACTIVE.

[0106] Example 4

[0107] In this embodiment, if the UE has not updated the PTM configuration of the MBS multicast session configured for RRC_INACTIVE reception contained in the most recently received RRC release message before initiating or executing the RRC recovery process or before receiving the RRC recovery message, the UE retains the multicast MRB of the MBS multicast session configured for RRC_INACTIVE reception; otherwise, the UE deletes the multicast MRB of the MBS multicast session configured for RRC_INACTIVE reception. Failure to update the PTM configuration of the MBS multicast session configured for RRC_INACTIVE reception contained in the most recently received RRC release message before receiving the RRC recovery message means that the UE has not read the multicast MCCH after the most recently received RRC release message. Optionally, the UE may carry an indication flag in an RRC message (e.g., an RRC recovery complete message) sent to the base station to instruct the UE to retain information related to the multicast MRB of the MBS multicast session configured for RRC_INACTIVE reception. The RRC recovery complete message is used to confirm the successful completion of the RRC connection recovery, and is a response message to the RRC recovery message.

[0108] If the UE receives an RRC Reject message from the base station after sending an RRC Resume Request message, the existing RRC Connection Rejection process will cause the UE to reset its MAC address, which may cause the UE to stop receiving the MBS multicast session or cause MBS multicast session data to be lost. The following embodiments address this issue.

[0109] Example 5

[0110] In step 501, the UE receives an RRC message from a base station, where the RRC message may be an RRCReject message.

[0111] In step 503, the UE performs at least one of the following operations:

[0112] Step 5-1: Reset MAC.

[0113] Operation 5-2: If the UE is configured with one or more MBS multicast sessions for RRC_INACTIVE reception and the MBS multicast session is in an active state (i.e., not instructed to stop detecting G-RNTI), indicate the G-RNTI of the active MBS multicast session to the lower layer (e.g., the MAC layer or the physical layer), or instruct the lower layer to listen to the G-RNTI of the active MBS multicast session, or instruct the lower layer to receive the MBS multicast session, or instruct the lower layer to receive the MBS multicast session, or instruct the lower layer to receive the MBS multicast session configured to be receivable in the RRC inactive state, or instruct the lower layer to receive the MBS multicast session configured to be receivable in the RRC inactive state and in an active state.

[0114] Operation 5-3: If the UE is configured with one or more MBS multicast sessions for RRC inactive reception and / or at least one of the MBS multicast sessions is in active state, perform a unicast MAC reset.

[0115] Operation 5-4: If the UE is not configured with an MBS multicast session for RRC_INACTIVE reception and / or is configured with one or more MBS multicast sessions for RRC_INACTIVE reception but the MBS multicast sessions are all in an inactive state (ie, all are instructed to stop detecting G-RNTI), reset the MAC.

[0116] In the embodiment of the present disclosure, the unicast MAC reset is performed by the UE's RRC layer (or entity) instructing the MAC layer (or entity). The unicast MAC reset includes at least one of the following operations (or if the upper layer requests the unicast MAC reset, the MAC entity performs at least one of the following operations):

[0117] Operation 6-1: Stop all timers except the MBS multicast DRX timer and the MBS broadcast DRX timer. It should be noted that the operation of stopping the timer is performed only when the timer is running.

[0118] Operation 6-2: Set the new data indication (NDI) of all uplink HARQ processes to 0.

[0119] Operation 6-3: Clear the soft buffers of all DL HARQ processes, except for the soft buffers of the DL HARQ processes for MBS broadcast and the soft buffers of the DL HARQ processes used by the MBS multicast sessions that are configured for RRC_INACTIVE reception and are not instructed to stop detecting G-RNTI. The DL HARQ processes used by the MBS multicast sessions that are configured for RRC_INACTIVE reception and are not instructed to stop detecting G-RNTI refer to processes where the data or transport block TB or downlink allocation most recently received by the DL HARQ processes is for the G-RNTI of the MAC entity (or G-RNTI scrambled or G-RNTI addressed). Optionally, the G-RNTI is the G-RNTI associated with the MBS multicast session that is configured for RRC_INACTIVE reception.

[0120] Operation 6-4: For each downlink DL HARQ process, the next received TB or downlink allocation is considered to be the first transmission, except for the DL HARQ process used for MBS broadcast and the DL HARQ process used for the MBS multicast session that is configured for RRC_INACTIVE reception and is not instructed to stop detecting G-RNTI. The DL HARQ process of the MBS multicast session that is configured for RRC_INACTIVE reception and is not instructed to stop detecting G-RNTI means that the data or transport block TB or downlink allocation most recently received by the DL HARQ process is for the G-RNTI of the MAC entity (or G-RNTI scrambled or G-RNTI addressed). Optionally, the G-RNTI is the G-RNTI associated with the MBS multicast session that is configured for RRC_INACTIVE reception.

[0121] In the embodiment of the present disclosure, the MAC reset is performed by the UE's RRC layer (or entity) instructing the MAC layer (or entity). The MAC reset includes at least one of the following operations (or if the upper layer requests to perform a MAC reset, the MAC entity performs at least one of the following operations):

[0122] Operation 7-1: Stop all timers except the MBS broadcast DRX timer. It should be noted that the operation of stopping the timer is performed only when the timer is running.

[0123] Operation 7-2: Set the new data indication (NDI) of all uplink HARQ processes to 0.

[0124] Operation 7-3: Clear the soft buffers of all DL HARQ processes, except the soft buffers of the DL HARQ processes broadcast by the MBS.

[0125] Operation 7-4: For each downlink DL HARQ process, consider the next received TB or downlink allocation as the first transmission, except for the DL HARQ process used for MBS broadcast.

[0126] A UE in an RRC connected state and a UE in an RRC inactive state may receive an RRCResume message from the base station when requesting to restore the RRC connection (for example, a UE in an RRC inactive state sends an RRCResumeRequest or RRCResumeRequest1 message for SDT). When the UE receives the RRCResume message from the base station, if the message contains a suspendConfig field and sdt-Config is configured, the RLC entity is rebuilt for each RLC bearer that is not suspended. One of the purposes of the UE rebuilding the RLC entity is to avoid the triggering of SDT due to the presence of old data in RLC bearers that are not used for small data transmission. If the UE does not clear the data of all RLC bearers, even if all newly arrived uplink data is for bearers configured as SDT, the SDT will be prevented from being triggered because the RLC bearers corresponding to the bearers that are not configured with SDT have old data (for example, there is old data in the buffer area of ​​the corresponding RLC entity). The operation of rebuilding the RLC entity includes discarding all RLC SDUs, RLC SDU segments and all RLC PDUs.

[0127] Specifically, reestablishing the RLC entity includes at least the following operations:

[0128] 1. Discard all RLC SDUs, RLC SDU segments, and all RLC PDUs (the corresponding operation is performed only when there are RLC SDUs, RLC SDU segments, or RLC PDUs).

[0129] 2. Stop and reset all timers.

[0130] 3. Reset all state variables to their initial values.

[0131] When the UE receives the RRCRelease message containing the suspendConfig field and the sdt-Config field, the UE will re-establish all non-suspended RLC entities (except the RLC entity corresponding to the RLC bearer associated with the broadcast MRB). At this time, if the UE is performing MBS multicast services, the MRB (or its corresponding RLC bearer) used to receive the MBS multicast services is not suspended, so the RLC entity associated with the MRB or the MRB's corresponding RLC entity is also re-established, which will result in data loss of the MBS multicast services.

[0132] The following embodiments are provided to solve this problem.

[0133] Example 6

[0134] The method performed by the user equipment in Example 6 may generally include the following steps:

[0135] Step 601: The UE receives an RRCRelease message from the base station.

[0136] Step 603: When the RRCRelease message includes the suspendConfig field and the sdt-Config is configured (i.e., the RRCRelease message includes the sdt-Config field), the UE performs the following operations:

[0137] Re-establish the RLC entities corresponding to the unsuspended RLC bearers, except for the RLC bearers associated with or configured with the multicast MRB of the UM RLC entity. In other words, for each unsuspended RLC bearer (except the RLC bearers associated with or configured with the multicast MRB of the UM RLC entity), re-establish the RLC entity corresponding to the RLC bearer.

[0138] The suspendConfig field indicates the configuration of the RRC_INACTIVE state; the sdt-Config field is used to indicate SDT-related configuration.

[0139] In the present disclosure, MBS multicast or multicast session or service is an MBS multicast session or service.

[0140] Unless otherwise specified, the embodiments executed by the UE or base station in the present disclosure may be executed by the RRC entity in the UE or base station or executed at the RRC layer. In the present disclosure, fields, domains, and information elements may be used interchangeably. In the embodiments of the present disclosure, if multiple operations are included, the embodiments obtained by changing the execution order of the operations are also within the scope of protection of the present disclosure. When multiple parallel judgment conditions are included, the embodiments obtained by changing the order of the judgment conditions are also within the scope of protection of the present disclosure. The conditions involved in the embodiments of the present disclosure are used interchangeably with "and", "or", "and / or", "and", and "and", and the resulting embodiments are also within the scope of the present disclosure.

[0141] 4 is used to illustrate a user equipment as an embodiment that can execute the method executed by the user equipment described in detail above in the present invention.

[0142] FIG4 is a block diagram showing a user equipment UE according to the present invention.

[0143] As shown in Figure 4, the user equipment UE 400 includes a processor 401 and a memory 402. The processor 401 may include, for example, a microprocessor, a microcontroller, an embedded processor, etc. The memory 402 may include, for example, a volatile memory (such as a random access memory (RAM), a hard disk drive (HDD), a non-volatile memory (such as a flash memory), or other memory. The memory 402 stores program instructions. When executed by the processor 401, the instructions may execute the above-described method performed by the user equipment as described in detail in the present invention.

[0144] The method and user equipment executed by the user equipment involved in the present invention have been described in detail above based on Example 1, etc. However, the present invention is not limited to the method and user equipment executed by the user equipment, and can also be implemented in other ways as long as the main purpose of the present invention can be achieved.

[0145] The method and related apparatus of the present disclosure have been described above in conjunction with preferred embodiments. Those skilled in the art will appreciate that the methods described above are merely exemplary and that the various embodiments described above can be combined with one another unless conflicts arise. The method of the present disclosure is not limited to the steps and sequence described above.

[0146] In the embodiments of the present disclosure, when multiple operations are involved, the embodiments of the present disclosure exemplarily list the execution order of each operation, and the embodiments obtained by changing the execution order of each operation are also within the scope of protection of the present disclosure. In addition, when multiple judgment conditions are involved, the embodiments obtained by changing the execution order of each judgment condition are also within the scope of protection of the present disclosure. In addition, in the present disclosure, unless otherwise specified, the meaning of the fields defined in one embodiment can also be applied to the corresponding fields involved in other embodiments. In addition, in the embodiments of the present disclosure, "if...", "when...", "when...", "at...", "satisfy..." or "satisfy the conditions..." can be replaced with "under the condition of...". In the embodiments of the present disclosure, the embodiments obtained by replacing "and" in some or all conditions with "or" are also within the scope of protection of the present disclosure; the embodiments obtained by replacing "or" in some or all conditions with "and" are also within the scope of protection of the present disclosure.

[0147] In addition, the user equipment shown above may include more modules, for example, modules that can be developed or will be developed in the future and can be used for a base station, MME, or UE, etc. The various identifiers shown above are merely exemplary and not restrictive, and the present disclosure is not limited to the specific information elements used as examples of these identifiers. Those skilled in the art may make many changes and modifications based on the teachings of the illustrated embodiments.

[0148] It should be understood that the above embodiments of the present disclosure can be implemented through software, hardware, or a combination of software and hardware. For example, the various components within the base station and user equipment in the above embodiments can be implemented through a variety of devices, including but not limited to: analog circuit devices, digital 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.

[0149] In addition, the computer executable instructions or programs running on the device according to the present invention can be programs that enable the computer to implement the functions of the embodiments of the present invention by controlling the central processing unit (CPU). The program or the information processed by the program can be temporarily stored in a volatile memory (such as a random access memory RAM), a hard disk drive (HDD), a non-volatile memory (such as a flash memory), or other memory systems.

[0150] The computer executable instructions or program for realizing each embodiment of the present invention function can be recorded on a computer-readable storage medium. The corresponding function can be realized by making a computer system read the program recorded on the recording medium and executing these programs. The so-called "computer system" herein can be a computer system embedded in the device, and can include an operating system or hardware (such as a peripheral device). "Computer-readable storage medium" can be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a short-term dynamic storage program recording medium or any other recording medium that is computer-readable.

[0151] The various features or functional modules of the devices used in the above embodiments can be implemented or executed by circuits (e.g., single-chip or multi-chip integrated circuits). The circuits designed to perform the functions described in this specification may include general-purpose processors, digital signal processors (DSPs), proprietary integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of the above devices. The general-purpose processor may be a microprocessor, or any existing processor, controller, microcontroller, or state machine. The above circuits may be digital circuits or analog circuits. In the event that new integrated circuit technologies have emerged to replace 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.

[0152] 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 can be used as terminal devices or communication devices, such as AV equipment, kitchen equipment, cleaning equipment, air conditioners, office equipment, vending machines, and other household appliances.

[0153] As described above, the embodiments of the present invention have been described in detail with reference to the accompanying drawings. However, the specific structure is not limited to the above-described embodiments, and the present invention also includes any design changes that do not deviate from the main purpose 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 different embodiments are also included in the technical scope of the present invention. In addition, components with the same effect described in the above embodiments can be replaced with each other.

Claims

1. A user equipment (UE), comprising a processor, wherein the processor is configured to: receiving an RRC message, and if the UE is configured for RRC_INACTIVE multicast reception, stopping the MBS multicast DRX timer; in, The RRC message is an RRCSetup message for establishing SRB1, or an RRCResume message for resuming a suspended RRC connection.

2. The user equipment according to claim 1, further comprising: If the UE is configured with the RRC_INACTIVE multicast reception, the soft buffers of all downlink HARQ processes used by the MBS multicast are cleared.

3. The user equipment according to claim 1 or 2, further comprising: If the UE is configured with the RRC_INACTIVE multicast reception, for each downlink HARQ process used for the MBS multicast, the next received transport block of the TB is regarded as the first transmission.

4. The user equipment according to claim 1 or 2, further comprising: If the UE is configured for the RRC_INACTIVE multicast reception, release the multicast MRB configured for the RRC_INACTIVE multicast reception.

5. A method performed by a user equipment (UE), comprising: receiving an RRC message, and if the UE is configured for RRC_INACTIVE multicast reception, stopping the MBS multicast DRX timer; The RRC message is an RRCSetup message for establishing SRB1, or an RRCResume message for resuming a suspended RRC connection.

6. A base station, communicating with a user equipment (UE), the base station comprising a processor, the processor being configured to: Sending an RRC message to the UE; If the UE is configured for RRC_INACTIVE multicast reception, stopping the MBS multicast DRX timer; in, The RRC message is an RRCSetup message for establishing SRB1, or an RRCResume message for resuming a suspended RRC connection.

7. A method performed by a base station, the base station communicating with a user equipment (UE), the method comprising: Sending an RRC message to the UE; If the UE is configured for RRC_INACTIVE multicast reception, stopping the MBS multicast DRX timer; The RRC message is an RRCSetup message for establishing SRB1, or an RRCResume message for resuming a suspended RRC connection.

Images