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

Abstract

This communication method for use in a mobile communication system providing a multicast / broadcast service (MBS) comprises a step for receiving, by a user device from a network, a multicast control channel (MCCH) including a plurality of MBS settings of the plurality of MBS sessions. The plurality of MBS settings include a broadcast setting for a broadcast session and a multicast setting for a multicast session.

Description

Communication Method

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

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

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

[0004] A communication method according to a first aspect is a communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising the step of receiving, by a user equipment, a multicast control channel (MCCH) from a network, the MCCH including a plurality of MBS configurations for a plurality of MBS sessions, the plurality of MBS configurations including a broadcast configuration for a broadcast session and a multicast configuration for a multicast session.

[0005] 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), the method comprising the steps of: a user equipment (UE) in a radio resource control (RRC) connected state receiving a multicast session from a network; and receiving, by the user equipment, an RRC release message from the network for transitioning the user equipment to an RRC inactive state, the release RRC message including an MBS configuration provided by the network on a multicast control channel (MCCH).

[0006] A communication method according to a third aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state receiving a multicast session from a network; the user equipment receiving a multicast control channel (MCCH) reception instruction from the network; the user equipment receiving the MCCH and attempting to receive the multicast session in response to the reception instruction; and the user equipment transmitting information indicating whether the multicast session was successfully or unsuccessfully received to the network.

[0007] A communication method according to a fourth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state receiving the multicast session from a network using an MBS setting for the multicast session; the user equipment transitioning to an RRC inactive state; the user equipment in the RRC inactive state attempting to receive a multicast control channel (MCCH); and the user equipment in the RRC inactive state continuing to receive the multicast session using the MBS setting until it receives the MCCH.

[0008] A communication method according to a fifth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using a first MBS configuration provided on a multicast control channel (MCCH); the user equipment transitioning to an RRC connected state; the user equipment in the RRC connected state receiving an RRC reconfiguration message from the network, the RRC reconfiguration message including a second MBS configuration; and the user equipment in the RRC connected state discarding the first MBS configuration in response to receiving the RRC reconfiguration message.

[0009] A communication method according to a sixth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting provided on a multicast control channel (MCCH); the user equipment transitioning to an RRC idle state; and the user equipment discarding the MBS setting in response to the transition to the RRC idle state.

[0010] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment. FIG. 3 is a diagram showing a configuration of a gNB (base station) according to an embodiment. FIG. 4 is a diagram showing a protocol stack configuration of a radio interface of a user plane that handles data. FIG. 5 is a diagram showing a protocol stack configuration of a radio interface of a control plane that handles signaling (control signals). FIG. 6 is a diagram for explaining MRB configuration (MRB-ToAddMod) specified in the RRC technical specification (TS38.331). FIG. 7 is a diagram showing an overview of operations according to an embodiment. FIG. 8 is a diagram showing an MBS broadcast configuration (MBSBroadcastConfiguration) message in an MCCH specified in the RRC technical specification (TS38.331). FIG. 9 is a diagram showing operation pattern 1 according to an embodiment. FIG. 10 is a diagram showing operation pattern 2 according to an embodiment. FIG. 11 is a diagram showing operation pattern 3 according to an embodiment. FIG. 12 is a diagram showing operation pattern 4 according to an embodiment. FIG. 13 is a diagram showing operation pattern 5 according to an embodiment. FIG. 14 is a diagram for explaining operation pattern 6 according to an embodiment.

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

[0012] (1) Configuration of a Mobile Communication System FIG. 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). While the following description uses 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.

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

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

[0015] The NG-RAN 10 includes a base station (called a "gNB" in a 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, and the like. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource for wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

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

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

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

[0019] The receiving unit 110 performs various reception operations under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

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

[0021] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. 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 processes 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.

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

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

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

[0025] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. 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 processes 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0039] 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, RRC inactive state, and RRC connected state. Such a delivery mode is sometimes referred to as Delivery Mode 1.

[0040] In the case of a multicast communication service (also referred to as "MBS multicast"), the same service and the same specific content data are simultaneously provided to a specific set of UEs. That is, not all UEs 100 within a multicast service area are permitted to receive the data. The multicast communication service is delivered to the UEs 100 using a multicast session, which is a type of MBS session. The UEs 100 can receive the multicast communication service in an RRC connected state using mechanisms such as Point-to-Point (PTP) and / or Point-to-Multipoint (PTM) delivery. The UEs 100 may also receive the multicast communication service in an RRC inactive (or RRC idle) state. Such a delivery mode is sometimes referred to as Delivery Mode 2.

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

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

