Communication methods, user devices, programs, chipsets and systems

Abstract

This invention provides a method for a user equipment (UE) in a Radio Resource Control (RRC) inactive state to receive multicast in a mobile communication system that provides multicast / broadcast services (MBS). [Solution] The method involves a UE receiving an RRC release message from a network node that includes information to be notified when a multicast session is deactivated, causing the UE to transition to an RRC inactive state. The UE then stops the predetermined processing for multicast session reception and, upon receiving a paging message containing the session identifier, receives a multicast control channel (MCCH) that transmits configuration information used for multicast session reception in the RRC inactive state. Even if multicast session reception in the RRC inactive state is configured, the UE sends an RRC connection restart request message upon receiving a paging message.

Description

Technical Field

[0001] The present disclosure relates to a communication method, a user device, a program, a chipset, and a system used in a mobile communication system.

Background Art

[0002] In 3GPP (3rd Generation Partnership Project), the technical specifications of NR (New Radio), which is a 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 a 4th generation (4G) radio access technology. In 3GPP, the technical specifications of 5G / NR multicast / broadcast services (MBS) are defined.

[0003] In 3GPP Release 17, reception of MBS multicast (i.e., multicast reception) is only possible for user devices 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 devices 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] The first aspect of the communication method is a communication method performed by a user device in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes receiving an RRC release message from a network node that includes information notified when a multicast session is deactivated and causes the user device to transition to a radio resource control (RRC) inactive state; stopping the execution of predetermined processing for receiving the multicast session based on the information; and receiving a multicast control channel (MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state in response to receiving a paging message that includes the session identifier of the multicast session.

[0006] The second aspect of the communication method is a method executed by a user device in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes configuration information used for receiving a multicast session in a radio resource control (RRC) inactive state, and comprises the steps of: receiving an RRC release message from a network node that causes the user device to transition to an RRC inactive state; checking whether the multicast session is activated; and, if the multicast session is not activated, postponing the execution of a predetermined process for starting to receive the multicast session.

[0007] A third aspect of the communication method is a method executed by a network node in a mobile communication system that provides multicast / broadcast services (MBS). The communication method includes configuration information used for receiving a multicast session in a radio resource control (RRC) inactive state, and includes the step of sending an RRC release message to a user device in an RRC connected state, which causes the user device to transition to an RRC inactive state. The RRC release message includes session state information indicating whether or not the multicast session is activated.

[0008] The user device according to the fourth embodiment is a user device used in a mobile communication system that provides multicast / broadcast services (MBS). The user device includes configuration information used for receiving multicast sessions in a radio resource control (RRC) inactive state, and includes a control unit that performs the following: receiving an RRC release message from a network node that causes the user device to transition to an RRC inactive state; checking whether the multicast session is activated or not; and, if the multicast session is not activated, suspending the execution of a predetermined process for starting to receive the multicast session.

[0009] The network node according to the fifth embodiment is a network node used in a mobile communication system that provides multicast / broadcast services (MBS). The network node includes configuration information used for receiving multicast sessions in a radio resource control (RRC) inactive state, and includes a transmitting unit that transmits an RRC release message to a user device in an RRC connected state, which causes the user device to transition to an RRC inactive state. The RRC release message includes session status information indicating whether or not the multicast session is activated. [Brief explanation of the drawing]

[0010] [Figure 1]This is a diagram showing an example configuration of a mobile communication system according to the embodiment. [Figure 2] This figure shows an example configuration of a UE (User Equipment) according to the embodiment. [Figure 3] This figure shows an example configuration of a 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 an overview of the operation of the UE related to the first operational example of the embodiment. [Figure 7] This figure shows an example of the operation sequence of a mobile communication system according to the first operational example of the embodiment. [Figure 8] This figure shows an example of specification change 1 according to the embodiment. [Figure 9] This figure shows an example of specification change 2 according to the embodiment. [Figure 10] This figure shows an overview of the operation of the UE according to the second operational example of the embodiment. [Figure 11] This figure shows an example of the operation sequence of a mobile communication system according to a second operational example of the embodiment. [Figure 12] This diagram shows the initial setup procedures for an ongoing session (left) and a stopped session (right). [Modes for carrying out the invention]

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

[0012] (1) Example of system configuration Figure 1 shows an example 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.

[0013] 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 of the mobile communication system 1.

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

[0015] NG-RAN10 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").

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

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

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

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

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

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

[0022] Figure 3 shows an example configuration of a gNB200 (base station) according to an 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.

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

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

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

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

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

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

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

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

[0031] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.

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

[0033] 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, the SDAP is not required.

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

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

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

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

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

[0039] (2.1) MBS Broadcast 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. Broadcast communication services are delivered to the UE100s using broadcast sessions, which are a type of MBS session. UE100s can receive broadcast sessions regardless of whether they are in the RRC idle, RRC inactive, or RRC connected state.

[0040] Broadcast communication services utilize Point-to-Multipoint (PTM) distribution. In PTM transmission, the gNB200 distributes a single copy of an MBS packet to a set (group) of multiple UE100s. For example, the gNB200 schedules a group-common PDSCH, which has a Cyclic Redundancy Code (CRC) scrambled by a Group-Common RNTI (G-RNTI), using a group-common PDCCH.

[0041] For broadcast communication services, UE100 receives a broadcast session in the following steps: First, UE100 receives a System Information Block Type 20 (SIB20) from gNB200. SIB20 contains the settings for a Multicast Control Channel (MCCH), which is a type of logical channel. Second, based on SIB20, UE100 receives the MCCH from gNB200. The MCCH contains the PTM settings. The PTM settings transmit settings for a Multicast Traffic Channel (MTCH), which is a type of logical channel (MTCH settings), and settings for a Broadcast MRB, which is a Multicast Radio Bearer (MRB) for the broadcast session. The information transmitted by the MCCH is sometimes referred to as MBS broadcast control information. Third, based on the MCCH, UE100 receives the MTCH. The MTCH transmits the broadcast session (specifically, the MBS data belonging to the broadcast session).

[0042] MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 10 to UE100. MTCH is a PTM downlink channel for transmitting MBS data for either a multicast session or a broadcast session from network 10 to UE100.

[0043] (2.2) MBS Multicast In the case of multicast communication services (also known 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 a 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.

[0044] UE100 can only receive multicast sessions after it has joined the multicast session. Joining a multicast session may mean that UE100 is registered with network 5 (CN20) as a device capable of receiving the multicast session.

[0045] For multicast communication services, 3GPP Release 17 allows only UE100s in an RRC connected state to receive multicast sessions. However, 3GPP Release 18 is planned to extend this so that UE100s in an RRC inactive state can also receive multicast sessions.

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

[0047] In the case of a multicast communication service, a UE100 in the RRC connected state receives a multicast session in the following procedure. First, the UE100 receives an RRC Reconfiguration message from the gNB200. The RRC Reconfiguration message is transmitted on the Dedicated Control Channel (DCCH). The RRC Reconfiguration message transmits the settings for the MTCH for receiving the multicast session (MTCH settings) and the settings for the multicast MRB, which is the MRB for that multicast session. Second, the UE100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0048] (2.2.2) Multicast reception in RRC inactive state A UE100 in an RRC inactive state can receive multicast sessions (specifically, MBS data belonging to multicast sessions) using the PTM distribution mechanism.

[0049] In the case of a multicast communication service, a UE100 in an RRC inactive state can receive a multicast session in the following manner. First, the UE100 in an RRC inactive state receives a newly introduced system information block (also called the "new SIB") from the gNB200. The new SIB includes the configuration of a newly introduced MCCH (also called the "multicast MCCH"). Second, the UE100 in an RRC inactive state receives the multicast MCCH from the gNB200 based on the new SIB. The multicast MCCH includes the PTM configuration. The PTM configuration transmits the configuration for the MTCH for multicast session reception (MTCH configuration) and the configuration of the multicast MRB, which is the MRB for multicast sessions. Third, the UE100 in an RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0050] If the gNB200 configures the UE100 to receive multicast in an RRC inactive state, it can send the PTM configuration to the UE100 using an RRC Release message that includes the suspend configuration. In this case, when the UE100 receives the RRC Release message containing the PTM configuration from the gNB200, it transitions to the RRC inactive state and receives multicast sessions in the RRC inactive state.

