Communication method

Abstract

A communication method for use in a mobile communication system to provide a multicast / broadcast service (MBS), the method comprising the steps of: receiving configuration information from a base station by a user equipment in a radio resource control (RRC) connected state; and the user equipment transitioning from the RRC connected state to the RRC inactive state receives the multicast session in the cell of the base station. The configuration information includes an information element indicating whether a user equipment receiving a multicast session in an RRC inactive state is allowed to reselect a cell to another cell.

Description

Technical Field

[0001] This disclosure relates to a communication method used in a mobile communication system. Background Technology

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

[0003] In 3GPP Release 17, MBS multicast reception (i.e., multicast reception) could only be supported by user equipment in a Radio Resource Control (RRC) connected state (see, for example, Non-Patent Document 1). On the other hand, in 3GPP Release 18, the technical specifications were planned to be extended so that user equipment in an RRC inactive state could perform multicast reception.

[0004] Reference List

[0005] Non-patent literature

[0006] Non-patent document 1: 3GPP technical specification: TS 38.300 V17.3.0. Summary of the Invention

[0007] The communication method according to the first aspect is a communication method for providing multicast / broadcast service (MBS) in a mobile communication system, the communication method comprising: receiving configuration information from a network node by a user equipment in a Radio Resource Control (RRC) connected state; and receiving a multicast session in a cell of the network node by a user equipment that has transitioned from an RRC connected state to an RRC inactive state. The configuration information includes information elements indicating whether a user equipment receiving a multicast session in an RRC inactive state is permitted to perform cell reselection to another cell.

[0008] The communication method according to the second aspect is a communication method for providing multicast / broadcast service (MBS) in a mobile communication system, the communication method comprising: receiving a multicast session from a network node by a user equipment in an RRC inactive state; measuring the quality of service of the multicast session by the user equipment; and when the user equipment determines that the quality of service does not meet a predetermined quality of service, switching the user equipment from the RRC inactive state to the RRC connected state. Attached Figure Description

[0009] Figure 1 This is a configuration diagram of a mobile communication system according to an embodiment.

[0010] Figure 2 This is a configuration diagram of a user equipment (UE) according to an embodiment.

[0011] Figure 3 This is a configuration diagram of a gNB (base station) according to an embodiment.

[0012] Figure 4 This is a configuration diagram showing the protocol stack of the radio interface for the user plane that processes data.

[0013] Figure 5 This is a configuration diagram of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0014] Figure 6 This is a diagram illustrating the MBS broadcast configuration message in the MCCH as defined in the RRC technical specification (TS 38.331).

[0015] Figure 7 This is an overview diagram showing how a UE 100 in an RRC inactive state can perform multicast reception operations.

[0016] Figure 8 This is a flowchart illustrating a typical cell reselection process.

[0017] Figure 9 This is a flowchart illustrating an operational example of a UE according to a first embodiment.

[0018] Figure 10 This is a diagram illustrating the operating environment of a mobile communication system according to a first embodiment.

[0019] Figure 11 It shows that based on Figure 10 The diagram illustrates the operation of a mobile communication system within its operating environment.

[0020] Figure 12 This is a flowchart illustrating an operational example of a UE according to a second embodiment.

[0021] Figure 13 This is a diagram illustrating the PTM configuration delivery process for activating a multicast session. Detailed Implementation

[0022] A mobile communication system according to an embodiment is described with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.

[0023] (1) First embodiment

[0024] refer to Figures 1 to 10 The first embodiment is described.

[0025] (1.1) System Configuration

[0026] Figure 1 This diagram illustrates a configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard for a fifth-generation system (5GS). The following description uses 5GS as an example, but a Long Term Evolution (LTE) system can be at least partially applied to the mobile communication system. Alternatively, a sixth-generation (6G) system can be at least partially applied to the mobile communication system.

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

[0028] UE 100 is a mobile wireless communication device. UE 100 can be any device as long as it is used by a user. Examples of UE 100 include mobile phone terminals (including smartphones) and / or tablet terminals, laptop PCs, communication modules (including communication cards or chipsets), sensors or devices mounted on sensors, vehicles or devices mounted on vehicles (vehicle UE), or flying objects and devices mounted on flying objects (airborne UE).

[0029] NG-RAN 10 includes base stations (referred to as "gNBs" in 5G systems) 200. gNBs 200 are interconnected via an Xn interface, which serves as an inter-base station interface. Each gNB 200 manages one or more cells. gNBs 200 perform wireless communication with UE 100, which has established a connection with a cell of the gNB 200. gNBs 200 have radio resource management (RRM) functions, functions for routing user data (hereinafter referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to represent the smallest unit of a wireless communication area. "Cell" is also used as a term to represent the functions or resources used to perform wireless communication with UE 100. A cell belongs to a carrier frequency (hereinafter referred to as "frequency").

[0030] Note that a gNB can connect to the Evolved Packet Core (EPC) corresponding to the LTE core network. LTE base stations can also connect to the 5GC. LTE base stations and gNBs can connect via an inter-base station interface.

[0031] The 5GC 20 includes Access and Mobility Management Functions (AMF) and User Plane Functions (UPF) 300. The AMF performs various types of mobility control for the UE 100. The AMF manages the mobility of the UE 100 by communicating with it using Non-Access Stratum (NAS) signaling. The UPF controls data transmission. The AMF and UPF are connected to the gNB 200 via the NG interface, which serves as the interface between the base station and the core network.

[0032] Figure 2 This diagram illustrates a configuration of a UE 100 (User Equipment) according to an embodiment. UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and transmitter 120 constitute a wireless communication device that performs wireless communication with the gNB 200.

[0033] Receiver 110 performs various types of reception under the control of controller 130. Receiver 110 includes an antenna and receiving equipment. The receiving equipment converts the radio signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 130.

[0034] Transmitter 120 performs various types of transmissions under the control of controller 130. Transmitter 120 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 130 into a radio signal and transmits the obtained signal through the antenna.

[0035] Controller 130 performs various types of control and processing within UE 100. This processing includes the processing of the various layers described later. The operations of UE 100 described above and below can also be performed under the control of controller 230. Controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be processed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0036] Figure 3 This diagram illustrates a configuration of a gNB 200 (base station) according to an embodiment. The gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240. The transmitter 210 and receiver 220 constitute a wireless communication device for performing wireless communication with the UE 100. The backhaul communicator 240 constitutes a network communicator for performing communication with the CN 20.

[0037] Transmitter 210 performs various types of transmissions under the control of controller 230. Transmitter 210 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 230 into a radio signal and transmits the obtained signal through the antenna.

[0038] Receiver 220 performs various types of reception under the control of controller 230. Receiver 220 includes an antenna and receiving equipment. The receiving equipment converts the radio signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 230.

[0039] Controller 230 performs various types of control and processing within gNB 200. This processing includes the processing of the various layers described later. The operations of gNB 200 described above and below can also be performed under the control of controller 230. Controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be processed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0040] The backhaul communicator 240 is connected to the adjacent base station via the Xn interface, which serves as an inter-base station interface. The backhaul communicator 240 is connected to the AMF / UPF 300 via the NG interface between the base station and the core network. Note that the gNB 200 may include a central unit (CU) and a distributed unit (DU) (i.e., functions are divided), and these two units may be connected via the F1 interface, which serves as a fronthaul interface.

[0041] Figure 4 This is a configuration diagram showing the protocol stack of the radio interface for the user plane that processes data.

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

[0043] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and demapping, and resource mapping and demapping. Data and control information are transmitted between the PHY layers of UE 100 and gNB 200 via physical channels. Note that the PHY layer of UE 100 receives downlink control information (DCI) transmitted from gNB 200 via the Physical Downlink Control Channel (PDCCH). Specifically, UE 100 blindly decodes the PDCCH using the Radio Network Temporary Identifier (RNTI) and obtains the successfully decoded DCI as the DCI addressed to UE 100. The DCI transmitted from gNB 200 is appended with CRC (Cyclic Redundancy Check) parity bits scrambled by the RNTI.

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

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

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

[0047] The SDAP layer performs the mapping between IP flows (as a unit of Quality of Service (QoS) control performed by the core network) and radio bearers (as a unit of QoS control performed by the access layer (AS)). Note that SDAP is not required when the RAN is connected to the EPC.

[0048] Figure 5 This is a configuration diagram of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0049] The protocol stack for the control plane's radio interface includes a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer, rather than... Figure 4 The SDAP layer is shown.

