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

Abstract

A communication method used in a mobile communication system for providing a multicast broadcast service (MBS) comprises: a user equipment in an RRC inactive state starting an RRC connection resume procedure for a network node on the basis of the fact that the reception quality of the user equipment at the time of multicast reception has deteriorated and / or the fact that the need for the user equipment to acquire a multicast reception setting from the network node; and the user equipment transmitting, to the network node, an RRC resume request message that includes an information element pertaining to the cause of RRC resume. The information element is first information which indicates RRC resume that is related to multicast reception, second information which indicates mobile terminated (MT) access, or third information which indicates multimedia priority access (MPS) priority access.

Description

Technical Field

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

Background Art

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

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

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] The first aspect of the communication method is a communication method used in a mobile communication system that provides a multicast broadcast service (MBS), comprising: a user device in an RRC inactive state participating in a multicast session initiating an RRC connection resume procedure to a network node based on the reception quality falling below a threshold; and the user device sending an RRC resume request message to the network node that includes an information element regarding the cause of the RRC resume. The information element may be information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) access. Service This is information indicating priority access.

[0006] The second aspect of the communication method is a communication method used in a mobile communication system that provides a multicast broadcast service (MBS), comprising: a user device in an RRC inactive state initiating an RRC connection resume procedure to a network node based on the deterioration of the reception quality when multicast is received by the user device and / or the need for the user device to obtain multicast reception settings from the network node; and the user device sending an RRC resume request message to the network node that includes information elements regarding the cause of the RRC resume. The information elements include first information indicating that the RRC resume is related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) Service This is the third piece of information indicating priority access.

[0007] The user device according to the third embodiment is a user device used in a mobile communication system that provides a multicast broadcast service (MBS), and comprises: a control unit that, in an RRC inactive state, initiates an RRC connection resume procedure to the network node based on the deterioration of the reception quality when multicast is received by the user device and / or the need for the user device to obtain multicast reception settings from the network node; and a transmission unit that transmits an RRC resume request message to the network node that includes information elements related to the cause of the RRC resume. The information elements include first information indicating that the RRC resume is related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) Service This is the third piece of information indicating priority access.

[0008] The network node according to the fourth embodiment is a network node used in a mobile communication system that provides a multicast broadcast service (MBS), and includes a receiving unit that receives an RRC resume request message from a user device in an RRC inactive state, based on the deterioration of the reception quality when multicast is received by the user device, and / or the need for the user device to obtain multicast reception settings from the network node, the message includes information elements related to the cause of the RRC resume. The information elements include first information indicating that the RRC resume is related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) Service This is the third piece of information indicating priority access. [Brief explanation of the drawing]

[0009] [Figure 1] This is a diagram showing an example configuration of a mobile communication system according to the embodiment. [Figure 2] This figure shows an example configuration of a UE (User Equipment) according to the embodiment. [Figure 3] This figure shows an example configuration of a gNB (Network Node) according to the embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This diagram shows an overview of the operation of the UE according to the embodiment. [Figure 7] This figure shows an example of a first operation pattern of the mobile communication system according to the embodiment. [Figure 8] This figure shows another example of the first operating pattern of the mobile communication system according to the embodiment. [Figure 9] This figure shows an example of a second operation pattern of the mobile communication system according to the embodiment. [Figure 10] This figure shows another example of the second operating pattern of the mobile communication system according to the embodiment. [Modes for carrying out the invention]

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

[0011] (1) Example of system configuration Figure 1 shows an example configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 5th Generation System (5GS) of the 3GPP standard. In the following explanation, 5GS will be used as an example, but the mobile communication system may also incorporate an LTE (Long Term Evolution) system at least partially. The mobile communication system may also incorporate a 6th Generation (6G) system at least partially.

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

[0013] 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 a smartphone) or 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).

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

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

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

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

[0018] 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 wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0019] 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 (transmitted signal) output by the control unit 130 into a wireless signal and transmits it from the antenna.

[0020] The control unit 130 performs various control and processing operations on the UE 100. Such processing includes processing of each layer described later. The operation of the UE 100 described above and later may also be controlled by the control unit 230. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

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

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

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

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

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

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

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

[0028] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel. The UE100's PHY layer receives downlink control information (DCI) transmitted from the gNB200 over the physical downlink control channel (PDCCH). Specifically, the UE100 performs blind decoding of the PDCCH using a Radio Network Temporary Identifier (RNTI) and acquires the successfully decoded DCI as the DCI addressed to its own UE. The DCI transmitted from the gNB200 has a CRC parity bit added, which is scrambled by the RNTI.

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

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

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

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

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

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

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

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

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

