Communication methods, user devices, processors, programs, and mobile communication systems

Abstract

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

Description

Technical Field

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

Background Art

[0002] In 3GPP (3rd Generation Partnership Project), the technical specifications of NR (New Radio), which is the 5th generation (5G) radio access technology, are defined. NR has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is the 4th generation (4G) radio access technology. In 3GPP, the technical specifications of 5G / NR's multicast / broadcast service (MBS) are defined.

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

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] A communication method according to the first embodiment is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising the step of a user device in a radio resource control (RRC) connected state receiving a point-to-multipoint (PTM) setting relating to a multicast session from a base station on a dedicated control channel (DCCH). The receiving step includes receiving the PTM setting on the DCCH from the base station, which includes the same information elements as the information elements provided on the multicast control channel (MCCH).

[0006] A communication method according to a second embodiment is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and comprises the step of a user device that is in a radio resource control (RRC) connected state and has already joined a multicast session receiving configuration information from a base station on a dedicated control channel (DCCH). If the multicast session has not yet been activated, the receiving step includes receiving configuration information from the base station regarding permission for multicast reception in an RRC inactive state. [Brief explanation of the drawing]

[0007] [Figure 1] This diagram shows the configuration of a mobile communication system according to an embodiment. [Figure 2] This diagram shows the configuration of the UE (User Equipment) according to the embodiment. [Figure 3] This diagram shows the configuration of the gNB (base station) according to the embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6]This diagram shows the MBS broadcast configuration (MBSBroadcastConfiguration) message in MCCH as defined in the RRC technical specification (TS38.331). [Figure 7] This diagram shows an overview of the operation that enables UE100, which is in an RRC inactive state, to perform multicast reception. [Figure 8] This is a diagram illustrating the overview of the operation according to the first embodiment. [Figure 9] This figure shows an example of the first operation pattern of the first embodiment. [Figure 10] This figure shows an example of a second operation pattern of the first embodiment. [Figure 11] This figure shows an example of the first operation pattern of the second embodiment. [Figure 12] This figure shows an example of the second operation pattern of the second embodiment. [Figure 13] This diagram illustrates an example of how distribution mode 2 works when applied to MBS multicast. [Figure 14] This diagram shows the configuration of SIB20 as defined in the 3GPP Release 17 RRC specification (TS38.331). [Figure 15] This is a diagram illustrating the operation of a mobile communication system according to another embodiment. [Figure 16] This diagram shows the PTM configuration distribution procedure for an activated multicast session. [Modes for carrying out the invention]

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

[0009] (1) First Embodiment A first embodiment will be described with reference to Figures 1 to 10.

[0010] (1.1) System Configuration Figure 1 shows the configuration 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. In the following explanation, 5GS will be used as an example, but the mobile communication system may also incorporate an LTE (Long Term Evolution) system at least partially. The mobile communication system may also incorporate a 6th Generation (6G) system at least partially.

[0011] The mobile communication system 1 comprises User Equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, NG-RAN 10 may be simply referred to as RAN 10, and 5GC 20 may be simply referred to as the core network (CN) 20. RAN 10 and CN 20 constitute the network 5 of the mobile communication system 1.

[0012] UE100 is a mobile wireless communication device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or device attached to a sensor, a vehicle or device attached to a vehicle (Vehicle UE), or an aircraft or device attached to an aircraft (Aerial UE).

[0013] NG-RAN 10 includes base stations (referred to as "gNB" in the 5G system) 200. The gNBs 200 are interconnected via the 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 cell. The gNB 200 has functions such as a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), and a measurement control function for mobility control and scheduling. A "cell" is used as a term indicating the smallest unit of a wireless communication area. A "cell" is also used as a term indicating a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

[0014] Note that the gNB can also be connected to the EPC (Evolved Packet Core), which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

[0015] The 5GC 20 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 performs transfer control of data. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

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

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

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

[0019] The control unit 130 performs various control and processing operations on the UE 100. Such processing includes processing of each layer described later. The operation of the UE 100 described above and later may also be 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 for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0020] Figure 3 shows the configuration of the gNB200 (base station) according to the embodiment. The gNB200 has a transmitter 210, a receiver 220, a control unit 230, and a backhaul communication unit 240. The transmitter 210 and receiver 220 constitute a wireless communication unit that performs wireless communication with the UE100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN20.

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

[0023] The control unit 230 performs various control and processing operations in the gNB200. Such processing includes processing in each layer described later. The operation of the gNB200 described above and below may also be controlled by 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0024] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via the NG interface, which is an inter-base station-core network interface. The gNB200 may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected by the F1 interface, which is a fronthaul interface.

[0025] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.

[0026] The user plane radio interface protocol consists of a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) 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 UE100's PHY layer and the gNB200's PHY layer via a physical channel. The UE100's PHY layer receives downlink control information (DCI) transmitted from the gNB200 over the physical downlink control channel (PDCCH). Specifically, the UE100 performs blind decoding of the PDCCH using a Radio Network Temporary Identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to its own UE. The DCI transmitted from the gNB200 has a CRC parity bit added, which is scrambled by the RNTI.

[0028] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[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 UE100's RLC layer and the gNB200's RLC layer via a logical channel.

[0030] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

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

[0032] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0033] The control plane's wireless interface protocol stack includes an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer, instead of the SDAP layer shown in Figure 4.

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

[0035] The NAS layer (also simply referred to as "NAS"), located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300A's NAS layer. The UE100 also has application layers and other components in addition to its wireless interface protocol. Furthermore, the layer below the NAS layer is called the AS layer (also simply referred to as "AS").

[0036] (1.2) MBS Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS). A session refers to a series of communications (from start to finish) for a service (application), and an MBS session refers to a session used in MBS.

[0037] In the case of multicast communication services (also referred to as "MBS multicast"), the same service and the same specific content data are provided simultaneously to a specific set of UEs. That is, not all UE100s within the multicast service area are permitted to receive the data. Multicast communication services are delivered to UE100s using multicast sessions, which are a type of MBS session. UE100s can receive multicast communication services in an RRC connected state using mechanisms such as PTP (Point-to-Point) and / or PTM (Point-to-Multipoint) delivery. UE100s may also receive multicast communication services in an RRC inactive (or RRC idle) state. This delivery mode is also referred to as "delivery mode 1". Note that UE100s can only receive multicast sessions after joining the multicast session. Here, joining a multicast session may mean registering with network 5 (CN20) as a UE100 capable of receiving the multicast session.

