Communication method

Abstract

A communication method performed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS) includes receiving a radio resource control (RRC) release message from a network node, the RRC release message causing the user equipment to transition to an RRC inactive state, wherein the RRC release message includes configuration information of a multicast inactive multicast radio bearer (MRB) for receiving the multicast session in the RRC inactive state; confirming whether the RRC release message includes state information on whether the multicast session has been activated; and initiating a multicast reception process using a multicast inactive MRB based on the configuration information when the RRC release message does not include the state information.

Description

Technical Field

[0001] This disclosure relates to a communication method 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 method performed by a user equipment in a mobile communication system for providing multicast / broadcast services (MBS). The communication method includes: receiving a Radio Resource Control (RRC) release message from a network node, the RRC release message including PTM configuration information for receiving a multicast session in an RRC inactive state, the RRC release message causing the user equipment to transition to an RRC inactive state; confirming whether the RRC release message includes predetermined information indicating a pause in initiation of a multicast reception process for the multicast session; and, when the RRC release message does not include the predetermined information, initiating the multicast reception process based on the PTM configuration information.

[0008] The communication method according to the second aspect is a communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS). The communication method includes: receiving a multicast session using a multicast radio bearer (MRB) while in a Radio Resource Control (RRC) connection state; receiving an RRC release message from a network node, the RRC release message including configuration information for receiving a multicast inactive MRB for a multicast session in an RRC inactive state, the RRC release message causing the user equipment to transition to an RRC inactive state; confirming whether a multicast inactive MRB corresponding to the multicast MRB is configured; and when a multicast inactive MRB corresponding to the multicast MRB is configured, initiating a multicast reception process using the multicast inactive MRB.

[0009] The communication method according to the third aspect is a communication method performed by a user equipment in a mobile communication system providing multicast / broadcast service (MBS). The communication method includes: receiving a Radio Resource Control (RRC) release message from a network node, the RRC release message including configuration information for receiving a multicast inactive multicast radio bearer (MRB) for a multicast session in an RRC inactive state, the RRC release message causing the user equipment to transition to an RRC inactive state; attempting to receive a multicast session using the multicast inactive MRB based on pre-stored upper-layer information; and continuing the multicast reception process using the multicast inactive MRB when, as a result of the attempt, the multicast session reception is successful. Attached Figure Description

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

[0011] Figure 2 This is a configuration example diagram of a UE (User Equipment) according to an embodiment.

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

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

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

[0015] Figure 6 This is a diagram illustrating an example of operation of a mobile communication system according to an embodiment in a first operating mode.

[0016] Figure 7 This is a diagram illustrating an example of operation of a mobile communication system in a second operating mode according to an embodiment.

[0017] Figure 8 This is a diagram illustrating an example of operation of a mobile communication system in a third operating mode according to an embodiment.

[0018] Figure 9 This diagram illustrates the initial configuration process for connecting a UE. Detailed Implementation

[0019] A mobile communication system according to an embodiment is described with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.

[0020] (1) System configuration example

[0021] Figure 1 This diagram illustrates 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 the mobile communication system. Alternatively, a sixth-generation (6G) system can be applied at least partially to the mobile communication system.

[0022] 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 constitute network 5 of mobile communication system 1.

[0023] 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) and / 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), or flying objects and devices mounted on flying objects (airborne UE).

[0024] NG-RAN 10 includes base stations (referred to as "gNBs" in 5G systems) 200 as network nodes. 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 "frequency").

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

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

[0027] Figure 2 This diagram illustrates 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.

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

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

[0030] 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 processed in 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.

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

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

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

[0034] 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 in 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.

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

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

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

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

[0039] 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 transmission format (transmission block size, modulation and coding scheme (MCS)) in the uplink and downlink, as well as the resource blocks to be assigned to UE 100.

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

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

[0042] The SDAP layer performs the mapping between IP flows (as a unit of Quality of Service (QoS) 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.

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

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

[0045] 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 a connection (RRC connection) is not 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.

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

[0047] (2) Overview of MBS

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

[0049] (2.1) MBS broadcasting

[0050] 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 an MBS session type). UE100 can receive broadcast sessions in any state: RRC idle state, RRC inactive state, and RRC connected state.

[0051] Point-to-multipoint (PTM) transmission is suitable for broadcast communication services. For PTM transmission, the gNB 200 transmits a single copy of MBS packets to a group(s) of UE100. For example, the gNB 200 uses a cyclic redundancy code (CRC) to schedule a group common PDSCH scrambled by a group common PDC ...

[0052] For broadcast communication services, UE 100 receives broadcast sessions in the following process: First, UE 100 receives System Information Block Type 20 (SIB 20) from gNB 200. SIB 20 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 SIB 20. 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).

[0053] Note that MCCH is a PTM downlink channel used to transmit MBS broadcast control information associated with one or more MTCHs from network 5 to UE 100. MTCH is a PTM downlink channel used to transmit MBS data from network 5 to UE 100 for either multicast or broadcast sessions.

[0054] (2.2) MBS multicast

[0055] 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 an MBS session type).

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

[0057] 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, enhancements will be made to allow UE 100 in RRC inactive state to also receive multicast sessions.

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

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

[0060] 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).

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

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

[0063] 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 the multicast MCCH from gNB 200 based on SIBx. The multicast MCCH includes PTM configuration. The PTM configuration sends the configuration of the MTCH for receiving multicast sessions (MTCH configuration) and the configuration of the multicast inactive MRB as the MRB for receiving multicast sessions in an 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.

[0064] 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 pause 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 receives multicast sessions in the RRC inactive state (multicast reception procedure).

[0065] (2.2.3) Group notification

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

[0067] When a multicast session is activated by CN 20, the MBS-enabled gNB 200 notifies the UE 100, which is in an RRC idle or 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.

[0068] Upon receiving the 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 via the paging RNTI (P-RNTI) on the PDCCH, and UE 100 monitors the paging channel.

[0069] The paging message used for group notification includes a session identifier (MBS session ID) and is used 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.

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

[0071] Note that group notifications can be executed on the MCCH or via MCCH change notifications. When using the MCCH, this depends on whether an MTCH configuration for the interested MBS session exists within the MCCH. When using MCCH change notifications, the group notification can be executed within a predefined segment of the DCI.

[0072] (3) Operation of mobile communication systems

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

[0074] As described above, when gNB 200 sends an RRC release message (specifically, an RRC release message suspending configuration) to UE 100, which is in an RRC connected state, to cause UE 100 to transition to an RRC inactive state, the PTM configuration related to receiving multicast sessions in the RRC inactive state can be included in the RRC release message. The PTM configuration includes configuration information for the multicast inactive MRB used to receive multicast sessions in the RRC inactive state.

