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

Abstract

This communication method, which is used in a mobile communication system that provides a multicast / broadcast service (MBS), comprises: a step of user equipment in a radio resource control (RRC) connected state receiving configuration information from a base station; and a step of the user equipment having transitioned from the RRC connected state to an RRC inactive state receiving a multicast session in a cell of the base station. The configuration information includes an information element indicating whether to permit cell reselection to another cell by the user equipment that receives the multicast session in the RRC inactive state.

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 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 service (MBS) are defined.

[0003] In 3GPP Release 17, multicast reception of MBS (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 steps of: a user device in a radio resource control (RRC) connected state receiving configuration information from a network node; and the user device, which has transitioned from the RRC connected state to an RRC inactive state, receiving the multicast session in a cell of the network node. The configuration information includes an information element indicating whether or not the user device receiving the multicast session in the RRC inactive state is permitted to reselect a cell to another cell.

[0006] A communication method according to a second embodiment is a communication method used in a mobile communication system that provides multicast / broadcast services (MBS), comprising the steps of: a user device in an RRC inactive state receiving a multicast session from a network node; the user device measuring the quality of service of the multicast session; and, if the user device determines that the quality of service does not meet a predetermined quality of service, transitioning from the RRC inactive state to the RRC connected 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 diagram shows a general overview of a typical cell reselection procedure. [Figure 9] This figure shows an example of the operation of the UE according to the first embodiment. [Figure 10] This figure shows an example of the operating environment of the mobile communication system according to the first embodiment. [Figure 11] This figure shows an example of the operation of a mobile communication system based on the operating environment shown in Figure 10. [Figure 12] This figure shows an example of the operation of the UE according to the second embodiment. [Figure 13] 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 own 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 data transfer control. 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] FIG. 2 is a diagram showing the configuration of the UE 100 (user device) 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 receptions 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 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 radio signal and transmits it from the antenna.

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

[0020] FIG. 3 is a diagram showing the configuration of the gNB 200 (base station) according to the embodiment. The gNB 200 has a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240. The transmitting unit 210 and the receiving unit 220 constitute a radio communication unit that performs radio communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

[0021] The transmitting unit 210 performs various transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts 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 (Cyclic Redundancy Code) 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, the 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 that a UE100 is registered 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, MBS settings for UE100 are configured 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 MBS packets 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 scrambled by a UE-specific RNTI. On the other hand, in the case of 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 scrambled with a group-common RNTI (e.g., G-RNTI) using a group-common PDCCH with a CRC 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] 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.

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

[0044] 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 6(a) and a distribution mode 2-based solution shown in Figure 6(b). It is assumed that the UE100 supports multicast reception in an RRC inactive state and is already participating in a multicast session.

[0045] In the distribution mode 1-based solution shown in Figure 6(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).

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

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

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

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

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

[0051] On the other hand, in the delivery mode 2-based solution shown in Figure 6(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.).

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

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

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

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

