COMMUNICATION METHOD, USER EQUIPMENT, PROCESSOR, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

In the present invention, a communication method that is used in a mobile communication system that provides multicast / broadcast services (MBS) has a step in which a user device in a radio resource control (RRC)-connected state and having already participated in a multicast session receives a point-to-multipoint (PTM) configuration from a base station, on a dedicated control channel (DCCH). The receiving step includes a step in which, when the multicast session has been activated, the PTM configuration that includes the same information element as the information element provided on a multicast control channel (MCCH) is received from the base station on the DCCH channel.

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.3.0

[0005] A communication method according to a first aspect is a communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising a step of a user equipment in a radio resource control (RRC) connected state receiving a point-to-multipoint (PTM) configuration for a multicast session from a base station on a dedicated control channel (DCCH), the receiving step including receiving the PTM configuration from the base station on the DCCH, the PTM configuration including information elements identical to information elements provided on a multicast control channel (MCCH).

[0006] A communication method according to a second aspect is a communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising a step of a user equipment (UE) in a Radio Resource Control (RRC) connected state and having joined a multicast session receiving configuration information from a base station on a Dedicated Control Channel (DCCH), the receiving step including, if the multicast session has not yet been activated, receiving from the base station configuration information regarding permission for multicast reception in an RRC inactive state.

[0007] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. FIG. 2 is a diagram illustrating a configuration of a gNB (base station) according to an embodiment. FIG. 3 is a diagram illustrating a protocol stack configuration of a radio interface of a user plane that handles data. FIG. 4 is a diagram illustrating a protocol stack configuration of a radio interface of a control plane that handles signaling (control signals). FIG. 5 is a diagram illustrating an MBS Broadcast Configuration message in an MCCH specified in the RRC technical specification (TS38.331). FIG. 6 is a diagram illustrating an overview of an operation that enables a UE 100 in an RRC inactive state to perform multicast reception. FIG. 7 is a diagram for explaining an overview of an operation according to a first embodiment. FIG. 8 is a diagram illustrating an example of a first operation pattern according to the first embodiment. FIG. 9 is a diagram illustrating an example of a second operation pattern according to the first embodiment. FIG. 10 is a diagram illustrating an example of a first operation pattern according to the second embodiment. FIG. 11 is a diagram illustrating an example of an operation example when distribution mode 2 is applied to MBS multicast. FIG. 12 is a diagram illustrating the configuration of SIB20 specified in the RRC specification (TS38.331) of 3GPP Release 17. 10 is a diagram illustrating an operation of a mobile communication system according to another embodiment of the present invention;FIG. 11 is a diagram illustrating a PTM setting distribution procedure for an activated multicast session;FIG.

[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) First Embodiment A first embodiment will be described with reference to FIGS. 1 to 10. FIG.

[0010] (1.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). While the following description will be given using 5GS as an example, 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.

[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. 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 for 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 showing the configuration of a UE 100 (user equipment) according to an embodiment. The UE 100 has a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.

[0017] The receiving unit 110 performs various 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 the configuration of a gNB 200 (base station) 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] (1.2) MBS The mobile communication system 1 can perform resource-efficient distribution using multicast / broadcast service (MBS). Note that a session refers to a series of communications (from start to finish) for a service (application), and an MBS session refers to a session used in MBS.

[0037] 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. In other words, 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 PTP (Point-to-Point) and / or PTM (Point-to-Multipoint) delivery. The UEs 100 may receive the multicast communication service in an RRC inactive (or RRC idle) state. This delivery mode is also referred to as "Delivery Mode 1." Note that the UEs 100 can receive the multicast session only after joining the multicast session. Here, joining a multicast session may mean being registered in the network 5 (CN 20) as a UE 100 capable of receiving the multicast session.

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

[0039] The main logical channels used for MBS distribution are a multicast traffic channel (MTCH), a dedicated traffic channel (DTCH), and a multicast control channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast session or a 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. Note that in distribution mode 1, various settings for the UE 100 are performed using a dedicated control channel (DCCH).

[0040] In MBS multicast, the transmission of MBS data packets (also referred to as "MBS packets") can be either point-to-point (PTP) transmission, which is equivalent to unicast, or point-to-multipoint (PTM) transmission. In contrast, in MBS broadcast, only PTM transmission can be applied. In the case of PTP transmission, the gNB 200 can independently deliver individual copies of the MBS packet to each UE 100. For example, the gNB 200 schedules a UE-specific PDSCH scrambled with a UE-specific RNTI (e.g., C-RNTI) using a UE-specific PDCCH having a CRC (Cyclic Redundancy Code) scrambled with the UE-specific RNTI. On the other hand, in the case of PTM transmission, the gNB 200 delivers a single copy of the MBS packet to a set (group) of multiple UEs 100. For example, gNB200 schedules a group-common PDSCH scrambled by a group-common RNTI using a group-common PDCCH having a CRC scrambled by a group-common RNTI (e.g., G-RNTI).

[0041] 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 PTM 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 broadcast session-related information includes an MBS session identifier (e.g., TMGI (Temporary Mobile Group Identity)), related MTCH scheduling information, and information on neighboring cells providing a specific service on the MTCH.

[0042] 6 is a diagram showing an MBS Broadcast Configuration message in the MCCH defined in the RRC technical specification (TS38.331). The MCCH includes an MBS session information list (mbs-SessionInfoList) that provides the configuration of each MBS session (each broadcast session) provided by MBS broadcast in the current cell, a list of neighboring cells that provide the MBS broadcast service via the broadcast MRB (mbs-NeighborCellList), a list of DRX settings (drx-ConfigPTM-List), and parameters for acquiring a PDSCH for the MTCH (pdsch-ConfigMTCH).

[0043] 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 PTM configuration for the multicast session to UE 100. Such PTM configuration is also referred to as multicast radio bearer (MRB) configuration, MTCH configuration, or PTM configuration. The MRB configuration (MRB-ToAddMod) includes other parameters such as an MBS session identifier (mbs-SessionId), an MRB identifier (mrb-Identity), and a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured in UE 100.

[0044] 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. 7 is a diagram showing an overview of the operation.

[0045] As a solution for the UE 100 in the RRC inactive state to perform multicast reception, a solution based on delivery mode 1 shown in Fig. 7(a) and a solution based on delivery mode 2 shown in Fig. 7(b) can be considered. It is assumed that the UE 100 supports multicast reception in the RRC inactive state and has already participated in the multicast session.

