Communication method and user device

Abstract

This communication method used in a mobile communication system that provides multicast / broadcast services (MBS) comprises: a step of a user device that is in a radio resource control (RRC)-inactive state, and is participating in a multicast session, receiving multicast data from a network node via the multicast session; and a step of the user device deciding to transition from the RRC-inactive state to an RRC-connected state, in accordance with having detected emergence of uplink data belonging to the multicast session.

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) defines 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 defines the technical specifications for 5G / NR multicast / broadcast services (MBS) (see, for example, Non-Patent Document 1).

[0003] 3GPP Technical Specification: TS 38.300 V17.1.0

[0004] A communication method according to a first aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment that is in a radio resource control (RRC) inactive state and has joined a multicast session receiving multicast data from a network node (or a network equipment) via the multicast session; and a step of the user equipment determining to transition from the RRC inactive state to an RRC connected state in response to detecting generation of uplink data belonging to the multicast session.

[0005] A communication method according to a second aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state receiving multicast settings required for receiving a multicast session together with version information of the multicast settings from a network node; the user equipment storing the version information; and the user equipment, which has transitioned from the RRC connected state to an RRC inactive state, receiving broadcast information from the network node, the broadcast information including version information of the latest multicast settings for the multicast session.

[0006] A communication method according to a third aspect is a communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of a user equipment that is in a radio resource control (RRC) inactive state and has joined the multicast session receiving multicast data from a network node via the multicast session, and the user equipment receiving, from the network node, identification information of one or more multicast sessions to be released or stopped.

[0007] 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. FIG. 2 is a diagram showing the configuration of a UE (user equipment) according to an embodiment. FIG. 3 is a diagram showing the configuration of a gNB (base station) 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 for explaining an operation that enables a UE in an RRC inactive state to perform multicast reception. FIG. 7 is a diagram showing an operation example of a mobile communication system according to a first operation pattern. FIG. 8 is a diagram showing an operation example of a mobile communication system according to a second operation pattern. FIG. 9 is a diagram showing an operation example of a mobile communication system according to a third operation pattern.

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

[0009] (1) System Configuration Fig. 1 is a diagram showing the configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially based on a 6th Generation (6G) system.

[0010] 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 (or network 10). The 5GC 20 may be simply referred to as the core network (CN) 20.

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

[0012] The NG-RAN 10 includes a base station (called a "gNB" in a 5G system) 200. 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 a 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, and the like. 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 for wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

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

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

[0015] 2 is a diagram showing the 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 constitute a wireless communication unit that performs wireless communication with the gNB 200.

[0016] The receiving unit 110 performs various reception operations 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.

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

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

[0019] 3 is a diagram showing the configuration of a gNB 200 (base station) according to an embodiment. The gNB 200 includes 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0034] The NAS layer, which is 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 called an AS layer.

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

[0036] 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. The UEs 100 can receive the multicast communication service in an RRC connected state using mechanisms such as Point-to-Point (PTP) and / or Point-to-Multipoint (PTM) delivery. The UEs 100 may also receive the multicast communication service in an RRC inactive (or RRC idle) state. Such a delivery mode is also referred to as "Delivery Mode 1".

[0037] 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 communication service in any of the RRC idle state, the RRC inactive state, and the RRC connected state. This delivery mode is also referred to as "delivery mode 2".

[0038] The main logical channels used for MBS delivery are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast or broadcast session from the network 10 to the UE 100. The DTCH is a PTP channel for transmitting MBS data of a multicast session from the network 10 to the UE 100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 10 to the UE 100.

[0039] Regarding the configuration for MBS broadcast, the UE 100 in the RRC idle state, the RRC inactive state, or the RRC connected state receives the MBS configuration for the broadcast session (e.g., parameters required for MTCH reception) via the MCCH. The parameters required for MCCH reception (MCCH configuration) are provided via system information. Specifically, the system information block type 20 (SIB20) includes the MCCH configuration. Note that the SIB type 21 (SIB21) includes information on service continuity for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions, transmitted on the MTCH. The related information for the broadcast session includes the MBS session ID (e.g., TMGI (Temporary Mobile Group Identity)), related MTCH scheduling information, and information on neighboring cells providing a specific service on the MTCH.

[0040] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, UE 100 can only receive multicast session data in the RRC connected state. When UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, gNB 200 transmits an RRC reconfiguration message including MBS configuration for the multicast session to UE 100. Such MBS configuration is also referred to as multicast radio bearer (MRB) configuration, MTCH configuration, or multicast configuration. Such MRB configuration (MRB-ToAddMod) includes other parameters such as an MBS session ID (mbs-SessionId), an MRB ID (mrb-Identity), and a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured in UE 100.