[0038] (2.1) MBS Broadcast In the case of broadcast communication services (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. Broadcast communication services are delivered to the UE100s using broadcast sessions, which are a type of MBS session. UE100s can receive broadcast sessions regardless of whether they are in the RRC idle, RRC inactive, or RRC connected state.

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

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

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

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

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

[0044] For multicast communication services, 3GPP Release 17 allows only UE100s in the RRC Connected state to receive multicast sessions. However, 3GPP Release 18 extends this to allow UE100s in the RRC Inactive state to also receive multicast sessions.

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

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

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

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

[0049] When gNB200 configures UE100 to receive multicast sessions in an RRC inactive state, it can send a PTM setting (multicast inactive MRB setting) to UE100 using an RRC Release message that includes a suspend setting. In this case, when UE100 receives the RRC Release message containing the PTM setting from gNB200, it transitions to the RRC inactive state and receives multicast sessions (multicast reception) in the RRC inactive state.

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

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

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

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

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

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

[0056] (3) Operation of the mobile communication system The operation of the mobile communication system 1 according to this embodiment will be described.

[0057] (3.1) Operation overview In this embodiment, we assume a scenario in which UE100 in an RRC inactive state initiates an RRC connection resume (also referred to as "RRC resume") in connection with a multicast session (multicast reception).

[0058] In the RRC connection resume procedure, UE100 sends an RRC resume request message to gNB200. The RRC resume request message includes a Resume Cause, which is an information element that indicates the cause of the RRC resume. Upon receiving the RRC resume request message, gNB200 can identify the cause of UE100's RRC resume based on the Resume Cause. This allows gNB200 to decide, for example, whether to accept the RRC resume request during network congestion based on the Resume Cause.

[0059] However, when a UE100 in an RRC inactive state initiates an RRC connection resume in relation to a multicast session (multicast reception), there is a problem in that it is not clear what information the UE100 should set in Resume Cause. The following embodiment describes the operation that enables the UE100 to set appropriate information in Resume Cause in such a case.

[0060] Here, the case in which UE100 in an RRC inactive state initiates RRC connection resume in relation to a multicast session (multicast reception) is when the reception quality of multicast reception on UE100 deteriorates, and / or when UE100 needs to obtain multicast reception settings (PTM settings) from gNB200.

[0061] In this embodiment, a deterioration in reception quality during multicast reception at UE100 occurs when the reference signal received power (RSRP) measured by UE100 for a serving cell falls below the RSRP threshold set by network 5 to UE100, and / or the reference signal received quality (RSRQ) measured by UE100 for a serving cell falls below the RSRQ threshold set by network 5 to UE100. However, a deterioration in reception quality during multicast reception at UE100 may also occur when the bit error rate (BER) measured by UE100 for a multicast session exceeds the BER threshold set by network 5 to UE100, and / or the block error rate (BLER) measured by UE100 for a multicast session exceeds the BLER threshold set by network 5 to UE100.

[0062] UE100 may need to obtain multicast reception settings from gNB200 if UE100 has not received multicast reception settings for a multicast session it has joined in an RRC release message, and the serving cell has not provided those multicast reception settings via the multicast MCCH, and UE100 may also need to receive a paging message (group notification) from the serving cell indicating the activation of that multicast session. UE100 may also need to obtain multicast reception settings from gNB200 if UE100 has re-selected a cell from the first cell to the second cell, and the second cell (the re-selected cell) has not provided multicast reception settings for a multicast session it has joined in a multicast session via the multicast MCCH.

[0063] Figure 6 is a diagram illustrating the overview of the operation of UE100 according to this embodiment.

[0064] In step S1, the RRC-inactive UE100 initiates an RRC connection resume procedure to gNB200 based on the fact that the reception quality of multicast reception on UE100 has deteriorated and / or that UE100 needs to obtain multicast reception settings from gNB200.

[0065] In step S2, UE100 sends a Resume Request message to gNB200 that includes Resume Cause, which is an information element related to the cause of the RRC resume. This information element (Resume Cause) includes first information indicating that the RRC resume is related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) Service This is the third piece of information indicating priority access. MT access may be access based on incoming traffic (i.e., paging). MPS may be a service that allows communication even during network congestion. MPS priority access may be priority access via MPS.

[0066] Thus, when a UE100 in an RRC inactive state initiates an RRC connection resume in relation to a multicast session (multicast reception), it sends an RRC Resume Request message to the gNB200 that includes, as a Resume Cause, first information indicating that the RRC resume is related to multicast reception, second information indicating MT access, or third information indicating MPS.

[0067] The first piece of information is a new Resume Cause not defined in the technical specifications up to Release 17 of the 3GPP standard. By introducing such a new Resume Cause, the gNB200 can recognize that the RRC resume is related to multicast reception. For example, upon receiving an RRC Resume Request message containing the first piece of information as the Resume Cause, the gNB200 may make an acceptance decision to prioritize accepting the RRC resume request. Upon receiving an RRC Resume Request message containing the first piece of information as the Resume Cause, the gNB200 may, in response to receiving the RRC Resume Request message, send an RRC Release message to the UE100 containing the multicast reception settings for the multicast session in which the UE100 has joined, and keep the UE100 in an RRC inactive state.

[0068] The first information may differ depending on whether the reception quality of multicast reception in UE100 deteriorates or whether UE100 needs to obtain multicast reception settings from gNB200. For example, the new Resume Cause when the reception quality of multicast reception in UE100 deteriorates may be "Multicast Quality," while the new Resume Cause when UE100 needs to obtain multicast reception settings from gNB200 may be "Multicast Configuration."

[0069] On the other hand, the second and third pieces of information are existing Resume Causes already defined in the technical specifications of the 3GPP standard up to Release 17. By reusing such existing Resume Causes, it becomes easier to minimize specification changes. The second and third pieces of information may also be existing Resume Causes with higher priority than other existing Resume Causes. The second and third pieces of information may also be existing Resume Causes that the gNB200 prioritizes accepting RRC resume requests for. This can prevent the gNB200 from rejecting RRC connection resumes related to multicast sessions (multicast reception). The third piece of information may also be an existing Resume Cause with higher priority than the second piece of information.

[0070] The UE100, which operates as shown in Figure 6, has a control unit 130 that initiates an RRC connection resume procedure to the gNB200 based on the deterioration of the reception quality when receiving multicast in the UE100 and / or the need for the UE100 to obtain multicast reception settings from the gNB200, while in an RRC inactive state, and a transmission unit 120 that sends an RRC Resume Request message to the gNB200 containing information elements related to the cause of the RRC resume. These information elements are first information indicating that the RRC resume is related to multicast reception, second information indicating MT access, or third information indicating MPS. On the other hand, the gNB200 has a receiving unit 220 that receives the RRC Resume Request message containing these information elements from the UE100 in an RRC inactive state based on the deterioration of the reception quality when receiving multicast in the UE100 and / or the need for the UE100 to obtain multicast reception settings from the gNB200.

