Communication method, user equipment and network node

Abstract

A communication method used in a mobile communication system for providing multicast broadcast service (MBS) includes: a user equipment (UE) in an RRC inactive state initiating an RRC connection recovery process with respect to a network node based on the fact that the reception quality during multicast reception in the UE has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node; and the UE sending an RRC recovery request message to the network node including information elements related to the reason for RRC recovery. The information elements are first information indicating RRC recovery related to multicast reception, second information indicating Mobile Termination (MT) access, or third information indicating Multimedia Preferred Access (MPS) preferred access.

Description

Technical Field

[0001] This disclosure relates to a communication method, user equipment, and network node used in a mobile communication system. Background Technology

[0002] The 3rd Generation Partnership Project (3GPP) defines the technical specifications for New Radio (NR) as a fifth-generation (5G) radio access technology. Compared to Long Term Evolution (LTE) as a fourth-generation (4G) radio access technology, NR offers features such as high speed, high capacity, high reliability, and low latency. 3GPP has also defined the technical specifications for 5G / NR multicast / broadcast services (MBS).

[0003] In 3GPP Release 17, MBS multicast reception (i.e., multicast reception) could only be supported by user equipment in a Radio Resource Control (RRC) connected state (see, for example, Non-Patent Document 1). On the other hand, in 3GPP Release 18, the technical specifications were planned to be extended so that user equipment in an RRC inactive state could perform multicast reception.

[0004] Reference List

[0005] Non-patent literature

[0006] Non-patent document 1: 3GPP technical specification: TS 38.300 V17.5.0 Summary of the Invention

[0007] The communication method according to the first aspect is a communication method used in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising: initiating an RRC connection restoration process for a network node by a user equipment (UE) in a Radio Resource Control (RRC) inactive state participating in a multicast session based on a reception quality degradation to a threshold; and sending an RRC restoration request message to the network node by the UE including information elements related to the reason for the RRC restoration. The information elements are information indicating Mobile Termination (MT) access or information indicating Multimedia Priority Access (MPS) priority access.

[0008] The communication method according to the second aspect is a communication method used in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising: a user equipment (UE) in an RRC inactive state initiating an RRC connection recovery process with respect to a network node based on the fact that the reception quality during multicast reception in the UE has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node; and the UE sending an RRC recovery request message to the network node including information elements related to the reason for RRC recovery. The information elements are first information indicating RRC recovery related to multicast reception, second information indicating Mobile Termination (MT) access, or third information indicating Multimedia Preferred Access (MPS) preferred access.

[0009] According to a third aspect, a user equipment (UE) for use in a mobile communication system for providing multicast broadcast service (MBS) includes: a controller configured to initiate an RRC connection recovery process with respect to a network node in an RRC inactive state based on the fact that the reception quality during multicast reception in the UE has deteriorated and / or the UE needs to obtain multicast reception configuration from a network node; and a transmitter configured to send an RRC recovery request message to the network node including information elements related to the cause of the RRC recovery. The information elements are first information indicating RRC recovery related to multicast reception, second information indicating Mobile Termination (MT) access, or third information indicating Multimedia Preferred Access (MPS) preferred access.

[0010] According to the fourth aspect, a network node is a network node used in a mobile communication system for providing multicast broadcast service (MBS), the network node comprising: a receiver configured to receive, based on the fact that the reception quality during multicast reception in a user equipment (UE) in an RRC inactive state has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node, an RRC recovery request message from the UE including information elements related to the cause of RRC recovery. The information elements are first information indicating RRC recovery related to multicast reception, second information indicating Mobile Termination (MT) access, or third information indicating Multimedia Preferred Access (MPS) preferred access. Attached Figure Description

[0011] Figure 1 This is a diagram illustrating a configuration example of a mobile communication system according to an embodiment.

[0012] Figure 2 This is a diagram illustrating a configuration example of a user equipment (UE) according to an embodiment.

[0013] Figure 3 This is a diagram illustrating a configuration example of a gNB (network node) according to an embodiment.

[0014] Figure 4 This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.

[0015] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0016] Figure 6 This is a diagram illustrating an overview of the operation of the UE according to an embodiment.

[0017] Figure 7 This is a diagram illustrating an example of a first operating mode of a mobile communication system according to an embodiment.

[0018] Figure 8 This is a diagram illustrating another example of a first operating mode of a mobile communication system according to an embodiment.

[0019] Figure 9 This is a diagram illustrating an example of a second operating mode of a mobile communication system according to an embodiment.

[0020] Figure 10 This is a diagram illustrating another example of a second operating mode of a mobile communication system according to an embodiment. Detailed Implementation

[0021] According to an embodiment, a mobile communication system is described herein with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.

[0022] (1) System configuration example

[0023] Figure 1 This is a diagram illustrating a configuration example of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard for a fifth-generation system (5GS). The following description uses 5GS as an example, but a Long Term Evolution (LTE) system can be applied at least partially to this mobile communication system. Alternatively, a sixth-generation (6G) system can be applied at least partially to this mobile communication system.

[0024] Mobile communication system 1 includes user equipment (UE) 100, a 5G radio access network (Next Generation Radio Access Network (NG-RAN)) 10, and a 5G core network (5GC) 20. In the following text, NG-RAN 10 may be simply referred to as RAN 10. 5GC 20 may be simply referred to as core network (CN) 20. RAN 10 and CN 20 configure network 5 of mobile communication system 1.

[0025] UE 100 is a mobile wireless communication device. UE 100 can be any device as long as it is used by a user. Examples of UE 100 include mobile phone terminals (including smartphones) or tablet terminals, laptop PCs, communication modules (including communication cards or chipsets), sensors or devices mounted on sensors, vehicles or devices mounted on vehicles (vehicle UE), and flying objects or devices mounted on flying objects (airborne UE).

[0026] NG-RAN 10 includes base stations 200 (referred to as gNBs in 5G systems) as a type of network node. gNBs 200 are interconnected via an Xn interface, which serves as an inter-base station interface. Each gNB 200 manages one or more cells. gNBs 200 perform wireless communication with UE 100, which has established a connection with a cell of the gNB 200. gNBs 200 have radio resource management (RRM) functions, functions for routing user data (hereinafter referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to represent the smallest unit of a wireless communication area. "Cell" is also used as a term to represent the functions or resources used to perform wireless communication with UE 100. A cell belongs to a carrier frequency (hereinafter referred to as a "frequency").

[0027] Note that a gNB can connect to the Evolved Packet Core (EPC) corresponding to the LTE core network. LTE base stations can also connect to the 5GC. LTE base stations and gNBs can connect via an inter-base station interface.

[0028] The 5GC 20 includes Access and Mobility Management Functions (AMF) and User Plane Functions (UPF) 300. The AMF performs various types of mobility control for the UE 100. The AMF manages the mobility of the UE 100 by communicating with it using Non-Access Stratum (NAS) signaling. The UPF controls data transmission. The AMF and UPF are connected to the gNB 200 via the NG interface, which serves as the interface between the base station and the core network.

[0029] Figure 2 This is a diagram illustrating a configuration example of a UE 100 (User Equipment) according to an embodiment. UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and transmitter 120 constitute a wireless communication device that performs wireless communication with the gNB 200.

[0030] Receiver 110 performs various reception functions under the control of controller 130. Receiver 110 includes an antenna and receiving equipment. The receiving equipment converts the radio signals or terahertz wave signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 130.

[0031] Transmitter 120 performs various transmissions under the control of controller 130. Transmitter 120 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 130 into a radio signal or a terahertz wave signal, and transmits the obtained signal through the antenna.

[0032] Controller 130 performs various control and processing operations within UE 100. This processing includes the processing of various layers, which will be described later. The operation of UE 100 described above and below can be under the control of controller 230. Controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for processing within the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0033] Figure 3 This diagram illustrates a configuration example of gNB 200 (network node) according to an embodiment. gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240. Transmitter 210 and receiver 220 constitute a wireless communication device for performing wireless communication with UE 100. Backhaul communicator 240 constitutes a network communicator for performing communication with CN 20.

