Communication methods, user devices, programs, chipsets, and systems

Abstract

This communication method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS) includes: a step for receiving, from a network, a first PTM setting used for receiving a multicast session in a radio resource control (RRC) inactive state, and retaining the first PTM setting; a step for determining whether or not update of the first PTM setting is necessary in response to reception of a paging message including a session identifier of the multicast session from the network in an RRC inactive state; and a step for receiving a multicast control channel (MCCH) for multicast communication in response to the determination that the update of the first PTM setting is necessary in the RRC inactive state to acquire a second PTM setting used for receiving the multicast session.

Description

Technical Field

[0001] This disclosure relates to a communication method used in a mobile communication system 、 user equipment , programs, chipsets, and systems and pertains to it.

Background Art

[0002] In 3GPP (3rd Generation Partnership Project), the technical specifications of NR (New Radio), which is the 5th generation (5G) radio access technology, are defined. NR has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is the 4th generation (4G) radio access technology. In 3GPP, the technical specifications of the 5G / NR multicast / broadcast service (MBS) are defined.

[0003] In 3GPP Release 17, reception of MBS multicast (i.e., multicast reception) is only possible for user equipment in the radio resource control (RRC) connected state (see, for example, Non-Patent Document 1). In contrast, in 3GPP Release 18, the technical specifications are planned to be extended so that user equipment in the RRC inactive state can perform multicast reception.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] The first aspect of the communication method is a communication method performed by a user device in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes: determining whether predetermined conditions are met in response to receiving a paging message containing the session identifier of a multicast session from the network while the radio resource control (RRC) is inactive; and, in the RRC inactive state, receiving a multicast control channel (MCCH) for multicast communication in response to meeting the predetermined conditions, thereby obtaining configuration information used for receiving the multicast session in the RRC inactive state.

[0006] The second aspect of the communication method is a method executed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes the steps of: receiving a first PTM setting from the network for use in receiving a multicast session in a radio resource control (RRC) inactive state and maintaining the first PTM setting; determining whether or not it is necessary to update the first PTM setting in response to receiving a paging message containing the session identifier of the multicast session from the network in the RRC inactive state; and obtaining a second PTM setting for receiving the multicast session by receiving a multicast control channel (MCCH) for multicast communication in response to determining that it is necessary to update the first PTM setting in the RRC inactive state.

[0007] The user device according to the third embodiment is a device used in a mobile communication system that provides multicast / broadcast services (MBS). The user device includes a control unit that performs the following: receiving a first PTM setting from the network for use in receiving multicast sessions in a radio resource control (RRC) inactive state and maintaining the first PTM setting; determining whether or not it is necessary to update the first PTM setting in response to receiving a paging message containing the session identifier of the multicast session from the network in the RRC inactive state; and obtaining a second PTM setting for receiving multicast sessions by receiving a multicast control channel (MCCH) for multicast communication in response to determining that it is necessary to update the first PTM setting in the RRC inactive state. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagram showing an example configuration of a mobile communication system according to the embodiment. [Figure 2] This figure shows an example configuration of a UE (User Equipment) according to the embodiment. [Figure 3] This figure shows an example configuration of a gNB (base station) according to the embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This figure shows an overview of the operation of the UE related to the first operation pattern of the embodiment. [Figure 7] This figure shows an example of the operation sequence of a mobile communication system relating to the first operation pattern of the embodiment. [Figure 8] This figure shows an overview of the operation of the UE related to the second operation pattern of the embodiment. [Figure 9]This figure shows an example of the operation sequence of a mobile communication system according to the second operation pattern of the embodiment. [Figure 10] This figure shows an overview of the operation of the UE related to the third operation pattern of the embodiment. [Figure 11] This figure shows an example of the first operation example of the third operation pattern of the embodiment. [Figure 12] This figure shows another example of the first operation example of the third operation pattern of the embodiment. [Figure 13] This figure shows an example of a second operation example of the third operation pattern of the embodiment. [Figure 14] This figure shows another example of the second operation example of the third operation pattern of the embodiment. [Modes for carrying out the invention]

[0009] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

[0010] (1) Example of system configuration Figure 1 shows an example configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following explanation, 5GS will be used as an example, but the mobile communication system may also incorporate an LTE (Long Term Evolution) system at least partially. The mobile communication system may also incorporate a 6th Generation (6G) system at least partially.

[0011] The mobile communication system 1 comprises user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, NG-RAN 10 may be simply referred to as RAN 10, and 5GC 20 may be simply referred to as the core network (CN) 20. RAN 10 and CN 20 constitute the network of the mobile communication system 1.

[0012] UE100 is a mobile wireless communication device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or device attached to a sensor, a vehicle or device attached to a vehicle (Vehicle UE), or an aircraft or device attached to an aircraft (Aerial UE).

[0013] NG-RAN10 includes base stations (referred to as "gNBs" in 5G systems) 200. The gNBs 200 are interconnected via the Xn interface, which is an inter-base station interface. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with UEs 100 that have established a connection with its own cell. The gNB 200 has radio resource management (RRM) functions, user data routing functions (hereinafter simply referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to indicate the smallest unit of a wireless communication area. "Cell" is also used as a term to indicate a function or resource that performs wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

[0014] Note that the gNB can also be connected to the EPC (Evolved Packet Core), which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

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

[0016] Figure 2 is a diagram showing a configuration example of the UE 100 (user equipment) according to the embodiment. The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.

[0017] The receiving unit 110 performs various receptions under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0018] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmitted signal) output by the control unit 130 into a wireless signal and transmits it from the antenna.

[0019] The control unit 130 performs various control and processing operations on the UE 100. Such processing includes processing of each layer described later. The operation of the UE 100 described above and later may also be controlled by the control unit 230. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0020] Figure 3 shows an example configuration of a gNB200 (base station) according to an embodiment. The gNB200 has a transmitter 210, a receiver 220, a control unit 230, and a backhaul communication unit 240. The transmitter 210 and receiver 220 constitute a wireless communication unit that performs wireless communication with the UE100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN20.

[0021] The transmitting unit 210 performs various types of transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.

[0022] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0023] The control unit 230 performs various control and processing operations in the gNB200. Such processing includes processing in each layer described later. The operation of the gNB200 described above and below may also be controlled by the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0024] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via the NG interface, which is an inter-base station-core network interface. The gNB200 may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected by the F1 interface, which is a fronthaul interface.

[0025] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.

[0026] The user plane radio interface protocol consists of a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0027] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel. The UE100's PHY layer receives downlink control information (DCI) transmitted from the gNB200 over the physical downlink control channel (PDCCH). Specifically, the UE100 performs blind decoding of the PDCCH using a Radio Network Temporary Identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to its own UE. The DCI transmitted from the gNB200 has a CRC parity bit added, which is scrambled by the RNTI.

[0028] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[0029] 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 UE100's RLC layer and the gNB200's RLC layer via a logical channel.

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

[0031] The SDAP layer maps IP flows, which are the units under which the core network performs QoS (Quality of Service) control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, the SDAP is not required.

[0032] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0033] The control plane's wireless interface protocol stack includes an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer, instead of the SDAP layer shown in Figure 4.

[0034] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. If the connection between the RRC of the UE100 and the RRC of the gNB200 is suspended, the UE100 is in the RRC inactive state.

[0035] The NAS layer (also simply referred to as "NAS"), located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300A's NAS layer. The UE100 also has application layers and other components in addition to its wireless interface protocol. Furthermore, the layer below the NAS layer is called the AS layer (also simply referred to as "AS").

[0036] (2) Overview of MBS Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS).

[0037] (2.1) MBS Broadcast In the case of broadcast communication services (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. Broadcast communication services are delivered to the UE100s using broadcast sessions, which are a type of MBS session. UE100s can receive broadcast sessions regardless of whether they are in the RRC idle, RRC inactive, or RRC connected state.

[0038] Broadcast communication services utilize Point-to-Multipoint (PTM) distribution. In PTM transmission, the gNB200 distributes a single copy of an MBS packet to a set (group) of multiple UE100s. For example, the gNB200 schedules a group-common PDSCH, which has a Cyclic Redundancy Code (CRC) scrambled by a Group-Common RNTI (G-RNTI), using a group-common PDCCH.

[0039] For broadcast communication services, UE100 receives a broadcast session in the following steps: First, UE100 receives a System Information Block Type 20 (SIB20) from gNB200. SIB20 contains the settings for a Multicast Control Channel (MCCH), which is a type of logical channel. Second, based on SIB20, UE100 receives the MCCH from gNB200. The MCCH contains the PTM settings. The PTM settings transmit settings for a Multicast Traffic Channel (MTCH), which is a type of logical channel (MTCH settings), and settings for a Broadcast MRB, which is a Multicast Radio Bearer (MRB) for the broadcast session. The information transmitted by the MCCH is sometimes referred to as MBS broadcast control information. Third, based on the MCCH, UE100 receives the MTCH. The MTCH transmits the broadcast session (specifically, the MBS data belonging to the broadcast session).

[0040] MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 10 to UE100. MTCH is a PTM downlink channel for transmitting MBS data for either a multicast session or a broadcast session from network 10 to UE100.

[0041] MCCH information transmitted via MCCH occurs at the boundary of a modification period, and within that modification period, the same MCCH information is repeatedly transmitted according to the MCCH settings (MCCH scheduling). When network 5 modifies (part of) the MCCH information, it notifies UE100 via PDCCH (DCI), which schedules the MCCH, for all repeated transmissions within that modification period, starting from the beginning of the modification period.

[0042] UE100, which is receiving or interested in receiving MBS services transmitted using MBS broadcast, will acquire new MCCH information starting from the same slot upon receiving such a change notification (MCCH change notification). UE100 will apply previously acquired MCCH information until it acquires new MCCH information.

[0043] MCCH change notifications are transmitted as a 2-bit bitmap. If the MSB (Most Significant Bit) of the 2-bit bitmap is set to "1", it indicates the start of a new MBS service. If the LSB (Least Significant Bit) of the 2-bit bitmap is set to "1", it indicates a change in MCCH information other than a change caused by the start of a new MBS service (e.g., activation of an MBS session), such as a change in the configuration of an ongoing MBS session, termination of an MBS session (specifically, a broadcast session), or a change in adjacent cell information.

[0044] However, although there is only one MCCH per cell, it transmits MCCH information for all MBS services (all broadcast sessions) within that cell. Therefore, UE100 cannot identify which broadcast session's MCCH information has been changed based on the MCCH change notification. Consequently, UE100 needs to acquire MCCH information in response to the MCCH change notification, even if the MCCH information of a broadcast session it does not receive or is not interested in receiving has been changed.

[0045] (2.2) MBS Multicast In the case of multicast communication services (also known as "MBS multicast"), the same service and the same specific content data are provided simultaneously to a specific set of UEs. That is, not all UE100s within a multicast service area are permitted to receive the data. Multicast communication services are delivered to UE100s using multicast sessions, which are a type of MBS session.

[0046] UE100 can only receive multicast sessions after it has joined the multicast session. Joining a multicast session may mean that UE100 is registered with network 5 (CN20) as a device capable of receiving the multicast session.

[0047] For multicast communication services, 3GPP Release 17 allows only UE100s in an RRC connected state to receive multicast sessions. However, 3GPP Release 18 is planned to extend this so that UE100s in an RRC inactive state can also receive multicast sessions.

[0048] (2.2.1) Multicast reception in RRC connected state A UE100 in RRC connected state can receive multicast sessions (specifically, MBS data belonging to a multicast session) using mechanisms such as PTP (Point-to-Point) and / or PTM (Point-to-Multipoint) distribution.

[0049] In the case of a multicast communication service, a UE100 in the RRC connected state receives a multicast session in the following procedure. First, the UE100 receives an RRC Reconfiguration message from the gNB200. The RRC Reconfiguration message is transmitted on the Dedicated Control Channel (DCCH). The RRC Reconfiguration message transmits the settings for the MTCH for receiving the multicast session (MTCH settings) and the settings for the multicast MRB, which is the MRB for that multicast session. Second, the UE100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0050] (2.2.2) Multicast reception in RRC inactive state A UE100 in an RRC inactive state can receive multicast sessions (specifically, MBS data belonging to multicast sessions) using the PTM distribution mechanism.

