Communication method, user device, and network node

Abstract

This communication method executed by a user device in a mobile communication system that provides a multicast broadcast service (MBS) comprises: receiving, from a network node, prohibition period information and / or network congestion degree information for determining whether or not to start a radio resource control (RRC) connection resume procedure related to a multicast session; determining, in an RRC inactive state and on the basis of the prohibition period information and / or the network congestion degree information, whether or not to start the RRC connection resume procedure; and starting the RRC connection resume procedure with respect to the network node upon determining to start the RRC connection resume procedure.

Description

COMMUNICATION METHOD, USER EQUIPMENT, AND NETWORK NODE

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

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

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

[0004] 3GPP Technical Specification: TS 38.300 V17.5.0

[0005] A communication method according to a first aspect is a communication method executed by a user equipment in a mobile communication system that provides a multicast broadcast service (MBS), and includes receiving, from a network node, prohibition period information and / or network congestion information for determining whether to start a radio resource control (RRC) connection resume procedure related to a multicast session; determining, in an RRC inactive state, whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information; and, if it is determined that the RRC connection resume procedure should be started, initiating the RRC connection resume procedure with the network node.

[0006] A user equipment according to a second aspect is a user equipment for use in a mobile communication system that provides a multicast broadcast service (MBS), and includes: a receiving unit that receives, from a network node, prohibition period information and / or network congestion information for determining whether to start a radio resource control (RRC) connection resume procedure related to a multicast session; and a control unit that, in an RRC inactive state, determines whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information. When the control unit determines to start the RRC connection resume procedure, the control unit starts the RRC connection resume procedure with the network node.

[0007] A communication method according to a third aspect is a communication method executed by a network node in a mobile communication system that provides a multicast broadcast service (MBS), and includes the steps of: managing priority information that associates information indicating the priority of multicast reception of a user device with an identifier assigned to the user device; transmitting to the user device an RRC release message that transitions the user device to a radio resource control (RRC) inactive state, the RRC release message including the identifier; receiving from the user device an RRC resume request message including the identifier; and determining whether to accept the RRC resume request of the user device based on the identifier and the priority information included in the RRC resume request message.

[0008] A network node according to a fourth aspect is a network node used in a mobile communication system that provides a multicast broadcast service (MBS), and comprises: a control unit that manages priority information that associates information indicating the priority of multicast reception of a user device with an identifier assigned to the user device; a transmission unit that transmits to the user device an RRC release message that transitions the user device to a radio resource control (RRC) inactive state, the RRC release message including the identifier; and a reception unit that receives from the user device an RRC resume request message including the identifier, and the control unit determines whether to accept the RRC resume request of the user device based on the identifier and the priority information included in the RRC resume request message.

[0009] 1 is a diagram illustrating an example of the configuration of a mobile communication system according to an embodiment. FIG. 2 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. FIG. 3 is a diagram illustrating an example of the configuration of a gNB (network node) according to an embodiment. FIG. 4 is a diagram illustrating a protocol stack configuration of a radio interface of a user plane that handles data. FIG. 5 is a diagram illustrating a protocol stack configuration of a radio interface of a control plane that handles signaling (control signals). FIG. 6 is a diagram illustrating a first example of a ping-pong phenomenon. FIG. 7 is a diagram illustrating a second example of the ping-pong phenomenon. FIG. 8 is a diagram illustrating a third example of the ping-pong phenomenon. FIG. 9 is a diagram illustrating an overview of the operation of a UE according to an embodiment. FIG. 10 is a diagram illustrating an example of a first operation pattern of a mobile communication system according to an embodiment. FIG. 11 is a diagram illustrating an example of a second operation pattern of a mobile communication system according to an embodiment. FIG. 12 is a diagram illustrating an overview of the operation of a gNB according to another embodiment. FIG. 13 is a diagram illustrating an example of the operation of a mobile communication system according to another embodiment.

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

[0011] (1) System Configuration Example Fig. 1 is a diagram showing a configuration example of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). Although 5GS will be described below as an example, the mobile communication system may be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may be at least partially based on a 6th Generation (6G) system.

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

[0013] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user, but for example, the UE 100 is a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).

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

[0015] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.

[0016] The 5GC20 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 controls data forwarding. The AMF and the UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0017] 2 is a diagram illustrating an example configuration 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 configure a wireless communication unit that performs wireless communication with the gNB 200.

[0018] The receiving unit 110 performs various reception operations under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal 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 a baseband signal (transmission signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0020] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The operations of the UE 100 described above and below may be operations 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 in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0021] 3 is a diagram showing an example configuration of a gNB 200 (network node) according to an embodiment. The gNB 200 has a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

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

[0024] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer described below. The operations of the gNB 200 described above and below may be operations under the control of 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 in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

[0025] The backhaul communication unit 240 is connected to adjacent base stations via an Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally divided), and the two units may be connected by an F1 interface, which is a fronthaul interface.

[0026] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.

[0027] The user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) 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 PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has a CRC (Cyclic Redundancy Code) parity bit scrambled by the RNTI added.

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

[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 RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

[0031] The PDCP layer performs header compression / decompression, encryption / decryption, and the like.

[0032] The SDAP layer maps IP flows, which are units for Quality of Service (QoS) control by the core network, to radio bearers, which are units for QoS control by the Access Stratum (AS). Note that if the RAN is connected to the EPC, SDAP may not be required.

[0033] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0034] The protocol stack of the radio interface of the control plane has an RRC (Radio Resource Control) layer and an NAS (Non-Access Stratum) layer instead of the SDAP layer shown in FIG.

[0035] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0036] The NAS layer (also simply referred to as "NAS") located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300A. Note that the UE 100 has an application layer and the like in addition to the radio interface protocol. Also, a layer lower than the NAS layer is referred to as the AS layer (also simply referred to as "AS").

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

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

[0039] Point-to-Multipoint (PTM) delivery is applied to broadcast communication services. In the case of PTM transmission, the gNB 200 delivers a single copy of an MBS packet to a set (group) of multiple UEs 100. For example, the gNB 200 schedules a group-common PDSCH scrambled by a G-RNTI (Group RNTI), which is a group-common RNTI, using a group-common PDCCH having a CRC scrambled by the G-RNTI.

[0040] In the case of a broadcast communication service, the UE 100 receives a broadcast session in the following procedure. First, the UE 100 receives a system information block type 20 (SIB20) from the gNB 200. The SIB20 includes a configuration of a multicast control channel (MCCH), which is a type of logical channel. Second, the UE 100 receives the MCCH from the gNB 200 based on the SIB20. The MCCH includes a PTM configuration. The PTM configuration transmits a configuration (MTCH configuration) for a multicast traffic channel (MTCH), which is a type of logical channel, and a broadcast MRB configuration, 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, the UE 100 receives the MTCH based on the MCCH. The MTCH transmits the broadcast session (specifically, MBS data belonging to the broadcast session).

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

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

[0043] The UE 100 can receive the multicast session only after joining the multicast session (session join). Joining the multicast session may mean being registered in the network 5 (CN 20) as the UE 100 that can receive the multicast session.

[0044] In the case of a multicast communication service, only UEs 100 in an RRC connected state can receive a multicast session in 3GPP Release 17. On the other hand, in 3GPP Release 18, the standard is extended so that UEs 100 in an RRC inactive state can also receive a multicast session.

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