[0034] Transmitter 210 performs various transmissions under the control of controller 230. Transmitter 210 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 230 into a radio signal or a terahertz wave signal, and transmits the obtained signal through the antenna.

[0035] Receiver 220 performs various types of reception under the control of controller 230. Receiver 220 includes an antenna and receiving equipment. The receiving equipment converts the radio signals or terahertz wave signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 230.

[0036] Controller 230 performs various types of control and processing within gNB 200. This processing includes the processing of the various layers described later. The operations of gNB 200 described above and below can also be performed under the control of controller 230. Controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for processing within the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0037] The backhaul communicator 240 is connected to an adjacent base station via the Xn interface, which serves as an inter-base station interface. The backhaul communicator 240 is connected to the AMF / UPF 300 via the NG interface, which is the interface between the base station and the core network. Note that the gNB 200 may include a central unit (CU) and a distributed unit (DU) (i.e., functions are divided), and these two units can be connected via the F1 interface, which serves as a fronthaul interface.

[0038] Figure 4 This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.

[0039] The user plane radio interface protocol includes the physical (PHY) layer, media access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, and service data adaptation protocol (SDAP) layer.

[0040] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE 100 and the PHY layer of gNB 200 via the physical channel. Note that the PHY layer of UE 100 receives downlink control information (DCI) transmitted from gNB 200 via the physical downlink control channel (PDCCH). Specifically, UE 100 performs blind decoding of the PDCCH using the Radio Network Temporary Identifier (RNTI) and obtains the successfully decoded DCI as the DCI addressed to the UE. CRC parity bits scrambled by the RNTI are added to the DCI transmitted from gNB 200.

[0041] The MAC layer performs data priority control, retransmission processing via Hybrid ARQ (HARQ: Hybrid Automatic Repeat Request), and random access procedures. Data and control information are transmitted between the MAC layer of UE 100 and the MAC layer of gNB 200 via the transport channel. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) in the uplink and downlink, as well as the resource blocks to be assigned to UE 100.

[0042] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of UE 100 and the RLC layer of gNB 200 via logical channels.

[0043] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

[0044] The SDAP layer performs the mapping between IP flows (as a unit of QoS (Quality of Service) control performed by the core network) and radio bearers (as a unit of QoS control performed by the access layer (AS)). Note that SDAP is not required when the RAN is connected to the EPC.

[0045] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0046] The protocol stack for the control plane's radio interface includes a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer, rather than... Figure 4 The SDAP layer is shown.

[0047] RRC signaling for various configurations is transmitted between the RRC layer of UE 100 and the RRC layer of gNB 200. The RRC layer controls logical channels, transport channels, and physical channels based on the establishment, reconstruction, and release of radio bearers. UE 100 is in an RRC connected state when a connection (RRC connection) is established between the RRC layers of UE 100 and gNB 200. UE 100 is in an RRC idle state when no connection (RRC connection) is established between the RRC layers of UE 100 and gNB 200. UE 100 is in an RRC inactive state when the connection between the RRC layers of UE 100 and gNB 200 is suspended.

[0048] The NAS layer (also simply "NAS"), located above the RRC layer, performs session management, mobility management, and other functions. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF 300A. In addition to the radio interface protocol, UE100 includes an application layer. Layers lower than the NAS layer are called AS layers (also simply "AS").

[0049] (2) Overview of MBS

[0050] Mobile communication system 1 can perform transmission with high resource efficiency by using multicast / broadcast service (MBS).

[0051] (2.1) MBS broadcasting

[0052] In the case of broadcast communication service (also known as "MBS broadcast"), the same service and the same specific content data are provided to every UE100 in the geographical area simultaneously. That is, every UE100 in the broadcast service area is allowed to receive data. The broadcast communication service is delivered to UE100 using a broadcast session (which is a type of MBS session). UE100 can receive broadcast sessions in any state: RRC idle state, RRC inactive state, and RRC connected state.

[0053] Point-to-multipoint (PTM) transmission is applicable to broadcast communication services. For PTM transmission, the gNB 200 transmits a single copy of MBS packets to a set (group) of multiple UEs 100. For example, the gNB 200 uses a group common PDCCH scrambled with a cyclic redundancy code (CRC) scrambled by a group common RNTI (G-RNTI) to schedule a group common PDSCH scrambled with a G-RNTI.

[0054] For broadcast communication services, UE 100 receives broadcast sessions in the following process: First, UE 100 receives System Information Block Type 20 (SIB20) from gNB 200. SIB20 includes the configuration of the Multicast Control Channel (MCCH), which is a logical channel. Second, UE 100 receives the MCCH from gNB 200 based on SIB20. The MCCH includes PTM configuration. The PTM configuration sends the configuration for the Multicast Traffic Channel (MTCH) (MTCH configuration) and the configuration for the Broadcast Multicast Radio Bearer (MRB), which is a logical channel. The broadcast MRB is the MRB used for broadcast sessions. The information sent by the MCCH can be referred to as MBS broadcast control information. Third, UE 100 receives the MTCH based on the MCCH. The MTCH sends the broadcast session (specifically, MBS data belonging to the broadcast session).

[0055] MCCH is the PTM downlink channel used to transmit MBS broadcast control information associated with one or more MTCHs from network 5 to UE 100. MTCH is the PTM downlink channel used to transmit MBS data of multicast or broadcast sessions from network 5 to UE 100.

[0056] (2.2) MBS multicast

[0057] For multicast communication services (also known as "MBS multicast"), the same service and the same specific content data are provided to a specific group of UEs simultaneously. That is, not every UE 100 in the multicast service area is allowed to receive data. Multicast communication services are delivered to UE 100 using a multicast session (which is a type of MBS session).

[0058] UE 100 can only receive multicast sessions after joining a multicast session (session joining). Joining a multicast session means that UE 100 is registered in network 5 (core network 20) ​​to be able to receive multicast sessions.

[0059] For multicast communication services, in 3GPP Release 17, only UE 100 in RRC connected state could receive multicast sessions. On the other hand, in 3GPP Release 18, the specification was extended to allow UE 100 in RRC inactive state to also receive multicast sessions.

[0060] (2.2.1) Multicast reception in RRC connection state

[0061] UE 100 in RRC connection state can use mechanisms such as point-to-point (PTP) and / or point-to-multipoint (PTM) transmission to receive multicast sessions (specifically, MBS data belonging to the multicast session).

[0062] For multicast communication services, UE 100 in RRC connection state receives multicast sessions in the following process: First, UE 100 receives an RRC reconfiguration message from gNB 200. The RRC reconfiguration message is a message sent on the dedicated control channel (DCCH). The RRC reconfiguration message sends the configuration of the MTCH for multicast session reception (MTCH configuration) and the configuration of the multicast MRB as the MRB for the multicast session. Second, UE 100 receives the MTCH based on the RRC reconfiguration message. The MTCH sends the multicast session (specifically, the MBS data belonging to the multicast session).

[0063] (2.2.2) Multicast reception in RRC inactive state

[0064] UE 100 in an RRC inactive state can receive multicast sessions (specifically, MBS data belonging to the multicast session) by using the PTM transmission mechanism.