[0038] In the case of broadcast communication services (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. The broadcast communication service is delivered to the UE100s using a broadcast session, which is a type of MBS session. The UE100s can receive the broadcast communication service in any of the following states: RRC idle, RRC inactive, and RRC connected. This delivery mode is also known as "delivery mode 2".

[0039] The main logical channels used for MBS distribution 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 for either a multicast session or a broadcast session from network 10 to UE100. The DTCH is a PTP channel for transmitting MBS data for a multicast session from network 10 to UE100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 10 to UE100. In distribution mode 1, various settings for UE100 are performed using the Dedicated Control Channel (DCCH).

[0040] In MBS multicast, the transmission of MBS data packets (also called "MBS packets") can be either point-to-point (PTP) transmission, which is equivalent to unicast, or point-to-multipoint (PTM) transmission. In contrast, MBS broadcast can only use PTM transmission. In the case of PTP transmission, the gNB200 can independently distribute individual copies of the MBS packet to each UE100. For example, the gNB200 schedules a UE-specific PDSCH scrambled with a UE-specific RNTI (e.g., C-RNTI) using a UE-specific PDCCH with a CRC (Cyclic Redundancy Code) scrambled with a UE-specific RNTI. On the other hand, in the case of PTM transmission, the gNB200 distributes a single copy of the MBS packet to a set (group) of multiple UE100s. For example, gNB200 uses a group-common PDCCH with a group-common RNTI (e.g., G-RNTI) that scrambles the CRC, to schedule a group-common PDSCH scrambled by a group-common RNTI.

[0041] Regarding the settings for MBS broadcasts, UE100 in the RRC idle, RRC inactive, or RRC connected state receives PTM settings for the broadcast session (e.g., parameters required for MTCH reception) via MCCH. The parameters required for MCCH reception (MCCH settings) are provided via system information. Specifically, system information block type 20 (SIB20) contains the MCCH settings. SIB type 21 (SIB21) contains information regarding the continuity of service for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions transmitted via MTCH. The broadcast session information includes the MBS session identifier (e.g., TMGI (Temporary Mobile Group Identity)), relevant MTCH scheduling information, and information about neighboring cells providing specific services via MTCH.

[0042] Figure 6 shows the MBS broadcast configuration (MBSBroadcastConfiguration) message in MCCH as defined in the RRC technical specification (TS38.331). MCCH includes an MBS session information list (mbs-SessionInfoList) that provides the configuration for each MBS session (each broadcast session) provided by MBS broadcast in the current cell, a list of neighboring cells providing MBS broadcast services via broadcast MRB (mbs-NeighbourCellList), a list of DRX configurations (drx-ConfigPTM-List), and parameters for obtaining the PDSCH for MTCH (pdsch-ConfigMTCH).

[0043] On the other hand, with regard to MBS multicast, the current 3GPP technical specifications stipulate that the UE100 can only receive multicast session data when it is in the RRC Connected state. If a UE100 participating in a multicast session is in the RRC Connected state and the multicast session is activated, the gNB200 sends an RRC Reconfiguration message to the UE100 that includes the PTM settings for that multicast session. Such PTM settings are also referred to as multicast radio bearer (MRB) settings, MTCH settings, or PTM settings. The MRB setting (MRB-ToAddMod) includes the MBS session identifier (mbs-SessionId), the MRB identifier (mrb-Identity), and other parameters such as the PDCP setting (pdcp-Config) for the MRB (multicast MRB) to be configured on the UE100.

[0044] The following embodiment primarily describes an operation that enables a UE100 in an RRC inactive state to perform multicast reception. Figure 7 is a diagram illustrating an overview of this operation.

[0045] Two solutions are possible for a UE100 in an RRC inactive state to perform multicast reception: a distribution mode 1-based solution shown in Figure 7(a) and a distribution mode 2-based solution shown in Figure 7(b). The UE100 is assumed to support multicast reception in an RRC inactive state and to have already joined a multicast session.

[0046] In the distribution mode 1-based solution shown in Figure 7(a), in step S1, the gNB200 sends an RRC Reconfiguration message to the RRC-connected UE100, which includes the MBS settings (PTM settings) for the multicast session. Based on the PTM settings received in the RRC Reconfiguration message, the UE100 receives multicast data on the MTCH via the multicast session (multicast MRB).

[0047] In step S2, gNB200 sends an RRC Release message to UE100, which is in the RRC Connected state, to transition UE100 to the RRC Inactive state. This RRC Release message includes the settings for the RRC Inactive state (Suspend Config.).

[0048] In step S3, UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message in step S2.

[0049] In step S4, the UE100, which is in an RRC inactive state, continues to use the PTM settings from step S1 to receive multicast data on the MTCH via the multicast session.

[0050] This allows the UE100, which is in an RRC inactive state, to receive multicast traffic. While this example demonstrates using the RRC Reconfiguration message to configure PTM settings, you can also use the RRC Release message.

[0051] Both RRC Reconfiguration messages and RRC Release messages are RRC messages transmitted individually to each UE over the Dedicated Control Channel (DCCH), and are hereafter referred to as dedicated RRC messages or dedicated signaling.

[0052] On the other hand, in the delivery mode 2-based solution shown in Figure 7(b), in step S11, the gNB200 sends an RRC Release message to the UE100 in the RRC connected state to transition the UE100 to the RRC inactive state. This RRC Release message includes a setting for the RRC inactive state (Suspend Config.).

[0053] In step S12, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S11.

[0054] In step S13, gNB200 transmits an MCCH containing MBS settings (PTM settings) for the multicast session. UE100 receives the MCCH. Prior to receiving the MCCH, UE100 receives an SIB20 and receives the MCCH based on the SIB20. The transmission (and reception) of the MCCH may occur before step S11 or simultaneously with step S11.

[0055] In step S14, the UE100, which is in an RRC inactive state, receives multicast data on the MTCH via the multicast session based on the PTM settings received on the MCCH in step S13. This enables the UE100, which is in an RRC inactive state, to perform multicast reception.

[0056] A hybrid solution combining delivery mode 1-based and delivery mode 2-based solutions is also conceivable. For example, a hybrid configuration method is possible where the initial MBS (PTM) settings are set using dedicated signaling, and the MBS (PTM) settings are updated using MCCH.

[0057] (1.3) Operation according to the first embodiment Figure 8 is a diagram illustrating the overview of the operation according to the first embodiment. Figure 8(a) shows an example of a mixed configuration method that combines a delivery mode 1-based solution and a delivery mode 2-based solution as a comparative example. Figure 8(b) shows an overview of the operation according to the first embodiment.

[0058] As shown in Figure 8(a), in step S51, UE100 is in the RRC connected state. UE100 supports multicast reception in the RRC inactive state and is already participating in a multicast session.

[0059] In step S52, the gNB200 sends an RRC Reconfiguration message on the DCCH to the UE100, which is in the RRC Connected state, containing the MBS settings (PTM settings) for the multicast session. The UE100 receives the RRC Reconfiguration message and establishes a multicast MRB. At this point, the multicast session is activated.

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

[0061] In step S54, gNB200 sends an RRC Release message to UE100, which is in the RRC Connected state, to transition UE100 to the RRC Inactive state.

[0062] In step S55, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S54.

[0063] In step S56, gNB200 transmits SIB20, which includes the MCCH setting, over BCCH. UE100, in an RRC inactive state, receives SIB20.

[0064] In step S57, the gNB200 sends a PTM configuration (e.g., an MBSBroadcastConfiguration message) for the multicast session over the MCCH. The UE100, in an RRC inactive state, receives the PTM configuration on the MCCH based on the SIB20 in step S56. The UE100 establishes a new MRB in accordance with the PTM configuration. This new MRB may be a broadcast MRB.

[0065] In step S58, gNB200 transmits the multicast session over the MTCH via the new MRB. UE100, in an RRC inactive state, receives the multicast session over the MTCH.

[0066] Thus, in the comparative example shown in Figure 8(a), since UE100 transitions to an RRC inactive state (step S55) and then acquires SIB20 (step S56) and MCCH (step S57), there is a problem that service interruptions may occur due to the acquisition of SIB20 and MCCH.

[0067] In the first embodiment, as shown in Figure 8(b), the gNB200 transmits the PTM settings for the multicast session on the DCCH to the UE100, which is in the RRC connected state and has joined the multicast session (step S104). Here, if the multicast session is activated, the gNB200 transmits the PTM settings on the DCCH that include the same information elements as those provided on the MCCH. The UE100, which is in the RRC connected state and has joined the multicast session, receives the PTM settings on the DCCH (step S104). As a result, the UE100 can transition to the RRC inactive state (step S105) and then quickly receive the multicast session on the MTCH (step S106).

[0068] Specifically, as shown in Figure 8(b), in step S101, UE100 is in the RRC connected state. UE100 supports multicast reception in the RRC inactive state and is already participating in a multicast session.

[0069] In step S102, gNB200 sends an RRC Reconfiguration message on DCCH to UE100, which is in the RRC Connected state, containing the MBS settings (PTM settings) for the multicast session. UE100 receives the RRC Reconfiguration message and establishes a multicast MRB (first MRB). At this point, the multicast session is activated.

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

[0071] In step S104, gNB200 sends a PTM configuration on the DCCH (i.e., dedicated signaling) to the RRC-connected UE100 that is similar to the PTM configuration sent on the MCCH (e.g., the MBSBroadcastConfiguration message). For example, gNB200 sends an RRC Reconfiguration message or an RRC Release message containing the said PTM configuration. The RRC-connected UE100 receives the said PTM configuration on the DCCH. UE100 recognizes the received PTM configuration as configuration information for multicast reception. UE100 establishes a new MRB (second MRB) according to the said PTM configuration. This new MRB may be a broadcast MRB.

[0072] In step S105, UE100 transitions to the RRC inactive state. If step S104 is performed with an RRC Reconfiguration message, gNB200 sends an RRC Release message to transition UE100 to the RRC inactive state. UE100 transitions to the RRC inactive state upon receiving the RRC Release message.

[0073] In step S106, gNB200 transmits the multicast session over the MTCH via the new MRB (second MRB). UE100, in an RRC inactive state, receives the multicast session over the MTCH.

[0074] Furthermore, UE100 may perform predetermined processing related to switching from the first MRB to the second MRB based on the result of comparing the sequence number of the MBS packet received via the first MRB for the RRC connected state with the sequence number of the MBS packet received via the second MRB for the RRC inactive state. This makes it easier to ensure consistency of received packets between the first MRB and the second MRB.

[0075] In the first operation pattern of the first embodiment, step S104 is performed with an RRC Reconfiguration message. In this case, the predetermined process may be a process of sending a notification for the switchover (for example, a consistency notification) to the gNB200. In the second operation pattern of the first embodiment, step S104 is performed with an RRC Release message. In this case, the predetermined process may be a process of transitioning from the RRC Connected state to the RRC Inactive state.

[0076] Figure 9 shows an example of the first operation pattern of the first embodiment. Here, operations that overlap with the operations shown in Figure 8(b) are not explained.

[0077] In step S111, UE100, in the RRC connected state, is participating in a multicast session.

[0078] In step S112, the gNB200 sends the multicast MRB configuration (PTM configuration) to the UE100 in an RRC Reconfiguration message. The UE100 receives the PTM configuration and establishes the multicast MRB (first MRB). The multicast session is also activated.

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

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

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

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

[0083] The PTM settings in step S115 may include only the PTM settings for multicast sessions that UE100 is currently receiving. That is, the PTM settings in step S115 may include only the PTM settings for activated multicast sessions. Alternatively, the PTM settings in step S115 may include only the PTM settings for MBS sessions that have multicast MRB configured on UE100. The PTM settings in step S115 may not include the PTM settings for broadcast sessions. Alternatively, the PTM settings in step S115 may include only the PTM settings for multicast sessions that UE100 has already joined. That is, the PTM settings in step S115 may include only the PTM settings for multicast sessions that can be activated.

[0084] In step S116, UE100 recognizes the PTM settings received from gNB200 via DCCH as relating to a multicast session. Here, UE100 may make this recognition even if it receives PTM settings that do not include MRB settings (MRB-ToAddMod). Alternatively, UE100 may make this recognition even if it receives PTM settings that do not include an MRB identifier (MRB-Identity). UE100 may also recognize the PTM settings as settings to be used for reception in an RRC inactive state. However, UE100 may use these settings to perform multicast reception while remaining in an RRC connected state.

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

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

[0087] In step S119, the UE100 in the RRC Connected state sends a notification to the gNB200 indicating that a switchover from the first MRB to the second MRB is possible or that the switchover has been completed. The UE100 may send this notification to the gNB200 as part of a response message corresponding to the RRC Reconfiguration message in step S115 (for example, an RRC Reconfiguration Complete message). Alternatively, the UE100 may send this notification in a UE Assistance Information message. For example, the UE100 may send it as part of the Release Assistance Information (specifically, the “ReleasePreference”IE), which is an information element included in the UE Assistance Information message.

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

[0089] In step S121, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message.

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

[0091] Figure 10 shows an example of the second operation pattern of the first embodiment. Here, operations that overlap with the first operation pattern in Figure 9 are not explained.

[0092] The operation of steps S131 to S134 is the same as the operation of steps S111 to S114 in Figure 9.

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

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

[0095] The PTM settings in step S135 may include only the PTM settings for multicast sessions that UE100 is currently receiving. That is, the PTM settings in step S135 may include only the PTM settings for activated multicast sessions. Alternatively, the PTM settings in step S135 may include only the PTM settings for MBS sessions that have multicast MRB configured on UE100. The PTM settings in step S135 may not include the PTM settings for broadcast sessions.

[0096] In step S136, UE100 recognizes the PTM settings received from gNB200 via DCCH as relating to a multicast session. UE100 may also recognize these PTM settings as settings to be used for reception in an RRC inactive state. However, UE100 may also use these settings to perform multicast reception while remaining in an RRC connected state.

[0097] In step S137, the UE100 in the RRC connected state receives a multicast session from the gNB200 on the MTCH via the second MRB, based on the PTM settings in step S135. At this point, having received the RRC Release message, the UE100 postpones transitioning to the RRC inactive state.

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

[0099] In step S139, UE100, which is in the RRC connected state, transitions to the RRC inactive state.

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

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

[0102] In the first embodiment described above, an example was explained in which, when a multicast session is activated, the PTM settings used in the RRC inactive state are provided from the gNB200 to the UE100 via DCCH (Dedicated Signaling).

[0103] In contrast, in the second embodiment, when a multicast session has not yet been activated, configuration information regarding the RRC inactive state is provided to the UE100 via DCCH (Dedicated Signaling) from the gNB200. Specifically, for a multicast session in an inactive state (before activation), the gNB200 configures information regarding permission for multicast reception in the RRC inactive state to the UE100, which is in an RRC connected state, via dedicated signaling.

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

[0105] This makes it possible to streamline multicast reception even when RRC is inactive.

[0106] In the first operation pattern of the second embodiment, the configuration information includes an information element that instructs monitoring the MCCH (acquiring PTM settings from the MCCH). This information element may also be an information element that instructs monitoring the MCCH after transitioning to the RRC inactive state. The UE100 monitors the MCCH based on this information element.

[0107] In the second operation pattern of the second embodiment, the configuration information may include an information element that allows the serving cell to request an MCCH if it has not sent one. This information element may also be an information element that allows the current serving cell to request an MCCH if it has not sent one after the transition to the RRC inactive state and the multicast session has been activated. When the UE100 detects the activation of the multicast session, if the gNB200 has not provided an MCCH at the time of detection, it requests the gNB200 to provide one.

[0108] In the second embodiment, the configuration information may include an information element that prohibits the UE100 from transitioning to the RRC connected state in response to the reception of a paging message indicating the activation of a multicast session. Even if the UE100 receives a paging message from the gNB200 indicating the activation of a multicast session, it will maintain the RRC inactive state without transitioning to the RRC connected state.

[0109] Figure 11 shows an example of the first operation pattern of the second embodiment.

[0110] In step S201, UE100, in the RRC connected state, is participating in a multicast session.

[0111] In step S202, the gNB200 recognizes that the multicast session has not yet been activated (i.e., is inactive). The gNB200 can also determine whether the multicast session has been activated or not based on a message received from CN20 (AMF300A) on the NG interface (for example, a "MULTICAST SESSION ACTIVATION REQUEST" message).

[0112] In step S203, gNB200 sends configuration information regarding multicast reception in the RRC inactive state to UE100 in the RRC connected state via DCCH (i.e., via dedicated signaling). UE100 receives this configuration information via DCCH. This dedicated signaling may be an RRC Reconfiguration message or an RRC Release message.

[0113] The configuration information in step S203 may include an information element instructing UE100 to monitor the MCCH (even in the RRC connected state). Alternatively, the configuration information in step S203 may include an information element instructing UE100 to monitor the MCCH when it transitions to the RRC inactive state. The configuration information in step S203 may include the MBS session ID (e.g., TMGI) of the multicast session from which PTM settings should be obtained. UE100 may also notify gNB200 if it successfully receives the MCCH (or successfully establishes the MRB) (in the RRC connected state). UE100 may send this notification in a UE Assistance Information message. For example, it may be sent as part of the Release Assistance Information (specifically, the “ReleasePreference”IE), which is an information element included in UE Assistance Information. Alternatively, UE100 may notify gNB200 if it fails to receive the MCCH.

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

[0115] In step S204, UE100 may transition to the RRC inactive state. If step S203 is performed with an RRC Reconfiguration message, gNB200 may send an RRC Release message to transition UE100 to the RRC inactive state. UE100 may transition to the RRC inactive state upon receiving the RRC Release message.

[0116] In step S205, UE100 in either the RRC inactive or RRC connected state starts monitoring the MCCH based on the configuration information from step S203.

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

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

[0119] Figure 12 shows an example of the second operation pattern of the second embodiment. Here, operations that overlap with the first operation pattern shown in Figure 11 are not explained. Note that this second operation pattern may be implemented in combination with the first operation pattern shown in Figure 11.

[0120] In step S231, UE100 is in an RRC connected state and has joined a multicast session.

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

[0122] In step S233, gNB200 transmits configuration information regarding multicast reception in the RRC inactive state to UE100 in the RRC connected state via DCCH. UE100 receives this configuration information via DCCH. This configuration information may include an information element instructing UE100 to obtain PTM settings from MCCH. This configuration information may also include an information element allowing UE100 to make a request to MCCH.

[0123] In step S234, gNB200 may transition UE100 to the RRC inactive state with an RRC Release message. UE100, having transitioned to the RRC inactive state, may re-select a cell different from the one configured in step S233.

[0124] In step S235, UE100, which is in an RRC inactive or RRC connected state, recognizes the activation timing, which is the timing when the multicast session is started (activated). The activation timing may be when UE100 receives group paging from gNB200, which includes the MBS session ID of the multicast session. The activation timing may be when UE100 receives an MCCH Change Notification from gNB200 and the PTM settings for the multicast session are added. The activation timing may also be when the start time of the multicast session is determined from the USD (User Service Description) information that UE100 has previously stored.

[0125] In step S236, UE100, which is in an RRC inactive or RRC connected state, starts monitoring the MCCH in response to recognizing the activation timing.

[0126] Here, if MCCH is not broadcast from gNB200 (the current serving cell) (step S237: YES), in step S238, UE100 in the RRC inactive or RRC connected state sends an MCCH request to gNB200. UE100 may send the MCCH request in the random access procedure messages Msg1, Msg3, or Msg5. UE100 may also send the MCCH request in the MBS Interest Indication message or the UE Assistance information message.

[0127] In step S239, gNB200 sends the PTM settings for the multicast session over the MCCH. Here, gNB200 may start broadcasting on the MCCH. Alternatively, gNB200 may send the MCCH contents (PTM settings) to the UE100 in the RRC connected state using an RRC Reconfiguration message. Alternatively, gNB200 may send the MCCH contents (PTM settings) to the UE100 using an RRC Release message. For example, the UE100 may request the MCCH contents (PTM settings) from gNB200 in a random access procedure Msg3 (RRC Resume message), and in response to Msg3, gNB200 may send the MCCH contents (PTM settings) to the UE100 using an RRC Release message.

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

[0129] (3) Other embodiments In the above embodiment, an example was described in which the gNB200 broadcasts the SIB20 and MCCH in distribution mode 2. Figure 13 is a diagram illustrating an example of operation when distribution mode 2 is applied to MBS multicast. When distribution mode 2 is applied to MBS multicast, the following procedure is possible. Specifically, firstly, the gNB200 sends the SIB20, which includes the MCCH settings (specifically, the MCCH scheduling information, etc.), to the UE100 (UE100a to 100c in the illustrated example) on the broadcast control channel (BCCH). Figure 14 shows the configuration of the SIB20 as defined in the 3GPP Release 17 RRC specification (TS38.331). The SIB20 includes the MCCH settings, mcch-Config-r17. Secondly, the gNB200 sends the PTM settings (MTCH settings) to the UE100 on the MCCH. Thirdly, the gNB200 sends a multicast session (specifically, multicast PTM data) to the UE100 via the MTCH.

[0130] Here, since SIB20 and MCCH transmissions are broadcast, all UE100s in the cell to which SIB20 and MCCH are transmitted can receive the multicast session. However, MBS multicast should only be received by a specific set of UEs participating in the multicast session. Therefore, the fact that the multicast PTM settings (i.e., MCCH) can be obtained by all UE100s raises security concerns. In other embodiments, an operation (communication method) that enables proper multicast distribution using MCCH will be described.

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

[0132] In a communication method according to another embodiment, firstly, the gNB200 transmits scheduling information (MCCH setting) for the MCCH that transmits the PTM settings for the multicast session to the UE100 (UE100a in the illustrated example) in an RRC connected state, using dedicated signaling (e.g., DCCH). The UE100 receives the MCCH scheduling information (MCCH setting). Here, the MCCH scheduling information (MCCH setting) is scheduling information for the multicast session MCCH that transmits the PTM settings for the multicast session. The multicast session MCCH is a different MCCH from the broadcast session MCCH that transmits the PTM settings for the broadcast session.

[0133] Secondly, gNB200 transmits the MCCH for the multicast session. gNB200 may transmit the MCCH for the multicast session on a different schedule (e.g., time and frequency resources) than the MCCH for the broadcast session. UE100 (UE100a in the illustrated example) receives the MCCH for the multicast session. At this time, UE100 may be in the RRC connected state, the RRC inactive state, or the RRC idle state.

[0134] Thirdly, the gNB200 transmits a multicast session (multicast MBS data) over the MTCH. The UE100 (UE100a in the illustrated example) receives the multicast session. At this time, the UE100 may be in the RRC connected state, the RRC inactive state, or the RRC idle state.

[0135] Thus, in another embodiment, the MCCH configuration for the multicast session is provided to the UE100 via dedicated signaling. This allows the multicast session MCCH configuration to be provided only to a specific UE100 (or a specific set of UE100s). Therefore, even when using MCCH, it becomes easy for only the specific UE100 (or a specific set of UE100s) participating in the multicast session to receive that multicast session.

[0136] In the embodiments described above, multicast reception in the RRC inactive state was mainly explained, but the operation according to the embodiments described above may also be applied to multicast reception in the RRC idle state. In the case of the RRC idle state, the above-described RRC resume is read as RRC establishment.

[0137] Each of the above-described operation flows can be performed not only independently, but also in combination of two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow. It is not necessary to execute all steps in each flow; only some steps may be executed.

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

[0139] Furthermore, 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). Additionally, a network node may consist of a combination of at least a part of the core network device and at least a part of a base station.