[0046] In the case of a multicast communication service, the UE 100 in the RRC connected state receives a multicast session in the following procedure. First, the UE 100 receives an RRC Reconfiguration message from the gNB 200. The RRC Reconfiguration message is a message transmitted on a dedicated control channel (DCCH). The RRC Reconfiguration message transmits a setting (MTCH setting) for the MTCH for receiving the multicast session and a setting of a multicast MRB, which is an MRB for the multicast session. Second, the UE 100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, MBS data belonging to the multicast session).

[0047] (2.2.2) Multicast Reception in RRC Inactive State The UE 100 in the RRC inactive state can receive a multicast session (specifically, MBS data belonging to the multicast session) using the PTM distribution mechanism.

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

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

[0050] (2.2.3) Group Notification When there is temporarily no data to transmit to UE 100 in an active multicast session, gNB 200 may transition UE 100 to an RRC inactive state. When the multicast session is deactivated, gNB 200 may transition UE 100 to an RRC idle state or an RRC inactive state.

[0051] A gNB 200 that supports MBS uses a group notification mechanism to notify UEs 100 in an RRC idle state or an RRC inactive state when a multicast session is activated by CN 20. For example, a gNB 200 that supports MBS may use a group notification mechanism to notify UEs 100 in an RRC inactive state when a multicast session has been activated and there is multicast session data to be distributed in the gNB 200.

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

[0053] The group notification paging message includes a session identifier (MBS Session ID) that is used to page all UEs 100 in RRC idle and RRC inactive states that have joined the associated MBS multicast session, i.e., the UEs 100 are not paged individually.

[0054] When UE 100 transitions to the RRC connected state, UE 100 may stop monitoring group notifications related to a particular multicast session. That is, UE 100 stops checking the MBS session ID in paging messages. UE 100 does not monitor group notifications in cases where UE 100 leaves this multicast session, network 5 requests UE 100 to leave, or network 5 releases the multicast session.

[0055] The group notification may be performed using the MCCH or may be performed using an MCCH Change Notification. When the MCCH is used, the determination may be made based on whether or not an MTCH configuration for the MBS session of interest exists in the MCCH. When the MCCH Change Notification is used, the group notification may be notified in a predetermined bit of the DCI.

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

[0057] (3.1) Operation Overview In the embodiment, a scenario is assumed in which UE 100 in an RRC inactive state starts an RRC connection resume (also referred to as "RRC resume") in relation to a multicast session (multicast reception). Here, the case in which UE 100 in an RRC inactive state starts an RRC connection resume in relation to a multicast session is when the reception quality during multicast reception at UE 100 is poor, and / or when UE 100 needs to acquire a multicast reception setting (PTM setting) from gNB 200. In the embodiment, a scenario in which UE 100 starts an RRC connection resume in response to poor reception quality during multicast reception at UE 100 in an RRC inactive state is mainly assumed.

[0058] A case where the reception quality during multicast reception at UE 100 is poor is a case where the reference signal received power (RSRP) measured by UE 100 for the serving cell is below the RSRP threshold set in UE 100 by the network 5, and / or a case where the reference signal received quality (RSRQ) measured by UE 100 for the serving cell is below the RSRQ threshold set in UE 100 by the network 5. However, a case where the reception quality during multicast reception at UE 100 is poor may also be a case where the bit error rate (BER) measured by UE 100 for the multicast session exceeds the BER threshold set in UE 100 by the network 5, and / or a case where the block error rate (BLER) measured by UE 100 for the multicast session exceeds the BLER threshold set in UE 100 by the network 5.

[0059] The threshold value to be compared with the reception quality during such multicast reception can be set by PTM setting (multicast reception setting) on ​​an MBS session basis from the network 5 (gNB 200) to the UE 100 by an RRC Release message or a multicast MCCH (multicast MCCH message). In an embodiment, the UE 100 performing multicast reception in an RRC inactive state starts an RRC connection resume procedure when the reception quality of the serving cell is worse than the threshold value set by the network 5.

[0060] In addition, a case where UE100 needs to acquire the multicast reception setting from gNB200 is a case where UE100 has not received the multicast reception setting of the multicast session in which UE100 has joined in the RRC Release message, and the serving cell does not provide the multicast reception setting on the multicast MCCH, and UE100 may receive a paging message (group notification) indicating activation of the multicast session from the serving cell. A case where UE100 needs to acquire the multicast reception setting from gNB200 is a case where UE100 reselects a cell from the first cell to the second cell, and the second cell (reselected cell) does not provide the multicast reception setting of the multicast session in which UE100 has joined in the multicast MCCH.

[0061] In the embodiment, a scenario is mainly assumed in which the reception quality at the UE 100 performing multicast reception in an RRC inactive state is worse than a threshold set by the network 5. In such a scenario, a ping-pong phenomenon may occur in which an RRC connection resume procedure and an RRC release procedure are repeated in a short period of time.

[0062] 6 is a diagram illustrating a first example of the ping-pong phenomenon. In the following description of the embodiment, it is assumed that the UE 100 has already joined a certain multicast session, and the multicast session is also referred to as a joined multicast session. "Having joined a multicast session" may mean a state in which the UE 100 is registered in the network 5 (CN 20) as the UE 100 that receives the multicast session.

[0063] In STEP 1, gNB200 transmits to UE100 an RRC Release message (i.e., an RRC Release message including a suspend setting) for transitioning UE100 to an RRC inactive state. UE100 transitions from an RRC connected state to an RRC inactive state in response to receiving the RRC Release message. Note that UE100 may start multicast reception in the RRC connected state. gNB200 may indicate to UE100 which multicast services (multicast sessions) can be received in the RRC inactive state in the suspend setting in the RRC Release message.

[0064] The RRC Release message transmitted by gNB200 includes multicast reception settings (PTM settings) for multicast sessions in which UE100 has joined, and the multicast reception settings may include thresholds (RSRP threshold and / or RSRQ threshold). Alternatively, the multicast MCCH transmitted (broadcast) by gNB200 includes multicast reception settings (PTM settings) for each multicast session, and the multicast reception settings may include thresholds (RSRP threshold and / or RSRQ threshold).

[0065] In STEP 2, UE 100, which performs multicast reception in an RRC inactive state, measures the reception quality of the serving cell and compares the measurement result (measured values ​​of RSRP and / or RSRQ) with a threshold. Here, if the reception quality at UE 100 is worse than the threshold set by network 5, UE 100 starts an RRC connection resume procedure for gNB 200 and transmits an RRC resume request (Resume Request) message to gNB 200. When the RRC connection resume procedure is completed, UE 100 transitions from the RRC inactive state to the RRC connected state.

[0066] For example, if the threshold setting by the gNB 200 is inappropriate and / or if the radio environment in which the UE 100 is located is poor, STEP 2 may occur immediately after STEP 1. In this case, an RRC connection resume procedure may occur immediately after an RRC release procedure, which may result in inefficient operation.

[0067] FIG. 7 is a diagram for explaining a second example of the ping-pong phenomenon.

[0068] In STEP 1, UE 100, which performs multicast reception in an RRC inactive state, measures the reception quality of the serving cell and compares the measurement result (measured values ​​of RSRP and / or RSRQ) with a threshold. Here, if the reception quality at UE 100 is worse than the threshold set by network 5, UE 100 starts an RRC connection resume procedure with gNB 200 and transmits an RRC Resume Request message to gNB 200.

[0069] In STEP 2, the gNB 200 that has received the RRC Resume Request message transmits an RRC Release message including new multicast reception settings and suspend settings to the UE 100. That is, before the RRC connection resume procedure is completed, the gNB 200 provides the UE 100 with the new multicast reception settings and causes the UE 100 to maintain the RRC inactive state. The UE 100 applies the new multicast reception settings and performs multicast reception while maintaining the RRC inactive state. The new multicast reception settings may include a threshold setting.