[0071] UE100 may initiate the RRC connection resume procedure and send an RRC Resume Request message to gNB200 containing any of the first to third pieces of information as an information element, based on the fact that multicast reception in an RRC inactive state is permitted by gNB200. Permission for multicast reception in an RRC inactive state by gNB200 may also mean that the RRC Release message (suspend setting) indicates that multicast reception in an RRC inactive state is permitted for multicast sessions that UE100 has joined. This makes it easier to differentiate UE100's behavior regarding Resume Cause when multicast reception in an RRC inactive state is permitted by gNB200 from its conventional behavior.

[0072] In the first operational pattern of the embodiment, a UE100 in an RRC inactive state may receive a paging message (group notification) from gNB200 indicating the activation of a multicast session in which UE100 has joined. In step S1, if UE100 does not have multicast reception settings corresponding to the multicast session in which UE100 has joined when it receives the paging message, it may start the RRC connection resume procedure. In step S2, UE100 may send an RRC Resume Request message to gNB200 that includes first information (new Resume Cause) as an information element.

[0073] In the second operation pattern of the embodiment, in step S2, UE100 sends an RRC Resume Request message to gNB200 that includes the second information or the third information (existing Resume Cause) as an information element.

[0074] In the second operating pattern of the embodiment, if UE100 has not received a paging message indicating the activation of a multicast session in which UE100 has joined, UE100 may initiate an RRC connection resume procedure and send an RRC Resume Request message to gNB200 that includes the second or third information as an information element.

[0075] In the second operation pattern of the embodiment, UE100 may initiate an RRC connection resume procedure and send an RRC Resume Request message to gNB200 containing the second or third information as an information element, based on the fact that UE100 is performing multicast reception in an RRC inactive state. UE100 may also initiate an RRC connection resume procedure and send an RRC Resume Request message to gNB200 containing the second or third information as an information element, based on the fact that UE100 is performing multicast reception in an RRC inactive state and the reception quality during multicast reception has deteriorated.

[0076] In the second operation pattern of the embodiment, UE100 may initiate an RRC connection resume procedure and send an RRC Resume Request message to gNB200 containing the second or third information as an information element, based on the fact that UE100 cannot obtain multicast reception settings from the cell re-selected by cell re-selection.

[0077] (3.2) Examples of operation As specific examples of the operation of the mobile communication system 1, the first operation pattern and the second operation pattern will be described. The first operation pattern and the second operation pattern may be implemented independently, or the two operation patterns may be implemented in combination.

[0078] (3.2.1) First Operation Pattern In the first operating pattern, if UE100 receives a group notification (paging message) and must transition to the RRC Connected state to receive multicast reception settings (PTM settings), it sets the first information (new Resume Cause) in the RRC Resume Request message. This operation may only be applicable if the gNB200 permits multicast session reception in the RRC Inactive state.

[0079] Figure 7 shows an example of the first operation pattern of the mobile communication system 1 according to the embodiment.

[0080] In step S101, UE100 is in the RRC connected state in the gNB200 cell. UE100 is assumed to have joined a multicast session, which is also referred to as the joined multicast session. Joining a multicast session may mean that UE100 is registered with network 5 (CN20) as a receiver of that multicast session. In the first operation pattern, the joined multicast session of UE100 is activated after UE100 transitions to the RRC inactive state.

[0081] In step S102, gNB200 sends an RRC Release message to UE100 that includes a suspend setting, i.e., an RRC Release message that transitions UE100 to the RRC inactive state. UE100 receives the RRC Release message.

[0082] The RRC Release message in step S102 includes at least one of the following pieces of information: 1) through 3).

[0083] 1) Information that permits (or instructs) multicast reception in an RRC inactive state. This information may be provided for each multicast session. This information may also indicate a joined multicast session in which multicast reception in an RRC inactive state is permitted (or instructed).

[0084] 2) Information that instructs the system to use a new Resume Cause (first piece of information).

[0085] 3) Information indicating that a joined multicast session is not active (i.e., inactive). This information may indicate whether each joined multicast session is active or not. Whether a multicast session is active or not may be synonymous with whether or not to immediately begin receiving MBS data (MTCH) corresponding to that multicast session.

[0086] However, the RRC Release message in step S102 does not include multicast receive settings (PTM settings) for multicast reception in an RRC inactive state.

[0087] In step S103, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S102.

[0088] In step S104, the gNB200 sends a paging message (group notification) containing the session identifier (MBS session ID) of the joined multicast session in the UE100, in response to the activation of the joined multicast session. The UE100 receives the paging message (group notification).

[0089] In step S105, UE100 initiates the RRC connection resume procedure in response to receiving the paging message in step S104. Specifically, UE100 initiates the RRC connection resume procedure in response to the paging message containing the session identifier of a multicast session joined by UE100, and because UE100 does not have multicast receive settings for that multicast session. Not having multicast receive settings may mean that the multicast receive settings were not received in the RRC Release message in step S132, and that the serving cell has not broadcast the multicast receive settings over the multicast MCCH.

