Communication methods, user devices, chipsets for user devices, mobile communication systems, and programs

Abstract

This communication method, which is executed by a user device in a mobile communication system for providing a multicast / broadcast service (MBS), comprises: a step for receiving, from a network node, a radio resource control (RRC) release message including setting information of a multicast inactive / multicast radio bearer (MRB) used for receiving a multicast session in an RRC inactive state, and causing the user device to transition to the RRC inactive state; a step for confirming whether state information related to whether the multicast session is activated is included in the RRC release message; and a step for, if the state information is not included in the RRC release message, starting multicast reception processing that uses the multicast inactive MRB on the basis of the setting information.

Description

Communication Method

[0001] The present disclosure relates to a communication method for use in a mobile communication system.

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

[0003] In 3GPP Release 17, reception of MBS multicast (i.e., multicast reception) is possible only for user equipment in a 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 an RRC inactive state can perform multicast reception.

[0004] 3GPP Technical Specification: TS 38.300 V17.5.0

[0005] A communication method according to a first aspect is a method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), the communication method comprising the steps of: receiving, from a network node, a radio resource control (RRC) release message including PTM setting information used for receiving a multicast session in an RRC inactive state, the RRC release message causing the user equipment to transition to the RRC inactive state; checking whether the RRC release message includes predetermined information indicating that start of multicast reception processing for the multicast session is to be suspended; and, if the predetermined information is not included in the RRC release message, starting the multicast reception processing based on the PTM setting information.

[0006] A communication method according to a second aspect is a method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), the communication method comprising the steps of: receiving a multicast session using a multicast-multicast radio bearer (MRB) in a radio resource control (RRC) connected state; receiving an RRC release message from a network node, the RRC release message including configuration information of a multicast inactive MRB used for receiving the multicast session in an RRC inactive state, and causing the user equipment to transition to the RRC inactive state; checking whether the multicast inactive MRB corresponding to the multicast MRB has been configured; and, if the multicast inactive MRB corresponding to the multicast MRB has been configured, starting a multicast reception process using the multicast inactive MRB.

[0007] A communication method according to a third aspect is a method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), the communication method comprising the steps of: receiving, from a network node, an RRC release message including configuration information of a multicast inactive / multicast radio bearer (MRB) used for receiving a multicast session in an RRC inactive state, the RRC release message causing the user equipment to transition to the RRC inactive state; attempting to receive the multicast session using the multicast inactive MRB based on pre-stored upper layer information; and, if the attempt to receive the multicast session is successful, continuing multicast reception processing using the multicast inactive MRB.

[0008] 1 is a diagram showing an example of the configuration of a mobile communication system according to an embodiment. FIG. 2 is a diagram showing an example of the configuration of a UE (user equipment) according to an embodiment. FIG. 3 is a diagram showing an example of the configuration of a gNB (network node) according to an embodiment. FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). FIG. 6 is a diagram showing an example of the operation of a mobile communication system according to a first operation pattern of an embodiment. FIG. 7 is a diagram showing an example of the operation of a mobile communication system according to a second operation pattern of an embodiment. FIG. 8 is a diagram showing an example of the operation of a mobile communication system according to a third operation pattern of an embodiment. FIG. 9 is a diagram showing an initial setting procedure for a connected UE.

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

[0010] (1) System Configuration Example Fig. 1 is a diagram showing a configuration example of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). Although 5GS will be described below as an example, the mobile communication system may be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may be at least partially based on a 6th Generation (6G) system.

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

[0012] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).

[0013] The NG-RAN 10 includes a base station (referred to as "gNB" in the 5G system) 200, which is a type of network node. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used 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] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.

[0015] The 5GC20 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 controls data forwarding. The AMF and the UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0016] 2 is a diagram illustrating an example configuration of a UE 100 (user equipment) according to an 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 configure a wireless communication unit that performs wireless communication with the gNB 200.

[0017] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal 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 a baseband signal (transmission signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0019] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The operations of the UE 100 described above and below may be operations under the control of 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 in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0020] 3 is a diagram showing an example configuration of a gNB 200 (network node) according to an embodiment. The gNB 200 has a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

[0021] The transmitting unit 210 performs various transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts a 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 a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0023] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer described below. The operations of the gNB 200 described above and below may be operations under the control of 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 in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0024] The backhaul communication unit 240 is connected to adjacent base stations via an Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally divided), and the two units may be connected by an F1 interface, which is a fronthaul interface.

[0025] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.

[0026] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) 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 PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires the successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has a CRC parity bit scrambled by the RNTI added.

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

[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 RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

[0030] The PDCP layer performs header compression / decompression, encryption / decryption, and the like.

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

[0032] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0033] The protocol stack of the radio interface of the control plane has an RRC (Radio Resource Control) layer and an NAS (Non-Access Stratum) layer instead of the SDAP layer shown in FIG.

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

[0035] The NAS layer (also simply referred to as "NAS") located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300A. Note that the UE 100 has an application layer and the like in addition to the radio interface protocol. Also, a layer lower than the NAS layer is referred to as the AS layer (also simply referred to as "AS").

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

[0037] (2.1) MBS Broadcast In the case of a broadcast communication service (also referred to as "MBS Broadcast"), the same service and the same specific content data are simultaneously provided to all UEs 100 in a geographical area. That is, all UEs 100 within the broadcast service area are permitted to receive the data. The broadcast communication service is delivered to the UEs 100 using a broadcast session, which is a type of MBS session. The UEs 100 can receive the broadcast session in any of the following states: RRC idle state, RRC inactive state, and RRC connected state.

[0038] Point-to-Multipoint (PTM) delivery is applied to broadcast communication services. In the case of PTM transmission, the gNB 200 delivers a single copy of an MBS packet to a set (group) of multiple UEs 100. For example, the gNB 200 schedules a group-common PDSCH scrambled by a G-RNTI (Group RNTI), which is a group-common RNTI, using a group-common PDCCH having a CRC (Cyclic Redundancy Code) scrambled by the G-RNTI.

[0039] In the case of a broadcast communication service, the UE 100 receives a broadcast session in the following procedure. First, the UE 100 receives a system information block type 20 (SIB20) from the gNB 200. The SIB20 includes a configuration of a multicast control channel (MCCH), which is a type of logical channel. Second, the UE 100 receives the MCCH from the gNB 200 based on the SIB20. The MCCH includes a PTM configuration. The PTM configuration transmits a configuration (MTCH configuration) for a multicast traffic channel (MTCH), which is a type of logical channel, and a broadcast MRB configuration, 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, the UE 100 receives the MTCH based on the MCCH. The MTCH transmits the broadcast session (specifically, MBS data belonging to the broadcast session).