[0051] (2.2.3) Group Notifications If there is temporarily no data to send to UE100 in an active multicast session, gNB200 may transition UE100 to the RRC inactive state. When the multicast session is deactivated, gNB200 may transition UE100 to the RRC idle state or the RRC inactive state.

[0052] A gNB200 that supports MBS will use the group notification mechanism to notify UE100s that are in an RRC idle or RRC inactive state when a multicast session is activated by CN20. For example, a gNB200 that supports MBS may use the group notification mechanism to notify UE100s that are in an RRC inactive state if a multicast session has been activated and there is multicast session data to be distributed on the gNB200.

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

[0054] The group notification paging message includes a session identifier (MBS session ID) used to page all UE100s in the RRC idle and RRC inactive states that are participating in the associated MBS multicast session. In other words, UE100s are not paged individually.

[0055] When UE100 transitions to the RRC Connected state, UE100 may stop monitoring group notifications associated with a particular multicast session. In other words, UE100 stops checking for the MBS session ID in paging messages. UE100 does not monitor group notifications if UE100 leaves the multicast session, network 5 requests UE100 to leave, or network 5 releases the multicast session.

[0056] Group notifications may be made via MCCH or via MCCH Change Notification. When using MCCH, the determination may be made based on whether or not the MCCH setting for the MBS session of interest exists in MCCH. When using MCCH Change Notification, the group notification may be notified in a predetermined bit of DCI.

[0057] (3) First example of operation The following describes a first operational example regarding multicast reception in an RRC inactive state.

[0058] If a multicast session is active, i.e., if a multicast session is in progress, the UE100 in the RRC Connected state can be configured with a multicast MRB for multicast reception via the RRC Reconfiguration message and can begin receiving MTCH.

[0059] Furthermore, in the case of multicast reception while RRC is inactive, a UE100 in the RRC connected state may have a multicast reception MRB (also referred to as a "multicast inactive MRB") configured via an RRC Release message.

[0060] When a UE100 in the RRC Connected state receives an RRC Release message containing a suspendConfig, it suspends the multicast MRB for the RRC Connected state. However, if the RRC Release message contains a PTM configuration for the RRC Inactive state, the UE100 continues to receive the same multicast session.

[0061] The continuity of service for multicast sessions must be guaranteed during and after transitions in RRC states. Therefore, UE100 should apply the PTM setting for multicast inactive MRBs before pausing multicast MRBs. UE100 will begin receiving multicast inactive MRBs as soon as the PTM setting is applied. This prevents interruptions in multicast reception when transitioning from the RRC connected state to the RRC inactive state.

[0062] (3.1) UE Operation Overview Figure 6 is a diagram showing an overview of the operation of UE100 according to the first operational example of the embodiment. In steps S1 to S5 of Figure 6, UE100 is assumed to be in the RRC connected state.

[0063] In step S1, UE100 uses the first MRB (multicast MRB) for the RRC connected state to receive a multicast session (referred to as "multicast session #1") from network 5 (gNB200).

[0064] In step S2, UE100 receives an RRC Release message from network 5 (gNB200) to transition UE100 to the RRC inactive state (i.e., an RRC Release message including suspend settings). This RRC Release message includes configuration information (PTM settings) indicating the settings for the second MRB (multicast inactive MRB) used to receive multicast session #1 in the RRC inactive state. The suspend settings are an information element indicating the settings for the RRC inactive state.