[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 MBS configuration for the multicast session to UE 100. Such MBS configuration is also referred to as multicast radio bearer (MRB) configuration, MTCH configuration, or multicast configuration. Figure 6 is a diagram for explaining MRB configuration (MRB-ToAddMod) specified in the RRC technical specification (TS38.331). The MRB setting (MRB-ToAddMod) includes other parameters such as an MBS session ID (mbs-SessionId), an MRB ID (mrb-Identity), and a PDCP setting (pdcp-Config) for the MRB (multicast MRB) to be set 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 solutions 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) are possible.

[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 for the multicast session to UE100 in the RRC connected state. UE100 receives multicast data of the multicast MRB (multicast session) on the MTCH based on the RRC reconfiguration message.

[0047] In step S2, the gNB 200 transmits an RRC release (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 receiving the RRC release message in step S2, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0049] In step S4, the UE 100 in the RRC inactive state continues to use the MBS setting in step S1 and receives multicast data of the multicast MRB (multicast session) on the MTCH.

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

[0051] 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 (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.

[0052] In step S12, in response to receiving the RRC release message in step S11, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0053] In step S13, the gNB 200 transmits an MCCH including an MBS setting for the multicast session. The UE 100 receives the MCCH.

[0054] In step S14, the UE 100 in the RRC inactive state receives multicast data of the multicast MRB (multicast session) on the MTCH based on the MCCH (MBS setting) in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0055] In each operation pattern of the following embodiment, an improvement of the distribution mode 2 based solution as described above is described.

[0056] (3) Operation Pattern 1: Figure 8 shows 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 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). Thus, in the current 3GPP technical specification, the MCCH provides broadcast configuration for broadcast sessions but does not provide multicast configuration for multicast sessions. This operation pattern assumes that the MCCH is used to provide multicast configuration.

[0057] Multicast communication should only be received by a specific set of UEs participating in the multicast session. However, since the MCCH can be received by all UEs 100, when the network 10 (gNB 200) transmits the multicast setting on the MCCH, all UEs 100 can acquire the multicast setting in the MCCH. In this operation pattern, by explicitly distinguishing between multicast setting and broadcast setting on the MCCH, only a specific set of UEs participating in the multicast session can acquire and apply the multicast setting.

[0058] In this operation pattern, the UE 100 has a step of receiving an MCCH including multiple MBS settings for multiple MBS sessions from the network 10 (gNB 200). The multiple MBS settings include a broadcast setting for a broadcast session and a multicast setting for a multicast session. Here, in the MCCH, information indicating whether or not each MBS setting is a multicast setting may be assigned. This makes it possible to explicitly distinguish between multicast settings and broadcast settings in the MCCH.

[0059] The UE 100 acquires and applies the multicast configuration in the MCCH in accordance with its participation in the multicast session, i.e., only the UE 100 participating in the multicast session acquires and applies the corresponding multicast configuration in the MCCH.

[0060] The UE 100 may acquire and apply the multicast configuration in response to its own RRC state being an RRC inactive state. That is, only the UE 100 in the RRC inactive state acquires and applies the multicast configuration in the MCCH.

[0061] 9 is a diagram showing operation pattern 1 according to the embodiment. In the description of this operation pattern and the operation patterns described later, overlapping explanations of operations overlapping with those in FIG. 7, particularly FIG. 7(b), will be omitted. In addition, in this operation pattern and the operation patterns described later, it may be assumed that the UE 100 participating in the multicast session has received an MBS setting (multicast setting) related to the multicast session from the network 10 (gNB 200), for example, in an RRC reconfiguration message. In addition, in this operation pattern and the operation patterns described later, it may be assumed that the UE 100 receives SIB 20 prior to receiving the MCCH.

[0062] In step S101, the gNB 200 transmits an MCCH. The UE 100 receives the MCCH. The MCCH includes broadcast session setting information as well as multicast session setting information. The MCCH also includes information for distinguishing between broadcast setting and multicast setting.

[0063] For example, for each entry of the MBS session information list (mbs-SessionInfoList), information indicating that the setting is multicast setting may be included. If the information does not exist, the UE 100 may determine that the corresponding setting is broadcast setting. Alternatively, in the MCCH, an MBS session information list (MBS-SessionInfoList-Multicast-Inactive) for multicast sessions (and for RRC inactive state) may be provided separately from the MBS session information list (mbs-SessionInfoList) for broadcast sessions. Alternatively, in the MCCH, an MBS multicast setting (MBS Multicast Configuration) may be provided separately from the MBS broadcast setting (MBSBroadcastConfiguration). Alternatively, an MBSMulticastConfiguration message may be defined separately from the MBSBroadcastConfiguration message. A new logical channel such as MCCH-multicast may be defined. Such a new message or logical channel may be transmitted on an occasion different from the conventional MCCH occasion.