[0040] The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 5 to the UE 100. The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast session or a broadcast session from the network 5 to the UE 100.

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

[0042] The UE 100 can receive the multicast session only after joining the multicast session (session join). Joining the multicast session may mean being registered in the network 5 (CN 20) as the UE 100 that can receive the multicast session.

[0043] In the case of a multicast communication service, only UEs 100 in an RRC connected state can receive a multicast session in 3GPP Release 17. On the other hand, in 3GPP Release 18, the standard is extended so that UEs 100 in an RRC inactive state can also receive a multicast session.

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

[0045] In the case of a multicast communication service, the UE 100 in the RRC connected state receives a multicast session in the following procedure. First, the UE 100 receives an RRC Reconfiguration message from the gNB 200. The RRC Reconfiguration message is a message transmitted on a dedicated control channel (DCCH). The RRC Reconfiguration message transmits a setting (MTCH setting) for the MTCH for receiving the multicast session and a setting of a multicast MRB, which is an MRB for the multicast session. Second, the UE 100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, MBS data belonging to the multicast session).

[0046] (2.2.2) Multicast Reception in RRC Inactive State The UE 100 in the RRC inactive state can receive a multicast session (specifically, MBS data belonging to the multicast session) using the PTM distribution mechanism.

[0047] In the case of a multicast communication service, the UE 100 in the RRC inactive state can receive a multicast session in the following procedure. First, the UE 100 in the RRC inactive state receives a newly introduced system information block (also referred to as "SIBx") from the gNB 200. The SIBx includes a configuration of a newly introduced MCCH (also referred to as "multicast MCCH"). Second, the UE 100 in the RRC inactive state receives a multicast MCCH from the gNB 200 based on the SIBx. The multicast MCCH includes a PTM configuration. The PTM configuration transmits a configuration for an MTCH for receiving a multicast session (MTCH configuration) and a configuration of a multicast inactive MRB, which is an MRB for receiving a multicast session in the RRC inactive state (multicast inactive MRB configuration). The MTCH configuration may be included in the multicast inactive MRB configuration. Third, the UE 100 in the RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH transmits the multicast session, specifically, the MBS data (i.e., multicast data) belonging to the multicast session.

[0048] When gNB200 configures UE100 to receive a multicast session in an RRC inactive state, it can send a PTM setting (multicast inactive MRB setting) to UE100 using an RRC release message including a suspend setting. In this case, when UE100 receives an RRC release message including a PTM setting from gNB200, it transitions to an RRC inactive state and receives the multicast session in the RRC inactive state (multicast reception processing).

[0049] (2.2.3) Group Notification When there is temporarily no data to transmit to UE 100 in an active multicast session, gNB 200 may transition UE 100 to an RRC inactive state. When the multicast session is deactivated, gNB 200 may transition UE 100 to an RRC idle state or an RRC inactive state.

[0050] A gNB 200 that supports MBS uses a group notification mechanism to notify UEs 100 in an RRC idle state or an RRC inactive state when a multicast session is activated by CN 20. For example, a gNB 200 that supports MBS may use a group notification mechanism to notify UEs 100 in an RRC inactive state when a multicast session has been activated and there is multicast session data to be distributed in the gNB 200.

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

[0052] The group notification paging message includes a session identifier (MBS Session ID) that is used to page all UEs 100 in RRC idle and RRC inactive states that have joined the associated MBS multicast session, i.e., the UEs 100 are not paged individually.

[0053] When UE 100 transitions to the RRC connected state, UE 100 may stop monitoring group notifications related to a particular multicast session. That is, UE 100 stops checking the MBS session ID in paging messages. UE 100 does not monitor group notifications in cases where UE 100 leaves this multicast session, network 5 requests UE 100 to leave, or network 5 releases the multicast session.

[0054] The group notification may be performed using the MCCH or may be performed using an MCCH Change Notification. When the MCCH is used, the determination may be made based on whether or not an MTCH configuration for the MBS session of interest exists in the MCCH. When the MCCH Change Notification is used, the group notification may be notified in a predetermined bit of the DCI.

[0055] (3) Operation of the Mobile Communication System The operation of the mobile communication system 1 according to the embodiment will be described.

[0056] As described above, when the gNB 200 transmits an RRC Release message (specifically, an RRC Release message including a suspend setting) that transitions the UE 100 to the RRC inactive state to the UE 100 in the RRC connected state, the gNB 200 can include in the RRC Release message the PTM setting related to reception of the multicast session in the RRC inactive state. The PTM setting includes setting information of the multicast inactive MRB used for receiving the multicast session in the RRC inactive state.

[0057] There may be cases where the multicast session has not yet been activated at the time when such an RRC Release message is transmitted from the gNB 200 to the UE 100. The UE 100 establishes a multicast inactive MRB with the gNB 200 based on the PTM setting included in the RRC Release message, and starts a reception process for the multicast session (also referred to as a "multicast reception process").

[0058] However, even if the UE 100 starts the multicast reception process in a situation where the multicast session has not yet been activated, the UE 100 cannot receive the multicast session, specifically, the multicast data transmitted on the MTCH. Therefore, even if the UE 100 cannot receive the multicast data, the UE 100 performs the multicast reception process, which causes the UE 100 to waste power.

[0059] The following describes first to third operation patterns for solving these problems. The first to third operation patterns may be implemented independently, or two or more operation patterns may be combined and implemented.

[0060] (3.1) First Operation Pattern In the first operation pattern, the UE 100 receives an RRC Release message from the gNB 200, which includes configuration information (multicast inactive MRB configuration) of a multicast inactive MRB used to receive a multicast session in the RRC inactive state and transitions the UE 100 to the RRC inactive state. The UE 100 checks whether state information (hereinafter also referred to as "session state information") regarding whether the multicast session is activated is included in the RRC Release message. If the session state information is not included in the RRC Release message, the UE 100 starts a multicast reception process using the multicast inactive MRB based on the multicast inactive MRB configuration. That is, when a multicast inactive MRB is configured in the RRC Release message, the UE 100 may establish the multicast inactive MRB by immediately applying the configuration and start a reception process for the MTCH.

[0061] In this way, in the first operation pattern, session state information regarding whether the multicast session is activated may be included in the RRC Release message. This allows the UE 100 to determine whether the multicast session is activated based on the session state information. As a result, the UE 100 can appropriately determine whether to immediately start the multicast reception process. Furthermore, if the session state information is not included in the RRC Release message, the UE 100 can assume that the multicast session is activated and immediately start the multicast reception process.