[0050] RRC signaling for various configurations is transmitted between the RRC layer of UE 100 and the RRC layer of gNB 200. The RRC layer controls logical channels, transport channels, and physical channels based on the establishment, reconstruction, and release of radio bearers. UE 100 is in an RRC connected state when a connection (RRC connection) is established between the RRC layers of UE 100 and gNB 200. UE 100 is in an RRC idle state when no connection (RRC connection) is established between the RRC layers of UE 100 and gNB 200. UE 100 is in an RRC inactive state when the connection between the RRC layers of UE 100 and gNB 200 is suspended.

[0051] The NAS layer (also simply "NAS"), located above the RRC layer, performs session management, mobility management, and other functions. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF 300A. Note that UE100 includes an application layer in addition to the radio interface protocol. Each layer below the NAS layer is referred to as an AS layer (also simply "AS").

[0052] (1.2) MBS

[0053] Mobile communication system 1 can perform transmission with high resource efficiency by using multicast / broadcast service (MBS). Note that a session refers to the communication sequence of a service (application) (from start to finish), and an MBS session refers to the session used in the MBS.

[0054] In the case of multicast communication service (also known as "MBS multicast"), the same service and the same specific content data are provided simultaneously to a specific group of UEs. That is, not every UE 100 in the multicast service area is allowed to receive data. The multicast communication service is delivered to UE 100 using a multicast session (which is a type of MBS session). UE 100 can receive the multicast communication service in RRC connected state using mechanisms such as point-to-point (PTP) and / or point-to-multipoint (PTM) delivery. UE 100 can also receive the multicast communication service in RRC inactive (or RRC idle) state. This delivery mode will also be referred to as "delivery mode 1". Note that UE 100 can only receive multicast sessions after joining a multicast session. Here, joining a multicast session can mean that UE 100 registers in network 5 (CN 20) as capable of receiving multicast sessions.

[0055] In the case of broadcast communication service (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to every UE100 in a geographical area. That is, every UE100 in the broadcast service area is allowed to receive data. The broadcast communication service is delivered to UE100 using a broadcast session (which is a type of MBS session). UE100 can receive the broadcast communication service in any state: RRC idle state, RRC inactive state, and RRC connected state. This delivery mode will also be referred to as "delivery mode 2".

[0056] The main logical channels used for MBS transmission are the Multicast Service Channel (MTCH), the Dedicated Service Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel used to transmit MBS data for multicast and / or broadcast sessions from network 10 to UE 100. The DTCH is a PTP channel used to transmit MBS data for multicast sessions from network 10 to UE 100. The MCCH is a PTM downlink channel used to transmit MBS broadcast control information associated with one or more MTCHs from network 10 to UE 100. In transmission mode 1, the Dedicated Control Channel (DCCH) is used to perform MBS configuration on UE 100.

[0057] For the transmission of MBS data packets (also referred to as "MBS packets"), in MBS multicast, either point-to-point (PTP) transmission or point-to-multipoint (PTM) transmission, corresponding to unicast, can be applied. On the other hand, in MBS broadcast, only PTM transmission can be applied. For PTP transmission, the gNB 200 can independently transmit a separate copy of the MBS packet to each UE 100. For example, the gNB 200 uses a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) to schedule a UE-specific PDSCH scrambled by a UE-specific RNTI. On the other hand, for PTM transmission, the gNB 200 transmits a single copy of the MBS packet to a group(s) of UEs(s). For example, the gNB 200 uses a group-common PDCCH with a CRC scrambled by a group-common RNTI (e.g., G-RNTI) to schedule a group-common PDSCH scrambled by a group-common RNTI.

[0058] Regarding the configuration of MBS broadcasts, UE 100 in RRC idle, RRC inactive, or RRC connected states receives the PTM configuration (e.g., parameters required for MTCH reception) of the broadcast session via the MCCH. The parameters required for MCCH reception (MCCH configuration) are provided through system information. More specifically, System Information Block / Type 20 (SIB 20) includes the MCCH configuration. Note that SIB Type 21 (SIB 21) includes information related to service continuity for MBS broadcast reception. The MCCH provides a list of all broadcast services (including ongoing sessions) transmitted on the MTCH, and information related to the broadcast session includes the MBS session identifier (e.g., Temporary Mobile Group Identifier (TMGI)), relevant MTCH scheduling information, and information related to neighboring cells providing specific services on the MTCH.

[0059] On the other hand, for MBS multicast, the current 3GPP technical specifications enable UE 100 to receive multicast session data only in RRC connected state. When UE 100, which has joined a multicast session, is in RRC connected state and the multicast session is activated, gNB 200 sends an RRC reconfiguration message to UE 100 including the PTM configuration associated with the multicast session. This PTM configuration is also known as the Multicast Radio Bearer (MRB) configuration, MTCH configuration, or PTM configuration. This MRB configuration (MRB-ToAddMod) includes the MBS session identifier (mbs-SessionId), the MRB identifier (mrb-Identity), and other parameters of the MRB (multicast MRB) to be configured for UE 100 (such as PDCP configuration (pdcp-Config)).

[0060] In the following embodiments, the operation of enabling UE 100, which is in an RRC inactive state, to perform multicast reception will be described in detail. Figure 6 This is an overview diagram showing the operation.

[0061] As a solution to enable UE 100 in an RRC inactive state to perform multicast reception, consider based on Figure 6 The solution for transmission mode 1 shown in (a) and based on Figure 6 Solution for transmission mode 2 shown in (b). Assume UE100 supports multicast reception in RRC inactive state and has joined a multicast session.

[0062] Based on Figure 6In the solution of transmission mode 1 shown in (a), in step S1, gNB 200 sends an RRC reconfiguration message to UE 100 in RRC connection state, which includes MBS configuration (PTM configuration) related to the multicast session. Based on the PTM configuration received in the RRC reconfiguration message, UE 100 receives multicast data on MTCH via multicast session (multicast MRB).

[0063] In step S2, gNB 200 sends an RRC Release message to UE 100, which is in an RRC connected state, to transition UE 100 to an RRC inactive state. The RRC Release message includes the configuration (suspend configuration) for the RRC inactive state.

[0064] In step S3, in response to receiving the RRC release message in step S2, UE 100 transitions from the RRC connected state to the RRC inactive (INACTIVE) state.

[0065] In step S4, UE 100, which is in an RRC inactive state, continues to use the PTM configuration in step S1 to receive multicast data on MTCH via a multicast session.

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

[0067] Both the RRC reconfiguration message and the RRC release message are RRC messages sent to each UE on the dedicated control channel (DCCH), and are also referred to below as dedicated RRC messages or dedicated signaling.

[0068] On the other hand, Figure 7 In the solution based on transmission mode 2 shown in B, in step S11, gNB 200 sends an RRC release message to UE 100, which is in RRC connected state, to cause UE 100 to switch to RRC inactive state. The RRC release message includes the configuration (suspend configuration) for RRC inactive state.

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

[0070] In step S13, gNB 200 transmits the MCCH, which includes the MBS configuration (PTM configuration) for the multicast session. UE 100 receives the MCCH. Note that UE 100 receives SIB 20 before receiving the MCCH and receives the MCCH based on SIB 20. Note that MCCH transmission (and reception) can be performed before or concurrently with step S11.

[0071] In step S14, UE 100, which is in an RRC inactive state, receives multicast data on the MTCH through a multicast session based on the PTM configuration received on the MCCH in step S13. This enables UE 100, which is in an RRC inactive state, to perform multicast reception.

[0072] A hybrid solution based on transport mode 1 and transport mode 2 is also envisioned. For example, a hybrid configuration approach could also be adopted, in which the initial configuration of MBS configuration (PTM configuration) is performed via dedicated signaling, and the update of MBS configuration (PTM configuration) is performed on MCCH.

[0073] (1.3) Cell reselection