[0051] In the case of a multicast communication service, a UE100 in an RRC inactive state can receive a multicast session in the following manner. First, the UE100 in an RRC inactive state receives a newly introduced system information block (also called the "new SIB") from the gNB200. The new SIB includes the configuration of a newly introduced MCCH (also called the "multicast MCCH"). Second, the UE100 in an RRC inactive state receives the multicast MCCH from the gNB200 based on the new SIB. The multicast MCCH includes the PTM configuration. The PTM configuration transmits the configuration for the MTCH for multicast session reception (MTCH configuration) and the configuration of the multicast MRB, which is the MRB for multicast sessions. Third, the UE100 in an RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0052] The gNB200 multicasts the UE100 in an RRC inactive state. session When configured to receive, the PTM settings can be sent to the UE100 using an RRC Release message that includes the suspend setting. In this case, when the UE100 receives the RRC Release message containing the PTM settings from the gNB200, it transitions to the RRC inactive state and receives multicast sessions in the RRC inactive state.

[0053] (2.2.3) Group Notifications If there is temporarily no data to send to UE100 in an active multicast session, gNB200 may transition UE100 to the RRC inactive state. When the multicast session is deactivated, gNB200 may transition UE100 to the RRC idle state or the RRC inactive state.

[0054] A gNB200 that supports MBS will use the group notification mechanism to notify UE100s that are in an RRC idle or RRC inactive state when a multicast session is activated by CN20. For example, a gNB200 that supports MBS may use the group notification mechanism to notify UE100s that are in an RRC inactive state if a multicast session has been activated and there is multicast session data to be distributed on the gNB200.

[0055] Upon receiving a group notification, UE100 reconnects to network 5 or resumes the connection and transitions to the RRC connected state. The group notification is processed by the paging RNTI (P-RNTI) on the PDCCH, and the paging channel is monitored by UE100.

[0056] The group notification paging message includes a session identifier (MBS session ID) used to page all UE100s in the RRC idle and RRC inactive states that are participating in the associated MBS multicast session. In other words, UE100s are not paged individually.

[0057] When UE100 transitions to the RRC Connected state, UE100 may stop monitoring group notifications associated with a particular multicast session. In other words, UE100 stops checking for the MBS session ID in paging messages. UE100 does not monitor group notifications if UE100 leaves the multicast session, network 5 requests UE100 to leave, or network 5 releases the multicast session.

[0058] Group notifications may be made via MCCH or via MCCH change notifications. When using MCCH, the determination may be made based on whether or not the MCCH setting for the MBS session of interest exists in the MCCH. When using MCCH change notifications, the group notification may be made in a predetermined bit of the DCI.

[0059] (3) First operation pattern The first operational pattern for multicast reception in an RRC inactive state is described below.

[0060] If a multicast session is active, i.e., if a multicast session is in progress, the UE100 in the RRC Connected state can be configured with a multicast MRB for multicast reception via the RRC Reconfiguration message and can begin receiving MTCH.

[0061] Furthermore, in the case of multicast reception while RRC is inactive, a UE100 in the RRC connected state may have a multicast reception MRB (also referred to as a "multicast inactive MRB") configured via an RRC Release message.

[0062] When a UE100 in the RRC Connected state receives an RRC Release message containing a suspendConfig, it suspends the multicast MRB for the RRC Connected state. However, if the RRC Release message contains a PTM configuration for the RRC Inactive state, the UE100 continues to receive the same multicast session.

[0063] The continuity of service for multicast sessions must be guaranteed during and after transitions in RRC states. Therefore, UE100 should apply the PTM setting for multicast inactive MRBs before pausing multicast MRBs. UE100 will begin receiving multicast inactive MRBs as soon as the PTM setting is applied. This prevents interruptions in multicast reception when transitioning from the RRC connected state to the RRC inactive state.

[0064] (3.1) UE Operation Overview Figure 6 is a diagram showing an overview of the operation of UE100 in relation to the first operation pattern of the embodiment. In steps S1 to S5 of Figure 6, UE100 is assumed to be in the RRC connected state.

[0065] In step S1, UE100 uses the first MRB (multicast MRB) for the RRC connected state to receive a multicast session (referred to as "multicast session #1") from network 5 (gNB200).

[0066] In step S2, UE100 receives an RRC Release message from network 5 (gNB200) to transition UE100 to the RRC inactive state (i.e., an RRC Release message including suspend settings). This RRC Release message includes configuration information (PTM settings) indicating the settings for the second MRB (multicast inactive MRB) used to receive multicast session #1 in the RRC inactive state. The suspend settings are an information element indicating the settings for the RRC inactive state.

[0067] In step S3, UE100 applies the configuration information (PTM settings) from step S2 to establish the second MRB before suspending the first MRB in response to the receipt of the RRC Release message. Step S3 may be performed before applying the suspend settings. Step S3 may also be performed when applying the suspend settings.

[0068] In step S4, UE100 begins receiving multicast session #1 using the second MRB established in step S3. For example, UE100 begins receiving the second MRB (specifically, the MTCH corresponding to the second MRB) immediately after applying the PTM configuration.

[0069] In step S5, UE100 suspends the first MRB. Specifically, UE100 stops using the first MRB while retaining its configuration. By suspending the first MRB after establishing the second MRB in this way, interruptions to multicast reception can be suppressed. Alternatively, UE100 may suspend the first MRB after confirming that reception of multicast session #1 (i.e., reception of MBS data) has started via the second MRB. This confirmation of reception start (successful reception start) may be performed at a lower layer (e.g., the PDCP layer), and the result of this confirmation may be notified to the RRC layer. If reception start cannot be confirmed within a certain period, UE100 may determine that there is a reception error for multicast session #1 and subsequently suspend the first MRB. If a reception error is detected, UE100 may attempt to transition back to the RRC connected state (specifically, by sending an RRC Resume Request).

[0070] In step S6, UE100 transitions from the RRC connected state to the RRC inactive state. In the RRC inactive state, UE100 can continue receiving multicast session #1 using the second MRB.

[0071] This operation makes it possible to suppress the interruption of multicast reception when a UE100 receiving multicast in the RRC connected state transitions from the RRC connected state to the RRC inactive state.

[0072] (3.2) Example of an operation sequence Figure 7 shows an example of the operation sequence of the mobile communication system 1 according to the first operation pattern of the embodiment.

[0073] In step S11, UE100 is in the RRC connected state in the gNB200 cell.

[0074] In step S12, network 5 activates multicast session #1. Step S12 may also be performed after step S13, after step S14, or after step S15.

[0075] In step S13, UE100, in the RRC connected state, joins multicast session #1.

[0076] In step S14, the gNB200 sends an RRC Reconfiguration message to the UE100, which includes the PTM settings for RRC Connected. The UE100, in the RRC Connected state, receives the RRC Reconfiguration message.

[0077] In step S15, the UE100 in RRC connected state applies the RRC connected PTM settings from step S14 and establishes the first MRB (multicast MRB) with the gNB200.

[0078] In step S16, gNB200 uses the first MRB to send the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in the RRC connected state, receives the multicast data.

[0079] Subsequently, in step S17, gNB200 sends an RRC Release message to UE100 that includes the suspend settings. UE100, in the RRC connected state, receives the RRC Release message. The RRC Release message further includes the PTM settings for RRC inactive. The PTM settings for RRC inactive may be included in the suspend settings. These PTM settings may be separate information elements from the suspend settings.

[0080] In step S18, the UE100 in RRC connected state applies the RRC inactive PTM setting from step S17 and establishes a second MRB (multicast inactive MRB) with the gNB200.