[0070] In STEP 3, UE 100, which performs multicast reception in an RRC inactive state, measures the reception quality of the serving cell and compares the measurement result (measured values ​​of RSRP and / or RSRQ) with a threshold. Here, if the reception quality at UE 100 is worse than the threshold set by network 5, UE 100 starts an RRC connection resume procedure with gNB 200 and transmits an RRC Resume Request message to gNB 200.

[0071] For example, if the threshold setting by the gNB 200 is inappropriate and / or if the radio environment in which the UE 100 is located is poor, STEP 3 may occur immediately after STEP 2. In this case, an RRC connection resume procedure may occur immediately after an RRC release procedure, which may result in inefficient operation.

[0072] FIG. 8 is a diagram for explaining a third example of the ping-pong phenomenon.

[0073] In STEP 1, gNB200 decides to transition UE100, which is receiving multicast, to the RRC inactive state due to network congestion, and transmits an RRC Release message (RRC Release message including suspend setting) to UE100. UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message. Note that gNB200 may indicate to UE100 which multicast services (multicast sessions) can be received in the RRC inactive state in the suspend setting in the RRC Release message.

[0074] The RRC Release message transmitted by gNB200 includes multicast reception settings (PTM settings) for multicast sessions in which UE100 has joined, and the multicast reception settings may include thresholds (RSRP threshold and / or RSRQ threshold). Alternatively, the multicast MCCH transmitted (broadcast) by gNB200 includes multicast reception settings (PTM settings) for each multicast session, and the multicast reception settings may include thresholds (RSRP threshold and / or RSRQ threshold).

[0075] In STEP 2, UE 100, which performs multicast reception in an RRC inactive state, measures the reception quality of the serving cell and compares the measurement result (measured values ​​of RSRP and / or RSRQ) with a threshold. Here, if the reception quality at UE 100 is worse than the threshold set by network 5, UE 100 initiates an RRC connection resume procedure with gNB 200 and transmits an RRC Resume Request message to gNB 200. However, gNB 200 determines that network congestion has not yet been resolved, and therefore decides to maintain UE 100 in the RRC inactive state.

[0076] In STEP 3, gNB200 transmits an RRC Release message (an RRC Release message including a suspend setting) to UE100 to maintain UE100, which is receiving multicast, in an RRC inactive state, as in STEP 1. UE100 maintains the RRC inactive state in response to receiving the RRC Release message.

[0077] As described above, when the network is congested, STEP 3 may occur immediately after STEP 2. In this case, an RRC release procedure may occur immediately after an RRC connection resume procedure, which may result in inefficient operation. Furthermore, STEP 2 may become a wasteful process.

[0078] In the following embodiment, an operation that can suppress the occurrence of the ping-pong phenomenon as described above will be described. Fig. 9 is a diagram showing an overview of the operation of the UE 100 according to the embodiment.

[0079] In step S11, UE100 receives prohibition period information and / or network congestion information from gNB200 to determine whether or not to start an RRC connection resume procedure related to the multicast session.

[0080] The RRC connection resume procedure related to the multicast session is an RRC connection resume procedure caused by poor reception quality during multicast reception at the UE 100, or an RRC connection resume procedure caused by the need for the UE 100 to acquire a multicast reception setting (PTM setting) from the gNB 200. In the following embodiment, the RRC connection resume procedure caused by poor reception quality during multicast reception at the UE 100 will be mainly described, but the embodiment may also be an RRC connection resume procedure caused by the need for the UE 100 to acquire a multicast reception setting from the gNB 200.

[0081] In step S12, the UE 100 determines whether to start an RRC connection resume procedure related to the multicast session in the RRC inactive state based on the prohibition period information and / or the network congestion information in step S11.

[0082] In step S13, if UE100 determines to initiate an RRC connection resume procedure related to the multicast session, it initiates an RRC connection resume procedure with gNB200.

[0083] In this manner, in the embodiment, the UE 100 in the RRC inactive state determines whether to start the RRC connection resume procedure related to the multicast session based on the prohibition period information and / or the network congestion information. This enables the UE 100 to start the RRC connection resume procedure at an appropriate timing, thereby suppressing the occurrence of the ping-pong phenomenon described above.

[0084] 9 includes a receiver 110 that receives prohibition period information and / or network congestion information from a gNB 200 for determining whether to start an RRC connection resume procedure related to a multicast session, and a controller 130 that determines whether to start an RRC connection resume procedure in an RRC inactive state based on the prohibition period information and / or network congestion information. When the controller 130 determines to start the RRC connection resume procedure, it starts the RRC connection resume procedure for the gNB 200.

[0085] In a first operation pattern of the embodiment, in step S11, the UE 100 receives an RRC Release message from the gNB 200, which includes prohibition period information indicating a period during which the start of an RRC connection resume procedure related to a multicast session is prohibited, and transitions the UE 100 to an RRC inactive state. In step S12, the UE 100 determines that the RRC connection resume procedure related to the multicast session can be initiated if the period indicated by the prohibition period information has expired. As a result, the UE 100 is prohibited from initiating an RRC connection resume procedure related to a multicast session from the time of transitioning to the RRC inactive state until the period indicated by the prohibition period information expires. This makes it possible to suppress the occurrence of the ping-pong phenomenon described above.

[0086] Specifically, in the first operation pattern of the embodiment, in step S12, UE100 determines to start an RRC connection resume procedure if the period indicated by the prohibition period information has expired and the reception quality during multicast reception at UE100 has deteriorated and / or UE100 needs to obtain multicast reception settings from gNB200.

[0087] In the first operation pattern of the embodiment, the prohibition period information may be associated with a multicast session identifier (MBS session ID). In step S12, when the UE 100 is participating in and / or receiving a specific multicast session indicated by the multicast session identifier and the period indicated by the prohibition period information has expired, the UE 100 may determine that it is possible to start an RRC connection resume procedure related to the specific multicast session. In this way, by making the prohibition period configurable on a multicast session basis, it is possible to set a prohibition period only for some multicast sessions and / or to set a different prohibition period for each multicast session.

[0088] In a second operation pattern of the embodiment, in step S11, the UE 100 receives broadcast signaling from the gNB 200, including network congestion information indicating the congestion level of the gNB 200. The broadcast signaling may be an SIB. The SIB may be an SIB for MBS, such as the above-mentioned SIB20 or SIBx. Alternatively, the broadcast signaling may be a multicast MCCH (multicast MCCH message). In step S12, the UE 100 determines that the RRC connection resume procedure can be initiated if the congestion level (network congestion level) indicated by the network congestion information is less than a predetermined level. This allows the UE 100 to refrain from initiating an RRC connection resume procedure related to a multicast session until the network congestion is resolved (or alleviated) after transitioning to the RRC inactive state. This makes it possible to suppress the occurrence of the ping-pong phenomenon described above.

[0089] Specifically, in the second operation pattern of the embodiment, in step S12, UE100 determines to start an RRC connection resume procedure if the congestion level (network congestion level) indicated by the network congestion level information is below a predetermined level and the reception quality during multicast reception at UE100 has deteriorated and / or UE100 needs to obtain multicast reception settings from gNB200.

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

[0091] (3.2.1) First Operation Pattern In the first operation pattern, the gNB 200 notifies the UE 100 of a prohibition period for RRC resume related to a multicast session by an RRC Release message. As described above, the RRC resume may be related to deterioration of reception quality. The RRC resume may be related to acquisition of a multicast reception setting (PTM setting). The prohibition period may be set on a multicast session (MBS session ID) basis.