[0074] Figure 7 This diagram illustrates a typical cell reselection process. When UE 100 moves, UE 100 in an RRC idle or inactive state performs a cell reselection process to migrate from its current serving cell (cell #1) to a neighboring cell (any one of cells #2 to #4). More specifically, UE 100 identifies the neighboring cell where it should camp and reselects the identified neighboring cell through the cell reselection process. When the current serving cell and the neighboring cell share the same frequency (carrier frequency), it is called intra-frequency; when they differ, it is called inter-frequency. The current serving cell and the neighboring cell can be managed by the same gNB 200. Alternatively, the current serving cell and the neighboring cell can be managed by different gNBs 200.

[0075] Figure 8 This is a flowchart illustrating a typical cell reselection process.

[0076] In step S21, UE 100 performs frequency prioritization based on the priority (also referred to as "absolute priority", "cell reselection priority", or "dedicated priority") of each frequency specified by gNB 200 in, for example, a System Information Block (SIB) or RRC release message. More specifically, UE 100 manages the frequency priority specified by gNB 200 for each frequency.

[0077] In step S22, UE 100 performs a measurement process to measure the radio quality of the serving cell and each neighboring cell. UE 100 measures the received power and received quality of the reference signals (more specifically, CD-SSB (Cell Defined Synchronization Signal and PBCH Block)) transmitted by the serving cell and each neighboring cell. For example, UE 100 always measures the radio quality of frequencies with a frequency priority higher than that of the current serving cell, while measuring the radio quality of frequencies with a frequency priority equal to or lower than that of the current serving cell when the radio quality of the frequencies in the current serving cell is lower than a predetermined quality.

[0078] In step S23, UE 100 performs cell reselection processing based on the measurement results in step S22, that is, reselects the cell where UE 100 itself is camped. For example, when the frequency priority of a neighboring cell is higher than the priority of the current serving cell and the neighboring cell meets a predetermined quality standard (i.e., the minimum quality standard) within a predetermined time period, UE 100 can perform cell reselection to the neighboring cell. When the frequency priority of a neighboring cell is the same as the priority of the current serving cell, UE 100 can rank the radio quality of the neighboring cells and perform cell reselection to the neighboring cell ranked higher than the current serving cell within a predetermined time period. When the frequency priority of a neighboring cell is lower than the priority of the current serving cell, and when the radio quality of the current serving cell remains below a threshold and the radio quality of the neighboring cell remains above another threshold within a predetermined time period, UE 100 can perform cell reselection to the neighboring cell.

[0079] Note that UE 100 supporting MBS in RRC idle or RRC inactive states is eligible for the above cell reselection, but with the following changes: Specifically, when a UE 100 receiving or interested in receiving MBS broadcast services via Point-to-Multipoint (PTM) can only receive these MBS broadcast services by camping on a frequency that provides these MBS broadcast services, the UE 100 is allowed to set that frequency as the highest priority (higher than the priority of other network configurations). This frequency prioritization also applies to multicast reception in RRC inactive states.

[0080] On the other hand, when the MBS broadcast service that UE 100 is interested in is unavailable (after the session ends), or when UE 100 is no longer interested in receiving the broadcast service, UE 100 does not prioritize that frequency. UE 100 that is receiving or is interested in receiving MBS broadcast services via PTM is allowed to set frequencies where these MBS broadcast services cannot be received to the lowest frequency (lower priority than other network configurations). This frequency prioritization process can also be applied to multicast reception during RRC inactivity.

[0081] (1.4) Operation according to the first embodiment

[0082] The first embodiment is an example of cell reselection performed by UE 100 performing multicast reception in an RRC inactive state.

[0083] In 3GPP Release 17, only UE 100 in RRC connected state can receive MBS multicast. Therefore, the serving cell of UE 100 performing multicast reception in RRC connected state can be switched via handover, and interruption of multicast reception during cell handover can be suppressed.

[0084] On the other hand, in 3GPP Release 18, UE 100, even in an RRC inactive state, can receive MBS multicast. Therefore, cell reselection switches the serving cell of UE 100, which was performing multicast reception in an RRC inactive state. In this case, cell reselection may lead to multicast reception interruption or disruption.

[0085] Here, in 3GPP Release 18, it is assumed that multicast reception does not require seamless / lossless mobility in the RRC inactive state. However, some multicast sessions received by UE 100 in the RRC inactive state may require seamless / lossless mobility. For example, in a scenario where gNB 200 temporarily transitions UE 100 to the RRC inactive state due to network congestion, UE 100 may receive multicast sessions requiring seamless / lossless mobility. In this case, Network 5 (gNB 200) may expect to control the handover of UE 100's serving cell through handover rather than cell reselection.

[0086] In the first embodiment, gNB 200 sends configuration information to UE 100, which is in RRC connected state. UE 100 receives the configuration information. UE 100, which has transitioned from RRC connected state to RRC inactive state, receives multicast sessions in the cell of gNB 200. The configuration information includes information elements indicating whether UE 100, which is receiving multicast sessions in RRC inactive state, is allowed to perform cell reselection to another cell (hereinafter referred to as "mobility configuration"). The mobility configuration may be information elements indicating whether UE 100, which is in RRC inactive state, should transition to RRC connected state before performing cell reselection.

[0087] Therefore, for example, it is possible to prevent UE 100, which requires seamless / lossless mobility to receive multicast sessions, from performing cell reselection to another cell, and to transition it to RRC connected state before cell reselection. Thus, the serving cell of UE 100 can be controlled by handover instead of cell reselection. Therefore, the continuity of multicast reception can be easily ensured.

[0088] For example, UE 100, which is receiving a multicast session in RRC inactive state, transitions to RRC connected state based on its mobility configuration (which indicates that cell reselection is not allowed) before performing cell reselection. UE 100, now in RRC connected state, can then receive a handover command from gNB 200 and access another cell providing the multicast session according to the handover command.

[0089] Figure 9 This is an example operation flowchart of UE 100 according to the first embodiment. It is assumed that UE 100 supports multicast reception in RRC inactive state and has joined a multicast session.

[0090] In step S101, UE 100, which is in an RRC connected state within the cell of gNB 200, receives configuration information including mobility configuration from gNB 200. For example, UE 100 receives configuration information including mobility configuration from gNB 200 on the DCCH (i.e., via dedicated signaling). The dedicated signaling can be an RRC reconfiguration message or an RRC release message. The dedicated signaling can include PTM configuration for multicast sessions. UE 100 can receive multicast sessions on the MTCH from gNB 200 based on the PTM configuration.

[0091] In step S102, UE 100 transitions from RRC connected state to RRC inactive state. When step S101 is executed via an RRC reconfiguration message, UE 100 receives an RRC release message from gNB 200 to transition UE 100 to RRC inactive state, and transitions to RRC inactive state in response to receiving the RRC release message.

[0092] In step S103, UE 100, which is in an RRC inactive state in the cell of gNB 200, receives a multicast session on MTCH from gNB 200 based on the PTM configuration from gNB 200.

[0093] In step S104, UE 100, which is in an RRC inactive state, determines whether it meets the conditions for cell reselection. For example, UE 100 determines whether it meets the conditions for cell reselection. Figure 8 The conditions described in step S23. When the cell reselection conditions are not met (step S104: No), UE 100 continues to receive multicast sessions in the current serving cell (the cell of gNB 200).

[0094] When the cell reselection condition is met (step S104: Yes), in step S105, UE 100 determines whether cell reselection is allowed (i.e., whether to switch to RRC connected state before cell reselection) based on the mobility configuration in step S101.

[0095] When cell reselection is not allowed (step S105: No), in step S108, UE 100 performs an RRC recovery procedure to transition from an RRC inactive state to an RRC connected state. The RRC recovery procedure includes sending an RRC recovery request message from UE 100 to gNB 200 and sending an RRC recovery message from gNB 200 to UE 100. UE 100 may send an RRC recovery request message that includes information elements (recovery reason) for receiving multicast sessions. In step S109, UE 100, which has transitioned to an RRC connected state, switches from its current serving cell to another cell under the control of gNB 200.

[0096] When cell reselection is permitted (step S105: Yes), in step S106, the UE 100 in the RRC inactive state can determine whether it can receive MCCH and / or MTCH from a neighboring cell that is a cell reselection candidate. When it is determined that MCCH and / or MTCH can be received from a neighboring cell, the UE 100 in the RRC inactive state can begin receiving MCCH and / or MTCH from the neighboring cell in the current serving cell and proceed to step S107. On the other hand, when it is determined that MCCH and / or MTCH cannot be received from a neighboring cell (step S106: No), the UE 100 in the RRC inactive state can proceed to step S108. However, step S106 is not required and can be omitted.

[0097] In step S107, UE 100, which is in an RRC inactive state, performs cell reselection from the current serving cell to another cell (neighboring cell).

[0098] Figure 10 This diagram illustrates the operating environment of a mobile communication system 1 according to a first embodiment. It is assumed that the UE 100 supports multicast reception in RRC inactive mode and has joined a multicast session.

[0099] UE 100 in cell a (current serving cell) of gNB 200a transitions from RRC connected state to RRC inactive state. While in RRC inactive state, UE 100 moves towards cell b (neighboring cell) of gNB 200b, simultaneously receiving multicast sessions on the MTCH from gNB 200a (cell a). Note that an Xn interface exists between gNB 200a and gNB 200b; this Xn interface is an inter-base station interface. Assume that inter-base station communication between gNB 200a and gNB 200b is performed via the Xn interface.

[0100] Note that in the example shown, cell a and cell b are managed by different gNB 200s, but cell a and cell b can be managed by the same gNB 200. In the following description of the first embodiment, it is assumed that cell a and cell b are managed by different gNB 200s.

[0101] Figure 11 It shows that based on Figure 10 The diagram shows an example of the operation of a mobile communication system 1 in its operating environment.

[0102] In step S131, UE 100 is in RRC connection state and has joined a multicast session.

[0103] In step S132, gNB 200a can query gNB 200b for the multicast session (MBS session) provided in cell b of gNB 200b. In step S133, gNB 200b responds to the query by sending information about the multicast session (MBS session) provided in cell b (e.g., MBS session ID) to gNB 200a.

[0104] In step S134, gNB 200a determines that UE 100, which is in an RRC inactive state, should perform multicast reception.

[0105] In step S135, gNB 200a may send an RRC reconfiguration message including PTM configuration to UE 100 on the DCCH. The PTM configuration may include mobility configuration. As described above, mobility configuration may be an information element indicating whether cell reselection is allowed in an RRC inactive state. Mobility configuration may be an information element indicating whether UE 100 should perform RRC recovery before cell reselection. Mobility configuration may be an information element that is only applied when a multicast session is received.

[0106] In step S136, UE 100 may receive a multicast session on MTCH from gNB 200a (cell a) based on the PTM configuration in step S135.

[0107] In step S137, gNB 200a sends an RRC release message to UE 100, and UE 100 transitions from an RRC connected state to an RRC inactive state. PTM configuration can be provided to UE 100 in the RRC release message, without needing to provide PTM configuration to UE 100 in step S135. The PTM configuration in the RRC release message can include the mobility configuration described above.

[0108] In step S138, UE 100, which is in an RRC inactive state, receives a multicast session on MTCH from gNB 200a (cell a).

[0109] In step S139, UE 100, which is in an RRC inactive state, determines that it will pass through before cell reselection. Figure 9 Steps S104, S105, and S108 perform RRC recovery.

[0110] In step S140, UE 100 transitions from an RRC inactive state to an RRC connected state through the RRC recovery process.

[0111] In step S141, when the triggering condition for the measurement report is met, the UE 100 in the RRC connection state can send a measurement report including the measurement results for cell b to gNB 200a.

[0112] In step S142, gNB 200a determines to hand over UE 100 from cell a to cell b. Here, when cell b is providing a multicast session that UE 100 is receiving, gNB 200a can preferentially select cell b as the HO destination (target cell, HO request transmission destination). On the other hand, when cell b is not providing a multicast session that UE 100 is receiving, gNB 200a can configure a data radio bearer (DRB) for UE 100 to receive multicast sessions via unicast.

[0113] In step S143, gNB 200a sends a HO request message to gNB 200b via the Xn interface. This HO request message may include information about the multicast session (MBS session ID) being received by UE 100. This information may be included in the HO request message as part of the UE context.

[0114] In step S144, gNB 200b responds to the HO request message from gNB 200a by sending an HO request response message to gNB 200a via the Xn interface. The HO request response message may include the multicast MRB configuration (PTM configuration) of the multicast session being received by UE 100. Alternatively, the HO request response message may include the DRB configuration for the unicast receive multicast session (which UE 100 is receiving). These configurations may be included in the RRC reconfiguration message container within the HO request response message.

[0115] In step S145, gNB 200a sends an RRC reconfiguration message (HO command) for handover to UE 100, which is in RRC connection state.

[0116] In step S146, UE 100, which is in RRC connection state, accesses cell b, which is the target cell, in response to receiving an RRC reconfiguration message (HO command) from gNB 200a.

[0117] In step S147, UE 100, which is in RRC connection state, receives a multicast session from gNB 200b (cell b) based on the configuration (multicast MRB configuration or DRB configuration) included in the RRC reconfiguration message (HO command) from gNB 200a.

[0118] (2) Second embodiment

[0119] A second embodiment is described, focusing on the differences from the first embodiment. Note that the second embodiment can be implemented in conjunction with the first embodiment.

[0120] The following approach can be envisioned: UE 100 performing multicast reception in an RRC inactive state, while existing in the current serving cell, for example, begins receiving MCCH and / or MTCH from a neighboring cell, thereby ensuring smooth service continuation during and after cell reselection to a neighboring cell.

[0121] However, this approach does not necessarily meet the Quality of Service (QoS) requirements of multicast sessions. From Network 5's perspective, it is desirable to monitor and control whether the QoS requirements of multicast sessions are met.

[0122] In the second embodiment, UE 100, which is in an RRC inactive state and receives a multicast session from gNB 200, measures the QoS of the multicast session. When UE 100 determines that the QoS does not meet the predetermined quality of service (hereinafter referred to as the "QoS requirement"), UE 100 transitions from the RRC inactive state to the RRC connected state. UE 100 can perform this determination before performing cell reselection (specifically, when the conditions for cell reselection are met (see the first embodiment)). This allows network 5 (gNB 200) to control the handover of UE 100's serving cell by handover instead of cell reselection, which is beneficial for meeting the QoS requirements of the multicast session.

[0123] Here, the QoS measured by the UE 100 in an RRC inactive state for a multicast session (i.e., the target QoS) is selected from 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 target QoS can be the reference signal received power (RSRP) or reference signal received quality (RSRQ) of the multicast session. Note that in the UE 100, QoS can be measured at a layer higher than the AS layer (e.g., the application layer, etc.), and the measurement results can be notified to the AS layer from that higher layer.

[0124] The base station (gNB) 200 can configure QoS requirements (also known as "QoS thresholds") for the UE 100 to be compared with the QoS measured by the UE 100 (also known as "measured QoS"). That is, the UE 100 receives information specifying the QoS threshold from the gNB 200 and compares the QoS threshold specified by the gNB 200 with the measured QoS. This is beneficial for meeting the QoS requirements of multicast sessions.

[0125] Figure 12 This is a flowchart illustrating an operational example of UE 100 according to the second embodiment. It is assumed that UE 100 supports multicast reception in RRC inactive mode and has already joined a multicast session. Figure 12 Prior to the operation, UE 100 may be receiving a multicast session in RRC connection state. Note that the following description will focus on the first embodiment ( Figure 9 The differences from the first embodiment are omitted. Figure 9 Repeated descriptions of repeated operations.

[0126] In step S201, UE 100 in RRC connection state receives configuration information (also referred to as "QoS information") on DCCH from gNB 200 related to the QoS requirements that multicast reception must meet in RRC inactive state.

[0127] QoS information includes QoS thresholds. QoS thresholds can be configured for each multicast session (each MBS session). For example, QoS information may include multiple sets of MBS session IDs and QoS thresholds. QoS thresholds can be configured for each type of measurement target QoS. QoS thresholds can be predefined in the technical specification as indices of QoS, such as 5QI (QoS Indicator).

[0128] QoS information may include information used to configure QoS measurement conditions. For example, this information may be used to measure the packet loss rate of the most recent 100 packets or to measure the average receive delay of the most recent 100 packets.

[0129] In step S202, UE 100 transitions from RRC connected state to RRC inactive state.

[0130] In step S203, UE 100, which is in an RRC inactive state, continues (or begins) to receive multicast sessions. UE 100 measures the QoS of the multicast sessions.

[0131] In step S204, the UE 100, which is in the RRC inactive state, compares the measured QoS with the QoS threshold to determine whether the QoS requirements are met. If the QoS requirements are not met (step S204: No), in step S209, the UE 100 transitions from the RRC inactive state to the RRC connected state.

[0132] When the QoS requirements are met (step S204: Yes), in step S205, UE 100, which is in an RRC inactive state, determines whether the conditions for cell reselection are met. For example, UE 100 determines whether the conditions for cell reselection are met. Figure 7 The conditions described in step S23. When the conditions for cell reselection are not met (step S205: No), UE 100 continues to receive multicast sessions in the current serving cell (the cell of gNB 200) (step S203).

[0133] When the conditions for cell reselection are met (step S205: Yes), in step S206, the UE 100, which is in the RRC inactive state, determines whether it can receive MCCH and / or MTCH from a neighboring cell that is a cell reselection candidate. When it cannot receive MCCH and / or MTCH from a neighboring cell (step S206: No), in step S209, the UE 100 transitions from the RRC inactive state to the RRC connected state.

[0134] When MCCH and / or MTCH can be received from a neighboring cell (step S206: Yes), in step S207, UE 100 performs QoS measurements on the candidate cell and determines whether the QoS requirements are met. For example, when UE 100 determines that the sequence number of packets in the MTCH of a neighboring cell is greater than the sequence number of packets in the MTCH of the current serving cell, and a packet loss corresponding to the gap between the sequence numbers occurs, UE 100 can determine that the QoS requirements are not met. When it is determined that the QoS requirements are not met (step S207: No), in step S209, UE 100 transitions from the RRC inactive state to the RRC connected state.

[0135] When it is determined that the QoS requirements are met (step S207: Yes), in step S208, the UE100, which is in the RRC inactive state, performs cell reselection from the current serving cell to another cell (neighboring cell).

[0136] On the other hand, when UE 100 transitions to an RRC connection state (i.e., performs RRC recovery) in step S209, a handover is performed under the control of gNB 200 in step S210. The details of this handover process are the same as and / or similar to the details of the handover process in the first embodiment. Here, in step S209, the RRC recovery request message sent from UE 100 to gNB 200 may include information elements as a recovery reason for receiving a multicast session (or for satisfying a multicast session QoS request).

[0137] Note that in Figure 12 In the process, the order of determining step S206 and step S207 can be reversed.

[0138] (3) Another embodiment

[0139] Although the above embodiments primarily describe multicast reception in the RRC inactive state, the operation according to the above embodiments can also be applied to multicast reception in the RRC idle state. For the RRC idle state, the aforementioned RRC recovery can be read as RRC establishment.

[0140] The above operational procedures can be implemented separately and independently, or they can be implemented as a combination of two or more operational procedures. For example, some steps in one operational procedure can be added to another, or some steps in one operational procedure can be replaced by some steps in another. In each procedure, not all steps are required to be executed; only some steps may be executed.

[0141] Although an example of an NR base station (gNB) has been described in the above embodiments and examples, the base station can be an LTE base station (eNB) or a 6G base station. The base station can be a relay node, such as an Integrated Access and Backhaul (IAB) node. The base station can be a DU of an IAB node. UE 100 can be a mobile terminal (MT) of an IAB node.

[0142] The term "network node" primarily refers to a base station, but can also refer to core network equipment or a portion of a base station (CU, DU, or RU). A network node can include a combination of at least a portion of core network equipment and at least a portion of a base station.

[0143] A program may be provided that enables a computer to perform each process executed by UE 100 or gNB 200. This program may be recorded on a computer-readable medium. The computer-readable medium allows the program to be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and may, for example, be a recording medium such as a CD-ROM or DVD-ROM. Circuitry for performing the processes executed by UE 100 or gNB 200 may be integrated, and at least a portion of UE 100 and gNB 200 may be implemented as a semiconductor integrated circuit (chipset, system-on-chip (SoC)).

[0144] The functions implemented by UE 100 or gNB 200 (network node) can be implemented in circuitry or processing circuitry programmed to perform the functions, including general-purpose processors, application-specific processors, integrated circuits, application-specific integrated circuits (ASICs), central processing units (CPUs), conventional circuitry, and / or combinations thereof. A processor may include transistors and other circuitry and may be considered as a circuit or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. As used herein, a circuit, unit, or device is hardware programmed to implement the functions or hardware that performs the functions. Hardware may be any hardware disclosed herein or any hardware programmed to implement the functions or any hardware known to perform the functions. When hardware is a processor considered as a type of circuit, the circuit, device, or unit is a combination of hardware and software used to configure the hardware and / or the processor.

[0145] Unless otherwise expressly stated, the phrases “based on” and “depending on / in response to” as used in this disclosure do not mean “based on only” and “depending on only / in response to only”. The phrase “based on” means “based on only” and “at least partially based on” both. The phrase “depending on” means “depending on only” and “at least partially dependent on” both. The terms “comprising,” “including,” and variations thereof do not mean “including only the said items,” but rather mean “may include only the said items” or “may include not only the said items but also other items.” The term “or” as used in this disclosure is not intended to be “exclusive or.” Any reference to elements in this disclosure using names such as “first” and “second” does not generally limit the number or order of those elements. These names may be used herein as a convenient way to distinguish two or more elements. Therefore, a reference to a first element and a second element does not imply that only the two elements may be used there or that the first element needs to precede the second element in some way. For example, when English articles such as “a,” “one,” and “the” are added in this disclosure by translation, these articles include plural unless the context clearly indicates otherwise.

[0146] The embodiments have been described in detail above with reference to the accompanying drawings, but the specific configurations are not limited to those described above, and various design changes can be made without departing from the spirit of this disclosure.

[0147] This application claims priority to U.S. Provisional Patent Application No. 63 / 443092 (filed February 3, 2023), the entire contents of which are incorporated herein by reference.

[0148] (4) Supplementary notes

[0149] Supplementary Note 1

[0150] A communication method for providing multicast / broadcast services (MBS) in a mobile communication system, the communication method comprising the following steps:

[0151] The user equipment in Radio Resource Control (RRC) connection state receives configuration information from the network node; and

[0152] Multicast sessions are received in the cell of the network node by user equipment that has transitioned from an RRC connected state to an RRC inactive state.

[0153] The configuration information includes information elements indicating whether user equipment receiving multicast sessions in an RRC inactive state is allowed to perform cell reselection to another cell.

[0154] Supplementary Note 2

[0155] The communication method described in Supplementary Note 1 also includes:

[0156] The user equipment receiving the multicast session in the RRC inactive state is converted to the RRC connected state before performing cell reselection based on the information element indicating that the user equipment is not allowed to perform cell reselection.

[0157] Supplementary Note 3

[0158] The communication method described in Supplementary Note 2 also includes:

[0159] When a user equipment that has been converted to RRC connection state receives a handover command from a network node, the user equipment accesses another cell that provides a multicast session according to the handover command.

[0160] Supplementary Note 4

[0161] A communication method for providing multicast / broadcast services (MBS) in a mobile communication system, the communication method comprising the following steps:

[0162] Multicast sessions are received from network nodes by user equipment in an RRC inactive state;

[0163] The quality of service for multicast sessions is measured by the user equipment; and

[0164] When a user equipment determines that the quality of service does not meet the predetermined quality of service, the user equipment shall switch from the RRC inactive state to the RRC connected state.

[0165] Supplementary Note 5

[0166] The communication method described in Supplementary Note 4 also includes:

[0167] The user equipment receives information from the network node specifying the pre-defined quality of service.

[0168] (5) Supplementary notes

[0169] 1. Introduction

[0170] The work project for enhanced MBS (eMBS) aims to support multicast reception by inactive UEs, as shown below.

[0171] Define support for multicast reception for UEs in RRC inactive state [RAN 2, RAN 3]; PTM configuration for UEs receiving multicast in RRC inactive state [RAN 2]; investigate the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not a necessary condition) [RAN 2, RAN 3]

[0172] RAN 2 has discussed this objective and reached a series of agreements.

[0173] Based on these protocols, this supplementary note discusses PTM configuration and mobility aspects of multicast reception in inactive states.

[0174] 2. Discussion

[0175] 2.1 PTM Configuration Transmission

[0176] Version 17 defines two transport modes: one for multicast sessions, referred to as "Transport Mode 1"; and one for broadcast sessions, referred to as "Transport Mode 2". In Transport Mode 1, reception on the MTCH is configured with RRC reconfiguration only for UEs in the connected state, while in Transport Mode 2, reception on the MTCH is configured with MCCH for all UEs in the RRC state.

[0177] RAN 2 #119e has defined these transport modes as candidates for multicast reception in inactive states, namely Option 1, Option 2, and a “mixture” of these options.

[0178] For PTM configuration transmission, RAN 2 further investigated the following solutions.

[0179] Option 1: Dedicated signaling

[0180] Option 2: SIB+MCCH based solution

[0181] A "mixture" of options is not excluded.

[0182] RAN 2 #120 has reached an agreement to advance the “hybrid approach”.

[0183] The mixing method is included and begins as follows.

[0184] 1. When the NW configures the UE to continue multicast reception in an inactive state, the NW provides the serving cell with at least the PTM configuration for activating the multicast session via RRC dedicated signaling (other cases require further study).

[0185] 2. Use MCCH when PTM configuration needs to be changed or when PTM configuration needs to be indicated during a handover outside the serving cell / gNB. State changes and other indications during this session require further investigation.

[0186] 3. Assume that the UE can receive multicast services after joining the session.

[0187] 4. Whether to initially provide MCCH configuration to user equipment via dedicated signaling requires further investigation.

[0188] According to the aforementioned protocol item #1, the network configures the PTM configuration for the active multicast session for the UE via dedicated signaling. Since the multicast session is activated, the UE in the connected state has already received the multicast session, and it is assumed that the UE can continue to receive the multicast session after transitioning to an inactive state according to this PTM configuration.

[0189] In this disclosure, the “hybrid approach” agreed upon by RAN 2 refers to the use of the MCCH for updating PTM configurations, etc., and thus closely resembles Transport Mode 2 of Version 17. In this sense, dedicated signaling only provides the content of the MCCH (such as MBS broadcast configurations), rather than the Version 17 dedicated multicast configurations (such as mrb-ToAddModList). This dedicated signaling helps prevent the UE from monitoring the MCCH in the connected state and minimizes service interruptions due to delayed MCCH acquisition after transitioning to an inactive state.

[0190] Recommendation 1: RAN 2 should agree to provide the MCCH content (i.e., MBS broadcast configuration) for multicast reception in inactive states via dedicated signaling.

[0191] On the other hand, since RAN 2 has agreed that UEs in an inactive state can start receiving multicast sessions, i.e., it has agreed to Scenario 2 with the following protocol items, it is unclear what can be configured for inactive multicast sessions.

[0192] In version 18, based on the premise that the UE already has a valid PTM configuration, multicast reception of an inactive UE supports at least the following scenarios.

[0193] -Scenario 1: The UE receives multicast in the connected state, enters the inactive state, and continues to receive multicast.

[0194] -Scenario 2: The UE joins a multicast session and is redirected to an inactive state, and the UE begins to receive multicast sessions.

[0195] State changes (e.g., state changes caused by services not being provided in an inactive state) require further investigation.

[0196] The actual PTM configuration may not be provided to inactive multicast sessions, but it can be provided when a multicast session is activated. In version 17, an inactive UE transitions to a connected state after receiving a group paging message to activate a multicast session. Therefore, some type of indication can be provided in advance via dedicated signaling to allow a UE that remains inactive to use the PTM configuration obtained from the MCCH for a multicast session. Another approach is to provide this indication via group paging, as discussed in the following sections.

[0197] Recommendation 2: RAN 2 should discuss whether some type of configuration should be provided via dedicated signaling when the UE transitions to an inactive state before activating a multicast session.

[0198] The aforementioned protocol item #2 specifies the use of the MCCH when a change to the PTM configuration is required or when indicating the PTM configuration is needed during a handover outside the serving cell / gNB. Session state changes and other indications are somewhat ambiguous. That is, it's unclear whether the MCCH is used to indicate or provide the PTM configuration. If it's only used for indication, it might mean an MCCH change notification. However, the MCCH provides the PTM configuration, for example, updating the PTM configuration of an inactive UE.

[0199] Recommendation 3: RAN 2 should specify whether the MCCH provides PTM configuration to multicast sessions of inactive UEs, for example, when the PTM configuration is updated.

[0200] RAN 2 leaves the question of whether the MCCH configuration is initially provided to the UE via dedicated signaling as an area for further investigation. The MCCH configuration refers to SIB 20. Since the dedicated signaling, as agreed by RAN 2, provides the PTM configuration for multicast reception in inactive states, the UE does not need to immediately read the MCCH and does not need to know which SIB 20 (i.e., the MCCH configuration) it is. Of course, the UE subsequently obtains SIB 20 and the MCCH to confirm whether the PTM configuration has been updated.

[0201] Recommendation 4: RAN 2 should agree that MCCH configuration (i.e., SIB 20) does not need to be provided via dedicated signaling.

[0202] 2.2. UE Mobility and Service Continuity

[0203] RAN 2 #120 has agreed to use MCCH during UE transition.

[0204] This disclosure employs a hybrid approach and begins as follows.

[0205] 1. When the NW configures the UE to continue multicast reception in an inactive state, the NW provides the serving cell with at least the PTM configuration of the active multicast session via RRC dedicated signaling (other cases require further study).

[0206] 2. Use MCCH when PTM configuration needs to be changed or when PTM configuration needs to be indicated during a handover outside the serving cell / gNB. State changes and other indications during this session require further investigation.

[0207] 3. Assume that the UE can receive multicast services after joining the session.

[0208] 4. Whether to initially provide MCCH configuration to user equipment via dedicated signaling requires further investigation.

[0209] WID points out that seamless / lossless mobility is not necessary.

[0210] Define support for multicast reception for UEs in RRC inactive state [RAN 2, RAN 3]; PTM configuration for UEs receiving multicast in RRC inactive state [RAN 2]; investigate the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not a necessary condition) [RAN 2, RAN 3]