[0065] For multicast communication services, UE 100 in an RRC inactive state can receive multicast sessions in the following manner. First, UE 100 in an RRC inactive state receives a newly introduced System Information Block (also referred to as "SIBx") from gNB 200. SIBx includes the configuration of the newly introduced MCCH (also referred to as "multicast MCCH"). Second, UE 100 in an RRC inactive state receives a multicast MCCH based on SIBx from gNB 200. The multicast MCCH includes a PTM configuration. The PTM configuration sends the configuration of the MTCH used for multicast session reception (MTCH configuration) and the configuration of the multicast inactive MRB (which is the MRB used for multicast session reception in the RRC inactive state) (multicast inactive MRB configuration). The MTCH configuration can be included in the multicast inactive MRB configuration. Third, UE 100 in an RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH sends the multicast session, specifically, MBS data (i.e., multicast data) belonging to the multicast session.

[0066] When gNB 200 configures UE 100 to receive multicast sessions in an RRC inactive state, gNB 200 can send a PTM configuration (multicast inactive MRB configuration) to UE 100 using an RRC release message that includes a suspend configuration. In this case, when UE 100 receives the RRC release message including the PTM configuration from gNB 200, UE 100 transitions to an RRC inactive state and performs multicast session reception (multicast reception) in the RRC inactive state.

[0067] (2.2.3) Group notification

[0068] If there is no data to be sent to UE 100 in an active multicast session, gNB 200 can switch UE 100 to an RRC inactive state. When the multicast session is deactivated, gNB 200 can switch UE 100 to an RRC idle state or an RRC inactive state.

[0069] When a multicast MBS session is activated by the core network (CN) 20, the MBS-enabled gNB 200 notifies the UE 100, which is in an RRC idle state or an RRC inactive state, using a group notification mechanism. When a multicast session has been activated and the gNB 200 has multicast session data to transmit, the MBS-enabled gNB 200 can use the group notification mechanism to notify the UE 100, which is in an RRC inactive state.

[0070] Upon receiving a group notification, UE 100 either reconnects to network 5 or restores the connection to transition to an RRC connected state. The group notification is processed using the paging RNTI (P-RNTI) on the PDCCH, and UE 100 monitors the paging channel.

[0071] The paging message used for group notification includes a session identifier (MBS session ID) to page all UE 100s that are in RRC idle or RRC inactive states and have joined the associated MBS multicast session. That is, UE 100 is not paged individually.

[0072] When UE 100 transitions to an RRC connected state, UE 100 can stop monitoring group notifications associated with a specific multicast session. That is, UE 100 stops checking the MBS session ID in paging messages. UE 100 does not monitor group notifications if UE 100 leaves the multicast session, network 5 requests UE 100 to leave the multicast session, or network 5 releases the multicast session.

[0073] Note that group notifications can be executed on the MCCH or via MCCH change notifications. When using the MCCH, this can be determined by whether an MTCH configuration for the interested MBS session exists within the MCCH. When using MCCH change notifications, the group notification can be sent in a predefined bit of the DCI.

[0074] (3) Operation of mobile communication systems

[0075] The operation of the mobile communication system 1 according to an embodiment will be described.

[0076] (3.1) Overview of the operation

[0077] In the embodiment, we assume a scenario where a UE 100 in an RRC inactive state initiates an RRC connection recovery (also referred to as "RRC recovery") associated with a multicast session (multicast reception).

[0078] During RRC connection restoration, UE 100 sends an RRC restoration request message to gNB 200. The RRC restoration request message includes a restoration reason, which is an information element related to the cause of the RRC restoration. gNB 200, having received the RRC restoration request message, can identify the reason for UE 100's RRC restoration based on the restoration reason. Therefore, for example, whether to accept the RRC restoration request under network congestion can be determined based on the restoration reason.

[0079] However, when a UE 100 in an RRC inactive state initiates RRC connection recovery in association with a multicast session (multicast reception), there is a problem that it is unclear what information the UE 100 should set in the recovery reason. In the following embodiments, the operation that enables the UE 100 to set appropriate information in the recovery reason in this situation will be described.

[0080] Here, the situation where UE 100 in an RRC inactive state initiates RRC connection recovery in association with a multicast session (multicast reception) is when the reception quality during multicast reception in UE 100 has degraded and / or UE 100 needs to obtain multicast reception configuration (PTM configuration) from gNB 200.

[0081] In this embodiment, the reception quality degradation during multicast reception in UE 100 occurs when the Reference Signal Received Power (RSRP) measured by UE 100 for the serving cell drops below the RSRP threshold configured by network 5 for UE 100 and / or the Reference Signal Received Quality (RSRQ) measured by UE 100 for the serving cell drops below the RSRQ threshold configured by network 5 for UE 100. Alternatively, the reception quality degradation during multicast reception in UE 100 can occur when the Bit Error Rate (BER) measured by UE 100 for the multicast session exceeds the BER threshold configured by network 5 for UE 100 and / or the Block Error Rate (BLER) measured by UE 100 for the multicast session exceeds the BLER threshold configured by network 5 for UE 100.

[0082] UE 100 needs to obtain multicast receive configuration from gNB 200 in the following situations: UE 100 has not yet received the multicast receive configuration of the multicast session in which UE 100 has participated in the RRC release message, and the serving cell has not provided multicast receive configuration by the multicast MCCH. This is when UE 100 receives a paging message (group notification) from the serving cell indicating that the multicast session has been activated. UE 100 also needs to obtain multicast receive configuration from gNB 200 in the following situations: UE 100 performs cell reselection from the first cell to the second cell (i.e., the second cell (the reselected cell) has not provided multicast receive configuration of the multicast session in which UE 100 participates by the multicast MCCH).

[0083] Figure 6 This is a diagram illustrating an overview of the operation of UE 100 according to an embodiment.

[0084] In step S1, UE 100, which is in an RRC inactive state, initiates an RRC connection recovery process for gNB 200 based on the fact that the reception quality during multicast reception in UE 100 has deteriorated and / or UE 100 needs to obtain multicast reception configuration from gNB 200.

[0085] In step S2, UE 100 sends an RRC recovery request message to gNB 200, which includes the recovery reason as an information element related to the reason for RRC recovery.

[0086] The information element (Recovery Reason) is either a first message indicating RRC recovery related to multicast reception, a second message indicating Mobile Termination (MT) access, or a third message indicating Multimedia Priority Access (MPS) priority access. MT access can be access based on incoming communication (i.e., paging reception). MPS can be a service that allows communication even during network congestion. MPS priority access can be priority access via MPS.

[0087] Therefore, when a UE 100 in an RRC inactive state initiates RRC connection recovery in association with a multicast session (multicast reception), the UE 100 sends an RRC recovery request message to the gNB 200. This RRC recovery request message includes first information indicating RRC recovery related to multicast reception, second information indicating MT access, or third information indicating MPS as the reason for recovery.

[0088] The first information is a new recovery reason not defined up to version 17 of the 3GPP standard. By introducing this new recovery reason, the gNB 200 can confirm RRC recovery related to multicast reception. For example, the gNB 200, having received an RRC recovery request message including the first information as the recovery reason, can make an acceptance determination, making it preferable to accept the RRC recovery request. Having received the RRC recovery request message including the first information as the recovery reason, the gNB 200 can, in response to receiving the RRC recovery request message, send an RRC release message to the UE 100 including the multicast reception configuration of the multicast session in which the UE 100 has participated, and can keep the UE 100 in an RRC inactive state.

