Communication method, user equipment, and network node

Abstract

This communication method, which is executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS), involves: a step for receiving, from a network, specification information for specifying through which signaling the user device acquires, from the network, a point-to-multipoint (PTM) setting necessary in order for the user device to receive a multicast session; and a step for acquiring the PTM setting from the network via the signaling specified on the basis of the specification information.

Description

COMMUNICATION METHOD, USER EQUIPMENT, AND NETWORK NODE

[0001] The present disclosure relates to a communication method, a user equipment, and a network node for use in a mobile communication system.

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

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

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

[0005] A communication method according to a first aspect is a method executed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), the method comprising the steps of: receiving, from a network, identifying information for identifying by which signaling the user equipment should acquire a point-to-multipoint (PTM) configuration required for the user equipment to receive a multicast session; and acquiring the PTM configuration from the network by the signaling identified based on the identifying information.

[0006] A user equipment according to a second aspect is an equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), and includes: a receiving unit that receives, from a network, identification information for identifying by which signaling the user equipment should acquire a point-to-multipoint (PTM) configuration required for the user equipment to receive a multicast session from the network; and a control unit that acquires the PTM configuration from the network by the signaling identified based on the identification information.

[0007] A network node according to a third aspect is a node for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a transmitter configured to transmit, to a user equipment, identification information for identifying by which signaling the user equipment should acquire from a network a point-to-multipoint (PTM) configuration required for the user equipment to receive a multicast session.

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

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

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

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

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

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

[0014] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.

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

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

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

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

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

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

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

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

[0023] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer described below. The operations of the gNB 200 described above and below may be operations under the control of the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

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

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

[0026] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[0027] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires the successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has a CRC parity bit scrambled by the RNTI added.

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

[0029] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

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

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

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

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

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

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

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

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

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

[0039] In the case of a broadcast communication service, the UE 100 receives a broadcast session in the following procedure. First, the UE 100 receives a system information block type 20 (SIB20) from the gNB 200. The SIB20 includes a configuration of a multicast control channel (MCCH), which is a type of logical channel. Second, the UE 100 receives the MCCH from the gNB 200 based on the SIB20. The MCCH includes a PTM configuration. The PTM configuration transmits a configuration (MTCH configuration) for a multicast traffic channel (MTCH), which is a type of logical channel, and a broadcast MRB configuration, which is a multicast radio bearer (MRB) for the broadcast session. The information transmitted by the MCCH is sometimes referred to as MBS broadcast control information. Third, the UE 100 receives the MTCH based on the MCCH. The MTCH transmits the broadcast session (specifically, MBS data belonging to the broadcast session).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0056] As described above, the gNB 200 transmits to the UE 100 a PTM configuration including configuration information for a multicast inactive MRB, which is an MRB for receiving a multicast session in an RRC inactive state. There are two types of signaling used when transmitting the PTM configuration for receiving a multicast session in an RRC inactive state to the UE 100: 1) dedicated RRC signaling, and 2) multicast MCCH. Here, the dedicated RRC signaling is signaling individual to the UE 100 (i.e., unicast signaling) and may be an RRC reconfiguration message or an RRC release message. On the other hand, the multicast MCCH may be signaling common to an unspecified number of UEs 100 (i.e., broadcast signaling).

[0057] The PTM setting transmitted by such signaling may be an initial PTM setting. The initial PTM setting may be a full setting for performing multicast reception (MTCH reception). The initial PTM setting may be a PTM setting that the UE 100 receives first. Under the assumption that the initial PTM setting can be transmitted by two types of signaling, it becomes unclear which of these two types of signaling the UE 100 should use to obtain the PTM setting from the network 5. Therefore, there is a concern that the UE 100 may not be able to properly perform multicast reception.

[0058] In the following embodiment, even if the initial PTM setting can be provided to the UE 100 from the network 5 (gNB 200) by multiple types of signaling, a method for enabling the UE 100 to properly perform multicast reception will be described. Figure 6 is a diagram showing an overview of the operation of the UE 100 according to the embodiment.