[0081] In step S19, gNB200 uses the second MRB to send the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in the RRC connected state, receives the multicast data. At this point, UE100 may perform both multicast reception using the first MRB and multicast reception using the second MRB. If UE100 receives the same multicast data on both the first and second MRBs, it may discard one of the multicast data.

[0082] In step S20, the UE100 in RRC connected state suspends the first MRB.

[0083] In step S21, UE100 transitions from the RRC connected state to the RRC inactive state.

[0084] Subsequently, if there is an update to the RRC inactive PTM setting, UE100 may receive a new SIB from gNB200 (step S22) and a multicast MCCH from gNB200 (step S23). Note that in step S17, an example was shown in which the RRC Release message includes the RRC inactive PTM setting, but this is not the only example. In step S17, UE100 may receive the RRC inactive PTM setting via MCCH. Furthermore, UE100 may receive an RRC Release message (which does not necessarily include the RRC inactive PTM setting).

[0085] (4) Second operation pattern In the following, we will explain the second operating pattern for multicast reception in the RRC inactive state, focusing primarily on the differences from the first operating pattern described above. Note that redundant explanations of operations similar to the first operating pattern will be omitted.

[0086] The first operating pattern described above assumed a scenario where the multicast session was already activated when the UE100 received the RRC Release message. In contrast, the second operating pattern primarily assumes a scenario where the multicast session was not yet activated when the UE100 received the RRC Release message.

[0087] For inactive multicast sessions, the UE100 may be configured with a PTM setting (MBSMulticastInactiveConfiguration) via an RRC Release message. In the first operating pattern described above, upon receiving the RRC Release message, the UE100 applies the PTM setting and immediately begins receiving MTCHs. However, if the multicast session is inactive, no MTCHs are sent at this point, and therefore the UE100 should not begin the process of receiving MTCHs. In this case, even if the UE100 attempts to receive multicast (receive MTCHs), it will not be able to receive any MTCHs, and the UE100 will waste power.

[0088] Therefore, in the second operating pattern, network 5 notifies UE100 that the multicast session (specifically, the multicast session in which UE100 is participating) is still inactive. For example, gNB200 notifies UE100 via an RRC Release message whether the multicast session has been activated or not, so that UE100 does not receive the corresponding MTCH. This allows UE100 to wait for, for example, a multicast session activation notification (group notification) without starting to receive the MTCH.

[0089] In other words, in the second operating pattern, the UE100 in the RRC connected state first receives an RRC Release message from the gNB200 that includes configuration information used for receiving multicast sessions in the RRC inactive state (PTM settings for RRC inactive) and transitions the UE100 to the RRC inactive state. Second, the UE100 checks whether the multicast session is activated or not. Third, if the multicast session is not activated, the UE100 suspends the execution of predetermined processing to start receiving the multicast session.

[0090] (4.1) UE Operation Overview Figure 8 shows an overview of the operation of UE100 in relation to the second operation pattern of the embodiment. Here, it is assumed that UE100 has already joined multicast session #1.

[0091] In step S201, the UE100 in the RRC connected state receives an RRC Release message from the gNB200 that includes configuration information (PTM settings for RRC inactive) used to receive multicast session #1 in the RRC inactive state, and transitions the UE100 to the RRC inactive state. In the second operation pattern, the RRC Release message includes session status information indicating whether multicast session #1 is activated or not.

[0092] The session status information may indicate that multicast session #1 is activated (i.e., not deactivated). The session status information may indicate that multicast session #1 is not activated (i.e., deactivated). The session status information may indicate whether to immediately apply the information described below (which may be PTM settings for RRC inactive) (i.e., whether to apply the predetermined processing or simply hold it). Alternatively, the session status information may indicate whether to immediately start MTCH reception.

[0093] The configuration information in the RRC Release message (PTM settings for RRC inactive) may include, as predetermined information associated with multicast session #1, at least one of the following: a session identifier (TMGI) associated with multicast session #1, an MRB identifier associated with multicast session #1, and an MTCH setting associated with multicast session #1. The MTCH setting is a setting related to MTCH reception and includes, for example, at least one of the following: a group identifier (G-RNTI), intermittent reception settings (DRX settings or scheduling information: MTCH transmission ON time, MTCH transmission period, reference time and time offset, HARQ retransmission settings), Layer 2 settings (PDCP settings, RLC settings), and physical channel settings (PDCCH settings, PDSCH settings, SSB mapping settings).

[0094] In the RRC Release message, session status information is associated with predetermined information. This allows the UE100 to identify which multicast sessions are active based on the predetermined information and the session status information.

[0095] In step S202, the UE100 in the RRC connected state checks whether multicast session #1 is activated based on the session status information in the RRC Release message. Alternatively, if the UE100 has obtained information from the CN20 regarding whether multicast session #1 is activated, the UE100 may check whether multicast session #1 is activated based on the information from the CN20.

[0096] If multicast session #1 is activated (step S202: YES), in step S203, the UE100 in the RRC connected state performs the same operation as the first operation pattern described above. Specifically, the UE100 performs predetermined processing to start receiving multicast session #1. The predetermined processing includes at least one of the following: processing to apply configuration information (PTM settings for RRC inactive) (including processing to establish a second MRB), and processing to start receiving MTCH (i.e., processing to start multicast reception using the second MRB). The predetermined processing may also include at least one of the following: processing to receive multicast MCCH, and processing to receive a new SIB that transmits configuration information (multicast MCCH settings) used to receive multicast MCCH.

[0097] After executing the predetermined process, in step S204, UE100 transitions from the RRC connected state to the RRC inactive state. Then, in step S205, UE100 in the RRC inactive state continues to receive multicast session #1.

[0098] On the other hand, if multicast session #1 is not activated (step S202: NO), in step S206, UE100 suspends the execution of predetermined processes for starting reception of multicast session #1. For example, UE100 in the RRC connected state will not execute at least one of the following: the process of applying configuration information (PTM settings for RRC inactive) (including the process of establishing the second MRB), and the process of starting reception of MTCH (i.e., the process of starting multicast reception using the second MRB). However, UE100 may perform the process of saving (holding) configuration information to its own memory.

[0099] After suspending the execution of predetermined processing, in step S207, UE100 transitions from the RRC connected state to the RRC inactive state. Then, in step S208, UE100 in the RRC inactive state awaits a paging message (i.e., a group notification) to notify the activation of multicast session #1, and receives the group notification.

[0100] Upon receiving a group notification, in step S209, the UE100 in the RRC inactive state performs a process to monitor and receive a predetermined logical channel. The predetermined logical channel is at least one of the multicast MCCH, which transmits configuration information used for receiving multicast session #1 in the RRC inactive state, and the MTCH, which transmits multicast session #1. Here, the UE100 may read the configuration information from memory and apply it. Then, in step S210, the UE100 in the RRC inactive state receives multicast session #1 transmitted on the MTCH.

[0101] (4.2) Example of an operation sequence Figure 9 shows an example of the operation sequence of the mobile communication system 1 according to the second operation pattern of the embodiment.

[0102] In step S251, UE100 is in the RRC connected state in the gNB200 cell.

[0103] In step S252, the UE100, in the RRC connected state, joins multicast session #1. Here, the UE100 joins multicast session #1 by communicating with CN20 (e.g., NAS signaling). At this time, the UE100 may obtain information from CN20 (e.g., AMF300A) about whether multicast session #1 is activated or not.

[0104] In step S253, gNB200 sends an RRC Release message to UE100 that includes the suspend setting. UE100, in the RRC Connected state, receives the RRC Release message. The RRC Release message further includes the PTM setting for RRC inactive for multicast session #1. The PTM setting for RRC inactive may be included in the suspend setting. This PTM setting may be a separate information element from the suspend setting.

[0105] In the second operating pattern, the RRC Release message may include session status information indicating whether multicast session #1 is activated or not. That is, when gNB200 configures PTM settings on UE100 using the RRC Release message, it notifies whether multicast session #1 corresponding to that PTM setting is active (i.e., in progress) or inactive (i.e., waiting to be activated). This notification may be made for each TMGI, each MRB, and each PTM setting (MTCH setting). Here, we will proceed with the explanation assuming that multicast session #1 is not activated.

[0106] In step S254, UE100 recognizes that multicast session #1 is inactive based on information from CN20 and / or session status information in the RRC Release message.

[0107] In step S255, UE100 suspends the execution of predetermined processing to begin receiving multicast session #1. For example, UE100 does not apply the PTM setting for RRC inactive. Alternatively, UE100 may apply the PTM setting but not perform MTCH reception. UE100 may also refrain from processing the multicast MCCH and new SIB reception.

[0108] In step S256, UE100 transitions from the RRC connected state to the RRC inactive state.

[0109] In step S257, the UE100, which is in an RRC inactive state, begins monitoring for paging messages (i.e., group notifications) to notify the activation of multicast session #1.

[0110] Subsequently, in step S258, network 5 activates multicast session #1.

[0111] In step S259, gNB200 sends a paging message (i.e., a group notification) to notify of the activation of multicast session #1. This group notification includes the session identifier (TMGI) of multicast session #1. UE100, in the RRC connected state, receives the group notification and confirms that the session identifier of multicast session #1, which it has joined, is included in the group notification.

[0112] In step S260, gNB200 may send a new SIB including the multicast MCCH configuration. UE100, in the RRC inactive state, may receive the new SIB in response to receiving the group notification in step S259.

[0113] In step S261, gNB200 may send a multicast MCCH containing a PTM setting for RRC inactive multicast session #1. UE100, in the RRC inactive state, may receive the multicast MCCH based on the new SIB in step S260.

[0114] In step S262, gNB200 sends the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in an RRC inactive state, receives the multicast data (MTCH) based on the RRC inactive PTM settings in step S253 and / or step S261.

[0115] (5) Third operation pattern The following describes the third operating pattern for multicast reception in the RRC inactive state, primarily focusing on its differences from the previously described operating patterns. The third operating pattern can be implemented in combination with the previously described operating patterns. Note that redundant explanations for operations similar to those described above will be omitted.

