Method executed by user equipment and user equipment

Abstract

The invention provides a method executed by user equipment and the user equipment. The method executed by user equipment UE comprises the following steps: the UE receives a radio resource control release RRCRelease message from a base station; and when the RRCRelease message contains a sutendConfig field and the sdt-Config field is configured, the UE executes any one of the following operations from the operation 1-1 to the operation 1-6.

Description

Technical Field

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

[0002] A research project SI on the improvement of the 5G multicast broadcast service architecture (specifically see SP-190625) has been approved. One of the objectives of this SI (referred to as Objective A) is to support general MBS services in 5GS. Use cases that can benefit from this feature include (but are not limited to) public safety, V2X applications, transparent IPv4 / IPv6 multicast transmission, IPTV, wireless software transmission, group communication, and Internet of Things applications, etc. Correspondingly, at the 86th plenary session of the 3rd Generation Partnership Project (3GPP) RAN, a work item on NR multicast and broadcast service (NR MBS) was proposed (see non-patent document: RP-193248: New WID: NR Multicast and Broadcast Service) and approved. This work item aims to provide support for Objective A in RAN. The objectives of this work item have been basically achieved, and the specific descriptions of the relevant solutions can be found in 3GPP Release 17 technical documents, such as TS38.300-h70, TS38.331-h70, TS38.321-h70, etc. At the 94th plenary session of 3GPP RAN, a work item named enhanced NR broadcast multicast was approved (see non-patent document: RP-213568: New WID: Enhancements of NR Multicast and Broadcast Services). This work item aims to further enhance the MBS broadcast multicast of Release 17, and one of its objectives is to support user equipment to receive MBS multicast services / sessions in the RRC inactive state.

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

[0004] To solve at least some 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 invention, there is provided a method performed by a user equipment UE, including: the UE receives a Radio Resource Control Release (RRCRelease) message from a base station; in the case where the suspendConfig field is included in the RRCRelease message and the sdt-Config is configured, the UE performs any one of the following operations: Operation 1-1: For each non-suspended Radio Link Control (RLC) bearer (except for the RLC bearer associated with a Multicast Radio Bearer (MRB) of a Multimedia Broadcast Multicast Service (MBS) multicast session configured to receive in RRC_INACTIVE and not indicated to stop detecting the Group Radio Network Temporary Identifier (G-RNTI)), reconstruct the RLC entity corresponding to the RLC bearer. Operation 1-2: For each non-suspended RLC bearer (except for the RLC bearer associated with an MRB of an MBS multicast session not indicated to stop detecting the G-RNTI), reconstruct the RLC entity corresponding to the RLC bearer. Operation 1-3: For each non-suspended RLC bearer associated with a Data Radio Bearer (DRB) and / or an MRB of an MBS multicast session indicated to stop detecting the G-RNTI, reconstruct the RLC entity corresponding to the RLC bearer. Operation 1-4: For each non-suspended RLC bearer associated with a DRB and / or an MRB of an MBS multicast session not in progress, reconstruct the RLC entity corresponding to the RLC bearer. Operation 1-5: For each non-suspended RLC bearer (except for the RLC bearer associated with an MRB of an MBS multicast session configured to receive in RRC_INACTIVE and / or detecting the corresponding G-RNTI), reconstruct the RLC entity corresponding to the RLC bearer. Operation 1-6: For each non-suspended RLC bearer (except for the RLC bearer associated with an MRB of an MBS multicast session configured to receive in RRC_INACTIVE and / or in progress), reconstruct the RLC entity corresponding to the RLC bearer.

[0006] In the method of the first aspect above, the suspendConfig field is used to indicate the configuration of the RRC inactive state, and the sdt-Config field is used to indicate the configuration related to Small Data Transfer (SDT).

[0007] In the method of the first aspect above, reconstructing the RLC entity includes at least one of the following operations: discarding all RLC Service Data Units (SDUs), RLC SDU segments, and all RLC Protocol Data Units (PDUs); stopping and resetting all timers; resetting all state variables to their respective initial values.

[0008] In the method of the first aspect above, the UE is performing MBS multicast services when receiving the RRCRelease message.

[0009] In the method according to the first aspect above, the UE is performing SDT when receiving the RRC Release message.

[0010] According to a second aspect of the present disclosure, there is provided a user equipment UE, including: a processor; and a memory storing instructions; wherein, the instructions, when run by the processor, execute the method according to the context.

[0011] Advantages of the Invention

[0012] The method performed by a user equipment and the user equipment according to the present disclosure can avoid data loss of MBS multicast services when the user equipment UE reconstructs an RLC entity that is not suspended. Brief Description of the Drawings

[0013] Through the following detailed description in conjunction with the drawings, the above and other features of the present invention will become more obvious, where:

[0014] Figure 1 is a schematic flowchart of the method performed by a user equipment in Embodiment 1 of the present invention.