[0046] In the distribution mode 1-based solution shown in Figure 7 (a), in step S1, gNB200 transmits an RRC Reconfiguration message including an MBS setting (PTM 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 PTM setting received in the RRC Reconfiguration message.

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

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

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

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

[0051] 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 or dedicated signaling.

[0052] On the other hand, in the distribution mode 2-based solution shown in FIG. 7(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.

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

[0054] In step S13, gNB200 transmits an MCCH including an MBS setting (PTM 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. Note that MCCH transmission (and reception) may be performed before step S11 or may be performed simultaneously with step S11.

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

[0056] A solution that combines a solution based on distribution mode 1 and a solution based on distribution mode 2 may also be considered. For example, a mixed setting method is possible in which the initial setting of the MBS setting (PTM setting) is performed by dedicated signaling and the update of the MBS setting (PTM setting) is performed by MCCH.

[0057] (1.3) Operation according to the first embodiment Fig. 8 is a diagram for explaining an overview of the operation according to the first embodiment. Fig. 8(a) shows, as a comparative example, an example of a mixed setting method in which a solution based on distribution mode 1 and a solution based on distribution mode 2 are mixed. Fig. 8(b) shows an overview of the operation according to the first embodiment.

[0058] 8A, in step S51, the UE 100 is in an RRC connected state. The UE 100 supports multicast reception in an RRC inactive state and has already participated in a multicast session.

[0059] In step S52, the gNB 200 transmits an RRC Reconfiguration message including an MBS setting (PTM setting) for the multicast session to the UE 100 in the RRC connected state on the DCCH. The UE 100 receives the RRC Reconfiguration message and establishes a multicast MRB. At this point, the multicast session is activated.

[0060] In step S53, gNB200 transmits the multicast session on MTCH. UE100 receives the multicast session on MTCH via the multicast MRB based on the PTM setting received in the RRC Reconfiguration message of step S52.

[0061] In step S54, gNB200 sends an RRC Release message to UE100 in the RRC connected state to transition UE100 to the RRC inactive state.

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

[0063] In step S56, the gNB 200 transmits the SIB 20 including the MCCH setting on the BCCH. The UE 100 in the RRC inactive state receives the SIB 20.

[0064] In step S57, the gNB 200 transmits a PTM configuration (e.g., an MBS Broadcast Configuration message) for the multicast session on the MCCH. The UE 100 in the RRC inactive state receives the PTM configuration on the MCCH based on the SIB 20 in step S56. The UE 100 establishes a new MRB according to the PTM configuration. The new MRB may be a broadcast MRB.

[0065] In step S58, the gNB 200 transmits the multicast session on the MTCH via the new MRB. The UE 100 in the RRC inactive state receives the multicast session on the MTCH.

[0066] As described above, in the comparative example shown in FIG. 8(a), since UE100 acquires SIB20 (step S56) and MCCH (step S57) after transitioning to the RRC inactive state (step S55), there is a problem that service interruption may occur due to the acquisition of SIB20 and MCCH.

[0067] In the first embodiment, as shown in FIG. 8(b), the gNB 200 transmits a PTM configuration for the multicast session to the UE 100 that is in the RRC connected state and has already participated in the multicast session on the DCCH (step S104). Here, when the multicast session is activated, the gNB 200 transmits a PTM configuration including the same information element as the information element provided on the MCCH on the DCCH. The UE 100 that is in the RRC connected state and has already participated in the multicast session receives the PTM configuration on the DCCH (step S104). As a result, the UE 100 transitions to the RRC inactive state (step S105) and then can quickly receive the multicast session on the MTCH (step S106).

[0068] Specifically, as shown in Fig. 8(b), in step S101, the UE 100 is in an RRC connected state. The UE 100 supports multicast reception in an RRC inactive state and has already participated in a multicast session.

[0069] In step S102, the gNB 200 transmits an RRC Reconfiguration message including an MBS setting (PTM setting) for the multicast session to the UE 100 in the RRC connected state on the DCCH. The UE 100 receives the RRC Reconfiguration message and establishes a multicast MRB (first MRB). At this point, the multicast session is activated.

[0070] In step S103, gNB200 transmits the multicast session on MTCH. UE100 receives the multicast session on MTCH via the multicast MRB based on the PTM setting received in the RRC Reconfiguration message in step S102.

[0071] In step S104, the gNB 200 transmits a PTM setting similar to the PTM setting (e.g., an MBSBroadcastConfiguration message) transmitted on the MCCH to the UE 100 in the RRC connected state on the DCCH (i.e., dedicated signaling). For example, the gNB 200 transmits an RRC Reconfiguration message including the PTM setting or an RRC Release message including the PTM setting. The UE 100 in the RRC connected state receives the PTM setting on the DCCH. The UE 100 recognizes the received PTM setting as setting information for multicast reception. The UE 100 establishes a new MRB (second MRB) according to the PTM setting. The new MRB may be a broadcast MRB.

[0072] In step S105, UE100 transitions to the RRC inactive state. If step S104 is performed using an RRC Reconfiguration message, gNB200 transmits an RRC Release message to transition UE100 to the RRC inactive state. UE100 transitions to the RRC inactive state in response to receiving the RRC Release message.

[0073] In step S106, the gNB 200 transmits the multicast session on the MTCH via the new MRB (second MRB). The UE 100 in the RRC inactive state receives the multicast session on the MTCH.

[0074] The UE 100 may perform a predetermined process for switching from the first MRB to the second MRB depending on a comparison result between the sequence number of the MBS packet received via the first MRB for the RRC connected state and the sequence number of the MBS packet received via the second MRB for the RRC inactive state. This makes it easy to match received packets between the first MRB and the second MRB.

[0075] In the first operation pattern of the first embodiment, step S104 is performed by an RRC Reconfiguration message. In this case, the predetermined process may be a process of transmitting a notification for the switching (e.g., a consistency notification) to the gNB 200. In the second operation pattern of the first embodiment, step S104 is performed by an RRC Release message. In this case, the predetermined process may be a process of transitioning from an RRC connected state to an RRC inactive state.

[0076] 9 is a diagram showing an example of the first operation pattern of the first embodiment, in which description of operations that overlap with the operations shown in FIG.

[0077] In step S111, the UE 100 in the RRC connected state participates in a multicast session.

[0078] In step S112, gNB200 transmits a multicast MRB setting (PTM setting) to UE100 in an RRC Reconfiguration message. UE100 receives the PTM setting and establishes a multicast MRB (first MRB). In addition, the multicast session becomes activated.

[0079] In step S113, UE100 in the RRC connected state receives a multicast session from gNB200 on MTCH via the first MRB.

[0080] In step S114, gNB200 decides to have UE100 perform multicast reception in an RRC inactive state.

[0081] In step S115, gNB200 transmits the PTM configuration of the multicast session (configuration information such as MTCH scheduling) to UE100 via DCCH. In this operation pattern, the message transmitted on the DCCH in step S115 is an RRC Reconfiguration message. UE100 receives the PTM configuration and establishes a second MRB. The second MRB may be 1) a multicast MRB, 2) a broadcast MRB for multicast, or 3) a new type of MRB for multicast reception in an RRC inactive state. UE100 associates the originally configured multicast MRB (first MRB) with the newly configured MRB for the RRC inactive state (second MRB).

[0082] Here, the PTM setting in step S115 may be the same as the MBS broadcast setting provided on the MCCH. The PTM setting in step S115 is new information used for multicast reception in the RRC inactive state, and may include the same information elements as the MBS broadcast setting provided on the MCCH.

[0083] The PTM settings in step S115 may include only the PTM settings of multicast sessions that UE 100 is currently receiving. That is, the PTM settings in step S115 may include only the PTM settings of activated multicast sessions. Alternatively, the PTM settings in step S115 may include only the PTM settings of MBS sessions in which a multicast MRB is configured in UE 100. The PTM settings in step S115 may not include the PTM settings of broadcast sessions. Alternatively, the PTM settings in step S115 may include only the PTM settings of multicast sessions in which UE 100 has joined. That is, the PTM settings in step S115 may include only the PTM settings of multicast sessions that can be activated.