[0064] In step S102, the UE 100 that has received the MCCH distinguishes between broadcast setting and multicast setting in the MCCH. The UE 100 may apply the broadcast setting as in the conventional case.

[0065] In step S103, UE 100 determines whether the multicast setting in the MCCH is applicable. For example, UE 100 may determine that the multicast setting is applicable when a first condition that UE 100 has joined a corresponding multicast session and a second condition that UE 100's RRC state is an RRC inactive state are satisfied. UE 100 may be prohibited from acquiring and applying the multicast setting if these conditions are not satisfied. That is, if UE 100 is not participating in a multicast session, acquisition and application of the corresponding multicast setting in the MCCH is prohibited. Furthermore, if UE 100's own RRC state is an RRC idle state or an RRC connected state, acquisition and application of the multicast setting in the MCCH is prohibited. Note that UE 100 may discard the multicast setting whose application is prohibited.

[0066] In step S103, the UE 100 applies the multicast setting determined to be applicable in step S102.

[0067] In step S104, the UE 100 starts receiving the multicast session based on the multicast configuration applied in step S103.

[0068] (4) Operation Pattern 2 Operation Pattern 2 according to the embodiment will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations.

[0069] In this operation pattern, the UE 100 participating in the multicast session first receives a multicast setting for the multicast session from the network 10 (gNB 200) in an RRC connected state via an RRC reconfiguration message. Next, the UE 100 receives an MBS setting (multicast setting) for the multicast session via the MCCH. In this manner, in this operation pattern, switching from distribution mode 1 to distribution mode 2 supports continued multicast reception in the RRC inactive state.

[0070] Under such assumptions, when the UE 100 receives the MCCH (and SIB 20) after transitioning to the RRC inactive state, there is a problem that it takes time to resume multicast reception. In this operation pattern, by providing information in the MCCH (multicast setting) in an RRC release message for transitioning the UE 100 to the RRC inactive state, it is possible to suppress interruption of multicast reception.

[0071] That is, in this operation pattern, the UE 100 receives an RRC release message from the network 10 (gNB 200) for transitioning itself to an RRC inactive state. The release RRC message includes an MBS setting (multicast setting) provided by the network 10 (gNB 200) on the MCCH.

[0072] FIG. 10 is a diagram showing operation pattern 2 according to the embodiment.

[0073] In step S201, the UE 100 in the RRC connected state performs multicast reception.

[0074] In step S202, gNB200 determines to transition UE100 to the RRC inactive state and transmits an RRC release message to UE100. UE100 receives the RRC release message. The RRC release message may include mbsBroadcastConfiguration shown in FIG. 8. Specifically, the RRC release message includes MBS-SessionInfo (MTCH scheduling information). gNB200 may include only MCCH information related to the multicast session being received by UE100 in the RRC release message. The gNB 200 may include, as associated information, drx-ConfigPTM-List (MTCH DRX setting list), pdsch-ConfigMTCH (MTCH PDSCH setting), and mtch-SSB-MappingWindowList (MTCH and SSB mapping setting list) in the RRC release message. The gNB 200 may include SIB20 for receiving the MCCH in the RRC release message.

[0075] In step S203, in response to receiving the RRC release message in step S202, the UE 100 transitions to an RRC inactive state.

[0076] In step S204, the UE 100 in the RRC inactive state applies the multicast setting corresponding to the multicast session currently being received from the information received in step S202, and starts receiving the multicast session.

[0077] (5) Operation Pattern 3 Operation Pattern 3 according to the embodiment will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations.

[0078] A UE 100 performing multicast reception in the RRC connected state can perform multicast reception using the multicast settings provided in the RRC reconfiguration message, and therefore does not need to receive the MCCH. Here, if it is not expected that MCCH information will be provided by dedicated signaling, as in the second operation pattern described above, it is preferable for the gNB 200 to explicitly instruct the UE 100 to receive the MCCH. In addition, it is desirable for the gNB 200 to transition the UE 100 to the RRC inactive state after confirming that the UE 100 has started multicast reception in distribution mode 2. Therefore, feedback is provided from the UE 100 to the gNB 200.

[0079] In this operation pattern, UE 100, which receives a multicast session from network 10 (gNB 200) in an RRC connected state, receives an MCCH reception instruction from network 10 (gNB 200). UE 100 receives the MCCH in response to the reception instruction and attempts to receive the multicast session. Then, UE 100 transmits information indicating the multicast session that UE 100 successfully or unsuccessfully received to network 10 (gNB 200).