[0015] Figure 2 is a schematic flowchart of the method performed by a user equipment in Embodiment 2 of the present invention.

[0016] Figure 3 is a block diagram of the user equipment UE involved in the present invention. Detailed Embodiments

[0017] The following describes some terms related to the present invention. The specific meanings of the terms can be found in the latest relevant 3GPP documents, such as TS38.300, TS38.321, TS38.323, TS38.331, etc. In addition, the embodiments of the present invention are described by taking broadcast / multicast services as an example, but the embodiments of the present invention are not limited to broadcast / multicast services and can also be applied to other application scenarios.

[0018] UE: User Equipment, user equipment.

[0019] RRC: Radio Resource Control, radio resource control.

[0020] RRC_CONNECTED: RRC connected state.

[0021] RRC_INACTIVE: RRC inactive state.

[0022] RRC_IDLE: RRC idle state.

[0023] RAN: Radio Access Network, the radio access network.

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

[0025] MBS: Multicast / Broadcast Services, multicast / broadcast services. Multicast can also be referred to as groupcast.

[0026] AS: Access Stratum, the access stratum or the access layer.

[0027] NAS: Non Access Stratum, the non-access stratum or the non-access layer.

[0028] RB: Radio Bearer, the radio bearer. DRB is the data radio bearer.

[0029] MRB: MBS Radio Bearer, that is, a radio bearer configured for MBS delivery (Aradio bearer that isconfigured for MBS delivery). MRB is divided into multicast MRB and broadcast MRB. Multicast MRB is a radio bearer configured for MBS multicast delivery, and broadcast MRB is a radio bearer configured for MBS broadcast delivery.

[0030] TMGI: Temporary Mobile Group Identity, the temporary mobile group identity, which is used to identify an MBS session.

[0031] RNTI: Radio Network Temporary Identifier, the radio network temporary identifier.

[0032] PTM: Point to Multipoint, point-to-multipoint, a way to deliver an MBS service (deliver). In the PTM delivery method, the base station sends a copy of the MBS data packet to a group of UEs (gNBdelivers a single copy of MB Sdata packets to a set of UEs). The UE uses G-RNTI or G-CS-RNTI to receive PTM transmissions. For example, the base station uses the group common physical downlink control channel PDCCH using G-RNTI to schedule the same group common physical downlink shared channel PDSCH using G-RNTI.

[0033] PCell: Primary Cell, the primary cell, the MCG cell, which operates on the primary frequency, and the UE performs the initial connection establishment process or initiates the connection reconstruction process in it.

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

[0035] G-CS-RNTI: Group Configuration Scheduling RNTI, which is used to scramble the semi-static scheduling SPS group common physical downlink shared channel PDSCH and activate / deactivate the SPS group common PDSCH for one or more MBS multicast services.

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

[0037] MCCH: MBS Control Channel, which is a PTM downlink channel used to transmit MBS broadcast or MBS multicast control information associated with one or more MTCHs from the network to the UE. MCCH includes broadcast MCCH and multicast MCCH.

[0038] The RRC resume 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 resume request, if the useFullResumeID field is included in SIB1, the RRCResumeRequest1 message is used and the resumeIdentity field in the RRCResumeRequest1 message is set to the fullI-RNTI stored by the UE; otherwise, the 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 to suspend an RRC connection. The RRC reconfiguration message, RRCReconfiguration, is used to command the modification of an RRC connection. The RRC resume message, RRCResume, is used to resume a suspended RRC connection. In the present disclosure, the useFullResumeID field indicates the resume identity and the resume request message used. When the field is included in SIB1, the fullI-RNTI and the RRCResumeRequest1 message are used; when the field is not included in SIB1, the shortI-RNTI and the RRCResumeRequest message are used. The shortI-RNTI uses fewer bits than the I-RNTI-Value to identify the suspended UE context of the UE in the RRC inactive state. The RRC resume procedure (i.e., the RRC connection resume procedure) is used to resume a suspended RRC connection, including resuming SRB(s), DRB(s) and multicast MRB(s), or performing an RNA update, or implementing an MBS multicast reception request, or initiating small data transfer (SDT) in the RRC_INACTIVE state, etc. During the RRC resume procedure, the UE sends an RRC resume request message to the base station and may receive an RRC resume message RRCResume or an RRC setup message RRCSetup or an RRC release message RRCRelease or an RRC reject message RRCReject from the base station.

[0039] In the present invention, the network, the base station and the RAN can be used interchangeably. The network can be a Long Term Evolution (LTE) network, a New Radio (NR) network, an enhanced Long Term Evolution (eLTE) network, or other networks defined in subsequent evolved versions of 3GPP.