[0084] In step S116, UE100 recognizes that the PTM setting received from gNB200 via DCCH is related to a multicast session. Here, UE100 may perform this recognition when it receives a PTM setting that does not include an MRB setting (MRB-ToAddMod). Alternatively, UE100 may perform this recognition when it receives a PTM setting that does not include an MRB identifier (MRB-Identity). UE100 may recognize the PTM setting as a setting to be used for reception in an RRC inactive state. However, UE100 may perform multicast reception using the setting while remaining in an RRC connected state.

[0085] In step S117, UE100 in the RRC connected state receives a multicast session from gNB200 on the MTCH via the second MRB based on the PTM setting in step S115.

[0086] In step S118, the UE 100 in the RRC connected state compares the sequence number (SN) of the received packet in the first MRB with the SN of the received packet in the second MRB. For example, the UE 100 compares the PDCP SN of the received PDCP packet in the first MRB with the PDCP SN of the received PDCP packet in the second MRB. The UE 100 may determine that there are no unreceived packets if there is no gap between the SN of the packet last received in the first MRB and the SN of the packet first received in the second MRB. Alternatively, the UE 100 may determine that there are no unreceived packets if the difference between the SN of the packet last received in the first MRB and the SN of the packet first received in the second MRB is equal to or less than a threshold. The threshold may be set to the UE 100 by the gNB 200.

[0087] In step S119, the UE 100 in the RRC connected state transmits a notification to the gNB 200 indicating that switching from the first MRB to the second MRB is possible or that the switching has been completed. The UE 100 may transmit the notification to the gNB 200 by including it in a response message (for example, an RRC Reconfiguration Complete message) corresponding to the RRC Reconfiguration message of step S115. Alternatively, the UE 100 may transmit the notification in a UE Assistance Information message. For example, the UE 100 may transmit the information as part of Release Assistance Information (specifically, "ReleasePreference" IE), which is an information element included in a UE Assistance Information message.

[0088] In step S120, based on the notification of step S119, gNB200 sends an RRC Release message to UE100 to transition UE100 to the RRC inactive state.

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

[0090] In step S122, UE100 in the RRC connected state receives a multicast session from gNB200 on the MTCH via the second MRB based on the PTM setting in step S115.

[0091] 10 is a diagram showing an example of the second operation pattern of the first embodiment. Here, a description of operations that overlap with the first operation pattern of FIG. 9 will be omitted.

[0092] The operations in steps S131 to S134 are the same as the operations in steps S111 to S114 in FIG.

[0093] In step S135, gNB200 transmits the PTM configuration of the multicast session (configuration information such as MTCH scheduling) to UE100 via DCCH. In this operation pattern, the message transmitted on the DCCH in step S135 is an RRC Release message. UE100 receives the PTM configuration and establishes a second MRB. The second MRB may be 1) a multicast MRB, 2) a broadcast MRB for multicast, or 3) a new type of MRB for multicast reception in an RRC inactive state. UE100 associates the originally configured multicast MRB (first MRB) with the newly configured MRB for the RRC inactive state (second MRB).

[0094] Here, the PTM setting in step S135 may be the same as the MBS broadcast setting provided on the MCCH. The PTM setting in step S135 is new information used for multicast reception in the RRC inactive state, and may include the same information elements as the MBS broadcast setting provided on the MCCH.

[0095] The PTM settings in step S135 may include only the PTM settings of the multicast sessions currently being received by UE 100. That is, the PTM settings in step S135 may include only the PTM settings of the activated multicast sessions. Alternatively, the PTM settings in step S135 may include only the PTM settings of the MBS sessions for which the multicast MRB is configured in UE 100. The PTM settings in step S135 may not include the PTM settings of the broadcast sessions.

[0096] In step S136, UE100 recognizes that the PTM setting received from gNB200 via DCCH is related to a multicast session. UE100 may recognize the PTM setting as a setting to be used for reception in an RRC inactive state. However, UE100 may perform multicast reception using the setting while remaining in the RRC connected state.

[0097] In step S137, UE 100 in the RRC connected state receives the multicast session on the MTCH via the second MRB from gNB 200 based on the PTM setting in step S135. At this point, UE 100 that has received the RRC Release message suspends transition to the RRC inactive state.

[0098] In step S138, the UE 100 in the RRC connected state compares the sequence number (SN) of the received packet in the first MRB with the SN of the received packet in the second MRB. For example, the UE 100 compares the PDCP SN of the received PDCP packet in the first MRB with the PDCP SN of the received PDCP packet in the second MRB. The UE 100 may determine that there are no unreceived packets if there is no gap between the SN of the packet last received in the first MRB and the SN of the packet first received in the second MRB. Alternatively, the UE 100 may determine that there are no unreceived packets if the difference between the SN of the packet last received in the first MRB and the SN of the packet first received in the second MRB is equal to or less than a threshold. The threshold may be set in the UE 100 by the gNB 200.

[0099] In step S139, the UE 100 in the RRC connected state transitions to the RRC inactive state.

[0100] In step S140, UE100 in the RRC connected state receives a multicast session from gNB200 on the MTCH via the second MRB based on the PTM setting in step S135.

[0101] (2) Second Embodiment A second embodiment will be described, focusing on differences from the first embodiment, with reference to Figures 11 and 12. The second embodiment may be implemented in combination with the first embodiment.

[0102] In the above-described first embodiment, an example was described in which, when a multicast session is activated, gNB200 provides UE100 with a PTM setting to be used in an RRC inactive state via DCCH (dedicated signaling).

[0103] In contrast, in the second embodiment, in a situation where the multicast session has not yet been activated, configuration information regarding the RRC inactive state is provided by DCCH (dedicated signaling) from the gNB 200 to the UE 100. Specifically, the gNB 200 configures the UE 100 in the RRC connected state for the multicast session in the inactive state (before activation) by dedicated signaling, with information regarding permission for multicast reception in the RRC inactive state.

[0104] In the second embodiment, UE100, which is in an RRC connected state and has already joined a multicast session, receives configuration information on a DCCH from gNB200. Here, if the multicast session has not yet been activated, UE100 receives configuration information regarding permission to receive multicast in an RRC inactive state from gNB200 on a DCCH.

[0105] This makes it possible to smoothly receive multicast signals in the RRC inactive state.

[0106] In a first operation pattern of the second embodiment, the setting information includes an information element instructing the UE 100 to monitor the MCCH (obtain the PTM setting from the MCCH). The information element may be an information element instructing the UE 100 to monitor the MCCH after transitioning to the RRC inactive state. The UE 100 monitors the MCCH based on the information element.

[0107] In a second operation pattern of the second embodiment, the configuration information may include an information element that permits a request for an MCCH when the serving cell is not transmitting the MCCH. The information element may be an information element that permits a request for an MCCH when the current serving cell is not transmitting the MCCH after transitioning to the RRC inactive state and when the multicast session is activated. When the UE 100 detects activation of the multicast session, if the MCCH is not provided by the gNB 200 at the time of the detection, the UE 100 requests the gNB 200 to provide the MCCH.

[0108] In the second embodiment, the setting information may include an information element that prohibits the UE 100 from transitioning to the RRC connected state in response to reception of a paging message indicating activation of the multicast session. Even if the UE 100 receives a paging message indicating activation of the multicast session from the gNB 200, the UE 100 maintains the RRC inactive state without transitioning to the RRC connected state.

[0109] FIG. 11 is a diagram illustrating an example of the first operation pattern according to the second embodiment.

[0110] In step S201, the UE 100 in an RRC connected state participates in a multicast session.