[0059] In step S1, the UE 100 receives, from the network 5, identification information for identifying by which signaling the UE 100 will acquire a point-to-multipoint (PTM) configuration required for receiving a multicast session from the network 5. For example, the identification information is information for identifying whether the UE 100 will acquire the PTM configuration by dedicated RRC signaling or by a multicast MCCH.

[0060] In step S2, the UE 100 acquires the PTM configuration from the network 5 by signaling identified based on the identifying information received in step S1. For example, the UE 100 acquires the PTM configuration from the network 5 by dedicated RRC signaling or a multicast MCCH.

[0061] In step S3, the UE 100 performs a multicast reception process (a reception process of a multicast session) by applying the PTM setting acquired in step S2. The multicast reception process is a process of establishing a multicast inactive MRB (or a multicast MRB) by applying the PTM setting and receiving an MTCH (i.e., multicast data) associated with the MRB.

[0062] Thus, in the embodiment, the network 5 (gNB 200) notifies the UE 100 of the identification information (permission information) indicating whether the initial PTM setting may be acquired from the multicast MCCH. This allows the UE 100 to properly perform multicast reception even when the initial PTM setting can be provided to the UE 100 from the network 5 (gNB 200) by multiple types of signaling.

[0063] Note that the gNB 200, which is a network node according to the embodiment, has a transmitter 200 that transmits to the UE 100 identification information for identifying by which signaling the UE 100 will acquire the point-to-multipoint (PTM) setting required for the UE 100 to receive the multicast session from the network 5. The UE 100 according to the embodiment has a receiver 110 that receives from the network 5 identification information for identifying by which signaling the UE 100 will acquire the PTM setting required for the UE 100 to receive the multicast session from the network 5, and a control unit 130 that acquires the PTM setting from the network 5 by signaling identified based on the identification information.

[0064] The identifying information may be set in units of a multicast session, an MRB, or a group DRX to the UE 100. For example, the identifying information may be set for each TMGI, for each MRB, or for each group DRX index.

[0065] The identification information may be information indicating whether acquisition of the PTM setting via the multicast MCCH is permitted. In step S2, the UE 100 acquires the PTM setting from the network 5 via the multicast MCCH in response to the identification information indicating permission to acquire the PTM setting via the multicast MCCH.

[0066] In step S1, the UE 100 may receive an RRC Release message from the network 5, which includes the identifying information and transitions the UE 100 from the RRC connected state to the RRC inactive state. That is, the network 5 (gNB 200) may include the identifying information in the RRC Release message and transmit it to the UE 100.

[0067] Alternatively, in step S1, UE 100 may receive a system information block (SIB) including identifying information from network 5. That is, network 5 (gNB 200) may include identifying information in an SIB and transmit (broadcast) it to UE 100. For example, the SIB may be SIB type 1 (SIB1), and identifying information may be set on a cell-by-cell basis. The SIB may be the above-mentioned SIB type x (SIBx), and identifying information may be set on a multicast session basis (per MBS session ID) or per MRB basis (per MRB ID).

[0068] Alternatively, in step S1, UE 100 may receive a multicast MCCH including identification information from network 5. That is, network 5 (gNB 200) may include the identification information in the multicast MCCH and transmit (broadcast) it to UE 100. In the multicast MCCH, identification information may be included on a multicast session basis (for each MBS session ID) or on an MRB basis (for each MRB ID).

[0069] Alternatively, in step S1, the UE 100 may receive a paging message (group notification) from the network 5 that includes the identifying information and notifies the activation of the multicast session. That is, the network 5 (gNB 200) may include the identifying information in the group notification and transmit it to the UE 100. Here, the identifying information may be set on a multicast session basis. For example, the group notification may include identifying information for each MBS session ID.

[0070] In step S2, the UE 100 in the RRC inactive state may, in response to recognizing the activation of the multicast session, acquire the PTM configuration from the network 5 by signaling identified based on the identifying information.

[0071] In step S2, the UE 100 in the RRC inactive state may acquire the PTM setting from the network 5 by the multicast MCCH. In this case, in step S1, the network 5 (gNB 200) notifies the UE 100 of identification information indicating the acquisition of the PTM setting by the multicast MCCH.