[0041] In the following embodiment, an operation that enables the UE 100 in the RRC inactive state to perform multicast reception will be mainly described. Fig. 6 is a diagram showing an overview of the operation.

[0042] Possible solutions for the UE 100 in the RRC inactive state to perform multicast reception include a distribution mode 1 based solution shown in FIG. 6( a) and a distribution mode 2 based solution shown in FIG. 6( b).

[0043] In the distribution mode 1-based solution shown in Figure 6 (a), in step S1, gNB200 transmits an RRC Reconfiguration message including an MBS setting (multicast setting) for the multicast session to UE100 in the RRC connected state. UE100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the multicast setting received in the RRC Reconfiguration message.

[0044] In step S2, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC Connected state to transition the UE 100 to the RRC inactive state. The RRC Release message includes a setting (Suspend Config.) for the RRC inactive state.

[0045] In step S3, in response to the reception of the RRC Release message in step S2, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0046] In step S4, the UE 100 in the RRC inactive state continues to use the multicast setting in step S1 to receive multicast data on the MTCH via the multicast session.

[0047] This enables the UE 100 in the RRC inactive state to perform multicast reception. Note that although an example of performing multicast configuration using an RRC Reconfiguration message has been described, multicast configuration may also be performed using an RRC Release message.

[0048] The RRC Reconfiguration message and the RRC Release message are both RRC messages transmitted individually to a UE on a Dedicated Control Channel (DCCH), and are hereinafter also referred to as dedicated RRC messages.

[0049] On the other hand, in the distribution mode 2-based solution shown in FIG. 6(b), in step S11, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC connected state to transition the UE 100 to the RRC inactive state. The RRC Release message includes a setting (Suspend Config.) for the RRC inactive state.

[0050] In step S12, in response to the reception of the RRC Release message in step S11, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0051] In step S13, gNB200 transmits an MCCH including an MBS setting (multicast setting) for the multicast session. UE100 receives the MCCH. Note that UE100 receives SIB20 prior to receiving the MCCH, and receives the MCCH based on SIB20. MCCH transmission (and reception) may be performed before step S11 or simultaneously with step S11.

[0052] In step S14, the UE 100 in the RRC inactive state receives multicast data on the MTCH via the multicast session based on the multicast setting received on the MCCH in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0053] (3) System Operation Example The operation of the mobile communication system 1 according to the embodiment will be described. The operation according to the embodiment relates to an operation in which the UE 100 in the RRC inactive state performs multicast reception.

[0054] (3.1) First Operation Pattern: Operation Related to Uplink Transmission The UE 100 cannot perform uplink (UL) transmission in the RRC inactive state. There is no particular problem when the application corresponding to the multicast session is an application such as a television broadcast, but in the case of an application such as a group call, the UE 100 may need to perform UL transmission.

[0055] In this operation pattern, UE 100, which is in an RRC inactive state and has already joined a multicast session, receives multicast data from gNB 200 via the multicast session. UE 100 determines to transition from the RRC inactive state to the RRC connected state in response to detecting the occurrence of UL data belonging to the multicast session. As a result, even if the application corresponding to the multicast session is an application such as a group call, UL transmission can be performed by transitioning to the RRC connected state in response to the occurrence of UL data belonging to the multicast session.

[0056] Thereafter, the UE 100 starts an RRC recovery process to transition to an RRC connected state. In the RRC recovery process, the UE 100 may transmit notification information indicating the generation of UL data belonging to the multicast session to the gNB 200. This allows the gNB 200 to smoothly perform RRC recovery. In addition, the gNB 200 can set a PTP leg to the MRB corresponding to the multicast session, or set a split MRB capable of PTP transmission.

[0057] 7 is a diagram showing an example of the operation of the mobile communication system 1 according to this operation pattern. It is assumed that, prior to this operation, the UE 100 has already joined the multicast session.

[0058] In step S101, the gNB 200 may transmit multicast settings required for receiving a multicast session (i.e., multicast reception) to the UE 100 in the RRC connected state in a dedicated RRC message. In the illustrated example, the dedicated RRC message is an RRC Reconfiguration message, but may also be an RRC Release message (step S103). The UE 100 may receive the multicast settings in a dedicated RRC message. Alternatively, the UE 100 may receive the multicast settings on the MCCH.

[0059] In step S102, the gNB 200 may transmit multicast data on the MTCH via a multicast session based on the multicast setting. The UE 100 may receive multicast data on the MTCH via a multicast session based on the multicast setting.

[0060] In step S103, the gNB 200 transmits an RRC Release message including Suspend config. to the UE 100. The UE 100 receives the RRC Release message. The RRC Release message may include multicast settings required for receiving a multicast session.