[0075] When this RRC release message is sent from gNB 200 to UE 100, the multicast session may not yet be active. UE 100 establishes a multicast inactive MRB with gNB 200 based on the PTM configuration included in the RRC release message and initiates the multicast session receive procedure (also known as the "multicast receive procedure").

[0076] However, even if UE 100 initiates the multicast reception process without activating the multicast session, UE 100 cannot receive the multicast session; specifically, it cannot receive multicast data sent on the MTCH. Therefore, UE 100 may still perform the multicast reception process even if it cannot receive the multicast data, thus wasting power.

[0077] The first to third operating modes for solving this problem will be described below. Each of the first to third operating modes can be executed independently, or two or more operating modes can be executed in combination.

[0078] (3.1) First operating mode

[0079] In the first operating mode, UE 100 receives an RRC release message from gNB 200. This RRC release message includes configuration information (multicast inactive MRB configuration) for receiving multicast sessions in the RRC inactive state, and causes UE 100 to transition to the RRC inactive state. UE 100 confirms whether to activate the state information regarding whether the RRC release message includes multicast session information (hereinafter referred to as "session state information"). When the RRC release message does not include session state information, UE 100 initiates a multicast reception procedure using the multicast inactive MRB configuration. That is, when the multicast inactive MRB is configured with an RRC release message, UE 100 can establish the multicast inactive MRB and initiate the MTCH reception procedure by immediately applying the configuration.

[0080] In this manner, in the first operating mode, the RRC release message may include session state information regarding whether a multicast session has been activated. Therefore, UE 100 can determine whether a multicast session is activated based on the session state information. Consequently, UE 100 can appropriately decide whether to immediately initiate the multicast reception procedure. Furthermore, when the RRC release message does not include this session state information, UE 100 considers the multicast session to be activated and can immediately initiate the multicast reception procedure.

[0081] In the first operating mode, when the RRC release message includes session state information and the session state information indicates that a multicast session has not yet been activated, UE 100 can suspend the initiation of the multicast reception process. Therefore, even if UE 100 cannot receive multicast data, it can prevent UE 100 from performing the multicast reception process and reduce the power consumption of UE 100. The session state information can be information indicating that a multicast session has not yet been activated. The session state information can also be information indicating that the multicast transmission process has been suspended (or interrupted). For example, the session state information can be information indicating that the initiation of the multicast reception process has been suspended (or interrupted). For example, the session state information can be information indicating that the reception of the MTCH (or multicast inactive MRB) for the multicast session will not be performed or will be suspended.

[0082] For example, when the multicast inactive MRB configuration includes information indicating that the multicast session is inactive, UE 100 may apply at least one selected from the group consisting of the following 1) through 3): 1) The multicast inactive MRB configuration is not applied. 2) The multicast inactive MRB is not established. 3) The MTCH reception procedure is not started.

[0083] In the first operating mode, when the RRC release message includes session state information that indicates a multicast session is already active, the UE 100 can initiate the multicast reception procedure. Therefore, since the UE 100 can immediately initiate the multicast reception procedure when a multicast session is already active, it can successfully receive multicast data. This session state information can be either information indicating a multicast session is already active or information indicating the initiation of the multicast reception procedure.

[0084] In the first operating mode, session state information can be associated with a group discontinuous reception (DRX) configuration to be applied to receiving one or more multicast sessions. That is, session state information can be configured for each group DRX configuration.

[0085] In the first operating mode, the multicast inactive MRB configuration may include the configuration of each of a plurality of multicast inactive MRBs. Session state information may include information indicating that all of the plurality of multicast inactive MRBs are inactive and / or information indicating that at least one of the plurality of multicast inactive MRBs is active. For example, session state information may be information indicating that at least one multicast session is active.

[0086] Figure 6 This is a diagram illustrating an example of the operation of the mobile communication system 1 in its first operating mode.

[0087] In step S101, UE 100 is in RRC connected state in the cell of gNB 200. It is assumed that UE 100 has already joined a multicast session. UE 100 may have joined multiple multicast sessions.

[0088] Assume gNB 200 knows the multicast sessions that UE 100 has joined and whether each multicast session is active. gNB 200 decides to perform receive configuration on UE 100 for the multicast sessions that UE 100 is joining while in RRC inactive.

[0089] In step S102, gNB 200 sends an RRC release message including the multicast inactive MRB configuration to UE 100. UE 100 receives the RRC release message.

[0090] The multicast inactive MRB configuration includes the MRB ID of the multicast inactive MRB to be configured and / or the MBS session ID of the multicast sessions to be sent in the multicast inactive MRB. The MBS session ID can be a Temporary Mobile Group Identifier (TMGI). Note that when the UE100 joins multiple multicast sessions, the multicast inactive MRB configuration may include multiple MRB IDs and / or multiple MBS session IDs corresponding to multiple multicast sessions. The multicast inactive MRB configuration may include group DRX configuration for configuring group DRX.

[0091] In the first operating mode, the multicast inactive MRB configuration includes at least one selected from the group consisting of a) to c).

[0092] a) Information indicating that each multicast session (MBS session ID) or each MRB (MRB ID) is inactive. Alternatively, information indicating that each multicast session or each MRB is active. In this way, session state information can be associated with a multicast session or MRB.

[0093] b) Information indicating that each group DRX configuration is inactive. Alternatively, information indicating that each DRX group configuration is active. This information can be associated with the DRX group's ID (index). In this way, session state information can be associated with group DRX configurations.

[0094] c) Information indicating that all multicast sessions are inactive. Alternatively, information indicating that at least one multicast session is active. Here, "all multicast sessions" can refer to all multicast sessions in the case where UE 100 joins multiple multicast sessions. "All multicast sessions" can refer to all MBS session IDs included in the multicast inactivity MRB configuration.

[0095] In a) through c) above, the information indicating an inactive state is information indicating a pause in the multicast reception process, and can be any of the following:

[0096] -Indicates that the multicast inactive MRB configuration has been retained but not applied;

[0097] - This indicates that a multicast inactive MRB configuration has been applied but the multicast inactive MRB has not been established;

[0098] - This indicates that a multicast inactive MRB was established by applying the multicast inactive MRB configuration and that the MTCH reception process was not performed;

[0099] - This indicates that multicasting of inactive MRBs has been suspended.

[0100] In a) through c) above, the information indicating an inactive state is the information indicating the initiation of the multicast reception process, and can be any of the following:

[0101] - Indicates that multicast inactive MRB configuration has been applied;