[0090] In step S106, UE100 sets the first information (new Resume Cause) in the RRC Resume Request message and sends the RRC Resume Request message to gNB200. gNB200 receives the RRC Resume Request message. UE100 may set the first information (new Resume Cause) in the RRC Resume Request message depending on whether multicast reception in the RRC inactive state is permitted (or instructed) in the RRC Release message in step S102, or whether it is instructed to use a new Resume Cause (first information). This first information may, for example, be "multicast settings for RRC inactive". This first information may be a Cause indicating that it is not related to unicast communication, or a Cause indicating that it is related only to multicast communication.

[0091] In step S107, upon receiving an RRC Resume Request message containing the first information (new Resume Cause) from step S106, gNB200 sends an RRC Release message to UE100 containing the multicast receive settings and suspend settings for the multicast session joined by UE100. In other words, gNB200 provides the multicast receive settings to UE100 in the RRC Release message without transitioning UE100 to the RRC Connected state. UE100 receives the RRC Release message.

[0092] In step S108, the gNB200 transmits the MBS data (multicast data) of the UE100's joined multicast session over the MTCH.

[0093] In step S109, UE100 applies the multicast reception settings from step S107 and performs multicast reception in the RRC inactive state. Specifically, UE100 receives MBS data (multicast data) of multicast sessions that UE100 has joined from gNB200 on the MTCH.

[0094] Figure 8 shows another example of the first operation pattern of the mobile communication system 1 according to this embodiment. Here, we will explain the differences from the operation example in Figure 7.

[0095] The operations in steps S131 to S136 are the same as the operation example in Figure 7. However, the operation in step S134 is optional. For example, UE100 may start the RRC connection resume procedure in response to a deterioration in the reception quality when multicast is received at UE100 (step S135). The first information (new Resume Cause) included in the RRC Resume Request message in step S136 may be information indicating a deterioration in multicast reception quality.

[0096] In step S137, gNB200, upon receiving an RRC Resume Request message containing the first information (new Resume Cause) from step S136, decides to transition UE100 to the RRC Connected state and sends an RRC Resume message to UE100. UE100 receives the RRC Resume message. gNB200 may decide to transition UE100 to the RRC Connected state depending on whether network congestion has eased.

[0097] In step S138, UE100 sends an RRC Resume Complete message to gNB200 in response to receiving the RRC Resume message in step S137. gNB200 receives the RRC Resume Complete message.

[0098] In step S139, UE100 transitions from the RRC inactive state to the RRC connected state.

[0099] In step S140, gNB200 sends an RRC Reconfiguration message to UE100 containing the multicast receive settings for the multicast sessions UE100 has joined. UE100 receives the RRC Reconfiguration message.

[0100] In step S141, gNB200 transmits the MBS data (multicast data) of the UE100's joined multicast session over the MTCH.

[0101] In step S142, UE100 applies the multicast reception settings from step S140 and performs multicast reception in the RRC connected state. Specifically, UE100 receives MBS data (multicast data) of multicast sessions that UE100 has joined from gNB200 on the MTCH.

[0102] (3.2.2) Second Operation Pattern In the second operating pattern, UE100 sets the Resume Cause to "MT Access" or "MPS Priority Access" in RRC resumes related to multicast sessions (multicast reception). This operation may be applied if UE100 has not received a group notification (paging message). This operation may be applied if UE100 is receiving a multicast session in an RRC inactive state, especially if the reception quality of the multicast session deteriorates in an RRC inactive state. This operation may be applied if UE100 performs cell reselection and is unable to obtain PTM settings from the reselected cell. This operation may be applied if UE100 has received permission (instruction) from gNB200 to receive multicast in an RRC inactive state.

[0103] Figure 9 shows an example of a second operation pattern of the mobile communication system 1 according to this embodiment. Here, we will mainly explain the differences from the first operation pattern described above.

[0104] In step S201, UE100 is in the RRC connected state in the gNB200 cell. Assume that UE100 has already joined a multicast session.

[0105] In step S202, gNB200 sends an RRC Release message to UE100 that includes a suspend setting, i.e., an RRC Release message to transition UE100 to the RRC inactive state. UE100 receives the RRC Release message. The RRC Release message in step S202 may contain information similar to that in the first operation pattern.

[0106] In step S203, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S202. UE100 in the RRC inactive state may perform multicast reception.

[0107] In step S204, UE100 starts the RRC connection resume procedure. In the second operation pattern, UE100 may start the RRC connection resume procedure if at least one of the following conditions 1) to 3) is met.

[0108] 1) The reception quality of multicast signals on the UE100 deteriorated.

[0109] 2) UE100 performs cell reselection, and the reselected cell (the cell newly camped by UE100) does not provide a multicast MCCH containing the multicast receive settings for the multicast sessions that UE100 has joined.

[0110] 3) Similar to the first operating pattern, UE100 receives a group notification (paging message), and UE100 does not have a valid PTM setting. In addition, multicast reception in an RRC inactive state may be permitted (instructed).

[0111] In step S205, UE100 sets the second piece of information (MT Access) as the Resume Cause in the RRC Resume Request message and sends the RRC Resume Request message to gNB200. gNB200 receives the RRC Resume Request message.

[0112] In step S206, gNB200, upon receiving an RRC Resume Request message containing the second information from step S205 as the Resume Cause, preferentially accepts the RRC resume from UE100 and sends an RRC Resume message to UE100. UE100 receives the RRC Resume message.

[0113] In step S207, UE100 sends an RRC Resume Complete message to gNB200 in response to receiving the RRC Resume message in step S206. gNB200 receives the RRC Resume Complete message.

[0114] In step S208, UE100 transitions from the RRC inactive state to the RRC connected state.

[0115] In step S209, gNB200 sends an RRC Reconfiguration message to UE100 containing the multicast receive settings for the multicast sessions UE100 has joined. UE100 receives the RRC Reconfiguration message.