[0065] In step S3, UE100 applies the configuration information (PTM settings) from step S2 to establish the second MRB before suspending the first MRB in response to the receipt of the RRC Release message. Step S3 may be performed before applying the suspend settings. Step S3 may also be performed when applying the suspend settings.

[0066] In step S4, UE100 begins receiving multicast session #1 using the second MRB established in step S3. For example, UE100 begins receiving the second MRB (specifically, the MTCH corresponding to the second MRB) immediately after applying the PTM configuration.

[0067] In step S5, UE100 suspends the first MRB. Specifically, UE100 stops using the first MRB while retaining its configuration. By suspending the first MRB after establishing the second MRB in this way, interruptions to multicast reception can be suppressed. Alternatively, UE100 may suspend the first MRB after confirming that reception of multicast session #1 (i.e., reception of MBS data) has started via the second MRB. This confirmation of reception start (successful reception start) may be performed at a lower layer (e.g., the PDCP layer), and the result of this confirmation may be notified to the RRC layer. If reception start cannot be confirmed within a certain period, UE100 may determine that there is a reception error for multicast session #1 and subsequently suspend the first MRB. If a reception error is detected, UE100 may attempt to transition back to the RRC connected state (specifically, by sending an RRC Resume Request).

[0068] In step S6, UE100 transitions from the RRC connected state to the RRC inactive state. In the RRC inactive state, UE100 can continue receiving multicast session #1 using the second MRB.

[0069] This operation makes it possible to suppress the interruption of multicast reception when a UE100 receiving multicast in the RRC connected state transitions from the RRC connected state to the RRC inactive state.

[0070] (3.2) Example of an operation sequence Figure 7 shows an example of the operation sequence of the mobile communication system 1 according to the first operation example of the embodiment.

[0071] In step S11, UE100 is in the RRC connected state in the gNB200 cell.

[0072] In step S12, network 5 activates multicast session #1. Step S12 may also be performed after step S13, after step S14, or after step S15.

[0073] In step S13, UE100, in the RRC connected state, joins multicast session #1.

[0074] In step S14, the gNB200 sends an RRC Reconfiguration message to the UE100, which includes the PTM settings for RRC Connected. The UE100, in the RRC Connected state, receives the RRC Reconfiguration message.

[0075] In step S15, the UE100 in RRC connected state applies the RRC connected PTM settings from step S14 and establishes the first MRB (multicast MRB) with the gNB200.

[0076] In step S16, gNB200 uses the first MRB to send the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in the RRC connected state, receives the multicast data.

[0077] Subsequently, in step S17, gNB200 sends an RRC Release message to UE100 that includes the suspend settings. UE100, in the RRC connected state, receives the RRC Release message. The RRC Release message further includes the PTM settings for RRC inactive. The PTM settings for RRC inactive may be included in the suspend settings. These PTM settings may be separate information elements from the suspend settings.

[0078] In step S18, the UE100 in RRC connected state applies the RRC inactive PTM setting from step S17 and establishes a second MRB (multicast inactive MRB) with the gNB200.

[0079] In step S19, gNB200 uses the second MRB to send the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in the RRC connected state, receives the multicast data. At this point, UE100 may perform both multicast reception using the first MRB and multicast reception using the second MRB. If UE100 receives the same multicast data on both the first and second MRBs, it may discard one of the multicast data.

[0080] In step S20, the UE100 in RRC connected state suspends the first MRB.

[0081] In step S21, UE100 transitions from the RRC connected state to the RRC inactive state.

[0082] Subsequently, if there is an update to the RRC inactive PTM setting, UE100 may receive a new SIB from gNB200 (step S22) and a multicast MCCH from gNB200 (step S23). Note that in step S17, an example was shown in which the RRC Release message includes the RRC inactive PTM setting, but this is not the only example. In step S17, UE100 may receive the RRC inactive PTM setting via MCCH. Furthermore, UE100 may receive an RRC Release message (which does not necessarily include the RRC inactive PTM setting).

[0083] (3.3) Examples of specification changes The following describes examples of changes to 3GPP technical specifications. Specifically, we will describe examples of changes to TS38.331, which is the specification for the RRC layer.

[0084] (3.3.1) Example of specification change 1 Figure 8 shows an example of specification change 1 according to the embodiment. The operation shown in Figure 8 is the operation performed by UE100 upon receiving an RRC Release message.

[0085] In step S101, UE100 checks whether the RRC Release message contains the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration). If the RRC Release message contains the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration), in step S102, UE100 applies the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration). Then, in step S103, UE100 establishes a second MRB (multicast inactive MRB). Also, in step S104, UE100 starts multicast reception (MTCH reception) using the second MRB.

[0086] Subsequently, in step S105, UE100 checks whether the RRC Release message contains a suspend configuration (suspendConfig). If the RRC Release message contains a suspend configuration (suspendConfig), in step S106, UE100 resets the MAC. Also, in step S107, UE100 applies the received suspend configuration (suspendConfig). Then, in steps S108 and S109, UE100 suspends the first MRB. Note that UE100 does not suspend the second MRB. Furthermore, in step S110, UE100 indicates the suspension of the RRC connection to the upper layer. At this point, UE100 may also notify the upper layer that the multicast session is receivable in an RRC inactive state (or that the second MRB is not suspended). Alternatively, it may notify the session identifier (TMGI) of the multicast session. Finally, in step S111, UE100 transitions to the RRC inactive state.

[0087] (3.3.2) Example of specification change 2 Figure 9 shows an example of specification change 2 according to the embodiment. The operation shown in Figure 9 is the operation performed by UE100 upon receiving an RRC Release message.