[0072] In step S2, UE100 may acquire the PTM setting from network 5 by dedicated RRC signaling in response to the identification information indicating that acquisition of PTM setting by multicast MCCH is not permitted or that the identification information indicates that PTM setting should be acquired by dedicated RRC signaling. In this case, network 5 (gNB200) notifies UE100 in step S1 of the identification information indicating that acquisition of PTM setting by multicast MCCH is not permitted or the identification information indicating that PTM setting should be acquired by dedicated RRC signaling. Note that UE100 in the RRC inactive state may transition to the RRC connected state and then acquire the PTM setting from network 5 by dedicated RRC signaling.

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

[0074] In step S101, UE100 is in an RRC connected state in the cell of gNB200. UE100 has already participated in a multicast session (hereinafter referred to as "multicast session #1"), and multicast session #1 is in an inactive state. Note that gNB200 is aware of multicast session #1 in which UE100 has participated, and is aware of whether multicast session #1 is activated.

[0075] In step S102, the gNB 200 transmits an RRC Release message including suspend configuration and identifying information to the UE 100. The UE 100 receives the RRC Release message. In an embodiment, the RRC Release message including the identifying information does not include a PTM configuration for the multicast session #1. Therefore, at this point, the UE 100 does not have a valid PTM configuration for the multicast session #1.

[0076] The identifying information may be information indicating that the initial PTM configuration may be acquired via a multicast MCCH. The identifying information may be information indicating that the initial PTM configuration may not be acquired via broadcast signaling (multicast MCCH). The identifying information may be information indicating that the initial PTM configuration must be acquired via dedicated RRC signaling (an RRC Reconfiguration message or an RRC Release message).

[0077] The identification information may include information instructing to start multicast reception in the RRC inactive state. The identification information may include information instructing to start multicast reception without transitioning to the RRC connected state. The identification information may include information instructing to start multicast reception in the RRC connected state.

[0078] FIG. 7 shows an example in which gNB200 transmits an RRC Release message including identifying information to UE100. By using the RRC Release message to notify UE100 of the identifying information, appropriate settings can be made for each UE100. However, signaling other than the RRC Release message may be used to notify UE100 of the identifying information. For example, gNB200 may use SIB, multicast MCCH, or paging message (group notification) to notify UE100 of the identifying information.

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

[0080] In step S104, the gNB 200 may transmit a paging message (group notification) including the MBS session ID of the multicast session #1 to notify that the multicast session #1 has been activated. The UE 100 may receive the group notification.

[0081] In step S105, the UE 100 recognizes the activation of the multicast session #1. For example, the UE 100 may recognize the activation of the multicast session in response to receiving the group notification in step S104.

[0082] Alternatively, UE 100 may recognize (estimate) the activation of a multicast session based on pre-stored upper layer information. The upper layer information is information managed in an upper layer. The upper layer may refer to a layer higher than the AS layer, for example, the application layer or the NAS layer. The upper layer information may be a USD (User Service Description). The USD may be provided to UE 100 from a server in the upper layer. The USD includes information on the start time of each MBS session (also referred to as "session start time information"). Therefore, UE 100 can determine whether multicast session #1 is active based on the current time and the session start time information included in the upper layer information (USD).

[0083] In step S106, the UE 100 checks whether or not acquisition of the PTM setting via the multicast MCCH is permitted, based on the identification information received in step S102.

[0084] If acquisition of PTM settings via the multicast MCCH is permitted (step S106: YES), in step S108, UE100 receives the multicast MCCH from gNB200 and acquires the initial PTM settings included in the received multicast MCCH. Here, gNB200 transmits a multicast MCCH including the PTM settings for multicast session #1 (step S107). UE100 acquires the PTM settings for multicast session #1. Then, processing proceeds to step S114.

[0085] On the other hand, if acquisition of the PTM setting via the multicast MCCH is not permitted (step S106: NO), that is, if the PTM setting should be acquired by dedicated RRC signaling, in step S109, the UE 100 starts an RRC Resume procedure with the gNB 200. In the RRC Resume procedure, the UE 100 may transmit to the gNB 200 an RRC Resume Request message including cause information indicating that the RRC Resume is for acquiring the PTM setting.