[0211] As described in Section 2.1, the transmission method of the new PTM configuration is similar to transmission mode 2 in version 17. Therefore, it is reasonable to use the service continuity mechanism of version 17 MBS broadcast as a benchmark. In this case, during a multicast session, neighboring cell information needs to be provided from the MCCH first to confirm that the UE is allowed to preferentially select the MBS frequency during cell reselection.

[0212] How to ensure service continuity depends on the UE's implementation, as assumed in LTE SC-PTM and NR MBS broadcasting. For example, how neighbor cell information is used, whether MBS frequencies are prioritized, and how / when MCCH is obtained from neighbor cells all depend on the UE's implementation.

[0213] Recommendation 5: RAN 2 should agree that the MCCH should provide neighbor cell information for multicast sessions in the same or similar manner as MBS broadcasting.

[0214] Recommendation 6: RAN 2 should agree to allow UEs to preferentially select MBS multicast frequencies in the same and / or similar manner as MBS broadcast during cell reselection.

[0215] Some companies have suggested enhancing service continuity during UE handover by enabling PTM configurations across multiple cells. Within a gNB, matching PTM configurations for each cell is relatively straightforward (if needed), but between gNBs, matching PTM configurations is more difficult and requires negotiation of Xn-APs. This small-scale extension is considered harmless within a gNB but has limitations. Therefore, RAN 2 needs to discuss whether PTM configurations can be applied to cells within multiple gNBs.