[0088] In step S131, UE100 checks whether the RRC Release message contains a suspend configuration (suspendConfig). If the RRC Release message contains a suspend configuration (suspendConfig), in step S132, UE100 resets the MAC. Also, in step S133, UE100 applies the received suspend configuration (suspendConfig). Here, in step S134, UE100 checks whether the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration) is set in the suspend configuration (suspendConfig). If the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration) is set, in step S135, UE100 applies the RRC inactive PTM configuration (MBSMulticastInactiveConfiguration). Then, in step S136, UE100 establishes a second MRB (multicast inactive MRB). Furthermore, in step S137, UE100 starts multicast reception (MTCH reception) using the second MRB.

[0089] Then, in steps S138 and S139, UE100 suspends the first MRB. However, UE100 does not suspend the second MRB. Furthermore, in step S140, UE100 indicates the suspension of the RRC connection to the upper layer. Here, UE100 may also notify the upper layer that the multicast session is receivable in the RRC inactive state (or that the second MRB is not suspended). Alternatively, it may notify the session identifier (TMGI) of the multicast session. Finally, in step S141, UE100 transitions to the RRC inactive state.

[0090] (4) Second example of operation The following describes a second operational example regarding multicast reception in an RRC inactive state, primarily highlighting the differences from the first operational example described above. Note that redundant explanations of operations similar to the first operational example will be omitted.

[0091] The first operational example described above assumed a scenario where the multicast session was already activated when UE100 received the RRC Release message. In contrast, the second operational example primarily assumes a scenario where the multicast session was not yet activated when UE100 received the RRC Release message.

[0092] For inactive multicast sessions, the UE100 may be configured with a PTM setting (MBSMulticastInactiveConfiguration) via an RRC Release message. In the first example described above, upon receiving the RRC Release message, the UE100 applies the PTM setting and immediately begins receiving MTCHs. However, if the multicast session is inactive, no MTCHs are sent at this point, and therefore the UE100 should not begin the process of receiving MTCHs. In this case, even if the UE100 attempts to receive multicast (receive MTCHs), it will not be able to receive any MTCHs, and the UE100 will waste power.

[0093] Therefore, in the second operational example, network 5 notifies UE100 that the multicast session (specifically, the multicast session in which UE100 is participating) is still inactive. For example, gNB200 notifies UE100 via an RRC Release message whether the multicast session has been activated, so that UE100 does not receive the corresponding MTCH. This allows UE100 to wait for, for example, a multicast session activation notification (group notification) without starting to receive the MTCH.

[0094] In other words, in the second operational example, the UE100 in the RRC connected state first receives an RRC Release message from the gNB200 that includes configuration information used for receiving multicast sessions in the RRC inactive state (PTM settings for RRC inactive) and transitions the UE100 to the RRC inactive state. Secondly, the UE100 checks whether the multicast session is activated or not. Thirdly, if the multicast session is not activated, the UE100 suspends the execution of predetermined processing to start receiving the multicast session.

[0095] (4.1) Example of UE operation Figure 10 is a diagram showing an overview of the operation of UE100 according to the second operational example of the embodiment. Here, it is assumed that UE100 has already joined multicast session #1.

[0096] In step S201, the UE100 in the RRC connected state receives an RRC Release message from the gNB200 that includes configuration information (PTM settings for RRC inactive) used to receive multicast session #1 in the RRC inactive state, and transitions the UE100 to the RRC inactive state. In the second example, the RRC Release message includes session status information indicating whether multicast session #1 is activated or not.

[0097] The session status information may indicate that multicast session #1 is activated (i.e., not deactivated). The session status information may indicate that multicast session #1 is not activated (i.e., deactivated). The session status information may indicate whether to immediately apply the information described below (which may be PTM settings for RRC inactivity) (i.e., whether to apply the prescribed processing or simply hold it). The session status information may also indicate whether to immediately start MTCH reception.

[0098] The configuration information in the RRC Release message (PTM settings for RRC inactive) may include, as predetermined information associated with multicast session #1, at least one of the following: a session identifier (TMGI) associated with multicast session #1, an MRB identifier associated with multicast session #1, and an MTCH setting associated with multicast session #1. The MTCH setting is a setting related to MTCH reception and includes, for example, at least one of the following: a group identifier (G-RNTI), intermittent reception settings (DRX settings or scheduling information: MTCH transmission ON time, MTCH transmission period, reference time and time offset, HARQ retransmission settings), Layer 2 settings (PDCP settings, RLC settings), and physical channel settings (PDCCH settings, PDSCH settings, SSB mapping settings).

[0099] In the RRC Release message, session status information is associated with predetermined information. This allows the UE100 to identify which multicast sessions are active based on the predetermined information and the session status information.

[0100] In step S202, the UE100 in the RRC connected state checks whether multicast session #1 is activated based on the session status information in the RRC Release message. Alternatively, if the UE100 has obtained information from the CN20 regarding whether multicast session #1 is activated, the UE100 may check whether multicast session #1 is activated based on the information from the CN20.

[0101] If multicast session #1 is activated (step S202: YES), in step S203, the UE100 in the RRC connected state performs the same operation as in the first example of operation described above. Specifically, the UE100 performs predetermined processing to start receiving multicast session #1. The predetermined processing includes at least one of the following: processing to apply configuration information (PTM settings for RRC inactive) (including processing to establish a second MRB), and processing to start receiving MTCH (i.e., processing to start multicast reception using the second MRB). The predetermined processing may also include at least one of the following: processing to receive multicast MCCH, and processing to receive a new SIB that transmits configuration information (multicast MCCH settings) used to receive multicast MCCH.

[0102] After executing the predetermined process, in step S204, UE100 transitions from the RRC connected state to the RRC inactive state. Then, in step S205, UE100 in the RRC inactive state continues to receive multicast session #1.