[0092] FIG. 10 is a diagram showing an example of a first operation pattern of the mobile communication system 1 according to the embodiment.

[0093] In step S101, UE100 is in an RRC connected state in the cell of gNB200.

[0094] In step S102, the gNB 200 determines to have the UE 100 perform multicast reception in the RRC inactive state, and transmits to the UE 100 an RRC Release message including a suspend setting, i.e., an RRC Release message for transitioning the UE 100 to the RRC inactive state. The UE 100 receives the RRC Release message. The RRC Release message may include a multicast reception setting (PTM setting) for multicast reception in the RRC inactive state. The multicast reception setting may include a threshold to be compared with the multicast reception quality.

[0095] In the first operation pattern, the gNB 200 transmits prohibition period information indicating a prohibition period for starting RRC resume related to a multicast session to the UE 100 in an RRC Release message. The prohibition period information may be a timer value corresponding to the prohibition period. When the gNB 200 causes the UE 100 to receive multicast in an RRC inactive state due to network congestion, the gNB 200 may determine the prohibition period by estimating the time when the network congestion will be resolved.

[0096] The prohibition period information may be associated with a multicast session identifier (MBS session ID). For example, in the suspend setting in the RRC Release message, the gNB 200 may indicate to the UE 100 which multicast services (multicast sessions) are receivable in the RRC inactive state. Here, the gNB 200 may include in the RRC Release message the MBS session ID of the multicast session that is permitted to be received in the RRC inactive state and prohibition time information associated with the MBS session ID. Alternatively, when the gNB 200 includes in the RRC Release message the multicast reception setting of the multicast session to which the UE 100 has joined, the gNB 200 may include in the RRC Release message prohibition time information associated with the multicast reception setting. For example, the multicast reception setting may include an MBS session ID and prohibition time information associated with the MBS session ID.

[0097] In step S103, UE 100 transitions to an RRC inactive state in response to receiving the RRC Release message in step S102. UE 100 may start a timer in which a prohibition period (timer value) is set when UE 100 receives the RRC Release message in step S102. UE 100 may start a timer in which a prohibition period (timer value) is set when UE 100 transitions to the RRC inactive state in step S103.

[0098] In step S104, the gNB 200 may transmit a multicast MCCH including a multicast reception setting (PTM setting) for multicast reception in an RRC inactive state. The UE 100 may receive the multicast MCCH. The multicast reception setting may include a threshold value to be compared with the multicast reception quality.

[0099] In step S105, gNB200 transmits MBS data (multicast data) of the multicast session in which UE100 has joined on MTCH.

[0100] In step S106, UE100 applies the multicast reception setting received in step S102 or S104 and performs multicast reception in the RRC inactive state. Specifically, UE100 receives MBS data (multicast data) of the multicast session in which UE100 has joined from gNB200 on MTCH. UE100 also measures the reception quality (e.g., RSRP and / or RSRQ) for gNB200 (serving cell).

[0101] In step S107, the UE 100 compares the measurement result of the reception quality in step S106 with the threshold set in the multicast reception setting. If the measurement result of the reception quality in step S106 is not worse than the threshold (step S107: NO), the UE 100 returns the process to step S106.

[0102] On the other hand, if the measurement result of the reception quality in step S106 is worse than the threshold (step S107: YES), in step S108, the UE 100 determines whether the prohibition period has expired (for example, whether the timer has expired). If the prohibition period has not expired (step S108: NO), for example, if the timer is running, the UE 100 does not start the RRC connection resume procedure and returns the process to step S106.

[0103] If the prohibition period has expired (step S108: YES), in step S109, the UE 100 starts an RRC connection resume procedure and transmits an RRC Resume Request message to the gNB 200. The gNB 200 receives the RRC Resume Request message.

[0104] As a variation of this operation example, the order of the determination in step S107 and the determination in step S108 may be reversed. For example, the UE 100 in the RRC inactive state may not perform the threshold determination of the multicast reception quality (step S107) if the prohibition period has not expired, but may perform the threshold determination of the multicast reception quality (step S107) after the prohibition period has expired.

[0105] Also, in this operation example, in step S107, UE100 determines the need to start the RRC connection resume procedure due to poor reception quality during multicast reception. However, in addition to or instead of such a determination, UE100 may determine the need to start the RRC connection resume procedure due to the need to acquire multicast reception settings from gNB200. Alternatively, when UE100 receives a group notification (paging message) related to a multicast session but including the MBS session ID of a multicast session in which UE100 has joined, the prohibition period may not be applied.

[0106] In addition, in the case of an RRC resume not related to a multicast session, the prohibition period may not be applied. The not related to a multicast session may be, as in conventional unicast communication, that uplink data is generated in the UE 100 and / or that a normal paging message addressed to the UE 100 is received by the UE 100.

[0107] (3.2.2) Second operation pattern In the second operation pattern, gNB200 broadcasts network congestion information, and UE100 determines whether to start RRC resume depending on the network congestion information.

[0108] FIG. 11 is a diagram showing an example of the second operation pattern of the mobile communication system 1 according to the embodiment.

[0109] In step S131, UE100 is in an RRC connected state in the cell of gNB200.

[0110] In step S132, gNB200 decides to have UE100 perform multicast reception in the RRC inactive state, and transmits an RRC Release message including a suspend setting, i.e., an RRC Release message for transitioning UE100 to the RRC inactive state, to UE100. UE100 receives the RRC Release message. The RRC Release message may include a multicast reception setting (PTM setting) for multicast reception in the RRC inactive state. The multicast reception setting may include a threshold value to be compared with the multicast reception quality.

[0111] In the second operation pattern, the gNB 200 may include a threshold to be compared with the network congestion level (also referred to as the "congestion level threshold") in an RRC Release message and transmit it to the UE 100. Hereinafter, in order to distinguish it from the congestion level threshold, the threshold to be compared with the multicast reception quality will also be referred to as the "reception quality threshold."

[0112] In step S133, in response to the reception of the RRC Release message in step S132, the UE 100 transitions to an RRC inactive state.

[0113] In step S134, the gNB 200 may transmit a multicast MCCH including a multicast reception setting (PTM setting) for multicast reception in an RRC inactive state. The UE 100 may receive the multicast MCCH. The multicast reception setting may include a threshold to be compared with the multicast reception quality. In the second operation pattern, the gNB 200 may transmit a congestion threshold in the multicast MCCH. Alternatively, the gNB 200 may transmit network congestion information (described later) in the multicast MCCH.

[0114] In step S135, gNB200 transmits MBS data (multicast data) of the multicast session in which UE100 has joined on MTCH.

[0115] In step S136, UE100 applies the multicast reception setting received in step S132 or S134 and performs multicast reception in the RRC inactive state. Specifically, UE100 receives MBS data (multicast data) of the multicast session in which UE100 has joined from gNB200 on MTCH. UE100 also measures the reception quality (e.g., RSRP and / or RSRQ) for gNB200 (serving cell).

[0116] In step S137, UE100 compares the measurement result of the reception quality in step S136 with the reception quality threshold set in the multicast reception setting. In this operation example, UE100 determines the need to start the RRC connection resume procedure due to poor reception quality during multicast reception. However, in addition to or instead of such a determination, UE100 may determine the need to start the RRC connection resume procedure due to the need to acquire the multicast reception setting from gNB200.