[0061] In step S104, in response to the reception of the RRC Release message, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0062] In step S105, the UE 100 in the RRC inactive state receives multicast data on the MTCH via the multicast session based on the multicast setting. The UE 100 receives multicast data on the MTCH via the multicast session based on the multicast setting.

[0063] In step S106, the UE 100 in the RRC inactive state checks whether or not UL data belonging to the multicast session has occurred.

[0064] When the generation of UL data belonging to the multicast session is detected (step S106: YES), in step S107, the UE 100 in the RRC inactive state decides to transition to the RRC connected state, and starts the RRC recovery process.

[0065] In step S108, the UE 100 in the RRC inactive state transmits an RRC Resume Request message to the gNB 200 to request restoration of the RRC connection. Here, the UE 100 may include notification information indicating the occurrence of UL data belonging to the multicast session in the RRC Resume Request message. The notification information may be set in a Resume Cause (recovery cause) field in the RRC Resume Request message. The notification information may be information such as multicast MO (Mobile Originated) data. The notification information may be notified from the NAS to the AS (e.g., the RRC layer) in the UE 100.

[0066] In step S109, in response to receiving the RRC Resume Request message, gNB200 transmits an RRC Resume message to UE100.

[0067] In step S110, the UE 100 transitions from the RRC inactive state to the RRC connected state in response to receiving the RRC Resume message. The gNB 200 may set a PTP leg to the MRB corresponding to the multicast session. The gNB 200 may set the MRB to a split MRB.

[0068] In step S111, the UE 100 that has transitioned to the RRC connected state transmits UL data to the gNB 200. The gNB 200 receives the UL data.

[0069] In the illustrated example, the UE 100 includes notification information indicating the generation of UL data belonging to the multicast session in the RRC Resume Request message. However, after transitioning to the RRC connected state, the UE 100 may include the notification information in an RRC message, for example, a UE Assistance Information message, and transmit the message to the gNB 200.

[0070] (3.2) Second operation pattern: Operation related to change of multicast setting Here, a distribution mode 1-based solution is assumed. In a distribution mode 1-based solution, after the gNB 200 performs multicast setting for the UE 100 using a dedicated RRC message, the UE 100 performs multicast reception in an RRC inactive state based on the multicast setting. Note that the UE 100 in the RRC inactive state cannot receive the dedicated RRC message.

[0071] Here, it is assumed that the gNB 200 updates the multicast setting (for example, MTCH scheduling) for some reason. In order for the UE 100 to continue multicast reception, it is necessary to set the updated multicast setting to the UE 100 again.

[0072] In order to set the updated multicast setting in the UE 100, the UE 100 needs to perform an RRC recovery process and transition to an RRC connected state. However, since the UE 100 in the RRC inactive state cannot know that the gNB 200 has changed the multicast setting, it is difficult for the UE 100 to voluntarily start the RRC recovery process.

[0073] Therefore, in this operation pattern, the gNB 200 transmits to the UE 100, in an RRC connected state, the multicast settings required for receiving a multicast session, along with version information of the multicast settings. Specifically, the gNB 200 transmits to the UE 100 a dedicated RRC message including a set of multicast settings and version information. The version information is a variable that is counted up when the corresponding multicast setting is updated. Hereinafter, such version information is also referred to as a "Value Tag."

[0074] The UE 100 stores the multicast setting and version information received from the gNB 200. After the UE 100 transitions from the RRC connected state to the RRC inactive state, the UE 100 receives broadcast information including version information (Value Tag) of the latest multicast setting of the multicast session from the gNB 200. This allows the UE 100 to know whether the multicast setting it has stored (i.e., the currently applied multicast setting) is the latest or old.

[0075] The UE 100 determines to transition from the RRC inactive state to the RRC connected state based on the fact that the version information in the broadcast information is different from the stored version information. As a result, the UE 100 transitions to the RRC connected state and can receive a dedicated RRC message including the latest multicast setting from the gNB 200.

[0076] 8 is a diagram showing an example of operation of the mobile communication system 1 according to this operation pattern. It is assumed that the UE 100 has already joined the multicast session prior to this operation. Here, differences from the first operation pattern described above will be mainly described, and overlapping descriptions will be omitted.

[0077] In step S201, the gNB 200 transmits the multicast setting required for receiving the multicast session (i.e., multicast reception) to the UE 100 in the RRC connected state together with its Value Tag in a dedicated RRC message. The Value Tag may be included in the multicast setting. The multicast setting may include a session identifier (TMGI) of the multicast session. The Value Tag may be associated with the session identifier (TMGI). In the illustrated example, the value of the Value Tag is "#0".

[0078] In the illustrated example, the dedicated RRC message is an RRC Reconfiguration message, but may be an RRC Release message (step S203). The UE 100 receives the multicast setting and the Value Tag in the dedicated RRC message.