[0102] - Indicates that a multicast inactive MRB has been established;

[0103] - Information indicating that the MTCH receive process has been executed.

[0104] In step S103, UE 100 confirms whether the multicast session it is joining has been activated based on the session state information included in the RRC release message in step S102. UE 100 can also confirm whether to initiate the multicast reception process for the multicast session it is joining based on the session state information included in the RRC release message in step S102. The multicast reception process is the process of establishing a multicast inactive MRB by applying a multicast inactive MRB configuration and receiving the MTCH associated with the multicast inactive MRB.

[0105] When the multicast session that UE 100 is joining has not yet been activated (step S103: No), UE 100 suspends the initiation of the multicast reception procedure for the multicast session. Then, in step S104, UE 100 transitions to an RRC inactive state in response to receiving the RRC release message in step S102. In this case, UE 100 in the RRC inactive state can monitor the aforementioned group notification, and when the group notification indicates that the multicast session that UE 100 itself is joining has been activated, it can initiate the multicast reception procedure based on the multicast inactive MRB configuration in step S102.

[0106] On the other hand, when the multicast session that UE 100 is joining is already activated (step S103: Yes), in step S105, UE 100 initiates the multicast reception procedure and establishes a multicast inactive MRB by applying the multicast inactive MRB configuration received in step S102. In step S106, UE 100 transitions to an RRC inactive state in response to receiving the RRC release message in step S102. In step S107, UE 100 uses the established multicast inactive MRB to receive the multicast session (multicast data) on the MTCH from gNB 200. Note that the order of steps S105 and S106 can be reversed.

[0107] (3.2) Second operating mode

[0108] The second operating mode will be described in terms of its differences from the first operating mode described above.

[0109] The second operating mode is an operating mode that does not require the aforementioned session state information. Specifically, in the second operating mode, UE 100 determines whether to start or pause the multicast reception process using the multicast inactive MRB configuration received via the RRC release message based on the reception status of the multicast session (multicast MRB) under the RRC connection state. That is, UE 100, having received the RRC release message including the multicast inactive MRB configuration, determines whether the multicast session sent using the configured multicast inactive MRB is active based on whether the multicast MRB under the RRC connection state has been configured.

[0110] For example, in the second operating mode, UE 100, in RRC connected state, uses a multicast MRB to receive multicast sessions. UE 100 receives an RRC release message from gNB 200, including the configuration of a multicast inactive MRB, and transitions UE 100 to an RRC inactive state. Here, UE 100 confirms whether a multicast inactive MRB corresponding to the multicast MRB used in RRC connected state has been configured. If a multicast inactive MRB corresponding to the multicast MRB used in RRC connected state has been configured, UE 100 initiates a multicast reception procedure using the multicast inactive MRB.

[0111] Note that the multicast inactive MRB corresponding to the multicast MRB used in the RRC connection state can be a multicast inactive MRB that has a common MBS session ID with the multicast MRB, or it can be a multicast inactive MRB that has a common MRB ID with the multicast MRB.

[0112] In the second operating mode, when a multicast inactive MRB that does not correspond to the multicast MRB used in the RRC connection state has been configured, the UE 100 can pause the start of the multicast reception process.

[0113] Figure 7 This is a diagram illustrating an example of the operation of the mobile communication system 1 in a second operating mode.

[0114] In step S201, UE 100 is in RRC connected state in the cell of gNB 200. It is assumed that UE 100 has already joined a multicast session. UE 100 may have joined multiple multicast sessions.

[0115] In step S202, gNB 200 may send an RRC reconfiguration message to UE 100, including the multicast MRB configuration of the RRC connection state. UE 100 may receive the RRC reconfiguration message.

[0116] In step S203, UE 100 can establish a multicast MRB based on the multicast MRB configuration in step S202.

[0117] In step S204, gNB 200 uses the multicast MRB to send a multicast session (multicast data) to UE 100 on the MTCH. UE 100 uses the multicast MRB to receive the multicast session.

[0118] In step S205, gNB 200 sends an RRC release message including the multicast inactive MRB configuration to UE 100. UE 100 receives the RRC release message.

[0119] The multicast inactive MRB configuration includes the MRB ID of the multicast inactive MRB to be configured and / or the MBS session ID of the multicast session to be sent via the multicast inactive MRB. The MBS session ID may be a Temporary Mobile Group Identifier (TMGI). Note that when the UE100 joins multiple multicast sessions, the multicast inactive MRB configuration may include multiple MBS session IDs and / or multiple MRB IDs corresponding to the multiple multicast sessions. The multicast inactive MRB configuration may include group DRX configuration for configuring group DRX.

[0120] In step S206, UE 100 confirms whether the multicast inactive MRB configured in step S205 corresponds to a multicast MRB used in the RRC connection state. For example, UE 100 confirms whether a multicast MRB whose MBS session ID is shared by the multicast inactive MRB configured in step S205 has already been used in the RRC connection state. Alternatively, UE 100 may confirm whether a multicast MRB whose MRB ID is shared by the multicast inactive MRB configured in step S205 has already been used in the RRC connection state. Note that when multiple multicast inactive MRBs are configured in step S205, this confirmation can be performed for each MBS session ID or each MRB ID corresponding to the multiple multicast inactive MRBs.

[0121] When the multicast inactive MRB configured in step S205 does not correspond to the multicast MRB used in the RRC connection state (step S206: No), UE 100 considers the multicast session sent via the multicast inactive MRB to be in an inactive state and suspends the initiation of the multicast reception process for the multicast session. In step S207, UE 100 transitions to the RRC inactive state in response to receiving the RRC release message in step S205. In this case, UE 100 in the RRC inactive state can monitor the aforementioned group notification, and when, based on the group notification, it specifies that a multicast session that UE 100 itself is joining has been activated, it can initiate the multicast reception process based on the multicast inactive MRB configuration in step S205.

[0122] On the other hand, when the multicast inactive MRB configured in step S205 corresponds to the multicast MRB used in the RRC connection state (step S206: Yes), in step S208, UE 100 considers the multicast session sent through the multicast inactive MRB to be active and initiates the multicast reception process. UE 100 applies the multicast inactive MRB configuration received in step S205 to establish the multicast inactive MRB. In step S209, UE 100 transitions to the RRC inactive state in response to receiving the RRC release message in step S205. In step S210, UE 100 uses the established multicast inactive MRB to receive the multicast session (multicast data) on the MTCH from gNB 200. Note that the order of steps S208 and S209 can be reversed.

[0123] (3.3) Third operating mode

[0124] The third operating mode will be described by focusing on its differences from the first and second operating modes described above.