[0080] FIG. 11 is a diagram showing operation pattern 3 according to the embodiment.

[0081] In step S301, the UE 100 in the RRC connected state performs multicast reception.

[0082] In step S302, when the gNB 200 decides to transition the UE 100 in the RRC connected state during multicast reception to the RRC inactive state, the gNB 200 adds related configuration information to the MCCH for the multicast session being received by the UE 100. However, the gNB 200 may add configuration information for all currently provided multicast sessions to the MCCH.

[0083] In step S303, gNB200 instructs UE100 to receive the MCCH. The instruction may be an instruction to receive a multicast session in distribution mode 2. The instruction may be an instruction to receive an MTCH (set in the MCCH) corresponding to the MCCH. The instruction may be an instruction to receive SIB20. The instruction may include a multicast session ID (TMGI, MRB ID) to be received in distribution mode 2. gNB200 may not schedule unicast communication in slots corresponding to SIB20 / MCCH / MTCH.

[0084] In step S304, in response to receiving the instruction in step S303, UE100 performs the following processing for the multicast session being received: - May receive SIB20 (may apply the settings of SIB20) - May receive MCCH (may apply the settings of MCCH) - May start receiving MTCH.

[0085] In step S305, UE100 notifies gNB200 that it has started receiving the multicast session in distribution mode 2.

[0086] The UE 100 may transmit the notification when triggered by the successful reception of the MCCH, the application of the MCCH setting contents, or the start of reception of the MTCH. The UE 100 may transmit the notification in a UE assistance information (Assistance Information) message. The UE assistance information message may include an information element (Preferred RRC state = inactive) indicating that the RRC state desired by the UE 100 is the RRC inactive state. The UE 100 may transmit the notification in an MBS interest indication (Interest Indication) message. The UE 100 may transmit the notification in a response message to the instruction of step S303. The notification may include information indicating that reception of the multicast session has started (for example, information indicating that the MCCH has been received or that reception of the MTCH has started). The notification may include the multicast session ID (TMGI, MRB ID, etc.) from which reception has started.

[0087] Alternatively, in step S305, UE100 may notify gNB200 that it was unable to start receiving the multicast session (for example, that it was unable to receive the MCCH or the MTCH). UE100 may make this notification if it was unable to start receiving the multicast session within a certain period of time after receiving the instruction in step S303. This certain period may be set by gNB200 or may be a value predefined in the technical specifications. UE100 may include in this notification the multicast session ID (TMGI, MRB ID, etc.) for which it was unable to start receiving. gNB200 suspends (stops) the transition to the RRC inactive state for UE100 that is unable to start multicast reception, or sets the MCCH in an RRC release message (see operation pattern 2 described above).

[0088] In step S306, gNB200 confirms that UE100 has started receiving the multicast session, and then sends an RRC release message to UE100.

[0089] In step S307, in response to the reception of the RRC release message, the UE 100 transitions to an RRC inactive state. Then, the UE 100 in the RRC inactive state performs multicast reception using the multicast setting received on the MCCH.

[0090] (6) Operation Pattern 4 Operation Pattern 4 according to the embodiment will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations.

[0091] In this operation pattern, the UE 100 in the RRC connected state receives a multicast session from the network 10 (gNB 200) using the MBS setting of the multicast session (multicast setting for the RRC connected state). The UE 100 transitions to the RRC inactive state and attempts to receive the MCCH. The UE 100 continues to receive the multicast session using the MBS setting (multicast setting for the RRC connected state) until it receives the MCCH. This prevents service interruptions in multicast reception.

[0092] FIG. 12 is a diagram showing operation pattern 4 according to the embodiment.

[0093] In step S401, the UE 100 in the RRC connected state performs multicast reception.

[0094] In step S402, gNB200 may notify UE100 that after transitioning to the RRC inactive state, it may continue to apply the multicast settings in the RRC connected state until MCCH reception is completed.

[0095] In step S403, gNB200 sends an RRC release message to UE100.

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

[0097] In step S405, the UE 100 in the RRC inactive state continues to apply the multicast configuration received in the RRC connected state. As a result, the UE 100 performs multicast reception (step S406).

[0098] In step S407, the UE 100 in the RRC inactive state attempts to acquire the MCCH. If the UE 100 has successfully received the MCCH or if the MCCH setting has been applied, the UE 100 performs multicast reception using the multicast setting of the MCCH (step S408). In this case, the UE 100 may discard the multicast setting that was received in the RRC connected state.