[0086] In step S110, gNB200 transmits dedicated RRC signaling including PTM settings for multicast session #1 to UE100. After UE100 transitions to the RRC connected state, gNB200 may transmit the PTM settings for multicast session #1 to UE100 by an RRC Reconfiguration message or an RRC Release message. Alternatively, gNB200 may transmit an RRC Release message including the PTM settings to UE100 during the RRC Resume procedure. For example, gNB200 may transmit an RRC Release message including the PTM settings to UE100 in response to receiving an RRC Resume Request message from UE100. In this case, the RRC Resume procedure ends without the UE 100 transitioning to the RRC connected state.

[0087] In step S111, UE100 receives dedicated RRC signaling, specifically, an RRC Reconfiguration message or an RRC Release message, from gNB200 and obtains the PTM settings contained in the received message.

[0088] In step S112, gNB200 transmits multicast data for multicast session #1 on MTCH.

[0089] In step S113, UE100 applies the acquired PTM settings and receives multicast data for multicast session #1 from gNB200 on MTCH.

[0090] (4) Modified Example of Operation of Mobile Communication System A modified example of the operation of the mobile communication system 1 will be described, focusing mainly on the differences from the above-described operation. In the modified example, the network 5 (gNB 200) sets identification information in the UE 100 in advance. Specifically, the network 5 (gNB 200) transmits an RRC Reconfiguration message including the identification information to the UE 100. In step S1 of FIG. 6, the UE 100 receives the RRC Reconfiguration message including the identification information from the network 5. In this way, in the modified example, the network 5 (gNB 200) sets identification information (permission information) in the UE 100 for specifying whether or not the initial PTM setting may be acquired from the multicast MCCH.

[0091] In a modified example, in step S2 of Figure 6, if the identification information indicates that UE 100 may obtain the initial PTM setting from the multicast MCCH, UE 100 may obtain the PTM setting from network 5 via the multicast MCCH at a time when a predetermined condition that allows obtaining the PTM setting via the multicast MCCH is satisfied.

[0092] The identifying information may include information specifying a predetermined condition. In this case, the network 5 (gNB 200) may transmit to the UE 100 an RRC Reconfiguration message including identifying information indicating a condition (predetermined condition) under which the initial PTM setting may be acquired from the multicast MCCH. Alternatively, the predetermined condition may be predefined in a technical specification.

[0093] The predetermined condition may be one of the following conditions a) to d) or a combination of two or more of them.

[0094] a) The predetermined condition may include a condition that the reception quality of the serving cell (for example, reference signal reception power or reference signal reception quality) in the UE 100 in the RRC connected state has deteriorated below a predetermined quality. For example, the predetermined condition may be a condition that the UE 100 is out of coverage of the serving cell. The permission to acquire the PTM setting by the multicast MCCH may be valid only when the UE 100 is out of coverage. Note that even an out-of-coverage UE 100 may be able to perform composite multicast reception (MCCH reception and MTCH reception) from multiple cells or multicast reception from other cells. In such a case, multicast reception may be possible by the UE 100 acquiring the initial PTM setting by the multicast MCCH.

[0095] b) The predetermined condition may include a condition that the UE 100 in the RRC connected state or the RRC inactive state receives a multicast session provided by a single frequency network (SFN). When the SFN is applied, there may be a case where the reception quality of a single cell is poor, but the combined multicast reception quality (MCCH reception quality and MTCH reception quality) from multiple cells constituting the SFN is good. In such a case, the UE 100 may be able to receive multicast by acquiring an initial PTM setting via the multicast MCCH.

[0096] c) The predetermined condition may include a condition that the UE 100 in the RRC connected state fails to reestablish RRC. When the UE 100 in the RRC connected state detects a radio link failure (RLF) in the serving cell, the UE 100 initiates an RRC reestablishment procedure. If the RRC reestablishment procedure fails, the UE 100 may transition from the RRC connected state to the RRC idle state. In such a case, assuming that multicast reception in the RRC idle state is supported by the technical specifications, multicast reception may be possible by the UE 100 acquiring an initial PTM setting via the multicast MCCH.