[0116] In step S210, gNB200 transmits the MBS data (multicast data) of the UE100's joined multicast session over the MTCH.

[0117] In step S211, UE100 applies the multicast reception settings from step S140 and performs multicast reception in the RRC connected state. Specifically, UE100 receives MBS data (multicast data) of multicast sessions that UE100 has joined from gNB200 on the MTCH.

[0118] Figure 10 shows another example of the second operation pattern of the mobile communication system 1 according to the embodiment.

[0119] The operations in steps S231 to S241 are basically the same as the specific example of the operation in Figure 9. However, in step S235, UE100 sets the third piece of information (MPS Priority Access) as the Resume Cause in the RRC Resume Request message and sends the RRC Resume Request message to gNB200. gNB200 receives the RRC Resume Request message. In step S236, in response to receiving the RRC Resume Request message containing the third piece of information from step S235 as the Resume Cause, gNB200 preferentially accepts UE100's RRC resume and sends an RRC Resume message to UE100. UE100 receives the RRC Resume message.

[0120] (4) 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, and the above-described Resume Cause is read as Establishment Cause.

[0121] 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. Furthermore, the order of steps in each flow may be changed as appropriate.

[0122] In the embodiments and examples described above, an example was given where the base station is an NR base station (gNB), 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. That is, UE100 may be a terminal function unit (a type of communication module) for the base station to control a repeater that performs signal relay. Such a terminal function unit is called an MT. Examples of MTs other than IAB-MT include, for example, NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.

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

[0124] A program is provided that causes a computer to execute each of the processes according to the above embodiment. 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. Furthermore, the circuits that execute each of the processes according to the above embodiment 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).

[0125] The functions realized by the apparatus according to the embodiments described above may be implemented in a circuit or processing circuitry, including a general-purpose processor, an application-specific processor, an integrated circuit, an ASIC (Application Specific Integrated Circuit), a CPU (a Central Processing Unit), conventional circuits, and / or a combination thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered a circuit or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this disclosure, a circuit, unit, or means is hardware programmed to realize or execute the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or execute the described functions. If such hardware is a processor that is considered a type of circuit, then the circuit, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0126] The terms "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 their variations do not mean to include only the listed items, but may include only the listed items or may include additional items 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.

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

[0128] This application claims priority to U.S. Provisional Application No. 63 / 540261 (filed September 25, 2023), the entirety of which is incorporated into the specification of this application.

[0129] (5) 1st Appendix The features of the above-described embodiment are noted below.

[0130] (Note 1) A communication method used in a mobile communication system that provides multicast broadcast services (MBS), A user device in an RRC inactive state initiates an RRC connection resume procedure to the network node based on the deterioration of the reception quality during multicast reception on the user device, and / or the need for the user device to obtain multicast reception settings from the network node. The user device transmits an RRC resume request message to the network node, which includes an informational element regarding the cause of the RRC resume. The aforementioned information elements include first information indicating that it is an RRC resume related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) access. Service ) This is the third piece of information indicating priority access. Communication method.

[0131] (Note 2) The user device, based on the fact that multicast reception in an RRC inactive state is permitted by the network node, initiates the RRC connection resume procedure and sends the RRC resume request message to the network node, which includes any of the first to third pieces of information as an information element. The communication method described in Appendix 1.

[0132] (Note 3) The user device further includes receiving a paging message from the network node indicating the activation of a multicast session in which the user device has joined. The commencement described above includes, if the user device does not have the multicast receive settings corresponding to the multicast session when the paging message is received, initiating the RRC connection resume procedure. The aforementioned transmission includes transmitting the RRC resume request message, which includes the first information as an information element, to the network node. The communication method described in Appendix 1 or 2.

[0133] (Note 4) The aforementioned transmission includes transmitting the RRC resume request message, which includes the second information or the third information as the information element, to the network node. The communication method described in Appendix 1 or 2.

[0134] (Note 5) If the user device has not received a paging message indicating the activation of a multicast session in which the user device has joined, the user device initiates the RRC connection resume procedure and sends the RRC resume request message, which includes the second or third information as an information element, to the network node. The communication method described in Appendix 4.

[0135] (Note 6) Based on the fact that the user device is performing multicast reception in an RRC inactive state, the user device initiates the RRC connection resume procedure and sends the RRC resume request message, which includes the second information or the third information as an information element, to the network node. The communication method described in Appendix 4 or 5.

[0136] (Note 7) The user device, based on the fact that it is performing multicast reception in an RRC inactive state and that the reception quality during multicast reception has deteriorated, initiates the RRC connection resume procedure and sends the RRC resume request message, which includes the second information or the third information as information elements, to the network node. The communication method described in Appendix 6.

[0137] (Note 8) The user device, based on the fact that it cannot obtain multicast reception settings from the cell re-selected by cell re-selection, initiates the RRC connection resume procedure and sends the RRC resume request message, which includes the second information or the third information as information elements, to the network node. The communication method described in any of the appendices 4 through 7.

[0138] (Note 9) A user device used in a mobile communication system that provides multicast broadcast services (MBS), A control unit that, in the RRC inactive state, initiates an RRC connection resume procedure to the network node based on the deterioration of the reception quality during multicast reception on the user device and / or the need for the user device to obtain multicast reception settings from the network node, The system includes a transmission unit that transmits an RRC resume request message containing informational elements regarding the cause of the RRC resume to the network node, The aforementioned information elements include first information indicating that it is an RRC resume related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) access. Service ) This is the third piece of information indicating priority access. User device.