[0062] In a first operation pattern, when session state information is included in an RRC Release message and the session state information is information indicating that a multicast session is not activated, the UE 100 may suspend the start of a multicast reception process. This prevents the UE 100 from performing a multicast reception process even when it is unable to receive multicast data, thereby reducing the power consumption of the UE 100. Such session state information may be information indicating that a multicast session is not activated. The session state information may be information indicating that a multicast transmission process is suspended (or interrupted). The session state information may be information indicating that the start of a multicast reception process is suspended (or interrupted). For example, the session state information may be information indicating that reception of an MTCH (or a multicast inactive MRB) of a multicast session is not performed or is suspended.

[0063] For example, when the multicast inactive MRB configuration includes information that the multicast session is inactive, the UE 100 may apply at least one of the following 1) to 3): 1) Do not apply the multicast inactive MRB configuration; 2) Do not establish a multicast inactive MRB; 3) Do not start the reception process of the MTCH.

[0064] In a first operation pattern, when session state information is included in the RRC Release message and the session state information is information indicating that a multicast session is activated, the UE 100 may start a multicast reception process. This allows the UE 100 to immediately start a multicast reception process when the multicast session is activated, thereby enabling smooth reception of multicast data. Such session state information may be information indicating that a multicast session is activated. The session state information may also be information indicating that a multicast reception process is to be started.

[0065] In the first operation pattern, the session state information may be associated with a group DRX (Discontinuous Reception) setting applied to reception of one or more multicast sessions. That is, the session state information may be set for each group DRX setting.

[0066] In the first operation pattern, the multicast inactive MRB configuration may include configurations for each of a plurality of multicast inactive MRBs. The session state information may include at least one of information indicating that all of the plurality of multicast inactive MRBs are in an inactive state and information indicating that at least one of the plurality of multicast inactive MRBs is in an active state. For example, the session state information may be information indicating that at least one multicast session is in an active state.

[0067] FIG. 6 is a diagram showing an example of operation of the mobile communication system 1 according to the first operation pattern.

[0068] In step S101, UE 100 is in an RRC connected state in the cell of gNB 200. UE 100 is assumed to have participated in a certain multicast session. UE 100 may have participated in multiple multicast sessions.

[0069] It is assumed that the gNB 200 is aware of the multicast sessions in which the UE 100 has participated and whether each multicast session is activated. The gNB 200 determines to perform reception settings in the RRC inactive state for the multicast session in which the UE 100 is participating.

[0070] In step S102, gNB200 transmits an RRC Release message including a multicast inactive MRB configuration to UE100. UE100 receives the RRC Release message.

[0071] The multicast inactive MRB configuration includes an MRB ID of the multicast inactive MRB to be configured and / or an MBS session ID of a multicast session to be transmitted by the multicast inactive MRB. The MBS session ID may be a TMGI (Temporary Mobile Group Identity). Note that, when the UE 100 participates in multiple multicast sessions, the multicast inactive MRB configuration may include multiple MRB IDs and / or multiple MBS session IDs corresponding to the multiple multicast sessions. Furthermore, the multicast inactive MRB configuration may include a group DRX configuration for configuring group DRX.

[0072] In the first operation pattern, the multicast inactive MRB configuration includes at least one of the following session state information a) to c).

[0073] a) Information indicating inactivity for each multicast session (MBS session ID) or each MRB (MRB ID), or information indicating activity for each multicast session or each MRB. In this way, session state information may be associated with a multicast session or an MRB.

[0074] b) Information indicating that each group DRX setting is inactive. Alternatively, information indicating that each group DRX setting is active. Such information may be associated with an ID (index) of the group DRX. In this way, the session state information may be associated with the group DRX setting.

[0075] c) Information indicating that all multicast sessions are inactive. Alternatively, information indicating that at least one multicast session is active. Here, "all multicast sessions" may mean all of the multiple multicast sessions when the UE 100 participates in multiple multicast sessions. "All multicast sessions" may mean all MBS session IDs included in the multicast inactive MRB configuration.

[0076] In the above a) to c), the information indicating inactivity is information indicating that the start of multicast reception processing is suspended, and may be any of the following information: - Information indicating that the multicast inactive MRB setting is maintained and the multicast inactive MRB setting is not applied; - Information indicating that the multicast inactive MRB setting is applied and the multicast inactive MRB is not established; - Information indicating that the multicast inactive MRB setting is applied and the multicast inactive MRB is established and the MTCH reception processing is not performed; - Information indicating that the multicast inactive MRB is suspended.

[0077] In the above a) to c), the information indicating inactivity is information indicating starting multicast reception processing, and may be any of the following information: - Information indicating applying a multicast inactive MRB setting; - Information indicating establishing a multicast inactive MRB; - Information indicating performing MTCH reception processing.

[0078] In step S103, UE 100 checks whether the multicast session in which UE 100 participates is activated based on the session state information included in the RRC Release message in step S102. UE 100 may check whether to start multicast reception processing for the multicast session in which UE 100 participates based on the session state information included in the RRC Release message in step S102. The multicast reception processing is processing for establishing a multicast inactive MRB by applying a multicast inactive MRB setting and receiving an MTCH associated with the multicast inactive MRB.

[0079] If the multicast session in which UE 100 participates has not been activated (step S103: NO), UE 100 suspends the start of multicast reception processing for the multicast session. Then, in step S104, UE 100 transitions to an RRC inactive state in response to the reception of the RRC Release message in step S102. In this case, UE 100 in the RRC inactive state may monitor the above-mentioned group notification, and when it determines based on the group notification that the multicast session in which UE 100 participates has been activated, it may start the multicast reception processing based on the multicast inactive MRB configuration in step S102.

[0080] On the other hand, if the multicast session in which the UE 100 participates is activated (step S103: YES), in step S105, the UE 100 starts the multicast reception process and establishes a multicast inactive MRB by applying the multicast inactive MRB setting received in step S102. Then, in step S106, the UE 100 transitions to an RRC inactive state in response to receiving the RRC Release message in step S102. In step S107, the UE 100 receives the multicast session (multicast data) from the gNB 200 on the MTCH using the established multicast inactive MRB. Note that the order of steps S105 and S106 may be reversed.

[0081] (3.2) Second Operation Pattern The second operation pattern will be described, focusing mainly on the differences from the first operation pattern described above.

[0082] The second operation pattern is an operation pattern that does not require the above-mentioned session state information. Specifically, in the second operation pattern, the UE 100 determines whether to start or suspend multicast reception processing using the multicast inactive MRB configuration received in the RRC Release message based on the reception status of the multicast session (multicast MRB) in the RRC connected state. That is, the UE 100 that has received the RRC Release message including the multicast inactive MRB configuration determines whether the multicast session transmitted using the configured multicast inactive MRB is active depending on whether the multicast MRB for the RRC connected state has been configured.