[0117] If the measurement result of the reception quality in step S136 is not worse than the reception quality threshold value (step S137: NO), the UE 100 returns the process to step S136.

[0118] On the other hand, if the measurement result of the reception quality in step S136 is worse than the threshold (step S137: YES), in step S138, UE100 receives (acquires) an SIB including network congestion information from gNB200. Here, gNB200 transmits (broadcasts) an SIB including network congestion information. The network congestion information may include at least one of the following information 1) to 3).

[0119] 1) Information indicating whether the network 5 is congested (1-bit flag information). The information may be information indicating whether the gNB 200 is congested. The information may be information indicating whether the cell of the gNB 200 (the serving cell of the UE 100) is congested.

[0120] 2) Numerical information indicating the congestion level of the network 5 (or the gNB 200 or the cell). The information may be information indicating the congestion level of the network 5 (or the gNB 200 or the cell) as a percentage (e.g., 80%). The congestion level may be the usage rate of radio resources. The congestion level may be the usage rate of hardware resources.

[0121] 3) Information (1-bit flag information) indicating whether to permit the start of RRC connection resume related to a multicast session. The information may include information indicating whether to permit the start of RRC connection resume caused by deterioration of multicast reception quality and / or information indicating whether to permit the start of RRC connection resume caused by acquisition of multicast reception configuration.

[0122] In step S139, the UE 100 determines whether or not the network congestion level is below a predetermined level, based on the network congestion level information in step S138.

[0123] For example, if the network congestion information includes information (1-bit flag information) indicating whether network 5 is congested or not, UE 100 may determine that the network congestion is below a predetermined level if the information does not indicate that network 5 is congested.

[0124] If the network congestion information includes numerical information indicating the congestion level of network 5 (or gNB200 or cell), UE100 may determine that the network congestion level is below a predetermined level if the numerical value indicated by the information is lower than the congestion level threshold.

[0125] If the network congestion information includes information (1-bit flag information) indicating whether to allow the start of an RRC connection resume related to a multicast session, UE 100 may determine that the network congestion is below a predetermined level if the information indicates that the start of the RRC connection resume is allowed.

[0126] If it is determined that the network congestion level is equal to or greater than the predetermined level (step S139: NO), the UE 100 returns the process to step S136. Alternatively, the UE 100 may notify the NAS that the network is congested or that RRC resume cannot be performed in the AS, and start an RRC connection resume for multicast reception in unicast. In this case, the UE 100 transmits an RRC Resume Request message to the gNB 200, assuming that the message may be rejected by the gNB 200.

[0127] On the other hand, if it is determined that the network congestion level is less than the predetermined level (step S139: YES), in step S140, the UE 100 starts an RRC connection resume procedure and transmits an RRC Resume Request message to the gNB 200. The gNB 200 receives the RRC Resume Request message.

[0128] As a variation of this operation example, the order of the determination in step S137 and the determination in step S139 may be reversed. For example, the UE 100 in the RRC inactive state may not perform the threshold determination of the multicast reception quality (step S137) when the network congestion level is equal to or higher than a predetermined level, but may perform the threshold determination of the multicast reception quality (step S137) after the network congestion level falls below the predetermined level.

[0129] The second operation pattern may be implemented in combination with the first operation pattern. In this case, the UE 100 may determine that the RRC connection resume procedure can be started only when the prohibition period has expired and the network congestion level is less than a predetermined level.

[0130] (4) Another embodiment will be described, focusing mainly on the differences from the above-described embodiment. This embodiment can be implemented in combination with the above-described embodiment.

[0131] In this embodiment, an operation that can suppress the occurrence of the ping-pong phenomenon as described in Figures 7 and 8 will be described. When the UE 100 starts RRC connection resume in relation to a multicast session and the priority of the UE 100 is high, it is desirable that the gNB 200 transition the UE 100 to an RRC connected state to provide high-quality services even during network congestion. In this embodiment, when a UE 100 with a high priority starts RRC connection resume in relation to a multicast session, the gNB 200 can transition the UE 100 to an RRC connected state, thereby suppressing the occurrence of the ping-pong phenomenon.

[0132] Figure 12 is a diagram showing an overview of the operation of gNB200 in this embodiment.

[0133] In step S21, the gNB 200 manages priority information that associates information indicating the priority of multicast reception of the UE 100 (also referred to as "multicast priority") with an identifier assigned to the UE 100. The identifier is an inactive RNTI (I-RNTI) assigned by the gNB 200 to the UE 100 in the RRC inactive state.

[0134] In step S22, gNB200 sends to UE100 an RRC RRC Release message that transitions UE100 to an RRC inactive state and includes an I-RNTI to be assigned to UE100.

[0135] Then, in step S23, gNB200 receives an RRC Resume Request message including I-RNTI from UE100.

[0136] In step S24, gNB200 determines whether to accept the RRC resume request from UE100 in step S23 based on the I-RNTI included in the RRC Resume Request message in step S23 and the priority information in step S21.

[0137] As described above, according to the present embodiment, the gNB 200 can identify the multicast priority of the UE 100 based on the I-RNTI included in the RRC Resume Request message from the UE 100. Therefore, it is possible to appropriately determine whether to accept the RRC resume request of the UE 100.

[0138] The gNB 200 that operates as shown in FIG. 12 includes a control unit 230 that manages priority information that associates information indicating the priority (multicast priority) of multicast reception of the UE 100 with the I-RNTI assigned to the UE 100, a transmission unit 210 that transmits an RRC Release message including the I-RNTI to the UE 100, which is a message that transitions the UE 100 to an RRC inactive state, and an RRC Resume Request message including the I-RNTI from the UE 100. The control unit 230 determines whether to accept the RRC resume request of the UE 100 based on the I-RNTI included in the RRC Resume Request message and the priority information that it manages.

[0139] In this embodiment, gNB200 may receive UE information indicating multicast priority from a core network device (e.g., AMF300A) and determine the multicast priority of UE100 based on the UE information.

[0140] 13 is a diagram showing an example of the operation of the mobile communication system 1 according to this embodiment. In this operation example, the gNB 200 acquires information regarding the priority of multicast reception of the UE 100 from the AMF 300A. Then, when the gNB 200 transitions the UE 100 to an RRC inactive state, it determines the priority regarding the RRC connection resume of the UE 100 and retains the priority information in which the priority is associated with the I-RNTI as a UE context.

[0141] In step S201, UE100 is in an RRC connected state in the cell of gNB200.

[0142] In step S202, gNB200 receives (acquires) priority information for each UE100 from CN20 (AMF300A). Here, AMF300A transmits the priority information for each UE100 to gNB200 over the NG interface.

[0143] For example, CN20 (AMF300A) may refer to the subscriber information of each UE100 and set the priority low if the user has a contract for best-effort multicast reception, and set the priority high if the contract guarantees quality of service (QoS) for multicast reception.

[0144] The CN 20 (AMF 300A) may transmit priority information for each UE 100 in a UE Context Setup / Update message defined in the application protocol (AP) of the NG interface. The priority information may be, for example, delay-tolerant multicast or low-priority multicast.

[0145] In step S203, gNB200 decides to have UE100 perform multicast reception in the RRC inactive state, determines the priority of multicast reception in UE100's RRC connected state (or when RRC resumes), and associates it with the I-RNTI and retains it as a UE context.

[0146] In step S204, the gNB 200 transmits to the UE 100 an RRC Release message including a suspend setting, i.e., an RRC Release message for transitioning the UE 100 to an RRC inactive state. The suspend setting includes an I-RNTI assigned to the UE 100. The UE 100 receives the RRC Release message and holds the assigned I-RNTI. The RRC Release message may include a multicast reception setting (PTM setting) for multicast reception in the RRC inactive state. The multicast reception setting may include a threshold to be compared with the multicast reception quality.