[0139] (Note 10) A network node used in a mobile communication system that provides multicast broadcast services (MBS), The system includes a receiving unit that receives an RRC resume request message from a user device in an RRC inactive state, based on the deterioration of the reception quality during multicast reception on the user device and / or the need for the user device to obtain multicast reception settings from the network node, the receiving unit receiving the RRC resume request message containing informational elements regarding the cause of the RRC resume. The aforementioned information elements include first information indicating that it is an RRC resume related to multicast reception, second information indicating MT (Mobile Terminated) access, or MPS (Multimedia Priority) access. Service ) This is the third piece of information indicating priority access. Network node.

[0140] (6) Second Appendix 1. Introduction The work items related to enhanced MBS (eMBS) aim to support multicast reception by inactive UEs, as follows: — Specifies support for multicast reception by UEs in RRC inactive state [RAN2, RAN3]. • PTM configuration for UE receiving multicast in RRC inactive state [RAN2]. Investigate the impact of mobility and state transitions on UEs receiving multicast in the RRC inactive state. (Seamless / lossless mobility is not required.) [RAN2, RAN3]

[0141] This addendum discusses the details of RRC resumption due to poor quality and the causes of such resumption.

[0142] 2. Discussion 2.1. RRC resume due to poor reception quality RAN2#123 agreed to introduce an RSRP / RSRQ-based RRC resume as follows:

[0143] For UEs receiving multicast while RRC is inactive, the UE will reactivate RRC connectivity when the RSRP or RSRQ, measured based on the serving cell's existing measurement requirements (the one set by the network), falls below the threshold set by the network. Further consideration is needed regarding whether or not the ping-pong issue needs to be addressed.

[0144] The threshold can be set per MBS session via RRC Release or multicast MCCH message using PTM.

[0145] Based on the agreement, the remaining issues will be discussed in the following sections.

[0146] 2.1.1. The Ping-pong Issue The agreement captures the points to consider regarding whether or not the ping-pong issue needs to be addressed and how it should be addressed. Possible scenarios for resuming ping-pong include the following:

[0147] 1. If an inactive UE with degraded wireless quality experiences an RSRP / RSRQ reading below a threshold, it will initiate RRC resume. 2. In response to an RRC resume request, a gNB under network congestion sends an RRC release with a suspend config that includes the RSRP / RSRQ threshold. 3. If the wireless quality remains poor, the UE will revert to an inactive state, and the RSRP / RSRQ will immediately fall below the threshold, causing the RRC resume to start again.

[0148] To avoid the ping-pong issue in the above scenario, the gNB could either keep the UE connected or set appropriate RSRP / RSRQ thresholds for the UE.

[0149] To support such decisions, gNB may need to know the radio conditions and / or the reason for the RRC resume (in this case, due to poor radio quality) as soon as the UE requests an RRC resume.

[0150] Finding 1: The gNB may need to know the UE's radio state and the reason for the RRC resume when the UE requests one, in order to ensure QoS requirements.

[0151] According to the RAN2 discussion in the early stages of Release 18, it should be noted that the two main motivations for supporting multicast reception in an inactive state are network congestion mitigation and UE power consumption. Therefore, it is not reasonable for the gNB to always keep the UE connected and set up measurement reporting every time the UE requests RRC resume.

[0152] Finding 2: Since the motivation for supporting multicast reception in an inactive state is to mitigate network congestion and save power to the UE, it is not reasonable to rely on measurement reports to guarantee QoS requirements.

[0153] Considering the above findings, it would be useful if the UE reported the measurement results when initiating an RRC resume procedure due to degraded reception quality, i.e., during the RRC resume request or RRC resume complete. Another option is for the UE to notify of the deterioration of radio conditions as the reason for the resume. With such information, the gNB can make an appropriate decision on whether or not to keep the UE connected for QoS assurance.

[0154] Proposal 1: RAN2 should agree that measurement results be reported within the RRC resume procedure, or that a new resume cause, "Multicast quality," should be introduced.

[0155] 2.1.2. Effectiveness of RSRP / RSRQ thresholds set in RRC release RAN2 agreed that "thresholds can be set by RRC release or per-MBS session PTM settings via multicast MCCH messages." In the case of dedicated configurations provided by RRC release, many settings remain effective until the corresponding timer expires. For example, dedicated frequency priority remains effective until T320 expires. This occurs regardless of cell reselection; dedicated configurations provided by the source cell remain effective even after the UE reselects the target cell.

[0156] Observation 3: According to the current specifications, many custom settings remain active until the timer expires, regardless of cell re-selection.

[0157] Regarding RSRP / RSRQ thresholds, if they are valid after cell re-selection, the following conditions may cause problems: —In the source cell, PTM is transmitted with a low MCS, so the UE set a low RSRP threshold to ensure a certain level of receive quality. - In the target cell after cell reselection, the PTM is sent with a higher MCS, but the UE continues to apply the old RSRP threshold. - As a result, the UE will experience MTCH receive errors even though RSRP is still better than the old threshold.

[0158] To avoid this problem, RSRP / RSRQ thresholds should be cell-specific, considering that NR MBS PTM transmission is cell-specific. In other words, if the UE re-selects a different cell, the old RSRP / RSRQ thresholds should be discarded.

[0159] Proposal 2: RAN2 should agree to discard RSRP / RSRQ thresholds during cell reselection.

[0160] Another potential issue with handling RSRP / RSRQ thresholds is which threshold the UE should apply when thresholds are provided by both RRC release and multicast MCCH. The current specification generally prioritizes the dedicated setting provided by RRC release over the setting provided by SIB. However, for inactive multicast reception, RAN2 agreed to "use MCCH if the PTM setting needs to be indicated, if the PTM setting needs to be changed," meaning that the PTM setting provided by RRC release may be modified by the PTM setting provided by multicast MCCH. This means that RSRP / RSRQ thresholds cannot be UE-specific, i.e., TMGI-specific, because they are overridden by multicast MCCH.