[0097] d) The predetermined condition may include a condition that the UE 100 in the RRC inactive state (or the RRC idle state) has reselected a serving cell (i.e., cell reselection). If the UE 100 has performed cell reselection, the UE 100 will no longer be able to acquire the initial PTM configuration from the original serving cell through dedicated RRC signaling. In such a case, the UE 100 may be able to receive multicast signals from the new serving cell by acquiring the initial PTM configuration through the multicast MCCH of the new serving cell.

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

[0099] In step S201, UE100 is in an RRC connected state in the cell of gNB200. UE100 has already participated in a certain multicast session (multicast session #1), and multicast session #1 is in an inactive state. Note that gNB200 is aware of multicast session #1 in which UE100 has participated, and is aware of whether multicast session #1 is activated.

[0100] In step S202, the network 5 (gNB 200) transmits an RRC Reconfiguration message including the identification information to the UE 100. The UE 100 receives the RRC Reconfiguration message. The RRC Reconfiguration message may include information specifying at least one of the above-described conditions a) to d) as a condition (predetermined condition) under which the identification information is applicable.

[0101] The RRC Reconfiguration message may include PTM settings for multicast session #1. In this case, in step S203, network 5 (gNB 200) may transmit multicast data of multicast session #1 on an MTCH. In step S204, UE 100 may apply the PTM settings and receive multicast data of multicast session #1 from network 5 (gNB 200) on an MTCH.

[0102] In step S205, the UE 100 checks whether a predetermined condition is satisfied.

[0103] If the predetermined condition is satisfied (step S205: YES), in step S206, the UE 100 checks whether or not acquisition of the PTM setting via the multicast MCCH is permitted, based on the identification information in step S202.

[0104] If acquisition of PTM settings via multicast MCCH is permitted (step S206: YES), in step S208, UE100 receives multicast MCCH from network 5 (gNB200) and acquires the initial PTM settings included in the received multicast MCCH. Here, network 5 (gNB200) transmits multicast MCCH including PTM settings for multicast session #1 (step S207). UE100 acquires the PTM settings for multicast session #1.

[0105] In step S209, network 5 (gNB200) transmits multicast data for multicast session #1 on MTCH.

[0106] In step S210, UE100 receives multicast data for multicast session #1 from network 5 (gNB200) on MTCH.

[0107] In a modified example, the identification information in the RRC Reconfiguration message in step S202 may include the initial PTM configuration itself. Specifically, the identification information may include the initial PTM configuration and information indicating a condition (predetermined condition) for applying the initial PTM configuration. In this case, the identification information in step S202 may be considered as information indicating that the initial PTM configuration should be acquired by dedicated RRC signaling. Such an initial PTM configuration may be referred to as a conditional PTM configuration. The UE 100 may apply the initial PTM configuration when the predetermined condition is satisfied. The conditional PTM configuration is maintained even when the UE 100 enters an RRC inactive state. The conditional PTM configuration may be a multicast inactive MRB configuration.

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

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

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

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

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

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

[0114] The functions performed by the UE 100 or the gNB 200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, circuitry, units, and means refer to hardware that is programmed to perform the described functions or 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.

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

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

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

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

[0119] (Supplementary Note 1) A communication method executed by a user device in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step of receiving, from the network, identification information for identifying by which signaling the user device is to obtain from the network a point-to-multipoint (PTM) setting required for the user device to receive a multicast session; and a step of obtaining the PTM setting from the network by the signaling identified based on the identification information.

[0120] (Supplementary Note 2) The communication method according to Supplementary Note 1, wherein the identification information is information indicating whether acquisition of the PTM setting via a multicast-multicast control channel (MCCH) is permitted, and the acquiring step includes a step of acquiring the PTM setting from the network via the multicast MCCH in response to the identification information indicating permission to acquire the PTM setting via the multicast MCCH.

[0121] (Supplementary Note 3) The communication method according to Supplementary Note 2, wherein the acquiring step includes a step in which the user equipment in an RRC inactive state acquires the PTM configuration from the network via the multicast MCCH.