[0099] (7) Operation Pattern 5 Operation Pattern 5 according to the embodiment will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations.

[0100] In this operation pattern, switching from distribution mode 2 to distribution mode 1 will be described. Multicast reception in the RRC inactive state may be necessary when the gNB 200 is unable to maintain the UE 100 in the RRC connected state due to network congestion. Therefore, multicast reception in the RRC inactive state is considered to be temporary. After the network congestion is resolved, the gNB 200 may return all UEs 100 performing multicast reception in the RRC inactive state to the RRC connected state and allow them to receive multicast. Therefore, it is desirable to suppress service interruptions even when switching from distribution mode 2 to distribution mode 1.

[0101] In this operation pattern, UE 100 in the RRC inactive state receives a multicast session from network 10 (gNB 200) using the first MBS setting (first multicast setting) provided by the MCCH. When UE 100 transitions to the RRC connected state, it receives an RRC reconfiguration message including a second MBS setting (second multicast setting) from network 10 (gNB 200). UE 100 in the RRC connected state discards the first MBS setting (first multicast setting) in response to transition to the RRC connected state or receiving an RRC reconfiguration message.

[0102] For example, when the UE 100 receives the multicast setting (distribution mode 1) in the RRC reconfiguration message, the UE 100 discards the multicast setting (distribution mode 2) set in the MCCH. When the UE 100 starts (has started) receiving the MTCH by the multicast setting of the RRC reconfiguration message, the UE 100 may stop receiving the MTCH by the multicast setting of the MCCH.

[0103] FIG. 13 is a diagram showing operation pattern 5 according to the embodiment.

[0104] In step S502, the UE 100 in the RRC inactive state receives an MCCH including multicast configuration from the gNB 200. The MCCH may be provided in an RRC release message.

[0105] In step S503, the UE 100 in the RRC inactive state performs multicast reception using the multicast setting in step S502.

[0106] In step S504, UE100 transitions to the RRC connected state. For example, UE100 may transmit an RRC resume request message to gNB200 upon receiving a call from gNB200 via RAN paging. UE100 may stop multicast reception in step S503 when transitioning to the RRC connected state. For example, UE100 may stop the reception process of MCCH. UE100 may discard the contents (multicast settings) set in MCCH. UE100 may stop the reception process of MTCH (multicast session) set in MCCH.

[0107] In step S505, gNB200 transmits an RRC reconfiguration message including multicast configuration to UE100. UE100 receives the RRC reconfiguration message.

[0108] In step S506, in response to receiving the multicast setting in step S505, UE 100 may stop the multicast reception in step S503. For example, UE 100 may stop the reception process of the MCCH. UE 100 may discard the content (multicast setting) set in the MCCH. UE 100 may stop the reception process of the MTCH (multicast session) set in the MCCH.

[0109] In step S507, the UE 100 in the RRC connected state performs multicast reception using the multicast setting in step S505.

[0110] (8) Operation Pattern 6 Operation pattern 6 according to the embodiment will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations. This operation pattern focuses on cell reselection performed after the UE 100 transitions to the RRC inactive state.

[0111] 14 is a diagram for explaining operation pattern 6 according to the embodiment. In the illustrated example, cell a is managed by gNB200a, and cell b is managed by gNB200b. UE100 in the RRC inactive state performs multicast reception in cell a (gNB200a) in the RRC inactive state using the multicast setting in the MCCH received in cell a (gNB200a). When UE100 leaves cell a and moves out of range, UE100 transitions from the RRC inactive state to the RRC idle state. Under such an assumption, UE100 may discard the multicast setting in response to transition from the RRC inactive state to the RRC idle state.

[0112] In this way, the UE 100 in the RRC inactive state receives a multicast session from the network 10 (gNB 200) using the MBS setting (multicast setting) provided by the MCCH. The UE 100 discards the MBS setting (multicast setting) in response to transition to the RRC idle state.

[0113] FIG. 15 is a diagram showing operation pattern 6 according to the embodiment.

[0114] In step S601, the UE 100 in an RRC inactive state performs multicast reception using a multicast setting provided by an MCCH. The MCCH may be provided in an RRC release message.

[0115] In step S602, the UE 100 in the RRC inactive state transitions to the RRC idle state. For example, the UE 100 transitions to the RRC idle state when the UE 100 moves out of the service area.

[0116] In step S603, in response to transition to the RRC idle state, the UE 100 discards the applied multicast setting and stops multicast reception (MTCH reception).

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

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

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

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

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

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