[0079] In step S202, the UE 100 in the RRC connected state stores the multicast setting and the Value Tag received in step S201 in association with each other, and uses the multicast setting for multicast reception.

[0080] In step S203, the gNB 200 may transmit multicast data on the MTCH via a multicast session based on the multicast setting notified to the UE 100. The UE 100 may receive multicast data on the MTCH via a multicast session based on the stored multicast setting.

[0081] In step S204, the gNB 200 transmits an RRC Release message including Suspend config. to the UE 100. The UE 100 receives the RRC Release message. The RRC Release message may include multicast settings required for receiving the multicast session and its Value Tag. The multicast settings may include a session identifier (TMGI) of the multicast session. The Value Tag may be associated with the session identifier (TMGI).

[0082] In step S205, in response to the reception of the RRC Release message, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0083] In step S206, the gNB 200 transmits multicast data on the MTCH via the multicast session based on the multicast setting notified to the UE 100. The UE 100 in the RRC inactive state may receive multicast data on the MTCH via the multicast session based on the stored multicast setting.

[0084] In step S207, gNB200 transmits broadcast information including the currently valid Value Tag value, i.e., the Value Tag value of the latest multicast setting. UE100 receives the broadcast information. The broadcast information may include a session identifier (TMGI) of each multicast session being provided by gNB200. In the broadcast information, the Value Tag may be associated with the session identifier (TMGI). Here, since the multicast setting corresponding to the multicast session being received by UE100 has not been updated, the value of the Value Tag for the multicast session remains "#0".

[0085] The broadcast information may be a system information block (SIB) broadcast on a broadcast control channel (BCCH). The SIB may be SIB type 1, SIB type 20 (MCCH configuration), SIB type 21 (service continuity information), or a newly defined SIB. Alternatively, the broadcast information may be information broadcast on an MCCH. Alternatively, the broadcast information may be a paging message broadcast on a PCCH. Alternatively, the broadcast information may be a MAC CE multicast using a group RNTI (G-RNTI).

[0086] In step S208, UE 100 in the RRC inactive state compares the Value Tag received in step S207 (specifically, the Value Tag corresponding to the multicast session being received by UE 100) with the stored Value Tag and determines that the two match. In this case, UE 100 in the RRC inactive state considers that the currently stored (applied) multicast setting is valid and continues to use the multicast setting to receive multicast.

[0087] In step S209, the gNB 200 updates the multicast setting for the multicast session being received by the UE 100. In response to the update of the multicast setting, the gNB 200 counts up (increments) the Value Tag corresponding to the multicast session to "#1".

[0088] In step S210, gNB200 transmits broadcast information including the currently valid Value Tag value, i.e., the latest multicast setting Value Tag value. Here, the latest Value Tag value corresponding to the multicast session being received by UE100 is "#1". UE100 receives the broadcast information.

[0089] In step S211, UE100 in the RRC inactive state compares the Value Tag received in step S210 (specifically, the Value Tag corresponding to the multicast session being received by UE100) with the stored Value Tag. Here, since the value of the Value Tag stored by UE100 is "#0" and the value of the latest Value Tag received from gNB200 is "#1", it is determined that the two do not match. In this case, UE100 in the RRC inactive state considers that the currently stored (applied) multicast setting is old, and determines to transition to the RRC connected state to acquire new multicast settings, and starts the RRC recovery process.

[0090] In step S212, the UE 100 in the RRC inactive state transmits an RRC Resume Request message to the gNB 200 to request restoration of the RRC connection. Here, the UE 100 may include notification information indicating a request to acquire new multicast settings in the RRC Resume Request message. The notification information may be set in a Resume Cause (recovery cause) field in the RRC Resume Request message.

[0091] In step S213, in response to receiving the RRC Resume Request message, gNB200 transmits an RRC Resume message to UE100.

[0092] In step S214, in response to the reception of the RRC Resume message, the UE 100 transitions from the RRC inactive state to the RRC connected state.

[0093] In step S215, the gNB 200 transmits the new multicast setting together with the Value Tag to the UE 100 that has transitioned to the RRC connected state in a dedicated RRC message. The UE 100 in the RRC connected state associates the multicast setting and Value Tag received in step S215 with each other and stores them, and uses the multicast setting for multicast reception.

[0094] (3.3) Third Operation Pattern: Operation Related to Session Release In this operation pattern, when UE 100 is receiving a multicast session in an RRC inactive state, it is assumed that the multicast session is released on the network side. Since a general operation at the time of session release involves receiving a PDU Session Modification of the NAS and transmitting an Ack, UE 100 needs to be in an RRC connected state.