[0147] In step S205, in response to the reception of the RRC Release message in step S204, the UE 100 transitions to an RRC inactive state.

[0148] In step S206, the gNB 200 may transmit a multicast MCCH including a multicast reception setting (PTM setting) for multicast reception in an RRC inactive state. The UE 100 may receive the multicast MCCH. The multicast reception setting may include a threshold value to be compared with the multicast reception quality.

[0149] In step S207, gNB200 transmits MBS data (multicast data) of the multicast session in which UE100 has joined on MTCH.

[0150] In step S208, UE100 applies the multicast reception setting received in step S204 or S206 and performs multicast reception in the RRC inactive state. Specifically, UE100 receives MBS data (multicast data) of the multicast session in which UE100 has joined from gNB200 on MTCH. UE100 also measures the reception quality (e.g., RSRP and / or RSRQ) for gNB200 (serving cell).

[0151] In step S209, UE100 compares the measurement result of the reception quality in step S208 with the reception quality threshold set in the multicast reception setting. In this operation example, UE100 determines the need to start the RRC connection resume procedure due to poor reception quality during multicast reception. However, in addition to or instead of such a determination, UE100 may determine the need to start the RRC connection resume procedure due to the need to acquire the multicast reception setting from gNB200.

[0152] If the measurement result of the reception quality in step S208 is not worse than the reception quality threshold (step S209: NO), the UE 100 returns the process to step S208.

[0153] On the other hand, if the measurement result of the reception quality in step S208 is worse than the threshold (step S209: YES), in step S210, the UE 100 starts an RRC connection resume procedure and transmits an RRC Resume Request message including the assigned I-RNTI to the gNB 200. The gNB 200 receives the RRC Resume Request message.

[0154] In step S211, gNB200 identifies the UE context from the I-RNTI in the RRC Resume Request message of step S210 and identifies the priority information of UE100.

[0155] In step S212, the gNB 200 determines whether to accept the RRC Resume Request message of step S210 based on the identified priority (multicast priority). For example, if the multicast priority of the UE 100 is high, the gNB 200 may determine to accept the RRC resume even during network congestion. If the multicast priority of the UE 100 is low, the gNB 200 may determine not to accept the RRC resume during network congestion.

[0156] If the gNB200 accepts the RRC resume, it may transmit an RRC Resume message to the UE100 and transition the UE100 to an RRC connected state by receiving an RRC Resume Complete message from the UE100. On the other hand, if the gNB200 does not accept the RRC resume, it may transmit an RRC Release message including a suspend setting to the UE100 and maintain the UE100 in an RRC inactive state.

[0157] (5) Supplementary Note 1 In the above-described embodiment, multicast reception in the RRC inactive state has been mainly described, but the operation according to the above-described embodiment may also be applied to multicast reception in the RRC idle state. In the RRC idle state, the above-described RRC resume (Resume) is replaced with RRC establishment (Establishment), and the above-described resume cause is replaced with establishment cause.

[0158] The above-described operational flows are not limited to being implemented independently, but can be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed. Furthermore, the order of steps in each flow may be changed as appropriate.

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

[0160] That is, the UE 100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that relays signals. Such a terminal function unit is referred to as an MT. Examples of the MT include, in addition to the IAB-MT, an NCR (Network Controlled Repeater)-MT and a RIS (Reconfigurable Intelligent Surface)-MT.

[0161] 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). A network node may also be configured by a combination of at least a part of a core network device and at least a part of a base station.

[0162] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, the program can 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 particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Furthermore, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a portion of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0163] The functions performed by the UE 100 or the gNB 200 may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, or means refers to hardware that is programmed to perform the described functions or hardware that executes them. The hardware may be any hardware disclosed herein or any hardware known to be programmed or capable of performing the described functions. If the hardware is a processor, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0164] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

[0165] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

[0166] This application claims priority to U.S. Provisional Application No. 63 / 540,274 (filed September 25, 2023), the entire contents of which are incorporated herein by reference.

[0167] (6) Second Supplementary Note The following is a supplementary note regarding the features of the above-described embodiment.

[0168] (Supplementary Note 1) A communication method executed by a user equipment in a mobile communication system that provides a multicast broadcast service (MBS), comprising: receiving, from a network node, prohibition period information and / or network congestion information for determining whether to start a radio resource control (RRC) connection resume procedure related to a multicast session; determining, in an RRC inactive state, whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information; and, when it is determined to start the RRC connection resume procedure, initiating the RRC connection resume procedure with the network node.

[0169] (Supplementary Note 2) The communication method according to Supplementary Note 1, wherein the receiving includes receiving an RRC release message from the network node, the RRC release message including the prohibition period information indicating a period during which initiation of the RRC connection resume procedure is prohibited, and causing the user equipment to transition to the RRC inactive state; and the determining includes determining that the RRC connection resume procedure can be initiated if the period indicated by the prohibition period information has expired.

[0170] (Supplementary Note 3) The communication method according to Supplementary Note 2, wherein the determining step includes determining to start the RRC connection resume procedure when the period indicated by the prohibition period information has expired and reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to acquire a multicast reception setting from the network node.

[0171] (Supplementary Note 4) The communication method according to Supplementary Note 2 or 3, wherein the prohibition period information is associated with a multicast session identifier, and the determining step includes determining that the RRC connection resume procedure related to the specific multicast session can be initiated if the user equipment is participating in and / or receiving a specific multicast session indicated by the multicast session identifier and the period indicated by the prohibition period information has expired.

[0172] (Supplementary Note 5) The communication method according to any one of Supplementary Notes 1 to 4, wherein the receiving includes receiving, from the network node, broadcast signaling including the network congestion information indicating a congestion level of the network node, and the determining includes determining that the RRC connection resume procedure can be initiated if the congestion level is less than a predetermined level.

[0173] (Supplementary Note 6) The communication method according to Supplementary Note 5, wherein the determining step includes determining to start the RRC connection resume procedure when the congestion level is below the predetermined level and reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to acquire a multicast reception configuration from the network node.

[0174] (Supplementary Note 7) A user equipment used in a mobile communication system that provides a multicast broadcast service (MBS), comprising: a receiving unit that receives, from a network node, prohibition period information and / or network congestion information for determining whether to start a radio resource control (RRC) connection resume procedure related to a multicast session; and a control unit that, in an RRC inactive state, determines whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information, wherein, when it is determined that the RRC connection resume procedure should be started, the control unit starts the RRC connection resume procedure with the network node.

[0175] (Supplementary Note 8) A communication method executed by a network node in a mobile communication system providing a multicast broadcast service (MBS), comprising: managing priority information that associates information indicating a priority of multicast reception of a user equipment with an identifier assigned to the user equipment; transmitting to the user equipment a radio resource control (RRC) release message that transitions the user equipment to an RRC inactive state, the RRC release message including the identifier; receiving from the user equipment an RRC resume request message including the identifier; and determining whether to accept the RRC resume request of the user equipment based on the identifier and the priority information included in the RRC resume request message.

[0176] (Supplementary Note 9) The communication method according to Supplementary Note 8, further comprising: receiving user equipment information indicating a priority of the multicast reception from a core network device; and determining the priority of the multicast reception based on the user equipment information.