[0116] The above 2nd Action Putter n As explained, a UE100 in the RRC Connected state participating in multicast session #1 may have multicast session #1 inactive when the RRC Release message sets the RRC inactive PTM setting. In such a scenario (hereinafter also referred to as "Scenario 1"), the RRC inactive PTM setting may change when multicast session #1 is activated after the UE100 has transitioned to the RRC inactive state. In that case, the UE100 needs to update its existing RRC inactive PTM setting to the new RRC inactive PTM setting. In this case, the UE100 obtains the new RRC inactive PTM setting by receiving the multicast MCCH and receives the activated multicast session #1 on the MTCH based on the new RRC inactive PTM setting.

[0117] Alternatively, as mentioned above 1 Action Putter nAs explained, we assume a scenario where UE100, which has transitioned to an RRC inactive state, is receiving the activated (i.e., ongoing) multicast session #1 on the MTCH. In such a scenario (hereinafter also referred to as "Scenario 2"), the network 5 side may change the PTM setting for RRC inactive for the ongoing multicast session #1. In this case, UE100 obtains the new PTM setting for RRC inactive by receiving the multicast MCCH and receives the ongoing multicast session #1 on the MTCH based on the new PTM setting for RRC inactive.

[0118] In scenarios 1 and 2, similar to MBS broadcasts, it is conceivable to notify UE100s in an RRC inactive state of updates to multicast MCCH information (PTM settings for RRC inactive) via MCCH Change Notification for MBS multicast. However, UE100 cannot identify the MBS sessions to which the RRC inactive PTM settings should be updated based solely on MCCH Change Notification.

[0119] Therefore, in Scenario 1, even if UE100 in an RRC inactive state receives a multicast MCCH in response to an MCCH Change Notification, the received multicast MCCH may not contain the RRC inactive PTM setting for multicast session #1, which it is interested in receiving. Similarly, in Scenario 2, even if UE100 in an RRC inactive state receives a multicast MCCH in response to an MCCH Change Notification, the received multicast MCCH may not contain the RRC inactive PTM setting for multicast session #1 that it is receiving. Thus, receiving multicast MCCHs may be wasted, posing a challenge in terms of reducing the power consumption of UE100.

[0120] Furthermore, UE100, which is receiving or interested in receiving multicast session #1, needs to receive and decode the PDCCH at least once per MCCH change cycle in order to receive the MCCH Change Notification when the RRC is inactive. Therefore, there is a challenge in terms of reducing the power consumption of UE100.

[0121] Therefore, Third Action Putter n To address the aforementioned challenges, group notifications (i.e., paging messages containing session identifiers) are used. Regardless of whether the RRC inactive UE100 is receiving (or interested in receiving) multicast sessions, it receives (monitors) paging messages during its own paging occasions. Therefore, by using group notifications to notify the UE100 of changes to the multicast MCCH (PTM settings for RRC inactive), the UE100 can receive (monitor) multicast MCCH more efficiently than when using MCCH Change Notification.

[0122] (5.1) UE Operation Overview Figure 10 is a diagram showing an overview of the operation of UE100 according to the third operation pattern of the embodiment. In steps S31 and S32 of Figure 10, UE100 is assumed to be in the RRC connected state or the RRC inactive state. In steps S33 to S37 of Figure 10, UE100 is assumed to be in the RRC inactive state.

[0123] In step S31, UE100 receives the first PTM setting (hereinafter also referred to as the "first RRC inactive PTM setting") from network 5, which is used to receive multicast session #1 in the RRC inactive state. For example, UE100 in the RRC connected state receives an RRC Release message containing the first RRC inactive PTM setting from gNB200. Alternatively, UE100 in the RRC inactive state receives a multicast MCCH containing the first RRC inactive PTM setting from gNB200. As will be described in detail later, in the first example of the third operation pattern, the first RRC inactive PTM setting for multicast session #1 is associated with version information (hereinafter also referred to as the "value tag").

[0124] In step S32, UE100 retains the PTM setting for first RRC inactivity received in step S31. If multicast session #1 is not activated, UE100 retains the PTM setting for first RRC inactivity received in step S31 without applying it, similar to the second operating pattern described above. On the other hand, if multicast session #1 is activated, UE100 retains the PTM setting for first RRC inactivity received in step S31 while applying it, similar to the first operating pattern described above. In this case, UE100 receives multicast session #1 on the MTCH based on the PTM setting for first RRC inactivity.

[0125] In step S33, UE100 in the RRC inactive state receives a paging message (i.e., a group notification) containing the session identifier (TMGI) of multicast session #1 from network 5 (gNB200). Note that, according to the 3GPP Release 17 technical specification, MBS multicast can only be received by UE100 in the RRC connected state. Therefore, when UE100 in the RRC inactive state receives a paging message (group notification) containing the session identifier of multicast session #1 in which it has joined, it transitions to the RRC connected state in order to receive multicast. In contrast, in this embodiment (third operation pattern), when UE100 in the RRC inactive state receives a paging message (group notification) containing the session identifier of multicast session #1 in which it has joined, it does not transition to the RRC connected state and maintains the RRC inactive state.

[0126] In step S34, the UE100, which is in an RRC inactive state, determines whether or not it is necessary to update the first RRC inactive PTM setting held in step S32, in response to receiving the group notification in step S33.

[0127] In step S35, the UE100, which is in an RRC inactive state, determines that it needs to update the PTM setting for the first RRC inactive and performs multicast MCCH reception processing. Multicast MCCH reception processing may include receiving the new SIB and receiving the multicast MCCH.

[0128] In step S36, the UE100, which is in an RRC inactive state, receives (acquires) the second PTM setting used for receiving multicast session #1 (hereinafter also referred to as the "second RRC inactive PTM setting") on the multicast MCCH, and updates the first RRC inactive PTM setting with the second RRC inactive PTM setting.

[0129] In step S37, UE100, which is in an RRC inactive state, receives multicast session #1 on the MTCH based on the PTM setting for second RRC inactive.

[0130] In the first example of the third operation pattern, step S32 includes a step of storing the first RRC inactive PTM setting in association with a value tag which is version information. Step S34 includes a step of receiving a signaling from network 5 (gNB200) that includes the latest value tag of the RRC inactive PTM setting used to receive multicast session #1, and a step of determining whether an update to the first RRC inactive PTM setting is necessary by comparing the stored value tag with the latest value tag. Here, the signaling that includes the latest value tag is the paging message (group notification) from step S33, a System Information Block Type 1 (SIB1) sent from network 5 (gNB200), or a new SIB indicating the multicast MCCH setting.

[0131] In the first example of the third operation pattern, step S34 may include a step of determining that an update to the first RRC inactive PTM setting is necessary if the latest value tag is not included in the above signaling. Step S34 may also include a step of determining that an update to the first RRC inactive PTM setting is necessary based on the fact that the first RRC inactive PTM setting is not included in the RRC Release message in step S31.

[0132] In the second example of the third operation pattern, step S34 may include a step of determining that an update to the first RRC inactive PTM setting is necessary in response to the paging message (group notification) or new SIB in step S33 containing update information for the RRC inactive PTM setting. The update information may be a 1-bit flag. For example, in step S34, the UE100 in the RRC inactive state may determine that an update to the first RRC inactive PTM setting is necessary in response to the group notification or new SIB containing update information for the RRC inactive PTM setting.

[0133] In the second example of the third operation pattern, a paging message (group notification) containing a session identifier may also contain a UE identifier associated with that session identifier. In the group notification, the PTM configuration update information may be associated with the UE identifier. In the group notification, the PTM configuration update information may be associated with the session identifier. Alternatively, the new SIB may contain a session identifier, and in the new SIB, the PTM configuration update information may be associated with that session identifier.

[0134] (5.2) First example of operation Figure 11 shows an example of the first operation example of the third operation pattern of the embodiment. The operation example in Figure 11 is based on Scenario 1, which uses the second operation pattern described above. However, the second operation pattern described above assumed that the RRC inactive PTM setting set in the RRC Release message for the inactive multicast session #1 would not be changed when the session was activated. In contrast, the operation example in Figure 11 assumes that the RRC inactive PTM setting set in the RRC Release message is changed when the session is activated (i.e., an update is required). Note that redundant explanations of operations similar to the second operation pattern described above will be omitted.

[0135] In step S301, UE100 is in the RRC connected state in the gNB200 cell.

[0136] In step S302, UE100, in the RRC connected state, joins multicast session #1. Here, UE100 joins multicast session #1 through communication with CN20 (e.g., NAS signaling). However, network 5 has not yet activated multicast session #1.

[0137] In step S303, gNB200 sends an RRC Release message containing the suspend setting to UE100 in the RRC Connected state. UE100 in the RRC Connected state receives the RRC Release message. The RRC Release message further includes the RRC inactive PTM setting (first PTM setting) for multicast session #1. The RRC inactive PTM setting may be included in the suspend setting. The RRC Release message may contain information elements separate from the suspend setting. In this example, the RRC inactive PTM setting has a value tag. The value tag may be included in the RRC inactive PTM setting. The value tag may contain information elements separate from the RRC inactive PTM setting.

[0138] In step S304, the UE100 in RRC connected state stores the RRC inactive PTM settings and value tags received in step S303 in association with each other.

[0139] In step S305, UE100 transitions from the RRC connected state to the RRC inactive state.

[0140] In step S306, the UE100, which is in an RRC inactive state, starts paging monitoring. Specifically, the UE100, which is in an RRC inactive state, wakes up for its own paging occasion and monitors the paging channel (paging messages).

[0141] In step S307, the gNB200 may decide to change the PTM setting for RRC inactive for multicast session #1 based on the wireless conditions of its own cell. The gNB200 increments (i.e., adds 1 to) the value tag of the changed PTM setting for RRC inactive.

[0142] In step S308, network 5 activates multicast session #1.