[0111] In step S202, gNB200 recognizes that the multicast session has not yet been activated (i.e., is in an inactive state). Note that gNB200 can recognize whether the multicast session has been activated based on a message (e.g., a "MULTICAST SESSION ACTIVATION REQUEST" message) received on the NG interface from CN20 (AMF300A).

[0112] In step S203, the gNB 200 transmits configuration information regarding multicast reception in the RRC inactive state to the UE 100 in the RRC connected state on the DCCH (i.e., by dedicated signaling). The UE 100 receives the configuration information on the DCCH. The dedicated signaling may be an RRC Reconfiguration message or an RRC Release message.

[0113] The configuration information of step S203 may include an information element instructing the UE 100 to monitor the MCCH (even in the RRC connected state). Alternatively, the configuration information of step S203 may include an information element instructing the UE 100 to monitor the MCCH when the UE 100 transitions to the RRC inactive state. The configuration information of step S203 may include an MBS session ID (e.g., TMGI) of a multicast session for which PTM configuration should be acquired from the MCCH. Note that the UE 100 may notify the gNB 200 when it successfully receives the MCCH (in the RRC connected state) (or when it successfully establishes an MRB). The UE 100 may transmit the notification in a UE Assistance Information message. For example, it may be transmitted as part of Release Assistance Information (specifically, "ReleasePreference" IE), which is an information element included in UE Assistance Information. Alternatively, the UE 100 may notify the gNB 200 when it fails to receive the MCCH.

[0114] The configuration information of step S203 may include an information element that instructs UE100 not to monitor group paging (i.e., a paging message including the MBS session ID of the multicast session to be activated) in the RRC inactive state, or to ignore the MBS session ID in the paging message. In this way, by having UE100 ignore the group paging, UE100 is prevented from transitioning to the RRC connected state in response to receiving the group paging, making it easier for UE100 to continue multicast reception in the RRC inactive state. Specifically, even if an MBS session of interest to UE100 is activated and a paging message including the MBS session ID of the MBS session is transmitted from gNB200, UE100 can be controlled not to transition to the RRC connected state.

[0115] In step S204, the UE 100 may transition to an RRC inactive state. If step S203 is performed using an RRC Reconfiguration message, the gNB 200 may transmit an RRC Release message to transition the UE 100 to the RRC inactive state. The UE 100 may transition to the RRC inactive state in response to receiving the RRC Release message.

[0116] In step S205, the UE 100 in the RRC inactive state or the RRC connected state starts monitoring the MCCH based on the setting information in step S203.

[0117] In step S206, gNB200 transmits (broadcasts) the PTM configuration for the multicast session on the MCCH. gNB200 recognizes that the multicast session has been activated and may transmit (broadcast) the PTM configuration for the activated multicast session on the MCCH. UE100 receives the PTM configuration on the MCCH.

[0118] In step S207, gNB200 transmits (multicasts) the multicast session on MTCH. UE100 receives the multicast session on MTCH based on the PTM setting in step S206.

[0119] Fig. 12 is a diagram showing an example of a second operation pattern according to the second embodiment. Here, a description of operations that overlap with the first operation pattern shown in Fig. 11 will be omitted. Note that this second operation pattern may be implemented in combination with the first operation pattern shown in Fig. 11.

[0120] In step S231, the UE 100 is in an RRC connected state and has already participated in the multicast session.

[0121] In step S232, gNB200 recognizes that the multicast session has not yet been activated (i.e., is in an inactive state).

[0122] In step S233, the gNB 200 transmits configuration information regarding multicast reception in an RRC inactive state to the UE 100 in an RRC connected state on the DCCH. The UE 100 receives the configuration information on the DCCH. The configuration information may include an information element that instructs the UE 100 to acquire PTM configuration from the MCCH. The configuration information may include an information element that allows the UE 100 to request the MCCH.

[0123] In step S234, the gNB 200 may transition the UE 100 to an RRC inactive state by an RRC Release message. The UE 100 that has transitioned to the RRC inactive state may reselect a cell other than the cell in which the setting in step S233 was performed.

[0124] In step S235, UE100 in the RRC inactive state or the RRC connected state recognizes the activation timing, which is the timing at which the multicast session is started (activated). The activation timing may be the timing at which UE100 receives a group paging including the MBS session ID of the multicast session from gNB200. The activation timing may be the timing at which UE100 receives an MCCH Change Notification from gNB200 and the PTM setting of the multicast session is added. The activation timing may be the timing at which the start time of the multicast session is reached, based on USD (User Service Description) information previously stored by UE100.

[0125] In step S236, the UE 100 in the RRC inactive state or the RRC connected state starts monitoring the MCCH in response to recognizing the activation timing.

[0126] Here, if the MCCH is not broadcast from the gNB 200 (current serving cell) (step S237: YES), in step S238, the UE 100 in the RRC inactive state or the RRC connected state transmits an MCCH request to the gNB 200. The UE 100 may transmit the MCCH request in Msg 1, Msg 3, or Msg 5 of the random access procedure. The UE 100 may transmit the MCCH request in an MBS Interest Indication message or a UE Assistance information message.

[0127] In step S239, gNB200 transmits the PTM setting of the multicast session on the MCCH. Here, gNB200 may start broadcasting the MCCH. Alternatively, gNB200 may transmit the MCCH content (PTM setting) to UE100 in an RRC connected state using an RRC Reconfiguration message. Alternatively, gNB200 may transmit the MCCH content (PTM setting) to UE100 using an RRC Release message. For example, UE100 may request the MCCH content (PTM setting) from gNB200 using Msg3 (RRC Resume message) of the random access procedure, and in response to Msg3, gNB200 may transmit the MCCH content (PTM setting) to UE100 using an RRC Release message.

[0128] In step S240, gNB200 transmits (multicasts) the multicast session on MTCH. UE100 receives the multicast session on MTCH based on the PTM setting in step S239.

[0129] (3) Other Embodiments In the above-described embodiment, an example has been described in which the gNB 200 broadcasts the SIB 20 and the MCCH in distribution mode 2. FIG. 13 is a diagram for explaining an example of operation when distribution mode 2 is applied to MBS multicast. When distribution mode 2 is applied to MBS multicast, the following procedure can be considered. Specifically, first, the gNB 200 transmits the SIB 20 including the MCCH configuration (specifically, MCCH scheduling information, etc.) to the UE 100 (UEs 100a to 100c in the illustrated example) on the broadcast control channel (BCCH). FIG. 14 shows the configuration of the SIB 20 specified in the RRC specification (TS38.331) of 3GPP Release 17. The SIB 20 includes the MCCH configuration, mcch-Config-r17. Second, the PTM setting (MTCH setting) is transmitted on the MCCH from the gNB 200 to the UE 100. Third, the multicast session (specifically, multicast PTM data) is transmitted on the MTCH from the gNB 200 to the UE 100.

[0130] Here, since SIB20 transmission and MCCH transmission are performed by broadcast, all UEs 100 in the cell to which SIB20 and MCCH are transmitted can receive the multicast session. However, MBS multicast should be received only by a specific set of UEs participating in the multicast session. Therefore, there is a security concern if the multicast PTM setting (i.e., MCCH) can be acquired by all UEs 100. In another embodiment, an operation (communication method) capable of performing appropriate multicast distribution using MCCH will be described.

[0131] FIG. 15 is a diagram for explaining the operation (communication method) of the mobile communication system 1 according to another embodiment.