[0216] Recommendation 7: RAN 2 should investigate whether the PTM configuration can be applied to multiple cells within a gNB. In this case, the gNB scenario is the basic assumption.

[0217] Another consideration is network QoS control. WID states that seamless / lossless mobility is not necessary, but this doesn't mean that all multicast sessions a UE can receive in an inactive state don't require seamless / lossless mobility. For example, the network might need to put a UE into an inactive state due to congestion, but the UE might need to transition after connection due to QoS requirements. For seamless / lossless mobility, version 17 MBS multicast supports handover in RRC connected state. Therefore, the network may need to choose whether to have the UE perform cell reselection or restore RRC connection (for handover in connected state) before cell reselection.

[0218] Recommendation 8: RAN 2 should discuss whether the gNB can indicate whether to allow the UE to perform inactive mode mobility before cell reselection or to restore RRC connectivity for better QoS control.

[0219] (6) Supplementary Notes

[0220] 1. Introduction

[0221] The following are the work items for enhancing MBS (eMBS).

[0222] Support for multicast reception for UEs in RRC inactive state is specified [RAN 2, RAN 3]; PTM configuration for UEs receiving multicast in RRC inactive state [RAN 2]; Investigation of the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not a necessary condition) [RAN 2, RAN 3]

[0223] Based on these protocols, this supplementary note discusses notifications for multicast reception and RRC state transitions in inactive states.