[0122] (Supplementary Note 4) The communication method according to Supplementary Note 2 or 3, wherein the acquiring step includes a step of acquiring the PTM configuration from the network by the dedicated RRC signaling in response to the identification information indicating that acquisition of the PTM configuration via the multicast MCCH is not permitted or the identification information indicating that the PTM configuration should be acquired by dedicated RRC signaling.

[0123] (Supplementary Note 5) The communication method according to Supplementary Note 4, wherein the acquiring step includes a step of the user equipment in an RRC inactive state transitioning to an RRC connected state and acquiring the PTM configuration from the network by the dedicated RRC signaling.

[0124] (Supplementary Note 6) The communication method according to any one of Supplementary Notes 1 to 5, wherein the acquiring step includes a step of the user equipment in an RRC inactive state acquiring the PTM configuration from the network by the signaling identified based on the identification information in response to recognition of activation of the multicast session.

[0125] (Supplementary Note 7) The communication method according to any one of Supplementary Notes 1 to 5, wherein the receiving step includes a step of receiving, from the network, an RRC release message including the identification information and causing the user equipment to transition from an RRC connected state to an RRC inactive state.

[0126] (Supplementary Note 8) The communication method according to any one of Supplementary Notes 1 to 5, wherein the receiving step includes a step of receiving a system information block (SIB) including the identifying information from the network.

[0127] (Supplementary Note 9) The communication method according to any one of Supplementary Notes 1 to 5, wherein the receiving step includes a step of receiving a multicast MCCH including the identifying information from the network.

[0128] (Supplementary Note 10) The communication method according to any one of Supplementary Notes 1 to 5, wherein the receiving step includes a step of receiving, from the network, a paging message that includes the identifying information and notifies activation of the multicast session.

[0129] (Supplementary Note 11) The communication method according to any one of Supplementary Notes 1 to 5, wherein the receiving step includes a step of receiving an RRC reconfiguration message including the identifying information from the network.

[0130] (Supplementary Note 12) The communication method according to Supplementary Note 11, wherein the acquiring step includes a step of acquiring the PTM setting from the network via the multicast MCCH at a timing when a predetermined condition for permitting acquisition of the PTM setting via the multicast MCCH is satisfied, when the identification information indicates permission to acquire the PTM setting via the multicast MCCH.

[0131] (Supplementary Note 13) The communication method according to Supplementary Note 12, wherein the identification information includes information that specifies the predetermined condition.

[0132] (Supplementary Note 14) The communication method according to Supplementary Note 12 or 13, wherein the predetermined condition includes a condition that reception quality of a serving cell in the user equipment in an RRC connected state has deteriorated below a predetermined quality.

[0133] (Supplementary Note 15) The communication method according to any one of Supplementary Notes 12 to 14, wherein the predetermined condition includes a condition that the user equipment in an RRC connected state has failed to re-establish RRC.

[0134] (Supplementary Note 16) The communication method according to any one of Supplementary Notes 12 to 15, wherein the predetermined condition includes a condition that the user equipment in an RRC inactive state has performed serving cell reselection.

[0135] (Supplementary Note 17) The communication method according to any one of Supplementary Notes 12 to 16, wherein the predetermined condition includes a condition that the user equipment in an RRC connected state or an RRC inactive state receives the multicast session provided by a single frequency network.

[0136] (Supplementary Note 18) The communication method according to any one of Supplementary Notes 11 to 17, further comprising a step of applying the PTM setting, wherein the identification information includes the PTM setting and information indicating a condition for applying the PTM setting, and the applying step includes a step of applying the PTM setting in response to the condition being satisfied.

[0137] (Supplementary Note 19) A user equipment used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a receiving unit that receives, from a network, identification information for identifying by which signaling the user equipment should obtain from the network a point-to-multipoint (PTM) setting required for the user equipment to receive a multicast session; and a control unit that obtains the PTM setting from the network by the signaling identified based on the identification information.

[0138] (Supplementary Note 20) A network node used in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a transmitter configured to transmit, to a user equipment, identification information for identifying by which signaling a point-to-multipoint (PTM) setting required for receiving a multicast session is to be acquired from the network by the user equipment.