[0132] In a communication method according to another embodiment, first, the gNB 200 transmits scheduling information (MCCH setting) of the MCCH that transmits the PTM setting of the multicast session to the UE 100 (UE 100a in the illustrated example) in the RRC connected state by dedicated signaling (e.g., DCCH). The UE 100 receives the MCCH scheduling information (MCCH setting). Here, the MCCH scheduling information (MCCH setting) is scheduling information of the MCCH for the multicast session that transmits the PTM setting of the multicast session. The MCCH for the multicast session is an MCCH that is different from the MCCH for the broadcast session that transmits the PTM setting of the broadcast session.

[0133] Second, the gNB 200 transmits the MCCH for the multicast session. The gNB 200 may transmit the MCCH for the multicast session using a different scheduling (e.g., time / frequency resources) than the MCCH for the broadcast session. The UE 100 (in the illustrated example, the UE 100a) receives the MCCH for the multicast session. At this time, the UE 100 may be in an RRC connected state, an RRC inactive state, or an RRC idle state.

[0134] Third, the gNB 200 transmits a multicast session (multicast MBS data) on the MTCH. The UE 100 (in the illustrated example, the UE 100a) receives the multicast session. At this time, the UE 100 may be in an RRC connected state, an RRC inactive state, or an RRC idle state.

[0135] As described above, in another embodiment, the MCCH configuration for the MCCH for the multicast session is provided to the UEs 100 by dedicated signaling. This allows the MCCH configuration for the multicast session to be provided only to specific UEs 100 (or a specific set of UEs 100). Therefore, even when the MCCH is used, it becomes easy for only specific UEs 100 (or a specific set of UEs 100) participating in the multicast session to receive the multicast session.

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

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

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

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

[0140] A program may be provided that causes a computer to execute each process performed by the UE 100, the gNB 200, or the relay device. 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, the gNB 200, or the relay device may be integrated, and at least a portion of the UE 100, the gNB 200, or the relay device may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0141] The functions performed by the UE 100, the gNB 200 (network node), or the relay device may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (a Central Processing Unit), 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.

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

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

[0144] This application claims priority to U.S. Provisional Application No. 63 / 443,083 (filed February 3, 2023), the entire contents of which are incorporated herein by reference.

[0145] (4) Supplementary Notes Characteristic features of the above-described embodiment are as follows.

[0146] (Supplementary Note 1) A communication method used in a mobile communication system providing a multicast / broadcast service (MBS), comprising a step of a user equipment in a radio resource control (RRC) connected state and having joined a multicast session receiving a point-to-multipoint (PTM) configuration for the multicast session from a base station on a dedicated control channel (DCCH), wherein the receiving step includes a step of receiving from the base station on the DCCH the PTM configuration including information elements that are the same as information elements provided on a multicast control channel (MCCH) when the multicast session is activated.

[0147] (Supplementary Note 2) The communication method according to Supplementary Note 1, further comprising the step of the user device recognizing the received PTM setting information as setting information for multicast reception.

[0148] (Supplementary Note 3) The communication method according to Supplementary Note 1 or 2, further comprising the steps of: the user equipment receiving the multicast session via a first multicast radio bearer (MRB); the user equipment establishing a second MRB different from the first MRB based on the PTM setting; and the user equipment performing a predetermined process for switching from the first MRB to the second MRB depending on a comparison result between a sequence number of an MBS packet received via the first MRB and a sequence number of an MBS packet received via the second MRB.

[0149] (Supplementary Note 4) The communication method according to Supplementary Note 3, wherein the step of receiving the PTM configuration includes a step of receiving an RRC reconfiguration message including the PTM configuration, and the step of performing the predetermined processing includes a step of transmitting a notification for the switching to the base station.

[0150] (Supplementary Note 5) The communication method according to Supplementary Note 3, wherein the step of receiving the PTM configuration includes a step of receiving an RRC release message including the PTM configuration, and the step of performing the predetermined processing includes a step of transitioning from the RRC connected state to the RRC inactive state.

[0151] (Supplementary Note 6) 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) connected state and has already joined a multicast session receiving configuration information from a base station on a dedicated control channel (DCCH), wherein the receiving step includes a step of receiving from the base station, if the multicast session has not yet been activated, configuration information regarding permission for multicast reception in an RRC inactive state.

[0152] (Supplementary Note 7) The communication method according to Supplementary Note 6, wherein the configuration information includes an information element instructing monitoring of a multicast control channel (MCCH), and further comprising the step of the user equipment monitoring the MCCH based on the information element.

[0153] (Supplementary Note 8) The communication method according to Supplementary Note 6 or 7, wherein the configuration information includes an information element that allows the user equipment to request the base station to provide a multicast control channel (MCCH), and further comprises the steps of: the user equipment detecting activation of the multicast session; and the user equipment requesting the base station to provide the MCCH if the MCCH is not provided by the base station upon the detection.

[0154] (Supplementary Note 9) The communication method according to any one of Supplementary Notes 6 to 8, wherein the configuration information includes an information element that prohibits the user equipment from transitioning to an RRC connected state in response to reception of a paging message indicating activation of the multicast session.

[0155] (5) Supplementary Note 1. Introduction The work item on enhancements to MBS (eMBS) aims to support multicast reception by UEs in inactivity as follows: Specify support for multicast reception by UEs in RRC inactive state [RAN2, RAN3] PTM configuration for UEs receiving multicast in RRC inactive state [RAN2] Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not mandatory) [RAN2, RAN3]

[0156] RAN2 has been discussing this goal and has reached a set of agreements. Based on these agreements, the PTM configuration and mobility aspects of multicast reception in inactive mode are discussed in this appendix.

[0157] 2. Discussion 2.1. PTM Configuration Distribution Rel-17 specifies two distribution modes: a mode called "Distribution Mode 1" for multicast sessions and a mode called "Distribution Mode 2" for broadcast sessions. In Distribution Mode 1, MTCH reception is configured by RRC reconfiguration only for UEs in the Connected state, while in Distribution Mode 2, MTCH reception is configured by MCCH for UEs in all RRC states.

[0158] RAN2#119e defines these delivery modes, namely option 1, option 2, and a "mix" of these options, as candidates for multicast reception in inactive mode.

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

[0160] RAN2#120 has reached an agreement to move forward with a "mixed approach". It will have a mixed approach and start as follows: 1. When the NW configures a UE to continue multicast reception in an inactive state, the NW provides PTM configuration for activated multicast sessions via RRC dedicated signaling, at least to the serving cell (other cases require further study). 2. MCCH is used when the PTM configuration needs to be changed or when the PTM configuration needs to be indicated during transition across serving cells / gNBs. Session state changes and other indications require further study. 3. It is assumed that the UE can receive multicast services only after joining the session. 4. Whether the MCCH configuration is initially provided to the UE via dedicated signaling requires further study.

[0161] According to agreement #1 above, the network configures the PTM settings of the activated multicast session to the UE via dedicated signaling. It is assumed that since the multicast session is activated, the connected UE is already receiving the multicast session and this PTM configuration allows the UE to continue receiving the multicast session even after transitioning to inactive.

[0162] In this disclosure, the "mixed approach" agreed upon by RAN2 means using the MCCH for updating PTM configuration, etc., and is therefore closer to Rel-17's Delivery Mode 2. In this sense, dedicated signaling only provides MCCH content (e.g., MBS Broadcast Configuration) rather than Rel-17-specific multicast configuration (e.g., mrb-ToAddModList). Such dedicated signaling is useful for avoiding UEs monitoring the MCCH in the Connected state and minimizing service interruptions due to delays in MCCH acquisition after transitioning to the Inactive state.