[0089] The initial information can differ between a situation where reception quality has deteriorated during multicast reception in UE 100 and a situation where UE 100 needs to obtain multicast reception configuration (PTM configuration) from gNB 200. For example, the new recovery reason in the case where reception quality has deteriorated during multicast reception in UE 100 could be "multicast quality," and the new recovery reason in the case where UE 100 needs to obtain multicast reception configuration from gNB 200 could be "multicast configuration."

[0090] Meanwhile, the second and third information are existing recovery reasons, defined in the technical specifications up to version 17 of the 3GPP standard. Minimizing specification changes is facilitated by reusing existing recovery reasons. The second and third information can be existing recovery reasons with higher priority than other existing recovery reasons. The second and third information can be existing recovery reasons for which the gNB 200 preferably accepts the RRC recovery request. This allows RRC connection recovery associated with multicast sessions (multicast reception) rejected by the gNB 200 to be suppressed. The third information can be existing recovery information with higher priority than the second information.

[0091] Execution as Figure 6 The UE 100 shown in the operation includes: a controller 130, which, in an RRC inactive state, initiates an RRC connection recovery process for the gNB 200 based on degraded reception quality during multicast reception in the UE 100 and / or based on the UE 100 needing to obtain a multicast reception configuration from the gNB 200; and a transmitter 120, which sends an RRC recovery request message to the gNB 200 including information elements related to the cause of the RRC recovery. This information element is first information indicating RRC recovery related to multicast reception, second information indicating MT access, or third information indicating MPS. On the other hand, the gNB 200 includes a receiver 220, which receives the RRC recovery request message including the information element from the UE 100 in an RRC inactive state based on degraded reception quality during multicast reception in the UE 100 and / or the UE 100 needing to obtain a multicast reception configuration from the gNB 200.

[0092] UE 100 can also initiate an RRC connection recovery process and send an RRC recovery request message to gNB 200, including any one of the first to third information elements, based on the fact that gNB 200 allows multicast reception in RRC inactivity. The fact that gNB 200 allows multicast reception in RRC inactivity can mean that the RRC release message (suspend configuration) has indicated permission for multicast reception in RRC inactivity for multicast sessions in which UE 100 is already involved. Therefore, when gNB 200 allows multicast reception in RRC inactivity, it becomes easier to perform operations on UE 100 regarding the reason for recovery, unlike existing operations.

[0093] In the first operating mode of this embodiment, UE 100, which is in an RRC inactive state, can receive a paging message (group notification) from gNB 200 indicating that a multicast session in which UE 100 has already been activated is active. In step S1, when UE 100 receives the paging message and UE 100 does not have a multicast receive configuration corresponding to the multicast session in which UE 100 has already been in, UE 100 can initiate the RRC connection recovery process. In step S2, UE 100 can send an RRC recovery request message to gNB 200, including first information (new recovery reason) as an information element.

[0094] In the second operating mode of the embodiment, in step S2, UE 100 sends an RRC recovery request message to gNB 200, which includes second information or third information (existing recovery reason) as information elements.

[0095] In the second operating mode of the embodiment, when UE 100 does not receive a paging message indicating that a multicast session in which UE 100 has already been activated is activated, UE 100 may initiate an RRC connection recovery process and send an RRC recovery request message to gNB 200, including second information or third information as information elements.

[0096] In the second operating mode of the embodiment, UE 100 can initiate an RRC connection recovery process based on the fact that UE 100 is performing multicast reception in an RRC inactive state, and send an RRC recovery request message including second information or third information as information elements to gNB 200. UE 100 can also initiate an RRC connection recovery process based on the fact that UE 100 is performing multicast reception in an RRC inactive state and that the reception quality during multicast reception has degraded, and can send an RRC recovery request message including second information or third information as information elements to gNB 200.

[0097] In the second operating mode of the embodiment, UE 100 can initiate the RRC connection recovery process based on the fact that UE 100 cannot obtain multicast reception configuration from the cell reselected through cell reselection, and can send an RRC recovery request message including second information or third information as information elements to gNB 200.

[0098] (3.2) Specific operation example

[0099] Specific examples of the operation of the mobile communication system 1, including a first operating mode and a second operating mode, will be described. Each operating mode can be implemented independently, or the two operating modes can be combined.

[0100] (3.2.1) First operating mode

[0101] In the first operating mode, when UE 100 receives a group notification (paging message) and needs to transition to RRC connected state to receive multicast reception configuration (PTM configuration), UE 100 sets the first information (new recovery reason) in the RRC recovery request message. This operation is only applicable if gNB 200 allows multicast session reception in RRC inactive state.

[0102] Figure 7 This is a diagram illustrating an example of a first operating mode of a mobile communication system according to an embodiment.

[0103] In step S101, UE 100 is in an RRC connected state in the cell of gNB 200. It is assumed that UE 100 has participated in a multicast session, and this multicast session is also referred to as the multicast session in which UE 100 has participated. "Involved in a multicast session" can mean the following state: UE 100 is registered in network 5 (CN 20) as a UE 100 receiving a multicast session. In the first operating mode, it is assumed that the multicast session in which UE 100 has participated is activated after UE 100 transitions to an RRC inactive state.

[0104] In step S102, gNB 200 sends an RRC release message including a suspend configuration to UE 100, that is, an RRC release message used to convert UE 100 to an RRC inactive state. UE 100 receives the RRC release message.

[0105] The RRC release message in step S102 includes at least one of the following information 1) to 3).

[0106] 1) Information allowing (or indicating) multicast reception in RRC inactive state. This information can be provided for each multicast session. This information can be information indicating that UE 100 has participated in a multicast session in which multicast reception in RRC inactive state is allowed (or indicated).

[0107] (2) Information indicating the use of a new recovery reason (first information).

[0108] (3) Notify UE 100 that the multicast session it has participated in is not in an active state (i.e., is in an inactive state).

[0109] This information can be an indication of whether a multicast session is active for each multicast session that the UE 100 has already participated in. Whether a multicast session is active can be equivalent to whether to immediately start receiving MBS data (MTCH) corresponding to the multicast session.

[0110] However, the RRC release message in step S102 does not include the multicast receive configuration (PTM configuration) for multicast reception in the RRC inactive state.

[0111] In step S103, UE 100 transitions to an RRC inactive state in response to receiving the RRC release message from step S102.

[0112] In step S104, in response to activating a multicast session that UE 100 has already participated in, gNB 200 sends a paging message (group notification) including the session identifier (MBS session ID) of the multicast session that UE 100 has already participated in. UE 100 receives the paging message (group notification).

[0113] In step S105, UE 100 initiates the RRC connection recovery procedure in response to receiving the paging message from step S104. Specifically, in response to the paging message including a session identifier of a multicast session that UE 100 has already participated in, and UE 100 not having a multicast receive configuration for the multicast session that UE 100 has already participated in, UE 100 initiates the RRC connection recovery procedure. Not having a multicast receive configuration may mean that UE 100 has not yet received the multicast receive configuration in the RRC release message from step S132, and the serving cell has not broadcast the multicast receive configuration via the multicast MCCH.

[0114] In step S106, UE 100 sets the first information (new recovery reason) in the RRC recovery request message and sends the RRC recovery request message to gNB 200. gNB 200 receives the RRC recovery request message. In response to multicast reception being allowed (or indicated) in the RRC release message in step S102, or in response to being indicated to use a new recovery reason (first information), UE 100 may set the first information (new recovery reason) in the RRC recovery request message. For example, the first information may be "multicast configuration in RRC inactivity". The first information may indicate a reason unrelated to unicast communication or a reason only related to multicast communication.