[0224] 2. Discussion

[0225] RAN 2 #119e leaves aspects related to RRC status changes as items that need to be studied.

[0226] In version 18, based on the premise that the UE already has a valid PTM configuration, multicast reception of an inactive UE supports at least the following scenarios.

[0227] - Scenario 1: The UE receives multicast in the connected state, enters the inactive state, and continues to receive multicast.

[0228] - Scenario 2: The UE joins a multicast session and is redirected to an inactive state, and the UE begins to receive multicast sessions.

[0229] State changes (e.g., changes due to services not being provided in an inactive state) require further investigation.

[0230] Several scenarios related to RRC state changes have been considered from both the network and UE perspectives. Some of these scenarios also involve notifications sent from the network to the UE. Therefore, the following scenarios are considered.

[0231] 2.1. Case 1: Deactivation / Release of Multicast Sessions

[0232] When a multicast session is deactivated, the agreed RAN 2 #119bis-e is notified to the UE, and when a multicast session is released, the version 17 mechanism applies.

[0233] When a UE is in an RRC inactive state and is configured to receive multicast sessions in an RRC inactive state, the UE will be notified when the multicast session is deactivated. Further investigation is needed regarding whether notification can be made via group paging, MCCH, or other methods.

[0234] Version 17 mechanism (NAS-based directive) applies to multicast session release. Further research is available upon request.