[0140] A program may be provided that causes a computer to execute each process performed by the UE100, gNB200, or relay device. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE100, gNB200, or relay device may be integrated, and at least a part of the UE100, gNB200, or relay device may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0141] The functions realized by UE100, gNB200 (network node), or relay device may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, and means are hardware programmed to realize or perform the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or perform the described functions. If such hardware is a processor that is considered to be of the type of circuitry, such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0142] The phrases “based on” and “depending on / in response to” used in this disclosure do not mean “based solely on” or “depending solely on” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending on” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that only the listed items are included; they mean that only the listed items may be included, or that additional items may be included in addition to the listed items. Furthermore, the term “or” used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated by the context that they are not.

[0143] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0144] This application claims priority to U.S. Provisional Application No. 63 / 443083 (filed February 3, 2023), the entirety of which is incorporated into the specification of this application.

[0145] (4) Note The following are additional notes regarding the distinctive features of the above-described embodiment.

[0146] (Note 1) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The user device, which is in a Radio Resource Control (RRC) connected state and has joined a multicast session, has the step of receiving a point-to-multipoint (PTM) configuration for the multicast session from a base station on a dedicated control channel (DCCH), The receiving step includes, if the multicast session is activated, receiving the PTM configuration from the base station on the DCCH, which includes the same information elements as those provided on the multicast control channel (MCCH). Communication method.