[0123] This application claims priority to U.S. Provisional Application No. 63 / 396,354 (filed August 9, 2022), the entire contents of which are incorporated herein by reference.

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

[0125] (Supplementary Note 1) A communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a user equipment receiving a multicast control channel (MCCH) from a network, the MCCH including a plurality of MBS configurations for a plurality of MBS sessions, the plurality of MBS configurations including a broadcast configuration for a broadcast session and a multicast configuration for a multicast session.

[0126] (Supplementary Note 2) The communication method according to Supplementary Note 1, further comprising the user equipment obtaining and applying the multicast configuration in the MCCH in response to the user equipment participating in the multicast session.

[0127] (Supplementary Note 3) The communication method according to Supplementary Note 1 or 2, further comprising the user equipment acquiring and applying the multicast configuration in response to an RRC state of the user equipment being an RRC inactive state.

[0128] (Supplementary Note 4) A communication method used in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) connected state receiving a multicast session from a network; and the user equipment receiving an RRC release message from the network for transitioning the user equipment to an RRC inactive state, wherein the release RRC message includes an MBS configuration provided by the network on a multicast control channel (MCCH).

[0129] (Supplementary Note 5) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) connected state receiving a multicast session from a network; the user equipment receiving a reception instruction for a multicast control channel (MCCH) from the network; the user equipment receiving the MCCH in response to the reception instruction and attempting to receive the multicast session; and the user equipment transmitting information indicating the multicast session that was successfully or unsuccessfully received to the network.

[0130] (Supplementary Note 6) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) connected state receiving the multicast session from a network using an MBS setting for the multicast session; the user equipment transitioning to an RRC inactive state; the user equipment in the RRC inactive state attempting to receive a multicast control channel (MCCH); and the user equipment in the RRC inactive state continuing to receive the multicast session using the MBS setting until it receives the MCCH.

[0131] (Supplementary Note 7) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using a first MBS configuration provided on a multicast control channel (MCCH); the user equipment transitioning to an RRC connected state; the user equipment in the RRC connected state receiving an RRC reconfiguration message from the network that includes a second MBS configuration; and the user equipment in the RRC connected state discarding the first MBS configuration in response to transitioning to the RRC connected state or receiving the RRC reconfiguration message.

[0132] (Supplementary Note 8) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS configuration provided on a multicast control channel (MCCH); the user equipment transitioning to an RRC idle state; and the user equipment discarding the MBS configuration in response to the transition to the RRC idle state.

[0133] (11) Second Supplement

[0134] Introduction In RAN#94e, a new work item on Enhanced MBS (eMBS) was approved with a revised WID in RAN#96. One of the objectives of Rel-18 is to enable UEs in RRC inactive state to receive multicast sessions.

[0135] - Specify support for multicast reception by UEs in RRC inactive state. - Configure PTM for UEs receiving multicast in RRC inactive state. - Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive (seamless / lossless mobility is not mandatory).

[0136] In this appendix, we provide an initial consideration of support for multicast reception in RRC inactive, taking into account the relevant discussions that took place in Rel-17.

[0137] Discussion Discussions in Rel-17 and solution direction in Rel-18 Multicast reception in RRC inactive was briefly discussed in Rel-17, but RAN2 decided to prioritize multicast reception only in RRC connected as follows: Although RAN2 did not specify this feature in Rel-17, there are already some candidate solutions, which still provide a good starting point for discussions in Rel-18.

[0138] Chair: RAN2 will prioritize RRC Connected Mode active multicast support in Rel-17. If time permits, RRC Inactive multicast support can be considered later (when connected mode multicast and broadcast solutions become more mature).

[0139] In some cases, such as when the network is congested due to the presence of a large number of UEs in a cell, the network may release a UE receiving a multicast session to inactivity. Therefore, in this scenario, it is assumed that the UE is initially connected when it starts receiving the multicast session (including the procedure for joining the multicast session). The UE is then released to inactivity while continuing to receive the multicast session.

[0140] Observation 1: This scenario is where a UE receiving a multicast session in RRC Connected is released to RRC Inactive, allowing the UE to continue receiving the multicast session.

[0141] Rel-17 specifies two delivery modes, called "Delivery Mode 1" for multicast sessions and "Delivery Mode 2" for broadcast sessions. In Delivery Mode 1, MTCH reception configuration is provided by RRC reconfiguration for UEs in Connected state, while in Delivery Mode 2, it is done by MCCH for UEs in all RRC states.

[0142] To support multicast reception in the inactive state, we first need to consider whether the solution is based on "Delivery Mode 1" or "Delivery Mode 2".