[0115] In step S107, in response to receiving the RRC recovery request message including first information (new recovery reason) from step S106, gNB 200 sends an RRC release message to UE 100, including multicast receive configuration and the suspension configuration of the multicast session already participated in by UE 100. That is, gNB 200 provides multicast receive configuration to UE 100 in the RRC release message without causing UE 100 to switch to an RRC connected state. UE 100 receives the RRC release message.

[0116] In step S108, gNB 200 sends MBS data (multicast data) of the multicast session in which UE 100 has participated on MTCH.

[0117] In step S109, UE 100 applies the multicast reception configuration of step S107 and performs multicast reception in the RRC inactive state. Specifically, UE 100 receives MBS data (multicast data) of the multicast session in which UE 100 participates from gNB 200 on MTCH.

[0118] Figure 8 This is a diagram illustrating another example of a first operating mode of a mobile communication system 1 according to an embodiment. The description herein is related to... Figure 7 The differences in the operation examples.

[0119] The operations of steps S131 to S136 and Figure 7 The operation is similar. However, step S134 can be omitted. For example, UE 100 can initiate an RRC connection recovery procedure (step S135) in response to a degradation in the reception quality during multicast reception in UE 100. The first information (new recovery reason) included in the RRC recovery request message in step S136 can be information indicating the degradation of multicast reception quality.

[0120] In step S137, in response to receiving the RRC recovery request message including first information (new recovery reason) from step S136, gNB 200 determines that UE 100 has transitioned to an RRC connected state and sends an RRC recovery message to UE 100. UE 100 receives the RRC recovery message. gNB 200 can determine that UE 100 transitioned to an RRC connected state in response to easing network congestion.

[0121] In step S138, UE 100 sends an RRC recovery complete message to gNB 200 in response to receiving the RRC recovery message from step S137. gNB 200 receives the RRC recovery complete message.

[0122] In step S139, UE 100 transitions from RRC inactive state to RRC connected state.

[0123] In step S140, gNB 200 sends an RRC reconfiguration message to UE 100, including the multicast receive configuration of the multicast sessions that UE 100 has already participated in. UE 100 receives the RRC reconfiguration message.

[0124] In step S141, gNB 200 sends MBS data (multicast data) of the multicast session in which UE 100 has participated on MTCH.

[0125] In step S142, UE 100 applies the multicast reception configuration of step S140 and performs multicast reception in RRC connection state. Specifically, UE 100 receives MBS data (multicast data) of the multicast session in which UE 100 participates from gNB 200 on MTCH.

[0126] (3.2.2) Second operating mode

[0127] In the second operating mode, during RRC recovery related to a multicast session (multicast reception), UE 100 sets the recovery reason to "MT access" or "MPS priority access". This operation can be applied when UE 100 has not yet received a group notification (paging message). This operation can be applied when UE 100 is receiving a multicast session in an RRC inactive state, especially when the reception quality of the multicast session in the RRC inactive state is degraded. This operation can be applied when UE 100 performs cell reselection and cannot obtain PTM configuration from the reselected cell. This operation can be applied when UE 100 has received permission (instruction) for multicast reception in the RRC inactive state from gNB 200.

[0128] Figure 9 This is a diagram illustrating an example of a second operating mode of a mobile communication system 1 according to an embodiment. This document primarily describes the differences from the first operating mode described above.

[0129] In step S201, UE 100 is in an RRC connected state in the cell of gNB 200. Assume that UE 100 has already participated in a multicast session.

[0130] In step S202, gNB 200 sends an RRC release message including a suspend configuration to UE 100, that is, an RRC release message used to switch UE 100 to an RRC inactive state. UE 100 receives the RRC release message. The RRC release message in step S202 may include information similar to the RRC release message of the first operating mode.

[0131] In step S203, UE 100 transitions to an RRC inactive state in response to receiving the RRC release message from step S202. UE 100 in the RRC inactive state can perform multicast reception.

[0132] In step S204, UE 100 initiates the RRC connection recovery procedure. In the second operating mode, UE 100 may initiate the RRC connection recovery procedure in response to at least one of the following conditions 1) to 3).

[0133] (1) The reception quality at UE 100 during multicast reception has deteriorated.

[0134] (2) UE 100 performs cell reselection, and the reselected cell (the cell where UE 100 is newly camped) does not provide a multicast MCCH that includes the multicast reception configuration of the multicast sessions that UE 100 has already participated in.

[0135] 3) Similar to the first operating mode, UE 100 receives group notifications (paging messages) and does not save a valid PTM configuration. Additionally, multicast reception in RRC inactive states can be allowed (or indicated).

[0136] In step S205, UE 100 sets the second information (MT access) as the recovery reason in the RRC recovery request message and sends the RRC recovery request message to gNB 200. gNB 200 receives the RRC recovery request message.

[0137] In response to receiving the RRC recovery request message from step S205, which includes the second information as the reason for recovery, gNB200 preferably accepts the RRC recovery from UE 100 and sends an RRC recovery message to UE 100. UE 100 receives the RRC recovery message.

[0138] In step S207, UE 100 sends an RRC recovery complete message to gNB 200 in response to receiving the RRC recovery message from step S206. gNB 200 receives the RRC recovery complete message.

[0139] In step S208, UE 100 transitions from RRC inactive state to RRC connected state.

[0140] In step S209, gNB 200 sends an RRC reconfiguration message to UE 100, including the multicast receive configuration of the multicast sessions that UE 100 has already participated in. UE 100 receives the RRC reconfiguration message.

[0141] In step S210, gNB 200 sends MBS data (multicast data) of the multicast session in which UE 100 has participated on MTCH.

[0142] In step S211, UE 100 applies the multicast reception configuration of step S140 and performs multicast reception in RRC connection state. Specifically, UE 100 receives MBS data (multicast data) of the multicast session in which UE 100 participates from gNB 200 on MTCH.

[0143] Figure 10 This is a diagram illustrating another example of a second operating mode of the mobile communication system 1 according to an embodiment.

[0144] The operation of steps S231 to S241 and Figure 9 The specific examples of the operations are basically the same. However, in step S235, UE 100 sets the third information (MPS priority access) as the recovery reason in the RRC recovery request message and sends the RRC recovery request message to gNB 200. gNB 200 receives the RRC recovery request message. In step S236, gNB 200 preferably accepts the RRC recovery request from UE 100 and, in response to receiving the RRC recovery request message from step S235 that includes the third information as the recovery reason, sends an RRC recovery message to UE 100. UE 100 receives the RRC recovery message.

[0145] (4) Other embodiments

[0146] Although the above embodiments primarily describe multicast reception in the RRC inactive state, the operation according to the above embodiments is also applicable to multicast reception in the RRC idle state. In the RRC idle state, the aforementioned RRC recovery is replaced by RRC establishment, and the aforementioned recovery reason is replaced by the establishment reason.

[0147] The above operational procedures can be implemented separately and independently, or they can be implemented as a combination of two or more operational procedures. For example, some steps in one operational procedure can be added to another, or some steps in one operational procedure can be replaced by some steps in another. In each procedure, not all steps are required to be executed; only some steps may be executed. In addition, the order of steps can be changed appropriately within each procedure.

[0148] Although the example of a base station being an NR base station (gNB) has been described in the above embodiments and examples, the base station can be an LTE base station (eNB) or a 6G base station. The base station can be a relay node, such as an Integrated Access and Backhaul (IAB) node. The base station can be a DU of an IAB node. UE 100 can be a Mobile Termination (MT) of an IAB node. That is, UE 100 can be a Terminal Functional Unit (a communication module) used by the base station to control repeaters that perform signal relay. Such a Terminal Functional Unit is called an MT. Besides IAB-MT, examples of MTs include Network Control Repeater (NCR)-MT and Reconfigurable Smart Surface (RIS)-MT.