[0083] For example, in the second operation pattern, UE100 receives a multicast session using a multicast MRB in the RRC connected state. UE100 receives an RRC Release message from gNB200, which includes a multicast inactive MRB setting and transitions UE100 to the RRC inactive state. Here, UE100 checks whether a multicast inactive MRB corresponding to the multicast MRB used in the RRC connected state has been set. When a multicast inactive MRB corresponding to the multicast MRB used in the RRC connected state has been set, UE100 starts a multicast reception process using the multicast inactive MRB.

[0084] In addition, the multicast inactive MRB corresponding to the multicast MRB used in the RRC connected state may be a multicast inactive MRB having a common MBS session ID with the multicast MRB, or may be a multicast inactive MRB having a common MRB ID with the multicast MRB.

[0085] In the second operation pattern, when a multicast inactive MRB that does not correspond to the multicast MRB used in the RRC connected state is set, the UE 100 may suspend the start of the multicast reception process.

[0086] FIG. 7 is a diagram showing an example of operation of the mobile communication system 1 according to the second operation pattern.

[0087] In step S201, UE 100 is in an RRC connected state in the cell of gNB 200. UE 100 is assumed to have already participated in a certain multicast session. UE 100 may have already participated in multiple multicast sessions.

[0088] In step S202, gNB200 may transmit an RRC Reconfiguration message including a multicast MRB setting for the RRC connected state to UE100. UE100 may receive the RRC Reconfiguration message.

[0089] In step S203, the UE 100 may establish a multicast MRB based on the multicast MRB setting in step S202.

[0090] In step S204, the gNB 200 transmits a multicast session (multicast data) to the UE 100 on the MTCH using the multicast MRB. The UE 100 receives the multicast session using the multicast MRB.

[0091] In step S205, gNB200 transmits an RRC Release message including a multicast inactive MRB setting to UE100. UE100 receives the RRC Release message.

[0092] The multicast inactive MRB configuration includes an MRB ID of the multicast inactive MRB to be configured and / or an MBS session ID of a multicast session to be transmitted by the multicast inactive MRB. The MBS session ID may be a TMGI (Temporary Mobile Group Identity). Note that, when the UE 100 participates in multiple multicast sessions, the multicast inactive MRB configuration may include multiple MRB IDs and / or multiple MBS session IDs corresponding to the multiple multicast sessions. Furthermore, the multicast inactive MRB configuration may include a group DRX configuration for configuring group DRX.

[0093] In step S206, UE 100 checks whether the multicast inactive MRB set in step S205 corresponds to the multicast MRB used in the RRC connected state. For example, UE 100 checks whether a multicast MRB having a common MBS session ID with the multicast inactive MRB set in step S205 was used in the RRC connected state. Alternatively, UE 100 may check whether a multicast MRB having a common MRB ID with the multicast inactive MRB set in step S205 was used in the RRC connected state. Note that, when multiple multicast inactive MRBs are set in step S205, such a check may be performed for each MBS session ID or each MRB ID corresponding to the multiple multicast inactive MRBs.

[0094] If the multicast inactive MRB set in step S205 does not correspond to the multicast MRB used in the RRC connected state (step S206: NO), the UE 100 considers the multicast session transmitted by the multicast inactive MRB to be inactive and suspends the start of multicast reception processing for the multicast session. Then, in step S207, the UE 100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S205. In this case, the UE 100 in the RRC inactive state may monitor the above-mentioned group notification, and when it determines based on the group notification that the multicast session in which the UE 100 participates has been activated, it may start the multicast reception processing based on the multicast inactive MRB setting in step S205.

[0095] On the other hand, if the multicast inactive MRB set in step S205 corresponds to the multicast MRB used in the RRC connected state (step S206: YES), in step S208, the UE 100 considers that the multicast session transmitted by the multicast inactive MRB is active and starts the multicast reception process. The UE 100 establishes a multicast inactive MRB by applying the multicast inactive MRB setting received in step S205. Then, in step S209, the UE 100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S205. In step S210, the UE 100 receives the multicast session (multicast data) from the gNB 200 on the MTCH using the established multicast inactive MRB. Note that the order of steps S208 and S209 may be reversed.

[0096] (3.3) Third Operation Pattern The third operation pattern will be described, focusing mainly on the differences from the first and second operation patterns described above.

[0097] The third operation pattern is an operation pattern that does not require the session state information, similar to the second operation pattern. In the third operation pattern, the UE 100 that has received the RRC Release message including the multicast inactive MRB configuration determines whether the multicast session transmitted by the configured multicast inactive MRB is active or not, based on the upper layer information stored in advance.

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

[0099] However, the information in the USD may be rough or outdated. For example, for a certain multicast session, even if the USD indicates that the session will start at 11:00, the network 5 of the mobile communication system 1 may actually start distribution (activation) at 11:05. Also, even if distribution is scheduled to start at 11:00, the actual start of distribution may be delayed due to congestion in the network 5 or other reasons. Therefore, in the third operation pattern, the UE 100 attempts multicast reception processing based on the upper layer information and determines whether to continue multicast reception. Specifically, the UE 100 uses the upper layer information to attempt MTCH reception on the configured multicast inactive MRB and determines whether to continue receiving the multicast session. In the third operation pattern, the UE 100 receives an RRC Release message from the gNB 200, which includes a multicast inactive MRB setting and transitions the UE 100 to an RRC inactive state. UE 100 attempts to receive a multicast session using a multicast inactive MRB based on pre-stored upper layer information. If the attempt to receive the multicast session is successful, UE 100 continues the multicast reception process using the multicast inactive MRB. On the other hand, if the attempt to receive the multicast session is unsuccessful, UE 100 stops the multicast reception process.

[0100] In the third operation pattern, the UE 100 attempts to receive multicast data for a certain period of time. The certain period may be set by the gNB 200 to the UE 100. That is, the trial period for determining whether to continue receiving multicast data may be set by the gNB 200.

[0101] FIG. 8 is a diagram showing an example of operation of the mobile communication system 1 according to the third operation pattern.

[0102] In step S301, UE 100 is in an RRC connected state in the cell of gNB 200. UE 100 is assumed to have participated in a certain multicast session. UE 100 may have participated in multiple multicast sessions.

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

[0104] In step S303, gNB200 transmits an RRC Release message including a multicast inactive MRB configuration to UE100. UE100 receives the RRC Release message.

[0105] The multicast inactive MRB configuration includes an MRB ID of the multicast inactive MRB to be configured and / or an MBS session ID of a multicast session to be transmitted by the multicast inactive MRB. The MBS session ID may be a TMGI (Temporary Mobile Group Identity). Note that, when the UE 100 participates in multiple multicast sessions, the multicast inactive MRB configuration may include multiple MRB IDs and / or multiple MBS session IDs corresponding to the multiple multicast sessions. Furthermore, the multicast inactive MRB configuration may include a group DRX configuration for configuring group DRX.

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

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