[0040] Currently, the NR MBS service includes MBS broadcast (also known as MBS broadcast session or broadcast MBS or MBS broadcast service or MBS broadcast service) and MBS multicast (also known as MBS multicast session or multicast MBS or MBS multicast service or MBS multicast service). MBS broadcast provides a downlink-only MBS transmission mode for services with low Quality of Service (QoS), enabling UEs in the RRC connected state, RRC idle state, and RRC inactive state to receive the MBS service. The UE obtains the MBS broadcast configuration information broadcast by the network through the MBS control channel (MCCH).

[0041] In Release 17, UEs in the RRC inactive state are not supported to receive MBS multicast sessions. Therefore, before receiving the MBS multicast service (i.e., MBS multicast session), the UE needs to establish an RRC connection with the base station, and then the base station (i.e., the network) configures the resources or PTM configuration for the UE to receive the MBS multicast service 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 MRB can receive the corresponding MBS multicast service. 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 supporting 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 with the P-RNTI on the physical downlink control channel (PDCCH), and the UE monitors the paging channel. The paging message for the 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 the RRC idle state or RRC inactive state. In other words, the base station does not page the UE separately (for the purpose of the UE receiving the MBS multicast session).

[0042] In version 18, the UE is supported to receive MBS multicast sessions in the RRC inactive state. For an MBS multicast session configured to be received in the RRC inactive state, the base station can provide or configure the PTM configuration information (also referred to as the configuration information of the MBS multicast session or the PTM configuration of the MBS multicast session or the MBS multicast configuration) for receiving the MBS multicast session for the UE through proprietary RRC signaling (such as the RRC Release message) or through the multicast MBS control channel MCCH (i.e., the multicast MCCH). The information required to obtain the multicast MCCH (or the multicast MCCH configuration) can be configured for the UE through proprietary RRC signaling or the 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 the RRC inactive state. The PTM configuration information may include the configuration information of the MRB corresponding to the MBS multicast session and / or the identification TMGI of the MBS multicast session and its corresponding G-RNTI / G-CS-RNTI and / or DRX and other configuration information fields. For example, the PTM configuration of a certain MBS multicast session is the information related to the reception of the MBS multicast session contained in the MBS multicast configuration MBSMulticastConfiguration message. Among them, the MBSMulticastConfiguration message contains the control information applicable for MBS multicast services transmitted via multicast MRBs for RRC_INACTIVE UEs. The MBSMulticastConfiguration message can be transmitted on the multicast MCCH or contained in the RRC release message. Among them, the multicast MCCH is a PTM downlink channel used for transmitting the control information of the MBS multicast session associated to one or several MTCH(s) from the network to the UE in the RRC inactive state.For the MBS multicast session received in the RRC_INACTIVE state, in the embodiments of the present disclosure, the MBS multicast session being in the active state or being activated means that the MBS multicast session is in progress or about to start, and the UE starts to receive (or is receiving) the MBS multicast session, or the UE starts to detect the G-RNTI corresponding to the MBS multicast session, or the UE starts to detect the multicast-MCCH-RNTI of the multicast MCCH. The network can indicate to the UE that the MBS multicast is activated or data transmission is resumed through RRC signaling (such as an RRC release message) or through a paging message. For example, including the TMGI of the MBS multicast session in the paging message indicates that the MBS multicast session is activated or data transmission is resumed. Not including the stopMonitoringRNTI in the G-RNTI field for indicating the stop of detecting the corresponding G-RNTI of the MBS multicast session in the RRC release message means that the MBS multicast session is activated or data transmission is resumed. After receiving the indication, the UE starts to receive the MBS multicast session (i.e., the UE starts to detect the G-RNTI corresponding to the MBS multicast session). In the embodiments of the present disclosure, the activation of the MBS multicast also applies to the case of resuming data transmission of the MBS multicast session, which will not be elaborated below. In the embodiments of the present disclosure, the MBS multicast session being in the inactive state or being deactivated means that the MBS multicast session has ended or data transmission has been paused, 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 associates an indication identifier for each MBS multicast session in the multicast MCCH message to explicitly indicate that the MBS multicast session is deactivated or to stop 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 to receive the MBS multicast session can be that the UE stops detecting the G-RNTI or G-CS-RNTI corresponding to the MBS multicast session. Therefore, in the present disclosure, the indication for deactivating the MBS multicast session or stopping data transmission is the indication for the UE to stop detecting the G-RNTI or G-CS-RNTI associated with the MBS multicast session. In addition, the indication for activating the MBS multicast session or resuming data transmission is the indication for starting to detect the G-RNTI corresponding to the MBS multicast session. The deactivation of the MBS multicast session includes the case where there is temporarily no data transmission in the MBS multicast session, and the activation of the MBS multicast session includes the case where data transmission of the MBS multicast session is resumed. In the present disclosure, the multicast session or service is the MBS multicast session or service. In the following embodiments, the G-RNTI is taken as an example for illustration, and the embodiments obtained by replacing the G-RNTI with the G-CS-RNTI are also within the scope of the present disclosure.

[0043] 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.