[0149] The term "network node" primarily refers to a base station, but can also refer to core network equipment or a portion of a base station (CU, DU, or RU). A network node can include a combination of at least a portion of core network equipment and at least a portion of a base station.

[0150] A program can be provided for causing a computer to perform each process according to the above embodiments. The program can be recorded on a computer-readable medium. The computer-readable medium enables the program to be installed on a computer. Here, the computer-readable medium on which the program is recorded can be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and can be, for example, a recording medium such as a CD-ROM or DVD-ROM. Furthermore, circuitry for performing the corresponding processes according to the above embodiments can be integrated, and at least a portion of UE 100 or gNB 200 can be configured as a semiconductor integrated circuit (chipset or SoC (system-on-chip)).

[0151] The functions implemented by the apparatus according to the above embodiments can be implemented in a circuit or processing circuit programmed to implement the functions, including a general-purpose processor, a special-purpose processor, an integrated circuit, an application-specific integrated circuit (ASIC), a central processing unit (CPU), conventional circuitry, and / or combinations thereof. A processor may include transistors and other circuitry and may be considered as a circuit or processing circuit. A processor may be a programmed processor that executes a program stored in memory. In this disclosure, circuits, units, and apparatuses are hardware programmed to implement the functions or hardware performing the functions. The hardware may be any hardware disclosed herein or any hardware programmed to implement the functions or any hardware known to perform the functions. When the hardware is a processor considered as a type of circuit, the circuit, apparatus, or unit is a combination of hardware and software for configuring the hardware and / or the processor.

[0152] Unless otherwise expressly stated, the phrases “based on” and “depending on / in response to” as used in this disclosure do not mean “based on only” and “depending on only / in response to only”. The phrase “based on” means “based on only” and “at least partially based on” both. The phrase “depending on” means “depending on only” and “at least partially dependent on” both. The terms “comprising,” “including,” and variations thereof do not mean “including only the said items,” but rather mean “may include only the said items” or “may include not only the said items but also other items.” The term “or” as used in this disclosure is not intended to be “exclusive or.” Any reference to elements in this disclosure using names such as “first” and “second” does not generally limit the number or order of those elements. These names may be used herein as a convenient way to distinguish two or more elements. Therefore, a reference to a first element and a second element does not imply that only the two elements may be used there or that the first element needs to precede the second element in some way. For example, when English articles such as “a,” “one,” and “the” are added in this disclosure by translation, these articles include plural unless the context clearly indicates otherwise.

[0153] The embodiments have been described in detail above with reference to the accompanying drawings, but the specific configurations are not limited to those described above, and various design changes can be made without departing from the spirit of this disclosure.

[0154] This application claims priority to U.S. Provisional Application No. 63 / 540261 (filed September 25, 2023), the entire contents of which are incorporated herein by reference.

[0155] (5) First Supplement

[0156] The following are additional features related to the above embodiments.

[0157] (Supplement 1)

[0158] A communication method for use in a mobile communication system for providing multicast / broadcast services (MBS), the communication method comprising:

[0159] An RRC connection recovery process is initiated by a user equipment (UE) in an RRC inactive state, based on the fact that the reception quality during multicast reception in the UE has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node; and

[0160] The user equipment sends an RRC recovery request message to the network node, including information elements related to the reason for the RRC recovery.

[0161] The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

[0162] Supplement 2

[0163] According to the communication method described in Supplement 1

[0164] The user equipment further initiates the RRC connection recovery process based on the network node's permission for multicast reception in the RRC inactive state, and sends an RRC recovery request message to the network node, including any one of the first to third information as the information element.

[0165] Supplement 3

[0166] The communication method described in Supplement 1 or 2 further includes:

[0167] The user equipment receives a paging message from the network, the paging message indicating that a multicast session already participated in by the user equipment has been activated.

[0168] The initiation includes starting the RRC connection recovery process when the user equipment does not have a multicast receive configuration corresponding to the multicast session when the paging message is received, and

[0169] The sending includes sending an RRC recovery request message to the network node, which includes the first information as an information element.

[0170] Supplement 4

[0171] According to the communication method described in Supplement 1 or 2, wherein,

[0172] The sending includes sending an RRC recovery request message to the network node, which includes the second information or the third information as information elements.

[0173] Supplement 5

[0174] According to the communication method described in Supplement 4

[0175] When the user equipment has not yet received a paging message indicating that the user equipment has activated a multicast session it has already participated in, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, which includes the second information or the third information as the information element.

[0176] Supplement 6

[0177] According to the communication method described in Supplement 4 or 5, wherein,

[0178] Based on the user equipment performing multicast reception in the RRC inactive state, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

[0179] Supplement 7

[0180] According to the communication method described in Supplement 6

[0181] Based on the fact that the user equipment performs multicast reception in the RRC inactive state and the reception quality has deteriorated during the multicast reception, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

[0182] Supplement 8

[0183] According to any one of Supplements 4 to 7, in the communication method, wherein,

[0184] Since the user equipment cannot obtain multicast reception configuration from the cell reselected through cell reselection, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

[0185] Supplement 9

[0186] A user equipment for use in a mobile communication system for providing multicast broadcast service (MBS), the user equipment comprising:

[0187] The controller is configured to initiate an RRC connection recovery process for the network node based on the fact that the reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to obtain multicast reception configuration from the network node while in an RRC inactive state; and

[0188] The transmitter is configured to send an RRC recovery request message to the network node, including information elements related to the reason for the RRC recovery.

[0189] The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

[0190] Supplement 10

[0191] A network node for use in a mobile communication system for providing multicast broadcast service (MBS), the network node comprising:

[0192] The receiver is configured to receive an RRC recovery request message from a user equipment (UE) that includes information elements related to the cause of RRC recovery, based on the fact that the reception quality during multicast reception in a UE in an RRC inactive state has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node.

[0193] The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

[0194] (6) Second Supplement

[0195] 1. Introduction

[0196] The work project regarding the enhancement of MBS (eMBS) aims to support multicast reception in inactive UEs, as follows:

[0197] - Define support for multicast reception by UEs in RRC inactive state [RAN2, RAN3].

[0198] • PTM configuration [RAN2] for UEs receiving multicast in RRC inactive state.

[0199] • Investigate the impact of multicast reception on UE mobility and state transitions in RRC inactive states. (Seamless / lossless mobility is not mandatory) [RAN2, RAN3].

[0200] This supplement discusses in detail the RRC recovery caused by poor quality and the reasons for such recovery.

[0201] 2. Discussion

[0202] 2.1. RRC recovery due to poor reception quality

[0203] RAN2#123 agrees to introduce RRC recovery based on RSRP / RSRQ, as shown below.

[0204] In UEs receiving multicast while in RRC inactive, the UE restores RRC connection when the RSRP or RSRQ of the serving cell, measured based on existing (NW-configured) measurement requirements, falls below a threshold configured by the network. Further investigation is needed to determine if the ping-pong problem needs to be addressed.

[0205] The threshold can be configured for each MBS session via RRC release or multicast MCCH messages.

[0206] Based on the agreement, the remaining issues will be discussed in the following sections.

[0207] 2.1.1. Table Tennis Problem

[0208] Agreements can be obtained by capturing discussion items regarding "whether and / or how to solve the ping-pong problem." For scenarios involving resuming ping-pong operations, the following can be considered:

[0209] 1. When RSRP / RSRQ becomes worse than the threshold, the radio quality deteriorates and the inactive UE initiates RRC recovery.

[0210] 2. In response to an RRC recovery request, a gNB under NW congestion sends an RRC release with a suspend configuration including RSRP / RSRQ thresholds.