[0143] In step S309, gNB200 sends a paging message (group notification) containing the session identifier of multicast session #1. UE100, which is in an RRC inactive state, receives the group notification from gNB200. The group notification may also include a value tag associated with the current (latest) RRC inactive PTM setting. Note that a value tag may exist for each session identifier (TMGI), each MRB identifier, or each PTM setting.

[0144] A UE100 in an RRC inactive state recognizes that multicast session #1, in which it is a participant, has been activated, based on the session identifier included in the group notification. Furthermore, if a value tag associated with the session identifier is included in the group notification, the RRC inactive UE100 retrieves that value tag from the group notification. If the value tag is not included in the group notification, the RRC inactive UE100 may receive SIB1 or a new SIB and retrieve the value tag from the received SIB1 or new SIB. In this case, SIB1 or the new SIB may contain a set of session identifiers and value tags.

[0145] In step S310, the UE100 in the RRC inactive state compares the value tag of the RRC inactive PTM setting it holds (set in the RRC Release message) with the value tag obtained in step S309.

[0146] If the value tags match, UE100 applies any PTM settings for RRC inactive that it has already applied, and begins receiving the MTCH for multicast session #1. In this case, UE100 begins receiving the MTCH without receiving the multicast MCCH and / or new SIB.

[0147] On the other hand, if the value tag is mismatched or the value tag could not be obtained (not provided), UE100 recognizes that there has been an update to the RRC inactive PTM setting and receives the multicast MCCH (and the new SIB if necessary) (steps S311, S312). Here, UE100 may obtain the new SIB for multicast MCCH reception (step S311). UE100 receives the multicast MCCH (step S312), obtains and applies the latest RRC inactive PTM setting (second PTM setting) provided in the multicast MCCH, and starts receiving the MTCH for multicast session #1 (step S313).

[0148] Furthermore, if the RRC Release message in step S303 does not provide the PTM setting for RRC inactive, UE100 may consider in step S310 that there was a mismatch in the value tag (that the PTM setting for RRC inactive has been updated).

[0149] In step S313, UE100, in an RRC inactive state, continues to receive multicast session #1.

[0150] In this example, we explained three methods for notifying the latest multicast MCCH value tags: using group notification, using the new SIB, and using SIB1.

[0151] Using the group notification method, the UE100 waiting for session activation performs paging monitoring, allowing for the confirmation of updates to the RRC inactive PTM settings with minimal power consumption and low latency.

[0152] While the method using the new SIB allows for easy specification expansion, it requires additional power consumption to check for updates to the RRC inactive PTM settings because the UE100 must monitor the new SIB, and it also causes delays in acquiring the new SIB. However, some improvement is possible by implementing a rule that updates the value tag of the new SIB (the value tag notified in SIB1) if the value tag of the multicast MCCH changes. The UE100 checks SIB1, and if the value tag of the new SIB has not changed, it can determine that the value tag of the multicast MCCH has also not changed.

[0153] Using SIB1, the UE100 constantly checks SIB1, allowing it to check for updates to the RRC inactive PTM settings without additional power consumption. However, increasing the message size of SIB1 is generally undesirable.

[0154] Figure 12 shows another example of the first operation example of the third operation pattern of the embodiment. This operation example is based on scenario 2 described above. Note that redundant explanations of operations similar to those in Figure 11 are omitted.

[0155] In step S331, network 5 activates multicast session #1.

[0156] In step S332, UE100 transitions from the RRC connected state to the RRC inactive state.

[0157] In step S333, gNB200 sends a new SIB containing the multicast MCCH configuration. UE100, in an RRC inactive state, receives the new SIB.

[0158] In step S334, gNB200 sends the RRC inactive PTM setting for multicast session #1 over the multicast MCCH. UE100, in the RRC inactive state, receives the RRC inactive PTM setting based on the new SIB and retains the received RRC inactive PTM setting as the first PTM setting. Here, the RRC inactive PTM setting is associated with a value tag.

[0159] In step S335, gNB200 transmits the MBS data for multicast session #1 over the MTCH. UE100, in an RRC inactive state, receives the MBS data for multicast session #1 over the MTCH based on the PTM settings for RRC inactive.

[0160] In step S336, gNB200 may decide to change the PTM setting for RRC inactive for multicast session #1 based on the wireless conditions of its own cell. gNB200 increments (i.e., adds 1 to) the value tag of the changed PTM setting for RRC inactive.

[0161] In step S337, gNB200 sends a paging message (group notification) containing the session identifier of multicast session #1. UE100, which is in an RRC inactive state, receives the group notification from gNB200. The group notification may also include a value tag associated with the current (latest) RRC inactive PTM setting. Note that a value tag may exist for each session identifier (TMGI), each MRB identifier, or each PTM setting.

[0162] If a UE100 in an RRC inactive state has a value tag associated with the session identifier included in the group notification, it retrieves the value tag from the group notification. If the value tag is not included in the group notification, the UE100 in an RRC inactive state may receive SIB1 or a new SIB and retrieve the value tag from the received SIB1 or new SIB. In this case, SIB1 or the new SIB may contain a set of session identifiers and value tags.

[0163] In step S338, the UE100 in the RRC inactive state compares the value tag of the RRC inactive PTM setting it holds (set in step S334) with the value tag obtained in step S337.

[0164] If the value tags match, UE100 maintains the PTM setting for RRC inactive that it has been holding and continues to receive MTCH for multicast session #1 (step S341).

[0165] On the other hand, if the value tag is mismatched or the value tag could not be obtained (not provided), UE100 recognizes that there has been an update to the RRC inactive PTM setting and receives the multicast MCCH (and the new SIB if necessary) (steps S339, S340). Here, UE100 may obtain the new SIB for multicast MCCH reception (step S339). UE100 receives the multicast MCCH (step S340), obtains and applies the latest RRC inactive PTM setting (second PTM setting) provided in the multicast MCCH, and continues receiving the MCCH for multicast session #1 (step S341).

[0166] (5.3) Second example of operation In the second example of the third operation pattern, instead of the value tag described above, PTM setting update information, which is 1-bit flag information, is used. A gNB200 that has changed the RRC inactive PTM setting may notify the UE100 of the change in the RRC inactive PTM setting corresponding to the session identifier by sending the session identifier and the PTM setting update information associated with the session identifier in a group notification or new SIB. Alternatively, a gNB200 that has changed the RRC inactive PTM setting may notify the UE100 indicated by the UE identifier of the change in the RRC inactive PTM setting by sending the UE identifier and the PTM setting update information associated with the UE identifier in a group notification.

[0167] Figure 13 shows an example of the second operation example of the third operation pattern of the embodiment. The operation example in Figure 13 is based on Scenario 1, which uses the second operation pattern described above. However, the second operation pattern described above assumed that the RRC inactive PTM setting configured in the RRC Release message for the inactive multicast session #1 would not be changed when the session was activated. In contrast, the operation example in Figure 13 assumes that the RRC inactive PTM setting configured in the RRC Release message is changed when the session is activated (i.e., an update is required). Note that redundant explanations of operations similar to the second operation pattern described above will be omitted.

[0168] In step S351, UE100 is in the RRC connected state in the gNB200 cell.

[0169] In step S352, UE100, in the RRC connected state, joins multicast session #1. Here, UE100 joins multicast session #1 through communication with CN20 (e.g., NAS signaling). However, network 5 has not yet activated multicast session #1.

[0170] In step S353, gNB200 sends an RRC Release message containing the suspend settings to UE100 in the RRC Connected state. UE100 in the RRC Connected state receives the RRC Release message. The RRC Release message further includes the PTM settings for RRC inactive (first PTM settings) for multicast session #1. The PTM settings for RRC inactive may be included in the suspend settings. These PTM settings may be separate information elements from the suspend settings.

[0171] In step S354, the UE100 in the RRC connected state retains the PTM setting for RRC inactive that was received in step S353.

[0172] In step S355, UE100 transitions from the RRC connected state to the RRC inactive state.

[0173] In step S356, the UE100, which is in an RRC inactive state, starts paging monitoring.

[0174] In step S357, the gNB200 may decide to change the PTM setting for RRC inactive of multicast session #1 based on the wireless conditions of its own cell.

[0175] In step S358, network 5 activates multicast session #1.

[0176] In step S359, the gNB200 sends a paging message (group notification) containing the session identifier of multicast session #1.

[0177] When the gNB200 changes the PTM configuration, it includes a 1-bit PTM configuration update information in the group notification along with the session identifier (and UE identifier). The PTM configuration update information may indicate whether or not there has been a PTM configuration update for RRC inactivity. The PTM configuration update information may also indicate whether or not multicast MCCH acquisition is required. In the group notification, the PTM configuration update information may be associated with the session identifier (or UE identifier). For example, the group notification may include PTM configuration update information for each entry in the Paging Group List, which is a list of session identifiers. The group notification is a list of UE identifiers. P PTM configuration update information may be included on an entry-by-entry basis in the Paging Record List. Furthermore, the PTM configuration update information may be structured as a bitmap, where each bit of the bitmap references (points to) each entry in the Paging Record List or Paging Group List (i.e., each UE identifier or each session identifier).

[0178] In step S360, UE100, which is in an RRC inactive state, may recognize that multicast session #1, in which it is a participant, has been activated, based on the session identifier included in the group notification. UE100 may also determine that an update to the PTM configuration of multicast session #1 is necessary if the group notification includes PTM configuration update information associated with that session identifier. Furthermore, UE100 may determine that an update to its own PTM configuration (the PTM configuration of multicast session #1) is necessary if the group notification includes a UE identifier identical to its own, and also includes PTM configuration update information associated with that UE identifier.

[0179] If the PTM setting update information is not included in the group notification, the UE100 in the RRC inactive state will apply any PTM settings for RRC inactivity that it has already applied, and will start receiving the MTCH for multicast session #1 (step S363). In other words, the UE100 will start receiving the MTCH without receiving the multicast MCCH and / or new SIB.