[0161] Proposal 3: RAN2 needs to ensure that the PTM settings, including the RSRP / RSRQ thresholds provided by RRC release, are always overridden by the settings provided by multicast MCCH, i.e., there are no UE-specific settings for multicast reception in an inactive state.

[0162] 2.1.3. Other Confirmation Items RAN2#123 agreed that, "For a UE receiving multicast in an RRC inactive state, the UE will reactivate the RRC connection when the measured RSRP or RSRQ[...] of the serving cell falls below the threshold[...]." The RSRP / RSRQ thresholds were introduced to ensure QoS for multicast reception in an inactive state.

[0163] On the other hand, if a multicast session is disabled by the network, an inactive UE may not receive MTCH (or temporarily not receive data) when the session is disabled. In this case, the UE is considered the same as an inactive legacy UE, and therefore RRC resume due to quality degradation (RSRP / RSRQ threshold) is not required. As the above agreement has already been suggested, it is necessary to ensure that even if RSRP / RSRQ degrades below the threshold, an inactive UE will not initiate RRC resume if the multicast session is inactive (deactivated) (or temporarily lacking data).

[0164] Proposal 4: RAN2 should ensure that an inactive UE does not initiate RRC resume even if RSRP / RSRQ deteriorates below a threshold when the multicast session is disabled (or there is no data temporarily).

[0165] In RAN2#123, the question of whether RAN2 could base its thresholds on BLER was discussed, but ultimately RAN2 decided to adopt RSRP / RSRQ.

[0166] On the other hand, in Release 17, the common understanding within RAN2 was that SFN (Single Frequency Network) could only be deployed within a DU, for example, depending on the network implementation. In inter-cell SFNs, reception quality is stable even at the cell edge by combining reception from MTCHs of different cells. However, RSRP / RSRQ are cell-specific and deteriorate at the cell edge when outside the SFN. Therefore, RSRP / RSRQ thresholds do not work well in SFN deployments, but BLER thresholds can avoid this problem.

[0167] Proposal 5: RAN2 needs to ensure that SFN (Single Frequency Network), which was permitted in Release 17 by the NW implementation, does not operate at the RSRP / RSRQ threshold in Release 18.

[0168] 2.2. Cause of Resume In Release 18, RAN2#123 agreed to reuse existing resume causes for RRC resumes due to several reasons, not just the deterioration of reception quality discussed in the previous section. However, further analysis is needed to determine which existing resume causes are applicable and whether new resume causes are truly unnecessary.

[0169] Unless a problem is identified with using one of the existing resume causes, if a resume occurs due to quality degradation or SIBx / PTM configuration errors, no new resume cause will be introduced for UEs receiving an inactive MC.

[0170] Currently, 11 resumes are defined along with the following five spare fields. ResumeCause ::= ENUMERATED {emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess, mcs-PriorityAccess, spare1, spare2, spare3, spare4, spare5}

[0171] Similar to finding 2 above, one motivation for inactive multicast reception is network congestion mitigation. Therefore, the analysis needs to consider the case when the network becomes congested.

[0172] Finding 4: Mapping RRC resumes and existing resume causes for multicast reception needs to take network congestion into account.

[0173] Typical gNB decisions when receiving an RRC resume request during network congestion can be classified as follows: —Always be prepared for emergencies; ―Prioritize access using highPriorityAccess, mps-PriorityAccess, and mcs-PriorityAccess; — Accept mt-Access and mo-Signalling (as much as possible); —mo-Data, mo-VoiceCall, mo-VideoCall, and mo-SMS may be rejected; ―In the case of RNA-Update, the new RNA is responded to by RRC release.

[0174] Finding 5: Resume allows gNBs, particularly in cases of NW congestion, to decide whether to accept, reject, or release with new RNA in response to an RRC resume request.

[0175] RAN2 agreed that the UE would initiate RRC resume in two cases: "due to quality degradation or SIBx / PTM configuration errors." From the perspective of impact on network load, the characteristics of these reasons differ as follows:

[0176] —As discussed in Section 2.1.1, in the case of RRC resume due to quality degradation, the UE must remain connected because if it is released again in an inactive state, QoS requirements will no longer be guaranteed. Given that the UE must remain connected, it does not consume additional downlink resources (as it only receives PTMs already sent to other UEs), but it does consume uplink resources (such as HARQ ACKs). During network congestion, it consumes slightly more resources compared to receiving multicast in an inactive state, but it may still take precedence over resume requests for unicast services. In other words, a gNB may prioritize RRC resume requests for multicast reception over RRC resume requests for unicast reception, but it may still reject RRC resume requests due to severe congestion.

[0177] ―In the case of an RRC resume due to a faulty SIBx / PTM configuration, if the wireless conditions are good, the UE is released by the PTM configuration, i.e., by the RRC resume, and can receive the multicast session. Therefore, in terms of network congestion, it is "light," meaning it consumes almost no downlink / uplink resources. In other words, the network can immediately accept an RRC resume request, assuming an RRC release with the PTM configuration for RRC resume.

[0178] Finding 6: gNB may sometimes refuse RRC resume due to quality degradation because it affects network congestion in order to maintain the UE in a connected state when the network is congested.

[0179] Finding 7: Due to a deficiency in SIBx / PTM configuration, the gNB can accept RRC resume and immediately release UEs with PTM configuration. This does not affect network congestion.