[0103] On the other hand, if multicast session #1 is not activated (step S202: NO), in step S206, UE100 suspends the execution of predetermined processes for starting reception of multicast session #1. For example, UE100 in the RRC connected state will not execute at least one of the following: the process of applying configuration information (PTM settings for RRC inactive) (including the process of establishing the second MRB), and the process of starting reception of MTCH (i.e., the process of starting multicast reception using the second MRB). However, UE100 may perform the process of saving (holding) configuration information to its own memory.

[0104] After suspending the execution of predetermined processing, in step S207, UE100 transitions from the RRC connected state to the RRC inactive state. Then, in step S208, UE100 in the RRC inactive state awaits a paging message (i.e., a group notification) to notify the activation of multicast session #1, and receives the group notification.

[0105] Upon receiving a group notification, in step S209, the UE100 in the RRC inactive state performs a process to monitor and receive a predetermined logical channel. The predetermined logical channel is at least one of the multicast MCCH, which transmits configuration information used for receiving multicast session #1 in the RRC inactive state, and the MTCH, which transmits multicast session #1. Here, the UE100 may read the configuration information from memory and apply it. Then, in step S210, the UE100 in the RRC inactive state receives multicast session #1 transmitted on the MTCH.

[0106] (4.2) Example of an operation sequence Figure 11 is a diagram showing an example of the operation sequence of the mobile communication system 1 according to the second operation example of the embodiment.

[0107] In step S251, UE100 is in the RRC connected state in the gNB200 cell.

[0108] In step S252, the UE100, in the RRC connected state, joins multicast session #1. Here, the UE100 joins multicast session #1 by communicating with CN20 (e.g., NAS signaling). At this time, the UE100 may obtain information from CN20 (e.g., AMF300A) about whether multicast session #1 is activated or not.

[0109] In step S253, gNB200 sends an RRC Release message to UE100 that includes the suspend setting. UE100, in the RRC Connected state, receives the RRC Release message. The RRC Release message further includes the PTM setting for RRC inactive for multicast session #1. The PTM setting for RRC inactive may be included in the suspend setting. This PTM setting may be a separate information element from the suspend setting.

[0110] In the second operational example, the RRC Release message may include session status information indicating whether multicast session #1 is activated or not. That is, when gNB200 configures a PTM on UE100 using the RRC Release message, it notifies whether multicast session #1 corresponding to that PTM configuration is active (i.e., in progress) or inactive (i.e., waiting to be activated). This notification may be made for each TMGI, each MRB, and each PTM configuration (MTCH configuration). Here, we will proceed with the explanation assuming that multicast session #1 is not activated.

[0111] In step S254, UE100 recognizes that multicast session #1 is inactive based on information from CN20 and / or session status information in the RRC Release message.

[0112] In step S255, UE100 suspends the execution of predetermined processing to begin receiving multicast session #1. For example, UE100 does not apply the PTM setting for RRC inactive. Alternatively, UE100 may apply the PTM setting but not perform MTCH reception. UE100 may also refrain from processing the multicast MCCH and new SIB reception.

[0113] In step S256, UE100 transitions from the RRC connected state to the RRC inactive state.

[0114] In step S257, the UE100, which is in an RRC inactive state, begins monitoring for paging messages (i.e., group notifications) to notify the activation of multicast session #1.

[0115] Subsequently, in step S258, network 5 activates multicast session #1.

[0116] In step S259, gNB200 sends a paging message (i.e., a group notification) to notify of the activation of multicast session #1. This group notification includes the session identifier (TMGI) of multicast session #1. UE100, in the RRC connected state, receives the group notification and confirms that the session identifier of multicast session #1, which it has joined, is included in the group notification.

[0117] In step S260, gNB200 may send a new SIB including the multicast MCCH configuration. UE100, in the RRC inactive state, may receive the new SIB in response to receiving the group notification in step S259.

[0118] In step S261, gNB200 may send a multicast MCCH containing a PTM setting for RRC inactive multicast session #1. UE100, in the RRC inactive state, may receive the multicast MCCH based on the new SIB in step S260.

[0119] In step S262, gNB200 sends the MBS data (multicast data) for multicast session #1 to UE100 over the MTCH. UE100, in an RRC inactive state, receives the multicast data (MTCH) based on the RRC inactive PTM settings in step S253 and / or step S261.

[0120] (5) Other embodiments 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.

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

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

[0123] In other words, UE100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that performs signal relay. Such a terminal function unit is called an MT. Examples of MTs other than IAB-MT include NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.

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

[0125] A program may be provided that causes a computer to execute each process performed by the UE100 or gNB200. 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 or gNB200 may be integrated, and at least a part of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0126] The functions realized by UE100 or gNB200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (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 a type of circuitry, then such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

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

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

[0129] This application claims priority to U.S. Provisional Application No. 63 / 456909 (filed April 4, 2023), the entirety of which is incorporated into the specification of this application.

[0130] (6) Appendix A The features of the above-described embodiment are noted below.

[0131] (Note 1) A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), The steps include receiving an RRC release message from a network node that causes the user device to transition to the RRC inactive state, which includes configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, The steps include: confirming whether the multicast session is activated or not, If the multicast session is not activated, the step of postponing the execution of a predetermined process for initiating reception of the multicast session is included. Communication method.

[0132] (Note 2) The RRC release message includes session status information indicating whether or not the multicast session is activated. The aforementioned verification step includes a step of determining whether the multicast session is activated based on the session status information. The communication method described in Appendix 1.

[0133] (Note 3) The configuration information includes, as predetermined information associated with the multicast session, at least one of the following: a session identifier, a multicast radio bearer (MRB) identifier, and a multicast traffic channel (MTCH) setting. In the RRC release message, the session state information is associated with the predetermined information. The communication method described in Appendix 2.