[0125] Similar to the second operating mode, the third operating mode is an operating mode that does not require the aforementioned session state information. In the third operating mode, the UE 100, having received an RRC release message including the multicast inactive MRB configuration, determines whether the multicast session sent by the configured multicast inactive MRB is active based on pre-stored upper-layer information.

[0126] Upper-layer information is information managed by the upper layer. The upper layer can represent a layer higher than the AS layer, and can be, for example, the application layer or NAS layer. Upper-layer information can be a User Service Description (USD). The USD can be provided to the UE 100 from the upper-layer server. The USD includes information about the start time of each MBS session (also referred to as "session start time information"). Therefore, the UE 100 can determine whether a multicast session sent using the configured multicast inactive MRB is active based on the current time when it receives an RRC release message including the multicast inactive MRB configuration and the session start time information included in the upper-layer information (USD).

[0127] However, there is a possibility that the information in the USD may be coarse or outdated. For example, for a certain multicast session, even if the USD is set to "start the session at 11:00", the following situation may occur: in network 5 of mobile communication system 1, the transmission is actually started (activated) at 11:05. Even if the transmission is planned to start at 11:00, the actual start of the transmission may be delayed due to congestion in network 5, etc. Therefore, in the third operating mode, UE 100 attempts to perform the multicast reception process based on upper-layer information and determines whether to continue multicast reception. Specifically, UE 100 attempts to use upper-layer information to receive the MTCH with a configured multicast inactive MRB and determines whether to continue receiving the multicast session.

[0128] In the third operating mode, UE 100 receives an RRC release message from gNB 200, including the multicast inactive MRB configuration, and transitions UE 100 to an RRC inactive state. Based on pre-stored upper-layer information, UE 100 attempts to receive a multicast session using the multicast inactive MRB. If the multicast session reception is successful as a result of the attempt, UE 100 continues the multicast reception process using the multicast inactive MRB. Conversely, if the multicast session reception fails as a result of the attempt, UE 100 stops the multicast reception process.

[0129] In the third operating mode, UE 100 performs multicast reception attempts within a specific time period. This specific time period is configured for UE 100 by gNB 200. That is, the period used to determine whether to continue multicast reception can be configured by gNB 200.

[0130] Figure 8 This is a diagram illustrating an example of the operation of the mobile communication system 1 in the third operating mode.

[0131] In step S301, UE 100 is in RRC connected state in the cell of gNB 200. It is assumed that UE 100 has already joined a multicast session. UE 100 may have joined multiple multicast sessions.

[0132] In step S302, the AS layer of UE 100 obtains the session start time information of the multicast session from the upper layer. For example, the USD information is notified to the AS from the upper layer.

[0133] In step S303, gNB 200 sends an RRC release message including the multicast inactive MRB configuration to UE 100. UE 100 receives the RRC release message.

[0134] The multicast inactive MRB configuration includes the MRB ID of the multicast inactive MRB to be configured and / or the MBS session ID of the multicast sessions to be sent in the multicast inactive MRB. The MBS session ID may be a Temporary Mobile Group Identifier (TMGI). Note that when the UE100 joins multiple multicast sessions, the multicast inactive MRB configuration may include multiple MBS session IDs and / or multiple MRB IDs corresponding to the multiple multicast sessions. The multicast inactive MRB configuration may include group DRX configuration for configuring group DRX.

[0135] In step S304, UE 100 establishes a multicast inactive MRB by applying the multicast inactive MRB configuration received in step S303. Here, based on upper-layer information (session start time information), UE 100 can only establish a multicast inactive MRB if the current time is after the session start time. If the current time is before the session start time, UE 100 can establish a multicast inactive MRB after transitioning to the RRC inactive state (step S309) and perform a multicast reception attempt.

[0136] In step S305, UE 100 attempts to receive MTCH (multicast session) using the multicast inactive MRB established in step S304.

[0137] In step S305, UE 100 determines whether the multicast reception (MTCH) attempt was successful. If the MTCH cannot be received normally within a specific time period, UE 100 considers the multicast reception attempt unsuccessful. gNB 200 can configure a specific time period in UE 100 using an SIB or RRC release message (step S303). When UE 100 joins multiple multicast sessions, a specific time period can be configured for each MBS session ID (MRB).

[0138] When it is determined that the multicast reception attempt is unsuccessful (step S306: No), in step S307, UE 100 stops the multicast reception process (MTCH reception process). UE 100 may consider the multicast session sent using the established multicast inactive MRB to be in an inactive state and may suspend the multicast inactive MRB. In this case, after transitioning to the RRC inactive state (step S309), UE 100 may monitor the aforementioned group notification, and when, based on the group notification, it specifies that a multicast session that UE 100 itself is joining has been activated, UE 100 may initiate the multicast reception process based on the multicast inactive MRB configuration in step S303.

[0139] On the other hand, when it is determined that the multicast reception attempt is unsuccessful (step S306: Yes), in step S308, UE 100 considers that the multicast session sent using the established multicast inactive MRB is in an inactive state and continues the multicast reception process (MTCH reception process).

[0140] In step S309, UE 100 transitions to an RRC inactive state in response to receiving the RRC release message in step S303.

[0141] In this operational example, after UE 100 receives the RRC release message in step S303, UE 100 can transition to an RRC inactive state before step S304. UE 100 can transition to an RRC inactive state before step S305. UE 100 can transition to an RRC inactive state before step S306.

[0142] (4) Other embodiments

[0143] 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. For the RRC idle state, the aforementioned RRC Resume can be read as RRC Establishment.

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

[0145] Although an example of 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 terminal (MT) of an IAB node.

[0146] That is, UE 100 can be a terminal functional unit (a communication module) of a repeater used for base station control execution signal relay. Such a terminal functional unit is called MT. In addition to IAB-MT, examples of MT include Network Control Repeater (NCR)-MT and Reconfigurable Smart Surface (RIS)-MT.

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

[0148] A program may be provided that enables a computer to perform each process executed by UE 100 or gNB 200. This program may be recorded on a computer-readable medium. The computer-readable medium allows the program to be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and may, for example, be a recording medium such as a CD-ROM or DVD-ROM. Circuitry for performing the processes executed by UE 100 or gNB 200 may be integrated, and at least a portion of UE 100 or gNB 200 may be implemented as a semiconductor integrated circuit (chipset, system-on-chip (SoC)).

[0149] The functions implemented by UE 100 and gNB 200 (network nodes) can be implemented in circuitry or processing circuitry programmed to perform the functions, including general-purpose processors, application-specific processors, integrated circuits, application-specific integrated circuits (ASICs), central processing units (CPUs), conventional circuitry, and / or combinations thereof. A processor may include transistors and other circuitry and may be considered as a circuit or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. As used herein, a circuit, unit, or device is hardware programmed to implement the functions or hardware that performs 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, device, or unit is a combination of the hardware and software used to configure the hardware and / or the processor.