[0180] On the other hand, if the PTM setting update information is included in the group notification, the UE100 in the RRC inactive state recognizes that there has been an update to the PTM setting for RRC inactive and receives the multicast MCCH (and new SIB if necessary) (steps S361, S362). The UE100 obtains and applies the latest PTM setting for RRC inactive from the received multicast MCCH and starts receiving the MTCH for multicast session #1 (step S363).

[0181] In this example, if the RRC Release message in step S353 does not include the PTM settings for RRC inactivity, UE100 may consider that an update has occurred to the PTM settings for RRC inactivity, even if the PTM setting update information is not included in the group notification.

[0182] Figure 14 shows another example of the second operation example of the third operation pattern of the embodiment. This operation example is based on scenario 2 described above. Note that redundant explanations of operations similar to those in Figure 13 are omitted.

[0183] In step S371, network 5 activates multicast session #1.

[0184] In step S372, UE100 transitions from the RRC connected state to the RRC inactive state.

[0185] In step S373, gNB200 sends a new SIB containing the multicast MCCH configuration. UE100, in an RRC inactive state, receives the new SIB.

[0186] In step S374, gNB200 sends the RRC inactive PTM setting for multicast session #1 over the multicast MCCH. UE100, in the RRC inactive state, receives the RRC inactive PTM setting based on the new SIB and retains the received RRC inactive PTM setting as the first PTM setting.

[0187] In step S375, gNB200 transmits the MBS data for multicast session #1 over the MTCH. UE100, in an RRC inactive state, receives the MBS data for multicast session #1 over the MTCH based on the PTM settings for RRC inactive.

[0188] In step S376, gNB200 may decide to change the PTM setting for RRC inactive for multicast session #1 based on the wireless conditions of its own cell. gNB200 increments (i.e., adds 1 to) the value tag of the changed PTM setting for RRC inactive.

[0189] In step S377, the gNB200 sends a paging message (group notification) containing the session identifier for multicast session #1. If the gNB200 changes the PTM configuration, it includes 1 bit of PTM configuration update information in the group notification along with the session identifier (and UE identifier). The description of the PTM configuration update information is the same as the operation shown in Figure 13.

[0190] In step S378, UE100 may determine that an update to the PTM settings for multicast session #1 is necessary if the group notification includes PTM setting update information associated with the session identifier of multicast session #1. UE100 may also determine that an update to its own PTM settings (PTM settings for multicast session #1) is necessary if the group notification includes a UE identifier identical to its own, and the group notification includes PTM setting update information associated with that UE identifier.

[0191] If the PTM setting update information is not included in the group notification, UE100 maintains its existing PTM settings for RRC inactivity and continues to receive MTCH for multicast session #1 (step S381).

[0192] On the other hand, if the PTM setting update information is included in the group notification, UE100 recognizes that there has been an update to the PTM setting for RRC inactive and receives the multicast MCCH (and the new SIB if necessary) (steps S379, S380). Here, UE100 may also acquire the new SIB in order to receive the multicast MCCH (step S379). UE100 receives the multicast MCCH (step S380), acquires and applies the latest PTM setting for RRC inactive (second PTM setting) provided in the multicast MCCH, and continues to receive the MTCH for multicast session #1 (step S381).

[0193] (6) Other embodiments In the embodiments described above, multicast reception in the RRC inactive state was mainly explained, but the operation according to the embodiments described above may also be applied to multicast reception in the RRC idle state. In the case of the RRC idle state, the above-described RRC resume is read as RRC establishment.

[0194] Each of the above-described operation flows can be performed not only independently, but also in combination of two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow. It is not necessary to execute all steps in each flow; only some steps may be executed.

[0195] In the embodiments and examples described above, an example in which the base station is an NR base station (gNB) was described, but the base station may also be an LTE base station (eNB) or a 6G base station. Furthermore, the base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of an IAB node. Furthermore, UE100 may be an MT (Mobile Termination) of an IAB node.

[0196] In other words, UE100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that performs signal relay. Such a terminal function unit is called an MT. Examples of MTs other than IAB-MT include NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.

[0197] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or a part of a base station (CU, DU, or RU). Additionally, a network node may consist of a combination of at least a part of the core network device and at least a part of a base station.

[0198] A program may be provided that causes a computer to execute each process performed by the UE100 or gNB200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE100 or gNB200 may be integrated, and at least a part of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0199] The functions realized by UE100 or gNB200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, and means are hardware programmed to realize or perform the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or perform the described functions. If such hardware is a processor that is considered to be a type of circuitry, then such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0200] The phrases “based on” and “depending on / in response to” used in this disclosure do not mean “based solely on” or “depending solely on” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending on” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that only the listed items are included; they mean that only the listed items may be included, or that additional items may be included in addition to the listed items. Furthermore, the term “or” used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated by the context that they are not.

[0201] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0202] This application claims priority to U.S. Provisional Application No. 63 / 494316 (filed April 5, 2023), the entirety of which is incorporated into the specification of this application.

[0203] (7) Appendix A The features of the above-described embodiment are noted below.

[0204] (Note 1) A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), The steps include receiving a first PTM setting from the network for receiving multicast sessions in a Wireless Resource Control (RRC) inactive state, and retaining the first PTM setting, In the RRC inactive state, the step of determining whether or not it is necessary to update the first PTM setting in response to receiving a paging message from the network that includes the session identifier of the multicast session, The method includes the step of obtaining a second PTM setting to be used for receiving the multicast session by receiving a multicast control channel (MCCH) for multicast communication in response to a determination that an update of the first PTM setting is necessary in the RRC inactive state. Communication method.

[0205] (Note 2) The steps include receiving an RRC release message that causes the user device to transition to the RRC inactive state while in the RRC connected state, The system further includes the step of transitioning from the RRC connected state to the RRC inactive state in response to the receipt of the RRC release message, The first PTM setting is included in the RRC release message. The communication method described in Appendix 1.

[0206] (Note 3) The aforementioned retention step includes the step of retaining the first PTM setting in association with version information, The aforementioned determination step is, The steps include receiving signaling from the network that includes the latest version information of the PTM settings used to receive the multicast session, The step includes determining whether or not the first PTM setting needs to be updated by comparing the retained version information with the latest version information. The communication method described in Appendix 1 or 2.

[0207] (Note 4) The signaling is the paging message. The communication method described in Appendix 3.

[0208] (Note 5) The signaling is a system information block type 1 transmitted from the network. The communication method described in Appendix 3.

[0209] (Note 6) The signaling is a system information block (SIB) indicating the configuration of the MCCH for multicast communication. The communication method described in Appendix 3.

[0210] (Note 7) The aforementioned determination step includes determining that if the latest version information is not included in the signaling, an update to the first PTM setting is required. The communication method described in any of the appendices 3 to 6.

[0211] (Note 8) The steps include receiving an RRC release message that causes the user device to transition to the RRC inactive state while in the RRC connected state, The system further includes the step of transitioning from the RRC connected state to the RRC inactive state in response to the receipt of the RRC release message, The aforementioned determination step includes determining that an update of the first PTM setting is necessary based on the fact that the first PTM setting is not included in the RRC release message. The communication method described in any of the appendices 1 through 7.

[0212] (Note 9) The aforementioned determination step includes determining whether an update to the first PTM setting is necessary, depending on whether the paging message or system information block contains PTM setting update information. The communication method described in Appendix 1 or 2.

[0213] (Note 10) The paging message includes a user device identifier associated with the session identifier, In the aforementioned paging message, the PTM setting update information is associated with the user device identifier. The communication method described in Appendix 9.

[0214] (Note 11) In the aforementioned paging message, the PTM setting update information is associated with the session identifier. The communication method described in Appendix 9.

[0215] (Note 12) The system information block includes the session identifier, In the aforementioned system information block, the PTM setting update information is associated with the session identifier. The communication method described in Appendix 9.

[0216] (Note 13) User equipment used in a mobile communication system that provides multicast / broadcast services (MBS), The process involves receiving a first PTM setting from the network for receiving multicast sessions in a Wireless Resource Control (RRC) inactive state, and also maintaining the first PTM setting. In the RRC inactive state, a process is performed to determine whether or not the first PTM setting needs to be updated in response to receiving a paging message containing the session identifier of the multicast session from the network, The control unit includes, in the RRC inactive state, a control unit that, upon determining that an update of the first PTM setting is necessary, receives a multicast control channel (MCCH) for multicast communication and performs a process to obtain the second PTM setting used for receiving the multicast session. User device.

[0217] (8) Appendix B1. Introduction The work item concerning enhanced MBS (eMBS) aims to support multicast reception by UEs in inactive states and is described as follows: • Multicast by UE in RRC inactive state session [RAN2, RAN3] specifies support for receiving data. • Multicast in RRC inactive state session PTM settings for the receiving UE [RAN2]. • RRC inactive with multicast session Investigate the impact of the UE's mobility and state transitions on receiving data. (Seamless / lossless mobility is not required) [RAN2, RAN3].

[0218] RAN2 has discussed this objective and reached a series of agreements. Building upon these agreements, aspects of multicast reception notification and RRC state transitions in the inactive state are discussed in this appendix.

[0219] 2. Discussion Regarding the change in the RRC state in RAN2#119e, further consideration is needed.

[0220] Rel-18 supports multicast reception for UEs in inactive states, assuming the UE already has a valid PTM configuration, at least the following scenarios: Scenario 1: The UE is connected and receiving multicast, but becomes inactive and continues to receive multicast. Scenario 2: The UE joined a multicast session and was redirected to inactive.

[0221] Further consideration is needed if the situation changes, such as when service provision in an inactive state is terminated.

[0222] From a network and UE perspective, there are several possible cases related to changes in the RRC state. There are also cases involving notifications sent from the network to the UE. Therefore, we will discuss each case separately below.