[0134] (Note 4) If the multicast session is activated, the process further includes the step of performing the predetermined processing. The communication method described in any of the appendices 1 to 3.

[0135] (Note 5) The predetermined process includes at least one of the following: a process to apply the configuration information, and a process to start receiving a multicast traffic channel (MTCH). The communication method described in any of the appendices 1 to 4.

[0136] (Note 6) The predetermined process includes at least one of the following: a process for receiving a multicast control channel (MCCH) that transmits configuration information used for receiving multicast sessions in the RRC inactive state, and a process for receiving a system information block (SIB) that transmits configuration information used for receiving the MCCH. The communication method described in any of the appendices 1 to 5.

[0137] (Note 7) If the multicast session is not activated, the RRC inactive state further includes the step of waiting for a paging message to notify the activation of the multicast session. The communication method described in any of the appendices 1 to 6.

[0138] (Note 8) In the RRC inactive state, the step of receiving the paging message, The process further includes, in response to the receipt of the paging message, processing to receive a predetermined logical channel in the RRC inactive state, The predetermined logical channel is at least one of the following: a multicast control channel (MCCH) that transmits configuration information used for receiving multicast sessions in the RRC inactive state, and a multicast traffic channel (MTCH) that transmits the multicast session. The communication method described in Appendix 7.

[0139] (Note 9) A communication method performed by a network node in a mobile communication system that provides multicast / broadcast services (MBS), The process includes a step of sending an RRC release message to a user device in an RRC connected state, which includes configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, and causes the user device to transition to an RRC inactive state. The RRC release message includes session status information indicating whether or not the multicast session is activated. Communication method.

[0140] (Note 10) User equipment used in a mobile communication system that provides multicast / broadcast services (MBS), The process includes receiving an RRC release message from a network node that causes the user device to transition to the RRC inactive state, and which includes configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state. A process to check whether the multicast session is activated or not, The control unit includes a process that, if the multicast session is not activated, suspends the execution of a predetermined process for initiating reception of the multicast session. User device.

[0141] (Note 11) A network node used in a mobile communication system that provides multicast / broadcast services (MBS), The system includes a transmission unit that transmits an RRC release message to a user device in an RRC connected state, which includes configuration information used for receiving multicast sessions in a Radio Resource Control (RRC) inactive state, and which causes the user device to transition to an RRC inactive state. The RRC release message includes session status information indicating whether or not the multicast session is activated. Network node.

[0142] (7) Appendix B 1. Introduction The work item concerning enhanced MBS (eMBS) aims to support multicast reception by UEs when inactive, and is described as follows: — Specifies support for multicast reception by UEs in RRC inactive state [RAN2, RAN3]. • PTM configuration for UEs receiving multicast while RRC is inactive [RAN2]. Investigate the impact of mobility and state transitions on UEs receiving multicast with RRC inactive. (Seamless / lossless mobility is not required) [RAN2, RAN3].

[0143] RAN2 has discussed this objective and reached a series of agreements. Building upon these agreements, the PTM configuration and mobility aspects of multicast reception in inactive mode are discussed in this appendix.

[0144] 2. Discussion 2.1. Initial configuration procedures RAN2#120 has agreed to proceed with a "mixed approach."

[0145] The mixed approach begins as follows: 1. If the UE is configured to continue multicast reception while the NW is inactive, the NW will provide PTM configuration for the activated multicast session, at least to the serving cell, via RRC-dedicated signaling (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 only after joining a session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0146] RAN2#121 agreed to the following statement: • The UE must join a multicast session before it can receive multicast with RRC inactive. If the network determines it is beneficial, it can configure the PTM settings of (one) serving cell in the UE before activating the session, and the UE can save those settings. Once the session is active, the UE can apply the settings and receive multicast sessions in an inactive state without reverting to RRC connected, unless updated by MCCH after configuration. • When configuring the UE to receive multicast while the network is inactive, the PTM configuration can be delivered using RRC Release messages, including suspendconfig. Other dedicated RRC messages are not used to provide PTM configuration for inactive MBS multicast. • Introduce a new MCCH logical channel for multicast in inactive mode (different from broadcast MCCH). • Multicast MCCH configuration is provided via the new SIB. As an option, multicast MCCH configuration for serving cells can also be provided via dedicated signaling. Therefore, it is not optimized for mobility.

[0147] Based on these agreements, the setup procedures for an ongoing (i.e., activated) multicast session and a deactivated (i.e., pre-activation) multicast session can be considered as shown in Figure 12.

[0148] 2.1.1. Ongoing (Activated) Multicast Sessions For ongoing multicast sessions, the UE configures the multicast MRB for multicast reception in connected mode by RRC reconfiguration and begins receiving MTCH as in Rel-17. For multicast reception in inactive mode, the UE configures the broadcast MRB (or a new "multicast inactive MRB") for multicast reception via RRC release.

[0149] Regarding the PTM settings for RRC resume, it is clear that the content (i.e., IE) is the same, using Rel-17MCCH (i.e., MBSBroadcastConfiguration) as the baseline. However, since RAN2 agreed to "introduce a new MCCH logical channel," the naming of the RRC message also needs to be different from Rel-17MBSBroadcastConfiguration. The same message is forwarded via the new MCCH logical channel.

[0150] Proposal 1: RAN2 should agree to define a new RRC message for PTM configuration with RRC release and define a new “multicast MCCH,” e.g., MBSMulticastInactiveConfiguration.

[0151] Proposal 2: RAN2 should agree that the IE of the new RRC message for PTM configuration should be the same as Rel-17MBSBroadcastConfiguration as the baseline.