[0108] In step S305, UE100 determines whether the multicast reception (MTCH) attempt was successful. If UE100 cannot receive MTCH normally for a certain period of time, it considers the multicast reception attempt to have failed. The certain period may be set to UE100 by gNB200 in an SIB or RRC Release message (step S303). If UE100 participates in multiple multicast sessions, the certain period may be set for each MBS session ID (MRB).

[0109] If it is determined that the multicast reception attempt has failed (step S306: NO), in step S307, UE 100 stops the multicast reception process (MTCH reception process). UE 100 may consider the multicast session transmitted using the established multicast inactive MRB to be in an inactive state, and suspend the multicast inactive MRB. In this case, after transitioning to the RRC inactive state (step S309), UE 100 may monitor the above-mentioned group notification, and when it determines based on the group notification that the multicast session in which UE 100 participates has been activated, it may start the multicast reception process based on the multicast inactive MRB setting in step S303.

[0110] On the other hand, if it is determined that the multicast reception attempt has failed (step S306: YES), in step S308, UE 100 considers that the multicast session transmitted by the established multicast inactive MRB is in an inactive state, and continues the multicast reception process (MTCH reception process).

[0111] In step S309, the UE 100 transitions to an RRC inactive state in response to the reception of the RRC Release message in step S303.

[0112] In this operation example, after receiving the RRC Release message in step S303, the UE 100 may transition to the RRC inactive state before step S304. The UE 100 may transition to the RRC inactive state before step S305. The UE 100 may transition to the RRC inactive state before step S306.

[0113] (4) Other Embodiments In the above-described embodiment, multicast reception in the RRC inactive state has been mainly described, but the operation according to the above-described embodiment may be applied to multicast reception in the RRC idle state. In the RRC idle state, the above-described RRC resume (Resume) is replaced with RRC establishment (Establishment).

[0114] The above-described operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed.

[0115] In the above-described embodiments and examples, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. 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 the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node.

[0116] That is, the UE 100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that relays signals. Such a terminal function unit is referred to as an MT. Examples of the MT include, in addition to the IAB-MT, an NCR (Network Controlled Repeater)-MT and a RIS (Reconfigurable Intelligent Surface)-MT.

[0117] 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). A network node may also be configured by a combination of at least a part of a core network device and at least a part of a base station.

[0118] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Furthermore, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a portion of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0119] The functions performed by the UE 100 or the gNB 200 (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 (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, or means refers to hardware that is programmed to perform the described functions or hardware that executes them. The hardware may be any hardware disclosed herein or any hardware known to be programmed or capable of performing the described functions. If the hardware is a processor, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0120] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

[0121] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

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

[0123] (5) First Supplementary Note The following is a supplementary note regarding the features of the above-described embodiment.

[0124] (Supplementary Note 1) A communication method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving, from a network node, an RRC release message including configuration information of a multicast inactive / multicast radio bearer (MRB) used for receiving a multicast session in a radio resource control (RRC) inactive state, and causing the user equipment to transition to the RRC inactive state; checking whether the RRC release message includes state information regarding whether the multicast session is activated; and if the state information is not included in the RRC release message, starting a multicast reception process using the multicast inactive MRB based on the configuration information.

[0125] (Supplementary Note 2) The communication method according to Supplementary Note 1, further comprising suspending start of the multicast reception process when the state information is included in the RRC release message and the state information is information regarding that the multicast session is not activated.

[0126] (Supplementary Note 3) The communication method according to Supplementary Note 2, wherein the state information is information indicating that the start of the multicast reception process is suspended.

[0127] (Supplementary Note 4) The communication method according to any one of Supplementary Notes 1 to 3, further comprising: starting the multicast reception process when the state information is included in the RRC release message and the state information is information indicating that the multicast session is activated.

[0128] (Supplementary Note 5) The communication method according to Supplementary Note 4, wherein the state information is information indicating that the multicast reception process is to be started.

[0129] (Supplementary Note 6) The communication method according to any one of Supplementary Notes 1 to 5, wherein the state information is associated with a group DRX (Discontinuous Reception) setting applied to reception of one or more multicast sessions.

[0130] (Supplementary Note 7) The communication method according to any one of Supplementary Notes 1 to 6, wherein the setting information includes settings for each of a plurality of multicast inactive MRBs, and the state information includes at least one of information indicating that all of the plurality of multicast inactive MRBs are in an inactive state and information indicating that at least one of the plurality of multicast inactive MRBs is in an active state.

[0131] (Supplementary Note 8) A communication method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving a multicast session using a multicast-multicast radio bearer (MRB) in a radio resource control (RRC) connected state; receiving an RRC release message from a network node, the RRC release message including configuration information of a multicast inactive MRB used for receiving the multicast session in an RRC inactive state, and causing the user equipment to transition to the RRC inactive state; checking whether the multicast inactive MRB corresponding to the multicast MRB has been configured; and starting a multicast reception process using the multicast inactive MRB when the multicast inactive MRB corresponding to the multicast MRB has been configured.

[0132] (Supplementary Note 9) The communication method according to Supplementary Note 8, wherein the multicast inactive MRB corresponding to the multicast MRB is the multicast inactive MRB having a common MBS session ID with the multicast MRB, or the multicast inactive MRB having a common MRB ID with the multicast MRB.

[0133] (Supplementary Note 10) The communication method according to Supplementary Note 8 or 9, further comprising the step of suspending the start of the multicast reception process when the multicast inactive MRB that does not correspond to the multicast MRB is set.

[0134] (Supplementary Note 11) A communication method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), comprising the steps of: receiving, from a network node, an RRC release message including configuration information of a multicast inactive / multicast radio bearer (MRB) used for receiving a multicast session in a radio resource control (RRC) inactive state, and causing the user equipment to transition to the RRC inactive state; attempting to receive the multicast session using the multicast inactive MRB based on pre-stored upper layer information; and, if the attempt to receive the multicast session is successful, continuing multicast reception processing using the multicast inactive MRB.

[0135] (Supplementary Note 12) The communication method according to Supplementary Note 11, further comprising the step of stopping the multicast reception process if the attempt to receive the multicast session fails.

[0136] (Supplementary Note 13) The communication method according to Supplementary Note 11 or 12, wherein in the attempting step, the user equipment performs the attempt for a certain period of time, and the certain period of time is set by the network node to the user equipment.

[0137] (6) Annex 2 1. Introduction The work item on enhanced MBS (eMBS) aims to support multicast reception by UEs in inactive mode and is described as follows: - Specify support for multicast reception by UEs in RRC inactive mode [RAN2, RAN3]. - PTM configuration for UEs receiving multicast in RRC inactive mode [RAN2]. - Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive mode (seamless / lossless mobility is not mandatory) [RAN2, RAN3].