[0223] 2.1. Case 1: Deactivation / Release of a multicast session RAN2#119bis-e agrees to notify the UE when a multicast session is deactivated, and the Rel-17 mechanism is applied when the multicast session is released. • If a UE is in RRC inactive and configured to receive multicast sessions in RRC inactive, the UE may be notified when a multicast session becomes inactive. Further investigation is needed. The method of notification (e.g., group paging, MCCH, or other methods) is also needed. • The Rel-17 mechanism (NAS-based display) applies to multicast session releases. Further consideration is needed if additional functionality is required.

[0224] If an inactive UE is receiving MBS services, it is likely that the multicast session has stopped or been released, and accordingly the gNB has stopped sending PTM / MTCH. In this case, there is no reason for the UE to continue monitoring MTCH, but unless the PTM setting is deleted, the UE must continue monitoring MTCH. From the perspective of UE power saving, it is desirable to stop monitoring MTCH as soon as possible.

[0225] Finding 1: Continuing for the UE to monitor PTM / MTCH after a multicast session has been stopped or released is inefficient from the perspective of UE power consumption.

[0226] In other words, the UE should be permitted to stop monitoring the MTCH when it receives a multicast session invalidation notice, regardless of how it was notified. Furthermore, upon receiving such a notice, the UE should maintain the RRC inactive state.

[0227] Proposal 1: RAN2 should agree that the UE should stop monitoring the MTCH when it receives a multicast session invalidation notification.

[0228] Regarding the deactivation of multicast sessions, RAN2 needs further consideration on how to notify the UE, for example, through group paging, MCCH, or other methods.

[0229] In LTE SC-PTM, an SC-PTM Stop Indication MAC CE was introduced to notify the UE of stopping monitoring the PDCCH of a G-RNTI, with the MAC CE multiplexed to the SC-MTCH associated with the G-RNTI. This light-weight signaling may work under the constraint that TMGI and G-RNTI are mapped one-to-one. On the other hand, NR MBS allows many-to-one mapping between TMGI and G-RNTI, so if a MAC CE is introduced, it should indicate a deactivated TMGI. Since the MAC CE is transmitted with the MTCH, it is expected that the delay between receiving the last multicast data and stopping MTCH monitoring can be minimized.

[0230] Another option is to reuse group paging. Group paging is used to page multiple UEs within a group simultaneously, using TMGI instead of UE-ID. Since the existing paging group list (i.e., the list of TMGIs) applies to legacy UEs, group paging requires adding a new TMGI list for deactivation notifications to avoid impacting legacy UEs. Because group paging is sent on paging occasions, based on the I-DRX cycle, there will be some delay between receiving the last multicast data and stopping MTCH monitoring.

[0231] A third option is to reuse the MCCH. There are two ways to notify of the termination of a multicast session: deleting the PTM settings for the terminated TMGI, or adding a new indication to notify of the terminated TMGI. In either case, the MCCH needs to be updated, so an MCCH change notification must be sent to the UE in advance. Therefore, a longer delay is required between the reception of the last multicast data and the termination of the MCCH monitor.

[0232] According to the RAN2 agreement that "MCCH is used when PTM settings need to be changed," an inactive UE should wake up via MCCH, and stopping a multicast session can be interpreted as a kind of "PTM setting change." Therefore, if the corresponding PTM setting is removed from MCCH, the UE can notice that the multicast session has been deactivated. However, it takes time for the UE to stop monitoring MCCH. Therefore, notification via MAC CE is desirable.

[0233] In summary, the delay between receiving the last multicast data and stopping MTCH monitoring can directly impact the UE's power consumption. From a UE power saving perspective, notifications need to be sent as quickly as possible, making MAC CE the preferred first choice and solution.

[0234] Proposal 2: RAN2 should agree that when a multicast session becomes inactive, a new MAC CE (similar to the existing SC-PTM Stop Indication) should be notified to the UE in inactivity.

[0235] Regarding the release of multicast sessions, the Rel-17NAS-based representation agreed upon by RAN2 applies, which may be "Multicast session requested by network or MBS session release." This procedure assumes that the UE is paged by the gNB and transitions to RRC Connected to communicate with the AMF. This procedure assumes that existing group paging (or legacy individual paging) can be reused.

[0236] In other words, the gNB can send a MAC CE to the UE to stop monitoring the MTCH, and then the gNB can distribute the page timing to the UE (i.e., use legacy individual paging) to avoid a signaling storm caused by simultaneous RRC state transitions.

[0237] Proposal 3: RAN2 should agree that no feature enhancements specifically for multicast session release are necessary; in other words, UEs should transition to RRC Connected via existing (group) paging.

[0238] 2.2. Case 2: Selective transition during multicast session activation RAN2#119e reached the following agreements regarding Case 2. Whether a multicast session can be received by an inactive UE(s) depends on the gNB. Further consideration is needed regarding what information should be provided to the gNB to make such a decision (related to the SA2 discussion). • gNBs are supported for sending a single multicast session to both connected and inactive UEs within the same cell. Further investigation is needed to determine how gNBs configure this. The network is assumed to be able to choose which UEs receive RRC inactive and RRC connective states, and to be able to move UEs between states to receive multicast services.

[0239] When gNB inactively releases a UE, gNB can select which UE to release based on UE capabilities, UE assistance information, and / or CN assistance information (if specified), as it does now, i.e., via RRC Release with Suspend Config. Therefore, no enhancements for selective UE transitions are anticipated with respect to RRC release messages.

[0240] Finding 2: Existing RRC releases are used by gNB to select which UE to release.

[0241] Regarding multicast session activation, RAN2#119bis-e agreed to the following description: • When a Rel-18 session becomes active, it can notify the UE in an inactive state (further investigation is needed for details). • As a baseline, group paging can be used to notify the Rel-18UE of session activation (further investigation is needed for details such as the UE's behavior when receiving such a group notification). Further consideration is needed regarding how the UE determines whether it can receive a multicast session with RRC inactive when the session is activated, taking into account the following solutions (which can be updated if necessary; some solutions may be required, while others may only apply to specific configuration options).

[0242] 1. When a multicast session becomes active, the UE can receive the multicast session in RRC Inactive if the PTM configuration used for the session is available to the UE and the UE is already participating in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), but otherwise it will revert to RRC Connected to receive the multicast session. 2. When a multicast session becomes active, the UE is indicated by group paging whether or not it can receive the multicast session with RRC inactive (further investigation is needed regarding detailed signaling). 3. Before the UE is released, it is configured via dedicated signaling to determine whether it can receive multicast sessions while RRC is inactive. When a multicast session becomes active, the UE either remains RRC inactive or reactivates the RRC connection accordingly (further consideration is needed regarding the detailed signaling).

[0243] In Rel-17, multicast session activation is notified by group paging. In Rel-18, there is no need to differ from the legacy mechanism, so RAN2 needs to ensure that group paging is used to notify multicast session activation.

[0244] Proposal 4: RAN2 needs to be able to use group paging to notify Rel-18UE of session activation.

[0245] In addition to verification, RAN2 identified three options for how the UE should behave upon receiving a multicast activation notification, as mentioned above.

[0246] In Option 1, if the UE has a valid PTM configuration, the UE can receive multicast sessions while inactive. Since a UE in inactive cannot receive multicast sessions without a PTM configuration, this can be considered the baseline behavior for all other UEs. Therefore, we should agree on Option 1.

[0247] Proposal 5: RAN2 should agree on option 1 for UE behavior: "When a multicast session is activated, if the PTM configuration used for the session in RRC inactive is available to the UE and the UE is already in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), the UE can receive the multicast session in RRC inactive; otherwise, it should revert to RRC connected to receive the multicast session."

[0248] In option 2, when the UE receives group paging, it is indicated whether or not it should accept the multicast session in an inactive state.

[0249] In option 3, the UE is given prior indication of whether or not it should receive the multicast session in an inactive state by reconfiguring or releasing the RRC.

[0250] The mechanisms of the two options are very similar, except for the message that instructs the UE to do so. Therefore, these options can be analyzed in terms of the motivation for multicast reception in an inactive state, namely network congestion and UE power saving.

[0251] In the case of network congestion, the cell load is expected to change moment by moment. In option 2, since instructions are sent within group paging, the gNB can consider the latest load situation when deciding whether the UE should remain inactive. On the other hand, in option 3, the gNB needs to predict the future load when sending instructions to the UE, so the cell load may change at the time the gNB actually sends the group paging. Therefore, there is a risk that, for example, more UEs may transition to connected even if congestion worsens, or more UEs may remain inactive even if congestion is resolved. For this reason, option 2 is preferable for efficiently controlling the RRC state of UEs.

[0252] From the perspective of UE power saving, it is expected that some kind of "power saving preference" will be introduced into the UE assistance information. Such preference indications can only be sent from connected UEs and cannot be sent to inactive UEs. Therefore, when a UE was previously connected, the gNB can indicate to the UE whether or not it is allowed to receive multicast sessions in an inactive state. If such a preference indication is not introduced, the gNB will not know whether the UE prefers power saving or not, and can therefore display it to the UE at any time. In other words, there is no difference between option 2 and option 3.

[0253] Based on the above analysis, option 2 is considered more efficient and can cover the usage of option 3. Therefore, RAN2 should agree to at least option 2.

[0254] Proposal 6: RAN2 should agree on UE operation option 2, "When the multicast session is activated, the UE can receive the multicast session in RRC inactive as indicated by group paging (further study is required for detailed signaling)".

[0255] That is, when the TMGI of interest is included in the paging message, all UEs start the RRC Resume procedure. If selection 2 is selected and selective paging is required, the gNB cannot include the TMGI in the paging message. If the gNB includes only the UE-ID for selective paging (i.e., legacy individual paging without TMGI for paging the selected Rel-18 UEs), it cannot page Rel-17 UEs waiting for the activation of multicast in inactive. Furthermore, it is also inefficient in terms of signaling overhead.

[0256] That is, when the TMGI of interest is included in the paging message, all UEs transition to RRC connected.