[0044] 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 permitted to be received in the RRC_INACTIVE state and / or the UE has a (valid) PTM configuration for the MBS multicast session, the UE can directly receive the MBS multicast session without establishing an RRC connection with the base station. The network can configure the PTM configuration information (e.g., included in the MBSMulticastConfiguration message) for the MBS multicast session received in the RRC_INACTIVE state for the UE through the multicast MCCH and / or proprietary RRC signaling (e.g., RRC release message, RRC reconfiguration message). The MBS multicast configuration message MBSMulticastConfiguration can be transmitted on the multicast MCCH (in which case the MBSMulticastConfiguration message can be referred to as a multicast MCCH message), or it can be included in the RRC release message. If the RRC release message is used to configure the PTM configuration information for the MBS multicast session received in the RRC_INACTIVE state for the UE, the network can include the MBSMulticastConfiguration message in the RRC release message sent to the UE.

[0045] In the embodiments of the present disclosure, the 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 (Dynamically scheduled MCCH signaling and / or MCCH change notification) or for scrambling the CRC of a DCI or DCI format (format) or for scrambling the PDCCH for MBS multicast transmission purposes or for scrambling the CRC of a DCI or DCI format (format) for MBS multicast purposes or for scheduling the transmission of the PDSCH for the MBS multicast session. The DCI or DCI format can be DCI format 4_0 or DCI format 4_1.

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

[0047] The UE receives an RRC release message from the base station, and the multicastConfigInactive field included in the RRC release message indicates the multicast sessions or services that the UE can receive in the current serving cell (i.e., the cell that receives the RRC release message) when the UE is in the RRC_INACTIVE state. 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 the RRC_INACTIVE state.

[0048] In the present disclosure, embodiments obtained by replacing the function of the multicastConfigInactive field with one of the following are also within the scope of the present disclosure:

[0049] The multicastConfigInactive field indicates the multicast sessions or services that the UE can receive in the current serving cell when the UE is in RRC_INACTIVE, or the multicastConfigInactive field is used to indicate the multicast sessions or services that the UE can receive when the UE is in RRC_INACTIVE, or the multicastConfigInactive field is used to indicate the multicast sessions or services that the UE can receive in the current serving cell when the UE 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 the UE is in RRC_INACTIVE before obtaining the multicast MCCH.

[0050] Optionally, the multicastConfigInactive field further includes the corresponding configurations of these multicast sessions, and the configurations are valid in the current serving cell. The multicastConfigInactive field may include two fields, namely 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.

[0051] For a UE configured to receive an MBS multicast session in RRC_INACTIVE, the UE learns whether the joined MBS multicast session is activated and allowed to be received in the RRC_INACTIVE state by receiving a paging message. Specifically, if the paging message contains the TMGI of the MBS multicast session joined by the UE (at this time the UE considers the MBS multicast session to be activated) and its corresponding inactiveReceptionAllowed field, then 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 all other MBS multicast sessions joined by the UE included in the paging message are indicated as being receivable in RRC_INACTIVE when the UE receives the paging message. If there is at least one MBS multicast session joined by the UE indicated by the TMGI included in the paging message that is not indicated by the paging message as being receivable in RRC_INACTIVE (that is, the paging message does not contain the inactiveReceptionAllowed field corresponding to at least one MBS session joined by the UE included in the paging message indicated by the TMGI), then for other MBS multicast sessions joined by the UE indicated by the TMGI included in the paging message, even if the paging message contains its corresponding inactiveReceptionAllowed, the UE does not receive the MBS session in RRC_INACTIVE. In other words, only when all the inactiveReceptionAllowed fields corresponding to the MBS multicast sessions joined by the UE indicated by the TMGI included in the paging message are included in the paging message, does the UE receive the MBS multicast session joined by the UE indicated by the TMGI included in the paging message in RRC_INACTIVE. Among them, the inactiveReceptionAllowed field is used to indicate whether a UE with a valid PTM configuration of the TMGI indicated in the pagingGroupList (i.e., pagingGroupList-r17) included in the paging message stays in RRC_INACTIVE to receive the MBS multicast session indicated by the TMGI.