[0139] (7) Supplement 2 1. Introduction The work item on enhanced MBS (eMBS) aims to support multicast reception by UEs in inactive state and is described 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].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0193] 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 executed by a user device in a mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving identification information from the network for identifying by which signaling the user device should obtain point-to-multipoint (PTM) settings required for the user device to receive a multicast session from the network; and obtaining the PTM settings from the network by the signaling identified based on the identification information.

2. The communication method according to claim 1, wherein the specific information indicates whether or not acquisition of the PTM settings is permitted via a multicast-multicast control channel (MCCH), and the acquiring includes acquiring the PTM settings from the network via the multicast MCCH in response to the specific information indicating permission for acquisition of the PTM settings via the multicast MCCH.

3. The communication method according to claim 2, wherein the acquiring step includes the user equipment in an RRC inactive state acquiring the PTM configuration from the network via the multicast MCCH.

4. The communication method of claim 2, wherein the acquiring step includes acquiring the PTM setting from the network by the dedicated RRC signaling in response to the specific information indicating that acquisition of the PTM setting by the multicast MCCH is not permitted or the specific information indicating that the PTM setting should be acquired by dedicated RRC signaling.

5. The communication method according to claim 4, wherein the acquiring step includes the user equipment in an RRC inactive state transitioning to an RRC connected state and acquiring the PTM configuration from the network by the dedicated RRC signaling.

6. A communication method according to any one of claims 1 to 5, wherein the acquiring step includes acquiring the PTM configuration from the network by the signaling identified based on the identification information in response to the user equipment in an RRC inactive state recognizing activation of the multicast session.

7. The communication method according to any one of claims 1 to 5, wherein the receiving step includes receiving an RRC release message from the network, the RRC release message including the identifying information and causing the user equipment to transition from an RRC connected state to an RRC inactive state.

8. A method according to any one of claims 1 to 5, wherein said receiving comprises receiving a system information block (SIB) from said network, said system information block (SIB) including said identifying information.

9. A communication method according to any one of claims 1 to 5, wherein the receiving step includes receiving a multicast MCCH including the identifying information from the network.

10. A method according to any one of claims 1 to 5, wherein said receiving comprises receiving a paging message from said network, said paging message including said identifying information and indicating activation of said multicast session.

11. The method of any one of claims 1 to 5, wherein the receiving step includes receiving an RRC reconfiguration message from the network, the RRC reconfiguration message including the identifying information.

12. The communication method described in claim 11, wherein the acquiring includes, when the identification information indicates permission to acquire the PTM settings via the multicast MCCH, acquiring the PTM settings from the network via the multicast MCCH at a timing when a predetermined condition for permitting acquisition of the PTM settings via the multicast MCCH is satisfied.

13. The communication method according to claim 12, wherein the identifying information includes information that specifies the predetermined condition.

14. The communication method according to claim 12, wherein the predetermined condition includes a condition that reception quality of a serving cell in the user equipment in an RRC connected state becomes worse than a predetermined quality.

15. The communication method according to claim 12, wherein the predetermined condition includes a condition that the user equipment in an RRC connected state has failed to re-establish RRC.

16. The communication method according to claim 12, wherein the predetermined condition includes a condition that the user equipment in an RRC inactive state has reselected a serving cell.

17. The communication method according to claim 12, wherein the predetermined condition includes a condition that the user equipment in an RRC connected state or an RRC inactive state receives the multicast session provided by a single frequency network.

18. The communication method according to claim 11, further comprising applying the PTM setting, wherein the identification information includes the PTM setting and information indicating a condition for applying the PTM setting, and wherein the applying includes applying the PTM setting in response to the condition being satisfied.

19. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a receiving unit that receives, from a network, identification information for identifying by which signaling the user equipment should obtain from the network a point-to-multipoint (PTM) setting required for the user equipment to receive a multicast session; and a control unit that obtains the PTM setting from the network by the signaling identified based on the identification information.

20. A network node used in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a transmitter that transmits, to a user device, identification information for identifying by which signaling the user device should obtain from the network a point-to-multipoint (PTM) setting required for the user device to receive a multicast session.

Images