[0257] Assuming that the current paging group list is set in the group paging message for paging at least Rel-17 UEs, Rel-18 UEs are also paged by the TMGI of interest. Therefore, in order for the selected UE not to RR transition to connected, it is conceivable to define a new list of UE-IDs, the "paging cancellation list" (or "inactive permission list"), and keep the UEs listed in this list inactive so that they can receive the multicast session.

[0258] Therefore, RAN2 needs to discuss ways to enhance group paging for paging a subset of UEs.

[0259] Proposal 7: RAN2 should discuss how to enhance group paging to page a subset of UEs, for example, by using a new UE-ID list to remain inactive in multicast session reception.

[0260] 2.3. Case 3: Implementing QoS RAN2#119e reached the following agreements relating to Case 3: HARQ feedback and PTP are not supported for multicast reception with RRC inactive.

[0261] According to the agreement, multicast reception in inactive mode is similar to MBS broadcast reception (so-called distribution mode 2) as defined in Rel-17. MBS broadcast is best-effort.

[0262] On the other hand, ensuring QoS / reliability is a critical issue for multicast sessions. SA2 also questioned whether there is a difference in the quality / reliability of multicast reception in connected and inactive states, and RAN2#119bis-e agreed to the following answer.

[0263] RAN2(Q1-a)When there is a significant difference in the quality and reliability of MBS data reception between UEs in the RRC connected state and UEs in the RRC inactive state: The quality and reliability of MBS data reception between UEs in RRC-connected and RRC-inactive states may differ because HARQ feedback and PTP transmission are not supported, and seamless / lossless mobility is not required for multicast reception in RRC-inactive states.

[0264] RAN2#119e proposes introducing receive quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. It is also useful for the network to manage QoS requests. If multicast reception in an inactive state fails to meet the corresponding QoS requirements, the UE must transition to connected mode to utilize HARQ feedback / retransmission and / or PTP (or split MRB) to guarantee receive quality.

[0265] Finding 4: Multicast sessions need to ensure certain QoS requirements even when the UE is inactive.

[0266] Regarding RSRP thresholds, since NR MBS assumes single-cell transmission, it is thought that the UE needs to transition to connected mode every time it moves to the cell edge or performs cell reselection. This may not be optimal operation depending on the deployment, considering network congestion and UE power saving.

[0267] Regarding the BLER threshold, it is considered a simpler approach to ensure QoS requirements. Therefore, if RRC state transitions based on receive quality are to be introduced, these options need to be discussed.

[0268] Proposal 8: RAN2 should agree that if the reception quality falls below a threshold (e.g., RSRP or BLER), the UE in an inactive state should transition to a connected state.

[0269] 2.4. Case 4: Updating PTM settings In RAN2#120, it was agreed that MCCH should be used when it is necessary to update the PTM settings.

[0270] We will take a "mixed approach" and begin as follows: 1. If the NW configures the UE to continue receiving multicast while inactive, the NW will provide PTM settings for the activated multicast session through RRC-dedicated signaling, at least for the serving cell (further consideration is needed for other cases). 2. MCCH is used when PTM settings need to be changed or when PTM settings need to be displayed during travel beyond the serving cell / gNB. Further consideration is needed for changing session status and other displays. 3. Assume that the UE can receive multicast services only after joining a session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE through dedicated signaling.

[0271] RAN2#121 agreed to use RRC release for PTM configuration (even before session activation) and to introduce a new MCCH (different from Rel-17MCCH). • The UE must join a multicast session before it can receive multicast in RRC inactive. If the network is deemed useful, the UE can configure the PTM settings for a (single) serving cell before the session is activated, and the UE can save those settings. Once the session is activated, the UE can apply the settings and receive multicast in an inactive state without reverting to RRC Connected, unless updated by MCCH after configuration. • If the UE configures multicast reception when the network is inactive, the PTM configuration can be delivered using RRC release messages, including suspendconfig. Other dedicated RRC messages are not used to provide PTM configuration for MBS multicast when inactive. • Introduce a new MCCH logical channel for multicast in inactive mode (different from broadcast MCCH).

[0272] According to these agreements, there are two cases for PTM configuration updates: · Case 1: For an inactive UE that is already receiving an activated multicast session; · Case 2: For an inactive UE waiting for the activation of a multicast session: · Note: Case 2 can be further classified according to whether the PTM configuration is provided by RRC release.

[0273] In such cases, it is desirable that the solutions be as common as possible.

[0274] Proposal 9: RAN2 should aim for a common solution for the notification of PTM configuration updates, considering at least two cases: the already activated session and the session before activation.

[0275] That is, the UE cannot maintain an inactive state to obtain the updated PTM configuration. Therefore, from the perspective of an inactive UE, the new PTM configuration delivery method in Rel-18 is similar to Delivery Mode 2 in Rel-17. In this case, it is considered appropriate to reuse the existing MCCH change notification to notify the update of the PTM configuration.

[0276] However, in the MCCH change notification, the UE needs to be woken up once for each MCCH change boundary, which causes an additional burden in addition to monitoring the paging occasion. Also, the MCCH change notification is not efficient, especially in Case 2 above (i.e., to confirm whether the PTM configuration provided by RRC release has been updated, the UE needs to monitor the MCCH change notification even if it only waits for the multicast session notification).

[0277] To address these issues, group paging is expected to be enhanced for PTM configuration update notifications. The UE would only need to monitor paging opportunities to determine whether a PTM configuration update has occurred, regardless of whether the UE is receiving a multicast session (i.e., case 1 or case 2 above). Therefore, RAN2 needs to agree to use group paging for this notification. Further consideration is required for details of the enhancement.

[0278] Proposal 10: RAN2 should agree to use group paging for PTM configuration updates instead of existing MCCH change notifications.

[0279] 2.5. Case 5: Service continuity upon RRC resumption It is necessary to consider the possibility that a UE that is already receiving a multicast session in an inactive state (i.e., via a broadcast MRB or a new MRB for receiving multicast in an inactive state) may be paged and initiate the RRC Resume procedure. After transitioning to Connected, the UE naturally wants to continue receiving the same multicast session. However, in this case, the UE has two MRBs for the same multicast session: a broadcast MRB (or a new MRB) configured for receiving multicast in an inactive state, and a multicast MRB that has been resumed for receiving multicast in a Connected state.

[0280] In Rel-17, multicast sessions could only be received via a multicast MRB configured by RRC reconfiguration. In contrast, in Rel-18, it is expected that UEs will be able to receive multicast sessions via a broadcast MRB (or a new MRB) configured by RRC reconfiguration or a new MCCH.

[0281] It is thought that the UE should use multicast MRBs for reception after transitioning to connected (similar to Rel-17). However, it is unclear how the UE switches between these MRBs, when the UE discards broadcast MRBs (or new MRBs), and how the UE should behave (i.e., from the perspective of the lossless principle) if the multicast MRB is an AM MRB. Therefore, RAN2 needs to discuss the UE's behavior when RRC is restarted, from the perspective of MRB processing and the continuity of multicast session service.

[0282] Proposal 11: RAN2 should discuss the behavior of the UE when RRC is resumed during continuous reception of a multicast session (such as the handling of broadcast MRB and multicast MRB). [Explanation of Symbols]

[0283] 1: Mobile communication systems 5: Network 10: RAN 20:CN 100: UE (User Device) 110: Receiving unit 120: Transmitter 130: Control Unit 200:gNB (base station) 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department

Claims

1. A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), In a Radio Resource Control (RRC) inactive state, it is determined whether predetermined conditions are met upon receiving a paging message containing the session identifier of a multicast session from a network node, In the RRC inactive state, the system obtains configuration information used for receiving the multicast session in the RRC inactive state by receiving a multicast control channel (MCCH) for multicast communication in accordance with the predetermined conditions being met. Communication method.

2. In the RRC connected state, receiving an RRC release message that transitions the user device to the RRC inactive state, The system further includes transitioning from the RRC connected state to the RRC inactive state in response to the receipt of the RRC release message, The aforementioned predetermined conditions include the condition that the setting information is not included in the RRC release message. The communication method according to claim 1.

3. A user device for use in a mobile communication system that provides multicast / broadcast services (MBS), A control unit that determines whether predetermined conditions are met in response to receiving a paging message containing the session identifier of a multicast session from a network node while the Radio Resource Control (RRC) is inactive, The receiving unit has, in the RRC inactive state, a multicast control channel (MCCH) for multicast communication that receives when the predetermined conditions are met, thereby acquiring configuration information used for receiving the multicast session in the RRC inactive state. User device.

4. A program for a user device used in a mobile communication system that provides multicast / broadcast services (MBS), wherein the user device provides: In a Wireless Resource Control (RRC) inactive state, a process is performed to determine whether predetermined conditions are met upon receiving a paging message containing the session identifier of a multicast session from a network node, and In the RRC inactive state, the system performs a process to obtain configuration information used for receiving the multicast session in the RRC inactive state by receiving a multicast control channel (MCCH) for multicast communication in accordance with the predetermined conditions being met. program.

5. A chipset for user equipment used in a mobile communication system that provides multicast / broadcast services (MBS), In a Wireless Resource Control (RRC) inactive state, a process is performed to determine whether predetermined conditions are met upon receiving a paging message containing the session identifier of a multicast session from a network node, and In the RRC inactive state, the process of receiving a multicast control channel (MCCH) for multicast communication in accordance with the predetermined conditions is performed, thereby obtaining configuration information used for receiving the multicast session in the RRC inactive state. Chipset.

6. A system used in a mobile communication system that provides multicast / broadcast services (MBS), comprising a user device and a network node, The User device is A control unit that determines whether predetermined conditions are met in response to receiving a paging message containing the session identifier of a multicast session from the network node while the Radio Resource Control (RRC) is inactive, The receiving unit has, in the RRC inactive state, a multicast control channel (MCCH) for multicast communication that receives when the predetermined conditions are met, thereby acquiring configuration information used for receiving the multicast session in the RRC inactive state. The aforementioned network node is The system includes a transmission unit that transmits the paging message to the user device in the RRC inactive state. system.

Images