[0163] Proposal 1: RAN2 should agree to provide MCCH content (i.e., MBS Broadcast Configuration) for multicast reception when dedicated signaling is inactive.

[0164] On the other hand, since RAN2 has agreed that an inactive UE can start receiving a multicast session, i.e., scenario 2 in the agreement below, it is unclear what can be configured for the inactivated multicast session.

[0165] In Rel-18, multicast reception for a UE in inactive state supports at least the following scenarios, assuming that the UE already has a valid PTM configuration: - Scenario 1: The UE is receiving multicast in Connected state, enters Inactive state, and continues receiving multicast. - Scenario 2: The UE joins a multicast session, is induced to Inactive state, and the UE starts receiving the multicast session. State changes, e.g., due to services not provided in Inactive state, require further study.

[0166] It is assumed that the actual PTM configuration cannot be provided for an inactivated multicast session, but will be provided once the multicast session is activated. In Rel-17, an inactive UE transitions to Connected upon receiving a group paging for multicast session activation. Therefore, some kind of indication may be provided in advance via dedicated signaling to allow the UE to remain inactive and use the PTM configuration obtained from the MCCH for the multicast session. Another approach is for such an indication to be provided by group paging as discussed in the following section.

[0167] Proposal 2: RAN2 should discuss whether any configuration can be provided via dedicated signaling if the UE transitions to inactivity before the multicast session is activated.

[0168] As per agreement #2 above, the MCCH is used when the PTM setting needs to be changed or when the PTM setting needs to be indicated during transition beyond the serving cell / gNB. The session status change and other indications are a bit ambiguous. That is, it is unclear whether the MCCH is used for indication or to provide the PTM setting. If it were only an indication, it could mean an MCCH Change Notification. However, the MCCH provides the PTM setting, for example, updating the PTM setting configuration of an inactive UE.

[0169] Proposal 3: RAN2 should clarify whether the MCCH provides PTM configuration for multicast sessions of inactive UEs, for example, when the PTM configuration is updated.

[0170] RAN2 leaves open the question of whether the MCCH configuration is initially provided to the UE via dedicated signaling. MCCH configuration means SIB20. As RAN2 agreed, dedicated signaling is inactive and provides PTM configuration for multicast reception, so the UE does not need to read the MCCH immediately, and does not need to know what SIB20, i.e., the MCCH configuration, is. Naturally, the UE will later acquire SIB20 and the MCCH to check whether the PTM configuration has been updated.

[0171] Proposal 4: RAN2 should agree that MCCH configuration (i.e., SIB20) does not need to be provided via dedicated signaling.

[0172] 2.2 UE Mobility and Service Continuity RAN2#120 agreed that MCCH will be used during UE transition. This disclosure has a mixed approach and starts as follows: 1. When the NW configures the UE to continue multicast reception in inactive state, the NW provides PTM configuration of activated multicast sessions via RRC dedicated signaling, at least for the serving cell (other cases require further study). 2. MCCH is used when PTM configuration needs to be changed or when PTM configuration needs to be indicated during transition across serving cells / gNBs. Session state changes and other indications require further study. 3. It is assumed that the UE can receive multicast services only after joining the session. 4. Whether MCCH configuration is initially provided to the UE via dedicated signaling requires further study.

[0173] WID states that seamless / lossless mobility is not required. Specify support for multicast reception by UEs in RRC inactive state [RAN2, RAN3]. PTM configuration for UEs receiving multicast in RRC inactive state [RAN2]. Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not required) [RAN2, RAN3].

[0174] As explained in Section 2.1, the distribution method for the new PTM configuration is similar to Rel-17 distribution mode 2. Therefore, it is natural to base the service continuity mechanism of Rel-17 MBS broadcast on it. In this case, the multicast session must first provide neighbor cell information from the MCCH to ensure that UEs are allowed to prioritize MBS frequencies during cell reselection.

[0175] As envisioned for LTE SC-PTM and NR MBS broadcast, it is up to the UE implementation how to ensure service continuity, e.g., how to use neighboring cell information, whether to prioritize MBS frequencies, how / when to acquire MCCH from neighboring cells, etc.

[0176] Proposal 5: RAN2 should agree that neighbor cell information for multicast sessions will be provided by MCCH, similar to MBS broadcast.

[0177] Proposal 6: RAN2 should agree that UEs are allowed to prioritize MBS multicast frequencies during cell reselection, similar to MBS broadcast.

[0178] Some companies have proposed enabling PTM settings in multiple cells to improve service continuity during UE transitions. While intra-gNB PTM settings can be easily aligned (if necessary) for each cell, inter-gNB PTM settings are difficult and require negotiation involving the Xn-AP. It seems harmless to limit this small enhancement to the intra-gNB case. Therefore, RAN2 needs to discuss whether PTM settings can be applied to multiple cells within a gNB.

[0179] Proposal 7: RAN2 should consider whether the PTM configuration can be applied to multiple cells within a gNB, in which case the intra-gNB scenario is the basic assumption.

[0180] Another consideration is QoS control by the network. Although WID states that seamless / lossless mobility is not required, this does not mean that all multicast sessions that a UE can receive inactively do not require seamless / lossless mobility. For example, the network may need to transition the UE to inactive due to congestion, but the UE may need to transition after connecting due to QoS requirements. For seamless / lossless mobility, Rel-17 MBS multicast supports handover in the RRC connection. Therefore, the network may need to have the option to control whether the UE performs cell reselection or resumes the RRC connection before cell reselection (in the case of handover in the connected state).

[0181] Proposal 8: RAN2 should discuss whether, for better QoS control, the gNB can indicate whether the UE is allowed to perform inactive mode mobility before cell reselection or whether the RRC connection should be resumed.

[0182] (6) Supplementary Note 1. Introduction The work items related to the enhancement of MBS (eMBS) are as follows: Identify support for multicast reception by UE in RRC inactive state [RAN2, RAN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] Study the impact of mobility and state transitions for UE receiving multicast in RRC inactive state (seamless / lossless mobility is not mandatory) [RAN2, RAN3]

[0183] Based on these agreements, notification and RRC state transition aspects for multicast reception in inactive mode are discussed in this appendix.

[0184] 2. Discussion In RAN2#119e, aspects related to RRC state changes remain for further study. In Rel-18, multicast reception for a UE in inactive will support at least the following scenarios, assuming the UE already has a valid PTM configuration: - Scenario 1: The UE is connected and receiving multicast, enters inactive and continues multicast reception. - Scenario 2: The UE joins a multicast session and is directed to inactive, the UE starts receiving the multicast session. Changes due to state changes, e.g. services not offered in inactive, require further study.

[0185] From the network and UE perspective, there are several possible cases related to RRC state changes, some of which are also related to notifications sent from the network to the UE. Therefore, the following cases are considered:

[0186] 2.1 Case 1: Multicast Session Inactivation / Release When a multicast session is inactivated, the UE is notified of the agreed-upon RAN2#119bis-e, and the Rel-17 mechanism is applicable when the multicast session is released. If the UE is in RRC inactive and configured to receive the multicast session in RRC inactive, the UE can be notified when the multicast session is inactivated. For example, notification via group paging, MCCH, or other methods requires further study. The Rel-17 mechanism (NAS-based indication) is applicable for multicast session release. Further study will be conducted as necessary.