[0147] (Note 2) The user device further includes the step of recognizing the received PTM configuration information as configuration information for multicast reception. The communication method described in Appendix 1.

[0148] (Note 3) The user device receives the multicast session via the first multicast radio bearer (MRB), The user device establishes a second MRB that is different from the first MRB based on the PTM settings, The user device further includes the step of performing predetermined processing related to switching from the first MRB to the second MRB, based on the result of comparing the sequence number of an MBS packet received via the first MRB with the sequence number of an MBS packet received via the second MRB. The communication method described in Appendix 1 or 2.

[0149] (Note 4) The step of receiving the PTM setting includes the step of receiving an RRC reconfiguration message containing the PTM setting, The step of performing the predetermined processing includes the step of transmitting a notification for the switching to the base station. The communication method described in Appendix 3.

[0150] (Note 5) The step of receiving the PTM setting includes the step of receiving an RRC release message containing the PTM setting, The step of performing the predetermined processing includes a step of transitioning from the RRC connected state to the RRC inactive state. The communication method described in Appendix 3.

[0151] (Note 6) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The user device, which is in a Radio Resource Control (RRC) connected state and has joined a multicast session, has a step of receiving configuration information from a base station on a Dedicated Control Channel (DCCH), The receiving step includes, if the multicast session has not yet been activated, receiving configuration information from the base station regarding permission for multicast reception in an RRC inactive state. Communication method.