[0052] Currently, it is possible to indicate to the UE 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 an MBS multicast session allowed / configured to be received in RRC_INACTIVE, it means that the UE receives an indication to start detecting the G-RNTI of the MBS multicast session). It is also possible to indicate in the MBSMulticastConfiguration message whether to stop detecting the G-RNTI corresponding to the MBS multicast session. Specifically, for an MBS multicast session whose TMGI is included in the MBSMulticastConfiguration message, if the MBSMulticastConfiguration message also includes the stopMonitoringRNTI field of the MBS multicast session, it means that the UE receives an indication to stop detecting the G-RNTI of the MBS multicast session (that is, stop detecting the G-RNTI of the MBS multicast session). On the contrary (that is, the MBSMulticastConfiguration message does not include the stopMonitoringRNTI field of the MBS multicast session), it means that the UE does not receive an indication to stop detecting the G-RNTI of the MBS multicast session. Among them, the stopMonitoringRNTI field indicates to the UE to stop detecting the G-RNTI corresponding to the MBS multicast session. The stop detection of the G-RNTI of 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, it means that the MBS multicast session is not indicated to stop detecting the G-RNTI. The MBSMulticastConfiguration message can be transmitted on the multicast MCCH or included in the RRC release message for transmission. Specifically, the MBSMulticastConfiguration message can be included in the MulticastConfigInactive field of the suspendConfig field in the RRC release message.Among them, the suspendConfig field indicates the configuration in the RRC_INACTIVE state; the MulticastConfigInactive field is used to indicate one or more MBS multicast services that can be received in the RRC_INACTIVE state (or one or more MBS multicast services that can be received in the RRC_INACTIVE state for the current serving cell or one or more MBS multicast services that can be received in the RRC_INACTIVE state before obtaining the multicast MCCH for the current serving cell). 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 where the UE receives the RRC release message. The serving cell or the cell where the UE last or previously received the RRC release message may refer to the cell or the primary cell PCell where the UE last or previously received the RRC release message. If the RRC release message received by the UE contains the MBSMulticastConfiguration message or the MulticastConfigInactive field, it is considered that the UE is configured to receive MBS multicast in the RRC_INACTIVE state; or if the RRC release message (or the MBSMulticastConfiguration message contained in the RRC release message) received by the UE contains the TMGI, it is considered that the UE is configured to receive MBS multicast in the RRC_INACTIVE state. It should be noted that the UE obtaining the multicast MCCH means that the UE obtains the MBSMulticastConfiguration message from the multicast MCCH.

[0053] When a UE in the RRC connected state and a UE in the RRC inactive state request to resume the RRC connection (for example, a UE in the RRC inactive state sends an RRC Resume Request or RRC Resume Request1 message for SDT), it is possible for both to receive an RRC Release message from the base station. When the UE receives an RRC Release message from the base station, if the message contains a suspendConfig field and sdt-Config is configured, for each RLC bearer that is not suspended, the RLC entity is re-established. One of the purposes of the UE to re-establish the RLC entity is to avoid affecting the triggering of SDT due to the existence of old data in the RLC bearers that are not 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 the bearers configured for SDT, since there is old data in the RLC bearers corresponding to the bearers not configured for SDT (for example, there is old data in the buffer of the corresponding RLC entity), the triggering of SDT will be blocked. The operations for re-establishing the RLC entity include discarding all RLC SDUs, RLC SDU segments, and all RLC PDUs.

[0054] Specifically, re-establishing the RLC entity at least includes the following operations:

[0055] 1. Discard all RLC SDUs, RLC SDU segments, and all RLC PDUs (perform the corresponding operations only when there are RLC SDUs, RLC SDU segments, or RLC PDUs).

[0056] 2. Stop and reset all timers.

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

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

[0059] In view of the above problems in the prior art, the present disclosure proposes the following embodiments, but the following embodiments are only for illustration and do not limit the protection scope of the present invention.

[0060] Embodiments are provided below to solve this problem. Additionally, the following embodiments are merely examples and do not limit the present invention.

[0061] Embodiment 1

[0062] Hereinafter, Embodiment 1 of the present disclosure will be described in detail with reference to the accompanying drawings. Figure 1 is a schematic diagram showing the basic process of the method executed by the user equipment UE in Embodiment 1 of the present disclosure, as Figure 1 shown, the method executed by the user equipment in Embodiment 1 generally may include the following steps:

[0063] Step 101: The UE receives an RRC Release message from the base station.

[0064] Step 102: In the case where the suspendConfig field is included in the RRC Release message and the sdt-Config is configured (i.e., the RRC Release message further includes the sdt-Config field), the UE performs any one of the following operations:

[0065] Operation 1-1: Re-establish the RLC entities corresponding to the non-suspended RLC bearers except for the RLC bearers associated with the multicast MRBs of the MBS multicast sessions that are configured to be received in RRC_INACTIVE and not indicated to stop detecting the G-RNTI. In other words, for each non-suspended RLC bearer (except for the RLC bearers associated with the multicast MRBs of the MBS multicast sessions that are configured to be received in RRC_INACTIVE and not indicated to stop detecting the G-RNTI), re-establish the RLC entities corresponding to the RLC bearers.

[0066] Operation 1-2: Re-establish the RLC entities corresponding to the non-suspended RLC bearers except for the RLC bearers associated with the multicast MRBs of the MBS multicast sessions that are not indicated to stop detecting the G-RNTI. In other words, for each non-suspended RLC bearer (except for the RLC bearers associated with the multicast MRBs of the MBS multicast sessions that are not indicated to stop detecting the G-RNTI), re-establish the RLC entities corresponding to the RLC bearers.