[0150] 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 “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.

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

[0152] This application claims priority to U.S. Provisional Patent Application No. 63 / 530315 (filed August 2, 2023), the entire contents of which are incorporated herein by reference.

[0153] (5) First supplementary note

[0154] The features related to the above embodiments are described below as supplementary notes.

[0155] Supplementary Note 1

[0156] A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising:

[0157] Receive a Radio Resource Control (RRC) release message from a network node. The RRC release message includes configuration information for receiving multicast inactive multicast radio bearers (MRBs) of multicast sessions in an RRC inactive state. The RRC release message causes the user equipment to switch to an RRC inactive state.

[0158] Confirm whether the RRC release message includes status information regarding whether a multicast session has been activated; and

[0159] When the RRC release message does not include status information, a multicast reception process using a multicast inactive MRB is initiated based on the configuration information.

[0160] Supplementary Note 2

[0161] The communication method described in Supplementary Note 1 further includes: when the RRC release message includes status information and the status information indicates that a multicast session has not yet been activated, pausing the multicast reception process.

[0162] Supplementary Note 3

[0163] According to the communication method described in Supplementary Note 2, the status information is information indicating that the multicast reception process has been paused.

[0164] Supplementary Note 4

[0165] The communication method according to any one of Supplementary Notes 1 to 3 further includes: initiating a multicast reception process when the RRC release message includes status information and the status information is information indicating that a multicast session has been activated.

[0166] Supplementary Note 5

[0167] According to the communication method described in Supplementary Note 4, the status information is information that indicates the initiation of the multicast reception process.

[0168] Supplementary Note 6

[0169] According to any one of the supplementary notes 1 to 5, in the communication method, the status information is associated with a group discontinuous reception (DRX) configuration to be applied to receive one or more multicast sessions.

[0170] Supplementary Note 7

[0171] According to any one of Supplementary Notes 1 to 6, in the communication method, wherein,

[0172] This configuration information includes the configuration of multiple multicast inactive MRBs, and

[0173] The status information includes at least one of the following: information indicating that all of the multiple multicast inactive MRBs are inactive and information indicating that at least one of the multiple multicast inactive MRBs is active.

[0174] Supplementary Note 8

[0175] A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising:

[0176] In Radio Resource Control (RRC) connection status, multicast radio bearers (MRBs) are used to receive multicast sessions;

[0177] Receive an RRC release message from the network node. The RRC release message includes configuration information for receiving multicast inactive MRBs for multicast sessions in an RRC inactive state. The RRC release message causes the user equipment to switch to an RRC inactive state.

[0178] Confirm whether a multicast inactive MRB corresponding to the multicast MRB is configured; and

[0179] When a multicast inactive MRB corresponding to a multicast MRB is configured, the multicast reception process using the multicast inactive MRB is started.

[0180] Supplementary Note 9

[0181] According to the communication method described in Supplementary Note 8, the multicast inactive MRB corresponding to the multicast MRB is either a multicast inactive MRB that has a common MBS session ID with the multicast MRB or a multicast inactive MRB that has a common MRB ID with the multicast MRB.

[0182] Supplementary Note 10

[0183] The communication method described in Supplementary Note 8 or 9 further includes: when a multicast inactive MRB that does not correspond to a multicast MRB is configured, pausing the start of the multicast reception process.

[0184] Supplementary Note 11

[0185] A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising:

[0186] Receive a Radio Resource Control (RRC) release message from a network node. The RRC release message includes configuration information for receiving multicast inactive multicast radio bearers (MRBs) of multicast sessions in an RRC inactive state. The RRC release message causes the user equipment to switch to an RRC inactive state.

[0187] Based on pre-stored upper-layer information, an attempt is made to receive multicast sessions using a multicast inactive MRB; and

[0188] If the multicast session is successfully received as a result of the attempt, the multicast inactive MRB will continue to be used for the multicast reception process.

[0189] Supplementary Note 12

[0190] The communication method described in Supplementary Note 11 further includes: stopping the multicast reception process when the multicast session reception fails as a result of the attempt.

[0191] Supplementary Note 13

[0192] According to the communication method described in Supplementary Note 11 or 12, wherein,

[0193] During the attempt, the user device performs the attempt within a specific time period, and

[0194] The specific time period is configured by the network node in the user equipment.

[0195] (6) Second Supplement

[0196] 1. Introduction

[0197] The work project regarding the enhancement of MBS (eMBS) aims to support multicast reception by inactive UEs and is described as follows:

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

[0199] - PTM configuration for UEs receiving multicast in RRC inactive state [RAN2].

[0200] - Investigate the impact of UEs receiving multicast in RRC inactive state on mobility and state transition (without seamless / lossless mobility) [RAN2, RAN3].

[0201] RAN2 has already discussed this objective and reached a series of protocol terms. Based on these protocol terms, the control plane aspects for multicast reception in inactive states are discussed in the supplementary notes.

[0202] 2. Discussion

[0203] 2.1 Initial configuration process for connecting the UE

[0204] RAN2#120 has reached an agreement to advance the "hybrid approach".

[0205] -The mixing method is as follows:

[0206] 1. When the NW configures the UE to continue multicast reception in an inactive state, the NW provides the PTM configuration of the activated multicast session to at least one serving cell via RRC dedicated signaling (other cases require further study).

[0207] [ ]

[0208] 3. Assume that the UE can receive multicast services after joining the session.

[0209] RAN2#121 agrees with the following description.

[0210] - The UE needs to join a multicast session before receiving multicast in the RRC inactive state.

[0211] When the network determines that the PTM configuration of a (single) serving cell is useful, the network can use that PTM configuration to configure the UE before session activation, and the UE can store the configuration. When the session is activated, the UE can apply the configuration to receive multicast in an inactive state without returning to the RRC connection state, unless the configuration is updated by the MCCH afterward.

[0212] - When the network configures the UE to receive multicast in an inactive state, the PTM configuration can be delivered using an RRC release message that includes suspendconfig. No other dedicated RRC messages are used to provide the PTM configuration for MBS multicast in an inactive state.

[0213] - A new MCCH logical channel (different from the broadcast MCCH) has been introduced for multicast in inactive states.

[0214] - Provide multicast MCCH configuration via the new SIB.

[0215] - Alternatively, a multicast MCCH configuration for the serving cell can also be provided in dedicated signaling. Therefore, it is not optimized for mobility.