[0095] Therefore, when a multicast session being received by multiple UEs 100 in the RRC inactive state is released, the gNB 200 may call each UE 100 by a paging message and transition each UE 100 to the RRC connected state. In this case, it is necessary to include an identifier of each UE 100 in the paging message, which increases the size of the paging message.

[0096] Furthermore, when the multicast session is released, it is preferable to cancel the multicast setting set in the UE 100. If the multicast setting is maintained, even if the transmission of multicast data has ceased, the UE 100 continues to attempt multicast reception while remaining in the RRC inactive state, which causes a problem of increased power consumption of the UE 100.

[0097] Although this operation pattern will be mainly described with respect to the release of a multicast session, this operation pattern can also be applied to the case where a multicast session is temporarily stopped (deactivated).

[0098] In this operation pattern, the UE 100 performing multicast reception in an RRC inactive state receives identification information of one or more multicast sessions to be released or stopped from the gNB 200. The gNB 200 may transmit a paging message including the identification information or a medium access control element (MAC CE) including the identification information. This allows the UE 100 to identify (recognize) the release or stop of the multicast session it is receiving based on the identification information included in the paging message or MAC CE. Therefore, the UE 100 recognizes that the multicast session it is receiving has been released or stopped, and can stop the multicast reception operation.

[0099] 9 is a diagram showing an example of operation of the mobile communication system 1 according to this operation pattern. It is assumed that the UE 100 has already joined the multicast session prior to this operation. Here, differences from the first and second operation patterns described above will be mainly described, and overlapping descriptions will be omitted.

[0100] The operations of steps S301 to S305 are the same as the operation pattern described above. Here, in step S305, the UE 100 in the RRC inactive state receives multicast data on the MTCH via a multicast session based on the multicast setting. The UE 100 receives multicast data on the MTCH via the multicast session based on the multicast setting.

[0101] In step S306, gNB200 receives a notification of multicast session release from CN20.

[0102] In step S306, the gNB 200 transmits identification information indicating the multicast session to be released. The UE 100 receives the identification information. In the following, it is mainly assumed that the multicast session being received by the UE 100 is released.

[0103] The gNB 200 may transmit a paging message including the identifier (TMGI) of the multicast session to be released on the PCCH (Paging Control Channel). For example, the gNB 200 transmits a paging message including a list (e.g., "release group list") of the identifiers (TMGI) of each multicast session to be released.

[0104] Alternatively, the gNB 200 may transmit a MAC CE including an index value of the multicast session to be released, for example, on the MTCH (using the group RNTI). For example, the gNB 200 may transmit a MAC CE including a list of index values ​​for each multicast session to be released. Here, the index value is information having a shorter bit length than the session identifier (TMGI). The index value is associated with the session identifier (TMGI) or the MRB ID. In this case, mapping information indicating the correspondence between the index value and the session identifier (TMGI) or the MRB ID is assumed to be pre-configured in the UE 100 in the SIB, MCCH, or dedicated RRC message (step S301 or S303). Alternatively, an index value indicating a discontinuous reception (DRX) setting configured for each multicast session may be used as the index value.

[0105] In step S308, UE100 recognizes the release of the multicast session being received based on the identification information received from gNB200 in step S307. In this case, UE100 may stop the reception operation of the MRB corresponding to the multicast session, for example, PDCCH monitoring. The AS of UE100 may notify the upper layer (NAS) of UE100 of the stop of the multicast session. For example, the AS of UE100 may notify the upper layer (NAS) of the identifier (TMGI) of the released multicast session. UE100 may initiate RRC recovery and send an RRC Resume Request message to gNB200.

