Method performed by user equipment, and user equipment
By receiving the multicastConfigInactive and inactiveMCCH-Config fields from the base station's RRC messages, the user equipment correctly configures the MBS multicast session in the RRC inactive state, solving the problem that the user equipment cannot receive the MBS multicast session in the RRC inactive state, ensuring the correct setting of the resumeCause field, and improving the system's flexibility and efficiency.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-09-29
- Publication Date
- 2026-04-02
AI Technical Summary
In the prior art, user equipment cannot receive MBS multicast sessions when RRC is inactive, and the MBS multicast sessions received are not configured as RRC_INACTIVE in the paging message, which leads to improper setting of the resumeCause field in the RRC connection recovery request message, making it impossible to determine the specific cell configured for multicast MCCH/MTCH.
A method for a user equipment is provided, which determines whether to configure receiving MBS multicast sessions in the RRC_INACTIVE state by receiving the multicastConfigInactive field and the inactiveMCCH-Config field in the RRC message of the base station, and starts the RRC connection recovery process under certain conditions, setting the resumeCause field to mt-SDT to ensure correct multicast configuration.
This enables user equipment to correctly receive MBS multicast sessions in the RRC inactive state, avoids incorrect resumeCause field settings, ensures that user equipment can receive MBS multicast session configuration in the appropriate cell, and improves the system's flexibility and efficiency.
Smart Images