[0235] When an inactive UE receives MBS service, and the gNB can respond by stopping PTM / MTCH transmission, the multicast session is considered deactivated or released. In this case, it is assumed that the UE has no reason to continue monitoring the MTCH, but will monitor the MTCH as long as the PTM configuration is not removed. From the UE's power-saving perspective, it is desirable to stop monitoring the MTCH as quickly as possible.

[0236] Observation 1: Even after stopping or releasing the multicast session, the UE continues to monitor the PTM / MTCH, which is inefficient from the perspective of UE power consumption.

[0237] Therefore, the UE's behavior when a multicast session is deactivated should be clearly defined. Regardless of the notification given, the UE should be allowed to stop monitoring the MTCH upon receiving a notification to deactivate the multicast session. The UE should remain in the RRC deactivated state upon receiving such a notification.

[0238] Recommendation 1: RAN 2 should allow the UE to stop monitoring the MTCH when it receives a multicast session release notification.

[0239] When a multicast session is terminated, RAN 2 will notify the UE of the method (e.g., group paging, MCCH, or other methods) as an item to be studied later.

[0240] According to LTE SC-PTM, to notify the UE of ceasing PDCCH monitoring of the G-RNTI, an SC-PTM Stop Indication MAC CE is introduced, and this MAC CE is multiplexed onto the SC-MTCH associated with the G-RNTI. This lightweight signaling can function within the constraint of a one-to-one mapping between TMGI and G-RNTI. On the other hand, since NR MBS allows a many-to-one mapping between TMGI and G-RNTI, the MAC CE needs to indicate the deactivated TMGI. Because the MAC CE is sent along with the MTCH, the delay from receiving the last multicast data to ceasing MTCH monitoring is expected to be minimized.

[0241] Another option is to reuse group paging. Group paging is used to page multiple UEs in a group simultaneously using TMGI instead of UE-ID. Since the existing paging group list (i.e., the TMGI list) can be applied to legacy UEs, group paging requires adding a new TMGI list for deactivating notifications to avoid impacting legacy UEs. That is, a delay occurs from when the last multicast data is received until when MTCH monitoring stops based on the I-DRX cycle.

[0242] The third option is to reuse the MCCH. There are two possibilities for notifying the deactivation of a multicast session: deleting the PTM configuration of the deactivated TMGI or adding a new indication for notifying the deactivated TMGI. In either case, because the MCCH needs to be updated, an MCCH change notification needs to be sent to the UE in advance. Therefore, a longer delay is required from when the last multicast data is received until MTCH monitoring stops.

[0243] According to the RAN 2 protocol, "using MCCH when PTM configuration needs to be changed" can be interpreted as an inactive UE needing to be woken up at a timed point on the MCCH, and the deactivation of a multicast session being considered a type of "PTM configuration change." Therefore, when the corresponding PTM configuration is removed from the MCCH, the UE can be aware that the multicast session has been deactivated. However, it takes time for the UE to stop monitoring the MCCH. Therefore, notification via MAC CE is desirable.

[0244] In summary, the delay from receiving the last multicast data to ceasing MTCH monitoring can directly lead to unnecessary power consumption increases for the UE. From a UE power-saving perspective, using MAC CE is the preferred solution, as the notification needs to be sent as quickly as possible.

[0245] Recommendation 2: RAN 2 should agree that when a multicast session becomes inactive, a new MAC CE (such as an existing SC-PTM stop indication) should be notified to the inactive UE.

[0246] Regarding the release of multicast sessions, the NAS-based instruction of version 17 agreed by RAN 2 is applied, which can be "Release a network-requested multicast session or release an MBS session". This procedure assumes the UE is paged by the gNB and transitions to an RRC connected state to communicate with the AMF. During this procedure, it is assumed that existing group paging (or known dedicated paging) can be reused.

[0247] However, for optimization purposes, this procedure can be freely used when a new MAC CE is introduced, as in Recommendation 2, to notify the multicast session to deactivate. That is, the gNB sends a MAC CE to allow the UE to stop monitoring the MTCH, after which the gNB can allocate paging time to the UE, i.e., using traditional dedicated paging to avoid signaling storms caused by simultaneous transitions to RRC state.

[0248] Recommendation 3: RAN 2 needs to agree that dedicated function extensions in multicast session release are not necessary, i.e., the UE transitions to RRC connected state via existing (group) paging.

[0249] 2.2. Case 2: Selective Switching When Activating a Multicast Session

[0250] RAN 2 #119e has reached the following agreement regarding Case 2.

[0251] The gNB determines whether the UE can receive multicast sessions while inactive. What information should be provided to the gNB (related to the discussion of SA2) to make this determination requires further investigation.

[0252] The gNB is supported in sending a multicast session to both a connected UE and an inactive UE within the same cell. How the gNB can be configured to support this requires further investigation.

[0253] Assume the network can select which UE will receive in the RRC inactive state and which UE will receive in the RRC connected state, and can switch between states where the UE is receiving multicast services.

[0254] To release a UE to an inactive state, the gNB can select the UE to release based on UE capabilities, UE assistance information, and / or CN assistance information (when defined) in the same manner as the current approach (i.e., in an RRC release with a suspend configuration). Therefore, no enhancement to the selective switching of UEs is expected for RRC release messages.

[0255] Observation 2: The existing RRC release mechanism is used by the gNB to select which UE to release.

[0256] Regarding the activation of multicast sessions, RAN 2# 119bis-e has reached an agreement on the following items.

[0257] When a version 18 session is activated, it can notify UEs that are inactive (details require further investigation).

[0258] As a baseline, group paging can be used to notify the version 18 UE of session activation (e.g., further investigation is needed into the details of UE operation when the UE receives such group notification).

[0259] Consider the following solutions and further research to determine a method for determining whether a UE can receive a multicast session in an RRC inactive state when the session is active (this description may be updated as needed and multiple solutions may be required).

[0260] 1. When a multicast session is activated, the UE can receive the multicast session in the RRC inactive state if the UE can use the PTM configuration that the session uses in the RRC inactive state and the UE has joined the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH). Otherwise, the UE returns to the RRC connected state and receives the multicast session.

[0261] 2. When a multicast session is activated, whether the UE can receive the multicast session in the RRC inactive state is indicated by group paging (detailed signaling requires further study).

[0262] 3. Whether the UE can receive multicast sessions while in an RRC inactive state is configured for the UE by dedicated signaling before the UE is released. Once the multicast session is activated, the UE remains in an RRC inactive state or resumes the RRC connection in response to the activation (detailed signaling requires further investigation).

[0263] In version 17, multicast session activation is provided as a notification via group paging. Since there is no need to differentiate it from the legacy mechanism in version 18, RAN 2 needs to use group paging to confirm that the UE has been notified of multicast session activation.

[0264] Recommendation 4: RAN 2 requires confirmation group paging to be used to notify the UE of session activation for version 18.

[0265] In addition to confirmation, RAN 2 has defined three options for the UE's action when it receives a multicast activation notification, as described above.

[0266] For Option 1, a UE can receive multicast sessions even when inactive, provided a valid PTM configuration is in place. An inactive UE cannot receive multicast sessions without a PTM configuration, which can be considered the benchmark for all other UE operations. Therefore, consensus on Option 1 is needed.

[0267] Recommendation 5: According to RAN 2, when Operation Option 1 of a UE multicast session is activated, the UE can receive multicast sessions in the RRC inactive state if the UE can use the PTM configuration used by the session in the RRC inactive state and the UE has joined the session (provided to the UE via dedicated RRC signaling or MCCH).

[0268] For option 2, when the UE receives a group paging, it is indicated whether the UE needs to receive a multicast session in an inactive state.

[0269] For option 3, the RRC reconfiguration or RRC release indicates in advance whether the UE needs to receive multicast sessions in an inactive state.

[0270] The mechanisms of these two options are likely very similar, except for the message instructing the UE to do so. Therefore, these options can be analyzed from the perspective of the motivation for receiving multicast in an inactive state (i.e., network congestion and UE power saving).

[0271] Regarding network congestion, it is assumed that cell load varies over time. According to Option 2, since the notification is sent in group paging, the gNB can consider the latest load situation when determining whether a UE should remain inactive. On the other hand, according to Option 3, since the gNB needs to predict future load when providing notifications to UEs, there is a possibility that cell load may change when the gNB actually sends a group paging. Therefore, there is a risk that the number of UEs transitioning to a connected state increases when congestion worsens, or that the number of UEs remaining inactive increases even if congestion is resolved. Therefore, Option 2 is desirable for effectively controlling the RRC state of UEs.