[0216] RAN2#122 agrees with the following description.

[0217] - The multicast MCCH configuration uses the broadcast MCCH configuration structure (mcch-Config-r17) as a baseline.

[0218] - To provide notification of changes to the multicast MCCH, the version 17 broadcast MCCH change notification mechanism became the baseline.

[0219] - The PTM configuration for multicast MCCH uses the broadcast PTM configuration of version 17 as a benchmark.

[0220] - Basically, the PTM configuration including the RRC release message of suspendconfig has the same structure as the PTM configuration of multicast MCCH.

[0221] Based on these protocol terms and the currently running CR, the configuration process for connecting the UE for ongoing (i.e., activated) multicast sessions and deactivation (i.e., before activation) multicast sessions can be considered as follows: Figure 9 Same.

[0222] For ongoing multicast sessions, the UE reconfigures the multicast MRB for multicast reception in the connected state via RRC and begins receiving the MTCH, as in version 17. For inactive multicast reception, the UE is configured using the multicast inactive MRB. This is considered similar to the broadcast MRB released via RRC in version 17.

[0223] First, it should be clarified that the multicast inactive MRB described in the ongoing CR has the same characteristics as the version 18 broadcast MRB, but it is a different MRB from the version 17 broadcast MRB or the version 17 multicast MRB.

[0224] Recommendation 1: RAN2 needs to confirm that the multicast inactive MRB has similar functionality to the version 17 broadcast MRB, but it is a new MRB for multicast reception in inactive states.

[0225] Clearly, at least for ongoing multicast sessions, once the UE is released from the RRC configuration, the multicast inactive MRB must be applied and established immediately.

[0226] Recommendation 2: RAN2 should agree that when a UE is configured by RRC release, a multicast inactive MRB should be established immediately for at least the ongoing multicast session.

[0227] On the other hand, in a deactivated multicast session, the UE performs PTM configuration via RRC release. If recommendation 2 above is agreed upon, the UE will immediately begin receiving MTCH, but since no MTCH is being sent at this time, the UE should avoid doing so. Instead, the UE needs to provide notification via RRC release that the multicast session is still inactive, allowing the UE to wait for a multicast session activation notification without performing MTCH reception. Since the session state (i.e., active or deactivated) is different for each multicast session, the deactivation indication should be tailored to each TMGI notification. Further research is needed on the detailed operation. For example, it is necessary to investigate whether to apply PTM configuration but wait for session activation.

[0228] Recommendation 3: RAN2 should agree to notify the UE via RRC release whether each multicast session has been "deactivated" so that the UE does not attempt to receive the corresponding MTCH.

[0229] After transitioning to an inactive state, the UE monitors for multicast session activation notifications (i.e., group paging). Prior to multicast session activation, there is a possibility that the gNB will change the session's PTM configuration, which is configured by the multicast MCCH of the inactive UE.

[0230] From the UE's perspective, power consumption increases when the UE needs to monitor the multicast MCCH of a deactivated multicast session. Therefore, the UE needs to confirm that it does not need to monitor the multicast MCCH before receiving a multicast session activation notification. In other words, the UE can monitor the multicast MCCH only when it receives an activation notification with an interest TMGI. The same operation can also be applied to new SIBs for multicast MCCH configuration (e.g., SIB 20).

[0231] Recommendation 4: RAN2 should agree that when the corresponding multicast session is deactivated (i.e., before receiving a multicast session notification), the UE does not need to monitor the "Multicast MCCH" or the new SIB (SIB 20, etc.).

[0232] Upon receiving a multicast activation notification, if the MCCH configuration and / or PTM configuration are provided from the RRC release, the UE needs to check whether the MCCH configuration in the new SIB and / or the PTM configuration in the multicast MCCH have been updated. If the configuration has not been updated, the stored configuration, i.e., the configuration provided by the RRC release, should be applied. Of course, if the configuration has been updated, the UE needs to acquire the new SIB and / or multicast MCCH.

[0233] For the new SIB, the UE is expected to know whether the new SIB has been updated by checking the value tag of SIB1, as is currently the case. On the other hand, the UE cannot know whether the multicast MCCH has been updated before receiving and decoding it. In this case, even if the configuration is completed via RRC release, the UE still needs to decode the multicast MCCH once, which is meaningless. In this sense, in order for the UE to know the PTM configuration update without decoding the multicast MCCH, a value tag needs to be introduced into the multicast MCCH. Further research is needed regarding where the multicast MCCH value tag will be located: the new SIB, SIB1, or group paging.

[0234] Recommendation 5: RAN2 should agree to introduce a multicast MCCH value label. The UE uses this multicast MCCH value label to know whether the PTM configuration has been updated from the PTM configuration released by RRC without decoding the multicast MCCH itself.

[0235] 2.2. Initial configuration process for inactive UEs

[0236] RAN2#120 agrees to use multicast MCCH when updating PTM configuration.

[0237] - The mixing method is as follows.

[0238] 1. When the NW configures the UE to continue multicast reception in an inactive state, the NW provides the PTM configuration of the activated multicast session to at least one serving cell via RRC dedicated signaling (other cases require further study).

[0239] 2. The MCCH is used when the PTM configuration needs to be changed or when the PTM configuration needs to be indicated during migration outside the serving cell / gNB. Changes in session state and other indications require further investigation.

[0240] [ ]

[0241] In RAN2#121bis-e, it is agreed that RRC connections can be restored when the UE does not have PTM configuration. That is, in order to obtain PTM configuration, the UE needs to be switched to connected state.

[0242] - When events such as session activation / data transmission recovery occur, the UE begins to restore the RRC connection if the UE is not configured with PTM.

[0243] The original interpretation of the protocol item is the concept of a "hybrid approach," therefore the initial PTM configuration should always be provided by dedicated signaling, and the PTM configuration can be updated by multicast MCCH. However, the CR of the currently running TS 38.300 is considered an item requiring further investigation.

[0244] Note: Whether the UE can obtain the initial PTM configuration via multicast MCCH requires further investigation.

[0245] When the UE is allowed to obtain the initial PTM configuration via multicast MCCH, it is exactly the same as version 17 Transport Mode 2 (Transport Mode 2) (i.e., for broadcast MBS sessions). Previous discussions regarding the RAN2 protocol for the hybrid approach have shown that version 17 Transport Mode 2 is unacceptable for MBS multicast in some deployments. It is not expected to repeat the same discussions prior to the consensus on the hybrid approach; therefore, the version 18 mechanism should take deployment assumptions into account.