[0187] If an inactive UE receives an MBS service and the gNB can stop transmitting PTM / MTCH accordingly, the multicast session is considered to be inactivated or released. In this case, there is no reason for the UE to continue monitoring the MTCH, but the UE shall do so unless the PTM configuration is removed. From the UE power saving point of view, it is desirable to stop monitoring the MTCH as soon as possible.

[0188] Observation 1: 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 stopped or released.

[0189] Therefore, the UE behavior upon multicast session inactivation is clarified, i.e. the UE should be allowed to stop the monitoring MTCH when it receives a notification for multicast session inactivation, regardless of how it is notified, and the UE should remain in RRC inactive upon receiving such a notification.

[0190] Proposal 1: RAN2 should agree that upon receiving the multicast session release notification, the UE is allowed to stop the monitor MTCH.

[0191] Regarding the termination of a multicast session, RAN2 considers the method of notifying UEs, such as group paging, MCCH, or other methods, as an issue that requires further study.

[0192] In LTE SC-PTM, the SC-PTM Stop Indication MAC CE is introduced to notify the UE that it will stop monitoring the PDCCH of the G-RNTI. The MAC CE is multiplexed onto the SC-MTCH associated with the G-RNTI. This lightweight signaling can function under the constraint of a one-to-one mapping between TMGI and G-RNTI. On the other hand, NR MBS allows many-to-one mapping between TMGI and G-RNTI, so when the MAC CE is introduced, it is necessary to indicate a deactivated TMGI. Since the MAC CE is transmitted along with the MTCH, it is expected to minimize the delay between receiving the last multicast data and stopping monitoring the MTCH.

[0193] Another option is to reuse group paging, which is used to simultaneously page multiple UEs in a group using TMGI instead of UE-ID. Since the existing paging group list (i.e., the list of TMGI) is applicable to legacy UEs as well, a new TMGI list needs to be added for group paging to avoid impacting legacy UEs. This means that there is a delay between receiving the last multicast data and stopping MTCH monitoring based on the I-DRX period.

[0194] The third option is to reuse the MCCH. There are two possibilities for notifying the deactivation of a multicast session: either remove the PTM configuration of the deactivated TMGI or add a new indication to notify the deactivated TMGI. In either case, the MCCH needs to be updated, so an MCCH change notification needs to be sent to the UE in advance. This requires a longer delay between the reception of the last multicast data and the stopping of MTCH monitoring.

[0195] According to the RAN2 agreement that "MCCH is used when the PTM setting needs to be changed," inactive UEs need to wake up at the timing of MCCH, and deactivation of a multicast session can be interpreted as a kind of "change of PTM setting." Therefore, if the corresponding PTM setting is deleted from MCCH, the UE can notice that the multicast session has been deactivated. However, it takes time for the UE to stop monitoring the MTCH. Therefore, notification by MAC CE is preferable.

[0196] In summary, the delay between receiving the last multicast data and stopping MTCH monitoring can directly impact unnecessary UE power consumption increase. From the UE power saving point of view, the notification needs to be sent as soon as possible, so the first option using MAC CE is the preferred solution.

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

[0198] For multicast session release, the Rel-17 NAS-based indication agreed by RAN2 applies, which may be "multicast session release requested by network or MBS session release." This procedure assumes that the UE is paged by the gNB and transitions to RRC Connected to communicate with the AMF. This procedure can reuse existing group paging (or conventional individual paging).

[0199] However, for optimization purposes, if a new MAC CE is introduced for multicast session invalidation notification as in Proposal 2, this procedure can be freely used: the gNB sends a MAC CE to allow the UE to stop monitoring the MTCH, and then the gNB can distribute the timing of pages to the UE, i.e., use legacy dedicated paging, to avoid signaling storms caused by simultaneous RRC state transitions.

[0200] Proposal 3: RAN2 should agree that no enhancements specific to multicast session release are required, i.e. UEs will transition to RRC Connected via existing (group) paging.

[0201] 2.2. Case 2: Selective Transition When a Multicast Session is Active RAN2#119e reached the following agreement regarding Case 2: It is the gNB that decides whether a UE can receive a multicast session inactively. Further study is required on what information to provide to the gNB to make such a decision (related to the discussion of SA2). It is supported that a gNB can send one multicast session to both connected and inactive UEs in the same cell. How the gNB configures this requires 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 transition UEs between states for multicast service reception.

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

[0203] Observation 2: Existing RRC release is used by the gNB to select which UEs to release.

[0204] Regarding multicast session activation, RAN2#119bis-e agreed on the following: When a Rel-18 session becomes active, inactive UEs can be notified (details need further study). As a baseline, group paging can be used to notify Rel-18 UEs of session activation (details, e.g., UE behavior upon receiving such a group notification, need further study). How to determine whether a UE can receive a multicast session in RRC inactive when a session is activated will be determined through further study, taking into account the following solutions (the description can be further updated as needed, and multiple solutions may be required): 1. When a multicast session is activated, the UE can receive the multicast session in RRC inactive if the PTM configuration used in RRC inactive for the session is available to the UE and the UE is already joined to the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), otherwise it will return to RRC connected to receive the multicast session. 2. When a multicast session becomes active, the UE is indicated by group paging whether it can receive the multicast session in RRC inactive (detailed signaling needs further study). 3. The UE is configured by dedicated signaling whether it can receive the multicast session in RRC inactive before the UE is released. When a multicast session becomes active, the UE stays in RRC inactive or resumes RRC connected accordingly (detailed signaling needs further study).

[0205] In Rel-17, multicast session activation is signaled by group paging. In Rel-18, there is no need to differ from the legacy mechanism, so RAN2 needs to make sure that UEs are informed of multicast session activation using group paging.

[0206] Proposal 4: RAN2 should ensure that group paging can be used to notify Rel-18 UEs of session activation.

[0207] In addition to the confirmation, RAN2, as mentioned above, has defined three options for UE behavior upon receiving a multicast activation notification.

[0208] In the case of option 1, a UE can receive a multicast session even in an inactive state if it has a valid PTM configuration. Since an inactive UE cannot receive a multicast session without a PTM configuration, this is considered the baseline for the behavior of all other UEs. Therefore, option 1 should be agreed upon.

[0209] Proposal 5: RAN2 shall ensure that when a UE's behavior option 1 multicast session is activated, the UE can receive the multicast session in RRC inactive if the PTM configuration used in RRC inactive for the session is available to the UE and the UE is already participating in the session (e.g., a configuration provided to the UE via dedicated RRC signaling or MCCH).

[0210] In option 2, the UE is informed whether to receive the multicast session inactively when it receives the group paging.

[0211] In option 3, the UE is informed in advance by RRC reconfiguration or RRC release whether it should receive the multicast session inactively.

[0212] The mechanisms for these two options are very similar, except for the messages that instruct the UE to do so, so these options can be analyzed from the perspective of motivations for inactive multicast reception: network congestion and UE power saving.

[0213] In the case of network congestion, it can be assumed that the cell load changes from time to time. In option 2, an instruction is sent within the group paging, so the gNB can take the latest load status into account when deciding whether the UE should remain inactive. On the other hand, in option 3, the gNB needs to predict future load when notifying the UE, and the cell load may have changed by the time the gNB actually sends the group paging. Therefore, there is a risk that congestion will worsen and an increase in UEs will transition to connected, or that an increase in UEs will remain inactive even after congestion is resolved. Therefore, option 2 is preferable for efficiently controlling the UE's RRC state.