[0152] When a UE receives an RRC release with suspendConfig, similar to Rel-17, multicast MRBs for connected devices are suspended. If the RRC release includes a PTM setting in inactive, the UE continues the same multicast session. During / after RRC state transitions, service continuity for the multicast session must be ensured. This is similar to legacy-specific settings such as redirectedCarrierInfo, cellReselectionPriorities, deprioritisationReq, and measIdleConfig. The UE should begin receiving broadcast MRBs as soon as it applies the PTM setting. Further consideration is needed as to whether a new procedure (i.e., the UE applying the PTM setting and beginning to receive MTCHs) is performed when the UE applies suspendConfig.

[0153] Proposal 3: RAN2 should agree that before pausing multicast MRB, the UE should apply the PTM settings for broadcast MRB (or the new "multicast inactive MRB") and begin receiving the corresponding MCCH.

[0154] 2.1.2. Deactivated (pre-activation) multicast sessions In a deactivated multicast session, the UE configures the PTM by releasing the RRC. If the above proposal 3 is agreed upon, the UE immediately begins receiving the MTCH. However, since the MTCH is not sent at this point, the UE should not do so. Therefore, it is necessary to notify the UE that the multicast session is still inactive by releasing the RRC, allowing the UE to wait for the multicast session activation notification without receiving the MTCH. Further consideration is needed for the detailed behavior, for example, whether to wait for session activation while applying the PTM configuration.

[0155] Proposal 4: RAN2 should agree to notify the UE whether the multicast session has been deactivated by releasing the RRC, so that the UE does not attempt to receive the corresponding MTCH.

[0156] After transitioning to inactive, the UE monitors for multicast session activation notifications (i.e., group paging). Before the multicast session is activated, the gNB may change the session's PTM configuration, and such changes are set by the UE's new "multicast MCCH" while inactive. In this case, the gNB can send the "multicast MCCH" before the session is activated.

[0157] From the UE's perspective, if the UE needs to monitor a new "multicast MCCH" for a deactivated multicast session, its power consumption increases. Therefore, it's necessary to ensure that the UE doesn't need to monitor the multicast MCCH before receiving activation notifications for the multicast session. In other words, the UE should only need to monitor the multicast MCCH once it receives activation notifications on the target TMGI. The same behavior applies to newer SIBs (like SIB20) for MCCH configuration.

[0158] Proposal 5: RAN2 should agree that if the corresponding multicast session is deactivated (i.e., before receiving multicast session notification), the UE does not need to monitor for new "multicast MCCHs" or new SIBs (such as SIB20).

[0159] Upon receiving a multicast activation notification, the UE needs to check whether the MCCH settings and / or PTM settings for the multicast MCCH have been updated if they were provided via RRC release. Unless the settings have been updated, the saved settings (i.e., the settings provided by RRC release) should apply. Needless to say, if the settings have been updated, the UE needs to acquire the new SIB and / or multicast MCCH.

[0160] For the new SIB, it is expected that the UE will be able to know whether the new SIB has been updated by checking the value tag of SIB1, as is currently the case. On the other hand, the UE cannot know whether the multicast MCCH has been updated before receiving and decoding the MCCH. In this case, even if it was set by RRC release, the UE would have to decode the MCCH once, which is equally meaningless. In this sense, in order for the UE to know about PTM setting updates without decoding the MCCH, a value tag needs to be introduced to the MCCH. Where the MCCH value tag is placed requires further consideration, such as in the new SIB, SIB1, or group paging.

[0161] Proposal 6: RAN2 should agree to introduce an MCCH value tag that the UE will use to know whether the PTM setting has been updated from what it was set by RRC release, without having to decode the MCCH itself.

[0162] 2.2. Updating settings while inactive In Rel-17, there is one MCCH per cell. In Rel-18, RAN2 agreed to "introduce a new MCCH logical channel for multicast in inactive (different from broadcast MCCH)." Multicast MCCHs are used when the PTM configuration needs to be changed or when the PTM configuration needs to be shown during transitions across serving cells / gNBs.

[0163] Finding 1: Multicast MCCH is used to update the UE's PTM settings when inactive.

[0164] In other words, a Rel-18 network has two MCCHs: a (broadcast) MCCH and a multicast MCCH. The motivation for introducing separate MCCHs within a cell is to handle the different service requirements of different cast types (MBS broadcast and MBS multicast).

[0165] The question is whether different multicast sessions have different service requirements. The service requirements for a group multimedia call service and a firmware download service are entirely different. For example, the group multimedia call service is a foreground service and therefore requires frequent optimization of the PTM configuration, while the firmware download service is a background service and does not require such frequent optimization. Considering that the initial PTM configuration is provided by RRC release, updating the PTM configuration via multicast MCCH is necessary for some services but not for others. In this sense, deploying multiple multicast MCCHs is efficient for the UE and flexible for the network.

[0166] Proposal 7: RAN2 should discuss whether or not to implement multiple multicast MCCHs per cell.

[0167] 2.3. UE Mobility and Service Continuity In RAN2#120, it was agreed that MCCH would be used during UE transitions.

[0168] In a mixed approach, you start as follows: 1. If the NW configures the UE to continue receiving multicast while inactive, the NW will provide PTM settings for the activated multicast session through 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 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 only after joining a session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE through dedicated signaling.

[0169] WID states that seamless, loss-free mobility is not necessary: — Specifies support for multicast reception by UEs in RRC inactive state [RAN2, RAN3]. PTM configuration for UEs receiving multicast while RRC is inactive [RAN2]. • Investigate the impact of mobility and state transitions on UEs receiving multicast in an RRC inactive state (seamless / lossless mobility is not required) [RAN2, RAN3].

[0170] RAN2#120 concludes that multicast MCCH is used to configure PTM during mobility.