Figure CN2025125241_02042026_PF_FP_ABST
Abstract
Description
Method performed by user equipment and user equipment TECHNICAL FIELD
[0001] The present application relates to the technical field of wireless communication, and more particularly, to a method performed by user equipment and user equipment. BACKGROUND
[0002] A study item SI on improvements on 5G multicast broadcast service architecture (see SP-190625 for details) has been approved. One of the objectives of this SI (referred to as objective A) is to support generic MBS services in 5GS, and use cases that can benefit from this feature include (but are not limited to) public safety, V2X applications, transparent IPv4 / IPv6 multicast transport, IPTV, wireless software delivery, group communications, and Internet of Things applications, etc. Accordingly, at the 3rd Generation Partnership Project (3GPP) RAN #86 plenary, a work item on NR Multicast and Broadcast Service (see Non-Patent Literature: RP-193248: New WID: NR Multicast and Broadcast Service) was proposed and approved. This work item aims to provide support for objective A in the RAN. The objectives of this work item have been basically achieved, and the detailed description of the related solutions can be found in the 3GPP Release 17 technical documents, such as TS 38.300-h30, TS 38.331-h30, TS 38.321-h30, etc. At the 3GPP RAN #94 plenary, a work item named Enhancements of NR Multicast and Broadcast Services was approved (see Non-Patent Literature: RP-213568: New WID: Enhancements of NR Multicast and Broadcast Services). This work item aims to further enhance the MBS broadcast multicast of Release 17 in Release 18, and one of its objectives is to support user equipment receiving MBS multicast service / session in RRC inactive state.
[0003] The present application discusses related issues involved in supporting user equipment receiving MBS multicast service / session in RRC inactive state by the RAN. SUMMARY
[0004] To solve the above problems, the present application provides a method performed by user equipment and user equipment.
[0005] According to a first aspect of the present application, there is provided a method performed by a user equipment (UE), comprising: step 1, the UE receives an RRC message from a base station, the RRC message containing a multicastConfigInactive field indicating whether the UE is configured to receive MBS multicast in RC_INACTIVE, the multicastConfigInactive field containing an inactiveMCCH-Config field indicating the multicast MCCH / MTCH configuration for MBS multicast reception in RRC_INACTIVE in a cell where the UE receives a multicast session in RRC_CONNECTED; and step 2, if at least one multicast PTM configuration of a multicast session that is not indicated to stop detecting G-RNTI is provided in the RRC message, and / or the cell selected by the UE is a cell where the UE receives a multicast session in RRC_CONNECTED, the UE performs at least one of the following operations 1-2:
[0006] Operation 1: apply the multicast PTM configuration.
[0007] Operation 2: if the multicast MCCH is present, detect the multicast MCCH-RNTI.
[0008] According to a second aspect of the present application, there is provided another method performed by a user equipment (UE), comprising: step 1, the UE in RRC_INACTIVE receives a paging message from a base station; and step 2, if condition A and / or condition B and / or condition C and / or condition D are met, start an RRC connection resume procedure and set the resumeCause field carried by the RRC resume request message to "mt-SDT", wherein,
[0009] Condition A: the ue-Identity contained in a certain PagingRecord field contained in the paging message matches the fullI-RNTI stored by the UE;
[0010] Condition B: the UE is not configured by upper layers with access identity 1 and / or the UE is not configured by upper layers with access identity 2 and / or the UE is not configured by upper layers with any of access identities 11 to 15;
[0011] Condition C: the paging message contains an mt-SDT indication and meets the condition for starting SDT in response to starting an RRC resume procedure for RAN paging;
[0012] Condition D: the paging message contains a pagingGroupList field and the UE is configured to receive MBS multicast in RRC_INACTIVE state and the paging message contains an inactiveReceptionAllowed field for all MBS sessions the UE has joined indicated by TMGIs contained in the pagingGroupList field and all MBS sessions the UE has joined indicated by TMGIs contained in the pagingGroupList field are configured to be received in RRC_INACTIVE.
[0013] Further, according to a third aspect of the present application, there is provided a user equipment comprising: a processor; and a memory storing instructions which, when executed by the processor, perform the method described above.
[0014] Effects of the Invention
[0015] According to the present application, a method of setting the value of the resumeCause field of the RRC connection resume request message to mt_SDT in the SDT procedure when the MBS multicast session indicated by the TMGI contained in the received paging message is not configured to be received in RRC_INACTIVE, a method of avoiding the UE from being unable to determine the multicast MCCH / MTCH configuration for MBS multicast reception in RRC_INACTIVE state carried in the RRC release message is for which cell and a corresponding user equipment can be provided. BRIEF DESCRIPTION OF DRAWINGS
[0016] The above and other features of the present application will become more apparent by describing in detail the embodiments thereof with reference to the attached drawings, in which:
[0017] FIG. 1 is a flowchart schematically showing a method performed by a user equipment UE according to an embodiment of the present application.
[0018] FIG. 2 is a flowchart schematically showing a method performed by a user equipment UE according to another embodiment of the present application.
[0019] FIG. 3 is a block diagram showing a brief structure of a user equipment according to the present application. DETAILED DESCRIPTION
[0020] The present application will be described in detail by making reference to the attached drawings and specific embodiments. It should be noted that the present application should not be limited to the specific embodiments described below. In addition, detailed descriptions of well-known technology which is not directly related to the present application are omitted in order to prevent obscuring the understanding of the present application.
[0021] Some terms related to the present application are described below, and the specific meanings of the terms can be referred to the latest relevant documents of 3GPP, such as TS 38.300-i30, TS 38.321-i30, TS 38.323-i30, TS 38.331-i30, and the like. In addition, embodiments of the present application are described by taking broadcast / multicast services as an example, but 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, 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, radio access network.
[0028] NR: New RAT, new radio access technology.
[0029] MBS: Multicast / Broadcast Services, multicast / broadcast services. Multicast can also be referred to as groupcast.
[0030] MCCH: MBS Control Channel, MBS control channel.
[0031] MTCH: MBS Traffic Channel, MBS transmission channel.
[0032] AS: Access Stratum, access layer or access stratum.
[0033] NAS: Non Access Stratum, non-access layer or non-access stratum.
[0034] RB: Radio Bearer, radio bearer. DRB is a data radio bearer, and SRB is a signaling radio bearer.
[0035] MRB: MBS radio bearer, i.e. a radio bearer that is configured for MBS delivery. MRB is divided into multicast MRB and broadcast MRB, multicast MRB is a radio bearer that is configured for MBS multicast delivery, broadcast MRB is a radio bearer that is configured for MBS broadcast delivery.
[0036] TMGI: Temporary Mobile Group Identity, used to identify an MBS session. The present disclosure is that TMGI is used to identify MBS multicast session according to embodiments.
[0037] RNTI: Radio Network Temporary Identifier, used to scramble the scheduling and transmission of PTM for one or more MBS multicast services.
[0038] 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). UE uses G-RNTI to receive PTM transmission. For example, the base station uses group common PDCCH with G-RNTI to schedule the same group common PDSCH with G-RNTI.
[0039] PTP: Point to Point, a delivery mode of MBS service. In PTP delivery mode, the RAN node individually delivers separate copies of MBS data packets to each UE (gNB individually delivers separate copies of MBS data packets to each UEs independently). For example, the base station uses UE-specific PDCCH scrambled with UE-specific RNTI to schedule UE-specific PDSCH scrambled with the same UE-specific RNTI.
[0040] G-RNTI: Group RNTI, used to scramble the scheduling and transmission of PTM for one or more MBS multicast services.
[0041] Multicast MCCH-RNTI: Multicast MBS Control Channel RNTI, used for dynamic scheduling of MCCH signaling and MCCH change notification for MBS multicast in RRC_INACTIVE state. In the current version, the value corresponding to the Multicast MCCH-RNTI is FFFB (hexadecimal).
[0042] 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 where the RRC resume procedure is performed 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 RRCReject message is used to reject an RRC connection establishment or RRC connection resume. 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 used, the full I-RNTI and RRCResumeRequest1 message when the field is included in the SIB1, and 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.
[0043] In the present application, the network, base station and RAN can be used interchangeably unless otherwise specified, 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, such as a 6G network.
[0044] Currently, the NR MBS service includes MBS broadcast (also referred to as MBS broadcast session or broadcast MBS or MBS broadcast service) and MBS multicast (also referred to as MBS multicast session or multicast MBS 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). In 3GPP Release 17, the UE needs to establish an RRC connection with the base station before receiving the MBS multicast service (i.e., MBS multicast session), and then the base station configures the UE to receive the MBS multicast service resources through dedicated RRC signaling (also referred to as RRC message, such as RRC reconfiguration message), and the MBS radio bearer (MRB) for receiving the MBS multicast service is also configured for the UE by the base station through dedicated RRC signaling, only the UE in RRC connected state and configured with MRB can receive the corresponding MBS multicast service.
[0045] 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).
[0046] 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. multicast MCCH and / or multicast 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 (e.g. mrb-ListMulticast indicating the list of multicast MRB to which the related MBS multicast session is mapped) and / or pdschConfigIndex indicating the index of PDSCH configuration entry in pdschConfigList and / or the configuration information of domain of MBS multicast session such as TMGI and its corresponding G-RNTI and / or DRX, etc. Wherein, the pdschConfigList domain contains the list of PDSCH parameters which can be configured per G-RNTI. Only one entry entity is allowed to be configured if included in SIB20 or SIB24. The PTM configuration of MBS multicast session in RRC_INACTIVE reception is contained in MBS multicast configuration MBSMulticastConfiguration message. 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.
[0047] In the embodiments of the present disclosure, the MBSMulticastConfiguration message contains the control information applicable for MBS multicast services transmitted via multicast MRBs for RRC_INACTIVE UEs.
[0048] For the MBS multicast session received in RRC_INACTIVE state, the network can indicate the UE that the MBS multicast is activated or data transmission is resumed or ongoing or is about to start by the Multicast MCCH or RRC signaling (e.g. RRC release message) or by paging message. For example, the TMGI of the MBS multicast session contained in the paging message indicates that the MBS multicast session is activated or data transmission is resumed or ongoing or is about to start, and the stopMonitoringRNTI field of the MBS multicast session not contained in the Multicast MCCH or RRC release message indicates that the MBS multicast session is activated or data transmission is resumed or ongoing or is about to start. In the present disclosure, the stopMonitoringRNTI field is used to indicate the UE to stop monitoring the G-RNTI corresponding to the multicast session. The network associates a stopMonitoringRNTI field for each MBS multicast session in the Multicast MCCH message (i.e. the MBSMulticastConfiguration message transmitted on the Multicast MCCH) to explicitly indicate the UE to stop monitoring the G-RNTI corresponding to the MBS multicast session (i.e. to indicate that the MBS multicast session is deactivated or data transmission is stopped). The UE stops receiving the MBS multicast session after receiving the indication. The UE stopping receiving the MBS multicast session can be the UE stopping monitoring the G-RNTI corresponding to the MBS multicast session.
[0049] Each MBS multicast session is identified by a TMGI and is associated with a G-RNTI. A UE receives an MBS multicast session by detecting the G-RNTI associated with the MBS multicast session.
[0050] The network can configure the PTM configuration information (e.g., the PTM configuration information is contained in the MBSMulticastConfiguration message) of an MBS multicast session received in RRC_INACTIVE state for a UE through multicast MCCH and / or dedicated RRC signaling (e.g., RRC release message). The MBS multicast configuration message MBSMulticastConfiguration can be transmitted on multicast MCCH (in this case, the MBSMulticastConfiguration message can be referred to as a 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 an MBS multicast session received in RRC_INACTIVE state for a UE, the network can contain the MBSMulticastConfiguration message in the RRC release message sent to the UE. Specifically, the MBSMulticastConfiguration message can be contained in the inactivePTM-Config field of the MulticastConfigInactive field in the suspendConfig field in the RRC release message. The suspendConfig field indicates the configuration of the RRC_INACTIVE state.
[0051] In the existing system, it can be indicated in the MBSMulticastConfiguration message whether to stop monitoring the G-RNTI corresponding to the MBS multicast session. Specifically, for an MBS multicast session whose TMGI is contained in the MBSMulticastConfiguration message, if the MBSMulticastConfiguration message further contains a stopMonitoringRNTI field of the MBS multicast session, it indicates that the UE has received an indication to stop monitoring the G-RNTI of the MBS multicast session (i.e., stop monitoring the G-RNTI of the MBS multicast session). On the contrary (i.e., the MBSMulticastConfiguration message does not contain the stopMonitoringRNTI field of the MBS multicast session), it indicates that the UE has not received an indication to stop monitoring the G-RNTI of the MBS multicast session. By associating / configuring a stopMonitoringRNTI field for each MBS multicast session, it is indicated to stop monitoring the G-RNTI of the MBS multicast session. If an MBS multicast session is not associated / configured with a corresponding stopMonitoringRNTI field, it indicates that the MBS multicast session is not indicated to stop monitoring the G-RNTI.
[0052] The network can also achieve the indication of the activation or transmission of the MBS multicast session in progress or imminent by including the TMGI of the MBS multicast session in the paging message. If the UE receives a paging message containing the TMGI of an MBS multicast session that the UE has joined, the paging message further contains the inactiveReceptionAllowed field corresponding to the TMGI, and the UE is configured to receive the MBS multicast session indicated by the TMGI in RRC_INACTIVE, it indicates that the UE receives an indication to start monitoring the G-RNTI of the MBS multicast session in RRC_INACTIVE state. The inactiveReceptionAllowed field indicates whether the UE with a valid PTM configuration for the MBS multicast session indicated by the TMGI contained in the PagingGroupList field of the paging message stays in RRC_INACTIVE to receive the MBS multicast session (Indicates whether the UE with a valid PTM configuration for a TMGI in the PagingGroupList stays in RRC_INACTIVE to receive the corresponding MBS multicast session).
[0053] It is noted that the UE acquiring the multicast MCCH means that the UE acquires the MBS MulticastConfiguration message from the multicast MCCH. For an MBS multicast session configured for RRC_INACTIVE reception, if the TMGI of the MBS multicast session is contained in a paging message and the paging message further contains an inactiveReceptionAllowed field corresponding to the TMGI, the UE can receive the MBS multicast session in RRC_INACTIVE.
[0054] When the UE receives an RRC release message from a base station, if a multicastConfigInactive field is contained in the received RRC release message, it indicates that the UE is configured to receive MBS multicast in RRC_INACTIVE. If the multicastConfigInactive field is not contained in the RRC release message, it indicates that the UE is not configured to receive MBS multicast in RRC_INACTIVE.
[0055] As not specifically stated, in this disclosure, the multicastConfigInactive field indicates whether the UE is configured to receive MBS multicast in RC_INACTIVE. The multicastConfigInactive field can contain two fields, namely the inactivePTM-Config field and the inactiveMCCH-Config field. The inactivePTM-Config field carries the MBSMulticastConfiguration message, which indicates the multicast session(s) that can be received in RRC_INACTIVE and optionally the corresponding PTM configuration for the cell where the multicast session(s) was received in RRC_CONNECTED. If the RRC release message contains the multicastConfigInactive field but not the inactivePTM-Config field, the UE considers that all joined multicast sessions can be received in RRC_INACTIVE or all joined multicast sessions are configured to be received in RRC_INACTIVE. The inactiveMCCH-Config field carries the system information SIB24.
[0056] In the current protocol TS 38.331-i30, the inactiveMCCH-Config field is used to indicate the multicast MCCH / MTCH configuration for MBS multicast reception in RRC_INACTIVE in the serving cell. But for the UE in RRC_CONNECTED, the UE can be configured and activated multiple cells, which are all called serving cells, then the inactiveMCCH-Config field contained in the RRC release message is for which cell is a problem to be solved; for the UE in RRC_INACTIVE, the UE can perform cell selection or reselection, then the inactiveMCCH-Config field contained in the RRC release message is for which cell is a problem to be solved.
[0057] Further, upon receiving an RRC release message from a base station, if the RRC release message contains a multicastConfigInactive field and at least one multicast PTM configuration for a multicast session that is not indicated to stop monitoring G-RNTI is provided in the RRC release message, the UE applies the multicast PTM configuration and monitors for multicast MCCH-RNTI if a multicast MCCH occurs. However, if the RRC release message contains the multicastConfigInactive field, but the inactivePTM-Config field is not contained in the multicastConfigInactive field (i.e. no multicast PTM configuration for any multicast session is provided in the RRC release message). When the inactivePTM-Config field is not contained in the multicastConfigInactive field, the UE considers that all joined MBS multicast sessions are configured to be received in RRC_INACTIVE, and the UE does not receive the stopMonitoringRNTI field for the MBS multicast sessions (the stopMonitoringRNTI field is contained in the inactivePTM-Config field, and since the UE does not receive the inactivePTM-Config field, it does not receive the stopMonitoringRNTI field either). Whether or how the UE receives MBS multicast sessions after entering RRC_INACTIVE upon receiving an RRC release message containing the multicastConfigInactive field but not containing the inactivePTM-Config field is a problem to be solved.
[0058] To this end, in order to solve at least part of the above problems, the present disclosure provides corresponding embodiments. The following will enumerate specific embodiments to illustrate the processing method of the present disclosure. In addition, the following enumerated embodiments are only examples and do not limit the present disclosure.
[0059] The following will enumerate specific embodiments to illustrate the processing method of the present disclosure. In addition, the following enumerated embodiments are only examples and do not limit the present disclosure.
[0060] FIG. 1 is a flowchart schematically showing a method performed by a user equipment (UE) according to an embodiment of the present disclosure. As shown in FIG. 1, the embodiment can include the following steps:
[0061] At step 101, the UE receives an RRC message from the base station, which contains a multicastConfigInactive field (i.e. the multicastConfigInactive field contained in the RRC message is set to "setup"). The multicastConfigInactive field contains an inactiveMCCH-Config field and / or an inactivePTM-Config field. The inactiveMCCH-Config field has the following one of (1)-(2):
[0062] (1) is used to indicate the multicast MCCH / MTCH configuration for MBS multicast reception in RRC_INACTIVE in the serving cell. Optionally, the serving cell is the cell where the UE receives the MBS session in RRC_CONNECTED, which can be the same or different from the MBS multicast session indicated in the inactivePTM-Config field. In other words, the UE enters RRC_INACTIVE and performs cell selection due to receiving the RRC message containing the suspendConfig field, and if the selected cell is the cell where the UE receives the MBS multicast session in RRC_CONNECTED, the UE applies the multicast MCCH / MTCH configuration contained in the inactiveMCCH-Config field.
[0063] (2) is used to indicate the multicast MCCH / MTCH configuration for MBS multicast reception in RRC_INACTIVE in the cell where the multicast session(s) was received in RRC_CONNECTED.
[0064] Preferably, the RRC message is an RRC release message.
[0065] At step 103, if the RRC message provides at least one multicast PTM configuration for a multicast session that is not indicated to stop detecting G-RNTI (i.e. the inactivePTM-Config field is contained in the paging message), and / or the cell selected by the UE is the cell where the UE receives the multicast session in RRC_CONNECTED, at least one of the following operations 1-2 is performed:
[0066] Operation 1: apply the multicast PTM configuration.
[0067] Operation 2: if a multicast MCCH exists, detect the multicast MCCH-RNTI. The multicast MCCH can be the multicast MCCH determined by the UE from the SIB24 of the selected cell or the multicast MCCH determined by the inactiveMCCH-Config field contained in the RRC message. It can be specified that if the inactiveMCCH-Config field is contained in the RRC message, the multicast MCCH is the multicast MCCH determined according to the inactiveMCCH-Config field; if the inactiveMCCH-Config field is not contained in the RRC message, the multicast MCCH is the multicast MCCH determined by the UE from the SIB24 of the selected cell.
[0068] Optionally, embodiment 1 further comprises step 105. It should be noted that for steps 103 and 105, the UE can also only perform one of the steps, for example, only perform steps 101 and 103 or only perform steps 101 and 105.
[0069] In step 105, if the RRC message does not contain the multicast PTM configuration of at least one multicast session that is not indicated to stop detecting G-RNTI (or the inactivePTM-Config field is not contained in the paging message), and / or the selected cell of the UE is the cell in which the UE receives the multicast session in RRC_CONNECTED, the multicast MCCH / MTCH configuration is applied (i.e. the multicast MCCH / MTCH configuration contained in the inactiveMCCH-Config field is applied).
[0070] For a UE configured to receive MBS multicast in RRC_INACTIVE state, when the UE is in RRC_INACTIVE and receives a paging message from a base station, if the paging message contains an indication identity mt-SDT indicating mobile terminated (MT) small data transmission (SDT) and the conditions for initiating SDT for a resume procedure initiated in response to RAN paging are fulfilled, the UE will initiate an RRC connection resume procedure. If the resumeCause field carried by the RRC resume request message sent by the UE in the RRC connection resume procedure is set to mt-SDT (this mt-SDT indicates that the UE initiates the RRC connection resume procedure for SDT, and the mt-SDT contained in the resumeCause field of the RRC resume request message is referred to as the second mt-SDT), the UE can not be instructed by the base station to enter RRC_CONNECTED. The existing system (TS 38.331-i30) provides that, for all TMGIs of MBS multicast sessions that the UE has joined and that are contained in the received paging message, if the inactiveReceptionAllowed field corresponding to the TMGI is also contained in the paging message, the resumeCause field carried by the RRC resume request message is set to mt-SDT. However, if there is at least one MBS multicast session that is not configured to be received in RRC_INACTIVE among the MBS multicast sessions that the UE has joined and that are indicated by the TMGIs contained in the paging message, the UE needs to enter RRC_CONNECTED state to receive the MBS sessions when the paging message is received, but since the resumeCause field carried by the RRC resume request message is set to mt-SDT, the network can not instruct the UE to enter RRC_CONNECTED when the RRC resume request message is received, which will result in the UE being unable to receive the MBS sessions. The following embodiments are provided to solve this problem.
[0071] It should be noted that the mt-SDT contained in the paging message in the present disclosure is a field, and its value can be "true". The mt-SDT contained in the RRC resume request message is a value of the resumeCause field contained in the RRC resume request message, i.e., the value of the resumeCause field is "mt-SDT".
[0072] Figure 2 is a flowchart schematically representing a method performed by a user equipment, UE, according to another embodiment of the present application. As shown in Figure 2, the embodiment can comprise the following steps:
[0073] At step 201, the UE in RRC_INACTIVE state receives a paging message from a base station.
[0074] At step 203, if the following condition A and / or condition B and / or condition C are met, further determine whether condition D is met, and in case that condition D is met, initiate the RRC connection resume procedure and set the resumeCause field carried by the RRC resume request message to a first value, preferably, the first value is “mt-SDT”; alternatively, otherwise (i.e. the following condition A and / or condition B and / or condition C are met, but condition D is not met), initiate the RRC connection resume procedure and set the resumeCause field carried by the RRC resume request message (i.e. the RRC resume request message sent in the RRC connection resume procedure) to a second value, the second value is different from the first value, preferably, the second value is “mt-Access”. Wherein,
[0075] Condition A: the ue-Identity contained in the PagingRecord field contained in the paging message is the same as or matches the fullI-RNTI stored by the UE (i.e. the ue-Identity contained in a PagingRecord field contained in the paging message is the same as or matches the fullI-RNTI stored by the UE).
[0076] Condition B: the UE is not configured by upper layers with Access Identity 1 and / or the UE is not configured by upper layers with Access Identity 2 and / or the UE is not configured by upper layers with any of Access Identity 11 to Access Identity 15. The meaning of each access identity can be found in 3GPP TS 24.501-i80, which will not be repeated here.
[0077] Condition C: the mt-SDT indication (i.e. the mt-SDT indication for the UE) is contained in the paging message and the conditions for initiating SDT in response to RAN paging for initiating the RRC resume procedure are met. The conditions for initiating SDT in response to RAN paging for initiating the RRC resume procedure are defined in section 5.3.13.1b of TS 38.331-i30, which will not be repeated here.
[0078] Condition D: the paging message does not contain the pagingGroupList field, or the paging message contains the pagingGroupList field but the UE is not joined in any MBS session indicated by the TMGIs contained in the pagingGroupList field, or the paging message contains the pagingGroupList field and the UE is configured to receive MBS multicast in RRC_INACTIVE state and the inactiveReceptionAllowed field for all MBS multicast sessions indicated by the TMGIs contained in the pagingGroupList field that the UE has joined is contained in the paging message and all MBS multicast sessions indicated by the TMGIs that the UE has joined are configured to be received in RRC_INACTIVE.
[0079] It should be noted that in Condition D, the condition that the UE is configured to receive MBS multicast in RRC_INACTIVE state is optional, because if the UE is configured to receive one or more MBS multicast sessions in RRC_INACTIVE state, it means that the UE must be configured to receive MBS multicast in RRC_INACTIVE state.
[0080] As a variant of Embodiment 2, keeping other steps and conditions unchanged, the “inactiveReceptionAllowed field for all MBS multicast sessions indicated by the TMGIs that the UE has joined is contained in the paging message and all MBS multicast sessions indicated by the TMGIs that the UE has joined are configured to be received in RRC_INACTIVE” in Condition D in Embodiment 2 is replaced by “inactiveReceptionAllowed field for all MBS multicast sessions indicated by the TMGIs that the UE has joined and configured to be received in RRC_INACTIVE is contained in the paging message” or by “for all MBS multicast sessions indicated by the TMGIs that the UE has joined, the MBS multicast sessions are configured to be received in RRC_INACTIVE and the inactiveReceptionAllowed field for the MBS multicast sessions is contained in the paging message” or by “inactiveReceptionAllowed field for all MBS multicast sessions indicated by the TMGIs that the UE has joined is contained in the paging message and the MBS multicast sessions (i.e. all MBS multicast sessions indicated by the TMGIs contained in the pagingGroupList field that the UE has joined and contained in the paging message) are configured to be received in RRC_INACTIVE”, the resulting embodiment is also within the protection scope of the present disclosure.
[0081] As another variation of Embodiment 2, embodiments obtained by keeping other steps and conditions unchanged while replacing the condition D not met in Embodiment 2 with the condition E are also within the protection scope of the present disclosure.
[0082] Condition E: the paging message contains the pagingGroupList field and the UE has joined at least one MBS session indicated by the TMGI contained in the pagingGroupList field, but the UE is not configured to receive MBS multicast in RRC_INACTIVE state or although the UE is configured to receive MBS multicast in RRC_INACTIVE state, the paging message does not contain the inactiveReceptionAllowed field of at least one MBS multicast session indicated by the TMGI contained in the pagingGroupList field to which the UE has joined or although the UE is configured to receive MBS multicast in RRC_INACTIVE state, there is at least one MBS multicast session not configured to receive in RRC_INACTIVE among all MBS multicast sessions indicated by the TMGI contained in the pagingGroupList field to which the UE has joined.
[0083] As not specifically stated, in the embodiments of the present disclosure, the inactiveReceptionAllowed field indicates whether the UE with a valid PTM configuration for a TMGI in the PagingGroupList stays in RRC_INACTIVE to receive the corresponding MBS multicast session (Indicates whether the UE with a valid PTM configuration for a TMGI in the PagingGroupList stays in RRC_INACTIVE to receive the corresponding MBS multicast session). The pagingGroupList field contains one or more TMGIs (i.e., TMGI list), and the PagingRecordList field contains one or more PagingRecord fields (i.e., PagingRecord list). The PagingRecord field contains the ue-Identity field, and optionally, the accessType field for indicating whether the paging message is initiated due to a PDU session from a non-3GPP access. The ue-Identity field indicates the value of ng-5G-S-TMSI or fullI-RNTI. The ng-5G-S-TMSI contains the 5G S-TMSI, which is a temporary UE identity provided by the 5GC (5G core network, i.e., upper layer) to uniquely identify the UE in a tracking area. The fullI-RNTI indicates the value of I-RNTI-Value to identify the suspended UE context of the UE in the RRC inactive state. The resumeCause field is an ENUMERATED type (ENUMERATED) to provide the resume cause for the RRC connection resume request as provided by the upper layers or RRC.
[0084] In the present disclosure, the inactiveReceptionAllowed field in the paging message for all MBS sessions that the UE has joined and that the TMGI indicated in the pagingGroupList field in the paging message indicates refers to that for any MBS multicast session that the UE has joined and that the TMGI indicated in the pagingGroupList field in the paging message contains, the inactiveReceptionAllowed field of the MBS multicast session is contained in the paging message.
[0085] As not particularly specified, in the present disclosure, the terms RRC connection resume procedure, RRC resume procedure, resume procedure, connection resume procedure are used interchangeably; MBS multicast, MBS multicast session, multicast service, multicast session are used interchangeably.
[0086] As not particularly specified, in the present disclosure, the embodiments performed by the UE or the base station can be performed by the RRC entity in the UE or the base station or at the RRC layer, and the upper layer in the present disclosure is the upper layer (e.g., the NAS layer) of the RRC layer.
[0087] Fig. 3 is a schematic block diagram illustrating a user equipment according to the present application.
[0088] As shown in Fig. 3, the user equipment 30 at least includes a processor 301 and a memory 302. The processor 301 may, for example, include a microprocessor, a microcontroller, an embedded processor, etc. The memory 302 may, for example, include a volatile memory (such as a random access memory, RAM), a hard disk drive (HDD), a non-volatile memory (such as a flash memory), or other memory systems, etc. The memory 302 stores program instructions. When the instructions are executed by the processor 301, one or several steps in the processing method of the UE of the present disclosure can be performed.
[0089] In the embodiments of 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. 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” are used interchangeably, and the embodiments obtained are also within the scope of the present disclosure. As not particularly specified, the same terms or domains appearing in different embodiments of the present disclosure have the same meanings.
[0090] In the embodiments of the present disclosure, in the case where a plurality of operations are included, the embodiments of the present disclosure exemplarily list the execution order of each operation, and the embodiments obtained by changing the execution order of each operation are also within the scope of protection of the present disclosure. In addition, in the case where a plurality of judgment conditions are included, the embodiments obtained by changing the execution order of the judgment conditions are also within the scope of protection of the present disclosure.
[0091] 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 a central processing unit (CPU). The programs or information processed by the programs can be temporarily stored in a volatile memory (such as a random access memory RAM), a hard disk drive (HDD), a non-volatile memory (such as a flash memory), or other memory systems.
[0092] The computer executable instructions or programs for realizing the functions of the embodiments of the present application can be recorded on a computer readable storage medium. The corresponding functions can be realized by making a computer system read the programs recorded on the recording medium and execute the 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 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 computer readable recording medium.
[0093] The various features or functional modules of the device used in the above embodiments can be realized or executed by a circuit (for example, a single-chip or multi-chip integrated circuit). The circuit designed to execute 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 of the above devices. The general purpose processor can be a microprocessor, or any existing processor, controller, microcontroller, or state machine. The above circuit can be a digital circuit, or an analog circuit. In the case where new integrated circuit technologies appear as a result of the progress of semiconductor technologies, one or more embodiments of the present application can also be realized using these new integrated circuit technologies.
[0094] In addition, the present application is not limited to the above 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 household appliances.
[0095] 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 without departing 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 having the same effect described in the above-described embodiments can be substituted for each other.
Claims
1.A user equipment (UE) comprising a processor configured to: receive a RRC message containing a parameter inactiveMCCH-Config, apply a multicast point-to-multipoint (PTM) configuration in the RRC message if the RRC message contains at least one multicast PTM configuration not indicated to stop monitoring a corresponding G-RNTI of a multicast session and a cell selected by the UE is the same as a cell in which the UE receives the multicast session in RRC_CONNECTED state, and the parameter inactiveMCCH-Config indicates a configuration of a multicast MCCH / MTCH of the MBS multicast session in RRC_INACTIVE reception on a cell in which the MBS multicast session is received in RRC_CONNECTED state. 2.The UE of claim 1, further comprising: receive a paging message, start a RRC connection resume procedure and set a resumeCause to mt-SDT if a ue-Identity contained in the paging message matches a full I-RNTI stored by the UE and the UE is not configured by a higher layer to access an access identity 1 or an access identity 2 or any one of access identities 11 to 15, and if a mt-SDT indication and a condition to start a SDT for a resumed procedure started in response to a RAN paging are satisfied in the paging message, and the paging message contains a pagingGroupList containing TMGIs indicating MBS sessions joined by the UE are all configured to be received in the RRC_INACTIVE state and the paging message contains an inactiveReceptionAllowed of the MBS sessions indicating whether the UE with valid PTM configuration of the MBS multicast session indicated by the TMGI contained in the PagingGroupList field of the paging message stays to receive the MBS multicast session in the RRC_INACTIVE state. 3.The UE of claim 1, wherein the parameter inactiveMCCH-Config is contained in a system information block (SIB) or a dedicated RRC message. wherein
Citation Information
Patent Citations
Method and device for sending and receiving non-activated multicast service
CN115996485A
Multicast session indication method and device
CN118175667A
Drilling bit and low noise rock drill comprising the drilling bit
KR102719479B1