[0214] From the perspective of UE power saving, it is assumed that some kind of "power saving preference" is introduced into the UE assistance information. Such a preference indication can only be sent from a connected UE. Thus, the gNB can indicate to the UE whether the UE was "inactive" and allowed to receive the multicast session when the UE was previously "connected". If such a preference indication is not introduced, the gNB does not know whether the UE prefers power saving or not, and can therefore indicate it to the UE at any time. Therefore, there is no difference between option 2 and option 3.

[0215] Based on the above analysis, it is believed that Option 2 is more efficient and can cover the usage of Option 3. Therefore, RAN2 should at least agree to Option 2.

[0216] Proposal 6: RAN2 should agree to UE behavior option 2: "When a multicast session becomes active, the UE is indicated by group paging whether it can receive the multicast session in RRC inactive (detailed signaling needs further study)."

[0217] Regarding group paging in option 2, the current specification specifies the behavior of UEs when receiving a group paging. If the paging message contains an interesting TMGI, all UEs initiate the RRC resume procedure. Therefore, if selective paging is required in option 2, the gNB cannot include the TMGI in the paging message. If the gNB includes only the UE-ID for selective paging (i.e., legacy dedicated paging without TMGI for paging selected Rel-18 UEs), it cannot page inactive Rel-17 UEs waiting for multicast activation. Furthermore, this is inefficient in terms of signaling overhead.

[0218] Observation 3: That is, if the paging message contains a TMGI of interest, all UEs transition to RRC Connected.

[0219] Assuming that the current paging group list is set in the group paging message to page at least Rel-17 UEs, Rel-18 UEs will also be paged according to the TMGI of interest. Therefore, to prevent selected UEs from transitioning to Connected, it is conceivable to define a new list of UE-IDs, the "Paging Cancellation List" (or "Inactive Allowed List"), so that the UEs listed in this list will remain inactive to receive the multicast session.

[0220] Therefore, RAN2 should discuss how to enhance group paging to page a subset of UEs.

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

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

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

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

[0225] In RAN2#119e, it is proposed to introduce thresholds for reception quality, 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 should transition to Connected and use HARQ feedback / retransmission and / or PTP (or split MRB) to guarantee reception quality.

[0226] Observation 4: A multicast session should ensure certain QoS requirements even when the UE is inactive.

[0227] Regarding the RSRP threshold, since NR MBS is assumed to be a single-cell transmission scheme, it is considered that the UE needs to transition to connected mode every time it moves to the cell edge or performs cell reselection, which may not be optimal in some deployments due to network congestion and UE power saving considerations.

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

[0229] Proposal 8: RAN2 should agree that a UE in inactive state should transition to connected if the reception quality becomes worse than a threshold (e.g., RSRP or BLER).

[0230] 2.4. Case 4: PTM Configuration Update RAN2 has agreed on the following as a working premise. This disclosure has a mixed approach and starts as follows: 1. If the NW configures the UE to continue multicast reception in inactive state, the NW provides PTM configuration of activated multicast sessions via RRC dedicated signaling, at least to the serving cell (other cases require further study). 2. MCCH is used when PTM configuration needs to be changed or when PTM configuration needs to be indicated during transition across serving cells / gNBs. Session status changes and other indications require further study. 3. It is assumed that the UE can receive multicast services only after joining the session. 4. Whether MCCH configuration is initially provided to the UE by dedicated signaling requires further study.

[0231] That is, the UE can remain in the inactive state to obtain the updated PTM configuration. Therefore, from the perspective of the inactive UE, the distribution method of the new PTM configuration is similar to distribution mode 2 in Rel-17. In this case, it is very easy to reuse the existing MCCH change notification to notify the PTM configuration update. Therefore, no additional notification is required for the PTM configuration update of the inactive UE.

[0232] Proposal 9: RAN2 should agree that the existing MCCH change notification will be used to update the PTM configuration.

[0233] 2.5. Case 5: Service Continuity Upon RRC Resumption A UE already receiving an inactive multicast session (e.g., via a broadcast MRB) may be paged and initiate an RRC resume procedure. After transitioning to Connected, the UE would of course like to continue receiving the multicast session. However, in this case, the UE has both a broadcast MRB and a resumed multicast MRB for the same multicast session. In Rel-17, multicast sessions are only allowed to be received via the multicast MRB configured in RRC reconfiguration. On the other hand, in Rel-18, multicast sessions may be allowed to be received via the broadcast MRB configured on the MCCH. The UE should use the multicast MRB for reception after transitioning to Connected. However, it is unclear (i.e., in terms of the lossless principle) how the UE switches between these MRBs, when the UE discards the broadcast MRB, and what the UE should do if the multicast MRB is an AM MRB. Therefore, RAN2 needs to discuss UE behavior upon RRC resumption in terms of MRB handling and service continuity of multicast sessions.

[0234] Proposal 10: RAN2 should discuss UE behavior upon RRC resumption during continuous reception of a multicast session (such as handling of broadcast MRBs and multicast MRBs).

[0235] 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 for use in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, by a user equipment in a Radio Resource Control (RRC) Connected state, an RRC Release message from a network node on a Dedicated Control Channel (DCCH), the RRC Release message including a Point-to-Multipoint (PTM) configuration for receiving a multicast session in an RRC Inactive state; The user equipment transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC release message; the user equipment in the RRC inactive state receiving the multicast session; The user equipment receives the RRC release message including the PTM configuration, which includes the same information elements as those provided on a multicast control channel (MCCH). Communication method.

2. The PTM configuration includes an MBS session information list that provides configuration for each MBS session provided by multicast. The communication method according to claim 1 .

3. The PTM configuration includes a list of neighboring cells that provide MBS multicast services. The communication method according to claim 1 .

4. The PTM settings include a list of DRX settings. The communication method according to claim 1 .

5. The PTM configuration includes parameters for acquiring a PDSCH for an MTCH. The communication method according to claim 1 .

6. The PTM setting is a setting for a multicast session that the user equipment is receiving in the RRC connected state. The communication method according to claim 1 .

7. The user device continues receiving the multicast session in the RRC inactive state based on the PTM setting. The communication method according to claim 6.

8. The user equipment receives the RRC release message from the network node when the multicast session is in an inactive state. The communication method according to claim 1 .

9. The user equipment monitors the MCCH based on receipt of the RRC release message including the PTM configuration. The communication method according to claim 1 .

10. A user device for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a receiver configured to receive an RRC release message from a network node on a dedicated control channel (DCCH) when the user equipment is in a radio resource control (RRC) connected state, the RRC release message including a point-to-multipoint (PTM) configuration for receiving a multicast session in an RRC inactive state; a control unit configured to transition from the RRC connected state to the RRC inactive state in response to receiving the RRC release message, The receiver receives the multicast session when the user equipment is in the RRC inactive state, The receiver receives the RRC release message including the PTM configuration, which includes the same information element as the information element provided on a multicast control channel (MCCH). User equipment.

11. A method for causing a user device to execute the communication method according to claim 1. Processor.

12. A method for causing a user device to execute the communication method according to claim 1. program.

13. A user device comprising the user equipment of claim 10 and a network node. Mobile communication system.