[0106] (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. That is, the "RRC inactive state" in the operation according to the above-described embodiment and its modified examples may be read as the "RRC idle state." In the RRC idle state, RRC restoration (Resume) is read as RRC establishment (Establishment).

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

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

[0109] Also, the term "network node" primarily refers to a base station, but may also refer to a device in the core network or part of a base station (CU, DU, or RU).

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

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

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

[0113] This application claims priority to U.S. Provisional Application No. 63 / 410,725 (filed September 28, 2022), the entire contents of which are incorporated herein by reference.

[0114] (5) Supplementary Notes The following are additional notes regarding the features of the above-described embodiment.

[0115] (Supplementary Note 1) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step of a user equipment that is in a radio resource control (RRC) inactive state and has joined a multicast session receiving multicast data from a network node via the multicast session; and a step of the user equipment determining to transition from the RRC inactive state to an RRC connected state in response to detecting generation of uplink data belonging to the multicast session.

[0116] (Supplementary Note 2) The communication method according to Supplementary Note 1, further comprising: a step of initiating an RRC recovery procedure by the user equipment to transition to the RRC connected state; and a step of the user equipment transmitting, to the network node, notification information indicating generation of the uplink data belonging to the multicast session during the RRC recovery procedure.

[0117] (Supplementary Note 3) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step in which a user equipment in a radio resource control (RRC) connected state receives multicast settings required for receiving a multicast session together with version information of the multicast settings from a network node; a step in which the user equipment stores the version information; and a step in which the user equipment, which has transitioned from the RRC connected state to an RRC inactive state, receives broadcast information from the network node, the broadcast information including version information of the latest multicast settings of the multicast session.

[0118] (Supplementary Note 4) The communication method according to Supplementary Note 3, further comprising the step of: determining, by the user equipment, to transition from the RRC inactive state to the RRC connected state based on the version information in the broadcast information being different from the stored version information.

[0119] (Supplementary Note 5) A communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step in which a user equipment that is in a radio resource control (RRC) inactive state and has joined the multicast session receives multicast data from a network node via the multicast session; and a step in which the user equipment receives, from the network node, identification information of one or more multicast sessions to be released or stopped.

[0120] (Supplementary Note 6) The communication method according to Supplementary Note 5, further comprising the step of the user device determining release or stop of a multicast session currently being received based on the identification information.

[0121] (Supplementary Note 7) The communication method according to Supplementary Note 5 or 6, wherein the step of receiving the identification information includes a step of receiving a paging message including the identification information or a medium access control element (MAC CE) including the identification information.

[0122] (6) Supplementary Notes The following supplementary notes are provided for the above-mentioned embodiments. Introduction The work item on enhanced MBS (eMBS) aims to support multicast reception by UEs in inactivity as follows: - Specify support for multicast reception by UEs in RRC inactive state. - PTM configuration for UEs receiving multicast in RRC inactive state - Study on the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not mandatory).

[0123] RAN2#119e has initiated discussions for this purpose and reached a set of agreements, on which the details of multicast reception in inactive mode are discussed in this appendix.

[0124] Discussion Delivery Mode Baseline Rel-17 specifies two delivery modes: one for multicast sessions called "Delivery Mode 1" and one for broadcast sessions called "Delivery Mode 2". In Delivery Mode 1, MTCH reception is configured by RRCReconfiguration only for UEs in Connected state, while in Delivery Mode 2, MTCH reception is configured by MCCH for UEs in all RRC states.

[0125] RAN2#119e has defined these delivery modes as candidates for multicast reception in inactive mode, namely option 1 and option 2.

[0126] For PTM configuration distribution, RAN2 further considers the following solutions: Option 1: Dedicated signaling Option 2: SIB+MCCH based solution A "mix" of options is not excluded.

[0127] According to the addendum submitted in RAN2#119e, support for multicast reception in inactive mode is motivated by two reasons: network congestion and UE power saving.

[0128] Observation 1: Network congestion and UE power saving are the motivations for inactive multicast reception.

[0129] According to this contribution, option 1 is superior to option 2 in terms of signaling overhead, which directly impacts network congestion. In other words, from a motivation point of view, it does not make sense to allow additional signaling overhead due to SIB20 and MCCH transmissions when the network is in a congested state.

[0130] Observation 2: The signaling overhead due to MCCH transmission is significant under conditions of network congestion.

[0131] From the perspective of a UE in the inactive state, the UE performs DRX for paging monitoring and reduces power consumption. If option 2 is used for multicast reception in the inactive state, the UE needs to perform additional DRX activity, i.e., MCCH monitoring, which will result in additional power consumption. Therefore, it is inconsistent with the UE's motivation to reduce power consumption.

[0132] Observation 3: MCCH monitoring activity incurs additional UE power consumption in RRC inactivity.

[0133] Of course, Option 1 requires the UE to initiate the RRC Resume procedure when the MBS configuration is provided or updated. However, it clarifies that "once the MRB is configured and the session is active, the configuration will not be changed frequently during the session." Also, RAN2#119e agrees that "continuity of multicast service after cell reselection in the RRC inactive state (i.e., without restarting the RRC connection) is supported (if the new cell configuration is available to the UE)." Therefore, there are no major problems with network congestion or UE power consumption.

[0134] Furthermore, Rel-17 specifies that multicast services will be provided in so-called delivery mode 1 (option 1), and there is a common understanding in RAN2 that this is a fundamental concept of multicast design. There is no reason to make such a drastic change between releases.

[0135] Considering the above, option 1 is a simple way to provide PTM settings.

[0136] Proposal 1: RAN2 should agree that PTM configuration is provided by dedicated signaling, i.e. option 1.

[0137] RRC State Transitions In RAN2#119e, it was stated that further study was required regarding RRC state changes.

[0138] In Rel-18, multicast reception for an inactive UE is supported in at least the following scenarios, assuming that the UE already has a valid PTM configuration: - Scenario 1: The UE was receiving multicast in Connected mode, but entered Inactive mode and continues receiving multicast. - Scenario 2: The UE joined a multicast session and was induced to enter Inactive mode. Further study is required for the case where the state changes, such as when service is no longer provided in Inactive mode.