[0067] Operation 1-3: Re-establish the RLC entities of the non-suspended RLC bearers associated with the DRB and / or the multicast MRBs of the MBS multicast sessions that are indicated to stop detecting the G-RNTI. In other words, for each non-suspended RLC bearer associated with the DRB and / or the multicast MRBs of the MBS multicast sessions that are indicated to stop detecting the G-RNTI, re-establish the RLC entities corresponding to the RLC bearers.

[0068] Operation 1-4: Reconstruct the RLC entities of the non-suspended RLC bearers of the multicast MRBs associated with the DRB and / or the non-active MBS multicast sessions. In other words, for each non-suspended RLC bearer of the multicast MRBs associated with the DRB and / or the non-active MBS multicast sessions, reconstruct the RLC entity corresponding to the RLC bearer. The non-active MBS multicast session means that the UE is not detecting the G-RNTI of the MBS multicast session.

[0069] Operation 1-5: Reconstruct the RLC entities corresponding to the non-suspended RLC bearers except for those of the RLC bearers of the multicast MRBs associated with the MBS multicast sessions configured to receive and / or detect the G-RNTI (i.e., the G-RNTI corresponding to the MBS multicast session) in RRC_INACTIVE. In other words, for each non-suspended RLC bearer (except for the RLC bearers of the multicast MRBs associated with the MBS multicast sessions configured to receive and / or detect the corresponding G-RNTI in RRC_INACTIVE), reconstruct the RLC entity corresponding to the RLC bearer.

[0070] Operation 1-6: Reconstruct the RLC entities corresponding to the non-suspended RLC bearers except for those of the RLC bearers of the multicast MRBs associated with the MBS multicast sessions configured to receive and / or in progress. In other words, for each non-suspended RLC bearer (except for the RLC bearers of the multicast MRBs associated with the MBS multicast sessions configured to receive and / or in progress), reconstruct the RLC entity corresponding to the RLC bearer. Here, the in-progress MBS multicast session means that the UE is detecting the G-RNTI of the MBS multicast session.

[0071] Optionally, the UE must also satisfy that the SDT is in progress or the MulticastConfigInactive field is not included in the RRCRelease message before performing one of Operations 1-1 to 1-6.

[0072] Optionally, the UE is performing the SDT when receiving the RRCRelease message.

[0073] In the above-mentioned Embodiment 1, when the UE receives an RRC Release message that includes the suspendConfig field and the sdt-Config is configured, it does not re-establish the RLC entity corresponding to the RLC bearer of the multicast MRB associated with the MBS multicast session that is configured for RRC_INACTIVE reception and / or is not indicated to stop detecting the G-RNTI. The MBS multicast session not indicated to stop detecting the G-RNTI in the present disclosure means that the UE has not received an indication to stop detecting the G-RNTI of the MBS multicast session. It should be noted that in the present disclosure, the suspendConfig field is used to indicate the configuration of the RRC inactive state; the sdt-Config field is used to indicate the configuration related to SDT. In Embodiment 1, the RRC Release message is taken as an example for illustration, and the RRC Release message may also be other proprietary RRC signaling. The MBS multicast session for which the G-RNTI is being detected or not detected means that for the MBS multicast session, the UE is detecting or not detecting the G-RNTI corresponding to the MBS multicast session.

[0074]

Variant of Embodiment 1

[0075] An embodiment obtained by replacing the RRC Release message described in the embodiment that includes the suspendConfig field and the sdt-Config is configured (i.e., the RRC Release message further includes the sdt-Config field) with the RRC Release message that includes the sdt-Config.

[0076] In addition, when the UE receives an RRC release message from the base station, if the RRC release message includes at least the multicastConfigInactive field and the inactivePTM-Config field, in other words, at least one MBS multicast session is configured to be receivable in RRC_INACTIVE, or at least one MBS multicast session is configured to be receivable in RRC_INACTIVE in the current serving cell, or at least one MBS multicast session is configured to be receivable in RRC_INACTIVE in the current serving cell before receiving the multicast MCCH, the UE suspends all multicast MRBs associated with the MBS multicast sessions that are not configured to be receivable in RRC_INACTIVE. However, if the RRC release message includes the multicastConfigInactive field and the inactivePTM-Config field, but the inactivePTM-Config field does not include the mbs-SessionInfoList field, how the UE processes the established multicast MRBs is a problem that needs to be solved.

[0077] Embodiments are provided below to solve this problem. Additionally, the following embodiments are merely examples and do not limit the present invention. This disclosure takes the RRC release message as an example for illustration, and the relevant information can also be carried in other RRC signaling to achieve an effect similar to that of the RRC release message.

[0078] Embodiment 2

[0079] Figure 2 is a flowchart showing a method performed by a user equipment according to Embodiment 1 of the present invention.

[0080] As Figure 2 shown, in step 201, the user equipment receives an RRC release message from the base station.