[0177] (Supplementary Note 10) A network node used in a mobile communication system that provides a multicast broadcast service (MBS), comprising: a control unit that manages priority information that associates information indicating a priority of multicast reception of a user equipment with an identifier assigned to the user equipment; a transmission unit that transmits to the user equipment an RRC release message that causes the user equipment to transition to an RRC inactive state, the RRC release message including the identifier; and a reception unit that receives from the user equipment an RRC resume request message including the identifier, wherein the control unit determines whether to accept the RRC resume request of the user equipment based on the identifier and the priority information included in the RRC resume request message.

[0178] (7) Supplementary Note 3 1. Introduction The work item on enhanced MBS (eMBS) aims to support multicast reception by UEs in inactive state as follows: - Specify support for multicast reception by UEs in RRC inactive state [RAN2, RAN3]. - PTM configuration for UEs receiving multicast in RRC inactive state [RAN2]. - Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not mandatory) [RAN2, RAN3].

[0179] This appendix discusses the details of RRC resume due to bad quality and the causes of the resume.

[0180] 2. Discussion 2.1. RRC Resume Due to Deterioration of Reception Quality RAN2#123 agreed to introduce RSRP / RSRQ-based RRC Resume as follows.

[0181] For a UE receiving multicast in an RRC inactive state, the UE resumes the RRC connection when the RSRP or RSRQ measured based on the existing measurement requirements of the serving cell (whichever is set by the network) falls below a threshold set by the network. Whether the ping-pong issue needs to be addressed is a matter for further study.

[0182] The threshold can be PTM configured per MBS session via RRC Release or multicast MCCH messages.

[0183] Based on the agreement, remaining issues are discussed in the following sections.

[0184] 2.1.1 Ping-pong issue The agreement captures the considerations of "whether or not the ping-pong issue needs to be addressed / how to address it." Possible scenarios for resuming ping-pong include the following:

[0185] 1. A UE in an inactive state with deteriorating radio quality will initiate RRC resume when the RSRP / RSRQ falls below the threshold. 2. In response to the RRC resume request, a gNB under network congestion will send an RRC release with a suspend config. that includes the RSRP / RSRQ threshold. 3. A UE whose radio quality remains deteriorating will transition to an inactive state again, and since the RSRP / RSRQ will soon fall below the threshold, RRC resume will be initiated again.

[0186] To avoid ping-pong in the above scenario, the gNB may keep the UE in a connected state or set appropriate RSRP / RSRQ thresholds for the UE.

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

[0188] Observation 1: In order to guarantee QoS requirements, the gNB may need to know the UE's radio conditions when the UE requests RRC resume and the reason for RRC resume.

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

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

[0191] Considering the above observations, when the UE initiates RRC resume due to a deterioration in reception quality during the RRC resume procedure, it is useful for the UE to report the measurement results in the RRC resume request or RRC resume complete. Another option is for the UE to indicate the deterioration in radio conditions in the resume cause. With such information, the gNB can make an appropriate decision on whether to keep the UE in connected state for QoS guarantees.

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

[0193] 2.1.2 Validity of RSRP / RSRQ Thresholds Configured by RRC Release RAN2 agreed that "thresholds can be configured by RRC release or by PTM configuration per MBS session via multicast MCCH messages." For dedicated configurations provided by RRC release, many settings remain valid until the corresponding timer expires. For example, dedicated frequency priority remains valid until T320 expires. This occurs regardless of cell reselection; dedicated settings provided by the source cell remain valid even after the UE reselects the target cell.

[0194] Observation 3: According to the current specification, many dedicated settings remain valid until a timer expires, regardless of cell reselection.

[0195] Regarding the RSRP / RSRQ thresholds, if they are valid after cell reselection, problems may occur assuming the following conditions: - In the source cell, PTM is transmitted with a low MCS, so the UE sets a low RSRP threshold to ensure a certain reception quality. - In the target cell after cell reselection, PTM is transmitted with a higher MCS, but the UE still applies the old RSRP threshold. - As a result, the UE will experience MTCH reception errors even though the RSRP is still better than the old threshold.

[0196] To avoid this problem, the RSRP / RSRQ thresholds should be cell-specific, considering that the PTM transmission of NR MBS is cell-specific, i.e., if the UE reselects a different cell, the old RSRP / RSRQ thresholds should be discarded.

[0197] Proposal 2: RAN2 should agree to discard the RSRP / RSRQ thresholds upon cell reselection.

[0198] Another possible issue in handling RSRP / RSRQ thresholds is which threshold should the UE apply when thresholds are provided by both RRC release and multicast MCCH. In the current specification, dedicated settings provided by RRC release generally take precedence over settings provided by SIB. However, for inactive multicast reception, RAN2 agreed that "if the PTM setting needs to be changed, RAN2 will use the MCCH to indicate it," meaning that the PTM setting provided by RRC release may be changed by the PTM setting provided by multicast MCCH. This means that the RSRP / RSRQ thresholds cannot be UE-specific, i.e., TMGI-specific, because they are overwritten by the multicast MCCH.

[0199] Proposal 3: RAN2 should ensure that the PTM configuration including RSRP / RSRQ thresholds provided by RRC release is always overridden by the configuration provided by multicast MCCH, i.e. there is no UE-specific configuration for inactive multicast reception.

[0200] 2.1.3 Other Confirmations RAN2#123 agreed that "for a UE receiving multicast in an RRC inactive state, the UE resumes the RRC connection when the measured RSRP or RSRQ [...] of the serving cell falls below a threshold [...]." The RSRP / RSRQ threshold is introduced to guarantee QoS for multicast reception in an inactive state.

[0201] On the other hand, if the multicast session is deactivated by the network, a UE in an inactive state may not receive the MTCH (or temporarily not receive data) when the session is deactivated. In this case, the UE is considered the same as a legacy UE in an inactive state, so RRC resume due to quality deterioration (RSRP / RSRQ threshold) is not required. As already implied in the above agreement, a UE in an inactive state must ensure that it does not initiate RRC resume if the multicast session is deactivated (or there is temporarily no data), even if the RSRP / RSRQ deteriorates below the threshold.

[0202] Proposal 4: RAN2 needs to ensure that inactive UEs do not initiate RRC resume when the multicast session is disabled (or there is temporarily no data), even if the RSRP / RSRQ becomes worse than the threshold.

[0203] In RAN2#123, RAN2 discussed whether the threshold could be based on BLER, but ultimately RAN2 decided to adopt RSRP / RSRQ.

[0204] On the other hand, in Release 17, it was a common understanding in RAN2 that SFN (single frequency network) can only be deployed depending on the network implementation, e.g., within a DU. In inter-cell SFN, reception quality is stable even at the cell edge by combining reception from MTCHs of different cells. However, RSRP / RSRQ are cell-specific and degrade at the cell edge when moving away from SFN. Therefore, RSRP / RSRQ thresholds do not work well in SFN deployments, but BLER thresholds can avoid such issues.

[0205] Proposal 5: RAN2 should ensure that the NW implementation does not operate the SFN (Single Frequency Network) allowed in Release 17 at the RSRP / RSRQ threshold in Release 18.

[0206] RAN2#123 agreed to reuse existing resume causes for RRC resume due to several reasons other than the deterioration of reception quality discussed in the previous section in Release 18. However, it is still necessary to analyze which existing resume causes are applicable and whether new resume causes are really unnecessary.

[0207] No new resume causes are introduced for UEs receiving inactive MC when resuming due to quality degradation or incorrect SIBx / PTM configuration, unless a problem is identified with using one of the existing resume causes.

[0208] Currently, 11 resumes are defined, along with 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}