[0272] From the perspective of UE power saving, suppose a certain "power saving preference" is introduced into the UE auxiliary information. This preference indication can only be sent from a UE in a connected state. Therefore, when the UE was previously in a connected state, the gNB can indicate to the UE whether to allow the UE to receive multicast sessions in an "inactive state". When this preference indication is not introduced, since the gNB does not know whether the UE prefers power saving, the gNB can indicate this indication to the UE at any time. That is, there is no difference between option 2 and option 3.

[0273] Based on the above analysis, Option 2 is considered more efficient and covers the scope of Option 3. Therefore, RAN 2 needs to reach a consensus on at least Option 2.

[0274] Recommendation 6: RAN 2 needs to reach an agreement on UE operation option 2, which states that "when a multicast session is activated, the UE is instructed via group paging whether it can receive the multicast session in the RRC inactive state (detailed signaling needs further study)".

[0275] Regarding group paging in Option 2, the current specification defines the UE's behavior upon receiving a group paging message. Specifically, when the paging message includes the TMGI of interest, all UEs initiate an RRC recovery procedure. Therefore, when Option 2 requires selective paging, the gNB cannot include the TMGI in the paging message. When the gNB only includes the UE-ID used for selective paging (i.e., traditional dedicated paging for paging the selected version 18 UE and not using the TMGI), version 17 UEs waiting for multicast activation in an inactive state cannot be paged. This is also inefficient in terms of signaling overhead.

[0276] Observation 3: That is, when the paging message includes the TMGI of interest, all UEs switch to RRC connected state.

[0277] Assuming the current paging group list is configured in the group paging message, and at least version 17 UEs are paged, version 18 UEs will also be paged via the TMGI of interest. Therefore, to ensure that selected UEs do not transition to an active state, it is advisable to define a "paging cancellation list" (or "inactive permission list") as a new UE-ID list, so that UEs listed in this list remain inactive to receive multicast sessions.

[0278] Therefore, RAN 2 needs to discuss a method for enhancing group paging to paging subsets of UEs.

[0279] Recommendation 7: RAN 2 needs to discuss an enhanced group paging method for paging subsets of UEs, such as using a new UE-ID list to keep UEs inactive to receive multicast sessions.

[0280] 2.3. Case 3: QoS Implementation

[0281] RAN 2 #119e has reached the following agreement regarding Case 3.

[0282] Multicast reception in RRC inactive state does not support HARQ feedback and PTP.

[0283] According to the protocol, multicast reception in the inactive state is the same as and / or similar to MBS broadcast reception (so-called transmission mode 2) as defined in version 17. MBS broadcast is of the best-effort type.

[0284] On the other hand, ensuring QoS / reliability is a critical task for multicast sessions. SA2 also questioned whether there are differences in the quality / reliability of multicast reception in connected and inactive states, and RAN 2#119bis-e has reached an agreement on the following response.

[0285] RAN 2 Q1-a When there is a significant difference in the quality and reliability of MBS data reception between a UE in RRC connected state and a UE in RRC inactive state:

[0286] Because HARQ feedback and PTP transmission are not supported and multicast reception in RRC inactive state does not require seamless / lossless mobility, there may be differences in the quality and reliability of MBS data reception between UEs in RRC connected state and UEs in RRC inactive state.

[0287] RAN 2 #119e has introduced thresholds for reception quality (such as RSRP and BLER), which are intended to ensure a certain level of QoS requirements for multicast reception. These thresholds are also useful for network management of QoS requirements. When multicast reception in an inactive state does not meet the corresponding QoS requirements, the UE needs to transition to a connected state and ensure reception quality by using HARQ feedback / retransmission and / or PTP (or MRB segmentation).

[0288] Observation 4: Even when the UE is inactive, multicast sessions still need to ensure certain QoS requirements.

[0289] Regarding the RSRP threshold, since NR MBS assumes the use of a single-cell transmission method, it can be assumed that the UE needs to always transition to a connected state whenever it moves to the cell edge or performs cell reselection. From the perspective of network congestion and UE power saving, this operation may not be optimal, depending on the deployment.

[0290] BLER thresholds are considered to more easily ensure QoS requirements. Therefore, these options need to be discussed to introduce RRC state transitions based on receive quality.

[0291] Recommendation 8: RAN 2 needs to agree that when the reception quality is below a threshold (e.g., RSRP or BLER), an inactive UE should be switched to a connected state.

[0292] 2.4. Case 4: PTM Configuration Update

[0293] RAN 2 agrees to the following as a prerequisite for working.

[0294] This disclosure employs a hybrid approach and begins as follows.

[0295] 1. When the NW configures the UE to continue multicast reception in an inactive state, the NW provides the serving cell with at least the PTM configuration of the active multicast session via RRC dedicated signaling (other cases require further study).

[0296] 2. Use MCCH when PTM configuration needs to be changed or when PTM configuration needs to be indicated during handover outside the serving cell / gNB. Changes in session state and other indications require further investigation.

[0297] 3. Assume that the UE can receive multicast services after joining the session.

[0298] 4. Whether to initially provide MCCH configuration to the UE via dedicated signaling requires further investigation.

[0299] That is, the UE can remain inactive to receive the updated PTM configuration. Therefore, from the perspective of an inactive UE, the transmission of the new PTM configuration is similar to transmission mode 2 in version 17. In this case, existing MCCH change notifications can be easily reused to provide notification of PTM configuration updates. Therefore, no additional notification is required for inactive UEs to update the PTM configuration.

[0300] Recommendation 9: RAN 2 should agree to use the existing MCCH change notification to update the PTM configuration.

[0301] 2.5. Case 5: Service Continuity During RRC Recovery

[0302] It can also be envisioned that a UE that has already received a multicast session (e.g., via a broadcast MRB) in an inactive state is paged and initiates an RRC recovery procedure. After transitioning to an connected state, the UE naturally wants to continue receiving multicast sessions. However, in this case, the UE has both a recovery multicast MRB and a broadcast MRB for the same multicast session. In Release 17, it is allowed to receive multicast sessions only via a multicast MRB configured through RRC reconfiguration. On the other hand, in Release 18, it is allowed to receive multicast sessions via a broadcast MRB configured through the MCCH. After the UE transitions to a connected state, the UE should use the multicast MRB for reception. However, it is unclear how the UE switches these MRBs, when the UE discards the broadcast MRB, and what the UE should do when the multicast MRB is an AM MRB (i.e., lossless principle). Therefore, RAN 2 needs to discuss the UE's operation during RRC recovery, including MRB handling and service continuity of multicast sessions.

[0303] Recommendation 10: RAN 2 should discuss the operation of UEs that continue to receive multicast sessions when RRC is restored (such as the handling of broadcast MRBs and multicast MRBs).

[0304] Figure Labels

[0305] 1: Mobile communication system

[0306] 5: Network

[0307] 10: RAN

[0308] 20:CN

[0309] 100: User Equipment (UE)

[0310] 110: Receiver

[0311] 120: Transmitter

[0312] 130: Controller

[0313] 200: gNB (base station)

[0314] 210: Transmitter

[0315] 220: Receiver

[0316] 230: Controller

[0317] 240: Backhaul communicator.

Claims

1. A communication method for providing multicast / broadcast service (MBS) in a mobile communication system, the communication method comprising the following steps: The user equipment in the Radio Resource Control (RRC) connection state receives configuration information from the network node; as well as Multicast sessions are received in the cell of the network node by user equipment that has transitioned from the RRC connected state to the RRC inactive state. The configuration information includes the following information element: the information element indicates whether a user equipment receiving the multicast session in the RRC inactive state is allowed to perform cell reselection to another cell.

2. The communication method according to claim 1 further includes: The user equipment receiving the multicast session in the RRC inactive state switches to the RRC connected state before performing the cell reselection, based on an information element indicating that the user equipment is not allowed to perform the cell reselection.

3. The communication method according to claim 2 further includes: When a user equipment that has switched to the RRC connection state receives a handover command from the network node, the user equipment accesses another cell providing the multicast session according to the handover command.

4. A communication method for providing multicast / broadcast service (MBS) in a mobile communication system, the communication method comprising the following steps: Multicast sessions are received from network nodes by user equipment in an RRC inactive state; The quality of service of the multicast session is measured by the user equipment. as well as When the user equipment determines that the quality of service does not meet the predetermined quality of service, the user equipment shall switch from the RRC inactive state to the RRC connected state.

5. The communication method according to claim 4, further comprising: The user equipment receives information specifying the predetermined quality of service from the network node.

Images