[0081] In step 203, when the multicastConfigInactive field and the inactivePTM-Config field for carrying the MBS multicast configuration message are included in the RRC release message, but the mbs-SessionInfoList field is not included in the inactivePTM-Config field, the UE performs at least one of the following operations:

[0082] Operation 2-1: (The UE believes that) all joined or configured MBS multicast sessions are configured to be receivable in RRC_INACTIVE.

[0083] Operation 2-2: The UE believes that the configured MBS multicast session (i.e., the MBS multicast session whose PTM configuration the UE has received through the RRC reconfiguration message in the RRC connected state) is not indicated to stop detecting the G-RNTI.

[0084] Operation 2-3: The UE believes that an indication to stop detecting the G-RNTI for the configured MBS multicast session has been received.

[0085] Operation 2-4: If the inactivePTM-Config field contains the mbs-NeighbourCellList field, where the mbs-NeighbourCellList field is a list of neighbour cells providing one or more MBS multicast services for RRC_INACTIVE that are provided by the current cell, the UE considers that all cells included in the mbs-NeighbourCellList field provide all configured MBS multicast services for RRC_INACTIVE reception on the MTCH (i.e., multicast MTCH).

[0086] Operation 2-5: Obtain the MBSMulticastConfiguration message from the multicast MCCH of the concerned cell in the next repetition period.

[0087] Operation 2-6: The UE does not suspend any MRBs of the configured MBS multicast sessions.

[0088] In the present disclosure, the mbs-SessionInfoList field provides the configuration of each MBS session provided by MBS multicast in the current cell.

[0089] [Variant of Embodiment 2]

[0090] Replace "UE considers that all joined multicast sessions are configured to be receivable in RRC_INACTIVE" in Embodiment 2 with one of the following to obtain an embodiment: UE considers that all configured MBS multicast sessions can be received in RRC_INACTIVE; UE considers that all joined multicast sessions are configured to be receivable in RRC_INACTIVE in the current serving cell; UE considers that all configured multicast sessions in the current serving cell are configured to be receivable in RRC_INACTIVE; UE considers that all joined multicast sessions are configured to be receivable in RRC_INACTIVE in the current serving cell before obtaining the multicast MCCH; UE considers that all configured multicast sessions in the current serving cell are configured to be receivable in RRC_INACTIVE before obtaining the multicast MCCH.

[0091] It should be noted that the configured MBS multicast session in the embodiments of the present disclosure refers to the MBS multicast session configured when the UE is in the RRC connected state. In the present disclosure, the multicast session or service is the MBS multicast session or service.

[0092] In the embodiments executed by the UE or the base station in the present disclosure, they can be executed by the RRC entity in the UE or the base station or executed at the RRC layer. In the present disclosure, fields, domains, and information elements can be used interchangeably. In the embodiments of the present disclosure, if there are multiple operations, the embodiments obtained by changing the execution order of the transformation operations are also within the protection scope of the present disclosure. When there are multiple parallel judgment conditions, the embodiments obtained by changing the order of the judgment conditions are also within the protection scope of the present disclosure.

[0093] Next, use Figure 3 to illustrate the user equipment that can execute the method executed by the user equipment described in detail above in one embodiment of the present invention.

[0094] Figure 3 is a block diagram showing the user equipment UE involved in the present invention.

[0095] As Figure 3 shown, the user equipment UE400 includes a processor 401 and a memory 402. The processor 401 can include, for example, a microprocessor, a microcontroller, an embedded processor, etc. The memory 402 can 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 memories. Program instructions are stored on the memory 402. When executed by the processor 401, these instructions can execute the above-mentioned method executed by the user equipment described in detail in the present invention.

[0096] Above, based on Embodiment 1 and others, the method executed by the user equipment and the user equipment involved in the present invention have been described in detail. However, the present invention is not limited to the method executed by the user equipment and the user equipment, and can also be implemented in other ways as long as the gist of the present invention can be achieved.

[0097] The methods and the devices involved in the present disclosure have been described above in combination with the preferred embodiments. Those skilled in the art can understand that the methods shown above are only exemplary, and the above-described embodiments can be combined with each other without conflict. The methods of the present invention are not limited to the steps and sequences shown above.

[0098] In the embodiments of the present disclosure, in the case of including multiple operations, 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 protection scope of the present disclosure. In addition, in the case of including multiple judgment conditions, the embodiments obtained by changing the execution order of each judgment condition are also within the protection scope 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...", "when...", "meet...", or "meet... conditions" can be replaced by "in the case of...". In the embodiments of the present disclosure, the embodiments obtained by replacing "and" with "or" in some or all of the conditions are also within the protection scope of the present disclosure; the embodiments obtained by replacing "or" with "and" in some or all of the conditions are also within the protection scope of the present disclosure