[0138] RAN2 has been discussing this goal and has reached a set of agreements. Building on these agreements, the control plane aspects regarding multicast reception in inactive mode are discussed in this appendix.

[0139] 2. Discussion 2.1. Initial Setup Procedure for Connected UE RAN2#120 has agreed to proceed with a "mixed approach."

[0140] A mixed approach is as follows: 1. If the NW configures the UE to continue multicast reception in inactive state, the NW provides PTM configuration of the activated multicast session through RRC dedicated signaling at least to the serving cell (other cases require further study). [...] 3. It is assumed that the UE can receive the multicast service only after joining the session.

[0141] RAN2#121 agreed to the following: ・A UE needs to join a multicast session before receiving multicast in RRC inactive. ・If the network deems it useful, it can configure the PTM configuration of the (single) serving cell in the UE before session activation and the UE can save the configuration. Once the session is activated, the UE can apply the configuration and receive multicast in inactive state without returning to RRC connected, unless updated by MCCH after configuration. ・If the network configures the UE to receive multicast in inactive state, the PTM configuration can be delivered using an RRC release message with suspendconfig. No other dedicated RRC message is used to provide PTM configuration for MBS multicast in inactive. ・A new MCCH logical channel for multicast in inactive is introduced (different from the broadcast MCCH). ・Multicast MCCH configuration is provided via a new SIB. ・As an option, multicast MCCH configuration for the serving cell can also be provided by dedicated signaling. Therefore, it is not optimized for mobility.

[0142] RAN2#122 agreed to the following: ・Multicast MCCH configuration will be based on the broadcast MCCH configuration structure (mcch-Config-r17). ・To notify changes to the multicast MCCH, the Rel-17 broadcast MCCH change notification mechanism will be the baseline. ・The PTM configuration of the multicast MCCH will be based on the broadcast PTM configuration of Rel-17. ・As a rule, the PTM configuration of the RRC release message containing suspendconfig has the same structure as the PTM configuration of the multicast MCCH.

[0143] Based on these agreements and the currently running CR, the configuration procedure for the connected UE for ongoing (i.e., activated) and deactivated (i.e., prior to activation) multicast sessions can be considered as shown in Figure 9.

[0144] For an ongoing multicast session, the UE configures a multicast MRB for multicast reception in Connected via RRC reconfiguration and starts receiving MTCHs similar to Rel-17. For multicast reception in Inactive, the UE is configured with a multicast inactive MRB, which can be considered similar to a broadcast MRB in Rel-17, via RRC release.

[0145] Regarding the multicast inactive MRBs described in the running CR, it should first be clarified that they have the same characteristics as the Rel-18 broadcast MRBs, but are different MRBs from the Rel-17 broadcast MRBs or the Rel-17 multicast MRBs.

[0146] Proposal 1: RAN2 needs to ensure that the multicast inactive MRB functions similarly to the Rel-17 broadcast MRB, but is a new MRB type for multicast reception in inactive.

[0147] It is clear that at least for ongoing multicast sessions, the UE must immediately apply and establish the multicast inactive MRBs once set up by RRC release.

[0148] Proposal 2: RAN2 should agree that, at least for ongoing multicast sessions, the UE immediately establishes a multicast inactive MRB if configured by RRC release.

[0149] On the other hand, in a deactivated multicast session, the UE also performs PTM configuration via RRC release. If Proposal 2 above is acceptable, the UE would immediately start receiving the MTCH. However, since the MTCH is not transmitted at this time, the UE should refrain from doing so. Instead, the UE needs to notify via RRC release that the multicast session is still inactive so that it can wait for a multicast session activation notification without receiving the MTCH. Since the session state, i.e., activation or deactivation, differs for each multicast session, a deactivation indication should be notified for each TMGI. Further study is required for detailed operation. For example, whether to apply PTM configuration but wait for session activation is still required.

[0150] Proposal 3: RAN2 should agree to inform the UE via RRC release whether each multicast session is disabled or not, so that the UE does not attempt to receive the corresponding MTCH.

[0151] After transitioning to inactive, the UE monitors multicast session activation notifications (i.e., group paging). Prior to multicast session activation, the gNB may change the PTM settings of the session, and such changes are configured by the multicast MCCH of the UE in inactive.

[0152] From the UE's perspective, if the UE needs to monitor the multicast MCCH for a deactivated multicast session, the UE's power consumption will increase. Therefore, it is necessary to ensure that the UE does not need to monitor the multicast MCCH before receiving the multicast session activation notification. In other words, the UE only needs to monitor the multicast MCCH once it receives the activation notification for the TMGI of interest. The same behavior can also be applied to new SIBs (such as SIB20) for multicast MCCH configuration.

[0153] Proposal 4: RAN2 should agree that UEs do not need to monitor the multicast MCCH or new SIBs (such as SIB20) if the corresponding multicast session is deactivated (i.e., before receiving a multicast session notification).

[0154] Upon receiving the multicast activation notification, the UE needs to check whether the MCCH configuration in the new SIB and / or the PTM configuration in the multicast MCCH have been updated if the MCCH configuration and / or the PTM configuration were provided by the RRC release. Unless the configuration has been updated, the saved configuration, i.e., the configuration provided by the RRC release, should be applied. Of course, if the configuration has been updated, the UE needs to acquire the new SIB and / or the multicast MCCH.

[0155] For the new SIB, it is expected that the UE can know whether the new SIB has been updated by checking the value tag of SIB1 as in the current version. However, the UE cannot know whether the multicast MCCH has been updated before receiving and decoding the multicast MCCH. In this case, even if the multicast MCCH has been configured by RRC release, the UE needs to decode the multicast MCCH once, which is also meaningless. In this sense, a value tag needs to be introduced into the multicast MCCH so that the UE can know the PTM configuration update without decoding the multicast MCCH. Further study is required on where the value tag of the multicast MCCH should be located, such as in the new SIB, SIB1, or group paging.

[0156] Proposal 5: RAN2 should agree that a multicast MCCH value tag be introduced that is used by the UE to know if the PTM configuration has been updated from that set by RRC release without decoding the multicast MCCH itself.

[0157] 2.2. Initial Setup Procedure for Inactive UEs RAN2#120 agreed to use multicast MCCH for PTM configuration updates. A mixed approach is as follows: 1. If the NW configures the UE to continue multicast reception in the inactive state, the NW provides PTM configuration for activated multicast sessions through RRC dedicated signaling, at least for the serving cell (other cases require further study). 2. The MCCH is used when PTM configuration needs to be changed or when PTM configuration needs to be indicated during movement beyond the serving cell / gNB. Session status changes and other indications require further study. [...]