[0139] RRC state change may have many aspects from the network and UE perspective, so it will be explained case by case below.

[0140] Subcase 1: Releasing / Stopping a Multicast Session RAN2#119e has defined subcase 1 as an example.

[0141] Further consideration is required for cases where the status changes, such as when the service is no longer provided due to inactivity.

[0142] If an inactive UE is receiving an MBS service, the multicast session is released or stopped, and the gNB stops transmitting PTM / MTCH accordingly. In this case, there is no reason for the UE to continue monitoring the MTCH, but the UE needs to monitor the MTCH unless the PTM configuration is deleted. From the perspective of UE power saving, it is desirable to stop monitoring the MTCH as soon as possible.

[0143] Observation 4: It is inefficient in terms of UE power consumption for the UE to continue monitoring the PTM / MTCH even after the multicast session has been released or deactivated.

[0144] Therefore, the UE needs to be notified by the gNB of the release / inactivation of the configured multicast session. Further consideration is required as to whether release and inactivation should be handled separately and which signaling (e.g., MACCE or paging) should be used for this notification.

[0145] Proposal 2: When a multicast session is released or deactivated, inactive UEs should be notified and agree to stop monitoring the PTM / MTCH as soon as possible.

[0146] Sub-case 2: Selective Transition RAN2#119e reached the following agreement for sub-case 2: It is up to the gNB to decide whether UE(s) can receive a multicast session inactively. Further study is needed on what information to provide to the gNB to make such a decision (related to the discussion of SA2). It is supported for the gNB to send one multicast session to both Connected and Inactive UEs in the same cell. How the gNB configures this needs further study. It is assumed that the network can select which UEs receive in RRC Inactive and which UEs receive in RRC Connected, and can move UEs between states for multicast service reception.

[0147] When releasing a UE to inactivity, the gNB can select the UE to release based on the UE's capabilities, the UE's assistance information, and / or the CN's assistance information (if specified), in the same way as currently, i.e., by RRC Release with Suspend Config. Therefore, no enhancements regarding the selective transition of UEs are foreseen for the RRC release message.

[0148] On the other hand, when the gNB pages a UE inactively, it sends a multicast active notification, i.e., a RAN paging message including a TMGI. However, according to the current specification, if the paging message includes a TMGI of interest, all UEs initiate an RRC Resume procedure. If the gNB includes only the UE-ID for selective paging (i.e., no TMGI for paging selected Rel-18 UEs), it cannot page Rel-17 UEs that are inactive and waiting for multicast activation. Therefore, RAN2 needs to discuss whether it needs to extend the multicast active notification to page a subset of UEs.

[0149] Proposal 3: RAN2 needs to discuss whether it needs to enhance multicast active notification (i.e., RAN paging using TMGI) to page a subset of UEs.

[0150] Sub-case 3: QoS Enforcement RAN2#119e has reached the following agreements related to sub-case 3: HARQ feedback and PTP are not supported for multicast reception with RRC inactive.

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

[0152] On the other hand, in multicast sessions, ensuring QoS / reliability is an important issue. RAN2#119e proposes introducing reception quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. They are also useful for the network to manage QoS requirements. If inactive multicast reception cannot meet the corresponding QoS requirements, the UE must transition to Connected and use HARQ feedback / retransmission or PTP (or Split MRB) to guarantee reception quality.

[0153] Observation 5: Multicast sessions should ensure certain QoS requirements even when the UE is inactive.

[0154] Regarding the RSRP threshold, since NRMBS assumes single-cell transmission, it is considered that the UE needs to transition to the connected state every time it moves to a cell edge or performs cell reselection, which may not be optimal in some deployments from the viewpoint of network congestion and UE power saving.

[0155] The BLER threshold is considered to be easier to ensure QoS requirements, so if RRC state transitions based on reception quality are to be introduced, these options need to be discussed.

[0156] Proposal 4: RAN2 should agree that an inactive UE will transition to connected if the reception quality becomes worse than a threshold (e.g., RSRP or BLER).

[0157] Sub-case 4: Mobility and Service Continuity RAN2#119e agreed to the following statement for sub-case 4: Continuity of multicast service after cell reselection in RRC inactive state (i.e. without restarting RRC connection) is supported (if the new cell configuration is available to the UE). Further study is needed on whether the UE may need to restart the connection. Also, the impact of inter-GNB mobility on RAN3 needs further study. When cell reselection to a neighboring cell occurs during an active multicast session, if the session configuration is not available in the new cell for the inactive UE, the UE needs to restart the RRC connection to obtain the multicast MRB configuration.