[0211] 3. UEs with still degraded radio quality are switched to an inactive state, and RRC recovery is restarted because RSRP / RSRQ immediately falls below the threshold.

[0212] To avoid the ping-pong effect in the above scenarios, the gNB can be kept in a connected state or an appropriate RSRP / RSRQ threshold can be set for the UE.

[0213] To support this determination, the gNB may need to confirm the radio conditions and / or the cause of the RRC restoration as soon as possible when the UE requests RRC restoration (in this case, due to radio quality degradation).

[0214] Finding 1: When a UE requests RRC recovery to ensure QoS requirements, the gNB may need to verify the UE's radio conditions and the reason for the RRC recovery.

[0215] Based on the discussions in the early stages of RAN2 version 18, it should be noted that the two main motivations for supporting multicast reception in inactive states are NW congestion mitigation and UE power consumption. Therefore, it is unreasonable for the gNB to always keep the UE in a connected state and configure measurement reports every time the UE requests RRC recovery.

[0216] Finding 2: Since the motivation for supporting multicast reception in inactive states is NW congestion mitigation and UE power saving, it is unreasonable to rely on measurement reports to guarantee QoS requirements.

[0217] Considering the above findings, it is useful for the UE to report measurement results when it initiates RRC recovery due to reception quality degradation during the RRC recovery process—that is, at the time of the RRC recovery request or upon completion of the RRC recovery. Another option is for the UE to notify of the radio wave condition degradation in the recovery reason. With this information, the gNB can appropriately determine whether to keep the UE connected for QoS guarantees.

[0218] Recommendation 1: RAN2 should agree to report measurement results during RRC recovery or introduce a new recovery reason, "multicast quality".

[0219] 2.1.2. Validity of RSRP / RSRQ thresholds configured by RRC release

[0220] RAN2 agrees that "thresholds can be configured in the PTM configuration for each MBS session based on RRC release or multicast MCCH messages." In the case of dedicated configurations provided by RRC release, many configurations remain valid until the corresponding timer expires. For example, dedicated frequency priorities remain valid until T320 expires. This occurs regardless of whether cell reselection occurs, and the dedicated configurations provided from the source cell remain valid after the UE reselects the target cell.

[0221] Finding 3: According to the current specification, many dedicated configurations remain valid until the timer expires, regardless of whether cell reselection is performed.

[0222] Regarding the RSRP / RSRQ thresholds, when they are valid after cell reselection, problems are likely to occur in the following situations:

[0223] - In the source cell, since PTM transmits with a low MCS, the UE has set a low RSRP threshold to ensure a certain reception quality.

[0224] - In the target cell after cell reselection, PTM transmits with a higher MCS, but the UE still applies the old RSRP threshold.

[0225] Therefore, even if RSRP is still better than the old threshold, the UE will still cause MTCH reception errors.

[0226] To avoid this problem, considering that NR MBS PTM transmission is cell-specific, the RSRP / RSRQ thresholds should also be cell-specific. That is, when the UE reselects a different cell, the old RSRP / RSRQ thresholds should be discarded.

[0227] Recommendation 2: RAN2 should agree to discard the RSRP / RSRQ threshold during cell reselection.

[0228] Another issue to consider when handling RSRP / RSRQ thresholds is that the UE needs to determine which threshold should be applied when both RRC release and multicast MCCH provide the threshold. In the current specification, the dedicated configuration provided by RRC release typically takes precedence over the configuration provided by SIB. However, in the case of multicast reception in an inactive state, RAN2 agrees that "when a change in PTM configuration is required, the MCCH should be used when an indication of the PTM configuration is needed," meaning that the PTM configuration provided by RRC release may be changed by the PTM configuration provided by multicast MCCH. This implies that, since the RSRP / RSRQ thresholds are overridden by the multicast MCCH, the thresholds cannot be configured to a UE-specific configuration, i.e., a TMGI-specific configuration.

[0229] Recommendation 3: RAN2 needs to confirm that the PTM configuration provided by RRC release, including RSRP / RSRQ thresholds, is always overridden by the configuration provided by multicast MCCH, that is, there is no UE-specific configuration for multicast reception in the inactive state.

[0230] 2.1.3. Other Confirmation Items

[0231] RAN2#123 agrees that "for UEs receiving multicast in an inactive RRC state, the UE shall restore the RRC connection when the measured RSRP or RSRQ of the serving cell becomes below the threshold [...]." The RSRP / RSRQ threshold is introduced to ensure the QoS of multicast reception in an inactive state.

[0232] On the other hand, when a multicast session is deactivated by the network, an inactive UE may not be able to receive the MTCH (or may be temporarily unable to receive data) during the deactivation of the session. In this case, since the UE is considered the same as a conventional UE in an inactive state, RRC recovery due to poor quality (RSRP / RSRQ threshold) is not required. Although the above protocol has been recommended, it is still necessary to confirm that even if RSRP / RSRQ degrades to below the threshold, an inactive UE will not initiate RRC recovery when the multicast session is inactive (deactivated) (or when there is temporarily no data).

[0233] Recommendation 4: RAN2 needs to confirm that if a multicast session is deactivated (or data is temporarily unavailable), an inactive UE will not initiate RRC recovery even if RSRP / RSRQ becomes worse than the threshold.

[0234] In RAN2#123, RAN2 had already discussed whether the threshold could be based on BLER, but ultimately RAN2 decided to use RSRP / RSRQ.

[0235] On the other hand, in version 17, the general understanding of RAN2 is that, due to NW implementation, single-frequency networks (SFNs) can only be deployed in DUs, for example. In inter-cell SFNs, reception quality is stable even at cell edges by combining the reception of MTCHs from different cells. However, RSRP / RSRQ is cell-specific, and RSRP / RSRQ degrades at cell edges when leaving the SFN. Therefore, RSRP / RSRQ thresholds are ineffective in SFN deployments, but BLER thresholds can avoid this problem.

[0236] Recommendation 5: RAN2 needs to confirm that in version 18, the SFN (Single Frequency Network) allowed by NW implementation in version 17 cannot work using RSRP / RSRQ thresholds.

[0237] 2.2. Reasons for recovery

[0238] RAN2#123 agrees that, in version 18, existing recovery causes should be reused for RRC recovery due to certain reasons and the reception quality degradation discussed in previous sections. However, it is still necessary to analyze which existing recovery cause should be used and whether a new recovery cause is truly unnecessary.

[0239] Unless a problem is specified when using one of the existing recovery reasons, no new recovery reason is introduced for a UE that is in an inactive receiving MC when a recovery is performed due to poor quality or missing SIBx / PTM configuration.

[0240] Currently, 11 recovery reasons are defined through the following five alternative fields.

[0241] ResumeCause ::= ENUMERATED {emergency, highPriorityAccess, mt-Access,mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess, mcs-PriorityAccess, spare1, spare2, spare3, spare4, spare5}

[0242] Similar to Finding 2 above, one of the motivations for multicast reception in inactive states is network congestion mitigation. Therefore, the analysis needs to consider scenarios where the network becomes congested.

[0243] Finding 4: The mapping between RRC recovery and existing recovery reasons used for multicast reception needs to take network congestion into account.

[0244] Typical determinations made by a gNB when receiving an RRC recovery request under network congestion are categorized as follows:

[0245] - Always be prepared for emergencies;

[0246] - Prioritize highPriorityAccess, mps-PriorityAccess, and mcs-PriorityAccess;

[0247] - Accept mt-Access and mo-Signalling (as many times as possible);

[0248] - You can refuse mo-Data, mo-VoiceCall, mo-VideoCall, and mo-SMS;