[0171] The mixed approach begins as follows: 1. If the NW configures the UE to continue receiving multicast while inactive, the NW will provide PTM settings for the activated multicast session through 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 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 only after joining a session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE through dedicated signaling.

[0172] This is similar to Rel-17 MBS broadcasting. Therefore, it is natural to use the Rel-17 MBS broadcasting service continuity mechanism as a baseline. In this case, in a multicast session, neighbor cell information must first be provided from the MCCH, and it must be confirmed that the UE is permitted to prioritize the MBS frequency when re-selecting a cell.

[0173] As assumed in LTE SC-PTM and NRMBS broadcasting, how adjacent cell information is used, whether or not MBS frequencies are prioritized, and when / how MCCH is obtained from adjacent cells, and how service continuity is ensured, are all up to the UE implementation.

[0174] Proposal 8: RAN2 should agree that adjacent cell information for multicast sessions should be provided from MCCH, just like MBS broadcasts.

[0175] Proposal 9: RAN2 should agree that, during cell reselection, UEs should prioritize MBS multicast frequencies, similar to MBS broadcast frequencies.

[0176] At RAN2#121, the area scope of MCCH was discussed. Some companies proposed enabling PTM settings in multiple cells to improve service continuity during UE transitions. Within a gNB, PTM settings for each cell can be easily aligned (if necessary), but this becomes more difficult between gNBs and requires negotiation with Xn-AP. Ultimately, RAN2 agreed that area scope should not involve other gNBs, and further consideration is needed for cases within gNBs. Serving cells do not provide PTM settings for neighboring cells from other gNBs. Further investigation is needed to determine whether the network can provide PTM settings for cells within the gNB.

[0177] For this minor enhancement, limiting it to within a gNB would likely suffice. Therefore, RAN2 should discuss whether it can apply PTM settings to multiple cells within a gNB.

[0178] Proposal 10: RAN2 should discuss whether the PTM setting can be applied to multiple cells within a gNB.

[0179] Another consideration is network-based QoS control. While WID does not require seamless / lossless mobility, not all multicast sessions that allow reception while the UE is inactive do not require seamless / lossless mobility. For example, due to congestion, the network may need to transition the UE to inactive, but QoS requirements necessitate returning the UE to connected. Seamless / lossless mobility supports Rel-17MBS multicast handovers in RRC connected state. Therefore, it is necessary to consider whether the network needs the option to control whether the UE performs cell reselection or resumes RRC connectivity before cell reselection (in the case of a handover in connected state).

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

[0181] 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 performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), Receiving an RRC release message from a network node that includes information to be notified when a multicast session is deactivated, and which causes the user device to transition to a Radio Resource Control (RRC) inactive state, Based on the aforementioned information, the execution of a predetermined process for receiving the multicast session is stopped, Upon receiving a paging message containing the session identifier of the multicast session, the system receives a multicast control channel (multicast MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state. Even if the user device is configured to receive the multicast session in the RRC inactive state, the user device sends a message requesting the resumption of the RRC connection in response to receiving the paging message. Communication method.

2. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), A receiving unit that receives an RRC release message from a network node, which includes information to be notified when a multicast session is deactivated, and which causes the user device to transition to a Radio Resource Control (RRC) inactive state. A control unit that stops executing a predetermined process for receiving the multicast session based on the aforementioned information, It comprises a transmitting unit, Upon receiving a paging message containing the session identifier of the multicast session, the receiving unit receives a multicast control channel (multicast MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state. Even if the user device is configured to receive the multicast session in the RRC inactive state, the receiving unit will receive the paging message, and the transmitting unit will send a message requesting the resumption of the RRC connection. User device.

3. A program for a user device used in a mobile communication system that provides multicast / broadcast services (MBS), wherein the user device has the following capabilities: The process includes receiving an RRC release message from a network node, which includes information to be notified when a multicast session is deactivated, and which causes the user device to transition to a Radio Resource Control (RRC) inactive state. Based on the aforementioned information, a process to stop the execution of a predetermined process for receiving the multicast session, In response to receiving a paging message containing the session identifier of the multicast session, the process includes receiving a multicast control channel (multicast MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state, Even if the user device is configured to receive the multicast session in the RRC inactive state, the device will execute the process of sending a message requesting the resumption of the RRC connection in response to receiving the paging message. program.

4. A chipset for user equipment used in a mobile communication system that provides multicast / broadcast services (MBS), The process includes receiving an RRC release message from a network node, which includes information to be notified when a multicast session is deactivated, and which causes the user device to transition to a Radio Resource Control (RRC) inactive state. Based on the aforementioned information, a process to stop the execution of a predetermined process for receiving the multicast session, In response to receiving a paging message containing the session identifier of the multicast session, the process includes receiving a multicast control channel (multicast MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state, Even if the user device is configured to receive the multicast session in the RRC inactive state, upon receiving the paging message, it will perform the following process: send a message requesting the resumption of the RRC connection. Chipset.

5. A system including user equipment and network nodes used in a mobile communication system that provides multicast / broadcast services (MBS), The User device is A receiving unit that receives an RRC release message from a network node, which includes information to be notified when a multicast session is deactivated, and which causes the user device to transition to a Radio Resource Control (RRC) inactive state. A control unit that stops executing a predetermined process for receiving the multicast session based on the aforementioned information, It comprises a first transmitting unit, Upon receiving a paging message containing the session identifier of the multicast session, the receiving unit receives a multicast control channel (multicast MCCH) that transmits configuration information used for receiving the multicast session in the RRC inactive state. Even if the user device is configured to receive the multicast session in the RRC inactive state, the receiving unit, upon receiving the paging message, sends a message requesting the resumption of the RRC connection. The aforementioned network node is The system includes a second transmission unit that transmits the RRC release message containing the aforementioned information, the multicast MCCH, and the paging message to the user device. system.

Images