[0152] (Note 7) The aforementioned configuration information includes information elements that instruct monitoring of the multicast control channel (MCCH), The user device further includes the step of monitoring the MCCH based on the information element. The communication method described in Appendix 6.

[0153] (Note 8) The configuration information includes an information element that allows the user device to request the base station to provide a multicast control channel (MCCH), The user device detects the activation of the multicast session, The user device further includes the step of requesting the base station to provide the MCCH if the MCCH is not provided by the base station at the time of the detection. The communication method described in Appendix 6 or 7.

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

[0155] (5) Note 1. Introduction The work items related to enhancing MBS (eMBS) aim to support multicast reception by the UE when inactive, as follows: [RAN2, RAN3] specifies support for multicast reception by the UE when the RRC is inactive. PTM settings for a UE receiving multicast in RRC inactive state [RAN2] Investigation of the impact of mobility and state transitions on UEs receiving multicast in RRC inactive (seamless / lossless mobility is not required) [RAN2, RAN3]

[0156] RAN2 has discussed this objective and reached a series of agreements. Based on these agreements, the PTM settings and mobility configurations for multicast reception in inactive mode will be discussed in this appendix.

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

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

[0159] Regarding the distribution of PTM settings, RAN2 is also considering the following solutions. Option 1: Dedicated signaling Option 2: Solution based on SIB+MCCH This does not exclude the option of "mixing".