[0099] In addition, the user equipment shown above may include more modules. For example, it may also include modules that can be developed or will be developed and can be used for base stations, MMEs, or UEs, etc. The various identifiers shown above are merely exemplary and not restrictive, and the present disclosure is not limited to the specific cells that are examples of these identifiers. Those skilled in the art can make many changes and modifications according to the teachings of the illustrated embodiments

[0100] It should be understood that the above embodiments of the present disclosure can be implemented by software, hardware, or a combination of software and hardware. For example, various components inside the base station and user equipment in the above embodiments can be implemented by 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), complex programmable logic devices (CPLDs), etc

[0101] 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 volatile memory (such as random access memory RAM), hard disk drive (HDD), non-volatile memory (such as flash memory), or other memory systems

[0102] The computer-executable instructions or programs for implementing the functions of the embodiments of the present invention can be recorded on a computer-readable storage medium. The corresponding functions can be implemented by causing a computer system to read the programs recorded on the recording medium and execute these programs. The so-called "computer system" here can be a computer system embedded in the device, and can include an operating system or hardware (such as peripheral devices). The "computer-readable storage medium" can be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a recording medium for short-term dynamically storing programs, or any other recording medium readable by a computer.

[0103] The various features or functional modules of the devices used in the above embodiments can be implemented or executed by circuits (for example, single-chip or multi-chip integrated circuits). The circuits designed to execute the functions described in this specification can include general-purpose processors, digital signal processors (DSPs), application-specific 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 can be a microprocessor, or any existing processor, controller, microcontroller, or state machine. The above circuits can be digital circuits or analog circuits. In the case where new integrated circuit technologies that replace existing integrated circuits emerge due to the progress of semiconductor technology, one or more embodiments of the present invention can also be implemented using these new integrated circuit technologies.

[0104] In addition, the present invention is not limited to the above embodiments. Although various examples of the described 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 devices, kitchen appliances, cleaning devices, air conditioners, office equipment, vending machines, and other household appliances, etc.

[0105] As described above, the embodiments of the present invention have been described in detail with reference to the drawings. However, the specific structure is not limited to the above embodiments, and the present invention also includes any design changes that do not deviate from the gist of the present invention. In addition, various changes can be made to the present invention within the scope of the claims, and the embodiments obtained by appropriately combining the technical means invented in different embodiments are also included in the technical scope of the present invention. Moreover, the components having the same effects described in the above embodiments can be mutually replaced.

Claims

1. A method performed by a user equipment UE, comprising: The UE receives a Radio Resource Control Release (RRCRelease) message from a base station; When the suspendConfig field is included in the RRCRelease message and the sdt-Config is configured, the UE performs any one of the following operations: Operation 1-1: For each non-suspended RLC bearer (except for the RLC bearer associated with the multicast MRB of the MBS multicast session configured to receive in RRC_INACTIVE and not indicated to stop detecting the G-RNTI), reconstruct the RLC entity corresponding to the RLC bearer; Operation 1-2: For each non-suspended RLC bearer (except for the RLC bearer associated with the multicast MRB of the MBS multicast session not indicated to stop detecting the G-RNTI), reconstruct the RLC entity corresponding to the RLC bearer; Operation 1-3: For each non-suspended RLC bearer associated with a DRB and / or the multicast MRB of the MBS multicast session indicated to stop detecting the G-RNTI, reconstruct the RLC entity corresponding to the RLC bearer; Operation 1-4: For each non-suspended RLC bearer associated with a DRB and / or the multicast MRB of the non-in-progress MBS multicast session, reconstruct the RLC entity corresponding to the RLC bearer; Operation 1-5: For each non-suspended RLC bearer (except for the RLC bearer associated with the multicast MRB of the MBS multicast session configured to receive in RRC_INACTIVE and / or detecting the corresponding G-RNTI), reconstruct the RLC entity corresponding to the RLC bearer; Operation 1-6: For each non-suspended RLC bearer (except for the RLC bearer associated with the multicast MRB of the MBS multicast session configured to receive in RRC_INACTIVE and / or in progress), reconstruct the RLC entity corresponding to the RLC bearer.

2. The method according to claim 1, wherein The suspendConfig field is used to indicate the configuration of the RRC inactive state, and the sdt-Config field is used to indicate the configuration related to small data transmission (SDT).

3. The method according to claim 1 or 2, wherein Reconstructing the RLC entity includes at least one of the following operations: Discarding all RLC SDUs, RLC SDU segments, and all RLC PDUs; Stopping and resetting all timers; Resetting all state variables to their respective initial values.

4. The method according to claim 1 or 2, wherein The UE is performing MBS multicast service when receiving the RRCRelease message.

5. The method according to claim 1 or 2, wherein The UE is performing SDT when receiving the RRCRelease message.

6. A user equipment, comprising: A processor; And A memory, on which instructions are stored; Wherein, when the instruction is run by the processor, the user equipment is caused to execute the method according to any one of claims 1-5.

Images