User equipment, base station, and method therefor

Abstract

On the basis of the present invention, provided are a user equipment (UE), a base station, and a method therefor. The method executed by the UE comprises: receiving an RRC setup message from a base station; and upon the reception of the RRC setup message from the base station, resetting MAC if a small data transmission (SDT) is being performed.

Description

User equipment, base station and methods thereof TECHNICAL FIELD

[0001] The present application relates to the technical field of wireless communication, and more particularly, to user equipment, base station and methods thereof. BACKGROUND

[0002] A study item (SI) on 5G multicast broadcast service architecture improvement (see non-patent document: 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, and the 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. Accordingly, at the 3rd Generation Partnership Project (3GPP) RAN #86 plenary meeting, a work item (see non-patent document: RP-193248: New WID: NR Multicast and Broadcast Service) on NR multicast and broadcast service (NRMBS) was proposed 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 description of the related solutions can be found in 3GPP Release 17 technical documents, such as TS 38.300-h70, TS 38.331-h70, TS 38.321-h70, etc. At the 3GPP RAN #94 plenary meeting, a work item named Enhancements of NR Multicast and Broadcast Services (see non-patent document: RP-213568: New WID: Enhancements of NR Multicast and Broadcast Services) was approved. This work item aims to further enhance the MBS broadcast multicast of Release 17, and one of its objectives is to support user equipment receiving MBS multicast services / sessions in RRC inactive state.

[0003] The present application discusses related issues involved in supporting user equipment receiving MBS multicast services / sessions in RRC inactive state by RAN. SUMMARY

[0004] In order to solve at least part of the above problems, the present application provides user equipment, base station and methods thereof, which can avoid conflicts when scheduling SDT data and MBS multicast data.

[0005] To achieve the above object, according to the present application, a method performed by a user equipment (UE) is provided, comprising: receiving a RRC setup message from a base station; and resetting a MAC if a small data transmission (SDT) is ongoing when the RRC setup message from the base station is received.

[0006] Preferably, the RRC setup message is a response message to a RRC resume request message or a RRC resume request 1 message previously sent by the UE to the base station.

[0007] Preferably, the resetting the MAC comprises at least one of: stopping all MBS multicast discontinuous reception (DRX) timers; stopping all DRX timers if the resetting the MAC request is due to the RRC setup message received by an upper layer; emptying soft buffer of all MBS multicast used downlink (DL) hybrid automatic repeat request (HARQ) processes; emptying soft buffer of all SDT used DL HARQ processes or emptying soft buffer of all DL HARQ processes if the resetting the MAC request is due to the RRC setup message received by the upper layer; considering next reception transmission of a transport block (TB) as a first transmission for each DL HARQ process used by MBS multicast; and considering next reception transmission of a TB as a first transmission for each DL HARQ process being used by SDT or for all DL HARQ processes if the resetting the MAC request is due to the RRC setup message received by the upper layer.

[0008] Further, according to the present application, a method performed by a user equipment (UE) is provided, comprising: including information indicating that the UE is configured to receive MBS multicast in a RRC inactive state in a RRC resume request message if the UE is configured to receive MBS multicast in a RRC inactive state for a small data transmission (SDT) purpose; and initiating transmission of the RRC resume request message.

[0009] In addition, according to the present application, a user equipment is provided, comprising: a processor; and a memory storing instructions which, when executed by the processor, perform the above method.

[0010] Further, according to the present application, a method performed by a base station is provided, comprising: sending a retrieve UE context request message including a small data transmission (SDT) indication information and / or SDT assistance information to a last serving base station when a RRC resume request message from a user equipment (UE) is received; and always receiving a retrieve UE context response message for migrating all UE contexts from the last serving base station if the UE is configured to receive MBS multicast in a RRC inactive state.

[0011] In addition, according to the present application, a method performed by a base station is provided, comprising: sending, to a last serving base station, a UE context retrieval request message including small data transmission (SDT) indication information and / or SDT auxiliary information when receiving an RRC resume request message from a user equipment (UE); and receiving, from the last serving base station, a partial UE context transfer message including information indicating that the UE is configured to receive MBS multicast in an RRC inactive state if the UE is configured to receive MBS multicast in an RRC inactive state.

[0012] Furthermore, according to the present application, a base station is provided, comprising: a processor; and a memory storing instructions, wherein the instructions, when executed by the processor, perform the above-mentioned method.

[0013] Effects of Invention

[0014] According to the present application, it is possible to avoid the inconsistency between the user equipment and the base station MAC entity state when establishing an RRC connection and / or the conflict when scheduling SDT data and MBS multicast data in the case of RRC_INACTIVE. BRIEF DESCRIPTION OF DRAWINGS

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

[0016] FIG. 1 is a flow chart illustrating a method one performed by a user equipment according to the present application.

[0017] FIG. 2 is a flow chart illustrating a method two performed by a user equipment according to the present application.

[0018] FIG. 3 is a flow chart illustrating a method one performed by a base station according to the present application.

[0019] FIG. 4 is a block diagram schematically illustrating a user equipment related to the present application.

[0020] FIG. 5 is a block diagram schematically illustrating a base station related to the present application. DETAILED DESCRIPTION

[0021] Some terms related to the present application are described below, and the specific meanings of the terms can be referred to the latest related documents of 3GPP, such as TS38.300, TS38.321, TS38.323, TS38.331, etc. In addition, the embodiments of the present application are described taking broadcast / multicast services as an example, but the embodiments of the present application are not limited to broadcast / multicast services, and can also be applied to other application scenarios.

[0022] UE: User Equipment, user equipment.

[0023] RRC: Radio Resource Control

[0024] RRC_CONNECTED: RRC connected state

[0025] RRC_INACTIVE: RRC inactive state

[0026] RRC_IDLE: RRC idle state

[0027] RAN: Radio Access Network

[0028] NR: New RAT

[0029] MBS: Multicast / Broadcast Services

[0030] AS: Access Stratum

[0031] NAS: Non Access Stratum

[0032] RB: Radio Bearer

[0033] MRB: MBS Radio Bearer

[0034] TMGI: Temporary Mobile Group Identity

[0035] RNTI: Radio Network Temporary Identifier

[0036] HARQ: Hybrid Automatic Repeat reQuest

[0037] PTM: Point to Multipoint, a delivery mode of MBS service. In PTM delivery mode, the base station delivers a single copy of MBS data packets to a set of UEs (gNB delivers a single copy of MBS data packets to a set of UEs). The UE uses G-RNTI or G-CS-RNTI to receive PTM transmission. For example, the base station uses group common physical downlink control channel PDCCH with G-RNTI to schedule the same group common physical downlink shared channel PDSCH with G-RNTI.

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

[0039] MTCH: MBS Traffic Channel, an MBS service channel, is a PTM downlink channel used for transmitting MBS data of multicast session or broadcast session from the network to the UE. Unless otherwise specified, the MTCH referred to in the embodiments of the present disclosure refers to multicast MTCH used for transmitting MBS multicast session.

[0040] MCCH: MBS Control Channel, an 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. The MCCH includes broadcast MCCH and multicast MCCH. Unless otherwise specified, the MCCH referred to in the embodiments of the present disclosure refers to multicast MCCH.

[0041] RRCResumeRequest or RRCResumeRequest1 is used to request to resume a suspended RRC connection or to perform a RAN-based notification area, RNA, update. The UE uses the RRCResumeRequest1 message and sets the resumeIdentity field in the RRCResumeRequest1 message to the UE stored full I-RNTI, or uses the RRCResumeRequest and sets the resumeIdentity field in the RRCResumeRequest message to the stored short I-RNTI, if the useFullResumeID field is included in the SIB1 received from the camped or serving cell or the cell performing the RRC resume procedure when initiating the RRC connection resume request. The RRCRelease message is used to order the release of one RRC connection or to suspend one RRC connection. The RRCReconfiguration message is used to order the modification of an RRC connection. The RRCSetup message is used to establish SRB1. SRB1 is used for RRC messages, which can include piggybacked NAS messages, and NAS messages prior to the establishment of SRB2, both using the dedicated control channel, DCCH, logical channel. The RRCResume message is used to resume a suspended RRC connection. In this disclosure, the useFullResumeID field indicates the resume identity and resume request message to use, the full I-RNTI and RRCResumeRequest1 message when the field is included in the SIB1, or the short I-RNTI and RRCResumeRequest message when the field is not included in the SIB1. The short I-RNTI uses fewer bits than the I-RNTI-Value, i.e. full I-RNTI, to identify the suspended UE context of the UE in RRC inactive state. The RRC resume procedure, i.e. RRC connection resume procedure, is used to resume a suspended RRC connection, including resuming SRB(s), DRB(s) and multicast MRB(s), or to perform an RNA update, or to implement an MBS multicast reception request, or to initiate small data transmission, SDT, in RRC_INACTIVE state, etc. In the RRC resume procedure, the UE sends the RRC resume request message to the base station and can receive the RRC resume message RRCResume or the RRC setup message RRCSetup or the RRC release message RRCRelease or the RRC reject message RRCReject from the base station.

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

[0043] Currently, the NR MBS service includes MBS broadcast (also referred to as MBS broadcast session or broadcast MBS or MBS broadcast service or MBS broadcast service) and MBS multicast (also referred to as MBS multicast session or multicast MBS or MBS multicast service or MBS multicast service). The MBS broadcast provides a downlink-only MBS transmission mode for low quality of service (QoS) services, so that UEs in RRC connected state, RRC idle state and RRC inactive state can all receive the MBS service. The UE obtains the MBS broadcast configuration information broadcast by the network through the MBS control channel (MCCH).

[0044] In Rel-17, UE is not supported to receive MBS multicast session in RRC inactive state. Therefore, UE needs to establish RRC connection with the base station before receiving MBS multicast service (i.e. MBS multicast session), and then the UE is configured by the base station (i.e. network) through dedicated RRC signaling (also called RRC message, e.g. RRC reconfiguration message) to receive the resource or PTM configuration of MBS multicast service, and the MBS radio bearer (MRB) for receiving these MBS multicast services is also configured by the base station through dedicated RRC signaling for the UE. Only the UE in RRC connected state and configured with MRB can receive the corresponding MBS multicast service. The base station can send MBS multicast service in PTM mode or PTP mode. Using PTM mode to send MBS multicast service means that the transport block containing MBS multicast session data is addressed by G-RNTI (or the PDCCH scheduling the transport block is addressed or scrambled by G-RNTI), while using PTP mode to send MBS multicast service means that the transport block containing MBS multicast session data is addressed by C-RNTI (or the PDCCH scheduling the transport block is addressed or scrambled by C-RNTI). Therefore, when a 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 the UE in RRC idle state or RRC inactive state through a group notification mechanism. Upon receiving the group notification, the UE that has joined or is interested in the MBS multicast session establishes or resumes RRC connection with the network to receive the corresponding MBS multicast session. The group notification is addressed with P-RNTI on PDCCH, and the UE monitors the paging channel. The paging message for group notification contains MBS session identification TMGI, which is used to page all UEs that have joined the related MBS multicast session and are in RRC idle state or RRC inactive state. In other words, the base station does not individually page the UE (for the purpose of receiving MBS multicast session).

[0045] In Release 18, UE is supported to receive MBS multicast session in RRC inactive state. For MBS multicast session configured for RRC inactive state reception, the base station can provide or configure the PTM configuration information (also referred as configuration information of MBS multicast session or PTM configuration of MBS multicast session or MBS multicast configuration) for UE to receive the MBS multicast session through dedicated RRC signaling (e.g. RRCRelease message) or through multicast MBS control channel MCCH (i.e. multicast MCCH). While the information required to acquire the multicast MCCH (or multicast MCCH configuration) can be configured for UE through dedicated RRC signaling or system information block (denoted as SIB24), i.e. SIB24 contains the information required to acquire the configuration of multicast MCCH / MTCH (i.e. MCCH and / or MTCH) for RRC inactive state MBS multicast reception. The PTM configuration information can include the configuration information of 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 / or other configuration information. For example, the PTM configuration of a certain MBS multicast session is the information contained in MBSMulticastConfiguration message related to the reception of the MBS multicast session. Wherein, 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 multicast MCCH or contained in RRC release message. Wherein, 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 the MBS multicast session received in RRC_INACTIVE state, the MBS multicast session in the embodiment of the present disclosure is in the active state or activated, which means that the MBS multicast session is ongoing or about to start, 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 monitor the multicast MCCH-RNTI of the multicast MCCH. The network can indicate the UE that the MBS multicast is activated or resumes data transmission through the multicast MCCH or RRC signaling (such as RRC release message) or through the paging message. For example, the TMGI of the MBS multicast session is included in the paging message, which means that the MBS multicast session is activated or resumes data transmission, and the stopMonitoringRNTI field of the MBS multicast session is not included in the multicast MCCH or RRC release message, which means that the MBS multicast session is activated or resumes data transmission, wherein the stopMonitoringRNTI field is used to indicate the UE to stop detecting the G-RNTI corresponding to the multicast session. The UE starts to receive the MBS multicast session after receiving the indication that the MBS multicast is activated or resumes data transmission (i.e., the UE starts to detect the G-RNTI corresponding to the MBS multicast session). The MBS multicast activated in the embodiment of the present disclosure also applies to the case of resuming the data transmission of the MBS multicast session, which will not be described below. The MBS multicast session in the embodiment of the present disclosure is in the inactive state or deactivated, which means that the MBS multicast session has ended or paused data transmission or the UE stops receiving the MBS multicast session (i.e., the UE stops detecting the G-RNTI corresponding to the MBS multicast session). The network associates a stopMonitoringRNTI field for each MBS multicast session in the multicast MCCH message to explicitly indicate the UE to stop detecting the G-RNTI corresponding to the MBS multicast session (i.e., to indicate that the MBS multicast session is deactivated or stops data transmission). The UE stops receiving the MBS multicast session after receiving the indication. The UE stops receiving 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 that the MBS multicast session is deactivated or stops data transmission is the indication that the UE stops detecting the G-RNTI or G-CS-RNTI associated with the MBS multicast session. In addition, the indication that the MBS multicast session is activated or resumes data transmission is the indication that the UE starts to detect the G-RNTI corresponding to the MBS multicast session, i.e., the MBS multicast session is not indicated to stop detecting the G-RNTI. The MBS multicast session is deactivated, which includes the case that the MBS multicast session has no data transmission temporarily, and the MBS multicast session is activated, which includes the case that the MBS multicast session resumes data transmission.In this disclosure, a multicast session or service is MBS multicast session or service. The following embodiments are illustrated by taking G-RNTI as an example, and the embodiments obtained by replacing G-RNTI with G-CS-RNTI are also within the scope of this disclosure.

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

[0047] For a UE configured with MBS multicast sessions that can be received in RRC_INACTIVE state, when a MBS multicast session is activated or data transmission is resumed, if the MBS multicast session is configured and / or allowed to be received in RRC_INACTIVE state and / or the UE is in (valid) PTM configuration with the MBS multicast session, the UE can directly receive the MBS multicast session without establishing RRC connection with the base station. The network can configure the PTM configuration information (e.g., contained in MBSMulticastConfiguration message) of the MBS multicast session received in RRC_INACTIVE state for the UE through multicast MCCH and / or dedicated RRC signaling (e.g., RRC release message, RRC reconfiguration message). The MBS multicast configuration message MBSMulticastConfiguration can be transmitted on the multicast MCCH (at this time the MBSMulticastConfiguration message can be referred to as the multicast MCCH message), or can be contained in the RRC release message. If the RRC release message is used to configure the PTM configuration information of the MBS multicast session received in RRC_INACTIVE state for the UE, the network can contain the MBSMulticastConfiguration message in the RRC release message sent to the UE.

[0048] When the UE receives the RRC release message from the base station, when the multicastConfigInactive field is contained in the received RRC release message, it indicates that the UE has been configured to receive MBS multicast in RRC_INACTIVE. The multicastConfigInactive field indicates whether the UE is configured to receive the multicast session in RRC_INACTIVE.

[0049] The multicastConfigInactive field can contain two fields, namely an inactivePTM-Config field and an inactiveMCCH-Config field. The inactivePTM-Config field indicates the PTM configuration for receiving MBS multicast in RRC_INACTIVE in the serving cell, where the MBSMulticastConfiguration message is carried. The inactiveMCCH-Config field carries the system information SIB24.

[0050] Currently, it can be achieved by including the TMGI of the MBS multicast session in the paging message to indicate the UE to start detecting the G-RNTI of the MBS multicast session (i.e. if the UE receives the paging message containing a TMGI of an MBS multicast session allowed / configured to be received in RRC_INACTIVE, it means that the UE receives the indication to start detecting the G-RNTI of the MBS multicast session). It can also be indicated in the MBSMulticastConfiguration message whether to stop detecting the G-RNTI corresponding to the MBS multicast session. Specifically, for the MBS multicast session whose TMGI is included in the MBSMulticastConfiguration message, if the MBSMulticastConfiguration message further contains the stopMonitoringRNTI field of the MBS multicast session, it means that the UE receives the indication to stop detecting the G-RNTI (i.e. stop detecting the G-RNTI of the MBS multicast session) of the MBS multicast session. Otherwise (i.e. the MBSMulticastConfiguration message does not contain the stopMonitoringRNTI field of the MBS multicast session), it means that the UE does not receive the indication to stop detecting the G-RNTI of the MBS multicast session. The stopMonitoringRNTI field indicates the UE to stop detecting the G-RNTI of the corresponding MBS multicast session. By associating / configuring a stopMonitoringRNTI field for each MBS multicast session, it indicates to stop detecting the G-RNTI of the 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. Specifically, the MBSMulticastConfiguration message can be included in the MulticastConfigInactive field in the suspendConfig field of the RRC release message.The suspendConfig field indicates the configuration of the RRC_INACTIVE state. If the UE receives an RRC release message containing an MBSMulticastConfiguration message or a MulticastConfigInactive field, it is considered that the UE is configured to receive MBS multicast or multicast sessions in RRC_INACTIVE. Or if the UE receives an RRC release message (or an MBSMulticastConfiguration message contained in the RRC release message) containing a TMGI, it is considered that the UE is configured to receive MBS multicast in RRC_INACTIVE. It should be noted that the UE obtaining multicast MCCH means that the UE obtains the MBSMulticastConfiguration message from the multicast MCCH.

[0051] When a UE initiates an RRC resume procedure for small data transmission (SDT) purpose, the receiving gNB (also referred to as new gNB or new NG-RAN node) sends a Retrieve UE Context Request message to the last serving gNB (also referred to as old gNB or old NG-RAN node) upon receiving the RRCResumeRequest from the UE, which carries SDT indication information and / or SDT assistance information. The SDT assistance information indicates whether there is a subsequent SDT transmission expected or no subsequent SDT transmission expected. The last serving gNB decides whether to relocate the full UE context for SDT upon receiving this message. If the last serving gNB decides to keep the UE context, it sends a Partial UE Context Transfer message to the receiving gNB, which contains SDT DRB and / or SDT SRB related information, such as containing SDT RLC context information necessary for the receiving gNB to handle SDT. During the SDT procedure, if there is downlink non-SDT data to be transmitted, the last serving gNB sends a message to the receiving gNB to trigger the receiving gNB to send an RRCSetup message to the UE. For example, the last serving gNB sends a Retrieve UE Context Failure message to the receiving gNB, and includes the RRCSetup message in the Retrieve UE Context Failure message, thereby triggering the receiving gNB to send or forward the RRCSetup message to the UE. Whether the UE performs MAC reset upon receiving the RRCSetup message is a problem to be solved. In addition, if the UE is also configured to receive an MBS multicast session in RRC_INACTIVE, the receiving gNB does not know whether the UE performing SDT is also configured to receive an MBS multicast session in RRC_INACTIVE if the SDT procedure adopts the partial UE context transfer mode. Since the data for the MBS multicast session and the data for SDT share a HARQ process, this can cause the data for the MBS multicast session to overwrite the data for SDT waiting for retransmission in the HARQ buffer, resulting in loss of SDT data, and vice versa.

[0052] It is to be noted that in the present disclosure, initiating the RRC resume procedure for small data transmission (SDT) purpose can include that the UE receives a paging message containing an "MT-SDT" (i.e. terminal-oriented SDT, also known as downlink SDT) indication for the UE and uplink small data arrival and the conditions for initiating small data transmission are met. In the present disclosure, the RETRIEVE UE CONTEXT REQUEST message is sent by the new NG-RAN node to request the old NG-RAN node to transfer the UE Context to the new NG / RAN, the PARTIAL UE CONTEXT TRANSFER message is sent by the old NG-RAN node to transfer part of the UE Context to the new NG-RAN node; the RETRIEVE UE CONTEXT FAILURE message is sent by the old NG-RAN node to inform the new NG-RAN node that the Retrieve UE Context procedure has failed.

[0053] In order to solve the problems in the prior art, the present disclosure proposes the following embodiments, but the following embodiments are only used for illustration and do not limit the protection scope of the present application.

[0054] Fig. 1 is a flow chart showing a method one performed by a user equipment according to the present application.

[0055] As shown in Fig. 1, at step 101, the UE or the RRC entity of the UE receives an RRCSetup message from a base station.

[0056] At step 103, when receiving the RRCSetup message from the base station, if SDT is ongoing, reset the MAC (e.g., the RRC entity of the UE instructs the MAC entity of the UE to perform the reset of the MAC). Wherein, the RRCSetup message is a response message to the RRCResumeRequest or RRCResumeRequest1 message previously sent by the UE to the base station.

[0057] If the reset MAC request is due to the upper layers receiving RRCResume or RRCSetup (a reset of the MAC entity is requested by upper layers upon receiving RRCResume or RRCSetup), the MAC entity performs at least one of the following operations:

[0058] 1. Stop all MBS multicast discontinuous reception (DRX) timers (this operation is performed only if the timer exists or only if SDT is not ongoing).

[0059] 2. If the reset MAC request is due to the upper layers receiving RRCSetup message, stop all DRX timers. It can be specified that this operation is performed only if SDT is ongoing.

[0060] 3. Flush the soft buffers for all DL HARQ processes used for MBS multicast. Alternatively, flush the soft buffers for all DL HARQ processes used for MBS multicast, except for the DL HARQ processes being used by SDT. Alternatively, if the reset MAC request is due to the upper layers receiving RRCResume, flush the soft buffers for all DL HARQ processes used for MBS multicast, except for the DL HARQ processes being used by SDT. It can be specified that this operation is performed only if SDT is not ongoing.

[0061] 4. If the reset MAC request is due to the upper layers receiving RRCSetup message, flush the soft buffers for all DL HARQ processes used for SDT or flush the soft buffers for all DL HARQ processes. It can be specified that this operation is performed only if SDT is ongoing.

[0062] 5. For each DL HARQ process used for MBS multicast, consider the next received transmission for a TB as the very first transmission. Alternatively, for each DL HARQ process used for MBS multicast, consider the next received transmission for a TB as the very first transmission, except for the DL HARQ processes being used by SDT. Alternatively, if the reset MAC request is due to RRCResume received by upper layers, for each DL HARQ process used for MBS multicast, consider the next received transmission for a TB as the very first transmission, except for the DL HARQ processes being used by SDT. It can be specified that this is only performed when SDT is not ongoing.

[0063] 6. If the reset MAC request is due to RRCSetup message received by upper layers, for each DL HARQ process being used by SDT or for all DL HARQ processes, consider the next received transmission for a TB as the very first transmission. It can be specified that this is only performed when SDT is ongoing.

[0064] It is noted that a DL HARQ process being used by SDT can refer to the latest received downlink assignment or PDCCH for the process being for C-RNTI or CS-RNTI of the MAC entity. A DL HARQ process used for MBS multicast can refer to the latest received downlink assignment or PDCCH for the process being for G-RNTI of the MAC entity.

[0065] In addition, a new UE capability can be defined for whether the UE in ongoing SDT supports receiving the RRCSetup message, with a parameter resumeAfterSDT-RRCSetup, so that the UE can indicate whether it supports receiving the RRC connection setup message RRCSetup to establish the RRC connection in the ongoing SDT procedure. Specifically, the UE receives a UECapabilityEnquiry message from the base station, and if the parameter RAT-Type set to nr for indicating the RAT type of the UE capability requested by the network in the message, the UE sends a UECapabilityInformation message to the base station, which contains the parameter resumeAfterSDT-RRCSetup. Wherein, the UECapabilityEnquiry message is used to request the UE's wireless access capability of NR or other RAT, and the UECapabilityInformation message is used to transmit the UE's wireless access capability requested by the network.

[0066] When the UE starts the RRC resume procedure for the purpose of small data transmission SDT, in order to facilitate the receiving base station to determine whether the UE is configured to receive MBS multicast in RRC_INACTIVE, the UE can indicate the relevant information in the RRC resume request message (i.e. RRCResumeRquest or RRCResumeRquest1 message), for example, set the parameter resumeCause contained in the RRCResumeRquest message to a value corresponding to the indication that the UE is configured to receive MBS multicast in RRC_INACTIVE, or include the TMGI of the MBS multicast session that the UE has joined or is configured to receive in RRC_INACTIVE in the RRC resume request message. Wherein, the parameter resumeCause is used to provide the resume cause for the RRC connection resume request as provided by the upper layers or RRC.

[0067] Figure 2 is a flow chart showing a method two performed by a user equipment according to the present application.

[0068] As shown in FIG. 2, at step 201, for starting the RRC resume procedure for the SDT purpose, if the UE is configured to receive MBS multicast in RRC_INACTIVE, the parameter resumeCause carried in the RRC resume request message is set to a value corresponding to the UE being configured to receive MBS multicast in RRC_INACTIVE or the parameter resumeCause is set to a value corresponding to the UE being configured to receive MBS multicast in RRC_INACTIVE for the SDT purpose or the TMGI of the MBS multicast session that the UE has joined or is configured to receive in RRC_INACTIVE is included in the RRC resume request message.

[0069] At step 203, the transmission of the RRC resume request message is initiated.

[0070] In order to avoid the conflict of the receiving gNB in scheduling the SDT data and the MBS multicast data, the last serving gNB can also decide whether to migrate all UE contexts for the SDT migration according to whether the UE is configured to receive MBS multicast in RRC_INACTIVE.

[0071] FIG. 3 is a flow chart illustrating a method one performed by a base station according to the present application.

[0072] As shown in FIG. 3, at step 301, the receiving gNB (also referred to as a new gNB) sends a RETRIEVE UE CONTEXT REQUEST message to the last serving gNB when receiving the RRC resume request message from the UE, and the message carries SDT indication information and / or SDT assistance information.

[0073] At step 303, if the UE is configured to receive MBS multicast in RRC_INACTIVE, the last serving gNB always uses the RETRIEVE UE CONTEXT RESPONSE as the response message (i.e., always migrates all UE contexts). In other words, for the UE configured to receive MBS multicast in RRC_INACTIVE, the last serving gNB does not use the partial UE context transfer (i.e., does not use the PARTIAL UE CONTEXT TRANSFER message as the response message).

[0074] The above step 303 can be replaced by step 303a.

[0075] In step 303a, the last serving gNB decides whether to relocate the full UE context for SDT migration upon receiving the RETRIEVE UE CONTEXT REQUEST message. If the last serving gNB decides to transfer partial UE context, for the case that the UE is configured to receive MBS multicast in RRC_INACTIVE, the last serving gNB carries an indication that the UE is configured to receive MBS multicast in RRC_INACTIVE in the PARTIAL UE CONTEXT TRANSFER message. The indication can be the TMGI or TMGI list of MBS multicast that the UE has joined, or the TMGI or TMGI list of MBS multicast that the UE is configured to receive in RRC_INACTIVE, or an indication of whether the UE is configured to receive MBS multicast in RRC_INACTIVE.

[0076] To avoid the conflict of scheduling SDT data and MBS multicast data at the receiving gNB, it can be specified that the downlink HARQ process(es) used by SDT and the downlink HARQ process(es) used by MBS multicast received or transmitted in RRC_INACTIVE are different. In other words, one or more downlink HARQ processes are dedicated for SDT, and other one or more downlink HARQ processes are dedicated for MBS multicast received or transmitted in RRC_INACTIVE.

[0077] To avoid the conflict of scheduling SDT data and MBS multicast data at the receiving gNB, it can also be specified that the downlink HARQ process(es) for which no positive acknowledgement ACK of SDT data transmission is received is not used for MBS multicast. In other words, if a downlink HARQ process is used to transmit SDT data or transport block TB and no positive acknowledgement ACK of the SDT data or transport block TB from the UE is received, the downlink HARQ process cannot be used to transmit (or transport or retransmit) MBS multicast data or MBS multicast TB. For the downlink HARQ process used for MBS multicast data or MBS multicast TB, if the base station expects to receive a positive acknowledgement ACK or negative acknowledgement NACK from the UE, this downlink HARQ process is not used to transport (or retransmit) SDT data or transport block TB until a positive acknowledgement ACK or negative acknowledgement NACK from the UE is received.

[0078] To avoid the conflict between the SDT data and the MBS multicast data, when the UE receives the first type of data for a certain HARQ process, it determines whether there is the second type of data waiting for retransmission in the soft buffer area of the HARQ process. If there is, the UE maps the first data to another HARQ process in which there is no data waiting for retransmission, otherwise, the UE covers the data in the soft buffer area with the first data. The first data can be the SDT data, and the second type of data can be the MBS multicast data, or vice versa.

[0079] [Modified example]

[0080] Next, a user equipment that can execute the method performed by the user equipment described in detail above will be described as a modified example of the present application with reference to FIG. 4.

[0081] FIG. 4 is a block diagram of a user equipment UE according to the present application.

[0082] As shown in FIG. 4, the user equipment UE 40 includes a processor 401 and a memory 402. The processor 401 can include, for example, a microprocessor, a microcontroller, an embedded processor, or the like. 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 memory, or the like. The memory 402 stores program instructions. The instructions, when executed by the processor 401, can execute the above-described method performed by the user equipment described in detail above.

[0083] Next, a base station that can execute the method performed by the base station described above will be described as a modified example of the present application with reference to FIG. 5.

[0084] FIG. 5 is a block diagram of a base station according to the present application.

[0085] As shown in FIG. 5, the base station 50 includes a processor 501 and a memory 502. The processor 501 can include, for example, a microprocessor, a microcontroller, an embedded processor, or the like. The memory 502 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 memory, or the like. The memory 502 stores program instructions. The instructions, when executed by the processor 501, can execute the above-described method performed by the base station described in detail above.

[0086] Specifically, the base station according to the present application, when receiving an RRC resume request message from a user equipment (UE), sends an acquire UE context request message to the last serving base station, the acquire UE context request message including small data transmission (SDT) indication information and / or SDT assistance information; and if the UE is configured to receive MBS multicast in RRC inactive state, always receives an acquire UE context response message for migrating all UE contexts from the last serving base station. Optionally, the base station according to the present application, when receiving an RRC resume request message from a user equipment (UE), sends an acquire UE context request message to the last serving base station, the acquire UE context request message including small data transmission (SDT) indication information and / or SDT assistance information; and if the UE is configured to receive MBS multicast in RRC inactive state, receives a partial UE context transfer message from the last serving base station, the partial UE context transfer message including information indicating that the UE is configured to receive MBS multicast in RRC inactive state. For details, please refer to the above description.

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

[0088] Unless otherwise specified, the embodiments performed by the UE or the base station in the present disclosure can be performed by the RRC entity in the UE or the base station or at the RRC layer. In the present disclosure, the fields, domains, information elements, and parameters are 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 protection scope of the present disclosure, and when multiple parallel judgment conditions are included, the embodiments obtained by changing the order of the judgment conditions are also within the protection scope of the present disclosure. In the conditions involved in the embodiments of the present disclosure, “and”, “or”, “and / or”, “and”, and “and” are used interchangeably, and the embodiments obtained are also within the scope of the present disclosure.

[0089] The above has described in detail the method performed by the user equipment and the user equipment involved in the present application based on the embodiments, but the present application is not limited to the method performed by the user equipment and the user equipment, and other ways can also be used to realize the main idea of the present application.

[0090] The method and the related device of the present disclosure have been described above in combination with the preferred embodiments. Those skilled in the art can understand that the method shown above is only exemplary, and each of the embodiments described above can be combined with each other without contradiction. The method of the present application is not limited to the steps and the order shown above.

[0091] In the embodiments of the present disclosure, in the case of containing multiple operations, the embodiments of the present disclosure exemplarily list the execution sequence of each operation, and the embodiments obtained by changing the execution sequence of each operation are also within the protection scope of the present disclosure. In addition, in the case of containing multiple judgment conditions, the embodiments obtained by changing the execution sequence of each judgment condition are also within the protection scope of the present disclosure. In addition, in the present disclosure, unless specifically stated, the meaning of the domain defined in one embodiment can also be applied to the corresponding domain involved in other embodiments. In addition, in the embodiments of the present disclosure, “if”, “when”, “if...”, “when...”, “in the case of...”, “satisfy” or “satisfy the condition” can be replaced by “in the case of...”. The embodiments obtained by replacing “and”, “and”, “and” in part or all of the conditions with “or” in the embodiments of the present disclosure are also within the protection scope of the present disclosure; the embodiments obtained by replacing “or” in part or all of the conditions with “and” are also within the protection scope of the present disclosure

[0092] In addition, the user equipment shown above can include more modules, for example, modules that can be developed or developed in the future, which can be used for base stations, MMEs, or UEs, and the like. The various identifiers shown above are only exemplary and not limiting, and the present disclosure is not limited to the specific elements as examples of these identifiers. Those skilled in the art can make many changes and modifications according to the teachings of the embodiments shown.

[0093] It should be understood that the above embodiments of the present disclosure can be realized 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 realized by various 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.

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

[0095] Computer-executable instructions or programs for implementing the functions of the embodiments of the present application 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 the 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. The "computer-readable storage medium" can be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a short-time dynamic storage program recording medium, or any other recording medium readable by a computer.

[0096] The various features or functional modules of the device used in the above-described embodiments can be implemented or executed by a circuit (e.g., a single-chip or multi-chip integrated circuit). The circuit designed to perform the functions described in the present specification can include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor, but implementation is not limited thereto. The general-purpose processor can also be any existing processor, controller, microcontroller, or state machine. The circuit described above can be a digital circuit, and can also be an analog circuit. If new integrated circuit technologies emerge as a result of the advancement of semiconductor technologies, one or more embodiments of the present application can also be implemented using such new integrated circuit technologies.

[0097] Furthermore, the present application is not limited to the above-described embodiments. Although various examples of the embodiments have been described, the present application 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 devices, cleaning devices, air conditioners, office devices, vending machines, and other home appliances.

[0098] As described above, the embodiments of the present application have been described in detail with reference to the accompanying drawings. However, the specific configuration is not limited to the above-described embodiments, and the present application includes any design modification that does not deviate from the gist of the present application. In addition, various modifications can be made to the present application within the scope of the claims, and embodiments obtained by appropriately combining the technical means invented in the different embodiments are also included in the technical scope of the present application. Furthermore, components described in the above-described embodiments that have the same effect can be substituted for each other.

Claims

1. A method executed by a user equipment (UE), comprising: Receive RRC establishment message from base station; as well as When an RRC setup message is received from the base station, if Small Data Transmission Technique (SDT) is in progress, the MAC is reset.

2. The method according to claim 1, wherein, The RRC establishment message is a response message to the RRC recovery request message RRCResumeRequest or RRCResumeRequest1 previously sent by the UE to the base station.

3. The method according to claim 1, wherein, Resetting the MAC address involves at least one of the following operations: Stop all MBS multicast discontinuous reception DRX timers; If the MAC reset request is due to the upper layer receiving an RRC setup message, then stop all DRX timers; Clear the soft buffer of all downlink HARQ processes used by MBS multicast; If the MAC reset request is due to the upper layer receiving an RRC establishment message, clear the soft buffer of all downlink HARQ used by SDT or clear the soft buffer of all downlink HARQ. For each downlink HARQ process used by MBS multicast, the next receive transmission of transport block TB is regarded as the first transmission; as well as If the MAC reset request is due to the upper layer receiving an RRC setup message, the next receive transmission of TB will be regarded as the first transmission for each downlink HARQ process currently being used by SDT or for all downlink HARQ processes.

4. A method performed by a user equipment (UE), comprising: For RRC recovery procedures initiated for Small Data Transmission (SDT) purposes, if the UE is configured to receive MBS multicast in the RRC inactive state, the RRC recovery request message includes information indicating that the UE is configured to receive MBS multicast in the RRC inactive state; and Initiate the transmission of the RRC recovery request message.

5. A user equipment, comprising: processor; as well as Memory, which stores instructions The instructions, when executed by the processor, perform the method described in any one of claims 1 to 4.

6. A method performed by a base station, comprising: Upon receiving an RRC recovery request message from a user equipment (UE), a UE context request message is sent to the last serving base station. The UE context request message includes small data transmission SDT indication information and / or SDT auxiliary information. as well as If the UE is configured to receive MBS multicast in RRC inactive state, it will always receive an Get UE Context Response message from the last serving base station to migrate the entire UE context.

7. A method performed by a base station, comprising: Upon receiving an RRC recovery request message from a user equipment (UE), a UE context request message is sent to the last serving base station. The UE context request message includes small data transmission SDT indication information and / or SDT auxiliary information. as well as If the UE is configured to receive MBS multicast in RRC inactive state, a partial UE context transmission message is received from the last served base station. The partial UE context transmission message includes information indicating that the UE is configured to receive MBS multicast in RRC inactive state.

8. A base station, comprising: processor; as well as Memory, which stores instructions The instructions, when executed by the processor, perform the method of claim 6 or 7.

Images