[0160] RAN2#120 has reached an agreement to move forward with a "mixed approach". We have a mixed approach and begin as follows: 1. If the network configures a UE to continue receiving multicast while in an inactive state, the network will provide PTM configuration for the activated multicast session via RRC-dedicated signaling, at least for the serving cell (further consideration is needed for other cases). 2. MCCH is used when the PTM settings need to be changed or when the PTM settings need to be indicated during a transition beyond the serving cell / gNB. Further consideration is needed regarding session state changes and other instructions. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0161] In accordance with Agreement #1 above, the network configures the PTM setting for the activated multicast session on the UE via dedicated signaling. Since the multicast session is activated, the connected UE is already receiving the multicast session, and this PTM setting is assumed to allow it to continue receiving the multicast session even after the UE transitions to inactive.

[0162] In this disclosure, the "mixed approach" agreed upon by RAN2 means using MCCH for updating PTM settings, etc., and is therefore similar to Rel-17's delivery mode 2. In this sense, dedicated signaling will only provide MCCH content (such as MBS Broadcast Configuration) and not Rel-17-specific multicast settings (such as mrb-ToAddModList). Such dedicated signaling is useful in avoiding the UE monitoring MCCH in Connected mode and minimizing service interruptions due to delays in MCCH acquisition after transitioning to inactive mode.

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

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

[0165] In Rel-18, multicast reception for an inactive UE supports at least the following scenarios, assuming the UE already has a valid PTM configuration: -Scenario 1: The UE is connected and receiving multicast, enters inactive mode, and continues to receive multicast. -Scenario 2: The UE joins a multicast session, is redirected to inactive, and then begins receiving the multicast session. Further consideration is needed regarding state changes, such as state changes caused by services not being provided in an inactive state.

[0166] It is believed that the actual PTM configuration cannot be provided to an inactive multicast session, but once the multicast session is activated, it is provided. In Rel-17, an inactive UE transitions to connected when it receives group paging for the activation of a multicast session. Therefore, some kind of instruction may be provided in advance via dedicated signaling so that the UE can use the PTM configuration obtained from the MCCH for the multicast session while remaining inactive. Another approach is that such instruction is provided by group paging, as discussed in the following section.

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

[0168] Agreement #2 above states that MCCH is used when the PTM settings need to be changed or when the PTM settings need to be displayed during a transition beyond a serving cell / gNB. The use of MCCH for session status changes and other instructions is somewhat ambiguous. That is, it's unclear whether MCCH is used for instructions or for providing PTM settings. If it's just instructions, it could mean MCCH Change Notification. However, MCCH does provide PTM settings, for example, updating the PTM settings configuration of an inactive UE.

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

[0170] RAN2 leaves as a matter to consider whether the MCCH configuration is initially provided to the UE via dedicated signaling. The MCCH configuration refers to SIB20. As agreed by RAN2, since dedicated signaling is inactive and provides the PTM configuration for multicast reception, the UE does not need to read the MCCH immediately, and therefore does not need to know what SIB20, i.e., the MCCH configuration, is. Naturally, the UE will later retrieve the SIB20 and MCCH and check whether the PTM configuration has been updated.

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

[0172] 2.2.UE Mobility and Service Continuity RAN2#120 agreed that MCCH would be used during UE transitions. This disclosure has a mixed approach and begins as follows: 1. If the network configures the UE to continue receiving multicast in an inactive state, the network provides PTM settings for the activated multicast session via RRC-dedicated signaling to at least the serving cell (other cases require further consideration). 2. MCCH is used when PTM settings need to be changed or when PTM settings need to be instructed during transitions beyond the serving cell / gNB. Further consideration is needed regarding session state changes and other instructions. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0173] WID states that seamless / lossless mobility is not necessary. [RAN2, RAN3] specifies support for multicast reception by the UE when the RRC is inactive. PTM settings for a UE receiving multicast in RRC inactive state [RAN2] Investigate the impact of UE mobility and state transitions on multicast receiving in RRC inactive (seamless / lossless mobility is not required) [RAN2, RAN3]

[0174] As described in Section 2.1, the distribution method for the new PTM configuration is similar to distribution mode 2 of Rel-17. Therefore, it is natural to base it on the Rel-17 MBS broadcast continuity mechanism. In this case, the multicast session must first be provided with neighbor cell information from the MCCH and ensure that the UE is allowed to prioritize the MBS frequency when reselecting a cell.

[0175] As is expected with LTE SC-PTM and NR MBS broadcast, how service continuity is ensured depends on the UE implementation. For example, how adjacent cell information is used, whether MBS frequencies are prioritized, and how / when MCCH is obtained from adjacent cells are all at the discretion of the UE implementation.

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

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

[0178] Some companies propose enabling PTM settings across multiple cells to improve service continuity during UE transitions. Within a gNB, it's easy to synchronize PTM settings for each cell (if necessary), but this is more difficult between gNBs and requires negotiation involving Xn-AP. This small enhancement is unlikely to cause any harm even if it's limited to within a gNB. Therefore, RAN2 needs to discuss whether PTM settings can be applied to multiple cells within a gNB.

[0179] Proposal 7: RAN2 should consider whether the PTM configuration is applicable to multiple cells within a gNB. In this case, the gNB scenario would be the basic assumption.

[0180] Another consideration is network-based QoS control. While WID does not require seamless / lossless mobility, this does not mean that all multicast sessions that a UE can receive while inactive do not require seamless / lossless mobility. For example, congestion may necessitate the network transitioning the UE to inactive, but QoS requirements may necessitate the UE transitioning after being connected. For seamless / lossless mobility, Rel-17MBS multicast supports handover in RRC connections. Therefore, the network may need an option to control whether to have the UE perform cell reselection or to resume the RRC connection before cell reselection (in the case of connected handover).

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