[0249] - Respond to new RNA with RRC release targeting RNA-Update.

[0250] Finding 5: Through recovery, gNB can determine whether to accept, reject, or release new RNA in response to an RRC recovery request, especially in the case of NW congestion.

[0251] RAN2 agrees that the UE may initiate RRC recovery in the following two situations: "due to poor quality" or "due to lack of SIBx / PTM configuration". From the perspective of the impact on network load, these reasons are characterized as follows:

[0252] As discussed in Section 2.1.1, in cases of RRC recovery due to poor quality, QoS requirements are no longer guaranteed when the UE is released again while still inactive, thus requiring the UE to remain connected. Considering the need to remain connected, the UE does not consume additional downlink resources (because it only receives PTMs already sent to other UEs), but it does consume uplink resources (e.g., HARQ ACKs). When network congestion occurs, the UE consumes slightly more resources compared to multicast reception in an inactive state, but this still takes precedence over recovery requests for unicast services. In other words, the gNB can prioritize RRC recovery requests for multicast reception over those for unicast reception, but the gNB can still reject RRC recovery requests due to severe congestion.

[0253] - In the event of RRC recovery due to a lack of SIBx / PTM configuration, the UE can be released in PTM configuration (i.e., during RRC recovery) to receive multicast sessions when radio conditions are good. Therefore, this is "lightweight" in terms of network congestion; that is, the UE consumes almost no downlink / uplink resources. In other words, with RRC release accompanied by PTM configuration for RRC recovery, the NW can immediately accept the RRC recovery request.

[0254] Finding 6: Because the gNB affects NW congestion to some extent in order to keep the UE connected during NW congestion, the gNB may refuse RRC recovery due to poor quality.

[0255] Finding 7: Due to the lack of SIBx / PTM configuration, the gNB can accept RRC recovery and immediately release UEs with PTM configuration. This is because it does not affect NW congestion.

[0256] Considering the above discussion, RRC recovery due to poor quality may be mapped to any of mo-Data, mo-VoiceCall, mo-VideoCall, or mo-SMS. However, since multicast reception in connected mode does not require additional PDSCH resources (i.e., PTM has been provided to other UEs), mapping different types of communication (i.e., multicast reception only) to existing recovery causes may affect the current gNB implementation for such existing recovery causes.

[0257] For RRC recovery due to the lack of SIBx / PTM configuration, there is no recovery reason to map because there is a new intention for RRC recovery accompanied by PTM configuration. Although a similar gNB determination is assumed in rna-Update, the gNB provides RNA instead of PTM configuration for RRC recovery. That is, the gNB cannot send an RRC release with PTM configuration in response to an RRC recovery request, and the gNB may incorrectly reject the UE request even if the UE only requests a PTM configuration update without affecting NW congestion.

[0258] Finding 8: There is no existing recovery reason for the following: in the case of an RRC recovery request caused by poor quality or missing SIBx / PTM configuration, the gNB determination is as expected.

[0259] RAN2 has actually identified the possibility of new causes of recovery in the following discussion.

[0260] Reason for restoration:

[0261] 1. Multicast quality

[0262] 2. Multicast Configuration

[0263] These two recovery reasons can easily resolve all the problems discussed above without potentially impacting the current gNB implementation. As also discussed above, these two recovery reasons help gNB appropriately derive different results. Therefore, two new recovery reasons should be appropriately introduced.

[0264] Given the high expectation that 3GPP will consider 6G starting with release 20, it is anticipated that 5G NR will only develop two releases in the future (i.e., at most release 20). Considering the convention of adding recovery in previous releases, three recovery types will suffice in release 18.

[0265] Recommendation 6: RAN2 should agree on a new recovery reason, "Multicast Quality," to be configured when RRC recovery is initiated due to poor quality. The determination of the expected gNB should take precedence over MO data, etc.

[0266] Recommendation 7: RAN2 should agree on a new recovery reason, "Multicast Configuration," to be configured when RRC recovery is initiated due to a lack of SIBx / PTM configuration. The determination of the expected gNB will be responded to with a release RRC accompanied by PTM configuration.

[0267] Figure Labels

[0268] 1: Mobile communication system

[0269] 5: Network

[0270] 10: RAN

[0271] 20:CN

[0272] 100: User Equipment (UE)

[0273] 110: Receiver

[0274] 120: Transmitter

[0275] 130: Controller

[0276] 200: gNB (base station)

[0277] 210: Transmitter

[0278] 220: Receiver

[0279] 230: Controller

[0280] 240: Backhaul communicator.

Claims

1. A communication method used in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising the following steps: The RRC connection recovery process for the network node is initiated by a user equipment that is in an inactive state of Radio Resource Control (RRC) while participating in a multicast session, based on the reception quality dropping to a threshold. as well as The user equipment sends an RRC recovery request message to the network node, including information elements related to the reason for the RRC recovery. The information element is either information indicating mobile termination of MT access or information indicating multimedia priority access (MPS) priority access.

2. A communication method used in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising the following steps: An RRC connection recovery process is initiated by a user equipment (UE) in an RRC inactive state, based on the fact that the reception quality during multicast reception in the UE has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node. as well as The user equipment sends an RRC recovery request message to the network node, including information elements related to the reason for the RRC recovery. The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

3. The communication method according to claim 2, wherein, The user equipment also initiates the RRC connection recovery process based on the network node's permission for multicast reception in the RRC inactive state, and sends an RRC recovery request message to the network node, including any one of the first to the third information as the information element.

4. The communication method according to claim 2 further includes: The user equipment receives a paging message from the network node, the paging message indicating that a multicast session already participated in by the user equipment has been activated. The initiation includes starting the RRC connection recovery process when the user equipment does not have a multicast receive configuration corresponding to the multicast session when the paging message is received, and The sending includes sending an RRC recovery request message to the network node, which includes the first information as an information element.

5. The communication method according to claim 2, wherein The sending includes sending an RRC recovery request message to the network node, which includes the second information or the third information as information elements.

6. The communication method according to claim 5, wherein, When the user equipment has not yet received a paging message indicating that the user equipment has activated a multicast session it has already participated in, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, which includes the second information or the third information as the information element.

7. The communication method according to claim 5, wherein, Based on the user equipment performing multicast reception in the RRC inactive state, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

8. The communication method according to claim 7, wherein, Based on the fact that the user equipment performs multicast reception in the RRC inactive state and the reception quality has deteriorated during the multicast reception, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

9. The communication method according to claim 5, wherein Since the user equipment cannot obtain multicast reception configuration from the cell reselected through cell reselection, the user equipment initiates the RRC connection recovery process and sends an RRC recovery request message to the network node, including the second information or the third information as the information element.

10. A user equipment for use in a mobile communication system for providing multicast broadcast service (MBS), the user equipment comprising: The controller is configured to initiate an RRC connection recovery process for the network node in an RRC inactive state based on the fact that the reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to obtain multicast reception configuration from the network node. as well as The transmitter is configured to send an RRC recovery request message to the network node, including information elements related to the reason for the RRC recovery. The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

11. A network node for use in a mobile communication system for providing multicast broadcast service (MBS), the network node comprising: The receiver is configured to receive an RRC recovery request message from a user equipment (UE) that includes information elements related to the cause of RRC recovery, based on the fact that the reception quality during multicast reception in a UE in an RRC inactive state has deteriorated and / or the UE needs to obtain multicast reception configuration from the network node. The information element is a first information indicating RRC recovery related to multicast reception, a second information indicating mobile termination (MT) access, or a third information indicating multimedia priority access (MPS) priority access.

Images