[0158] In RAN2#121bis-e, it is agreed that if the UE does not have PTM configuration, it will resume the RRC connection. This means that the UE needs to transition to Connected to acquire PTM configuration. When an event such as session activation / resumption of data transmission occurs, if the UE does not have PTM configuration, the UE will initiate the resumption of the RRC connection.

[0159] The original interpretation of the agreement was a "mixed approach" concept, whereby the initial PTM configuration should always be provided by dedicated signaling, and PTM configuration updates could be made via multicast MCCH. However, the currently implemented CR of TS 38.300 states that this is an issue that requires further study. Note: Whether a UE can obtain the initial PTM configuration via multicast MCCH requires further study.

[0160] If UEs are allowed to obtain the initial PTM configuration via multicast MCCH, this will be exactly the same as Rel-17 delivery mode 2 (i.e., for broadcast MBS sessions). Previous RAN2 discussions leading up to the mixed approach agreement raised concerns that Rel-17 delivery mode 2 may not be acceptable for MBS multicast in some deployments. It is not desirable to repeat the same discussions that existed before the mixed approach was agreed upon, so the Rel-18 mechanism should take deployment assumptions into account.

[0161] Observation 1: Based on the discussion so far, it is not acceptable for a UE to obtain the initial PTM configuration via multicast MCCH in some deployments.

[0162] On the other hand, in practice, Rel-17 delivery mode 2 is almost identical to LTE eMBMS / SC-PTM, which can handle MBMS multicast sessions, so MBS multicast sessions via delivery mode 2 can also be applied to some other deployments. Furthermore, most of the current implementations of Rel-17 delivery mode 2 can be reused for Rel-18 multicast reception in inactive mode if it is allowed to obtain the initial PTM configuration via the multicast MCCH. Also, depending on the network implementation, the signaling overhead of broadcast signaling (i.e., multicast MCCH) can be reduced compared to dedicated signaling (i.e., RRC release). Therefore, this option is worth considering. In fact, in the currently implemented CR of TS 38.331, the same PTM configuration (MBSMulticastConfiguration) is captured for both the multicast MCCH and RRC release, so it is possible for the UE to obtain the initial PTM configuration from the multicast MCCH.

[0163] Observation 2: According to LTE eMBMS / SC-PTM, the UE obtains the initial PTM configuration via multicast MCCH, which is also applicable to some other deployments.

[0164] Considering these findings, an enhanced mixed approach should be considered to support all deployment assumptions in an efficient and flexible way. In fact, this can be achieved with a very simple solution. The RRC release can indicate whether the UE is allowed to obtain the initial PTM configuration from the multicast MCCH or not. In this solution, if this indication is not configured, the UE simply follows the current agreement. That is, the initial PTM configuration is always provided by dedicated signaling, and the UE resumes the RRC connection if necessary. If this indication is configured, the UE can obtain the initial PTM configuration from the multicast MCCH if it does not have a PTM configuration.

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

[0166] 2.3 Configuration Update in Inactive State In Rel-17, there is one MCCH in a cell. In Rel-18, RAN2 agreed to introduce a new MCCH logical channel for multicast in inactive state (different from broadcast MCCH). The multicast MCCH is used when the PTM configuration needs to be changed or when the PTM configuration needs to be indicated during movement across the serving cell / gNB.

[0167] Observation 3: The multicast MCCH is used to update the PTM configuration of UEs in inactivity.

[0168] In other words, there are two MCCHs in Rel-18 networks: (broadcast) MCCH and multicast MCCH. The reason for introducing separate MCCHs within a cell is thought to be to handle different service requirements for different cast types (MBS broadcast and MBS multicast).

[0169] The question is whether different multicast sessions have different service requirements. The service requirements for a group multimedia call service and a firmware download service are completely different. For example, the group multimedia call service is a foreground service, so it needs to frequently optimize the PTM settings, while the firmware download service is a background service, so such frequent optimization is not necessary. Considering that the initial PTM settings are provided by RRC release, updating the PTM settings via a multicast MCCH is necessary for some services but not for others. In this sense, introducing multiple multicast MCCHs is efficient for UEs and flexible for the network.

[0170] Proposal 7: RAN2 should discuss whether to introduce multiple multicast MCCHs per cell.

[0171] 2.4 UE Mobility and Service Continuity 2.4.1 Frequency Prioritization RAN2#121bis-e agreed that further study is needed on UE behavior during cell reselection. Similar to the Rel-17 broadcast reception procedure, the UE acquires new SIBs and multicast MCCH and acquires PTM configuration after cell reselection. If the UE reselects to a cell where PTM configuration is not available on the multicast MCCH, the UE initiates an RRC restart procedure for active multicast sessions that it is interested in receiving or continuing to receive. Frequency prioritization may be provided to the UE for cell reselection with RRC inactivity and multicast reception, but the detailed mechanism for identifying frequency information (e.g., SAI, USD, or frequency information provided directly by the network) requires further study. It is not necessary to define a mechanism other than frequency prioritization, i.e., cell-level prioritization for cell reselection, to enable the UE to select an appropriate cell. The neighbor cell list mechanism for multicast reception in RRC inactive is similar in some respects to the Rel-17 NCL mechanism for MBS broadcasting, but can be configured to be used by the UE to resume RRC connection if the service is not available in the reselected cell due to NCL, for example, without reading the MCCH in the reselected cell.

[0172] Regarding frequency information, higher layers can provide information via USD, etc. However, considering that NR MBS transmission is determined on a cell-by-cell basis, USD can only provide static information (especially for inactive UEs), while the RAN may have up-to-date information. Therefore, the RAN should also provide frequency information if possible. Therefore, like SIB21 in the Rel-17 MBS broadcast, the gNB can broadcast frequency information so that the UE can prioritize the appropriate frequency during cell reselection.

[0173] Proposal 8: RAN2 should agree that frequency information will be broadcast by the gNB.

[0174] 2.4.2 Area Scope of PTM Configuration In RAN2#121 and RAN2#122, the area scope of multicast MCCH and the provisioning of multicast MCCH in neighboring cells were discussed. Some companies also proposed enabling PTM configuration in multiple cells to improve service continuity during UE movement. While intra-gNB PTM configurations can be easily synchronized (if necessary), inter-gNB configurations are more difficult and require negotiation with the Xn-AP.

[0175] RAN2 agreed to the following statements: ・The serving cell does not provide PTM configuration of neighboring cells from other gNBs. ・Further study is required on whether the network can provide PTM configuration for cells within a gNB. ・Providing PTM configuration of neighboring cells within a gNB via dedicated signaling is not supported.