[0158] In Rel-17 Delivery Mode 1, the PTM configuration is provided by the RRCReconfiguration message, so the UE must always be in the Connected state to receive the PTM configuration. To avoid transitioning to the Connected state, it is possible to provide the updated PTM configuration using an RRCRelease message. In this case, when the UE sends an RRCResumeRequest message, the gNB responds with an RRCRelease message containing the PTM configuration. Therefore, the UE does not need to transition to the Connected state to receive the updated PTM configuration. Such a procedure can be used during cell reselection (i.e., initiated by the UE when the PTM configuration is not available in the new cell) or RAN paging (i.e., initiated by the network when the PTM configuration needs to be updated).

[0159] Proposal 5: RAN2 should agree that RRCRelease is enhanced to provide PTM configuration.

[0160] Another issue to consider is the impact of UE mobility under the assumption that "seamless / lossless mobility is not required" as stated in WID. In Rel-17, it is clear that the PTM configuration for distribution mode 1 is valid only in the cell where the UE is configured. When a handover is performed, the target cell reconfigures the UE with a new PTM configuration. On the other hand, when an inactive UE performs idle mode mobility, the starting point can be considered as the moment when the existing PTM configuration is no longer valid in the reselected cell (i.e., the new cell).

[0161] The simplest solution with minimal impact on the specifications may be to always require an inactive UE to transition to Connected (e.g., before or after performing cell reselection) so that the UE can be handed over from the serving cell to the target cell or reconfigured by the reselected cell.

[0162] A more efficient method is to have the PTM configuration valid within the RNA, so the gNB must be able to apply the same configuration within the RNA of each UE. The advantage of this method is that inactive UEs do not need to be reconfigured and can continue to receive MTCH within the RNA. However, because the RNA is UE-specific, this increases network complexity.

[0163] A more flexible and less complicated method is for the gNB to provide a cell list in the configuration, whereby the configuration is considered valid for the cells in the list. The cell list can be configured as cell-specific, DU / CU-related, UE-specific, RNA-related, MRB area-specific, or MBS service area-specific, but this is up to the NW implementation.

[0164] Therefore, RAN2 should discuss whether to introduce area scope for such configurations.

[0165] Proposal 6: For a distribution mode 1 based solution, RAN2 should discuss whether the configuration for receiving MTCH is valid for the serving cell or for the area (RNA, cell list, etc.).

[0166] 1: Mobile communication system 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 used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment that is in a radio resource control (RRC) inactive state and has already joined a multicast session receives multicast data from a network node via the multicast session; the user equipment determines to transition from the RRC inactive state to the RRC connected state in response to detecting the generation of uplink data belonging to the multicast session. The communication method.

2. The user equipment starts an RRC recovery process for transitioning to the RRC connected state; The user equipment further transmits, in the RRC recovery process, notification information indicating the generation of the uplink data belonging to the multicast session to the network node. The communication method according to claim 1.

3. A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in an RRC connected state receives, from a network node, multicast settings necessary for receiving a multicast session together with version information of the multicast settings; the user equipment stores the multicast settings and the version information; the user equipment that has transitioned from the RRC connected state to the RRC inactive state receives, from the network node, broadcast information including version information of the latest multicast settings of the multicast session. The communication method.

4. The user equipment further determines to transition from the RRC inactive state to the RRC connected state based on the fact that the version information in the broadcast information is different from the stored version information. The communication method according to claim 3.

5. A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: A user equipment that is in a Radio Resource Control (RRC) inactive state and has already participated in a multicast session receives multicast data from a network node via the multicast session, and the user equipment receives identification information of one or more multicast sessions to be released or stopped from the network node. Communication method. **Claim 6** The user equipment further has the step of identifying the release or stop of the multicast session being received based on the identification information. The communication method according to claim 5. **Claim 7** Receiving the identification information includes receiving a paging message including the identification information or a Medium Access Control - Control Element (MAC CE) including the identification information. The communication method according to claim 5 or 6. **Claim 8** A user equipment used in a mobile communication system that provides a Multicast / Broadcast Service (MBS), comprising: a receiving unit that is in a Radio Resource Control (RRC) inactive state, has already participated in a multicast session, and receives multicast data from a network node via the multicast session; and a control unit that determines to transition from the RRC inactive state to the RRC connected state in response to detecting the generation of uplink data belonging to the multicast session. User equipment. **Claim 9** A user equipment used in a mobile communication system that provides a Multicast / Broadcast Service (MBS), wherein the user equipment is in a Radio Resource Control (RRC) inactive state and has already participated in the multicast session, receives multicast data from a network node via the multicast session, and comprises a receiving unit that receives identification information of one or more multicast sessions to be released or stopped from the network node. User equipment.