[0056] (1.3) Reselect Cell Figure 7 is a diagram illustrating a typical cell reselection procedure. When UE100 is in an RRC idle or RRC inactive state, it performs a cell reselection procedure to move from the current serving cell (cell #1) to an adjacent cell (one of cells #2 through #4) upon movement. Specifically, UE100 identifies the adjacent cell to which it should camp on using the cell reselection procedure and reselects the identified adjacent cell. When the current serving cell and the adjacent cell have the same frequency (carrier frequency), it is called an intra-frequency, and when the current serving cell and the adjacent cell have different frequencies (carrier frequencies), it is called an inter-frequency. The current serving cell and the adjacent cell may be managed by the same gNB200. The current serving cell and the adjacent cell may be managed by different gNB200s.

[0057] Figure 8 shows a schematic flow of a typical cell reselection procedure.

[0058] In step S21, the UE100 performs frequency prioritization based on the frequency-specific priority (also referred to as "absolute priority," "cell reselection priority," or "dedicated priority") specified by the gNB200, for example, in a System Information Block (SIB) or RRC release message. Specifically, the UE100 manages the frequency priority specified by the gNB200 for each frequency.

[0059] In step S22, the UE100 performs a measurement process to measure the radio quality for both the serving cell and the adjacent cell. The UE100 measures the received power and received quality of the reference signal transmitted by each of the serving cell and the adjacent cell, specifically the CD-SSB (Cell Defining-Synchronization Signal and PBCH block). For example, the UE100 always measures the radio quality for frequencies with a higher priority than the current serving cell's frequency priority, and for frequencies with the same or lower priority as the current serving cell's frequency priority, it measures the radio quality of frequencies with the same or lower priority only if the current serving cell's radio quality falls below a predetermined quality.

[0060] In step S23, UE100 performs a cell reselection process to reselect the cell to which it will camp on, based on the measurement results in step S22. For example, UE100 may reselect a cell to an adjacent cell if the frequency priority of the adjacent cell is higher than the priority of the current serving cell, and the adjacent cell meets a predetermined quality standard (i.e., the minimum required quality standard) for a predetermined period. If the frequency priority of the adjacent cell is the same as the priority of the current serving cell, UE100 may rank the radio quality of the adjacent cell and reselect a cell to an adjacent cell that has a higher rank than the current serving cell for a predetermined period. If the frequency priority of the adjacent cell is lower than the priority of the current serving cell, and the radio quality of the current serving cell remains below a certain threshold, and the radio quality of the adjacent cell remains above another threshold for a predetermined period, UE100 may reselect a cell to that adjacent cell.

[0061] Furthermore, UE100 units in an RRC idle or RRC inactive state that support MBS will apply the following modification to the cell reselection described above. Specifically, UE100 units that are receiving or interested in receiving MBS broadcast services via PTM (Point-to-Multipoint) are permitted to set the frequency providing these MBS broadcast services as the highest priority (higher than the priority of other network settings) if they can only receive these MBS broadcast services by camping on that frequency. Such frequency prioritization processing may also be applicable to multicast reception in an RRC inactive state.

[0062] On the other hand, if an MBS broadcast service that UE100 is interested in becomes unavailable (after the session ends), or if UE100 loses interest in receiving that broadcast service, UE100 will no longer prioritize that frequency. Also, UE100s that are receiving or interested in receiving MBS broadcast services via PTM are permitted to set frequencies from which these MBS broadcast services cannot be received as the lowest priority (lower than the priority of other network settings). Such frequency prioritization processing may also be applicable to multicast reception in an RRC inactive state.

[0063] (1.4) Operation according to the first embodiment The first embodiment relates to cell reselection by UE100 performing multicast reception in an RRC inactive state.

[0064] In 3GPP Release 17, MBS multicast can only be received by UE100 devices in the RRC connected state. Therefore, the serving cell switchover of UE100 devices receiving multicast in the RRC connected state can be performed by handover, suppressing the interruption of multicast reception during cell switching.

[0065] On the other hand, in 3GPP Release 18, MBS multicast can be received even by UE100 devices that are in an RRC inactive state. Therefore, the serving cell switch for UE100 devices receiving multicast while in an RRC inactive state is performed by cell reselection. In this case, cell reselection may cause interruption or disruption of multicast reception.

[0066] Here, 3GPP Release 18 assumes that multicast reception in the RRC inactive state does not require seamless / lossless mobility. However, some multicast sessions received by UE100 in the RRC inactive state may require seamless / lossless mobility. For example, in a scenario where network congestion causes gNB200 to temporarily transition UE100 to the RRC inactive state, UE100 may be receiving multicast sessions that require seamless / lossless mobility. In such a case, it is desirable that network 5 (gNB200) be able to control the serving cell switching of UE100 by handover rather than cell reselection.

[0067] In the first embodiment, gNB200 transmits configuration information to UE100 in the RRC Connected state. UE100 receives the configuration information. UE100, having transitioned from the RRC Connected state to the RRC Inactive state, receives a multicast session in the gNB200's cell. The configuration information includes an information element (hereinafter referred to as "mobility setting") indicating whether or not to allow UE100, which receives a multicast session in the RRC Inactive state, to perform cell reselection to another cell. The mobility setting may also include an information element indicating whether or not UE100 in the RRC Inactive state should transition to the RRC Connected state before performing cell reselection.

[0068] This allows, for example, a UE100 receiving a multicast session requiring seamless / lossless mobility to be prevented from switching to another cell and instead transition to the RRC connected state before switching cells. Therefore, the serving cell switching of the UE100 can be controlled by handover rather than cell switching. Thus, it becomes easier to ensure the continuity of multicast reception.

[0069] For example, UE100, which receives a multicast session in the RRC inactive state, will transition to the RRC connected state before performing cell reselection, based on a mobility setting that indicates it does not allow cell reselection. Once in the RRC connected state, UE100 may receive a handover command from gNB200 and access another cell providing the multicast session according to the handover command.

[0070] Figure 9 shows an example of the operation of UE100 according to the first embodiment. UE100 supports multicast reception in an RRC inactive state and is assumed to be already participating in a multicast session.

[0071] In step S101, UE100, which is in an RRC connected state in the cell of gNB200, receives configuration information, including mobility settings, from gNB200. For example, UE100 receives configuration information, including mobility settings, from gNB200 on the DCCH (i.e., via dedicated signaling). The dedicated signaling may be an RRC Reconfiguration message or an RRC Release message. The dedicated signaling may include PTM settings for a multicast session. Based on these PTM settings, UE100 may receive the multicast session from gNB200 on the MTCH.

[0072] In step S102, UE100 transitions from the RRC connected state to the RRC inactive state. If step S101 is performed with an RRC Reconfiguration message, UE100 receives an RRC Release message from gNB200 to transition to the RRC inactive state, and transitions to the RRC inactive state in response to the receipt of the RRC Release message.

[0073] In step S103, UE100, which is in an RRC inactive state in the gNB200 cell, receives a multicast session from gNB200 on the MTCH based on the PTM settings from gNB200.

[0074] In step S104, the UE100, which is in an RRC inactive state, determines whether the conditions for cell reselection have been met. For example, the UE100 determines whether the conditions described for step S23 in Figure 8 have been met. If the conditions for cell reselection have not been met (step S104: NO), the UE100 continues to receive multicast sessions in the current serving cell (the cell of gNB200).

[0075] If the conditions for cell reselection are met (step S104: YES), in step S105, UE100 determines whether cell reselection is permitted (i.e., whether it should transition to the RRC connected state before cell reselection) based on the mobility settings in step S101.

[0076] If cell reselection is not permitted (step S105: NO), in step S108, UE100 performs the RRC recovery procedure and transitions from the RRC inactive state to the RRC connected state. The RRC recovery procedure includes sending an RRC recovery request message from UE100 to gNB200 and sending an RRC recovery message from gNB200 to UE100. UE100 may include an information element (Resume Cause) indicating that the RRC recovery request message is for receiving the multicast session. In step S109, UE100, having transitioned to the RRC connected state, performs a handover from the current serving cell to another cell under the control of gNB200.

[0077] If cell reselection is permitted (step S105: YES), in step S106, the RRC-inactive UE100 may determine whether it can receive MCCH and / or MTCH from the adjacent cell that is a candidate for cell reselection. If it determines that it can receive MCCH and / or MTCH from the adjacent cell, the RRC-inactive UE100 may start receiving MCCH and / or MTCH from the adjacent cell in the current serving cell and proceed to step S107. On the other hand, if it determines that it cannot receive MCCH and / or MTCH from the adjacent cell (step S106: NO), the RRC-inactive UE100 may proceed to step S108. However, step S106 is not mandatory and may be omitted.

[0078] In step S107, the UE100, which is in an RRC inactive state, performs cell reselection from the current serving cell to another cell (adjacent cell).

[0079] Figure 10 shows an example of the operating environment of the mobile communication system 1 according to the first embodiment. The UE100 is assumed to support multicast reception in an RRC inactive state and to have already joined a multicast session.

[0080] UE100 transitions from the RRC connected state to the RRC inactive state in cell a (the current serving cell) of gNB200a. In the RRC inactive state, UE100 receives a multicast session from gNB200a (cell a) on the MTCH and moves towards cell b (the adjacent cell) of gNB200b. An Xn interface, which is an inter-base station interface, exists between gNB200a and gNB200b. Inter-base station communication between gNB200a and gNB200b is assumed to take place over the Xn interface.

[0081] In the illustrated example, cells a and b are managed by different gNB200s, but cells a and b may be managed by the same gNB200. In the following description of the first embodiment, it will be assumed that cells a and b are managed by different gNB200s.

[0082] Figure 11 shows an example of the operation of the mobile communication system 1, based on the operating environment shown in Figure 10.

[0083] In step S131, UE100 is in the RRC connected state and has joined the multicast session.

[0084] In step S132, gNB200a may query gNB200b for the multicast session (MBS session) provided in cell b of gNB200b. In step S133, gNB200b may, in response to the query, send information about the multicast session (MBS session) provided in cell b (e.g., MBS session ID) to gNB200a.

[0085] In step S134, gNB200a decides to have UE100 perform multicast reception in an RRC inactive state.

[0086] In step S135, gNB200a may send an RRC Reconfiguration message containing PTM settings to UE100 on DCCH. The PTM settings may include mobility settings. As described above, the mobility settings may be information elements indicating whether or not to allow cell reselection in an RRC inactive state. The mobility settings may also be information elements indicating whether or not to perform RRC recovery before cell reselection by UE100. The mobility settings may also be information elements that apply only when receiving a multicast session.

[0087] In step S136, UE100 may receive a multicast session from gNB200a (cell a) on the MTCH based on the PTM settings in step S135.

[0088] In step S137, gNB200a sends an RRC Release message to UE100, and UE100 transitions from the RRC Connected state to the RRC Inactive state. Alternatively, PTM settings may be provided to UE100 in the RRC Release message instead of providing them in step S135. The PTM settings in the RRC Release message may include the mobility settings described above.

[0089] In step S138, UE100, which is in an RRC inactive state, receives a multicast session from gNB200a (cell a) on the MTCH.

[0090] In step S139, the UE100, which is in an RRC inactive state, decides to perform RRC recovery before cell reselection, as shown in steps S104, S105, and S108 in Figure 9.

[0091] In step S140, UE100 transitions from the RRC inactive state to the RRC connected state through the RRC recovery procedure.

[0092] In step S141, the UE100 in RRC connected state may send a measurement report, including the measurement results for cell b, to the gNB200a when the trigger condition for measurement reporting is met.

[0093] In step S142, gNB200a determines the handover (HO) of UE100 from cell a to cell b. Here, if cell b is providing the multicast session that UE100 is receiving, gNB200a may prioritize selecting cell b as the HO destination (target cell, HO Request destination). On the other hand, if cell b is not providing the multicast session that UE100 is receiving, gNB200a may configure UE100 to have a data radio bearer (DRB) for unicast reception of the multicast session.

[0094] In step S143, gNB200a sends an HO Request message to gNB200b on the Xn interface. The HO Request message may include information about the multicast session being received by UE100 (MBS session ID). This information may be included as part of the UE Context in the HO Request message.

[0095] In step S144, gNB200b sends an HO Request Ack message to gNB200a on the Xn interface in response to the HO Request message from gNB200a. The HO Request Ack message may include multicast MRB settings (PTM settings) for the multicast session being received by UE100. Alternatively, the HO Request Ack message may include DRB settings for unicast reception of the multicast session being received by UE100. These settings may be included in the RRC Reconfiguration message container within the HO Request Ack message.

[0096] In step S145, gNB200a sends an RRC Reconfiguration message (HO Command) for handover to UE100, which is in the RRC connected state.

[0097] In step S146, the UE100, in the RRC connected state, accesses cell b, which is the target cell, in response to receiving an RRC Reconfiguration message (HO Command) from gNB200a.

[0098] In step S147, the UE100 in RRC connected state receives a multicast session from gNB200b (cell b) based on the settings (multicast MRB settings or DRB settings) included in the RRC Reconfiguration message (HO Command) from gNB200a.

[0099] (2) Second Embodiment The second embodiment will be described primarily in terms of its differences from the first embodiment. Note that the second embodiment may be implemented in combination with the first embodiment.

[0100] For a UE100 that performs multicast reception while RRC is inactive, one possible approach is to start receiving the MCCH and / or MTCH of an adjacent cell while it is still in the current serving cell, thereby ensuring smooth service continuity during and after cell reselection to that adjacent cell.

[0101] However, this method does not necessarily guarantee that the required Quality of Service (QoS) for multicast sessions will be met. From a network perspective, it is desirable to be able to monitor and control whether the required QoS for multicast sessions is being met.

[0102] In the second embodiment, UE100, which receives a multicast session from gNB200 in the RRC inactive state, measures the QoS of the multicast session. If UE100 determines that the QoS does not meet a predetermined quality of service (hereinafter referred to as "QoS requirement"), it transitions from the RRC inactive state to the RRC connected state. UE100 may make this determination before cell reselection, specifically when the conditions for cell reselection (see the first embodiment) are met. This allows network 5 (gNB200) to control the serving cell switching of UE100 by handover rather than cell reselection, making it easier to satisfy the QoS requirements of the multicast session.

[0103] Here, the QoS measured by the UE100 in an RRC inactive state for a multicast session (i.e., the QoS to be measured) is at least one of the following: packet loss rate (packet error rate) or block error rate of packets received in the multicast session, packet delay time, and packet jitter (delay fluctuation). The QoS to be measured may also be the reference signal received power (RSRP) or reference signal received quality (RSRQ) for the multicast session. Note that in the UE100, QoS measurement may be performed at a layer higher than the AS layer (e.g., the application layer), and the measurement results may be notified to the AS layer from that higher layer.

[0104] The QoS requirements (also referred to as "QoS thresholds") that are compared to the QoS measured by the UE100 (also referred to as "measured QoS") may be set in the UE100 by the gNB200. That is, the UE100 receives information specifying the QoS threshold from the gNB200 and compares the QoS threshold specified by the gNB200 with the measured QoS. This makes it easier to meet the QoS requirements for multicast sessions.

[0105] Figure 12 shows an example of the operation of UE100 according to the second embodiment. UE100 supports multicast reception in the RRC inactive state and is assumed to be already participating in a multicast session. Prior to the operation shown in Figure 12, UE100 may be receiving a multicast session in the RRC connected state. Note that this explanation will primarily focus on the differences from the first embodiment (Figure 9), and redundant explanations of operations that overlap with the first embodiment (Figure 9) will be omitted.

[0106] In step S201, the UE100 in RRC connected state receives configuration information (also referred to as "QoS information") from the gNB200 on the DCCH regarding the QoS requirements that must be met when receiving multicast in the RRC inactive state.

[0107] QoS information includes QoS thresholds. QoS thresholds may be set for each multicast session (each MBS session). For example, QoS information may include multiple sets of MBS session IDs and QoS thresholds. QoS thresholds may be set for each type of QoS being measured. QoS thresholds may also be indices that represent QoS as defined in the technical specifications, such as 5QI (QoS Indicator).

[0108] QoS information may include information that sets the QoS measurement conditions. For example, this information may include information such as measuring the packet loss rate in the most recent 100 packets, or measuring the average received delay amount in the most recent 100 packets.

[0109] In step S202, UE100 transitions from the RRC connected state to the RRC inactive state.

[0110] In step S203, UE100, in an RRC inactive state, continues (or starts) receiving the multicast session. UE100 then measures the QoS for the multicast session.

[0111] In step S204, the UE100 in the RRC inactive state determines whether the QoS requirements are met by comparing the measured QoS with the QoS threshold. If the QoS requirements are not met (step S204: NO), in step S209, the UE100 transitions from the RRC inactive state to the RRC connected state.

[0112] If the QoS requirements are met (step S204: YES), in step S205, the RRC-inactive UE100 determines whether the conditions for cell reselection have been met. For example, the UE100 determines whether the conditions described for step S23 in Figure 7 have been met. If the conditions for cell reselection have not been met (step S205: NO), the UE100 continues to receive multicast sessions in the current serving cell (the cell of the gNB200) (step S203).

[0113] If the conditions for cell reselection are met (step S205: YES), in step S206, the UE100 in the RRC inactive state determines whether it can receive MCCH and / or MTCH from the adjacent cell that is a candidate for cell reselection. If it is not possible to receive MCCH and / or MTCH from the adjacent cell (step S206: NO), in step S209, the UE100 transitions from the RRC inactive state to the RRC connected state.

[0114] If MCCH and / or MTCH can be received from the adjacent cell (step S206: YES), in step S207, UE100 performs a QoS measurement on the candidate cell and determines whether the QoS requirements are met. Here, UE100 may determine that the QoS requirements are not met, for example, if it determines that the sequence number of the MTCH packet of the adjacent cell is greater than the sequence number of the MTCH packet of the current serving cell, and that packet loss due to the sequence number gap will occur. If it is determined that the QoS requirements are not met (step S207: NO), in step S209, UE100 transitions from the RRC inactive state to the RRC connected state.

[0115] If it is determined that the QoS requirements are met (step S207: YES), in step S208, the UE100 in the RRC inactive state performs cell reselection from the current serving cell to another cell (the adjacent cell).

[0116] On the other hand, if UE100 transitions to the RRC connected state (i.e., RRC recovery) in step S209, a handover is performed under the control of gNB200 in step S210. The details of such a handover procedure are the same as in the first embodiment. Here, the RRC recovery request message that UE100 sends to gNB200 in step S209 may include an information element as a Resume Cause indicating that it is for multicast session reception (or to satisfy multicast session QoS requests).

[0117] Note that in the flowchart of Figure 12, the order of the determination in step S206 and the determination in step S207 may be reversed.

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

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

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

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

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

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

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

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

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

[0127] (4) Note (Note 1) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The steps include: a user device in a Wireless Resource Control (RRC) connected state receiving configuration information from a network node; The user device, which has transitioned from the RRC connected state to the RRC inactive state, receives a multicast session in the network node cell, The aforementioned configuration information includes an information element indicating whether or not to allow the user device receiving the multicast session in the RRC inactive state to reselect a cell to another cell. Communication method.

[0128] (Note 2) The user device receiving the multicast session in the RRC inactive state further has the step of transitioning to the RRC connected state before performing the cell reselection, based on the information element indicating that it does not permit the cell reselection. The communication method described in Appendix 1.

[0129] (Note 3) When the user device, which has transitioned to the RRC connected state, receives a handover command from the network node, it further includes the step of accessing other cells providing the multicast session in accordance with the handover command. The communication method described in Appendix 2.

[0130] (Note 4) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The steps include: A user device in an RRC inactive state receives a multicast session from a network node, The user device measures the quality of service of the multicast session, The user device has a step of transitioning from the RRC inactive state to the RRC connected state if it determines that the service quality does not meet a predetermined service quality. Communication method.

[0131] (Note 5) The user device further includes the step of receiving information specifying the predetermined quality of service from the network node. The communication method described in Appendix 4.

[0132] (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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0150] 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]

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

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

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

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

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