[0143] Delivery mode 1 is easy to provide multicast sessions, but is currently limited to UEs in connected state. To support inactive UEs, many features and assumptions may need to be restricted / modified, such as handling of MTCH configuration, deactivation of PTP legs, HARQ feedback, CFR, etc. These modifications may require the involvement of RAN1, but it should be noted that RAN1 is not mentioned in Rel-18e MBSWI.

[0144] Observation 2: To provide a multicast session, it is straightforward to provide MTCH reception configuration via dedicated signaling (i.e., based on distribution mode 1). However, it should be noted that the involvement of RAN1 may be required, which is not included in the supported WGs in the WID.

[0145] Although distribution mode 2 already supports inactive broadcast reception, it has less network controllability compared to multicast sessions. Furthermore, the MCCH may be receivable by all UEs, and the reception settings of the MTCH related to the multicast session are also visible to all UEs, which raises potential security concerns.

[0146] Observation 3: MCCH can already provide broadcast sessions to RRC-inactive UEs (i.e., based on delivery mode 2), but Rel-17 has the problem of less network controllability.

[0147] Based on the above observations, RAN2 should discuss the solution direction for supporting multicast reception in RRC inactive, whether the MTCH reception configuration is provided by dedicated signaling (i.e., a distribution mode 1 based solution) or by MCCH (i.e., a distribution mode 2 based solution).

[0148] Proposal 1: To support multicast reception in RRC inactive, RAN2 should discuss the solution direction on whether the MTCH reception configuration is provided by dedicated signaling (i.e., a distribution mode 1 based solution) or by MCCH (i.e., a distribution mode 2 based solution).

[0149] Delivery Mode 1 Based Solution If the MTCH reception configuration is provided by dedicated signaling, it needs to be discussed whether the configuration is provided by RRC reconfiguration (as in Rel-17) or by RRC release.

[0150] With RRC reconfiguration, a UE transitions from Connected to Inactive and continues to apply the same configuration to receive the MTCH of interest. The advantage is that the current RRC reconfiguration can be reused, since the MRB configuration is already specified in Rel-17. On the other hand, since the UE needs to continue applying the MRB configuration even after transitioning to Inactive, additional UE behavior needs to be specified in the RRC reconfiguration procedure. In this case, the question remains as to whether a UE interested in a multicast session that transitions to Inactive can always continue to apply the configuration, or whether the network needs to explicitly indicate whether the MRB configuration should be applied, for example, via RRC release. Furthermore, RAN2 needs to discuss whether the UE can verify the MRB configuration, i.e., whether a validity timer such as T320 for dedicated priority is required. With RRC release, when the UE transitions to Inactive, if the configuration is provided in the RRC release message, it can continue receiving the MTCH of interest by simply applying the new configuration. Generally, it is very easy to provide a specific configuration to a UE using RRC release when the UE transitions to RRC inactive. Furthermore, it is highly compatible with the RNA update procedure. If the MRB used in inactive mode can also be reconfigured in RNA update (i.e., RRC release), the UE can be reconfigured without transitioning to connected mode. On the other hand, the disadvantage is that signaling overhead always occurs, even if the MRB configuration is the same as that already provided by a previous RRC reconfiguration. It is also worth discussing whether a validity timer is necessary.

[0151] Therefore, RAN2 should discuss whether the configuration of the received MTCH is provided by dedicated signaling, whether the configuration is provided by RRC reconfiguration or by RRC release. Furthermore, RAN2 should also discuss whether a validity timer is required for such dedicated configuration.

[0152] Proposal 2: For delivery mode 1 based solutions, RAN2 should discuss whether the configuration of the received MTCH is provided by RRC reconfiguration or by RRC release.

[0153] Proposal 3: For delivery mode 1 based solutions, RAN2 needs to discuss whether the UE's configuration for receiving MTCH can be considered valid all the time or only for a certain period of time (e.g. using a validity timer).

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

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

[0156] Since the configuration for MTCH reception is valid in the RNA, the gNB needs to be able to apply the same configuration in the RNA of each UE. The advantage of this method is that inactive UEs do not need to be reconfigured and can continue to receive MTCH in the RNA. On the other hand, since the RNA is UE-specific, it makes the network more complex.

[0157] A more flexible and less complicated method is for the gNB to provide a cell list in the configuration, so that the configuration is considered valid in the cells included in the list. The cell list can be cell-specific, UE-specific, RNA-related, MRB area-specific, or MBS service area-specific, depending on the implementation of the network.

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