[0182] (6) Addendum 1. Introduction The work items related to strengthening MBS (eMBS) are as follows: Identify support for multicast reception by the UE in the RRC inactive state [RAN2, AN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] This study investigates the impact of mobility and state transitions on UEs receiving multicast in RRC inactive states (seamless / lossless mobility is not required) [RAN2, RAN3].

[0183] Based on these agreements, the notification and RRC state transition behaviors in multicast reception in an inactive state are discussed in this appendix.

[0184] 2. Discussion In RAN2#119e, aspects related to changes in the RRC state remain as matters requiring further investigation. In Rel-18, multicast reception to an inactive UE supports at least the following scenarios, assuming the UE already has a valid PTM configuration: -Scenario 1: The UE is receiving connected multicast, enters an inactive state, and continues receiving multicast. Scenario 2: The UE joins a multicast session, is directed to be inactive, and begins receiving the multicast session. Further consideration is needed regarding changes in state, such as changes due to services not being provided when the system is inactive.

[0185] From a network and UE perspective, several cases related to RRC state changes are possible. Some of these cases also relate to notifications sent from the network to the UE. Therefore, the following cases should be considered:

[0186] 2.1. Case 1: Inactive / Released Multicast Session When a multicast session is inactive, the agreed-upon RAN2#119bis-e is notified to the UE, and the Rel-17 mechanism can be applied when the multicast session is released. If a UE is in RRC inactive and configured to receive multicast sessions in RRC inactive, the UE may be notified when the multicast session is deactivated. Further consideration is needed regarding notification via, for example, group paging, MCCH, or other methods. The Rel-17 mechanism (NAS-based instruction) is applicable for multicast session release. Further consideration will be given as needed.

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

[0188] Finding 1: It is inefficient from a power consumption standpoint for the UE to continue monitoring PTM / MTCH after a multicast session has been stopped or released.

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

[0190] Proposal 1: RAN2 should agree that when it receives a multicast session termination notice, the UE should be allowed to stop monitoring the MTCH.

[0191] Regarding the termination of multicast sessions, RAN2 states that further consideration is needed for methods of notifying the UE, such as group paging, MCCH, or other methods.

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

[0193] Another option is to reuse group paging. Group paging is used to page multiple UEs within a group simultaneously, using TMGI instead of UE-ID. Since the existing paging group list (i.e., the list of TMGIs) can also be applied to legacy UEs, group paging requires adding a new TMGI list for deactivation notifications to avoid impacting legacy UEs. This means there will be a delay between the last multicast data reception and the cessation of MTCH monitoring, based on the I-DRX cycle.

[0194] A third option is to reuse the MCCH. There are two possible ways to notify of multicast session inactivation: either remove the PTM setting for the inactivated TMGI, or add a new indicator to notify of the inactivated TMGI. In either case, the MCCH needs to be updated, so an MCCH change notification must be sent to the UE in advance. This requires a longer delay between receiving the last multicast data and stopping the MCCH monitor.

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

[0196] In summary, the delay between receiving the last multicast data and stopping the MTCH monitor can directly impact the unnecessary increase in UE power consumption. From a UE power saving perspective, notifications need to be sent as quickly as possible, making MAC CE the preferred first choice and solution.

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

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

[0199] However, if a new MAC CE is introduced for multicast session invalidation notifications as in Proposal 2 for optimization purposes, this procedure can be used free of charge. That is, the gNB sends a MAC CE to allow the UE to stop monitoring the MTCH, and then the gNB can distribute the page timing to the UE, i.e., use legacy individual paging, to avoid the signaling storm caused by simultaneously transitioning to the RRC state.

[0200] Proposal 3: RAN2 should agree that no functional enhancements specifically for multicast session release are necessary; in other words, UEs should transition to RRC Connected via existing (group) paging.

[0201] 2.2. Case 2: Selective transitions when a multicast session is active RAN2#119e reached the following agreement regarding Case 2: The gNB is responsible for determining whether a multicast session can be received in an inactive state by the UE. Further consideration is needed regarding what information should be provided to the gNB to make such a decision (related to the SA2 discussion). gNB supports sending a single multicast session to both connected and inactive UEs within the same cell. Further investigation is needed to determine how gNB configures this. The network assumes that UEs can choose which UEs receive in RRC inactive and which receive in RRC connected, and that UEs can transition between states to receive multicast services.

[0202] When releasing a UE inactively, gNB can select which UE to release based on the UE's capabilities, UE assistance information, and / or CN assistance information (if specified), as it does now, i.e., via RRC Release with Suspend Config. Therefore, no enhancements regarding selective UE transitions are anticipated for RRC release messages.

[0203] Finding 2: Existing RRC releases are used by gNB to select which UE to release.

[0204] Regarding the activation of multicast sessions, RAN2#119bis-e agreed on the following: When a Rel-18 session becomes active, it can notify inactive UEs (further investigation is needed for details). As a baseline, group paging can be used to notify the Rel-18 UE of session activation (further investigation is needed regarding details, such as how the UE behaves when it receives such a group notification). When a session is activated, the method for determining whether the UE can trust a multicast session with RRC inactive will be decided after further consideration, taking into account the following solutions (the description may be further updated as needed, and multiple solutions may be required). 1. When a multicast session is activated, the UE can receive the multicast session in RRC Inactive if the PTM configuration used for the session in RRC Inactive is available to the UE and the UE is already participating in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), but otherwise it will return to RRC Connected to receive the multicast session. 2. When a multicast session becomes active, the UE will be indicated by group paging whether it can receive the multicast session with RRC inactive (further consideration is needed regarding detailed signaling). 3. Before the UE is released, it is configured via dedicated signaling to determine whether it can receive multicast sessions while RRC is inactive. When a multicast session becomes active, the UE either remains RRC inactive or reactivates RRC Connected accordingly (further consideration is needed regarding the detailed signaling).

[0205] In Rel-17, multicast session activation is notified by group paging. In Rel-18, there is no need to differ from the legacy mechanism, so RAN2 needs to use group paging to ensure that multicast session activation is notified to the UE.

[0206] Proposal 4: RAN2 should be able to use group paging to notify the Rel-18 UE of session activation.

[0207] In addition to verification, RAN2, as mentioned above, specifies three options for how the UE should behave upon receiving a multicast activation notification.

[0208] In Option 1, a UE can receive multicast sessions even in an inactive state if it has a valid PTM configuration. Since an inactive UE cannot receive multicast sessions without a PTM configuration, this can be considered the baseline behavior for all other UEs. Therefore, we should agree on Option 1.

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

[0210] In option 2, when the UE receives group paging, it is indicated whether it should receive the multicast session inactive.

[0211] In option 3, the UE is given prior indication as to whether it should receive the multicast session inactive by reconfiguring or releasing the RRC.