[0156] 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 primary assumption.

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

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

[0159] (6) Addendum 1. Introduction The work items related to strengthening MBS (eMBS) are as follows: Identify support for multicast reception by UE in 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].

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

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

[0162] 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0211] 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]

[0212] 1: Mobile communication systems 5: Network 10: RAN 20:CN 100: UE (User Device) 110: Receiver 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), The user device receives a Radio Resource Control (RRC) Release message from a network node that contains information specifying thresholds, The user device in an RRC inactive state receives a multicast session from the network node, The user device measures the reference signal reception quality (RSRQ) for the multicast session, The user device transitions from the RRC inactive state to the RRC connected state in response to determining that the RSRQ does not meet the threshold. Communication method.

2. The threshold is set for each multicast session. The communication method according to claim 1.

3. The user device receives a plurality of sets, each of which includes an MBS session ID and information specifying the threshold. The communication method according to claim 2.

4. The user device compares the RSRQ with the threshold for the multicast session in which the user device has joined and is currently receiving. The communication method according to claim 1.

5. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), A receiving unit that receives a wireless resource control (RRC) Release message containing threshold information from a network node, and then receives a multicast session from the network node while in an RRC inactive state, It includes a control unit for measuring the reference signal reception quality (RSRQ) for the multicast session, The control unit, in response to determining that the RSRQ does not meet the threshold, transitions from the RRC inactive state to the RRC connected state. User device.

6. A network node used in a mobile communication system that provides multicast / broadcast services (MBS), The device has a transmitting unit that sends an RRC Release message to a user device that receives a multicast session, which includes information specifying a threshold used for comparison with the reference signal reception quality (RSRQ) for the multicast session when transitioning the user device from a Radio Resource Control (RRC) inactive state to an RRC connected state. Network node.

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

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

9. The user device is as described in claim 5, and the network node is as described in claim 6. Mobile communication system.

Images