[0159] Proposal 4: For distribution mode 1 based solutions, RAN2 should discuss whether the MTCH reception configuration is valid for the serving cell or for the area (RNA, cell list, etc.).

[0160] Delivery Mode 2 Based Solution As mentioned above, if the configuration for receiving the MTCH is provided over the MTCH, all the configuration, i.e., the MBS session information, is visible to all UEs, even if some of them are not participating in the multicast session. Therefore, these UEs that are not participating in the multicast session should not be able to receive the multicast MTCH.

[0161] It is assumed that due to higher layer procedures, UEs cannot receive the MTCH for the TMGI of a multicast session in the USD, but it is up to the gNB to decide whether to use distribution mode 1 or distribution mode 2 for the distribution of the multicast session. Therefore, an AS layer solution is desirable. One of the simplest solutions is to set an indicator in each MBS session information of the MCCH that distinguishes between multicast and broadcast sessions. UEs that do not participate in a multicast session are prohibited from using the corresponding MTCH. RAN2 should discuss whether this is an issue that needs to be resolved when the MCCH is inactive and used for multicast reception.

[0162] Proposal 5: For a delivery mode 2 based solution, RAN2 should consider whether to prevent a UE from using a multicast MTCH if the UE is not participating in the corresponding multicast session.

[0163] Another issue worth considering is the process of switching from delivery mode 1 to delivery mode 2 while receiving a multicast session. Although WID states that "seamless / lossless mobility is not required," some degree of service continuity should be ensured as part of the service requirements and expectations for multicast sessions.

[0164] If the UE starts acquiring MCCH and MTCH after an RRC state transition shortly after being released to inactivity, the service interruption during the delivery mode switch may be excessive, so such service interruption should be minimized, if not seamless / lossless.

[0165] A possible solution is for the gNB to provide the MCCH to the UE via dedicated signaling while the UE is still connected. In this way, the UE can start receiving the MTCH before transitioning to inactivity, thereby reducing service interruptions. One question is whether the dedicated signaling is an RRC reconfiguration or an RRC release; if it is an RRC reconfiguration, the UE may be able to start receiving the MTCH earlier.

[0166] Proposal 6: For a delivery mode 2 based solution, RAN2 should discuss whether to minimize service interruption when switching from delivery mode 1 to delivery mode 2.

[0167] Proposal 7: If Proposal 6 is agreed upon, RAN2 should further discuss whether to provide MCCH by dedicated signaling. Further consideration is needed on whether to use RRC reconfiguration or RRC release.

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

Claims

1. A communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a network node transmitting a multicast control channel (MCCH) including a plurality of MBS configurations for a plurality of MBS sessions, the plurality of MBS configurations including a multicast configuration for a multicast session; and the user equipment obtaining and applying the multicast configuration in the MCCH in response to the user equipment participating in the multicast session. Communication methods.

2. The user equipment further includes obtaining and applying the multicast configuration in response to an RRC state of the user equipment being an RRC inactive state. The communication method according to claim 1 .

3. A mobile communication system providing a multicast / broadcast service (MBS), comprising: A network node and a user equipment, The network node transmits a Multicast Control Channel (MCCH) including multiple MBS configurations for multiple MBS sessions; The plurality of MBS configurations includes a multicast configuration for a multicast session; The user equipment obtains and applies the multicast configuration in the MCCH in response to the user equipment participating in the multicast session. Mobile communication system.

4. A user device in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a receiving unit for receiving a Multicast Control Channel (MCCH) from a network, the Multicast Control Channel (MCCH) including a plurality of MBS configurations for a plurality of MBS sessions; A control unit, The plurality of MBS configurations includes a multicast configuration for a multicast session; The control unit acquires and applies the multicast setting in the MCCH in response to the user equipment participating in the multicast session. User equipment.

5. A processor for controlling a user device in a mobile communication system providing a multicast / broadcast service (MBS), comprising: A process of receiving a multicast control channel (MCCH) from a network, the multicast control channel (MCCH) including a plurality of MBS configurations for a plurality of MBS sessions, the plurality of MBS configurations including a multicast configuration for a multicast session; and acquiring and applying the multicast setting in the MCCH in response to the user equipment participating in the multicast session. Processor.

6. A program for controlling a user device in a mobile communication system providing a multicast / broadcast service (MBS), comprising: A process of receiving a multicast control channel (MCCH) from a network, the multicast control channel (MCCH) including a plurality of MBS configurations for a plurality of MBS sessions, the plurality of MBS configurations including a multicast configuration for a multicast session; and in response to the user equipment participating in the multicast session, acquiring and applying the multicast setting in the MCCH. program.