[0246] Observation 1: As discussed previously, UEs are not allowed to obtain the initial PTM configuration via multicast MCCH based on the deployment.

[0247] However, in practical applications, version 17 transmission mode 2 is essentially the same as LTE eMBMS / SC-PTM capable of handling MBMS multicast sessions. Therefore, MBS multicast sessions via transmission mode 2 can also be applied to some other deployment scenarios. Furthermore, most current implementations of version 17 transmission mode 2 are reused for receiving version 18 multicast in inactive states when initial PTM configuration is allowed via the multicast MCCH. Depending on the NW implementation, the signaling overhead of broadcast signaling (i.e., multicast MCCH) can be reduced compared to dedicated signaling (i.e., RRC release). Therefore, this option is worth investigating. In fact, in the CR of the currently operating TS 38.331, the UE can obtain the initial PTM configuration from the multicast MCCH because the same PTM configuration (MBSMulticastConfiguration) is captured in both the multicast MCCH and RRC release.

[0248] Observation 2: According to LTE eMBMS / SC-PTM, the UE can also obtain the initial PTM configuration via multicast MCCH in some other deployments.

[0249] Considering these observations, an enhanced hybrid approach should be investigated to support all deployment assumptions in an efficient and flexible manner. In practice, this can be achieved with a very simple solution. RRC release can indicate whether the UE is allowed to obtain the initial PTM configuration from the multicast MCCH. In this solution, when this indication is not set, the UE simply follows the current protocol. That is, the initial PTM configuration is always provided by dedicated signaling, and the UE resumes the RRC connection when needed. When this indication is configured, the UE can obtain the initial PTM configuration from the multicast MCCH even when it does not have a PTM configuration.

[0250] Recommendation 6: RAN2 should agree that the gNB can indicate whether the UE needs to obtain the initial PTM configuration from the multicast MCCH through RRC release.

[0251] 2.3. Configuration Updates During Inactivity

[0252] In version 17, one MCCH existed in the cell. In version 18, RAN2 agreed to "introduce a new MCCH logical channel (different from the broadcast MCCH) for multicast in inactive states." The multicast MCCH is used when the PTM configuration needs to be changed or when the PTM configuration needs to be indicated during migration outside the serving cell / gNB.

[0253] Observation 3: Multicast MCCH is used to update the PTM configuration of UEs that are inactive.

[0254] That is, in version 18 networks, there are two MCCHs: the (broadcast) MCCH and the multicast MCCH. The reason for introducing a separate MCCH in a cell is believed to be to handle the different service requirements for each propagation type (MBS broadcast and MBS multicast).

[0255] The question is whether different multicast sessions have different service requirements. The service requirements for group multimedia call service and firmware download service are quite different. For example, since group multimedia call service is a foreground service, it requires frequent optimization of the PTM configuration, while firmware download service is a background service and therefore does not require such frequent optimization. Considering that the initial PTM configuration is provided by RRC release, some services need to update the PTM configuration via multicast MCCH, while others do not. In this sense, introducing multiple multicast MCCHs is efficient for the UE and flexible for the network.

[0256] Recommendation 7: RAN2 should discuss whether to introduce multiple multicast MCCHs for each cell.

[0257] 2.4. UE Mobility and Service Continuity

[0258] 2.4.1. Frequency Prioritization

[0259] RAN2#121bis-e agrees that further research is needed on UE operations during cell reselection.

[0260] - Similar to the broadcast reception process in version 17, the UE obtains the new SIB and multicast MCCH after cell reselection, and also obtains the PTM configuration.

[0261] - When a UE reselects a cell where PTM configuration cannot be used in the multicast MCCH, the UE initiates an RRC recovery procedure for the active multicast session that is interested in receiving or continuing to receive.

[0262] - Frequency prioritization can be provided to the UE for cell reselection of multicast reception in RRC inactive state, but further research is needed on the detailed mechanism of how to identify frequency information (e.g., SAI, USD, or frequency information directly provided from the network).

[0263] - No mechanism other than frequency prioritization (i.e., cell prioritization during cell reselection) needs to be defined to allow the UE to select the appropriate cell.

[0264] The neighbor cell list mechanism for multicast reception in the inactive state of RRC is similar in some respects to the version 17 NCL mechanism in MBS broadcast, but can be configured by the UE to restore the RRC connection when NCL cannot provide services in the reselected cell, for example, without having to read the MCCH in the reselected cell.

[0265] For frequency information, the upper layer can provide this information, for example, via the USD. However, considering the decision on NR MBS transmission for each cell, the RAN also needs to provide frequency information (where possible), because the USD can only provide static information (especially for inactive UEs), while the RAN can have the most up-to-date information. Therefore, as with SIB 21 broadcast in version 17 MBS, the gNB can broadcast frequency information so that the UE prioritizes the appropriate frequency during cell reselection.

[0266] Recommendation 8: RAN2 should agree that frequency information should be broadcast by gNB.

[0267] 2.4.2. Area Scope of PTM Configuration

[0268] In RAN2#121 and RAN2#122, the regional scope of multicast MCCH and the configuration of multicast MCCH in adjacent cells are discussed. Some companies have suggested enhancing service continuity during UE migration by enabling PTM configuration in multiple cells. In the case within a gNB, the PTM configuration of each cell can be easily aligned (if needed), but in the case between gNBs, it is difficult to align the PTM configuration of each cell and negotiation with the Xn-AP is required.

[0269] RAN2 agrees with the following description.

[0270] - The serving cell does not receive PTM configurations for neighboring cells from other gNBs.

[0271] - Further research is needed to determine whether the network can provide PTM configuration to cells in the gNB.

[0272] Providing neighboring cell PTM configuration in gNB via dedicated signaling is not supported.

[0273] These protocols are confusing regarding what has been excluded. Clearly, the serving cell does not provide MBSMulticastConfiguration for neighboring cells; that is, the serving cell only provides its own MBSMulticastConfiguration. However, it is unclear whether serving cells that indicate the regional scope of MBSMulticastConfiguration are excluded (e.g., the serving cell's PTM configuration is valid across multiple cells). For example, the serving cell's PTM configuration is valid across multiple cells. The latter extension would have much less signaling overhead (e.g., simply adding to the cell list) and would not cause harm when limited to the case within the gNB (i.e., no impact on Xn). Therefore, RAN2 needs to discuss whether the PTM configuration can be applied to multiple cells within the gNB.

[0274] Recommendation 9: RAN2 should agree that the serving cell can indicate the area range of MBSMulticastConfiguration (e.g., a list of applicable cells).

[0275] 2.4.3. QoS Execution

[0276] RAN2#119e has reached the following agreement regarding situation 3.

[0277] Multicast reception in RRC inactive state does not support HARQ feedback and PTP.

[0278] According to the protocol, multicast reception in an inactive state is similar to MBS broadcast reception (so-called transmission mode 2) as defined in version 17. MBS broadcast is of the best-effort type.

[0279] On the other hand, ensuring QoS / reliability is a critical task for multicast sessions. SA2 also questioned whether there are differences in the quality / reliability of multicast reception in connected and inactive states, and RAN2#119bis-e has reached an agreement on the following response.

[0280] -RAN2 Q1-a) In cases where there is a significant difference in the quality and reliability of MBS data reception between a UE in RRC connected state and a UE in RRC inactive state:

[0281] Because HARQ feedback and PTP transmission are not supported and multicast reception in RRC inactive state does not require seamless / lossless mobility, there may be differences in MBS data reception quality and reliability between UEs in RRC connected state and UEs in RRC inactive state.

[0282] RAN2#121bis-e agrees to introduce an event-triggered RRC recovery mechanism, but the triggering conditions require further investigation.

[0283] - When the quality of multicast data reception is lower than the set threshold, there is a possibility that the UE will trigger the restoration of the RRC connection.

[0284] RAN2#119e has proposed introducing thresholds for receive quality such as RSRP and / or BLER, which are considered to be used to ensure a certain level of QoS requirements for multicast reception.

[0285] Regarding the RSRP threshold, NR MBS assumes a single-cell transmission method, and the threshold is related to SSB or CSI-RS, rather than directly to MTCH. Therefore, whenever a UE moves to the cell edge or performs cell reselection, the UE will always be considered to need to transition to a connected state. From the perspective of network congestion or UE energy saving, this may not be optimal in some deployments (e.g., single-frequency networks). On the other hand, RSRP is one of the fundamental metrics used to evaluate reception quality and is one of the commonly used metrics when the gNB decides to perform a handover (i.e., due to the RSRP threshold, a handover is performed after the UE transitions to a connected state). In other words, RSRP is a suitable measurement reference for monitoring reception quality.

[0286] The BLER threshold is considered easy to understand for directly monitoring the quality of the MTCH and ensuring QoS requirements. Therefore, BLER is worth defining as a metric.

[0287] Another approach is to define specific events. For example, when configuring a cell reselection event, the UE must always transition to the connected state before the cell reselection. However, there is a possibility that the aforementioned RSRP threshold will simulate such an event. Therefore, careful consideration is needed when defining events as triggering conditions in RAN2.

[0288] In summary, for event-triggered RRC recovery, at least the RSRP threshold and / or MTCH BLER threshold should be used.

[0289] Recommendation 10: RAN2 should agree to introduce RSRP thresholds and / or MTCH BLER thresholds to monitor multicast reception quality and trigger RRC recovery.

[0290] 2.5. Service Continuity During RRC Recovery

[0291] The following possibility also needs to be considered: a UE that has already received a multicast session in an inactive state (i.e., via an inactive multicast MRB) is paged and an RRC recovery procedure is initiated. After transitioning to the connected state, the UE naturally expects to continue receiving the same multicast session. However, in this case, the UE has two MRBs for the same multicast session: a multicast inactive MRB configured for multicast reception in the inactive state and a conventional multicast MRB restored for multicast reception in the connected state.

[0292] In version 17, multicast sessions could only be received via a multicast MRB configured by RRC reconfiguration. On the other hand, according to version 18, the UE could receive multicast sessions via a multicast inactive MRB configured by RRC release or multicast MCCH.

[0293] Recommendation 11: RAN2 should discuss UE operations during RRC recovery during continuous reception of multicast sessions (e.g., handling multicast inactive MRBs and legacy multicast MRBs).

[0294] Figure Labels

[0295] 1: Mobile communication system

[0296] 5: Network

[0297] 10: RAN

[0298] 20:CN

[0299] 100: User Equipment (UE)

[0300] 110: Receiver

[0301] 120: Transmitter

[0302] 130: Controller

[0303] 200: gNB (base station)

[0304] 210: Transmitter

[0305] 220: Receiver

[0306] 230: Controller

[0307] 240: Backhaul communicator.

Claims

1. A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising: The user equipment receives a Radio Resource Control (RRC) release message from a network node. The RRC release message includes PTM configuration information for receiving multicast sessions in an RRC inactive state. The RRC release message causes the user equipment to switch to the RRC inactive state. Confirm whether the RRC release message includes predetermined information indicating a pause in the multicast reception process for the multicast session; as well as When the RRC release message does not include the predetermined information, the multicast reception process is initiated based on the PTM configuration information.

2. The communication method according to claim 1 further includes: When the RRC release message includes the predetermined information, the multicast reception process is paused.

3. The communication method according to claim 1, wherein, The pre-defined information is associated with the discontinuous reception DRX configuration to be applied to receive the multicast session.

4. A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising: In Radio Resource Control (RRC) connection state, use Multicast-Multicast Radio Bearer (MRB) to receive multicast sessions; The user equipment receives an RRC release message from a network node. The RRC release message includes configuration information for receiving a multicast inactive MRB for a multicast session in an RRC inactive state. The RRC release message causes the user equipment to switch to the RRC inactive state. Confirm whether a multicast inactive MRB corresponding to the multicast MRB is configured; as well as When a multicast inactive MRB corresponding to the multicast MRB is configured, a multicast reception process using the multicast inactive MRB is initiated.

5. The communication method according to claim 4, wherein, The multicast inactive MRB corresponding to the multicast MRB is either a multicast inactive MRB that shares a common MBS session ID with the multicast MRB, or a multicast inactive MRB that shares a common MRB ID with the multicast MRB.

6. The communication method according to claim 4 or 5, further comprising: When a multicast inactive MRB that does not correspond to the multicast MRB is configured, the multicast reception process is paused.

7. A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising: The user equipment receives a Radio Resource Control (RRC) release message from a network node. The RRC release message includes configuration information for receiving multicast inactive multicast radio bearers (MRBs) of multicast sessions in an RRC inactive state. The RRC release message causes the user equipment to switch to the RRC inactive state. Based on pre-stored upper-layer information, attempt to receive the multicast session using the multicast inactive MRB; as well as When the multicast session is successfully received as a result of the attempt, the multicast reception process continues using the multicast inactive MRB.

8. The communication method according to claim 7, further comprising: If the multicast session is not successfully received as a result of the attempt, the multicast reception process is stopped.

9. The communication method according to claim 7 or 8, wherein, During the attempt, the user equipment performs the attempt within a specific time period, and The specific time period is configured from the network node in the user equipment.

Images