[0180] Considering the above discussion, RRC resumes due to poor quality could be mapped to mo-Data, mo-VoiceCall, mo-VideoCall, or mo-SMS. However, multicast reception in Connected does not require additional PDSCH resources (i.e., PTM is already provided to other UEs), so the current gNB implementation for these existing resume causes may be affected if a different type of communication (i.e., multicast reception only) is mapped to an existing resume cause.

[0181] Regarding RRC resumes due to the lack of SIBx / PTM settings, there is no cause for the mapped resume, as there is a new intent for RRC resumes with PTM settings. In rna-Update, a similar gNB decision is expected, but the gNB provides RNA instead of PTM settings for RRC resumes. In other words, the gNB cannot send an RRC release with PTM settings in response to an RRC resume request, and the gNB may mistakenly reject the UE's request even though the UE is simply requesting a PTM setting update that does not affect NW congestion.

[0182] Finding 8: Due to either degraded quality or incorrect SIBx / PTM configuration, there is no existing resume cause that conforms to the gNB determination expected in the case of an RRC resume request.

[0183] RAN2 actually identified the possible cause of the new resume in the following discussion. Reason for resuming: 1. Multicast Quality 2. Multicast Configuration

[0184] These two resume causes can easily resolve all the issues discussed above without potentially affecting the current gNB implementation. As discussed above, the two resume causes are effective in appropriately leading gNB to different outcomes. Therefore, the two new resume causes should be introduced as appropriate.

[0185] Since 3GPP is expected to begin considering 6G from release 20, 5G NR is expected to evolve in only two more releases (i.e., up to release 20 at most). Considering the history of additional resumes in past releases, three resumes for release 18 should be sufficient.

[0186] Proposal 6: RAN2 should agree on a new resume cause, "Multicast Quality," to be set when an RRC resume is initiated due to quality degradation. The expected gNB determination takes precedence over MO data, etc.

[0187] Proposal 7: RAN2 should agree that the cause of the new resume, "multicast configuration," should be set when an RRC resume is initiated due to a SIBx / PTM configuration error. The expected decision by gNB is to respond with an RRC release accompanied by PTM configuration. [Explanation of Symbols]

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

Claims

1. A communication method used in a mobile communication system that provides multicast broadcast services (MBS), A user device participating in a multicast session that is in an inactive state for Radio Resource Control (RRC) initiates an RRC connection resume procedure for a network node based on the fact that the received quality of the multicast session falls below a threshold. The user device transmits an RRC resume request message to the network node, which includes an informational element regarding the cause of the RRC resume. Initiating the RRC connection resume procedure includes setting the information element to information indicating MT (Mobile Terminated) access or information indicating MPS (Multimedia Priority Service) priority access. Communication method.

2. The user device further includes initiating the RRC connection resume procedure in response to receiving a paging message from the network node for initiating reception of a multicast session in which the user device has joined. The communication method according to claim 1.

3. Initiating the RRC connection resume procedure includes setting the information element to information indicating the MT (Mobile Terminated) access in response to the user device being unable to obtain the PTM (Point-to-Multipoint) setting from the cell re-selected by cell re-selection. The communication method according to claim 1.

4. A user device used in a mobile communication system that provides multicast broadcast services (MBS), A control unit that, in the RRC inactive state, initiates an RRC connection resume procedure for a network node based on the fact that the reception quality during multicast reception on the user device falls below a threshold, The system includes a transmission unit that transmits an RRC resume request message containing informational elements regarding the cause of the RRC resume to the network node, The control unit sets the information element to information indicating MT (Mobile Terminated) access or MPS (Multimedia Priority Service) priority access in response to starting the RRC connection resume procedure. User device.

5. A network node used in a mobile communication system that provides multicast broadcast services (MBS), The system includes a receiving unit that receives an RRC resume request message from a user device in an RRC inactive state, based on the fact that the reception quality during multicast reception on the user device has fallen below a threshold, and which includes information elements regarding the cause of the RRC resume. The aforementioned information element is information indicating MT (Mobile Terminated) access, or information indicating MPS (Multimedia Priority Service) priority access. Network node.

6. A mobile communication system that provides multicast broadcast service (MBS), The system comprises a user device and a network node that can be connected to the user device. A user device participating in a multicast session that is in a Radio Resource Control (RRC) inactive state will initiate an RRC connection resume procedure for the network node based on the multicast session's reception quality falling below a threshold. The user device transmits an RRC resume request message to the network node, which includes an informational element regarding the cause of the RRC resume. The user device sets the information element to either information indicating MT (Mobile Terminated) access or information indicating MPS (Multimedia Priority Service) priority access, in response to initiating the RRC connection resume procedure. Mobile communication system.

7. A user device participating in a multicast session that is in a Radio Resource Control (RRC) inactive state, Based on the fact that the reception quality of the multicast session falls below a threshold, the process of initiating the RRC connection resume procedure on the network node, The process involves sending an RRC resume request message containing informational elements regarding the cause of the RRC resume to the network node, and then executing the following: The process of initiating the RRC connection resume procedure includes setting the information element to information indicating MT (Mobile Terminated) access or information indicating MPS (Multimedia Priority Service) priority access. program.

8. A chipset for a user device, The user device participates in a multicast session and while the Radio Resource Control (RRC) is inactive, Based on the fact that the reception quality of the multicast session falls below a threshold, the process of initiating the RRC connection resume procedure for the network node, The process of sending an RRC resume request message containing informational elements regarding the cause of the RRC resume to the network node is performed. The process of initiating the RRC connection resume procedure includes setting the information element to information indicating MT (Mobile Terminated) access or information indicating MPS (Multimedia Priority Service) priority access. Chipset.

Images