[0212] The mechanisms of these two options are very similar, except for the message that instructs the UE to do so. Therefore, these options can be analyzed in terms of the motivation for inactive multicast reception, namely network congestion and UE power saving.

[0213] In the case of network congestion, it can be assumed that the cell load changes moment by moment. In option 2, since instructions are sent within group paging, the gNB can consider the latest load state when deciding whether the UE should remain inactive. On the other hand, in option 3, the gNB needs to predict the future load when notifying the UE, and the cell load may have changed by the time the gNB actually sends the group paging. Therefore, there is a risk that congestion will worsen and more UEs will transition to connected, or that even if the congestion is resolved, more UEs will remain inactive. For this reason, option 2 is preferable for efficiently controlling the RRC state of UEs.

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

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

[0216] Proposal 6: RAN2 should agree to UE operation option 2: "When a multicast session becomes active, the UE will be indicated by group paging whether it can receive the multicast session with RRC inactive (further consideration is needed regarding detailed signaling)."

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

[0218] Finding 3: In other words, if the paging message contains a TMGI of interest, all UEs will transition to RRC Connected.

[0219] Assuming the current paging group list is set for group paging messages and paging at least Rel-17 UEs, Rel-18 UEs will also be paged by any TMGI of interest. Therefore, one might consider defining a new list of UE-IDs, the "paging cancellation list" (or "inactive permission list"), to prevent selected UEs from transitioning to connected, and ensuring that UEs listed on this list remain inactive in order to receive multicast sessions.

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

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

[0222] 2.3. Case 3: QoS Enforcement RAN2#119e reached the following agreement relating to Case 3: HARQ feedback and PTP are not supported for multicast reception with RRC inactive.

[0223] According to the agreement, inactive multicast reception is similar to MBS broadcast reception (so-called distribution mode 2) as defined in Rel-17. MBS broadcast is best-effort.

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

[0225] RAN2#119e proposes introducing receive quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. It is also useful for the network to manage QoS requests. If inactive multicast reception fails to meet the corresponding QoS requirements, the UE must transition to connected mode and guarantee receive quality using HARQ feedback / retransmission and / or PTP (or split MRB).

[0226] Finding 4: Multicast sessions should maintain certain QoS requirements even when the UE is inactive.

[0227] Regarding RSRP thresholds, since NR MBS is assumed to be a single-cell transmission method, it is thought that the system must always transition to connected mode whenever the UE moves to the cell edge or performs cell reselection. This may not be optimal operation depending on the deployment, considering network congestion and UE power saving.

[0228] Regarding the BLER threshold, it is considered simpler in order to ensure QoS requirements. Therefore, if RRC state transitions based on receive quality are to be introduced, these options should be discussed.

[0229] Proposal 8: RAN2 should agree that if the reception quality falls below a threshold (e.g., RSRP or BLER), an inactive UE should transition to connected.

[0230] 2.4. Case 4: Updating PTM settings RAN2 agreed to the following as prerequisites for its work: This disclosure has a mixed approach and begins as follows: 1. If the network configures the UE to continue receiving multicast in an inactive state, the network provides PTM settings for the activated multicast session via RRC-dedicated signaling to at least the serving cell (other cases require further consideration). 2. MCCH is used when the PTM settings need to be changed or when the PTM settings need to be displayed during transitions beyond the serving cell / gNB. Further consideration is needed for changes to the session status and other displays. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0231] In other words, the UE can remain inactive in order to retrieve the updated PTM settings. Therefore, from the perspective of an inactive UE, the method of delivering new PTM settings is similar to Rel-17's delivery mode 2. In this case, it is very easy to reuse existing MCCH change notifications to notify of PTM setting updates. Therefore, no additional notifications are needed for PTM setting updates in an inactive UE.

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

[0233] 2.5. Case 5: Service continuity upon RRC resumption It is conceivable that a UE already receiving a multicast session via an inactive method (such as a broadcast MRB) may be paged, initiating the RRC resume procedure. After transitioning to Connected, the UE would naturally want to continue receiving the multicast session. However, in this case, the UE would have both a broadcast MRB and a resumed multicast MRB for the same multicast session. In Rel-17, multicast sessions are only permitted to be received via the multicast MRB configured during RRC reconfiguration. On the other hand, in Rel-18, receiving multicast sessions via the broadcast MRB configured in MCCH may be permitted. The UE should use the multicast MRB for reception after transitioning to Connected. However, it is unclear (i.e., in terms of the lossless principle) how the UE switches between these MRBs, when the UE discards the broadcast MRB, and what the UE should do if the multicast MRB is an AM MRB. Therefore, RAN2 needs to discuss the UE's behavior during RRC resumption from the perspective of MRB processing and the continuity of multicast session service.

[0234] Proposal 10: RAN2 should discuss the behavior of the UE when RRC is resumed during continuous reception of a multicast session (such as the handling of broadcast MRB and multicast MRB). [Explanation of symbols]

[0235] 1: Mobile communication systems 5: Network 10: RAN 20:CN 100: UE (User Device) 110: Receiving unit 120: Transmitter 130: Control Unit 200:gNB (base station) 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department

Claims

1. A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), A user device in a Radio Resource Control (RRC) connected state receives an RRC release message from a network node on a dedicated control channel (DCCH) that includes a point-to-multipoint (PTM) setting for receiving a multicast session in an RRC inactive state, The user device transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC release message, The user device in the RRC inactive state receives the multicast session, The user device receives the RRC release message, which includes the PTM settings, which include the same information elements as those provided on the multicast control channel (MCCH). The user device monitors the MCCH based on the receipt of the RRC release message, which includes the PTM setting. Communication method.

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

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

4. The aforementioned PTM setting includes a list of DRX settings. The communication method according to claim 1.

5. The PTM setting includes parameters for obtaining the PDSCH for the MTCH. The communication method according to claim 1.

6. The PTM setting is a setting relating to a multicast session being received by the user device while it is in the RRC connected state. The communication method according to claim 1.

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

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

9. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), When the user device is in a Radio Resource Control (RRC) connected state, the receiving unit receives an RRC release message from a network node on a dedicated control channel (DCCH) that includes a point-to-multipoint (PTM) setting for receiving multicast sessions in an RRC inactive state, The user device includes a control unit that, in response to receiving the RRC release message, transitions from the RRC connected state to the RRC inactive state. The receiving unit receives the multicast session when the user device is in the RRC inactive state. The receiving unit receives the RRC release message, which includes the PTM settings, which include the same information elements as those provided on the multicast control channel (MCCH). The control unit monitors the MCCH based on the reception of the RRC release message, which includes the PTM setting. User device.

10. Cause the user device to execute the communication method described in claim 1. Processor.

11. Cause the user device to execute the communication method described in claim 1. program.

12. The user device according to claim 9 and a network node are provided. Mobile communication system.

Images