[0209] Similar to observation 2 above, one of the motivations for inactive multicast reception is to alleviate network congestion, so the analysis must consider the case when the network is congested.

[0210] Observation 4: The mapping of RRC resume and existing resume causes for multicast reception needs to take into account the congestion state of the network.

[0211] Typical gNB decisions when receiving an RRC Resume request during network congestion can be classified as follows: - Always accept emergency situations; - Prioritize highPriorityAccess, mps-PriorityAccess, and mcs-PriorityAccess; - Accept mt-Access and mo-Signalling (as much as possible); - May reject mo-Data, mo-VoiceCall, mo-VideoCall, and mo-SMS; - In the case of rna-Update, respond with an RRC release with a new RNA.

[0212] Observation 5: Resume allows the gNB to decide whether to accept, reject, or release with a new RNA in response to an RRC resume request, especially in the case of NW congestion.

[0213] RAN2 has agreed that the UE will initiate RRC resume in two cases: due to quality degradation or insufficient SIBx / PTM configuration. From the perspective of the impact on network load, these reasons are characterized as follows:

[0214] As discussed in Section 2.1.1, in the case of RRC resume due to quality deterioration, the UE must remain connected because if the UE is released again while in inactive, QoS requirements will no longer be guaranteed. Considering that the UE must remain connected, the UE does not consume additional downlink resources (since it only receives PTMs already sent to other UEs), but it does consume uplink resources (e.g., HARQ ACKs). In times of network congestion, this consumes slightly more resources compared to multicast reception in inactive state, but may still be prioritized over resume requests for unicast services. In other words, the gNB may prioritize RRC resume requests for multicast reception over RRC resume requests for unicast reception, but may still reject the RRC resume request due to high congestion.

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

[0216] Observation 6: In order to keep the UE connected when the network is congested, the gNB may reject RRC resume due to quality degradation, which may have some impact on the network congestion.

[0217] Observation 7: Due to SIBx / PTM configuration deficiency, the gNB can accept RRC resume and immediately release UEs with PTM configuration, as this does not affect network congestion.

[0218] Considering the above discussion, RRC resume due to bad quality may be mapped to either mo-Data, mo-VoiceCall, mo-VideoCall, or mo-SMS. However, since multicast reception in Connected does not require additional PDSCH resources (i.e., PTM is already provided for other UEs), current gNB implementations 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.

[0219] For RRC resume due to lack of SIBx / PTM settings, there is no mapped resume cause because there is a new intent of RRC resume with PTM settings. For rna-Update, a similar gNB decision is assumed, but the gNB provides RNA instead of PTM settings for RRC resume. This means that 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 only requesting a PTM setting update, which has no impact on network congestion.

[0220] Observation 8: There is no existing resume cause that matches the gNB's expected decision in the case of an RRC resume request, either due to quality degradation or insufficient SIBx / PTM configuration.

[0221] RAN2 has indeed identified new possible resume causes with the following discussion: Resume Causes: 1. Multicast Quality 2. Multicast Configuration

[0222] These two resume causes can easily solve all the problems discussed above without potentially impacting current gNB implementations. As discussed above, the two resume causes are useful for gNBs to appropriately guide different results. Therefore, two new resume causes should be introduced accordingly.

[0223] Since 3GPP is likely to begin considering 6G from Release 20, 5G NR is expected to evolve over only the next two releases (i.e., up to Release 20 at most). Given the history of additional resumes in past releases, three resumes in Release 18 will be sufficient.

[0224] Proposal 6: RAN2 should agree on a new resume cause "Multicast Quality" to be set when RRC resume is initiated due to quality degradation. Expected gNB decisions take priority over MO data, etc.

[0225] Proposal 7: RAN2 should agree on a new resume cause "multicast configuration" that is set when RRC resume is initiated due to SIBx / PTM misconfiguration. The expected gNB decision is to respond with an RRC release with PTM configuration.

[0226] 1: Mobile communication system 5: Network 10: RAN 20: CN 100: UE (user equipment) 110: Receiving unit 120: Transmitting unit 130: Control unit 200: gNB (base station) 210: Transmitting unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method executed by a user device in a mobile communication system providing a Multicast Broadcast Service (MBS), comprising: receiving, from a network node, prohibition period information and / or network congestion information for determining whether to start a Radio Resource Control (RRC) connection resume procedure related to a multicast session; determining, in an RRC inactive state, whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information; and, when it is determined that the RRC connection resume procedure should be started, initiating the RRC connection resume procedure for the network node.

2. The communication method of claim 1, wherein the receiving step includes receiving an RRC release message from the network node, the RRC release message including prohibited period information indicating a period during which initiation of the RRC connection resume procedure is prohibited, and transitioning the user equipment to the RRC inactive state; and the determining step includes determining that the RRC connection resume procedure can be initiated if the period indicated by the prohibited period information has expired.

3. The communication method according to claim 2, wherein the determining step includes determining to initiate the RRC connection resume procedure when the period indicated by the prohibited period information has expired and reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to acquire multicast reception settings from the network node.

4. The communication method according to claim 2 or 3, wherein the prohibition period information is associated with a multicast session identifier, and the determining step includes determining that the RRC connection resume procedure related to the specific multicast session can be initiated if the user equipment is participating in and / or receiving a specific multicast session indicated by the multicast session identifier and the period indicated by the prohibition period information has expired.

5. The communication method according to claim 1, wherein the receiving step includes receiving broadcast signaling from the network node including network congestion information indicating a congestion level of the network node, and the determining step includes determining that the RRC connection resume procedure can be initiated if the congestion level is less than a predetermined level.

6. The communication method according to claim 5, wherein the determining step includes determining to initiate the RRC connection resume procedure when the congestion level is less than the predetermined level and reception quality during multicast reception in the user equipment has deteriorated and / or the user equipment needs to acquire multicast reception settings from the network node.

7. A user equipment used in a mobile communication system providing a multicast broadcast service (MBS), comprising: a receiving unit that receives from a network node prohibition period information and / or network congestion information for determining whether to start a radio resource control (RRC) connection resume procedure related to a multicast session; and a control unit that, in an RRC inactive state, determines whether to start the RRC connection resume procedure based on the prohibition period information and / or the network congestion information, wherein when the control unit determines to start the RRC connection resume procedure, it starts the RRC connection resume procedure with the network node.

8. A communication method executed by a network node in a mobile communication system providing a Multicast Broadcast Service (MBS), comprising: managing priority information that associates information indicating a priority of multicast reception of a user equipment with an identifier assigned to the user equipment; transmitting to the user equipment a radio resource control (RRC) release message including the identifier, the RRC release message causing the user equipment to transition to an RRC inactive state; receiving from the user equipment an RRC resume request message including the identifier; and determining whether to accept the RRC resume request of the user equipment based on the identifier and the priority information included in the RRC resume request message.

9. The communication method according to claim 8, further comprising: receiving user equipment information indicating a priority of the multicast reception from a core network device; and determining the priority of the multicast reception based on the user equipment information.

10. A network node used in a mobile communication system providing a Multicast Broadcast Service (MBS), comprising: a control unit that manages priority information that associates information indicating the priority of multicast reception of a user device with an identifier assigned to the user device; a transmission unit that transmits to the user device an RRC release message that transitions the user device to a Radio Resource Control (RRC) inactive state, the RRC release message including the identifier; and a reception unit that receives from the user device an RRC resume request message including the identifier, wherein the control unit determines whether to accept the RRC resume request of the user device based on the identifier and the priority information included in the RRC resume request message.

Images