[0176] These agreements are confusing in terms of what has been excluded. It is clear that a serving cell does not provide the MBSMulticastConfiguration of neighboring cells, i.e., the serving cell provides only its own MBSMulticastConfiguration. However, it is unclear whether the serving cell's indication of the area scope of its MBSMulticastConfiguration (e.g., the PTM configuration of the serving cell is valid in multiple cells) has also been excluded. For example, the PTM configuration of the serving cell is valid in multiple cells. The latter extension would require much less signaling overhead (e.g., just an additional cell list) and would not be harmful if it were limited to the intra-gNB case (i.e., no impact on Xn). Therefore, RAN2 needs to discuss whether the PTM configuration can be applied to multiple cells within a gNB.

[0177] Proposal 9: RAN2 should agree that the serving cell can indicate the area scope (e.g., applicable cell list) of MBSMulticastConfiguration.

[0178] 2.4.3 QoS Enforcement RAN2#119e has reached the following agreements related to Case 3: HARQ feedback and PTP are not supported for RRC inactive multicast reception.

[0179] According to the agreement, multicast reception in inactive mode is similar to MBS broadcast reception (so-called Delivery mode 2) specified in Rel-17. MBS broadcast is best-effort type.

[0180] On the other hand, guaranteeing QoS / reliability is an important issue for multicast sessions. SA2 also raised the question of whether there is a difference in quality / reliability of multicast reception between connected and inactive states, and RAN2#119bis-e agreed on the following answer: RAN2 Q1-a) If there is a significant difference in reception quality and reliability of MBS data between UEs in RRC connected state and UEs in RRC inactive state: UEs in RRC connected state and UEs in RRC inactive state may experience different reception quality and reliability of MBS data because HARQ feedback and PTP transmission are not supported and seamless / lossless mobility is not required for multicast reception in RRC inactive state.

[0181] RAN2#121bis-e agreed to introduce an event-triggered RRC resumption mechanism, but the trigger conditions need further study. A UE may trigger the resumption of an RRC connection if the reception quality of multicast data falls below a configured threshold.

[0182] In RAN2#119e, it is proposed to introduce thresholds for reception quality such as RSRP and / or BLER, which are thought to be used to ensure a certain level of QoS required for multicast reception.

[0183] Regarding the RSRP threshold, since NR MBS is assumed in a single-cell transmission scheme and this threshold is related to SSB or CSI-RS rather than directly to MTCH, it is considered that the UE must always transition to Connected whenever it moves to the cell edge or performs cell reselection. This may not be optimal in some deployments (such as single-frequency networks) from the perspective of network congestion or UE power saving. On the other hand, RSRP is one of the basic metrics for evaluating reception quality and is one of the metrics that gNBs typically use when making handover decisions (i.e., handover is performed after the UE transitions to Connected due to this RSRP threshold). In other words, RSRP is a suitable metric for monitoring reception quality.

[0184] Regarding the BLER threshold, it is considered to be more understandable to ensure QoS requirements since it directly monitors the quality of the MTCH, and therefore BLER is worth defining as a metric.

[0185] Another way is to define a specific event. For example, if the event is set to cell reselection, the UE must always transition to Connected before cell reselection. However, such an event may be emulated by the RSRP threshold mentioned above. Therefore, careful consideration is required when RAN2 defines the event that serves as a trigger condition.

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

[0187] Proposal 10: RAN2 should agree to introduce an RSRP threshold and / or an MTCH BLER threshold to monitor multicast reception quality and trigger RRC restart.

[0188] 2.5 Service Continuity Upon RRC Resume It is also necessary to consider the possibility that a UE already receiving a multicast session in Inactive (i.e., via a Multicast Inactive MRB) is paged and initiates an RRC Resume procedure. After transitioning to Connected, the UE would of course like to continue receiving the same multicast session. However, in this case, the UE would have two MRBs for the same multicast session: the Multicast Inactive MRB configured for multicast reception in Inactive, and the resumed legacy multicast MRB for multicast reception in Connected.

[0189] In Rel-17, multicast sessions can only be received via multicast MRBs configured via RRC reconfiguration, whereas in Rel-18, UEs can receive multicast sessions via multicast inactive MRBs configured via RRC release or multicast MCCH.

[0190] Proposal 11: RAN2 should discuss UE behavior upon RRC resumption during continuous reception of a multicast session (e.g., handling of multicast inactive MRBs and legacy multicast MRBs).

[0191] 1: Mobile communication system 5: Network 10: RAN 20: CN 100: UE (user equipment) 110: Receiving unit 120: Transmitting unit 130: Control unit 200: gNB (base station) 210: Transmitting unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), The steps include receiving an RRC release message from a network node that causes the user device to transition to the RRC inactive state, which includes PTM configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, A step of checking whether predetermined information indicating that the start of multicast reception processing for the multicast session is suspended is included in the RRC release message, If the predetermined information is not included in the RRC release message, the process includes the step of starting the multicast reception process based on the PTM setting information. Communication method.

2. If the predetermined information is included in the RRC release message, the process further includes the step of postponing the start of the multicast reception process. The communication method according to claim 1.

3. The aforementioned predetermined information is associated with the DRX (Discontinuous Reception) settings applied to the reception of the multicast session. The communication method according to claim 1.

4. A user device, A receiving unit that includes PTM configuration information used for receiving multicast sessions in a Wireless Resource Control (RRC) inactive state, and receives an RRC release message from a network node that transitions the user device to the RRC inactive state, The RRC release message includes a control unit that checks whether predetermined information indicating that the start of multicast reception processing for the multicast session is suspended is included in the RRC release message, If the predetermined information is not included in the RRC release message, the control unit starts the multicast reception process based on the PTM setting information. User device.

5. A chipset for a user device, The process includes receiving an RRC release message from a network node, which includes PTM configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, and transitioning the user device to the RRC inactive state. A process to check whether predetermined information indicating that the start of multicast reception processing is to be suspended for the multicast session is included in the RRC release message, If the predetermined information is not included in the RRC release message, the process of starting the multicast reception process based on the PTM setting information is executed. Chipset.

6. A mobile communication system comprising user equipment and providing multicast / broadcast services (MBS), The user device includes PTM configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, and receives an RRC release message from a network node that transitions the user device to the RRC inactive state. The user device checks whether predetermined information indicating that the start of multicast reception processing for the multicast session is suspended is included in the RRC release message. If the predetermined information is not included in the RRC release message, the user device starts the multicast reception process based on the PTM setting information. Mobile communication system.

7. The user device includes: The process includes receiving an RRC release message from a network node, which includes PTM configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, and transitioning the user device to the RRC inactive state. A process to check whether predetermined information indicating that the start of multicast reception processing is to be suspended for the multicast session is included in the RRC release message, If the predetermined information is not included in the RRC release message, the process of starting the multicast reception process based on the PTM setting information is executed. program.